El Proyecto
Design System as Infrastructure.
En el cuidado de la diabetes, la interfaz no es decoración. Es cómo un profesional sanitario lee los datos, toma una decisión y ve cuánto tiempo le queda de consulta con el paciente (unos cinco minutos). Cuando esa interfaz es inconsistente, está fragmentada o cuesta predecirla, ralentiza la lectura, enturbia la decisión y roba un tiempo que el paciente quizá no tenga.
EL PROYECTO DE UN VISTAZO
Rol
Design System Lead · Diseñadora de producto senior
Dominio
Salud · Diabetes
Alcance
Foundations · Componentes · Tokens · Gobernanza · Adopción
Herramientas
Figma · Zeroheight · Storybook · Design tokens
Foco
Madurez de diseño · Escalabilidad · Consistencia entre plataformas
Contexto
Un ecosistema healthcare en transformación digital.
Las herramientas soportaban a profesionales sanitarios trabajando con datos de diabetes, un entorno donde la claridad y la consistencia tenían impacto directo en la confianza del producto, la usabilidad y los flujos de trabajo clínicos.
El diseño necesitaba pasar de una función de ejecución visual a una práctica capaz de estructurar decisiones de producto.
MI ROL
Durante los primeros 18 meses fui la única diseñadora del equipo.
Un desarrollador a mi izquierda a través de una pantalla, otro a mi derecha a través de otra pantalla, y todo un conjunto de productos esperando a que el sistema funcionara. No había manual para eso. Tenía que construir la base, defender cada decisión importante ante stakeholders que no siempre veían el sentido, y mantener a los equipos de producto en marcha, todo a la vez.
Mi trabajo era crear las condiciones para que las buenas decisiones de diseño se repitieran solas, sin depender de que yo estuviera en cada conversación. Eso significaba foundations, tokens, arquitectura de componentes, documentación, gobernanza, la migración de Sketch a Figma, y un plan de adopción que hiciera que los equipos quisieran usar el sistema.
El equipo creció con el tiempo, de una diseñadora y dos desarrolladores a tres diseñadoras y cuatro desarrolladores, con iOS y Android más adelante. Pero en el periodo de construcción más duro, toda la capa de diseño descansaba en una sola persona. Eso me enseñó algo que ningún libro enseña: un sistema se sostiene tanto en la confianza que construyes alrededor como en su arquitectura, y en tener managers que te respaldan cuando las decisiones son difíciles.
CUATRO DECISIONES QUE DIERON FORMA AL SISTEMA
Hubo muchas decisiones a lo largo del proyecto. Estas cuatro marcaron la dirección de todo lo demás.
Empecé por las foundations, no por los componentes.
La opción fácil era obvia: sacar rápido una librería de componentes para mostrar avance y generar confianza. La descarté. En un entorno fragmentado, empezar por los componentes habría copiado el desorden que ya teníamos en lugar de arreglarlo. Necesitábamos un lenguaje común primero: color, tipografía, espaciado, retícula, tokens, accesibilidad. Sin esa base, los componentes son objetos bonitos sin gramática. Con ella, cada componente pertenece a algo más grande.
Traté la retícula responsive como una decisión de infraestructura.
Algunos stakeholders no veían la necesidad; los productos corrían sobre todo en escritorio, así que ¿para qué invertir en responsive? Cambié la pregunta. Olvidemos el móvil un momento: ¿queríamos seguir resolviendo layouts pantalla por pantalla durante los próximos cinco años, o construir una base capaz de adaptarse? Una vez en marcha, la retícula recortó tiempo y esfuerzo en cada nueva feature en más de un 60% entre diseño, desarrollo y testing. También abrió la puerta al soporte LTR/RTL para alfabetos latino, cirílico, árabe y asiáticos, a criterios reales de accesibilidad, y a una oportunidad de negocio clara: entrar en nuevos mercados. Lo que parecía una decisión técnica era, por debajo, cultural y estratégica.
Centralicé la gobernanza primero, luego la federé.
Al principio necesitábamos una dirección clara. Centralizar protegía la coherencia mientras el sistema se asentaba, y construía la confianza que los equipos necesitan antes de adoptar algo nuevo. Pero un modelo centralizado de forma permanente convierte al equipo de DS en un cuello de botella. A medida que el sistema maduró, pasamos a un modelo federado: los equipos podían proponer, probar y contribuir, mientras el equipo de DS mantenía el listón de calidad. El flujo Candidate fue el puente entre esos dos mundos: un camino claro desde una necesidad real de producto hasta una release oficial, sin retrabajo ni frustración.
Convertí la resistencia al móvil en una adopción planificada.
Llevar el sistema al móvil fue la decisión más difícil. Los equipos de las apps tenían sus propios lenguajes de diseño, años de trabajo invertido y un miedo del todo legítimo a perder algo que sentían suyo. Imponerlo habría sido un error. Ignorarlo, también. La estrategia fue otra: meses de conversaciones, workshops, sesiones sobre beneficios y riesgos, y un horizonte de ocho meses para que los equipos planificaran el cambio a su ritmo. Reforzamos el equipo con iOS, Android y una tercera diseñadora. La victoria que más importó fue un cambio en cómo lo veían los equipos, de "nos van a quitar el producto" a "tendremos una base común para movernos mejor y entregar una experiencia global".
| Decision | Rejected alternative | Trade-off | Why it mattered |
|---|---|---|---|
Foundations first Color · type · spacing · tokens | Build large component library early | Slower start | Components form a shared language, not isolated objects |
Semantic tokens Function over appearance | Visual naming (color-blue-500) | More naming effort | Reduces ambiguity across design and engineering |
Anatomy-based components Structure · states · slots | Appearance-driven design | Longer design phase | Flexibility without variant explosion |
Responsive grid as infrastructure Cultural + technical decision | Layout resolved per screen | Initial complexity | −60% effort in new features. LTR/RTL + A11y foundation |
Migration as refactorization Sketch → Figma | Treat as technical migration only | Higher effort upfront | Cultural inflection point for new habits and standards |
Centralize → federate Governance evolution | Open contribution from the start | Slower adoption early | Governance that outlasts the central team |
Candidate workflow Explore → test → release | Wait for official approval cycle | More process steps | Safer adoption, less rework, faster trust |
Mobile: progressive adoption 8-month horizon | Impose system or delay mobile entirely | Months of alignment work | Resistance converted into planned adoption across iOS and Android |
Cada decisión incluye la alternativa rechazada y el coste aceptado para llegar allí
Gobernanza
Centralizar → federar:
la gobernanza que sobrevive al equipo central.
Centralizar protegió la coherencia mientras el sistema se estabilizaba y generó la confianza necesaria para que los equipos adoptaran algo nuevo.
A medida que el sistema maduró, evolucionamos hacia un modelo federado. Los equipos podían proponer, probar y contribuir.
Candidate Workflow
El puente entre necesidad real de producto y release oficial.
El flujo Candidate permitía que los componentes se probaran en contextos reales de producto antes del release oficial.
Esto redujo significativamente la pérdida de trabajo para diseñadores que habían construido pantallas con componentes que luego cambiaban en el release.
RESULTADOS
El sistema nunca fue teoría.
Cuando se registraron estas cifras, 39 componentes de la librería web estaban en uso activo en 10 módulos de producto, con 3.026 instancias en total. HCP Client, la herramienta clínica principal, sumaba 35 componentes y 1.738 instancias por sí solo. Son cifras solo de la librería web; iOS, Android, iconos e ilustraciones no entran en este conjunto de datos.
Componentes en uso activo
Librería web · 10 módulos de producto
Instancias totales
Solo librería web · sin iOS ni Android
Reducción de esfuerzo
En nuevas funcionalidades tras el responsive grid
Meses de horizonte mobile
Para adopción planificada iOS/Android
"En diabetes care, eso no es un detalle de producto. Es una condición para que el profesional sanitario pueda hacer bien su trabajo."
