Crea el sistema de diseño que sobrevive al paso del tiempo y que desarrollo adopta sin resistencia. Con la arquitectura de componentes, la documentación que funciona, el proceso de contribución y cómo evitar los errores que hacen que los sistemas de diseño queden abandonados.
Cuándo usarlo: Design system, componentes, Figma, Storybook, frontend
Herramienta recomendada: Claude
Eres un Design Systems Lead con experiencia construyendo y escalando sistemas de diseño en equipos de 5 a 50 personas en entornos de producto digital. Contexto: - Tamaño del equipo: [N diseñadores / N desarrolladores] - Stack frontend: [React / Vue / Angular / Svelte / otro] - Herramienta de diseño: [Figma / Sketch / otro] - Estado actual: [sin sistema / UI Kit en Figma desconectado del código / librería de componentes sin documentación / otro] - Problemas actuales: [inconsistencias visuales / los componentes del diseño no coinciden con los del código / desarrollo ignora el kit de diseño / todo hay que explicarlo cada vez / otro] ## Sistema de Diseño — [Empresa/Producto] ### 🧱 La arquitectura correcta (tokens → componentes → patterns) **Nivel 1 — Design Tokens (la base de todo):** Los valores primitivos del sistema: colores, tipografía, espaciado, sombras, radios de borde. ```json { "color": { "brand": { "primary": { "value": "#2563EB" }, "secondary": { "value": "#7C3AED" } }, "neutral": { "100": { "value": "#F3F4F6" }, "900": { "value": "#111827" } } }, "spacing": { "xs": { "value": "4px" }, "sm": { "value": "8px" }, "md": { "value": "16px" }, "lg": { "value": "24px" } } } ``` **Nivel 2 — Componentes base (atómicos):** Button, Input, Badge, Avatar, Icon, Checkbox, Radio, Toggle, Select. Cada componente tiene: variantes, estados, props documentadas. **Nivel 3 — Componentes compuestos:** Modal, Dropdown, Toast, DataTable, Form, Card. Usan componentes base internamente. **Nivel 4 — Patterns y templates:** Combinaciones frecuentes: formularios de login, tablas con filtros, dashboards. ### 📐 Cómo estructurar los componentes para que desarrollo los adopte **El criterio de inclusión en el sistema:** Un componente entra en el sistema cuando aparece en 3+ lugares del producto. Si solo aparece una vez, es un componente de la feature, no del sistema. **La documentación que funciona (y la que no):** ``` ❌ Lo que no funciona: - Capturas de pantalla de cómo se ve el componente - Solo Figma sin código de ejemplo - Reglas sin ejemplos de cuándo aplicarlas ✅ Lo que sí funciona: - Storybook con el componente interactive en el navegador - Código de uso listo para copiar - Ejemplos de cuándo usarlo y cuándo NO usarlo - Las variantes cubiertas con ejemplos visuales ``` **Storybook como single source of truth:** ```javascript // Button.stories.js export default { title: 'Components/Button', component: Button, argTypes: { variant: { control: 'select', options: ['primary', 'secondary', 'ghost'] }, size: { control: 'select', options: ['sm', 'md', 'lg'] }, disabled: { control: 'boolean' }, }, } export const Primary = { args: { variant: 'primary', children: 'Guardar cambios' } } export const Loading = { args: { variant: 'primary', loading: true, children: 'Guardando...' } } export const Destructive = { args: { variant: 'danger', children: 'Eliminar cuenta' } } ``` ### 🔄 El proceso de contribución que evita el caos **Quién puede añadir componentes al sistema:** No todo el mundo. Define roles: - **Consumer:** usa los componentes existentes - **Contributor:** propone nuevos componentes con justificación - **Maintainer:** aprueba, refactoriza y garantiza la coherencia **El proceso RFC (Request for Component):** Cuando alguien necesita un componente que no existe: 1. Verifica que no existe ya (o que no puede adaptarse uno existente) 2. Crea un issue con: screenshot del caso de uso + propuesta de API del componente 3. Revisión del maintainer en 1-2 días 4. Si se aprueba: desarrollo + documentación en Storybook 5. Release con semantic versioning ### 📊 Cómo medir la salud del sistema de diseño El coverage rate (% de la UI construida con componentes del sistema) como KPI principal.