Reduje un 90% las incidencias de componentes y estilos inconsistentes con un design system white-label

La decisión de partir de cero — Cuando el producto pivotó hacia un SaaS white label para plataformas financieras, propuse aprovechar el cambio para construir todo desde cero en vez de arrastrar las inconsistencias anteriores. Partimos de Untitled UI en Figma, construimos componentes en React y los documentamos en Storybook. Font Awesome dio a diseño y desarrollo un lenguaje de íconos compartido.

Construido junto al producto, no antes — Sin un equipo dedicado y con un MVP que entregar, no intenté anticipar todos los componentes. Empecé por las fundaciones y los componentes de mayor impacto, y dejé que el sistema creciera con cada flujo. El branding fue parte de la arquitectura desde el primer día: tokens en cuatro capas (Brand, Primitive, Semantic, Component), de modo que los componentes nunca referenciaban directamente los colores de un cliente. La primera feature que construimos en la plataforma fue Platform Design, donde cada institución elige sus colores y sube su logo. El sistema también definió una sola vez cómo se comporta, se lee y se navega la plataforma — errores, estados vacíos, confirmaciones, tablas, jerarquía y navegación — y no solo cómo se ven los componentes. Fui dueña del sistema y de sus decisiones core, y cada componente nuevo pasaba por las mismas preguntas junto al equipo de diseño: ¿un componente existente puede resolverlo? ¿es un problema de componente o de flujo? ¿servirá más allá de esta feature?

Trabajo con ingeniería — Viajé un mes a China para trabajar con el equipo de desarrollo en el inicio del MVP: las primeras features, el design system y el comportamiento de la plataforma. En vez de entregar archivos de Figma, resolvimos juntos comportamientos, estados faltantes y decisiones de componentes.

Cómo se midió el 90% — Etiquetamos en Jira como “Design System” las incidencias de componentes y estilos. Comparamos el total mensual de esas incidencias antes y después de implementar el design system, y el número total bajó un 90%.

Aprendizajes — La lección más grande no fue sobre tokens ni componentes, sino darme cuenta de que muchos problemas aparentes de UI no eran problemas de componente: a veces la solución correcta era un componente nuevo, otras veces era un componente existente usado de otra forma, un patrón más claro, mejor UX writing, o un cambio al flujo mismo. La governance resultó tan importante como la librería. Construir el sistema junto al producto también me enseñó a no optimizar por completitud — intentar anticipar cada caso de uso posible habría creado complejidad antes de saber si la necesitábamos. Y trabajar directamente con ingeniería reforzó algo que definió todo el proyecto: un design system solo genera valor cuando diseño y desarrollo lo tratan como infraestructura compartida.