Bdeo · Sistema de diseño · Lectura de 9 min
Ethos, sistema de diseño multicliente · Bdeo
210 componentes · casi todos los clientes sobre la misma base
Caso de estudio de Vicente Molero, Senior Product Designer.
Resumen
Bdeo · Sistema de diseño
Ethos, el sistema de diseño de Bdeo. El cliente cambia los fundamentos, no los componentes.
Cada aseguradora quería ver su marca en el producto. Durante años, eso significó un producto distinto para cada una. Ethos separa lo que cambia por cliente, los fundamentos, de lo que no cambia nunca: los componentes y las reglas que los gobiernan.
En 30 segundos
En 30 segundos
- Problema
- No había sistema de diseño. Solo en la administración de siniestros convivían 10 botones con 7 estilos y ninguna regla, y cada cliente exigente tenía su propia versión del producto.
- Mi papel
- Lo propuse y diseñé su arquitectura: fundamentos, componentes, principios y documentación. Ingeniería lo implementó y el CTO lo patrocinó.
- Resultado
- Casi todos los clientes tienen hoy su marca aplicada sobre la misma base de 210 componentes, y soporte la aplica sin pasar por diseño ni desarrollo. El tech lead estima un 40% más de velocidad de desarrollo.
- Rol
- Senior Product Designer · diseño y dirección del sistema
- Duración
- En marcha. Nació en el rediseño del Dashboard de siniestros.
- Equipo
- Diseño (yo), ingeniería de front y soporte.
- Contexto
- Plataforma B2B multicliente para aseguradoras en más de 30 países. Cada cliente aplica su marca sobre la misma base.
Impacto
- 210 Componentes sobre la misma base — 44 componentes principales, 1.643 variantes y 134 iconos.
- Casi todos Los clientes, con su marca sobre Ethos — Soporte aplica cada tema en código, sin pasar por diseño ni desarrollo.
- ~40% Más velocidad de desarrollo — Estimación del tech lead. No hay una medición con línea base.
Antes cada pantalla empezaba de cero. Con Ethos montamos una funcionalidad nueva con piezas que ya están probadas, y se nota en los plazos.
El reto
Cuando llegué no había sistema de diseño. Había Figmas por proyecto, algunos heredados de agencias, sin relación entre ellos, y componentes en código que no se podían reutilizar.
Y cada cliente pedía su personalización. Si era exigente, se le hacía. Así el producto se fue partiendo: la misma pantalla se veía distinta según quién la abriera.
El botón lo resume. Solo en la administración de siniestros había 10 botones con 7 estilos distintos y ninguna regla para elegir entre ellos. En Ethos son 3 tipos (principal, secundario y destructivo) y 4 estados (normal, hover, pulsado y desactivado). Un solo sistema.
El coste no se veía en una factura. Se veía en bugs visuales, en retrabajo de desarrollo y en decisiones que se volvían a tomar en cada pantalla.
Los ejemplos están modificados para proteger datos de clientes.
Objetivos
Cada problema del antes se convirtió en un objetivo del sistema:
| Antes de Ethos | Objetivo |
|---|---|
| Cada cliente exigente tenía su propia versión del producto | 1 · Multicliente: el cliente cambia los fundamentos, no los componentes |
| 10 botones, 7 estilos y ninguna regla | 2 · Coherente: cada componente con su regla, y cada regla con su principio |
| Nadie sabía qué usar ni por qué | 3 · Autoexplicativo: que el sistema responda sin preguntar a diseño |
| Personalizaciones que solo existían para un cliente y nadie sabía mantener | 4 · Escalable: que soporte aplique un tema sin diseño ni desarrollo |
| Componentes con nombres que solo entendía quien los hizo | 5 · Legible para una IA: nombres y reglas que entienden una persona nueva y una IA |
Resultados
Objetivo 1 · Multicliente
La decisión que define a Ethos es dónde se pone la frontera entre la marca y el producto. La puse en los fundamentos.
Lo que cambia por cliente: color, tipografía, radios y el resto de fundamentos. Cada aseguradora tiene su tema en código.
Lo que no cambia nunca: los 210 componentes, su estructura, sus estados y sus reglas. Una tabla de siniestros funciona igual para todos; solo se viste distinto.
Para llegar aquí hubo que decidir antes otra cosa. Ingeniería propuso partir de una plantilla o de un sistema de diseño existente: era la vía rápida. Yo defendí lo contrario ante el CTO. Bdeo iba a crecer en verticales y casi cada cliente iba a necesitar su tema, y adaptar un sistema ajeno a eso nos obligaba a forzar una arquitectura que no estaba pensada para ello. El CTO lo apoyó, y Ethos se hizo nuestro, multitema desde el primer componente.
Los fundamentos de la base, cada uno con su escala:
- Tipografía. No la elegí: la heredé. Telegraf y Space Mono ya estaban en el brand book de Bdeo, y no tenía sentido abrir esa discusión. Mi trabajo no era elegir una letra, era convertirla en un sistema: 8 tamaños, de 12/16 a 48/68, y 18 estilos con un uso definido cada uno, del titular al dato técnico. Como cada aseguradora trae la suya, la familia cambia por cliente. La escala, la jerarquía y el ritmo se quedan.
- Espaciado: 11 pasos, de 0 a 192 px. Pocos y con saltos claros, para que nadie tenga que elegir entre 14 y 15.
- Radios y bordes: 4 radios (0, 4, 8 y redondo), 2 grosores y 3 estilos de borde. Menos opciones, menos discusiones.
- Elevación: 5 niveles, de sin sombra a la sombra más alta. La sombra dice qué está encima de qué, no decora.
- Color: 169 variables en capas. Las primitivas guardan los valores; las semánticas dicen para qué sirve cada uno (fondo, texto, estado, marca). Un componente nunca usa un color en bruto, siempre su significado. Por eso, al cambiar de cliente, el botón principal, los estados y el degradado de marca cambian en bloque, sin tocar un componente.
Objetivo 2 · Coherente
Antes de los componentes escribí los principios: ocho, en tres grupos. Los de creación dicen qué producto queremos hacer. Los de decisión, cómo decidimos como equipo. Los de diseño, cómo se comporta cada pantalla.
Un principio solo sirve si decide algo. Por eso cada regla de componente sale de un principio escrito:
| Principio | Lo que dice | Regla en el componente | Dónde se ve |
|---|---|---|---|
| Diseña experiencias de uso sencillas y escalables | «Facilita la misión de tu usuario. Limita sus distracciones.» | Una acción principal por vista | Botón, modal |
| Diseña experiencias de uso sencillas y escalables | «Haz que las acciones sean reversibles.» | Lo destructivo se confirma | Botón destructivo, modal de confirmación |
| Diseña experiencias de uso sencillas y escalables | «El usuario necesita saber qué está ocurriendo en todo momento.» | La carga conserva la forma | Skeleton, tabla |
| Diseños que deleitan y facilitan | «Ten presente a todos. La accesibilidad debe ser intrínseca.» | Nunca solo color | Estados, pills |
| Decide con consistencia y sin limitación técnica | «Addition by subtraction: less but better.» | 3 tipos de botón, no 10 | Botón |
| Diseños con datos y sentido común | «El producto mejor diseñado es el que menos adaptaciones necesita.» | El cliente cambia los fundamentos, no los componentes | Temas por cliente |
Cuando alguien pide una excepción, se discute contra un principio escrito, no contra el gusto de quien diseña.
Objetivo 3 · Autoexplicativo
Ingeniería necesitaba componentes; la documentación no era su prioridad. Yo defendí lo contrario: el valor del sistema está en las decisiones que toma por ti. Los componentes principales tienen su página de uso y anatomía en Figma, con la regla visible arriba: cuándo se usa, cuándo no y por qué.
El sistema responde las dudas sin que haga falta preguntar a diseño.
Objetivo 4 · Escalable
Hoy Ethos tiene 44 componentes principales, 210 componentes publicados y 1.643 variantes. Casi todos los clientes de Bdeo tienen su marca aplicada sobre esa base, y el tema de cada uno lo crea y lo mantiene soporte, en código, sin pasar por diseño ni desarrollo.
Lo que antes era un producto por cliente es hoy un tema por cliente.
Objetivo 5 · Legible para una IA
Ethos no nació pensando en la IA. Las páginas de uso las escribí antes, para personas. Resultó que es justo lo que una IA necesita: nombres claros, reglas cortas y ejemplos.
Hoy los tokens llegan a Claude Code y Cursor a través del MCP de Figma, y desarrollo construye en Cursor con los componentes de Storybook. Los últimos prototipos que hemos probado con usuarios no han pasado por Figma: los construimos con IA directamente sobre Ethos, así que lo que probamos ya está hecho con las piezas reales. El siguiente paso es que los PM también puedan hacerlo.
Para escribir este caso audité el propio sistema con IA a través del MCP. Así encontré parte de la deuda que cuento más abajo.
Cómo nos alineamos
Cómo nos alineamos
Ethos no se decidió solo en diseño. Cada área tenía algo en juego:
| Área | Qué le preocupaba | Cómo lo resolvimos |
|---|---|---|
| CTO | Justificar el coste de construir un sistema propio | Beneficios de escala y consistencia. Fue quien lo patrocinó. |
| Ingeniería | Tener componentes rápido, y el coste de los complejos como la tabla | Componentes primero en lo común; prioridades con el tech lead |
| Clientes | Perder su identidad de marca | Su marca en todos los fundamentos; nuestro producto en los componentes |
| Soporte | Depender de diseño y desarrollo para cada cliente nuevo | Temas en código que soporte aplica solo |
Concesiones, deuda y qué haría distinto
Un sistema real tiene deuda. Esta es la de Ethos, y lo que aprendí de cada una:
- La tabla: una batalla que perdí a medias. Es el componente más complejo de Bdeo, donde se trabaja cada siniestro. Yo quería convertirla en componente; ingeniería prefería no tocarla, porque cualquier cambio es caro. Acordamos hacer componente una parte, y después una funcionalidad con prisa la extendió fuera del sistema. Hoy la pelearía al principio: cada mes que pasa, la variante de fuera cuesta más de recuperar.
- El botón son 3 tipos y 4 estados para quien lo usa, pero 480 variantes en Figma. Crecieron al combinar tamaños, iconos y estados. Simplificar cómo está construido es lo siguiente.
- El contraste de los temas de cliente se recomienda, pero no se impone. El color es de cada aseguradora. Hoy impondría un mínimo AA desde el principio.
- Smart Video sigue en parte con su legacy. Se migra por partes, cuando hay una razón de producto, no de golpe.
- No medí desde el primer día. El impacto se apoya en estimaciones. Con una línea base de tiempo de desarrollo y variantes por componente, sería una cifra.
- Las personalizaciones que tocan la arquitectura de la plataforma se quedan fuera del sistema, a propósito. Lo dicen los propios principios: «Las personalizaciones son necesarias, pero hay que dejarlas solo para casos cualificados y bien justificados».
Mi papel en producto
Propuse Ethos y diseñé su arquitectura: fundamentos, componentes, principios y documentación de uso. Una compañera de soporte me ayudó al principio con el color; la paleta ya estaba casi definida. El equipo de ingeniería lo implementó entero, y el CTO lo patrocinó.
Hoy lo mantenemos entre desarrollo y yo. Los cambios los propone diseño y los priorizamos con el tech lead. Soporte crea y mantiene los temas de cada cliente.
Cierre
Ethos es el conjunto de rasgos y hábitos que definen la identidad de un grupo. Eso quería que fuera el sistema: lo que todos los productos de Bdeo comparten, sea cual sea el cliente.
Un sistema de diseño no son sus componentes: son las decisiones que ya no hay que volver a tomar.
In English
Ethos, a multi-client design system · Bdeo
210 components · almost every client on the same base
Overview
Bdeo · Design System
Ethos, Bdeo’s design system. Clients change the foundations, not the components.
Every insurer wanted to see its own brand in the product. For years, that meant a different product for each one. Ethos separates what changes per client, the foundations, from what never changes: the components and the rules that govern them.
In 30 seconds
In 30 seconds
- Problem
- There was no design system. The claims admin alone had 10 buttons in 7 styles and no rules, and every demanding client had its own version of the product.
- My role
- I proposed it and designed its architecture: foundations, components, principles and documentation. Engineering built it and the CTO sponsored it.
- Result
- Today almost every client has its brand applied on the same base of 210 components, and support applies it without going through design or engineering. The tech lead estimates development is about 40% faster.
- Role
- Senior Product Designer · system design and direction
- Duration
- Ongoing. It started with the claims dashboard redesign.
- Team
- Design (me), front-end engineering and support.
- Context
- Multi-tenant B2B platform for insurers in more than 30 countries. Every client applies its brand on the same base.
Impact
- 210 Components on the same base — 44 core components, 1,643 variants and 134 icons.
- Almost all Clients, with their brand on Ethos — Support applies each theme in code, without going through design or engineering.
- ~40% Faster development — The tech lead’s estimate. There’s no baseline measurement.
Every screen used to start from scratch. With Ethos we put a new feature together from pieces that are already tested, and it shows in our timelines.
The challenge
When I joined, there was no design system. There were per-project Figma files, some inherited from agencies, with no connection between them, and coded components nobody could reuse.
And every client asked for its own customization. If the client was demanding enough, it got one. So the product kept splintering: the same screen looked different depending on who opened it.
The button sums it up. The claims admin alone had 10 buttons in 7 different styles, and no rule for choosing between them. In Ethos there are 3 types (primary, secondary and destructive) and 4 states (default, hover, pressed and disabled). One system.
The cost never showed up on an invoice. It showed up as visual bugs, engineering rework and decisions made all over again on every screen.
Examples have been altered to protect client data.
Goals
Every problem from before became a goal for the system:
| Before Ethos | Goal |
|---|---|
| Every demanding client had its own version of the product | 1 · Multi-tenant: clients change the foundations, not the components |
| 10 buttons, 7 styles and no rules | 2 · Consistent: every component has its rule, and every rule has its principle |
| Nobody knew what to use or why | 3 · Self-explanatory: the system answers questions without asking design |
| Customizations that existed for a single client and nobody knew how to maintain | 4 · Scalable: support can apply a theme without design or engineering |
| Components with names only their author understood | 5 · Readable by AI: names and rules that both a new hire and an AI can understand |
Results
Goal 1 · Multi-tenant
The decision that defines Ethos is where you draw the line between the brand and the product. I drew it at the foundations.
What changes per client: color, typography, radii and the rest of the foundations. Each insurer has its own theme in code.
What never changes: the 210 components, their structure, their states and their rules. A claims table works the same for everyone; it just dresses differently.
Getting here meant settling something else first. Engineering proposed starting from a template or an existing design system: the fast route. I made the opposite case to the CTO. Bdeo was going to expand into new verticals, almost every client would need its own theme, and bending someone else’s system to that would force an architecture it was never built for. The CTO backed it, and Ethos became our own, multi-theme from the very first component.
The base foundations, each with its own scale:
- Typography. I didn’t choose it: I inherited it. Telegraf and Space Mono were already in Bdeo’s brand book, and there was no point reopening that debate. My job wasn’t to pick a typeface; it was to turn it into a system: 8 sizes, from 12/16 to 48/68, and 18 styles, each with a defined use, from headlines to technical data. Since every insurer brings its own, the font family changes per client. The scale, the hierarchy and the rhythm stay.
- Spacing: 11 steps, from 0 to 192 px. Few of them, with clear jumps, so nobody has to choose between 14 and 15.
- Radii and borders: 4 radii (0, 4, 8 and round), 2 weights and 3 border styles. Fewer options, fewer debates.
- Elevation: 5 levels, from no shadow to the highest one. A shadow tells you what sits on top of what; it isn’t decoration.
- Color: 169 variables in layers. Primitives hold the values; semantic tokens say what each one is for (background, text, state, brand). A component never uses a raw color, always its meaning. That’s why, when you switch clients, the primary button, the states and the brand gradient change all at once, without touching a single component.
Goal 2 · Consistent
Before the components, I wrote the principles: eight, in three groups. The creation principles say what product we want to build. The decision principles, how we decide as a team. The design principles, how each screen behaves.
A principle is only useful if it decides something. That’s why every component rule comes from a written principle:
| Principle | What it says | Component rule | Where you see it |
|---|---|---|---|
| Design simple, scalable experiences | “Make your user’s mission easier. Limit their distractions.” | One primary action per view | Button, modal |
| Design simple, scalable experiences | “Make actions reversible.” | Destructive actions are confirmed | Destructive button, confirmation modal |
| Design simple, scalable experiences | “Users need to know what’s happening at all times.” | Loading keeps the shape | Skeleton, table |
| Designs that delight and make things easier | “Keep everyone in mind. Accessibility must be built in.” | Never color alone | States, pills |
| Decide consistently, without technical limits | “Addition by subtraction: less but better.” | 3 button types, not 10 | Button |
| Designs grounded in data and common sense | “The best-designed product is the one that needs the fewest adaptations.” | Clients change the foundations, not the components | Client themes |
When someone asks for an exception, the argument is with a written principle, not with the designer’s taste.
Goal 3 · Self-explanatory
Engineering needed components; documentation wasn’t their priority. I argued the opposite: a system’s value lies in the decisions it makes for you. The core components each have a usage and anatomy page in Figma, with the rule right at the top: when to use it, when not to, and why.
The system answers questions without anyone having to ask design.
Goal 4 · Scalable
Today Ethos has 44 core components, 210 published components and 1,643 variants. Almost every Bdeo client has its brand applied on that base, and each client’s theme is created and maintained by support, in code, without going through design or engineering.
What used to be one product per client is now one theme per client.
Goal 5 · Readable by AI
Ethos wasn’t built with AI in mind. I wrote the usage pages first, for people. It turned out they’re exactly what an AI needs: clear names, short rules and examples.
Today the tokens reach Claude Code and Cursor through the Figma MCP, and engineering builds in Cursor with the Storybook components. The latest prototypes we tested with users never went through Figma: we built them with AI directly on top of Ethos, so what we tested was already made from the real pieces. The next step is for PMs to be able to do the same.
To write this case study, I audited the system itself with AI through the MCP. That’s how I found some of the debt I describe below.
How we aligned
How we aligned
Ethos wasn’t decided by design alone. Every team had something at stake:
| Team | What worried them | How we solved it |
|---|---|---|
| CTO | Justifying the cost of building our own system | The benefits of scale and consistency. The CTO became its sponsor. |
| Engineering | Getting components fast, and the cost of complex ones like the table | Components for the common parts first; priorities set with the tech lead |
| Clients | Losing their brand identity | Their brand across all the foundations; our product in the components |
| Support | Depending on design and engineering for every new client | Themes in code that support applies on its own |
Trade-offs, debt and what I’d do differently
Every real system has debt. This is Ethos’s, and what I learned from each piece of it:
- The table: a battle I half lost. It’s Bdeo’s most complex component, where every claim gets worked. I wanted to turn it into a component; engineering preferred not to touch it, because any change is expensive. We agreed to componentize part of it, and later a rushed feature extended it outside the system. Today I’d fight that battle at the start: every month that goes by, the off-system variant gets more expensive to bring back.
- The button is 3 types and 4 states for whoever uses it, but 480 variants in Figma. They piled up as sizes, icons and states were combined. Simplifying how it’s built is next.
- Contrast in client themes is recommended, not enforced. Color belongs to each insurer. Today I’d enforce an AA minimum from the start.
- Smart Video still partly runs on its legacy. It’s being migrated piece by piece, when there’s a product reason, not all at once.
- I didn’t measure from day one. The impact rests on estimates. With a baseline for development time and variants per component, it would be a hard number.
- Customizations that touch the platform’s architecture stay outside the system, on purpose. The principles say so themselves: “Customizations are necessary, but they should be reserved for qualified, well-justified cases.”
My product role
I proposed Ethos and designed its architecture: foundations, components, principles and usage documentation. A colleague from support helped me with color at the start; the palette was already mostly defined. The engineering team built all of it, and the CTO sponsored it.
Today engineering and I maintain it together. Design proposes the changes and we prioritize them with the tech lead. Support creates and maintains each client’s themes.
Closing
Ethos is the set of traits and habits that define a group’s identity. That’s what I wanted the system to be: what every Bdeo product shares, whoever the client is.
A design system isn’t its components: it’s the decisions you never have to make again.