Design Sprint: validar en días, no en meses

El Design Sprint es un proceso estructurado de cinco días diseñado por Jake Knapp en Google Ventures para pasar de un problema complejo a una solución validada con usuarios reales, sin construir nada.

No es un proceso de diseño completo. Es una herramienta de reducción de riesgo: te permite equivocarte en cinco días en lugar de hacerlo en cinco meses.

Cuándo tiene sentido hacer un sprint

Un Design Sprint no es la respuesta a todo. Es especialmente útil cuando:

• Hay una pregunta estratégica sin respuesta clara: “¿Tiene sentido añadir esta nueva funcionalidad? ¿Por qué flujo debería entrar el usuario?”
• El equipo lleva semanas debatiendo sin avanzar porque nadie tiene evidencia suficiente.
• Hay que convencer a stakeholders antes de comprometer semanas de desarrollo.
• Se está diseñando algo completamente nuevo, sin referente interno.

Si el problema ya está bien definido y el equipo tiene consenso, un sprint probablemente sea demasiado. Diseña directamente.

Los cinco días

Día 1: Map (Mapear)

El equipo define el objetivo a largo plazo, mapea el journey del usuario y elige un punto de enfoque concreto para el sprint.

Actividades clave:

• Objetivo a largo plazo: qué quieres que el producto consiga en 6-12 meses, en una frase.
• Preguntas del sprint: qué podría salir mal, qué suposiciones necesitas verificar.
• Mapa del journey: un diagrama simple de izquierda a derecha con los actores y los pasos principales del proceso.
• Elección del target: el punto del mapa donde va a centrarse todo el sprint. No podéis resolver todo en cinco días; elegid el momento crítico.
• Entrevistas con expertos: miembros del equipo (producto, desarrollo, soporte, ventas) comparten su conocimiento sobre el problema en rondas de 15-20 minutos. El facilitador captura “How Might We” de cada sesión.

Salida del día: mapa acordado, target elegido, preguntas del sprint claras.

Día 2: Sketch (Idear)

Cada persona trabaja individualmente para generar soluciones. La individualidad es deliberada: evita el pensamiento de grupo y aprovecha la diversidad del equipo.

Actividades clave:

• Lightning Demos: cada persona presenta en 3 minutos un referente que le parece relevante (puede ser un competidor, un producto de otro sector, una función concreta). El facilitador captura las ideas interesantes.
• Four-Step Sketch: el proceso individual de generación de ideas.
  1. Notas: 20 minutos revisando el mapa, el objetivo y las notas del día anterior.
  2. Ideas: 20 minutos generando ideas en bruto, sin filtro.
  3. Crazy 8s: 8 minutos dibujando 8 variantes de la idea más interesante (1 minuto por variante). Fuerza variación sin perfeccionismo.
  4. Storyboard: 30-60 minutos desarrollando la solución en detalle en 3 paneles: contexto, flujo principal, resultado.

Salida del día: un sketch detallado por persona, listo para ser evaluado sin identificar quién lo hizo.

Día 3: Decide (Decidir)

El equipo evalúa las propuestas del día anterior y elige una dirección para prototipar. El proceso de decisión está estructurado para evitar el debate interminable.

Actividades clave:

• Art Museum: los sketches se pegan en la pared. Todo el equipo los examina en silencio durante unos minutos.
• Heat Map: cada persona pega puntos adhesivos en las partes que le parecen más interesantes, sin discutir.
• Speed Critique: 3 minutos por sketch. El grupo identifica en voz alta lo más destacable. El facilitador lo captura. El autor no explica su diseño hasta el final.
• Dot Voting: cada persona vota con un punto adhesivo grande la solución que prefiere. El Decider (quien tiene la decisión final, normalmente el product manager u owner) tiene un voto extra.
• Rumble o merge: si hay dos ideas fuertes incompatibles, se decide si hacer dos prototipos para testear en paralelo o si se fusionan en una.
• Storyboard completo: el equipo construye el storyboard de 10-15 escenas que se va a prototipar al día siguiente. Cada escena es una pantalla del prototipo.

Salida del día: storyboard detallado, panel a panel, listo para construir.

Día 4: Prototype (Prototipar)

El equipo construye un prototipo realista en lo esencial en un solo día. No es código. No tiene que funcionar en producción. Tiene que parecer real al usuario que lo prueba mañana.

División de roles habitual:

• Makers (2-3 personas): construyen los componentes y pantallas individuales en Figma.
• Redactor (Stitcher): escribe todos los textos del prototipo: labels, mensajes de error, confirmaciones, onboarding copy.
• Assembler: ensambla los componentes en pantallas completas y conecta el flujo navegable.
• Reviewer: al final del día, recorre el prototipo completo siguiendo el storyboard y detecta incoherencias.

Principio del prototipo justo-suficiente:

• Solo las pantallas del flujo del test. Nada más.
• Contenido realista, no lorem ipsum. Los usuarios se bloquean con textos de relleno.
• Errores y estados vacíos solo si son parte del flujo de test.

Salida del día: prototipo navegable listo para testear.

Día 5: Test (Testear)

Cinco usuarios reales prueban el prototipo en sesiones individuales de 60 minutos. El resto del equipo observa en remoto y toma notas en una plantilla común.

Estructura de la sesión:

1. Bienvenida y contexto (5 min).
2. Preguntas de calentamiento sobre el contexto del usuario (10 min).
3. Tareas con el prototipo (35-40 min).
4. Preguntas de cierre sobre la experiencia general (5 min).

Síntesis al final del día:

• El equipo se reúne y comparte las notas en una pizarra dividida en dos columnas: lo que funcionó y lo que no.
• Se identifican los patrones: qué se repitió en 3 o más usuarios.
• Se toma una decisión: construir, modificar u descartar.

Salida del día: decisión informada sobre qué hacer a continuación, con evidencia de usuarios reales.

El sprint en versión compacta (2-3 días)

Cuando el problema está bien acotado y el equipo tiene contexto previo, se puede comprimir:

• Día 1: Mapa + Crazy 8s + decisión de enfoque.
• Día 2: Prototipo.
• Día 3: Test y síntesis.

Esta versión pierde profundidad en la fase de ideación y en la calidad del prototipo, pero es válida cuando el objetivo es únicamente desbloquear una decisión concreta.

Errores habituales en un sprint

• Demasiadas personas: el tamaño ideal del equipo es de 4 a 7 personas. Más participantes hacen las decisiones imposibles.
• Sin Decider real: si nadie tiene autoridad para tomar la decisión final, el sprint puede acabar con más debate en lugar de menos.
• Prototipar demasiado: construir más pantallas de las necesarias para el test consume el tiempo del día 4 sin añadir valor al aprendizaje.
• Testear con los usuarios equivocados: si los participantes del día 5 no representan al usuario real, las conclusiones no son válidas.

¿Qué hemos aprendido?

• El Design Sprint comprime semanas de debate en cinco días con evidencia real.
• Cada día tiene una salida concreta: mapa, sketches, storyboard, prototipo, decisión.
• La individualidad en el día 2 y la estructura de votación en el día 3 son los mecanismos que hacen funcionar el proceso.
• Con 5 usuarios y un prototipo justo-suficiente ya tienes evidencia para decidir.

Siguiente paso

En la próxima lección veremos Design System: fundamentos y estructura, donde aprenderás qué es un sistema de diseño, qué piezas lo componen y cuándo tiene sentido empezar a construirlo.