Design Systems con Lightning Decision Jam: del caos en Figma a tokens en producción

La mayoría de proyectos de design system falla de la misma forma. Seis meses adentro, el equipo tiene 47 componentes en Figma, tres estilos de botón compitiendo, dos sistemas de color, cero documentación, y un canal de Slack lleno de debates sobre “¿esto debería ser una variante o un componente nuevo?”. Nada sale al aire.

El problema no son las herramientas. El problema no es el talento. El problema es que los design systems se construyen con ping-pong de opiniones en vez de con decisiones. Ingenieros y diseñadores re-litigan las mismas cinco preguntas cada sprint. La pregunta del botón. La del spacing. La de los íconos. La de dark-mode. La del handoff.

Arrancamos cada engagement de design system igual: un workshop de Lightning Decision Jam (LDJ) de 90 minutos. No porque los workshops estén de moda. Porque LDJ es el único formato de reunión que hemos encontrado que fuerza a un cuarto de gente opinada a decisiones shippeadas en menos de dos horas.

Qué es realmente Lightning Decision Jam

Lightning Decision Jam es un formato de workshop estructurado desarrollado por AJ&Smart, un studio de design sprints en Berlín. Es una secuencia de siete pasos diseñada para mover a un grupo de “tenemos problemas” a “tenemos próximos pasos priorizados” sin caer en las trampas usuales de workshop: peleas de opiniones, anclaje, gana-el-carismático, diseño-por-comité, “volvamos a esto.”

Las mecánicas clave:

• Ideación en silencio. Todos escriben problemas y soluciones en stickies independientemente. Sin discusión hasta que se vota.
• Dot voting. Decisiones por preferencia agregada, no por quien habla más fuerte.
• Mapeo esfuerzo-vs-impacto. Cada solución se coloca en un 2x2. Solo el cuadrante alto-impacto bajo-esfuerzo avanza este sprint.
• Time-boxing estricto. Cada paso lleva minutos, no horas. El reloj fuerza decisiones.

No inventamos LDJ. AJ&Smart publicó el método original y es de uso libre. Lo que hicimos fue adaptarlo específicamente para kickoffs de design system, donde el espacio de problema encaja inusualmente bien: muchas opiniones, muchas decisiones pequeñas, sin respuesta única correcta para la mayoría, y fuerte necesidad de shippear.

Por qué los design systems específicamente necesitan esto

Los design systems son decisiones disfrazadas de trabajo de diseño. No estás realmente debatiendo si un botón debe tener 4px o 6px de border radius. Estás debatiendo quién decide el radius del botón a lo largo de 12 superficies de producto, cómo se propaga esa decisión, y qué pasa cuando un PM quiere uno custom.

Un design system sin alineación es solo un archivo de Figma. Un design system con alineación es un multiplicador en cada superficie de producto que tu equipo construya.

LDJ saca a la luz los desacuerdos reales (governance, ownership, alcance) en vez de dejarlos esconderse detrás de debates de componente que no tienen respuesta hasta que el governance está fijado.

La agenda LDJ exacta de 90 minutos para design systems

Hemos corrido esta agenda 30+ veces. Esta es la versión que funciona.

Pre-trabajo (el día anterior)

• Board de screenshots de auditoría. 20-50 screenshots de las superficies de producto existentes. Pantallas de login, dashboards, tablas, formularios, vistas móviles. Las pegamos todas en un board de Miro o FigJam.
• Participantes. Máximo 5-8. Un PM, dos diseñadores, dos ingenieros, un product leader, opcionalmente una persona de CX/soporte que escucha el dolor del usuario a diario. Más de 8 y el formato deja de funcionar.
• Sin deck de prep. No mandamos un pre-read de 30 slides. El punto es sacar a la luz lo que está en las cabezas de la gente ahora.

Paso 1 — Empezar la lista de problemas (7 minutos)

Todos escriben problemas en stickies, uno por sticky. En silencio. “Cualquier cosa que te frustra de cómo diseño e ingeniería shippean UI hoy.”

Stickies típicos:

• “Tenemos tres componentes de botón y nadie sabe cuál es el actual.”
• “Ingeniería shippea CSS one-off porque Figma nunca tiene el estado que necesita.”
• “Dark mode está 60% hecho en algunos lugares, 0% en otros.”
• “Los diseñadores no pueden decir qué está realmente en Storybook vs qué es solo un mockup.”

Paso 2 — Presentar problemas (5 minutos)

Cada persona lee sus stickies en 30 segundos. Sin discusión. Sin defender. Solo leer.

Paso 3 — Votar por los problemas más importantes (5 minutos)

Cada participante recibe 2 votos (dot stickers en stickies). Los 4-5 problemas más votados se vuelven el foco.

Paso 4 — Reframe de problemas como “Cómo podríamos…” (5 minutos)

Los problemas top se reescriben. “Tenemos tres componentes de botón” se vuelve “¿Cómo podríamos converger a un solo componente de botón y prevenir la próxima divergencia?”

Este paso es pequeño pero cambia todo. Los problemas jalan a la gente hacia queja. Las preguntas HMW jalan hacia solución.

Paso 5 — Soluciones en stickies (10 minutos)

En silencio otra vez. Cada participante genera tantas soluciones como pueda a las preguntas HMW. Una solución por sticky.

Este es el paso más generativo. Con 6 personas y 10 minutos tendrás 60-100 soluciones en stickies. El silencio es el punto — previene anclarse en la primera idea que alguien dice en voz alta.

Paso 6 — Votar por soluciones (10 minutos)

Cada persona recibe 6 votos esta vez. Vota a lo largo de todas las preguntas HMW.

Paso 7 — Mapear soluciones en esfuerzo-vs-impacto (15 minutos)

Las soluciones más votadas se colocan en un 2x2: esfuerzo bajo-a-alto horizontal, impacto bajo-a-alto vertical.

Solo el cuadrante arriba-izquierda (alto impacto, bajo esfuerzo) entra a la cola del próximo sprint. Todo lo demás va a un backlog con etiquetas explícitas de “no ahora”.

Paso 8 — Convertir decisiones en tareas (15 minutos)

Para cada solución del cuadrante top, asignamos: owner, deadline, definition-of-done. Sin estas tres cosas el output del workshop es teatro.

Paso 9 — Cerrar y documentar (10 minutos)

El board de Miro o FigJam es el registro. Le sacamos screenshot, lo posteamos en Slack, y lo linkeamos en el README del design system desde el día uno.

Lo que típicamente sale a la luz

Después de 30+ LDJs de design system, los mismos patrones aparecen en aproximadamente el mismo orden.

Problemas del sprint 1 (siempre los tres votos top):

1. “Nadie sabe qué componente es canónico.”
2. “Diseñadores e ingenieros usan nombres distintos para la misma cosa.”
3. “No hay governance — cualquiera puede agregar cualquier cosa, pero nadie puede quitar.”

Problemas del sprint 2 (después de que los obvios se arreglan):

1. Dark mode y theming son inconsistentes.
2. La accesibilidad es desigual (algunos componentes pasan WCAG AA, otros no).
3. La librería de Figma está fuera de sync con lo que está en código de producción.

Problemas del sprint 3 (rara vez salen en sprint 1 porque están escondidos por los anteriores):

1. No hay capa de design tokens; los valores están hardcodeados dos veces (en estilos de Figma y en CSS).
2. Soporte multi-marca o white-label nunca se planeó.
3. No hay visual regression testing — cada PR es una tirada de dados.

Saber el orden importa. Tratar de resolver problemas de sprint 3 antes que los de sprint 1 es cómo los design systems se vuelven proyectos de 18 meses que nunca shippean.

De workshop a tokens shippeados — el camino de 8 semanas

LDJ es el kickoff. Esto pasa después.

Semana 1 — LDJ + auditoría

Workshop de 90 minutos, luego una auditoría exhaustiva de cada componente actualmente en uso a lo largo de las superficies de producto. Usamos una hoja de cálculo (sí, en serio) listando cada variante de cada componente, dónde aparece, quién lo posee, y si debería vivir en v1 del sistema.

Semana 2-3 — Tokens y primitivos

Los design tokens vienen primero. Color, tipografía, spacing, radii, sombras, motion. Definidos una vez en un archivo de tokens (Style Dictionary o un setup custom de JSON-a-Tailwind-config), consumidos por Figma vía Tokens Studio, consumidos por código vía build step.

Después componentes primitivos: Button, Input, Select, Checkbox, Radio, Toggle, Modal, Tooltip. Los 8-12 componentes que todo producto necesita.

Semana 4-5 — Componentes compuestos y patrones

Cards, tablas, formularios, navegación, estados vacíos, estados de error. Los componentes que componen primitivos en UI reconocible.

Documentamos patrones al lado de componentes: “layouts de formulario”, “tabla-con-filtros”, “bottom-nav móvil”. Los componentes son las partes; los patrones son cómo encajan.

Semana 6 — Storybook y docs

Cada componente va a Storybook con cobertura completa de estado, controles y anotaciones de accesibilidad. La documentación vive al lado del componente, no en una wiki separada que nadie lee.

Para equipos usando Storybook 8+, conectamos visual regression testing con Chromatic o Loki. Cada PR corre diffs visuales. El costo de cachar una regresión ahora es 1/100 del costo de cacharla después del launch.

Semana 7 — Integración piloto

Elegimos una superficie de producto — usualmente el dashboard o la página de settings — y la migramos entera al nuevo sistema. Acá es donde encuentras los gaps. El componente que olvidaste especificar. El token que no encaja del todo. El issue de accesibilidad que solo sale bajo uso real.

Semana 8 — Handoff

Documentación, guía de contribución, doc de governance (quién puede agregar componentes, quién revisa PRs, cómo se bumpean versiones), y una ventana de soporte de 30 días. Tu equipo lo posee de ahí en adelante.

Realidad de pricing

Desde $2,500. 4-8 semanas. Workshop LDJ incluido.

El piso de $2,500 compra un engagement enfocado en tokens + primitivos: design tokens definidos, 10-12 componentes core construidos en Storybook con accesibilidad, docs básicas. Adecuado para startups tempranas que necesitan dejar de reinventar botones.

Engagements más grandes ($15K-$40K) incluyen componentes compuestos, soporte theming/multi-marca, visual regression, migración de una superficie de producto, setup de governance, y 30 días de soporte.

Lo que no compra: un design system que vive en Figma pero nunca llega a código. Shippeamos a producción o no tomamos el trabajo.

Cuándo todavía no necesitas un design system

Hemos sacado a equipos de empezar:

• Menos de 3 superficies de producto y un diseñador. No necesitas un sistema. Necesitas naming consistente.
• Startups pre-PMF. Construye el producto. El sistema puede llegar al mes 18 cuando realmente conozcas tus patrones de UI.
• Equipos de un ingeniero. El overhead de mantener un sistema a esa escala cuesta más que la duplicación que previene.

Un design system es una forcing function para escala. Si todavía no estás a escala, estás forzando lo equivocado.

¿Listo para dejar de re-litigar el radius del botón?

Agenda una llamada de 30 minutos. Te decimos si un design system es el próximo movimiento correcto para tu equipo y cuánto costaría realmente. Si solo necesitas LDJ, también ofrecemos el workshop standalone.

Más sobre workshops LDJ o agenda una llamada de design system. Para contexto más amplio de ingeniería de producto, mira nuestra página de servicios.