18 de octubre de 2026
·
6 min de lectura
Sistemas de diseño más allá de Figma: componentes, contenido y código
Cómo conectar componentes, contenido y código para construir un sistema de diseño accesible, coherente y útil para todo el equipo.
Temas:
Sistemas de diseño
Product Design
Accesibilidad
Una biblioteca puede tener variantes impecables, nombres ordenados y cientos de componentes. Aun así, el producto puede mostrar tres maneras de comunicar un error, botones que se comportan distinto y formularios difíciles de usar con teclado.
La distancia entre esas dos realidades revela el problema: el sistema existe como archivo, pero todavía no funciona como acuerdo entre personas. Figma permite representar decisiones; el producto necesita que esas decisiones sobrevivan al contenido real, la implementación y los cambios.
Un sistema de diseño útil conecta lo que una interfaz muestra, lo que dice y lo que hace. Para construirlo, conviene empezar por esas relaciones antes de ampliar el catálogo.
La unidad de trabajo es una decisión compartida
Pensemos en un botón para guardar cambios. Su definición visual incluye color, tamaño y espaciado. Pero faltan preguntas decisivas: ¿qué dice mientras guarda?, ¿cómo evita envíos repetidos?, ¿qué sucede si falla?, ¿cómo se comunica el resultado?
La documentación de componentes de GOV.UK combina elementos reutilizables con instrucciones de uso y ejemplos en código. Esa combinación ofrece una referencia concreta para conectar diseño e implementación. GOV.UK: componentes.
Como propuesta de trabajo, cada componente debería tener un pequeño contrato compartido:
Propósito y situaciones en las que conviene utilizarlo.
Anatomía, variantes necesarias y estados posibles.
Reglas de contenido y ejemplos realistas.
Comportamiento, accesibilidad y límites conocidos.
Implementación de referencia, responsable y versión.
No hace falta un documento interminable. Hace falta que diseño, contenido y desarrollo puedan responder las mismas preguntas sin interpretar una captura por separado.
El contenido también forma parte del componente
Una etiqueta ambigua puede volver confusa una interacción visualmente consistente. «Continuar» podría guardar un borrador, avanzar a otra pantalla o confirmar una operación. Si el sistema solo controla el aspecto del botón, deja una decisión esencial sin resolver.
Documentar intención, además de longitud
Una guía de contenido puede definir cómo nombrar acciones, distinguir errores recuperables y explicar estados vacíos. Sus ejemplos deberían incluir textos largos, traducciones y casos poco favorables; el contenido perfecto oculta problemas de diseño.
GOV.UK recomienda explicar qué ocurrió y cómo corregirlo, relacionar el mensaje con la etiqueta del campo y conservar las respuestas al mostrar errores. También distingue los problemas de validación de aquellos que la persona no puede solucionar, como un fallo del servicio. GOV.UK: mensajes de error.
En un ejemplo hipotético, un formulario rechaza un archivo demasiado pesado. «Error al cargar» no ayuda a decidir qué hacer. «El archivo supera el límite de 10 MB. Elige uno más pequeño» permite recuperarse, siempre que ese sea el límite real.
La regla compartida podría exigir motivo, acción siguiente y conservación de los demás datos. El equipo adapta las palabras al contexto sin perder la lógica del patrón.
Los tokens conectan decisiones, no solo colores
Un token da nombre a un valor de diseño para reutilizarlo. La diferencia práctica aparece cuando el nombre expresa intención: «texto de error» explica mejor su uso que «rojo 600». Ambos niveles pueden coexistir, pero cumplen funciones distintas.
El formato del Design Tokens Community Group busca facilitar el intercambio entre herramientas y contempla referencias entre tokens. Conviene describirlo con precisión: el informe 2025.10 es una especificación del grupo comunitario, no un estándar W3C. DTCG: Format Module.
Para un equipo que comienza, propongo tres decisiones explícitas:
Dónde se aprueban y versionan los valores compartidos.
Cómo llegan a las herramientas de diseño y al código.
Cómo se detecta y resuelve una divergencia.
Automatizar una exportación ayuda, pero no determina quién puede cambiar un token ni qué productos resultan afectados. Antes de cambiar un color de error, hay que revisar sus combinaciones reales, sus estados y su uso en distintos temas.
Tampoco conviene transformar cada número en una abstracción. Un token merece existir cuando representa una decisión reutilizable y comprensible.
La accesibilidad se comprueba en funcionamiento
Una variante de foco en Figma documenta una intención. No demuestra que el foco aparezca en el navegador, siga un recorrido comprensible o vuelva al lugar adecuado después de una interacción.
La guía de patrones de WAI-ARIA describe, por ejemplo, la activación de botones con Espacio y Enter, su nombre accesible y la gestión del foco según la acción realizada. Son aspectos de comportamiento que una revisión visual no cubre. WAI-ARIA APG: botones.
Probar el componente y su contexto
Como criterio de aceptación, conviene combinar revisiones automáticas con pruebas manuales de teclado, zoom, contenido extenso y tecnologías de asistencia. Una comprobación aislada tampoco sustituye la revisión del flujo completo.
Imaginemos un botón accesible dentro de un formulario que borra todos los datos al fallar. El componente puede comportarse correctamente y la experiencia seguir siendo problemática. Por eso, las pruebas deben incluir estados de espera, errores y recuperación, además del recorrido exitoso.
Gobernanza: decidir cómo cambia el sistema
Sin un proceso de contribución, aparecen dos extremos: una biblioteca rígida que bloquea necesidades legítimas o un catálogo que acumula variantes para cualquier petición.
Los criterios de GOV.UK piden que las propuestas sean útiles y distintas de lo existente; antes de publicarse, revisan usabilidad, consistencia y versatilidad. También consideran investigación con personas con discapacidad y pruebas en diferentes entornos. GOV.UK: criterios de contribución.
Una adaptación práctica para un equipo de producto sería pedir a cada propuesta el problema, los contextos donde aparece, las alternativas evaluadas y la evidencia disponible. Después, asignar una revisión compartida entre diseño y desarrollo, incorporando contenido y accesibilidad según corresponda.
Las excepciones necesitan responsable y fecha de revisión. Si una variante resuelve una necesidad local, puede permanecer en ese producto. Si demuestra utilidad más amplia, puede incorporarse al sistema.
Cuando un cambio rompe usos existentes, la publicación debe explicar qué cambia, cómo migrar y durante cuánto tiempo se mantendrá la versión anterior.
Adoptar por problemas reales, medir en producción
No es necesario sustituir toda la interfaz de una vez. El modelo de madurez de USWDS propone una adopción incremental que pasa por principios, orientación y código. USWDS: modelo de madurez.
Un punto de partida razonable es elegir un flujo frecuente con inconsistencias visibles. Un formulario permite trabajar campos, botones, errores y contenido como conjunto. Después se comprueba qué decisiones sirven en un segundo contexto.
Para evaluar el avance, propongo observar componentes compartidos realmente utilizados, versiones desactualizadas, excepciones recurrentes y problemas de accesibilidad pendientes. El número de piezas publicadas explica poco si nadie puede adoptarlas sin rehacerlas.
Checklist antes de publicar
¿El componente resuelve una necesidad comprobada?
¿Están claros sus estados y reglas de contenido?
¿Diseño y código representan la misma decisión?
¿Se probó con teclado y contenido realista?
¿Existe evidencia de funcionamiento dentro de un flujo?
¿Tiene responsable, versión y camino de actualización?
¿Se sabe cómo proponer una mejora o justificar una excepción?
Un sistema de diseño empieza a generar confianza cuando evita renegociar lo esencial en cada pantalla. Su valor está en hacer que la siguiente decisión sea más clara, más accesible y más fácil de mantener.
Fuentes
Más artículos
Trabajemos juntos
¿Buscas apoyo para tu producto o equipo? Cuéntame qué necesitas.
O si prefieres, puedes contactarme a través de:
Diseñador de producto e ingeniero de software. Transformo procesos complejos en experiencias claras para productos B2B, con foco en datos e interacción con IA.