# Breixo Fernández — Product Designer > Product Designer with 15+ years across AI, B2B systems, and technically complex products, from early-stage startups to $1B+ platforms. ## Expertise - **AI & Emerging Products**: From 0 to 1 in production AI agents. Designing non-deterministic systems and the design framework that supports them. - **Complex B2B Systems**: Highly technical, multi-stakeholder platforms. I map internal complexity so end users experience radical simplicity. - **Design × Engineering**: Engineering background. I speak both languages, and build the systems, rituals, and teams that keep them aligned. ## Case studies ### Aircall: Designing trust into Aircall's first AI voice agent URL: https://breixofernandez.com/case/aircall Built from zero: from a first, fully assisted beta to ~45% self-serve adoption, cutting the time to go live from two weeks to four days. - **Role:** Design Lead, AI Voice Agent - **Team:** Core team of 1 PM + 2 engineers, growing to 10+ engineers, with Sales, Solutions Engineering and training involved - **Timeline:** 2024 – now I set the design direction and guidelines for the agent experience, partnering with designers across other product areas where it touched their scope. #### Context Aircall's AI Voice Agent answers and makes phone calls on behalf of a business. It handles support, reception and scheduling, reads from a knowledge base, takes actions like updating the CRM, and hands off to a human when needed. Unlike a chatbot in a widget, it goes live on a real phone line, talking to real customers in the company's name. Once it's live, you have very little control over what it says. That made trust, not capability, the main barrier to adoption. We started as a very small team, and we had to move fast. The goal was to deliver value from day one and get a product into customers' hands as early as possible, so we could learn from real use. #### Designing the beta as a learning system We started with a hand-picked group of companies. At first, the PM and I worked alongside them directly, reacting to every issue and learning what setup really required. Then we turned that into a playbook and partnered closely with Forward Deployed Engineering and Solutions Engineering, so they could run onboarding without us. What it changed: our roadmap was heading toward giving the agent more skills, like writing to a CRM or connecting to other systems. The beta showed us that trust had to come first. Instead of adding skills, we spent a lot of time polishing the interaction itself, like how the agent handled interruptions, and proposing ways for people to keep control, starting with a reliable handoff to a human. The same signal led us to make prompting a first-class part of the experience from the start. #### What we learned from 30 beta customers > For non-deterministic AI, design's job isn't to be clever. It's to generate confidence. What you expose, how you frame it, and how it connects to what users already trust, is everything. - **They were afraid of two things:** the agent inventing answers, and not knowing when it would hand off to a human. - **They didn't know what "good" looked like.** Once live, there was no clear way to tell how well the agent was doing or how to make it better. - **They wanted to write, not configure.** I expected people to want structured options for more control. From the first sessions, they reached for natural language: an open-ended interface where they could describe what they wanted in their own words, instead of picking from menus. #### Key decisions 1. **Natural language where it behaves, controls where it acts** I started from the assumption that admins would want structured options for more control. Research said otherwise: they wanted to instruct the agent the way it would speak. So we split the model: - Behavior (tone, how to handle conversations) → free-text instructions. - Anything that touches our deterministic systems (call transfers, actions, integrations) → explicit configuration. When the agent hands off a call or writes to a CRM, how it works has to be unambiguous. **Templates as a starting point.** Writing a good prompt from scratch is hard, and you never know if you're doing it right. Each template is a working agent for a common use case (support, sales, reception, after-hours) that performs acceptably from day one. Users start there and refine, instead of facing a blank field. 2. **Make quality visible, before and after going live** Users didn't know what a good agent looked like, and a phone line gives you no second chance. So we built confidence into every stage. **Before going live: test it.** - Test calls, available from day one: hear the agent exactly as your customers will. - Simulated scenarios: another LLM generates realistic caller situations and runs them against your agent. An agent testing an agent, at a scale no one could test by hand. **After going live: see how it's doing.** Resolution rate and performance against the goals you set for the agent. **And know what to fix.** - Knowledge gaps: questions callers asked that your knowledge base doesn't answer, ready for you to add. - Configuration gaps: specific recommendations to improve how the agent is set up. #### From assisted setup to self-serve At launch, every agent was set up with help from our internal teams. That worked for learning, but it couldn't scale. Getting to self-serve took several things working together: - Templates that give a working agent from the first minute. - Build from a prompt: describe the agent you need and get a first version. - Embedded guidance and training, built for both customers and our internal teams, so the knowledge that lived in a few people's heads became part of the product. #### Impact What design moved: - ~45%: of customers set up their agent self-serve, up from fully assisted at launch Driven by: Templates (decision 1), build from a prompt and embedded guidance (from assisted setup to self-serve). - 2 wks → 4 days: from first setup to a live line Driven by: Self-serve setup, plus test calls and simulated scenarios before going live (decision 2). - ~80: NPS from admins Where the product went: - MRR, 4 months after the project started: $50K - MRR today: $2M+, backed by a major company investment in voice agents #### What I'd do differently I'd document conversational design decisions earlier. We made hundreds of micro-decisions about agent language and behavior that lived in our heads or in Slack threads. A lightweight decision log would have accelerated productization and made onboarding new team members much easier. ### Veepee: One entry point to sell across Europe URL: https://breixofernandez.com/case/veepee Unifying a partner experience fragmented across acquired companies, cutting onboarding from 7–8 weeks to 2–3 on average. - **Role:** Senior Product Designer & Researcher - **Team:** Lead PM, engineering leads and multiple stakeholders, distributed across Paris, Barcelona, Seville and Brussels - **Timeline:** 2021 – 2022 I was brought in to map the end-to-end partner landscape and set the design direction, working with designers who owned the individual tools and products I audited. #### Context Veepee, Europe's flash-sales leader, was building something new: a permanent catalog where brands could sell year-round, from small brands onboarding on their own to large partners like L'Oréal or Monoprix supported step by step. Veepee had grown by acquiring competitors in Spain, Italy and Belgium. Each kept its own tools, processes and terminology. They did roughly the same work, but not in the same way. So a brand that started selling with us in Spain couldn't easily expand to France or Italy, and the promise we wanted to sell, one entry point to sell across Europe, wasn't possible yet. #### Making the fragmentation visible Nobody had the full picture. Each team saw its own piece. So I built a map of the whole landscape: every system and actor involved in onboarding, in one large annotated board, with the key pains and opportunities for each internal role and the quirks of each system. It started with interviews, then became co-creation: I worked with the leads of internal teams, like Brand Support managers, and with the teams connecting our strategic partners to Veepee. Each area linked to the workshop outcomes where teams set their own priorities. Alongside it, I mapped the journey of strategic partners like L'Oréal, to show the same process from their side. The map gave everyone one shared view to set priorities against, and made the bottlenecks impossible to miss. Two stood out: carrier setup, and the master app, which partners had to complete before any other tool would work for them. #### What the research uncovered **Onboarding took 7–8 weeks on average.** Not because of one big blocker, but because of many small ones stacking up across countries and teams. - **Every country meant starting over.** Expanding a brand to a new market meant a different local team, different tools, and steps that didn't work quite the same way. - **Shipping setup wasn't coordinated well.** Carrier configuration, the delivery options each partner could offer, ran through third-party tools, and our checks on it were fragile. When something went wrong there, nobody found out, which led straight to the next problem. - **Accounts stalled silently.** Notifications didn't reach the right people, so a partner's account could sit on hold for days until someone in Brand Support happened to notice. - **Partners didn't know it was their turn.** We had a central app where partners entered their information to unlock the next steps: catalog import, configuration in other systems. But the sequence wasn't clear. Partners waited for us, while we were waiting for them. #### Key decisions 1. **One place to configure, with clear next steps** We centralized configuration in the master app and redesigned it around what partners needed to understand: where they were, what was on them, and what was on us. Better feedback at every step meant partners stopped waiting on actions that were theirs to take. 2. **Alerts that reach both sides** Carriers varied by country, and each could request actions at any point. We built a unified alert system: when an action was needed, both the brand and the right internal person (Brand Support or the Key Account Manager) were notified. Accounts stopped stalling silently. 3. **Unify the experience, not the systems** Each country's systems handled carriers slightly differently, and we kept rebuilding the same integrations in parallel. I pushed hard for a single unified layer for the most common carriers, rather than keeping a separate setup per country. **The trade-off:** more upfront work, and closer dependence on a handful of major European carriers. **What we gained:** centralized management, a flow partners could actually understand, and much faster onboarding. We applied the same pattern to stock: a master app giving partners one view across markets, even when the underlying tools stayed local. #### Impact What design moved: - 7–8 → 2–3 wks: average partner onboarding time Driven by: Clear next steps in the master app (decision 1), alerts to both sides (decision 2) and the unified carrier layer (decision 3). - > 50%: fewer Brand Support tickets Driven by: Partners knowing what was on them (decision 1), and alerts reaching the right person (decision 2). Where the business went: - Major partners onboarded: 3: L'Oréal, Ubaldi, Monoprix - Smaller partners onboarded: ~20 #### What I'd do differently **Filter requests against the priorities we'd agreed.** I gave too much weight to requests from business development. They were focused on closing deals, and some of what we built for them didn't move the partner experience. The map already showed what mattered most; I'd use it to say no sooner. **Plan the map's lifespan from the start.** It was a static artifact that needed constant upkeep. It was the right tool to align everyone at one moment, but not to steer the project over time. I'd have been clearer about that from day one, and set up a lighter way to track progress alongside it. ### Cycloid: From internal tool to SaaS product URL: https://breixofernandez.com/case/cycloid Building Cycloid's design practice from zero while shaping the product that took the company from $8M to $28M. - **Role:** Founding Designer → Design Lead - **Team:** Founding team (founder, CTO) and Core DevOps team; built and led a design team of 5 - **Timeline:** 2018 – 2020 As the company's first designer, I built the practice from zero and grew it to a team of five, combining designers focused on visual design with hybrid designer-developer profiles. #### Context Cycloid is a platform for DevOps teams that brings together pipelines, infrastructure as code and environment management across multiple clouds. Its idea: a platform team defines good practices once, and the whole organization benefits from them, deploying without needing to be infrastructure experts. The technology was powerful, but it was sold and used like an internal tool: on-premise installations, delivery through partners, heavy customization for every client. Going SaaS meant two things it didn't have yet: self-serve capabilities like subscription, and a product customers could use without someone from Cycloid guiding them. #### Building a design practice that didn't depend on me When I joined, the team was small and everything was debated asynchronously in GitHub threads. It was part of the company's DNA, but it didn't scale. I pushed for regular weekly sessions that brought together development, the DevOps engineers who validated the functional decisions, and product (the CTO and me). Within the design team, async critiques handled the work that didn't need a meeting. It changed who got heard. Decisions stopped going to whoever was most persistent in a thread, and started coming from people thinking through problems together. Fewer back-and-forths, more involvement, and a way of working that held up as the team grew. As the company scaled and teams specialized, every team adopted these rituals, and we added new ones to track and steer the roadmap. #### What we learned I audited the product against competitors, and became fluent in Concourse and Terraform myself. You can't simplify what you don't understand. - **Nobody could see the whole picture.** Teams lacked a shared view of their whole infrastructure and how it was connected. It was the gap we saw against competitors, and the first thing customers and partners asked for. - **Non-experts got lost in the possibilities.** Terraform and Concourse can do almost anything, which is exactly the problem for someone who just needs to deploy. - **Opinions were welcome.** I expected users to resist being told how to do things. Instead, they were happy with an opinionated product, as long as it solved their problem. #### Key decisions 1. **Opinionated defaults, full power on demand** Good practices applied by default, so non-experts could deploy safely and consistently. Progressive disclosure for experts, who could still use everything Terraform offers. One product, from newcomer to platform expert: catalog → configuration → operations. 2. **A design system as a contract with engineering** The goal wasn't a style guide, but a shared language that could scale without me in every room. The same type of data always looked and behaved the same way in the UI. And we left room for free-text editing where structure would have been a constraint, not a help. #### Impact What design moved: - ~20%: of customers on the first self-serve offering, in a business still built around enterprise sales Driven by: Opinionated defaults that let non-experts deploy on their own (decision 1). - 1 → 5: design team, with rituals adopted across engineering teams Driven by: The weekly sessions and async critiques described in how I worked. Where the business went: - Company valuation: $8M → $28M in just over 2 years - Orange Business Services: Strategic partnership: investor and key customer, with 20+ internal teams adopting the product #### What I'd do differently I'd set up research with our community much earlier. We had a technically engaged user base that could have told us what to prioritize and what to skip. Without that signal, we built some things we shouldn't have and delayed others we should have shipped sooner. ### Lulu dans ma rue: Designing for access, not preference URL: https://breixofernandez.com/case/lulu Turning one paper-based kiosk in Le Marais into a service supporting 250–300 requests a day, across four digital and physical touchpoints. - **Role:** Founding Designer - **Team:** Founder, small in-house team and external collaborators - **Timeline:** 2016 – 2017 As the only designer, I owned the full service design across four surfaces (customer app, provider app, back office and physical kiosks), working directly with the Lulus, the local providers who delivered the services, and bringing in external partners for illustration and web. #### Context Lulu dans ma rue is a city-backed platform that connects Paris neighbors with local service providers, the Lulus, for everyday help: cleaning, small repairs, errands, tech help. It started as a proof of concept with a social inclusion mission: showing that a business could sustain itself, serve its customers well, and be good for society at the same time. Customers came for different reasons: some were drawn to the project's philosophy, others simply found it useful and practical. The Lulus came from two very different populations: young, tech-comfortable people looking for flexibility, and people at risk of exclusion looking for stable income, often with little digital experience and limited French. When I joined, there was one kiosk in Le Marais, running on paper. #### Researching with people who blame themselves Sessions looked very different depending on who was in the room. Tech-help Lulus came with complaints and ideas for improvement. Many cleaning Lulus, often very grateful to be there, assumed that if something didn't work, it was their fault. They struggled with the app, but would never say the app was the problem. That's why research had to happen through observation, group sessions and prototype testing, not just by asking. And it shaped the interaction model: a universal design built on color codes and a radically simplified experience, usable by someone with very limited digital experience. For experienced users, we added shortcuts to get things done faster, without making the app harder for everyone else. #### What the fieldwork showed Before touching any tool, I spent weeks embedded at the kiosk in Le Marais, watching how the service actually worked on the ground. - **Requests arrived incomplete.** Communication didn't break down; information was missing. A concierge would pass on a request, say a repair in someone's kitchen, but the Lulu couldn't tell whether they could take it. The back-and-forth cost time and frustrated customers. - **Trust was built by people.** In the kiosk, the concierges reassured neighbors and explained how it worked. That was what made someone comfortable letting a stranger into their home, and the hardest thing to carry into a digital product. - **Lulus cared about fairness, not speed.** We expected providers to compete, grabbing missions as fast as possible on their phones. Instead, they cared that work was shared out fairly. #### Key decisions 1. **Requests a Lulu can say yes to** We mapped every type of service and the information each one needed. In the apps, each request launched a guided flow of questions, sometimes very specific to the job, so the Lulu had reliable information to decide whether to accept. A phone call was always possible to settle details: we couldn't capture everything, but we made sure nobody accepted blind. 2. **Carry human trust into the digital product** In the kiosk, trust came from the concierges. In the app, we made reaching a person easy at every step, and made the support behind every Lulu visible: each one was accompanied, followed up, and problems could be reported. Customers rated every service, and concierges rated reliability. We also invited customers, in the app and in person, to share feedback, framed around the project's social mission, closing the loop between what Lulus did and how they were seen. 3. **Fair over fast** The hardest balance. Customers wanted missions accepted quickly; Lulus wanted work shared fairly. The assignment algorithm balanced both: missions were offered with a delay to Lulus who had already done many, without slowing acceptance down too much. Later, Lulus could optionally share their availability. We couldn't require it legally, but it let us match workload to their schedules. 4. **Kiosks as trust infrastructure, not a fallback** The app didn't replace the kiosk. The kiosk was the primary place for onboarding and for the social connection, and the trust it created. Human support was designed in as a core part of the service, not as a fallback for edge cases. #### Impact What design moved: - 40 → 250–300: daily service requests supported, in 18 months Driven by: Guided requests that Lulus could accept without back-and-forth (decision 1). The new kiosks and more Lulus (below) also drove this growth. - Almost zero: Lulu complaints about missing missions or not understanding how to accept them Driven by: Fair assignment (decision 3), and the simplified, color-coded provider app (how I worked). Where the service went: - Active Lulus: ~60 → 250+ - Physical presence: 1 paper-based kiosk → 3 kiosks, a van serving markets, and a stand in a shopping center #### What I'd do differently I'd focus purely on observed frictions rather than assumptions about who the users were. Designing for accessibility means removing the barriers people actually encounter, not the ones you predict based on their background. ## Experience - 2023 – now · **Aircall**: Design lead for Aircall's first AI voice agent, at a $1B+ company. - 2021 – 2022 · **Veepee**: Designed cross-org systems for Europe's leading flash sales platform (90M members). - 2021 · **Cegid**: Post-acquisition UX audit for HR platform Meta4. - 2018 – 2020 · **Cycloid**: Built design org and SaaS foundation while the company grew from an $8M to a $28M valuation. - 2016 – 2017 · **Lulu dans ma rue**: Founding designer. Built an inclusive urban services platform with the city of Paris. - 2013 – 2016 · **Ippon**: Design + front-end dev for Chanel, AXA, Société Générale. - 2010 – 2012 · **Sopra**: J2EE engineer on French social services systems. ## Contact - Email: brei.pro@gmail.com - LinkedIn: https://www.linkedin.com/in/breixo-fl/ ## Links - [Home](https://breixofernandez.com/) - [Experience](https://breixofernandez.com/experience) - [CV (PDF)](https://breixofernandez.com/Breixo%20Fernandez%20-%20Product%20Designer.pdf)