Sistemas de diseño, sin el marketing
El término "sistema de diseño" se ha desgastado tras dos años de publicaciones en LinkedIn. Así que reiniciemos la definición.
Un sistema de diseño es la fuente única de verdad, ejecutable y versionada, de cómo se ve y se comporta tu producto. "Ejecutable" porque los diseñadores trabajan a partir de los mismos componentes que los ingenieros publican. "Versionada" porque el sistema evoluciona con el tiempo y las versiones antiguas deben seguir funcionando. "Fuente única de verdad" porque si todavía queda ambigüedad, el sistema no está cumpliendo su función.
Un archivo de Figma con algunos botones no es un sistema de diseño. Un Storybook con 40 componentes y sin tokens de diseño tampoco lo es. El sistema es el puente entre ambos.
Qué cambia cuando tienes uno
Tres cosas, de forma medible:
Velocidad en el desarrollo de nuevas funciones. En proyectos donde introducimos un sistema de diseño real a mitad del camino, la entrega de funciones se acelera entre un 30% y un 50% en dos sprints. Los diseñadores dejan de reinventar patrones de formularios. Los ingenieros dejan de reimplementar botones. Los PR se reducen.
Consistencia entre superficies. Las empresas con múltiples productos son el caso obvio, pero incluso los equipos de un solo producto se benefician. El sitio de marketing, la app, el panel de administración, las plantillas de correo: si comparten tokens, parecen provenir de la misma empresa. Sin tokens compartidos, siempre terminan divergiendo.
Costo de incorporación. Un nuevo diseñador o ingeniero puede lanzar su primer PR en su primera semana en lugar de su primer mes. El sistema responde la mayoría de las preguntas de "cómo hacemos X" antes de que alguien las haga.
Qué contiene
Un sistema de diseño funcional tiene aproximadamente cuatro capas. Si te saltas alguna, el sistema se vuelve frágil.
1. Tokens. Colores, tipografía, espaciado, radios, sombras, duraciones de movimiento, curvas de easing. Son JSON, no imágenes. Alimentan tanto Figma (mediante herramientas como Tokens Studio) como el código (mediante Style Dictionary o similar). La capa de tokens es la más importante y la que más se omite.
2. Primitivos. Botones, campos de entrada, selectores, checkboxes, radios, toggles, badges, tooltips, modales. Los elementos atómicos de la interfaz que aparecen en cada pantalla. Deben implementarse una sola vez, con la accesibilidad adecuada (anillos de foco, ARIA, soporte de teclado), y documentarse con tablas de props.
3. Patrones. Formularios, navegación, estados vacíos, estados de carga, estados de error, tablas de datos. Son composiciones de primitivos. Codifican decisiones: "así es como manejamos un formulario de varios pasos", no "aquí tienes una librería de formularios".
4. Lineamientos. Voz y tono, estándares de accesibilidad, reglas de contenido ("usamos mayúscula inicial en los botones"), principios de animación. Las partes que no son componentes pero que mantienen el trabajo coherente.
Un fallo común: lanzar el sistema y luego abandonarlo
La mitad de los sistemas de diseño que vemos en los repositorios de clientes se construyeron hace dos años, se usaron durante seis meses y luego fueron eludidos en silencio. Los síntomas: un Storybook que nadie actualiza, componentes en el código que duplican a los del sistema de diseño, valores hexadecimales de color escritos a mano en 30 lugares distintos.
Esto suele ocurrir cuando el sistema se trata como un entregable único en lugar de un producto vivo. La solución es estructural:
- Asigna un responsable. Aunque sea a tiempo parcial. Sin un responsable, nadie decide cuándo un nuevo componente pasa a formar parte del sistema.
- Haz que usar el sistema sea más fácil que eludirlo. Si agregar un nuevo componente al sistema toma más tiempo que copiar y pegar uno, ya perdiste.
- Realiza una auditoría trimestral. Revisa cada pantalla, cuenta las desviaciones y corrígelas. Nosotros usamos una métrica simple: "porcentaje de pantallas que usan solo componentes del sistema". Cualquier valor por debajo del 80% es un problema.
Empezar en pequeño (y no detenerse)
No necesitas una librería de 200 componentes para llamarlo sistema de diseño. Una v1 funcional cabe en una sola librería de Figma y un solo paquete npm, y contiene aproximadamente:
- 8 tokens de color
- 4 escalas tipográficas
- Una escala de espaciado (4 / 8 / 12 / 16 / 24 / 32 / 48)
- 6 componentes: botón, campo de entrada, selector, modal, tarjeta, tabla
- 3 patrones: diseño de formulario, encabezado de página, estado vacío
Eso ya es un sistema de diseño real. Lánzalo el viernes, úsalo el lunes y hazlo crecer durante el próximo año.
Cuándo no necesitas uno
Un equipo de dos personas construyendo un solo producto durante seis meses lanzará más rápido sin la sobrecarga de un sistema formal. El punto de equilibrio ronda: tres o más diseñadores/ingenieros, múltiples superficies, o un producto que se espera que dure más de 18 meses. Por debajo de eso, simplemente anota las convenciones y sigue adelante.
Por encima de eso, la pregunta ya no es "¿deberíamos construir un sistema de diseño?", sino "¿cuánto ya hemos pagado por no tener uno?". Si quieres una segunda opinión sobre en qué punto está el sistema de tu equipo, nuestro equipo de diseño UI/UX realiza una auditoría ligera como punto de partida.
