Sistemas de diseño que escalan: lo que me enseñaron más de 300 componentes

Cuando rediseñé la mayor parte de la plataforma de 23degrees, el trabajo dejó más de 120 pantallas y más de 300 componentes en Figma. Después, para GTAI, construimos un sistema modular de más de 50 componentes preparado para crecer con datos nuevos. Esto es lo que esos proyectos me enseñaron sobre sistemas que escalan de verdad.

1. Empieza por pantallas reales

Las librerías diseñadas en el vacío rara vez sobreviven al contacto con el producto. Revisa las pantallas que ya tienes, encuentra los patrones que se repiten y las incoherencias que duelen, y construye desde ahí. En 23degrees, uno de los objetivos era unir en un solo flujo servicios que antes iban por separado: el sistema tenía que reflejar recorridos reales.

2. Fundamentos antes que componentes

Color, tipografía, espaciado, retícula, elevación y estados son la gramática. Si los defines bien como tokens, la mayoría de componentes casi se diseñan solos. Cientos de variantes no arreglan unos fundamentos débiles.

3. Diseña todos los estados

Un componente no está terminado hasta que tiene sus estados: hover, foco, desactivado, cargando, vacío, error, texto largo. Los productos de datos y de IA añaden más: sin datos, datos parciales, poca confianza. Diseñar los estados de antemano evita sorpresas en desarrollo.

4. Nombra las cosas para quien las usa

Los nombres son la API de tu sistema. Usa nombres que diseño, desarrollo y producto entiendan igual, y documenta cuándo usar un componente, no solo cómo se ve.

5. Que escale con el contenido

El contenido real es más largo, más desordenado y más multilingüe que las maquetas. Prueba los componentes con etiquetas largas, palabras compuestas en alemán (el idioma de GTAI) y textos en español antes de darlos por terminados.

6. El traspaso forma parte del sistema

Las especificaciones, los prototipos y las convenciones de nombres son lo que hace que desarrollo pueda usar el sistema. Un sistema que solo vive en Figma todavía no es un sistema.

7. Mantenlo vivo

Asigna responsables, versiona los cambios y recoge peticiones. Un sistema de diseño es un producto para tu equipo y necesita una hoja de ruta como cualquier otro.

¿Merece la pena?

Si tu equipo redibuja una y otra vez el mismo botón, discute el mismo espaciado o publica pantallas incoherentes, sí. Un buen sistema libera al equipo de las conjeturas de diseño para que se centre en crecer. Veamos el tuyo.

Preguntas frecuentes

¿Cuándo necesita un producto un sistema de diseño?

Cuando varias personas diseñan o construyen pantallas, cuando el producto no para de crecer o cuando la incoherencia empieza a frenar al equipo. Los productos pequeños ganan con unos fundamentos incluso antes de tener una librería completa.

¿Cuántos componentes debe tener un sistema de diseño?

Los que necesite el producto y ni uno más. Importan más unos fundamentos sólidos y unos estados bien definidos que el número de componentes.

¿Qué diferencia hay entre un UI kit y un sistema de diseño?

Un UI kit es un conjunto de componentes. Un sistema de diseño añade fundamentos, reglas, documentación, nombres y gobierno para que los equipos construyan productos coherentes a escala.