Sistema de Diseño
Skill hoja en Diseño; se accede a través de su dominio o por nombre.
Un sistema de diseño solo ahorra decisiones mientras los equipos confían en él. La deriva erosiona esa confianza silenciosamente: tres nombres para un mismo componente, valores hex en bruto junto a los tokens que duplican, estados que nadie documentó. Cuando la gente deja de confiar en el sistema, construye alrededor. Este método funciona en tres modos — auditar el sistema tal como está, documentar un componente para que se use correctamente, extenderlo con un patrón que encaje — y cada uno se basa en la fuente real: archivos de tokens, código de componentes y el archivo de diseño, no en una idea genérica de sistema de diseño.
Un hallazgo de auditoría trabajado
Situación (ficticia): una librería React con un archivo de tokens; la solicitud es "auditar nuestros botones y tarjetas".
Nombres Button, IconBtn y .btn-link nombran un mismo concepto de tres formas.
→ Adoptar Button con una variante `icon` y una `link`; crear alias de los
nombres antiguos durante una versión.
Tokens 23 colores codificados en Card y Modal. 18 equivalen a un token existente
(reemplazar mecánicamente); 5 no coinciden con ninguno.
→ Los 5 necesitan una decisión: un token faltante o un error de diseño que corregir.
Estados Card no tiene estado de foco aunque es clickable.
La elección reutilizable es la división entre un valor que duplica un token, que es una corrección mecánica, y uno que no coincide con ningún token, que es una pregunta de diseño que poner frente a una persona en lugar de adivinar.
Recopilar el sistema
Lee lo que existe antes de juzgarlo: la fuente de tokens, el código de componentes o librería, y la documentación. Una búsqueda como rg -n '#[0-9a-fA-F]{3,8}\b|[0-9]+px' src/components encuentra valores codificados en el código; adapta el patrón al stack.
Las secciones marcadas con
~~nombran una categoría de herramienta, no un producto:~~herramienta de diseño(por ejemplo Figma) o~~base de conocimiento(por ejemplo Notion). Usa la herramienta conectada de esa categoría que proporcione el anfitrión; omite el paso cuando no haya ninguna.
Con una ~~herramienta de diseño, inspecciona nombres de componentes, variantes, estructura de capas y uso de tokens en el archivo de diseño y compáralos con el código. Con una ~~base de conocimiento, encuentra páginas de componentes existentes y guías de uso, y publica documentación actualizada allí solo cuando la persona lo haya solicitado.
Un sistema tiene tres capas; la auditoría y la documentación cubren cada una:
| Capa | Contenido |
|---|---|
| Tokens | Color (marca, semántico, neutro), tipografía, espaciado, radio y borde, elevación, duraciones de movimiento y easing |
| Componentes | Variantes, estados (por defecto, hover, foco, activo, deshabilitado, carga, error), tamaños, comportamiento, accesibilidad |
| Patrones | Formularios, navegación, visualización de datos, retroalimentación — componentes combinados para resolver un problema recurrente |
Cuando los tokens se mueven entre herramientas, el formato del Design Tokens Community Group (primera versión estable 2025.10, octubre de 2025) es el formato de intercambio común; sigue el formato que el proyecto ya usa.
Principios
- Consistencia sobre novedad. El sistema existe para que los equipos dejen de redecidir las mismas cosas; una variante única necesita una razón por la que el sistema carece de ella.
- Componible dentro de restricciones. Prefiere una variante o una composición de componentes existentes sobre un nuevo componente.
- No documentado significa inutilizable. Un estado o variante que nadie puede encontrar se reconstruye.
- Versiona y migra. Un renombramiento o eliminación drástica necesita una ruta de migración, como un alias durante una versión y un codemod o una búsqueda para encontrar usos.
Auditar
Reporta recuentos y evidencia, no una puntuación: un número sin criterios oculta qué problema importa.
## Auditoría del sistema de diseño: [alcance]
**Revisado:** [componentes, archivos de tokens] | **Hallazgos:** [recuento por categoría]
### Nombres
| Problema | Dónde | Recomendación |
|---|---|---|
### Cobertura de tokens
| Categoría | Tokens definidos | Valores codificados | Coincide con un token existente |
|---|---|---|---|
### Completitud de componentes
| Componente | Estados | Variantes | Docs | Accesibilidad |
|---|---|---|---|
| Button | completo | parcial: falta tamaño solo ícono | faltante | anillo de foco presente |
### Acciones prioritarias
1. [Mayor impacto en usuario o equipo primero, con el esfuerzo que requiere]
Documentar
Documenta un componente reutilizable para todos los que lo consumen. Toma las props y el ejemplo de código del componente real, no de una API inventada.
## Componente: [Nombre]
[Qué es y cuándo usarlo — y cuándo usar otra cosa]
### Variantes
| Variante | Usar cuando |
|---|---|
### Props
| Prop | Tipo | Predeterminado | Descripción |
|---|---|---|---|
### Estados
| Estado | Visual | Comportamiento |
|---|---|---|
### Accesibilidad
- **Rol:** [rol o elemento nativo]
- **Teclado:** [Tab, Enter, Espacio, Escape, flechas]
- **Lector de pantalla:** [anunciado como …]
### Hacer y no hacer
| Hacer | No hacer |
|---|---|
### Ejemplo
[Un fragmento corto en el framework del proyecto]
Extender
Antes de proponer algo nuevo, enumera los componentes existentes que se acercan y di por qué cada uno no es suficiente; la mayoría de las solicitudes terminan siendo una nueva variante. Un nuevo componente reutiliza tokens existentes y solo propone un nuevo token con su razón.
## Componente propuesto: [Nombre]
### Problema
[La necesidad del usuario o brecha]
### Opciones existentes
| Componente | Qué comparte | Por qué no es suficiente |
|---|---|---|
### Diseño
Props, variantes y estados como en la plantilla de documentación; tokens usados.
### Accesibilidad
Rol, comportamiento de teclado y lector de pantalla.
### Preguntas abiertas
[Decisiones que necesitan revisión de diseño]
Los componentes y tokens del sistema son el tema de este método. Una ficha técnica para una función o pantalla, y la dirección visual de un nuevo producto, son trabajo de diseño separado; una auditoría del sistema tampoco reemplaza una auditoría WCAG.