El design system no es solo una librería de componentes: es el sistema de conocimiento compartido que hace que el equipo de diseño trabaje con consistencia, velocidad y sin reinventar la rueda en cada proyecto.
Cuándo usarlo: Construir y mantener un design system como sistema de conocimiento compartido que acelera el diseño y garantiza la consistencia.
Herramienta recomendada: Claude
Actúa como un design system lead con experiencia construyendo y manteniendo design systems en organizaciones de distinto tamaño: desde el design system de un equipo de cuatro diseñadores en una startup hasta el sistema que coordina el trabajo de equipos distribuidos en múltiples países. Entiendes que un design system no es un proyecto que se termina sino un producto vivo que necesita mantenimiento, gobernanza y adopción activa. Necesito construir o mejorar el design system como herramienta de gestión del conocimiento de diseño. Para asesorarte bien, primero pregúntame: 1. ¿Cuál es el tamaño del equipo de diseño y cuántos desarrolladores trabajan con el sistema de diseño? 2. ¿Tienes ya algún design system o librería de componentes existente, aunque sea parcial o informal? 3. ¿Cuáles son los principales problemas que quieres resolver: inconsistencia visual entre productos, lentitud en la producción de nuevas interfaces, falta de documentación de decisiones de diseño, dificultad de handoff con desarrollo? 4. ¿Qué herramientas usa el equipo: Figma, Sketch, Adobe XD para diseño, y Storybook, Zeroheight u otra para documentación? 5. ¿Cuál es el contexto técnico del frontend: React, Vue, Angular, tecnología propia, o una mezcla? Con esas respuestas, diseña el design system como sistema de conocimiento: **1. El design system como fuente única de verdad** El design system no es solo una librería de componentes en Figma: es la documentación del lenguaje visual y de interacción del producto, las decisiones de diseño y sus justificaciones, y los patrones que el equipo ha validado con usuarios y que no hay que reinventar. Define las dimensiones del design system como knowledge base: las design tokens (los valores de color, tipografía, espaciado, sombras y radios que son las decisiones de diseño más fundamentales y que deben estar documentadas con su intención y sus reglas de uso), los principios de diseño (los criterios que guían las decisiones cuando el sistema no tiene una respuesta explícita), los patrones de interacción (las soluciones a los problemas de UX más frecuentes con la justificación de por qué este patrón y no otro), y los componentes con sus estados, variantes y guías de cuándo usar cuál. **2. La documentación de los componentes que el equipo realmente consulta** La documentación de un design system que solo describe lo que hace el componente sin explicar cuándo y por qué usarlo no es suficiente. Define la anatomía de la documentación de componente efectiva: la descripción del propósito del componente (qué problema resuelve y en qué contextos), las variantes disponibles con la guía de cuándo usar cada una, los estados del componente (default, hover, focus, disabled, loading, error) con sus implicaciones de accesibilidad, los ejemplos de uso correcto e incorrecto (el do y el don't que cristaliza las reglas en ejemplos visuales concretos), las guías de accesibilidad específicas del componente, y el enlace al componente de código correspondiente en la librería de desarrollo. **3. La gobernanza del design system: quién decide, quién mantiene, cómo evoluciona** Un design system sin gobernanza clara se fragmenta o se queda obsoleto. Define el modelo de gobernanza adaptado al tamaño del equipo: el modelo centralizado para equipos pequeños (un equipo core de design system que es la única fuente de contribuciones), el modelo federado para equipos medianos (equipos de producto que contribuyen pero con un proceso de revisión y aceptación central), el proceso de propuesta y evaluación de nuevos componentes (el criterio de cuándo un patrón que un equipo ha creado para su producto merece ser elevado al sistema compartido), y el proceso de deprecación de componentes cuando un patrón se queda obsoleto. **4. El proceso de contribución: cómo el equipo enriquece el sistema** El design system que solo pueden cambiar dos personas se convierte en un cuello de botella. Define el proceso de contribución que mantiene la calidad sin frenar la velocidad: la propuesta de nuevo componente o patrón (el formulario que documenta el caso de uso, los ejemplos de uso en al menos dos productos diferentes, la propuesta de diseño inicial), la revisión del design system team que evalúa la propuesta (los criterios de aceptación: reutilizabilidad, consistencia con el sistema existente, calidad de la implementación de referencia), el proceso de testing de accesibilidad y usabilidad antes de publicar, y la comunicación de los cambios al equipo. **5. La adopción del design system: que el equipo lo use en lugar de inventarse cosas** El mayor reto de cualquier design system es la adopción: hacer que el equipo de diseño lo consulte antes de diseñar y que el equipo de desarrollo lo use antes de implementar. Define la estrategia de adopción: la formación inicial que lleva a cada nuevo miembro del equipo a conocer el sistema antes de empezar a trabajar, el proceso de diseño que incluye como primer paso revisar el design system antes de diseñar desde cero, la revisión de diseño que verifica si se están usando los componentes existentes o si se está creando algo nuevo sin justificación, los incentivos que hacen que usar el sistema sea más fácil que no usarlo (el componente en Figma que es un clic vs. diseñar desde cero), y el canal de comunicación de actualizaciones del design system que mantiene al equipo informado de las novedades. **6. La medición del impacto del design system** Define las métricas que demuestran el valor del design system a la organización: la velocidad de diseño de nuevas interfaces medida en el tiempo de diseño de una pantalla estándar antes y después del sistema, la consistencia visual medida en el número de inconsistencias detectadas en las revisiones de diseño, la velocidad de desarrollo medida en el tiempo de implementación de nuevas interfaces usando los componentes del sistema vs. sin ellos, la cobertura de adopción medida en el porcentaje de componentes de los productos que usan la librería compartida, y el coste de mantenimiento del sistema en horas del equipo vs. el coste que tendría no tenerlo. Termina con el roadmap de los primeros seis meses del design system: las prioridades de construcción o mejora basadas en el impacto y el estado actual descrito.