La mayoría de los design systems empiezan de la misma forma: alguien nota que existen 7 variaciones diferentes de botón en el producto, abre un proyecto en Figma y empieza a crear componentes. Seis meses después, la biblioteca existe, pero nadie la usa.
El problema no es técnico. Es de mentalidad.
Un design system sin usuarios no es un sistema. Es una biblioteca de componentes que nadie pidió.
¿Quiénes son los usuarios de tu design system?
Esta es la primera pregunta que necesitas responder. En general, los usuarios de un design system son diseñadores y desarrolladores, equipos que necesitan construir producto de forma consistente y rápida.
Como cualquier producto, tienen dolores, necesidades y expectativas. Y como cualquier producto, necesitas descubrir qué necesitan antes de construir.
💡 Antes de crear un único componente, entrevista a 3 diseñadores y 3 devs de tu equipo. Pregunta: ¿cuál es el mayor punto de fricción hoy? ¿Qué te hace perder más tiempo? Te sorprenderás con lo que escuches.
Métricas de un design system
Si no mides, no sabes si está funcionando. Algunas métricas que uso para hacer seguimiento de la salud de un design system:
- Tasa de adopción: ¿Qué % de los componentes de la biblioteca se están usando en los productos?
- Tiempo de implementación: ¿Cuánto tiempo tarda un dev en implementar una nueva pantalla usando el sistema vs. sin él?
- Tickets de inconsistencia: ¿Cuántos bugs de UI se reportan por mes?
- NPS interno: ¿El equipo recomendaría el design system a otros equipos?
Roadmap y gobernanza
Todo producto tiene un roadmap. Tu design system también debería tener uno. Eso significa priorizar qué se construirá, cuándo y por quién, en función de las necesidades de los equipos que lo usan.
La gobernanza también es fundamental: ¿quién puede contribuir? ¿Cómo se aprueban los nuevos componentes? Sin un proceso claro, el sistema se convierte en un caos colaborativo.
IA en el design system
Con IA, es posible generar variaciones de componentes en segundos, documentar automáticamente los casos de uso e identificar inconsistencias en toda la base de código. Esto reduce drásticamente el tiempo de mantenimiento.
Conclusión
El Design System es un producto. Tiene usuarios, métricas, roadmap y necesita ser mantenido como tal. Los equipos que tratan su biblioteca de componentes como un proyecto paralelo cosechan resultados paralelos, no en el producto principal.