Mejores herramientas de design system para equipos pequeños
Tu producto se ve inconsistente. Los botones no coinciden entre pantallas, el espaciado cambia de página a página, y cada funcionalidad nueva parece venir de otra app. Entonces buscas una herramienta de design system y caes en una lista de quince, sin manera de saber cuál resuelve tu caso.
Resumen
Si tu equipo tiene menos de cinco personas, casi seguro no tienes un problema de herramienta. Tienes un problema de origen: las pantallas se están haciendo por caminos distintos. En ese caso, la herramienta correcta es la que no vas a tener que mantener.
Las seis de abajo resuelven cosas distintas, y la mayor parte de la frustración con los design systems viene de elegir una que resuelve un problema que no tienes.
Qué tiene que hacer una herramienta de design system
Un design system tiene cuatro partes, y casi ninguna herramienta cubre las cuatro:
- los tokens, que son las decisiones: color, escala tipográfica, espaciado, radio de esquina;
- los componentes, que son esos tokens aplicados a una pieza reutilizable;
- la documentación, que dice cuándo usar cada pieza y, sobre todo, cuándo no usarla;
- la sincronía, que mantiene diseño y código diciendo lo mismo después de la tercera semana.
La cuarta es donde mueren los design systems. Las tres primeras se hacen en un sprint. La cuarta es para siempre.
Las categorías, y para quién es cada una
Taller de componentes
Storybook. Desarrollas el componente aislado de la app, ves todos sus estados uno al lado del otro, y la documentación queda junto al componente en ejecución. Es la única categoría donde la documentación no envejece sola, porque es el propio código.
Para quién: equipo con desarrollador front-end dedicado. Si nadie del equipo escribe React o equivalente, esto no es para ti.
Herramienta de diseño
Figma. Es donde nace el design system en la mayoría de los equipos: los componentes, las variantes, las variables de color y espaciado. No es una herramienta de design system, es una herramienta de diseño que ganó funciones suficientes para convertirse en una.
Para quién: todo el que tenga diseñador. La pregunta nunca es si usas Figma, es qué usas además de él.
Sitio de documentación
zeroheight y Supernova. Toman lo que está en Figma y en el código y lo publican como un sitio de documentación navegable, con gobernanza, versión y aprobación.
Para quién: organización con más de un equipo de producto, donde quienes consumen el design system no conocen a quien lo escribió. Por debajo de ese tamaño, es infraestructura para un problema que todavía no existe.
Entrega de diseño a código
Zeplin. Organiza la entrega del diseño al desarrollo: especificación, medidas, recursos, qué cambió desde la última versión.
Para quién: equipos donde diseño y desarrollo son personas distintas con rituales distintos. Si el mismo par hace las dos cosas, esta capa solo añade un paso.
Constructor de sitios con sistema incorporado
Framer. Montas el sitio con componentes y estilos compartidos, y el resultado publicado ya es el sitio. La consistencia sale por construcción, porque no existe una segunda implementación que diverja de la primera. Quédate con ese mecanismo: es lo más interesante de toda esta página, y vuelve al final aplicado a otro tipo de producto.
Para quién: sitio de marketing, portafolio, landing page. No sirve para una aplicación con datos e inicio de sesión, y ahí es justamente donde el mecanismo se queda sin dueño.
Comparación
| Herramienta | Qué resuelve | Mejor para |
|---|---|---|
| Storybook | desarrollar y documentar componentes aislados | equipo con front-end dedicado |
| Figma | crear los componentes y los tokens | cualquier equipo con diseñador |
| zeroheight | publicar la documentación para mucha gente | organización con varios equipos |
| Supernova | documentación más automatización de tokens a código | organización con gobernanza de diseño |
| Zeplin | entrega ordenada de diseño a código | equipos con diseño y desarrollo separados |
| Framer | sitio publicado con consistencia incorporada | sitios institucionales y landing pages |
Coste total: la licencia es la parte barata
Las seis tienen plan gratuito o barato para equipo pequeño, y por eso la decisión parece fácil mientras la tomas. Los precios cambian a menudo y están en los enlaces del final de esta página.
El coste que nadie pone en la hoja de cálculo es el otro:
Alguien tiene que mantenerlo. Un design system sin dueño se pudre en un trimestre. Alguien revisa los componentes, resuelve las excepciones, actualiza la documentación, discute con el equipo que acaba de crear el décimo botón. Eso es una fracción real de una persona, cada semana.
Dos verdades divergen. El componente en Figma y el componente en código son dos implementaciones de una misma idea, y divergen. Siempre. Una herramienta de sincronía ayuda y no lo resuelve, porque lo que diverge no es el valor del color, es una decisión sobre un estado que solo existe en el código.
La adopción no es automática. Un design system que existe y no se usa es peor que ninguno, porque ahora tienes dos maneras de hacer lo mismo y un documento diciendo que solo una vale.
Para un equipo de dos o tres personas, ese coste es comparable al de construir las pantallas. Es la razón de que tanta gente monte un design system, lo use dos meses y lo abandone.
Cuándo necesitas design system y cuándo solo consistencia
Esta es la distinción que la mayoría de las listas se salta, y es la que decide si gastas bien o mal.
Necesitas un design system de verdad cuando varias personas construyen interfaz en paralelo, en bases de código o productos distintos, y necesitan un contrato compartido. El design system es ese contrato. Sin él, cada equipo inventa el suyo.
Solo necesitas consistencia cuando el problema es que tus pantallas no se parecen entre sí. Ahí la causa no es la falta de contrato, es el exceso de orígenes: cada pantalla se hizo en un momento, de una manera, por una decisión tomada sobre la marcha.
Y la consistencia tiene una solución más barata que un contrato: un origen único.
Consistencia por construcción, sin el mantenimiento
Aquí entramos nosotros, y conviene decir de entrada que somos parte interesada. El argumento se puede comprobar, así que júzgalo por eso.
Es el mismo mecanismo de Framer, aplicado al tipo de producto que él no atiende. Cuando toda la app se genera a partir de una misma biblioteca, la deriva visual no llega a empezar. No porque alguien la vigile, sino porque no existe una segunda forma de hacer un botón.
En Fabapp, la app generada consume 57 componentes listos, desde una tabla con paginación hasta un selector de fecha, campo de teléfono con máscara por país, subida de imagen, gráfico y diálogo de confirmación. Son la misma pieza en todas las pantallas de la app, con los mismos tokens de tema. La lista completa de lo que entrega la plataforma está en funciones.
Dos consecuencias que importan a quien ya ha sufrido un design system:
El sistema rechaza lo que se sale de la biblioteca. Antes de que la app compile, una verificación estática rechaza un componente que no existe y una propiedad inventada. Un design system en documento depende de que alguien lo lea; este depende de que el código pase.
El tema es una sola decisión. Color, tipografía y radio salen de un conjunto de tokens aplicado a toda la app. Cambiar el color primario es un cambio, no un barrido.
Y para quien se preocupa por la salida: los componentes viven en el código de tu app, editables, y el código sale en ZIP o push a GitHub desde el plan Builder. No estás cambiando mantenimiento de design system por dependencia de plataforma.
Dónde esto no sirve. Si tu problema es coordinar cuatro equipos de producto en bases de código que ya existen, nada de esto te ayuda: necesitas el contrato compartido, y la lista de arriba es donde buscar. El origen único arregla la deriva, no arregla la gobernanza.
Cambiar de herramienta, y qué sobrevive
Si ya tienes algo montado, dos notas antes de migrar.
Los tokens migran, los componentes no. Color, espaciado y tipografía son datos y viajan bien entre herramientas. Los componentes cargan decisiones de implementación y se reescriben, no se mueven. Planifica por esa segunda parte.
La documentación es lo que se pierde. El texto que explica por qué existe el botón terciario no está en ningún formato que se exporte. Si importa, cópialo antes de cancelar la suscripción.
Construye la interfaz consistente que tu producto necesita
Si lo que te trajo aquí es un producto que parece hecho por cinco personas distintas, vale la pena probar el camino barato antes que el completo: describe la app que quieres y mira cuánta consistencia sale gratis cuando todas las pantallas tienen el mismo origen.
En Fabapp, el plan Free no pide tarjeta.