Un proyecto de design system suele arrancar con buena intención y con un equipo capaz. A los pocos meses hay tres componentes de botón en Figma, dos paletas de color, un Storybook en el que nadie confía y un hilo de Slack discutiendo si la tarjeta nueva es una variante o un componente aparte. Cada sprint vuelven las mismas preguntas: cuál botón es el bueno, cuál es la escala de espaciado, quién aprueba un ícono nuevo, si el modo oscuro entra o no.
Cada una de esas preguntas es una decisión pendiente, y un grupo de gente capaz y con opiniones fuertes decide muy mal conversando.
Por eso conviene empezar por las decisiones, antes de ponerle nombre a un solo token. Reserva un Lightning Decision Jam de 90 minutos con las cinco a nueve personas que diseñan y construyen la interfaz. Termina con los problemas más votados convertidos en tareas con responsable y fecha, y esas tareas, casi siempre de gobernanza, marcan el orden de las primeras semanas de trabajo.
¿Qué es un Lightning Decision Jam?
Un Lightning Decision Jam (LDJ) es un taller corto y cronometrado: cada quien escribe problemas en silencio, se votan, el ganador se reformula como pregunta “¿Cómo podríamos…?”, se escriben soluciones en silencio y se priorizan por esfuerzo e impacto hasta convertirlas en tareas con responsable. Lo creó AJ&Smart, el estudio de design sprints de Berlín. Jonathan Courtney, uno de sus fundadores, lo explicó en Lightning Decision Jam: A Workshop to Solve Any Problem, y AJ&Smart mantiene material para usarlo. No es invento mío. Lo que hacemos nosotros es facilitarlo y ajustar el enfoque para el arranque de un design system.
Todo el método descansa en cuatro reglas. Cada quien escribe solo y en silencio antes de que nadie hable. Se decide con votos (puntos pegados en los post-its), así que no gana por defecto el que habla más fuerte ni el de mayor cargo. Los problemas se reescriben como preguntas “¿Cómo podríamos…?” antes de proponer soluciones. Y cada paso tiene un cronómetro que nadie extiende.
La versión original de AJ&Smart (en inglés) tiene más pasos que la nuestra, entre ellos una ronda inicial sobre lo que ya funciona bien. Para design systems usamos una versión comprimida de seis pasos, porque el equipo casi siempre llega sabiendo muy bien qué le duele.
Cómo es la sesión
Antes. Pegamos entre 20 y 50 capturas del producto real en un tablero de FigJam o Miro: login, paneles, tablas, formularios, vistas móviles, esa pantalla de configuración que nadie toca desde hace dos años. Ese muro es la evidencia común. No mandamos presentación previa; lo que queremos es sacar lo que la gente ya tiene en la cabeza.
Quiénes participan. Entre cinco y nueve personas: alguien de producto, diseñadores, ingenieros de front-end, quien lidere el producto y, si se puede, alguien de soporte que escuche las quejas de los usuarios todos los días. Con menos de cinco faltan miradas. Con más de nueve los tiempos dejan de alcanzar.
Quién facilita. Un diseñador y un ingeniero. El diseñador lleva la estructura y el reloj. El trabajo del ingeniero aparece en el último paso, cuando hay que revisar rápido qué soluciones puede absorber el código actual.
Los seis pasos:
| Paso | Minutos | Regla |
|---|---|---|
| 1. Anotar problemas | 4 | En silencio. Un problema por post-it. |
| 2. Presentar problemas | 4 | Cada quien lee los suyos en voz alta. Sin preguntas y sin defenderse. |
| 3. Votar problemas | 5 | Dos votos por persona. Avanzan uno o dos. |
| 4. Reformular como reto | 3 | El problema ganador se reescribe como “¿Cómo podríamos…?”. |
| 5. Capturar soluciones | 7 | En silencio. Todas las que se puedan, una por post-it. |
| 6. Decidir y asignar | 15 | Se votan soluciones, las ganadoras van a una matriz de esfuerzo contra impacto y las de alto impacto y bajo esfuerzo pasan a ser tareas con responsable y fecha. |
La consigna del paso 1 es cualquier cosa que moleste de cómo se diseña y se entrega interfaz hoy. Lo típico: “tenemos tres botones y nadie sabe cuál es el vigente”, “en front-end escribimos CSS suelto porque en Figma nunca está el estado que necesitamos”, “no sé qué está en Storybook y qué es solo una maqueta”.
En el paso 4, “tenemos tres botones” pasa a ser “¿Cómo podríamos quedarnos con un solo botón y evitar que vuelva a pasar?”. Parece un detalle, pero convierte una queja en algo que se puede responder. En el paso 5 el silencio pesa más que en ningún otro: la primera idea dicha en voz alta arrastra a todos los demás.
Los pasos suman menos de 40 minutos. El resto de los 90 se va en recorrer el muro de capturas al principio y en repetir los pasos 4 a 6 cuando empatan dos problemas. En total conviene reservar dos horas y media, con preparación antes y media hora después para escribir bien las tareas.
Una tarea sin responsable ni fecha es adorno. Si la sesión termina sin eso, no funcionó, por bonitos que hayan quedado los post-its.
Lo que suele salir primero
Los primeros votos se los suele llevar la gobernanza:
- Nadie sabe cuál es el componente oficial.
- Diseño e ingeniería llaman distinto a la misma cosa.
- Cualquiera puede agregar un componente y nadie puede quitar uno.
Cuando eso ya tiene responsable, aparece una segunda capa: modo oscuro y temas a medias, accesibilidad que cumple en unos componentes y en otros no, y una librería de Figma que se fue alejando de lo que hay en producción.
Hay una tercera capa que suele quedar tapada hasta resolver las dos primeras: valores escritos dos veces (en los estilos de Figma y en el CSS) sin una capa de tokens, soporte multimarca que nadie previó, y cero pruebas de regresión visual, de modo que cada cambio de interfaz es una apuesta.
El orden importa. Los equipos que empiezan por la tercera capa, montando un pipeline de tokens mientras nadie se pone de acuerdo en cuál botón es el bueno, son los que terminan con un design system de 18 meses.
Después del taller
El taller es el arranque. La construcción que sigue suele tomar entre cuatro y ocho semanas y se ve más o menos así:
- Inventario. Una hoja de cálculo (sí, en serio) con cada variante de cada componente, dónde aparece y si entra en la primera versión.
- Primero los tokens. Color, tipografía, espaciado, radios, sombras y movimiento, definidos una sola vez y consumidos tanto por Figma como por el código. El formato de Design Tokens del grupo comunitario del W3C publicó su primera versión estable en octubre de 2025, y herramientas como Style Dictionary y Tokens Studio ya lo soportan, así que hay menos motivos para inventar tu propio formato JSON.
- Primitivos. Botón, campo de texto, selector, casilla, radio, interruptor, modal, tooltip. Los pocos que necesita cualquier producto.
- Compuestos y patrones. Tarjetas, tablas, formularios, navegación, estados vacíos y de error, más los patrones que los combinan (“tabla con filtros”, “formulario de configuración”).
- Storybook y documentación junto a cada componente, con todos sus estados y pruebas de regresión visual en cada pull request.
- Una pantalla piloto. Una superficie real (el panel principal o la configuración) migrada completa. Ahí aparecen el componente que faltó y el token que no encaja.
- Entrega. Guía de contribución y un documento de gobernanza: quién puede agregar componentes, quién revisa, cómo se suben versiones.
Ese documento de gobernanza es lo que responde más directamente a lo que el equipo votó en el taller.
Cuándo todavía no lo necesitas
A más de un equipo le he dicho que no empiece. Si tienes menos de tres superficies de producto y un solo diseñador, lo que necesitas es nombrar las cosas de forma consistente. Si todavía no encontraste encaje con el mercado, construye el producto y deja que los patrones se asienten. Y un único ingeniero manteniendo un design system suele gastar más tiempo en mantenerlo que el que el sistema le ahorra.
Tu primer LDJ, por tu cuenta
Para un primer LDJ no hace falta un facilitador externo. Lee el artículo de AJ&Smart, pega 30 capturas de tu producto en un tablero y deja el cronómetro a la vista durante toda la sesión. Después mira el problema más votado: cuando habla de quién decide, y no de cómo se ve un componente, ese es el problema que tu proyecto de design system tiene que resolver primero.
Si prefieres que lo facilite alguien de fuera del equipo, en español o en inglés, los detalles están en la página del taller.
Actualizado el 23 de septiembre de 2026: reescrito, y se retiraron cifras que no podía respaldar.