Estrategia para centralizar y gestionar sistemas de diseño en plataformas cloud, facilitando la colaboración entre diseñadores, desarrolladores y stakeholders de producto en equipos distribuidos.
Cuándo usarlo: Centralización y gestión de sistemas de diseño en cloud para equipos distribuidos
Herramienta recomendada: Claude
Actúa como un design system lead con experiencia en organizaciones de producto de escala media y grande. Necesito tu ayuda para diseñar la estrategia de gestión de nuestro sistema de diseño en un entorno cloud colaborativo que soporte equipos distribuidos geográficamente. **Situación actual y problemas que resolver:** Nuestro equipo de diseño trabaja con una combinación de archivos Figma locales, componentes duplicados en varios proyectos y una biblioteca de componentes de código desincronizada con los diseños. Los desarrolladores frecuentemente implementan componentes que no coinciden con los diseños aprobados, y los stakeholders tienen dificultades para revisar y aprobar diseños antes del desarrollo. Necesitamos un sistema centralizado y versionado. **Arquitectura del sistema de diseño en cloud:** Define la estructura organizacional del sistema de diseño en Figma o herramienta equivalente: biblioteca de foundations (colores, tipografía, espaciado, iconos, sombras), biblioteca de componentes base (átomos y moléculas de Atomic Design), biblioteca de patrones (organismos y templates), y biblioteca de pantallas y flujos completos. Para cada biblioteca establece: quién tiene permisos de edición, quién de visualización, el proceso de versionado semántico y la estrategia de deprecación de componentes obsoletos. **Sincronización diseño-código:** El principal dolor en equipos de producto es la divergencia entre diseños y código. Diseña el proceso de sincronización usando herramientas como Storybook para documentar componentes de código, tokens de diseño gestionados con Style Dictionary y exportados a CSS custom properties, JSON o variables de plataforma nativa, y GitHub como fuente de verdad para los tokens. Define el workflow: quién actualiza los tokens de diseño, cómo se propaga el cambio al código, cómo se valida que el componente de código coincide con el de Figma. **Proceso de contribución y revisión:** Para que el sistema de diseño escale, necesita un proceso claro de contribución: cómo un diseñador propone un nuevo componente, quién lo revisa (design review), cómo se valida su utilidad (¿resuelve un problema recurrente o es específico de un flujo?), cómo se documenta (uso correcto, variantes, estados, accesibilidad), y cómo se comunica su disponibilidad al equipo. Diseña también el proceso de auditoría periódica para detectar componentes no utilizados o duplicados. **Documentación y onboarding:** Un sistema de diseño sin documentación es una colección de componentes sin contexto. Crea la estructura de documentación necesaria: principios de diseño y criterios de decisión, guía de uso de cada componente con ejemplos de uso correcto e incorrecto, guía de accesibilidad (contrastes WCAG, navegación por teclado, lectores de pantalla), y guía de onboarding para nuevos miembros del equipo de diseño y desarrollo. **Métricas de salud del sistema de diseño:** Define las métricas que usarás para medir el éxito y la adopción del sistema: cobertura de componentes (porcentaje de pantallas de producto que usan componentes del sistema), consistencia (número de variaciones no estándar encontradas en auditorías), velocidad de diseño (tiempo promedio para diseñar una nueva pantalla usando el sistema vs. desde cero), y satisfacción del equipo (NPS interno del sistema de diseño). **Formato de entrega esperado:** - Estructura recomendada de bibliotecas en Figma con jerarquía de permisos - Diagrama del workflow de contribución y revisión - Plantilla de documentación de componente - Dashboard de métricas de adopción del sistema de diseño - Plan de migración de diseños existentes al nuevo sistema