Sistema de diseño: lo que nadie te cuenta

Qué es realmente un sistema de diseño

Un sistema de diseño no es una biblioteca de componentes bonitos ni un Figma prolijo. Es un acuerdo vivo entre diseño y desarrollo sobre cómo se construye la interfaz de un producto. Incluye reglas, decisiones documentadas y piezas reutilizables que permiten escalar sin perder coherencia.

La diferencia con una guía de estilos es sustancial: la guía describe; el sistema prescribe y conecta. Un color no es solo un hex, es un token con nombre semántico, uso definido y variante de accesibilidad. Un botón no es una forma visual, es un componente con estados, variantes y comportamiento documentado.

Entender esto desde el arranque evita que el 'sistema' termine siendo un PDF que nadie consulta y una biblioteca de Figma que diverge del código a la semana de lanzada. En Xulum nos pasó que clientes llegaban con guías de estilo extensísimas y al mismo tiempo con interfaces que hacían lo que querían: el problema casi siempre era que nadie había conectado las decisiones de diseño con el código real.

Cuándo conviene implementarlo

La pregunta correcta no es '¿deberíamos tener un sistema de diseño?' sino cuándo el caos que ya tienen cuesta más que el esfuerzo de ordenarlo. La respuesta depende de algunos indicadores concretos.

• Múltiples productos o canales: si el mismo equipo mantiene una app, un sitio y un panel de administración, la inconsistencia crece de forma exponencial sin un sistema compartido.
• Onboarding lento: cuando incorporar a alguien nuevo implica semanas de 'así lo hacemos acá', hay deuda de documentación que un sistema salda.
• Rediseños que no escalan: si cada vez que cambia la tipografía o el color primario hay que tocar decenas de archivos, el costo operativo ya justifica la inversión.
• Equipos distribuidos: cuando diseño y desarrollo no comparten espacio físico ni horario, el sistema reemplaza conversaciones que no suceden.

Si ninguna de estas situaciones aplica, quizás un documento de estilos y convenciones claras sea suficiente por ahora. No toda empresa necesita un sistema completo.

Componentes clave que no podés ignorar

Un sistema mínimo viable tiene que resolver los problemas más frecuentes antes de volverse exhaustivo. Intentar documentar todo desde el día uno es una de las formas más seguras de no terminar nada.

Los componentes que generan más retorno inmediato son los que aparecen en casi todas las pantallas: tipografía base, paleta con roles semánticos, grilla y espaciado, botones con todos sus estados, campos de formulario, mensajes de error y estados vacíos. Con eso cubierto, la mayoría de los flujos se pueden construir sin decisiones improvisadas en cada sprint.

El segundo nivel incluye navegación (menús, breadcrumbs, tabs), tarjetas, modales y notificaciones. Los componentes específicos del dominio del negocio —tablas de datos complejas, selectores especializados, visualizaciones— recién aparecen en el tercer nivel. Ir en ese orden evita sobrediseñar piezas que quizás nunca se usen. Para profundizar en uno de los componentes más críticos de cualquier interfaz, la guía sobre diseño de botones y llamados a la acción cubre los estados, jerarquías y errores más comunes.

Design tokens: el corazón del sistema

• Qué son: variables con nombre semántico que almacenan decisiones de diseño. En lugar de usar #1A73E8 directamente, usás color-action-primary. Ese nombre describe el rol, no el valor.
• Por qué importan: permiten cambiar un valor en un solo lugar y que se propague a toda la interfaz, tanto en Figma como en el código. Son el puente real entre diseño y desarrollo.
• Niveles de tokens: los primitivos definen valores brutos (colores, tamaños, fuentes). Los semánticos asignan roles a esos valores (color de fondo, color de texto de error). Los de componente son específicos de una pieza, como 'button-primary-background'. No todos los proyectos necesitan los tres niveles.
• Herramientas: Style Dictionary de Amazon, Theo de Salesforce o directamente variables de CSS y Figma son puntos de partida válidos. La herramienta importa menos que la disciplina de mantener los tokens sincronizados.
• Error frecuente: crear tokens para absolutamente todo desde el inicio. Empezá con colores y espaciado; son los que generan más inconsistencia cuando no están controlados.

El contexto argentino cambia las reglas

Implementar un sistema de diseño en Argentina tiene particularidades que los tutoriales anglosajones no contemplan. La primera es la conectividad variable: una parte importante del tráfico digital llega desde dispositivos móviles con conexiones que no siempre son estables. Eso implica criterios claros sobre el peso de los assets, el uso de fuentes web y la progresividad del contenido.

La segunda es la rotación de equipos. En un mercado donde los perfiles de UX y desarrollo tienen alta demanda y movilidad, un sistema bien documentado reduce la dependencia de personas específicas. Lo que vemos seguido en proyectos de clientes es que el conocimiento sobre cómo está armada la interfaz vive en la cabeza de una sola persona, y cuando esa persona se va, el equipo queda a ciegas.

La tercera es el ciclo de iteración acelerado. Muchas empresas operan en contextos que obligan a pivotar con frecuencia. Un sistema rígido es un obstáculo; uno bien pensado es un acelerador. La clave está en diseñarlo para que sea fácil de extender sin romper lo existente. Si querés ver cómo este contexto impacta las decisiones visuales más amplias, el artículo sobre tendencias de diseño de interfaces para 2026 ofrece una lectura útil del momento actual.

Errores comunes al armar un sistema

El error más caro no es técnico: es organizacional. Muchos sistemas de diseño mueren porque son responsabilidad de una sola persona o de un equipo aislado. Si los desarrolladores no participaron en su construcción, no lo van a adoptar. Si los diseñadores no lo actualizan cuando el producto evoluciona, queda obsoleto en meses.

Hay otros errores que se repiten: documentar sin ejemplos reales de uso, nombrar los componentes con criterios que solo entiende quien los creó, no definir un proceso claro para proponer cambios. Un sistema sin gobernanza es un sistema que va a bifurcarse, sí o sí.

También es común confundir completitud con calidad. Un sistema con cincuenta componentes pobremente documentados es menos útil que uno con quince que tengan ejemplos claros, criterios de uso y variantes bien definidas. La profundidad de cada pieza vale más que la amplitud del catálogo.

Cómo empezar sin paralizarte

El mejor momento para empezar un sistema de diseño fue hace dos años. El segundo mejor es con el próximo componente que van a construir de todas formas. La estrategia de construir mientras avanzás funciona mucho mejor que un proyecto paralelo que nunca termina de arrancar.

Un camino concreto para equipos que parten de cero:

• Auditá lo que ya existe: tomá capturas de pantalla de todas las pantallas del producto y contá cuántas variantes distintas tienen los botones, los campos de texto y los colores. Ese inventario define la primera prioridad.
• Establecé los tokens antes que los componentes: acordá los colores con roles semánticos y la escala de espaciado. Son las decisiones con mayor impacto transversal.
• Construí el primer componente con toda la documentación que debería tener el sistema: descripción, variantes, estados, criterios de uso, accesibilidad y código. Ese componente se convierte en el estándar de calidad para el resto.
• Definí quién puede proponer cambios y cómo se aprueban. Sin ese proceso, cada persona termina haciendo su propia versión.

Un sistema de diseño es infraestructura. Como cualquier infraestructura, el valor no es inmediato pero el costo de no tenerla sí lo es. Para una visión más amplia de cómo el diseño de interfaz impacta los resultados de un producto digital, el área de diseño de interfaz UI reúne los recursos más relevantes del tema.