Curso de Design Sprint: Guía Práctica Completa
21 módulos · Guías visuales · Infografías · Casos prácticos · Material de repaso
Módulo 1: Introducción a Design Sprint
Muestra el origen de la metodología, sus ventajas y su encaje con otros marcos de innovación.
1.1 Definición y Origen
Design Sprint es un método estructurado, colaborativo y con límites de tiempo (time-constrained) diseñado para responder preguntas comerciales críticas mediante el diseño, prototipado y validación de ideas con usuarios reales. Fue creado originalmente por Jake Knapp en Google Ventures, una división de Google que opera invirtiendo en startups prometedoras. Nació en un escenario de alta competencia tecnológica donde 'el tiempo es dinero' y esperar el proceso tradicional de desarrollo y lanzamiento de un producto no era viable. El método se popularizó en el libro 'Sprint' (2017), escrito por Jake Knapp junto a sus socios John Zeratsky y Braden Kowitz.
1.2 Ventajas y Limitaciones
La metodología aporta múltiples beneficios, pero también presenta restricciones que conviene conocer:
- Reducción de riesgos y costos: Permite validar ideas de producto mediante una fachada interactiva (prototipo) antes de invertir tiempo y presupuesto en el desarrollo real de ingeniería.
- Aceleración del ciclo de aprendizaje: Actúa como un 'atajo' para aprender del cliente sin necesidad de construir de verdad.
- Alineación y visión compartida: Fomenta el consenso táctico y elimina interminables discusiones corporativas, alineando al equipo multidisciplinar desde el primer día.
- Limitación - No sustituye al desarrollo: Al final del sprint se obtiene un prototipo validado, no un software en producción ni un MVP funcional para el mercado masivo.
- Limitación - Inmersión total: Requiere reservar la agenda de personas clave durante varios días, lo cual puede ser un desafío logístico significativo.
1.3 ¿Cuándo usarlo y cuándo NO?
Cuándo usar:
- Al inicio de un nuevo proyecto o producto para definir su alcance o crear una visión unificada.
- En un bloqueo, callejón sin salida (atolladero) o bifurcación, cuando el equipo necesita destrabarse.
- Cuando el tiempo es sumamente crítico y se requiere velocidad extrema en la toma de decisiones.
- Para profundizar en un elemento oscuro o poco definido del Product Backlog (conocido en Agile como un 'Design Spike').
Cuándo NO usar:
- Si no hay investigación previa de usuarios ni comprensión básica de la base de clientes.
- Si ya se tiene una dirección totalmente clara y solo se requiere tiempo dedicado para ejecutarla.
- Si no se cuenta con la participación activa o patrocinio de los líderes (especialmente del Decider).
1.4 Relación de Enfoques: Design Thinking, Lean Startup y Agile
La combinación de estos tres enfoques genera la efectividad en la innovación moderna:
- Design Thinking: Enfoque centrado en las personas que busca explorar el problema y empatizar profundamente con el usuario para descubrir la deseabilidad.
- Lean Startup: Enfoque para 'construir la cosa correcta' mediante el ciclo 'Crear-Medir-Aprender' y el Producto Mínimo Viable (PMV), validando la viabilidad del negocio.
- Agile (Scrum): Marco de ejecución iterativo centrado en 'construir las cosas bien' de manera incremental, gestionando el Product Backlog en sprints de desarrollo de software.
- Design Sprint: Funciona como el puente táctico que combina la empatía de Design Thinking con la experimentación ágil e hipótesis de Lean Startup, validando una idea en solo una semana antes de iniciar Scrum.
| Dimensión | Design Thinking | Lean Startup | Agile (Scrum) | Design Sprint |
| Objetivo | Explorar problemas de forma humana y abierta. | Validar viabilidad del negocio. | Construir producto de forma incremental. | Validar soluciones críticas en 4-5 días. |
| Foco | Deseabilidad (usuario). | Viabilidad (negocio). | Factibilidad (técnica). | Deseabilidad y validación rápida. |
| Entregable | Mapas de empatía, conceptos de ideas. | Producto Mínimo Viable (PMV). | Incremento de software terminado. | Prototipo interactivo en alta fidelidad. |
Design Thinking ayuda a explorar el problema, Lean Startup aporta la lógica de experimentación y Agile permite construir de forma iterativa. Design Sprint conecta estos enfoques para reducir incertidumbre antes de realizar una inversión significativa en desarrollo.
| ★ QUÉDATE CON ESTO: Design Sprint es una metodología práctica basada en el Design Thinking y el marco ágil. Su lema es 'falla rápido, aprende más rápido' como un atajo directo para aprender del cliente sin construir el producto real. |
| ★ RECORDAR: Recuerda la combinación de enfoques: Design Thinking explora el problema, Lean Startup valida la dirección y Agile construye el producto final. El Design Sprint es un spike táctico que se coloca justo antes de la fase de desarrollo para reducir riesgos. |
Módulo 2: Principios Fundamentales
Explica las bases mentales y operativas que rigen el Design Sprint.
2.1 El Foco en el Usuario y la Empatía
Toda actividad dentro del sprint se orienta a empatizar profundamente con el usuario. Las decisiones se toman basándose en las necesidades de las personas reales, no en especulaciones de la junta directiva.2.2 Reducción de Incertidumbre y Timeboxing
La incertidumbre se ataca forzando al equipo a tomar decisiones rápidas bajo una limitación de tiempo estricta (timeboxing). El tiempo limitado previene la sobre-ingeniería y el debate excesivo, forzando la creatividad.
2.3 Hipótesis y Experimentación
Se asume una mentalidad científica. Cada idea es tratada como una hipótesis que debe validarse a través de un experimento objetivo (las entrevistas de usabilidad). No se defiende la idea por orgullo, sino por evidencia.
2.4 Divergencia y Convergencia
El sprint sigue la estructura del doble diamante. Durante la divergencia (lunes y martes), se expanden los límites y se generan tantas soluciones como sea posible de forma individual y silenciosa. Durante la convergencia (miércoles), se filtran, comparan y eligen las mejores propuestas.
2.5 'Trabajar Individualmente, Juntos'
Es el principio fundamental de la facilitación. Se evitan las lluvias de ideas (brainstorming) abiertas donde el pensamiento grupal (groupthink) y los perfiles dominantes sesgan las soluciones. En su lugar, cada participante trabaja en silencio en sus ideas antes de compartirlas de forma anónima.
| ★ QUÉDATE CON ESTO: El principio de 'trabajar individualmente, juntos' es la clave para desbloquear el verdadero potencial creativo del equipo sin caer en discusiones infructuosas. |
| ★ RECORDAR: La mentalidad científica y el principio de «trabajar individualmente, juntos» son dos pilares del Design Sprint. Las ideas se tratan como hipótesis y se validan mediante evidencia, evitando que el pensamiento grupal determine las soluciones. |
Módulo 3: Preparación del Design Sprint
Detalla las actividades necesarias para asegurar el éxito antes de que inicie la inmersión (Día 0).
3.1 Definición del Reto, Objetivo y Alcance
Antes de iniciar, el organizador debe definir un reto claro. Este reto no debe ser ni demasiado amplio ('rediseñar la experiencia de banca mundial') ni demasiado estrecho ('cambiar el color del botón de pago'). Debe ser una pregunta comercial relevante con suficiente alcance.
3.2 El Espacio de Trabajo (War Room o Sala de Guerra)
Es crucial contar con una sala dedicada que fomente la colaboración inmersiva:
- Pizarras blancas: Al menos dos pizarras grandes en las paredes.
- Materiales: Post-its de varios colores (amarillos, rosados, azules), rotuladores finos negros, papel A4, stickers redondos adhesivos (puntos de votación) y temporizadores físicos visibles.
- Sin distracciones: Prohibir el uso de teléfonos y portátiles dentro de la sala, excepto en las pausas.
3.3 Preparación de la Agenda (Día 0 o Fase Zero)
La fase Zero incluye:
- Compartir una sesión informativa o briefing sobre el reto y el objetivo a largo plazo.
- Hacer encuestas rápidas con usuarios para recopilar datos de entrada.
- Comunicar los horarios con anticipación y asegurar el bloqueo de la agenda de los participantes.
- Proporcionar los materiales necesarios y coordinar la logística del almuerzo y café.
| ★ QUÉDATE CON ESTO: La preparación previa (Fase Zero) es indispensable. Un sprint que arranca con un reto mal enmarcado o sin materiales terminará frustrando al equipo y produciendo resultados poco concluyentes. |
| ★ RECORDAR: El espacio de trabajo se denomina 'Sala de Guerra' o 'War Room'. Recuerda la regla de las distracciones: dispositivos bloqueados para mantener el foco constante. |
Módulo 4: Roles y Responsabilidades
Describe el equipo de sprint y el reparto de tareas.
4.1 El Equipo del Sprint
El equipo ideal está formado por 7 personas o menos para mantener la agilidad. Debe ser multidisciplinar e incluir las siguientes perspectivas:
4.2 Descripción de Roles
- Facilitador: Es el moderador del proceso. Es neutral, gestiona el tiempo de las actividades, controla la energía del grupo, modera discusiones y asegura que se cumplan las reglas. No toma decisiones de contenido.
- Decider (Definidor): Es el tomador de decisiones clave (ej. Product Owner, Gerente, Directivo). Es responsable de destrabar discusiones y dar la última palabra mediante el Supervoto. Su participación es obligatoria.
- Expertos: Perfiles clave en finanzas, marketing, tecnología, logística y consumidor que aportan contexto técnico y conocimientos específicos del mercado.
- Creador de Problemas (Troublemaker): Un perfil crítico y divergente que reta al grupo y evita que se enamoren de soluciones fáciles.
- Diseñadores e Ingenieros: Encargados de construir el prototipo interactivo en tiempo récord.
4.3 Diferencia Clave: Facilitador frente a Decider
Es uno de los conceptos más importantes. El Facilitador posee el control sobre el proceso (las dinámicas, el reloj, la agenda), mientras que el Decider posee el control sobre el contenido (el negocio, los retos, qué solución elegir). El Facilitador nunca debe imponer su criterio de diseño, y el Decider nunca debe boicotear el timeboxing de las actividades.
| Rol | Responsabilidad Principal | Poder sobre... | Neutralidad |
| Facilitador | Asegurar el cumplimiento del proceso, dinámicas y timeboxing. | El proceso y la agenda. | Totalmente neutral. No opina sobre el diseño. |
| Decider | Tomar las decisiones finales de negocio, prioridades y el Supervoto. | El contenido y la dirección. | No es neutral. Defiende la estrategia del negocio. |
| ★ QUÉDATE CON ESTO: El equipo perfecto une la facilitación ágil con el poder de decisión estratégica del negocio. Nunca corras un sprint sin un Decider asignado. |
| ★ RECORDAR: No confundas autoridad sobre el proceso con autoridad sobre el contenido. El Facilitador protege dinámicas, agenda y timeboxing; el Decider asume las decisiones finales y representa la dirección del negocio. |
Módulo 5: Comprender el Problema (Día 1 / Lunes)
La primera fase del sprint consiste en alinear al equipo, explorar el problema y definir el objetivo.
5.1 El Objetivo a Largo Plazo (Long-Term Goal)
Comenzamos el sprint con una perspectiva optimista sobre el futuro: '¿Dónde queremos estar dentro de un año, dos años o cinco años?'. El equipo define un objetivo a largo plazo claro que servirá como su estrella guía.
5.2 Preguntas del Sprint (Sprint Questions)
Al mismo tiempo, adoptamos un punto de vista crítico y pesimista: '¿Qué podría salir mal? ¿Qué riesgos técnicos, comerciales o de experiencia podrían evitar que alcancemos nuestro objetivo a largo plazo?'. Esto se traduce en una lista de preguntas específicas que el sprint necesita responder.
5.3 El Mapa del Recorrido (Mapping)
El mapa es un diagrama muy simple (de 5 a 15 pasos) que conecta a los actores clave de la izquierda con el objetivo final a la derecha, mostrando el recorrido actual del usuario e identificando dónde se produce la fricción principal.
5.4 Entrevistas con Expertos y 'Cómo Podríamos' (HMW)
Para enriquecer nuestra comprensión:
- Entrevistas con expertos: El Facilitador entrevista a personas clave de la organización para obtener datos de soporte, detalles técnicos e insights.
- Cómo Podríamos (How Might We - HMW): Los participantes escuchan activamente y convierten cada punto de fricción o problema en una pregunta de oportunidad bajo el formato HMW (Cómo = solución, Poder = optimismo, Nosotros = colaborativo).
- Priorización y votación: Las notas HMW se organizan por temas en una pizarra y se realiza una votación con stickers (pegatinas adhesivas) para enfocar los esfuerzos en las oportunidades de mayor impacto.
- Selección del Target: El Decider toma la decisión final sobre qué actor, qué paso del mapa y qué oportunidades HMW serán la meta del sprint.
| ★ QUÉDATE CON ESTO: El lunes (o el primer día de 2.0 por la mañana) se enfoca en alinear a todo el equipo multidisciplinar sobre la meta del sprint y el cuello de botella. No entres en fase de solución hasta haber comprendido el problema. |
| ★ RECORDAR: La secuencia lógica es: Objetivo a Largo Plazo -> Preguntas de Sprint -> Mapa -> Entrevistas de Expertos -> Notas HMW -> Votación -> Selección de la Meta por el Decider. |
Módulo 6: Generación de Soluciones (Día 1 Tarde / Martes)
La fase de divergencia donde se busca crear una gran cantidad de alternativas innovadoras de forma individual.
6.1 Lightning Demos (Demostraciones de Rayos)
Es un ejercicio de benchmarking rápido. Los participantes buscan inspiración existente en el mercado (en otras industrias, productos o competidores). Cada miembro presenta su referencia durante 3 minutos y el Facilitador toma notas en la pizarra de los conceptos más interesantes.
6.2 El Proceso de Boceto de 4 Pasos (Solution Sketch)
La ideación individual e independiente evita el groupthink mediante cuatro actividades consecutivas:
- Paso 1 - Notas: Recorrer silenciosamente la sala para tomar notas de la información recopilada en la pizarra (los HMW, los mapas, las demos de inspiración).
- Paso 2 - Ideas: Hacer dibujos y garabatos libres en un papel borrador para empezar a estructurar conceptos e ideas vagas.
- Paso 3 - Crazy 8s: Un ejercicio de alta velocidad donde se dobla un papel en 8 cuadrantes y se dibujan 8 variaciones de una idea, dedicando un minuto por cuadrante para forzar el pensamiento lateral.
- Paso 4 - Boceto de Solución (Solution Sketch): Crear un boceto final detallado de tres paneles (storyboard de la solución) que sea anónimo, autoexplicativo, contenga un título llamativo y palabras explicativas escritas con rotulador.
| ★ QUÉDATE CON ESTO: En el boceto final lo que importa es la calidad de la solución técnica, de negocio y experiencia de usuario, no el talento artístico. El dibujo de la solución debe ser autoexplicativo. |
| ★ RECORDAR: El proceso de boceto sigue cuatro pasos: Notas → Ideas → Crazy 8s → Solution Sketch. Crazy 8s fuerza la exploración de alternativas; el Solution Sketch convierte una de ellas en una propuesta detallada y autoexplicativa. |
Módulo 7: Selección y Toma de Decisiones (Día 2 / Miércoles)
Fase de convergencia para filtrar y seleccionar la mejor propuesta de forma rápida y objetiva.
7.1 El Proceso de Votación y Decisión Pegajosa (Sticky Decision)
Para evaluar las propuestas de forma justa y sin discusiones, se sigue este proceso estructurado:
- Art Museum (Museo de Arte): Los bocetos de solución se pegan de forma anónima en la pared de la sala de guerra.
- Heat Map (Mapa de calor): Los participantes recorren silenciosamente la sala de guerra y colocan pequeños stickers redondos adhesivos en las partes específicas de los bocetos que más les atraen, formando un mapa de calor visual.
- Speed Critique (Crítica rápida): El Facilitador revisa cada boceto, narra en voz alta las ideas destacadas señaladas por los stickers y el 'Escribiente' toma notas en post-its sobre el boceto. El creador puede aclarar cualquier malentendido al final de forma breve (3 minutos por solución).
- Straw Poll (Encuesta): Votación informal de los participantes con una pegatina más grande para señalar su solución completa favorita, justificando su elección en voz alta.
- Supervote (Súper voto): El Decider toma la decisión final sobre qué concepto o boceto se construirá, colocando sus pegatinas especiales (Supervotos) con peso absoluto sobre las ideas clave.
7.2 Consenso frente a Decisión
El Design Sprint no busca el consenso colectivo, el cual tiende a diluir la innovación y prolongar los debates corporativos interminables. Se busca alineación colaborativa donde el Decider es responsable de la última palabra basándose en los inputs visuales del equipo.
| ★ QUÉDATE CON ESTO: La decisión pegajosa (Sticky Decision) permite filtrar ideas y decidir la propuesta con mayor potencial de forma visual, silenciosa y en tiempo récord, respetando la autoridad del Decider. |
| ★ RECORDAR: Memoriza la lógica, no solo los nombres: Art Museum → Heat Map → Speed Critique → Straw Poll → Supervote. El equipo aporta información; el Decider asume la decisión final. |
Módulo 8: Storyboard (Día 2 Tarde / Miércoles Tarde)
Se detalla la planificación y la construcción de la guía visual para el prototipo.
8.1 El Flujo de Prueba de Usuario (User Testing Flow)
Se definen silenciosamente de 5 a 6 pasos fundamentales del recorrido del usuario durante la prueba, desde el momento en que se entera de la existencia del producto hasta que completa la tarea de mayor valor comercial.
8.2 Construcción del Storyboard (Guión Gráfico)
Consiste en un plano detallado de la experiencia de prueba. De 10 a 15 paneles grandes dibujados en la pizarra blanca donde el equipo detalla de forma exacta el contenido de cada pantalla (textos reales, imágenes, botones y transiciones). El storyboard actúa como una especificación de construcción, permitiendo que al día siguiente los diseñadores e ingenieros puedan prototipar sin debates de contenido.
| ★ QUÉDATE CON ESTO: La regla de oro del Storyboard es no debatir ideas nuevas. Se dibuja únicamente lo seleccionado por el Decider en el Supervoto. Debe contener suficiente detalle para evitar dudas al día siguiente. |
| ★ RECORDAR: El Storyboard es el blueprint del prototipo. Su regla de oro es no introducir nuevas ideas: desarrolla únicamente aquello que ya ha sido seleccionado. |
Módulo 9: Prototipado Rápido (Día 3 / Jueves)
El día destinado a construir la simulación interactiva de la solución.
9.1 La Filosofía 'Fake It' y la Calidad Ricitos de Oro (Goldilocks Quality)
La premisa fundamental es construir fachadas realistas que parezcan un producto final, simulando por completo la experiencia de usuario sin codificar el backend real. El prototipo debe ser desechable, construido únicamente para aprender lo justo de la reacción del cliente. Debe cumplir la Calidad Ricitos de Oro (Goldilocks Quality): ni muy tosco que no parezca real (el usuario se enfocará en opinar sobre la estética, no sobre el concepto), ni demasiado desarrollado que requiera semanas de programación.
9.2 Reparto de Tareas (Divide y Vencerás)
Para construir el prototipo en un solo día, el Facilitador coordina la distribución de tareas:
- Makers (Hacedores): Diseñadores o ingenieros (generalmente 2 o 3) que se encargan de crear las pantallas visuales usando herramientas de diseño rápido como Figma, PowerPoint o Keynote.
- Stitcher (Costurero/Cocedor): Se encarga de unir las partes individuales creadas por los makers para asegurar la consistencia del flujo, botones interactivos y fuentes.
- Writer (Escritor): Redacta textos realistas e informativos, evitando rellenar pantallas con 'Lorem Ipsum', ya que esto arruina el realismo del prototipo.
- Asset Collector / Reviewer (Revisor/Recopilador): Busca imágenes, logotipos, iconos y referencias necesarias para alimentar a los makers.
- Interviewer (Entrevistador): Se enfoca en preparar la guía de la entrevista para el día siguiente y realiza una prueba del prototipo al final del día junto al Stitcher para asegurar que funcione perfectamente.
9.3 Diferencias: Prototipo, MVP y Producto Terminado
Es indispensable comprender los límites de cada concepto para evitar malas alineaciones:
- Prototipo: Una fachada interactiva en alta fidelidad construida en 1 día. No es funcional ni escalable, es desechable y sirve únicamente para aprender del cliente de forma inmediata.
- MVP (Producto Mínimo Viable): Una versión funcional del producto lanzada al mercado con características básicas pero completas. Requiere desarrollo, recopila datos cuantitativos y su ciclo de aprendizaje es más largo.
- Producto Terminado: La versión definitiva, robusta, segura y escalable del producto, lista para soportar toda la base de usuarios.
| ★ QUÉDATE CON ESTO: La mentalidad del prototipo se basa en que los prototipos son desechables. No construyas nada con código si puedes simularlo de forma realista en un día con herramientas de diseño. |
| ★ RECORDAR: El prototipo es una simulación construida para aprender rápidamente. No lo confundas con un MVP: el prototipo puede ser desechable y no necesita backend; el MVP es ya un producto mínimo funcional utilizado en condiciones reales. |
Módulo 10: Validación con Usuarios (Día 4 / Viernes)
La fase final del sprint donde se expone la solución directamente al mercado real.
10.1 Selección de Usuarios y la Regla de los 5
Las pruebas de usabilidad se realizan en formato 1:1 con 5 usuarios reales por separado, cada una con un tiempo máximo de 1 hora. Según los estudios del experto en usabilidad Jakob Nielsen, entrevistar a 5 usuarios es suficiente para identificar el 85% de los problemas de usabilidad e interactividad de una solución. Entrevistar a más usuarios genera rendimientos decrecientes.
10.2 La Entrevista de 5 Actos (Five-Act Interview)
El Entrevistador conduce la conversación de forma amigable y sin guiar al usuario mediante esta estructura:
- Bienvenida amigable y calentamiento: Romper el hielo, relajar al usuario y explicar la metodología.
- Preguntas de contexto sobre el cliente: Entender sus hábitos, estilo de vida, frustraciones actuales y relación con la tecnología para enmarcar sus comentarios.
- Presentación del prototipo: Mostrar el prototipo recordando al usuario de forma clara que 'es solo una simulación creada recientemente, no es un producto final, puede fallar y no herirá nuestros sentimientos si es crítico'.
- Tareas detalladas para comprobar la reacción: El entrevistador plantea escenarios realistas y pide al usuario realizar tareas, instándolo a 'pensar en voz alta' mientras interactúa de forma autónoma con la simulación.
- Cierre o Debriefing: Una breve encuesta o preguntas abiertas finales para recopilar las impresiones, emociones e interpretaciones generales del usuario sobre el concepto.
10.3 Observación y Patrones
El equipo del sprint asiste por streaming en tiempo real a las entrevistas desde otra habitación (o de forma remota). Cada participante anota de forma individual observaciones en un tablero en forma de post-its usando un código de colores o categorías: positivo (+), negativo (-) o neutro. Al final de la tarde, se revisan las notas en silencio y se identifican patrones de comportamiento comunes entre los usuarios.
| ★ QUÉDATE CON ESTO: Validar una hipótesis no significa intentar que el usuario confirme o valide nuestra idea inicial. Significa observar de forma amigable, abierta y objetiva cómo interactúan los usuarios reales con el prototipo. |
| ★ RECORDAR: La estructura de la entrevista de 5 actos es: Bienvenida → Contexto → Presentación → Tareas/Pensar en voz alta → Cierre. El objetivo no es conseguir que el usuario apruebe la solución, sino observar su comportamiento y detectar patrones. |
Módulo 11: Resultados y Siguientes Pasos
Muestra cómo cerrar el sprint interpretando la evidencia obtenida.
11.1 Evaluación del Reto y Preguntas del Sprint
Al finalizar las 5 entrevistas, el equipo se reúne en la sala de guerra y revisa el Objetivo a Largo Plazo y las Preguntas de Sprint del lunes. Se comprueba de forma empírica y basándose en el tablero de observaciones cuántas preguntas fueron contestadas y en qué dirección.
11.2 Tipos de Resultados del Sprint
Las evidencias recolectadas pueden arrojar diferentes escenarios de validación:
- Éxito rotundo (Hipótesis totalmente validada): Los usuarios entendieron la propuesta, completaron las tareas con facilidad y expresaron entusiasmo. El equipo puede transferir la solución directamente al backlog de Scrum.
- Validación parcial (El resultado más común): El concepto principal funcionó muy bien, pero los usuarios tropezaron con ciertos pasos específicos o textos del flujo. Se requiere iterar mediante un sprint de seguimiento más corto.
- Fracaso eficiente (Hipótesis rechazada): Los usuarios rechazaron el concepto de raíz o no entendieron la propuesta. Aunque parezca desalentador, es un excelente resultado comercial porque ahorró meses de desarrollo e inversión en un producto inviable.
- Resultados no concluyentes.
11.3 La Hoja de Ruta (Roadmap) y Siguientes Iteraciones
Cualquiera que sea el resultado, el sprint debe finalizar estructurando los próximos pasos en un Roadmap. Si hay validación parcial, se planifica un sprint iterativo corto de 2 o 3 días para ajustar los puntos débiles de la simulación.
| ★ QUÉDATE CON ESTO: En Design Sprint no existe el fracaso si hay aprendizaje. Un fracaso eficiente es el mejor de los éxitos preventivos de negocio. |
| ★ RECORDAR: El Sprint no termina necesariamente con un «sí» o un «no». Su objetivo es producir evidencia suficiente para decidir qué hacer después. |
Módulo 12: Facilitación Profesional
Consejos de moderación ágil para gestionar la dinámica del equipo.
12.1 El Rol del Facilitador como Líder de Proceso
El Facilitador debe mantener la neutralidad total. No debe diseñar, opinar sobre el negocio ni imponer su criterio de contenido. Su foco absoluto es guiar al equipo y controlar las dinámicas del proceso.
12.2 Técnicas de Facilitación
- Control del tiempo: Usar temporizadores físicos o digitales visibles en la sala (el timeboxing estricto previene las discusiones).
- Gestión de la energía: Introducir pausas breves de estiramiento y controlar la energía del grupo a lo largo del día mediante actividades bien dinámicas.
- Gestión de personas dominantes: En Design Sprint la regla de 'trabajar individualmente, juntos' minimiza el impacto de los perfiles ruidosos, dando voz por igual a todos mediante post-its y votaciones en silencio.
- Neutralización de bloqueos y conflictos: Recordar que ante dudas o callejones sin salida interminables, el Decider es quien posee la autoridad para desbloquear mediante su Supervoto directo.
| ★ QUÉDATE CON ESTO: Un buen facilitador lidera el proceso, no las decisiones. Su éxito se mide en la consistencia de las dinámicas y la energía del equipo multidisciplinar. |
| ★ RECORAR: Ante un bloqueo que el equipo no puede resolver, el Facilitador no debe imponer su criterio. Protege el proceso y recurre al Decider para desbloquear la decisión. |
Módulo 13: Design Sprint Remoto
Alineación y mejores prácticas para facilitar sprints distribuidos.
13.1 Herramientas y Preparación
El sprint remoto requiere emular la sala de guerra física de forma digital:
- Pizarra de colaboración: Usar herramientas interactivas como Miro o Mural para el mapeo, notas HMW y votaciones visuales.
- Videoconferencia estable: Usar plataformas como Zoom, Teams o Teams con salas de descanso para dinámicas de equipo.
- Prototipado rápido en la nube: Figma o Miro para que los hacedores co-diseñen y colaboren en línea en tiempo real.
13.2 Buenas Prácticas del Sprint Remoto
- Dividir en bloques de tiempo más cortos (sesiones de 4 horas en lugar de 8 horas) para evitar la fatiga digital, permitiendo que el trabajo individual de bocetado se realice asincrónicamente fuera de la videollamada.
- Asegurar que todos los participantes dominen las herramientas colaborativas básicas antes del sprint de diseño mediante un pre-work o un onboard técnico de 30 minutos.
|
★ QUÉDATE CON ESTO: El sprint remoto funciona si se reducen las horas de pantalla en vivo, se confía en el trabajo asincrónico y se define una plantilla virtual clara en la pizarra digital. |
|
★ RECORDAR: El trabajo individual y anónimo sigue siendo importante en remoto. Cambia la herramienta, no los principios del método. |
Módulo 14: Errores Habituales
Analiza los problemas de facilitación y ejecución más frecuentes bajo el formato de control pedagógico:
14.1 Errores en la Definición del Reto
- Reto excesivamente amplio: ERROR: El reto seleccionado es demasiado amplio y ambiguo.
- Por qué ocurre: POR QUÉ OCURRE: El organizador quiere solucionar todos los problemas de la empresa en una sola semana de trabajo.
- Consecuencia: CONSECUENCIA: El equipo se dispersa, el mapa se vuelve inmanejable y es imposible construir un prototipo viable en 1 día.
- Cómo evitarlo: CÓMO EVITARLO: Enmarcar el reto de forma acotada. Enfocar el sprint en una única corriente crítica del flujo del usuario.
14.2 Errores en los Roles
- Ausencia del Decider: ERROR: El Decider (Definidor) no participa o delega su asistencia.
- Por qué ocurre: POR QUÉ OCURRE: El directivo cree que el sprint es 'un taller de diseño creativo' que no requiere su tiempo.
- Consecuencia: CONSECUENCIA: Al final del sprint, el directivo rechaza el prototipo y los resultados porque no se alinean con la estrategia comercial.
- Cómo evitarlo: CÓMO EVITARLO: Su presencia es obligatoria. Si el Decider no puede bloquear su agenda completa, se le debe invocar de forma presencial en las decisiones clave del primer día por la mañana y de las votaciones.
14.3 Errores en el Prototipado y Validación
- Sobredesarrollo del prototipo: ERROR: Construir el prototipo en código real.
- Por qué ocurre: POR QUÉ OCURRE: Los ingenieros o desarrolladores quieren que la base de datos y la interactividad técnica sean 100% correctas.
- Consecuencia: CONSECUENCIA: Toma semanas construirlo, se pierde agilidad comercial y el equipo se vuelve defensivo ante los comentarios críticos de los usuarios.
- Cómo evitarlo: CÓMO EVITARLO: Adscribirse estrictamente a la filosofía 'Fake It'. Diseñar únicamente fachadas estáticas y enlazadas para la usabilidad visual.
|
★ QUÉDATE CON ESTO: Identificar los errores te permite proteger las dinámicas del sprint antes de comprometer la energía del grupo multidisciplinar. |
|
★ RECORDAR: Algunos de los errores más frecuentes son iniciar un Sprint sin un Decider disponible, permitir debates interminables, definir un reto demasiado amplio o desarrollar en exceso el prototipo. Todos ellos reducen la velocidad de aprendizaje. |
Módulo 15: Caso Práctico Completo
Desarrollo completo e integrado de un caso empresarial paso a paso.
15.1 El Reto y Contexto Comercial
Caso de estudio oficial: 'Una organización detecta que muchos usuarios abandonan el proceso de alta (registro) de su portal de soporte antes de finalizarlo.'
15.2 Secuencia Completa del Design Sprint Aplicado
- Día 1: Lunes - Definición de Meta y Preguntas del Sprint:
- Meta a largo plazo: Dentro de un año, el 90% de los clientes se darán de alta de forma autónoma y rápida.
- Preguntas del Sprint: ¿Podemos simplificar el registro sin comprometer la seguridad? ¿Comprenderán los usuarios por qué pedimos tanta información?
- Mapa: Cliente en Portal -> Clicks Registrar -> Formulario de 12 campos -> Verificación de correo -> Acceso al Portal. (Identificamos el cuello de botella en el Formulario).
- HMW: '¿Cómo podríamos hacer que el registro parezca rápido pero sea seguro?'
- Día 2: Martes - Soluciones e Ideación:
- Lightning Demos: Analizamos Airbnb (progressive disclosure) y Stripe (autocompletado inteligente).
- Crazy 8s: El equipo aboceta variaciones rápidas (ej. Login social, formulario interactivo de 1 solo campo por pantalla).
- Solution Sketch: Creación de bocetos detallados anónimos de un 'Asistente de registro progresivo en 3 pasos'.
- Día 3: Miércoles - Selección y Storyboard:
- Sticky Decision: Creamos el mapa de calor sobre los bocetos. El Decider coloca el Supervoto en el 'Asistente Progresivo con autocompletado por base de datos'.
- Storyboard: Dibujamos en la pizarra el recorrido exacto de 8 paneles que detalla cada pantalla del registro progresivo.
- Día 4: Jueves - Prototipado rápido:
- Makers diseñan las pantallas en Figma usando componentes interactivos. El Writer redacta textos aclaratorios de seguridad reales. El Stitcher enlaza las transiciones de los botones.
- Día 5: Viernes - Pruebas con Usuarios y Resultados:
- El Interviewer realiza la entrevista de 5 actos con 5 usuarios por videoconferencia. El equipo observa en silencio y anota.
- Patrones: 4 de los 5 usuarios completaron el onboarding de registro con facilidad en menos de un minuto, alabando la progressive disclosure. Sin embargo, 2 expresaron dudas sobre el paso de verificación de correo.
- Resultados: Validación Parcial del Sprint. El concepto es un éxito comercial rotundo. Se planifican los siguientes pasos iterativos: pulir la verificación de correo y transferir la iniciativa de inmediato al Backlog de Scrum en el Sprint 1.
|
★ QUÉDATE CON ESTO: El caso práctico muestra cómo se conecta todo el Design Sprint, desde el problema de abandono del cliente hasta una solución validada con un roadmap ágil claro. |
|
★ RECORDAR: Observa cómo cada resultado de una fase se convierte en la entrada de la siguiente: problema → alternativas → decisión → prototipo → evidencia → roadmap. |
Módulo 16: Repaso y Conceptos Fundamentales
Consolida los conceptos fundamentales del Design Sprint y aprende a distinguir ideas que suelen confundirse en la práctica.
16.1 Conceptos que Conviene Diferenciar
En el examen, es vital saber diferenciar conceptos similares de forma técnica:
- Design Sprint vs Design Thinking: Design Thinking es una filosofía de diseño amplia centrada en empatizar y co-crear a largo plazo, mientras que Design Sprint es un proceso ágil cerrado de 4 o 5 días para validar soluciones específicas.
- Prototipo vs MVP: El prototipo es una fachada interactiva rápida en 1 día, mientras que el MVP es un producto mínimo real con funcionalidad backend lanzado al mercado para obtener datos.
- Facilitador vs Decider: El Facilitador modera de forma neutral el proceso, mientras que el Decider tiene el peso absoluto de la toma de decisiones de negocio mediante el Supervoto.
- Divergencia vs Convergencia: Divergencia es idear de forma privada e individual (lunes-martes), convergencia es filtrar, votar y decidir de forma silenciosa y ejecutiva (miércoles).
- Hipótesis vs Suposición: Hipótesis es un planteamiento que se expone a validación empírica en el mercado real; suposición es un supuesto que se asume verdadero sin pruebas.
| ★ QUÉDATE CON ESTO: El secreto del examen radica en comprender la lógica de cada fase, el rol neutral del facilitador y el valor del aprendizaje rápido por encima de defender soluciones iniciales. |
| ★ RECUERDA: Memoriza las características del examen. Asegúrate de conocer las diferencias exactas de tiempos y preguntas entre el examen Open de 20 preguntas y el oficial de 40 preguntas. |
Módulo 17: El Design Sprint en 5 Días — Visión Global
Este módulo consolida todo lo aprendido mediante una visión completa del Design Sprint de principio a fin. Su objetivo es comprender cómo cada día cumple una función concreta, utiliza unas técnicas determinadas y genera un resultado que alimenta directamente la fase siguiente.
17.1 La Secuencia Completa del Design Sprint
El Design Sprint no es una colección independiente de dinámicas. Es una secuencia estructurada en la que cada fase reduce progresivamente la incertidumbre hasta llegar a una prueba real con usuarios.
Lunes — Comprender y Definir
El primer día está dedicado a comprender el problema antes de intentar resolverlo.
El equipo comienza definiendo el Objetivo a Largo Plazo, formulando las Preguntas del Sprint y construyendo un Mapa del Recorrido que permita visualizar actores, pasos y puntos de fricción.
Las entrevistas con expertos aportan información adicional y permiten transformar los problemas identificados en oportunidades mediante notas How Might We (HMW). Finalmente, las oportunidades se priorizan y el Decider selecciona el Target sobre el que trabajará el Sprint.
Técnicas principales: Objetivo a Largo Plazo, Sprint Questions, Mapa, entrevistas con expertos, HMW y selección del Target.
Resultado esperado: una meta clara y un punto concreto del recorrido del usuario sobre el que concentrar el Sprint.
La lógica fundamental del lunes es sencilla: no empieces a diseñar soluciones hasta comprender exactamente qué problema quieres resolver. El manual establece esta secuencia de Objetivo → Preguntas → Mapa → Expertos → HMW → votación → selección final del Decider.
Martes — Bocetar y Divergir
Una vez comprendido el problema, el equipo abre el espacio de soluciones.
La jornada comienza con los Lightning Demos, donde los participantes buscan referencias e inspiración en productos, competidores u otras industrias.
Después se inicia el proceso individual de bocetado mediante cuatro pasos consecutivos:
Notas → Ideas → Crazy 8s → Solution Sketch.
Crazy 8s obliga a generar ocho variaciones en ocho minutos, mientras que el Solution Sketch transforma las mejores ideas en un boceto detallado de tres paneles, anónimo y autoexplicativo.
Técnicas principales: Lightning Demos, Notas, Ideas, Crazy 8s y Solution Sketch.
Resultado esperado: varias propuestas de solución suficientemente detalladas para poder evaluarlas al día siguiente.
El objetivo del martes no es alcanzar consenso, sino generar alternativas de calidad evitando el pensamiento grupal.
Miércoles — Decidir y Converger
El miércoles el equipo deja de generar alternativas y comienza a reducirlas.
Los Solution Sketch se exponen de forma anónima mediante el Art Museum. A continuación se aplica el proceso de decisión estructurada:
Art Museum → Heat Map → Speed Critique → Straw Poll → Supervote.
El equipo aporta información mediante observación, comentarios y votaciones, pero la decisión final corresponde al Decider mediante el Supervote.
Una vez seleccionada la solución, se desarrolla el Storyboard, una secuencia detallada de aproximadamente 10 a 15 paneles que especifica exactamente la experiencia que se construirá y probará.
Técnicas principales: Sticky Decision, Heat Map, Speed Critique, Straw Poll, Supervote y Storyboard.
Resultado esperado: una única solución seleccionada y un blueprint suficientemente detallado para que el equipo pueda construir el prototipo sin volver a debatir el contenido.
La regla de oro es especialmente importante: durante el Storyboard no se introducen nuevas ideas. Solo se desarrolla aquello que ya ha sido seleccionado por el Decider.
Jueves — Prototipar y Construir
El jueves se transforma el Storyboard en una experiencia que parezca suficientemente real para poder probarla.
El objetivo no es desarrollar el producto definitivo ni escribir un backend funcional. Se aplica la filosofía Fake It: simular aquello que el usuario necesita ver y utilizar.
El prototipo debe alcanzar la denominada Goldilocks Quality: ni tan pobre que resulte poco creíble, ni tan desarrollado que requiera semanas de trabajo.
Para conseguirlo en un solo día, el equipo divide las tareas entre Makers, Stitcher, Writer, Asset Collector / Reviewer e Interviewer.
Técnicas principales: Divide y vencerás, herramientas de prototipado rápido, Fake It y Goldilocks Quality.
Resultado esperado: un prototipo interactivo, realista y desechable preparado para ser probado con usuarios reales.
La pregunta correcta del jueves no es «¿cómo construimos el producto?», sino «¿qué necesitamos simular para poder aprender mañana?».
Viernes — Validar y Aprender
El viernes el prototipo abandona la sala del equipo y se enfrenta a usuarios reales.
Se realizan sesiones individuales con 5 usuarios, siguiendo la estructura de la Entrevista de 5 Actos:
Bienvenida → Contexto → Presentación → Tareas / Pensar en voz alta → Cierre.
Mientras el Interviewer conduce cada sesión, el resto del equipo observa y registra comportamientos, dificultades, reacciones y comentarios.
Al finalizar las entrevistas se buscan patrones repetidos, evitando conceder demasiado peso a opiniones aisladas.
Técnicas principales: regla de los 5 usuarios, entrevista de 5 actos, observación individual y análisis de patrones.
Resultado esperado: evidencia suficiente para determinar si la hipótesis queda validada, parcialmente validada, rechazada o necesita más investigación.
Validar no significa conseguir que el usuario confirme nuestra idea. Significa observar objetivamente cómo se comporta ante ella.
17.2 La Lógica que Conecta los Cinco Días
El Design Sprint sigue una progresión deliberada:
Comprender → Divergir → Converger → Prototipar → Validar
El lunes reduce la ambigüedad del problema.
El martes amplía el número de posibles soluciones.
El miércoles reduce esas alternativas hasta seleccionar una.
El jueves convierte esa decisión en una experiencia tangible.
El viernes sustituye las opiniones internas por evidencia procedente de usuarios reales.
Por eso alterar el orden de las fases rompe parte de la lógica del método. No tiene sentido prototipar antes de decidir, decidir antes de comprender o validar una solución que todavía no ha sido suficientemente definida.
El verdadero producto del Design Sprint no es el prototipo. Es el aprendizaje obtenido antes de realizar una inversión mayor.
17.3 Después del Viernes
La validación no implica necesariamente que el trabajo haya terminado.
Una hipótesis totalmente validada puede transferirse al Product Backlog para iniciar su desarrollo.
Una validación parcial puede requerir una nueva iteración corta.
Una hipótesis rechazada representa un fracaso eficiente: se ha descubierto rápidamente que la solución no merece una inversión mayor.
En Design Sprint, descubrir pronto que una idea no funciona puede tener tanto valor empresarial como confirmar que funciona. El manual resume esta filosofía indicando que no existe fracaso cuando existe aprendizaje y que las ideas validadas pueden transferirse posteriormente al Backlog de Scrum.
| ★ QUÉDATE CON ESTO: Cada día del Design Sprint responde a una pregunta diferente: el lunes entendemos dónde actuar, el martes exploramos cómo resolverlo, el miércoles decidimos qué probar, el jueves simulamos la solución y el viernes aprendemos de usuarios reales. Cada fase produce el input que necesita la siguiente. |
| ★ RECORDAR: Memoriza la relación día → fase → técnicas → resultado. Lunes: comprender y definir. Martes: divergir y bocetar. Miércoles: converger, decidir y construir el Storyboard. Jueves: prototipar mediante Fake It y Goldilocks Quality. Viernes: validar con 5 usuarios, observar patrones y obtener evidencia. No memorices las técnicas como elementos aislados: recuerda en qué momento aparecen y qué resultado debe producir cada una |
Módulo 18: Secuencias Clave del Design Sprint
Cuatro procesos que conviene poder reconstruir de principio a fin.
Este módulo consolida las secuencias operativas más importantes del Design Sprint. Muchas preguntas de certificación presentan actividades correctas, pero situadas en un orden incorrecto. Por este motivo, no basta con reconocer una técnica: es necesario saber qué ocurre antes, qué ocurre después y qué resultado debe producir cada fase.
El objetivo de este módulo es fijar cuatro secuencias especialmente relevantes: el proceso de bocetado, la Sticky Decision, la entrevista con usuarios y el recorrido completo de los cinco días.
18.1 El Proceso de Boceto de 4 Pasos
La generación de soluciones del martes no comienza directamente con Crazy 8s ni termina con una votación. Sigue una secuencia concreta destinada a pasar progresivamente de la información disponible a una propuesta suficientemente detallada.
El orden correcto es:
Notas → Ideas → Crazy 8s → Solution Sketch
Paso 1 — Notas
Cada participante revisa de forma silenciosa la información recopilada durante las fases anteriores: mapas, notas HMW, entrevistas con expertos y referencias obtenidas mediante los Lightning Demos.
El objetivo no es generar todavía una solución definitiva, sino recuperar la información relevante que puede servir de inspiración.
Paso 2 — Ideas
Los participantes comienzan a transformar las notas en dibujos, esquemas, conceptos y garabatos.
Aquí todavía no importa la calidad gráfica ni desarrollar completamente la propuesta. Se pretende externalizar rápidamente diferentes posibilidades antes de entrar en una fase más exigente de generación de alternativas.
Paso 3 — Crazy 8s
Crazy 8s fuerza la divergencia mediante una restricción muy concreta:
8 ideas en 8 minutos.
El papel se divide en ocho espacios y se dedica aproximadamente un minuto a cada variación.
El propósito no es producir ocho soluciones perfectas, sino impedir que el participante se quede únicamente con su primera idea y obligarlo a explorar alternativas. El manual establece expresamente esta secuencia de Notas, Ideas, Crazy 8s y Solution Sketch.
Paso 4 — Solution Sketch
Finalmente, cada participante convierte su propuesta más prometedora en un Boceto de Solución detallado.
El Solution Sketch debe ser:
anónimo, autoexplicativo y suficientemente detallado, normalmente mediante tres paneles que permitan comprender la propuesta sin que su autor tenga que defenderla personalmente.
La lógica es importante: primero se comprende la información, después se generan conceptos, se fuerzan alternativas y finalmente se desarrolla una propuesta concreta.
| ★ QUÉDATE CON ESTO: El proceso de boceto va de lo general a lo concreto: Notas → Ideas → Crazy 8s → Solution Sketch. Crazy 8s genera alternativas; el Solution Sketch convierte una de ellas en una propuesta evaluable. |
| ★ RECORDAR: Si una respuesta coloca Crazy 8s antes de Ideas o el Solution Sketch antes de Crazy 8s, la secuencia es incorrecta. |
18.2 La Secuencia de Sticky Decision
El miércoles comienza la convergencia. Las propuestas ya existen y el equipo debe analizarlas sin caer en discusiones interminables.
La secuencia correcta es:
Art Museum → Heat Map → Speed Critique → Straw Poll → Supervote
Paso 1 — Art Museum
Los Solution Sketch se exponen de forma anónima, como si se tratara de una galería.
El anonimato reduce el efecto de la jerarquía, la capacidad de persuasión de cada autor y otros sesgos personales.
Paso 2 — Heat Map
Los participantes revisan individualmente las propuestas y colocan pequeños stickers sobre aquellas partes concretas que consideran especialmente interesantes.
Todavía no se está seleccionando una solución completa.
Se están haciendo visibles las zonas que generan mayor interés.
Paso 3 — Speed Critique
El Facilitador recorre los bocetos y explica las partes señaladas por el equipo.
La revisión se realiza rápidamente y de forma estructurada, evitando convertir cada propuesta en un debate abierto.
Paso 4 — Straw Poll
Cada participante realiza una votación informal sobre la solución completa que considera más prometedora.
El Straw Poll aporta información al Decider, pero no determina la decisión final.
Paso 5 — Supervote
El Decider utiliza el Supervote para seleccionar definitivamente qué solución o qué elementos se llevarán al prototipo.
El manual establece expresamente que el orden es Art Museum, Heat Map, Speed Critique, Straw Poll y finalmente Supervote del Decider.
| ★ QUÉDATE CON ESTO: El equipo observa, destaca, analiza y recomienda. El Decider decide. |
| ★ RECORDAR: Una de las trampas más sencillas consiste en intercambiar Heat Map y Speed Critique o presentar el Straw Poll como decisión definitiva. Recuerda: Straw Poll orienta; Supervote decide. |
18.3 La Entrevista de 5 Actos
El viernes cambia completamente el foco. El equipo deja de discutir internamente y observa cómo reaccionan usuarios reales ante el prototipo.
La entrevista sigue cinco actos:
Bienvenida → Contexto → Presentación → Tareas / Pensar en voz alta → Cierre
Acto 1 — Bienvenida
El Interviewer crea un ambiente cómodo, explica cómo funcionará la sesión y reduce cualquier sensación de estar siendo evaluado.
La persona que se prueba es el prototipo, no el usuario.
Acto 2 — Contexto
Antes de enseñar la solución se realizan preguntas sobre hábitos, necesidades, experiencias y comportamientos relacionados con el problema.
Esto permite interpretar posteriormente las reacciones del usuario dentro de su contexto real.
Acto 3 — Presentación del prototipo
Se muestra el prototipo dejando claro que es una simulación reciente y que puede contener errores.
Esta explicación ayuda a que la persona entrevistada se sienta libre para señalar problemas y comportarse con naturalidad.
Acto 4 — Tareas y pensamiento en voz alta
El usuario recibe situaciones o tareas concretas y debe interactuar con el prototipo de manera autónoma.
El Interviewer anima a pensar en voz alta, pero evita conducirlo hacia la respuesta correcta.
Acto 5 — Cierre o Debriefing
La sesión termina con preguntas abiertas destinadas a recoger impresiones, emociones y valoraciones generales.
El objetivo no es conseguir una aprobación final del concepto, sino complementar la observación realizada durante las tareas.
El manual fija esta secuencia como Bienvenida, Contexto, Presentación, Tareas/Pensar en voz alta y Cierre.
| ★ QUÉDATE CON ESTO: La entrevista empieza entendiendo a la persona, después presenta el prototipo, observa su comportamiento y finalmente recoge impresiones. |
| ★ RECORDAR: No empieces mostrando el prototipo. Primero Bienvenida y Contexto. Tampoco confundas la entrevista con una presentación comercial: el Interviewer debe observar, no convencer. |
18.4 La Secuencia Global de los 5 Días
Además de las dinámicas concretas, es fundamental recordar la lógica completa del Design Sprint:
Lunes → Martes → Miércoles → Jueves → Viernes
Y asociar cada día con su función principal.
Lunes — Comprender / Definir
Se comprende el problema, se construye el mapa, se generan HMW y se determina el Target.
Resultado: Meta y Target del Sprint.
Martes — Bocetar / Divergir
Se buscan referencias y se generan propuestas mediante Lightning Demos, Crazy 8s y Solution Sketch.
Resultado: bocetos detallados de solución.
Miércoles — Decidir / Converger
Se ejecuta la Sticky Decision, el Decider realiza el Supervote y se construye el Storyboard.
Resultado: Storyboard que actuará como blueprint del prototipo.
Jueves — Prototipar / Construir
El equipo utiliza Fake It y Goldilocks Quality para crear una simulación creíble en un solo día.
Resultado: prototipo interactivo preparado para ser probado.
Viernes — Validar / Probar
Se realizan las entrevistas con usuarios, se observan comportamientos y se buscan patrones.
Resultado: validación, validación parcial o fracaso eficiente de la hipótesis.
Esta relación entre día, fase, técnicas y resultado aparece resumida expresamente en la Chuleta de Repaso Rápido del manual.
La lógica puede resumirse así:
Comprender → Divergir → Converger → Prototipar → Validar
Cada fase prepara la siguiente. Saltarse una de ellas o alterar su posición cambia la naturaleza del proceso.
18.5 Cómo Resolver Preguntas de Secuencia al aplicar el método
Cuando una pregunta presente varias actividades del Design Sprint y las respuestas parezcan casi idénticas, no intentes recordar únicamente la frase exacta del manual.
Reconstruye mentalmente qué está ocurriendo.
Primero identifica la fase. Después determina si el equipo está comprendiendo, generando alternativas, seleccionando, construyendo o validando. Finalmente, comprueba si las técnicas propuestas respetan la lógica temporal de esa fase.
Por ejemplo, si aparece un Supervote antes del Heat Map, la respuesta es incorrecta aunque todos los términos sean técnicas reales del Design Sprint.
Del mismo modo, si una opción sitúa el Solution Sketch antes de Crazy 8s, o presenta el prototipo antes de las preguntas de contexto de una entrevista, la secuencia tampoco es correcta.
La certificación no evalúa únicamente vocabulario. Evalúa que el candidato comprenda cómo funciona el método como sistema.
| ★ QUÉDATE CON ESTO: Memorizar una técnica sin saber dónde encaja tiene poco valor. Las cuatro secuencias que debes poder reconstruir sin dudar son: Boceto de 4 pasos, Sticky Decision, Entrevista de 5 actos y los 5 días completos del Design Sprint. |
| ★ RECORDAR: Si dudas entre dos respuestas, reconstruye el proceso desde el principio. Pregúntate: ¿qué debería haber ocurrido antes para que este paso tenga sentido? En muchas preguntas, esa lógica permite eliminar rápidamente las opciones incorrectas. |
Módulo 19: Roles del Design Sprint de un Vistazo
Este módulo consolida los principales roles que intervienen en un Design Sprint y aclara quién hace qué, quién decide y qué responsabilidades no deben confundirse.
El Design Sprint funciona mediante una separación deliberada de responsabilidades. Algunas personas protegen el proceso, otras aportan conocimiento, otras construyen el prototipo y una persona concreta dispone de la autoridad necesaria para tomar las decisiones finales.
Entender esta distribución es especialmente importante para Design Sprint, porque muchas preguntas presentan responsabilidades correctas asignadas al rol equivocado.
19.1 Roles de Dirección: Facilitador y Decider
Los dos roles más importantes desde el punto de vista de gobierno del Sprint son el Facilitador y el Decider.
Ambos poseen autoridad, pero sobre ámbitos diferentes.
Facilitador
El Facilitador es el responsable del proceso.
Su trabajo consiste en asegurar que las dinámicas se ejecutan correctamente, mantener el ritmo del grupo y proteger el timeboxing. También controla la agenda, modera las discusiones y gestiona la energía del equipo.
Su característica fundamental es la neutralidad.
El Facilitador puede decidir cómo ejecutar una dinámica, cuándo termina un timebox o cómo reconducir una discusión, pero no decide qué solución de diseño o de negocio es mejor.
El manual establece expresamente que no toma decisiones de contenido.
Sus responsabilidades principales son:
- asegurar el cumplimiento de las dinámicas;
- controlar el tiempo;
- mantener la agenda;
- moderar conversaciones;
- proteger las reglas del Sprint;
- facilitar la participación del equipo.
La frontera debe ser clara:
Facilitador = proceso.
No debe aprovechar su posición para imponer una solución, defender una propuesta o condicionar al equipo hacia una decisión concreta.
Decider
El Decider es el responsable de las decisiones finales de negocio y de contenido.
Suele ser una persona con autoridad suficiente para resolver bloqueos y decidir qué dirección debe seguir el equipo: Product Owner, gerente, directivo o responsable con capacidad real de decisión.
Su participación es obligatoria.
Cuando existen varias alternativas y el equipo necesita cerrar una decisión, el Decider dispone de la última palabra mediante el Supervote.
La frontera en este caso es:
Decider = decisión.
La diferencia entre ambos roles es uno de los conceptos centrales del método:
Facilitador → controla proceso, agenda y timeboxing.
Decider → controla contenido, prioridades y dirección.
El Facilitador debe permanecer neutral; el Decider no tiene por qué ser neutral, porque representa las prioridades y la estrategia del negocio.
| ★ QUÉDATE CON ESTO: El Facilitador tiene autoridad sobre cómo funciona el Sprint. El Decider tiene autoridad sobre qué decisión toma el Sprint. Confundir ambos papeles rompe la separación entre facilitación y decisión. |
| ★ PARA EL EXAMEN: Pregunta recurrente: ¿quién decide la solución final? El Decider. ¿Quién protege las dinámicas, el tiempo y la agenda? El Facilitador. |
19.2 Roles del Equipo de Prototipado
El jueves el Sprint cambia de naturaleza.
Ya no se está explorando el problema ni seleccionando soluciones. El Storyboard está cerrado y el objetivo consiste en transformar rápidamente esa especificación en una experiencia suficientemente realista para poder probarla al día siguiente.
Para conseguirlo en una sola jornada se aplica el principio de Divide y Vencerás, distribuyendo responsabilidades entre varios perfiles.
Makers
Los Makers o Hacedores son quienes construyen las diferentes partes visuales del prototipo.
Normalmente son diseñadores o ingenieros y pueden trabajar con herramientas como Figma, PowerPoint o Keynote.
Su objetivo no es desarrollar software real, sino producir rápidamente las pantallas y elementos necesarios para simular la experiencia definida en el Storyboard.
El equipo suele contar con dos o tres Makers trabajando en paralelo.
Por tanto:
Makers = construir las piezas del prototipo.
No deben reabrir la discusión sobre qué solución construir. Esa decisión ya se tomó el miércoles y está documentada mediante el Storyboard.
Stitcher
El Stitcher es la persona responsable de unir las piezas desarrolladas por los Makers.
Cuando varias personas construyen simultáneamente distintas pantallas o partes del flujo existe el riesgo de terminar con elementos visualmente incoherentes o con transiciones que no encajan.
El Stitcher evita ese problema.
Su responsabilidad es asegurar:
- coherencia entre pantallas;
- consistencia visual;
- funcionamiento de botones y enlaces;
- continuidad del flujo;
- uniformidad de fuentes y elementos.
El manual define expresamente al Stitcher como quien une las partes creadas por los Makers para asegurar la consistencia del flujo, botones interactivos y fuentes.
En términos sencillos:
Makers construyen las piezas.
Stitcher convierte las piezas en una experiencia única.
Writer
El Writer es responsable del contenido textual del prototipo.
Su participación puede parecer secundaria, pero resulta crítica para conseguir el nivel de realismo necesario durante las pruebas.
Debe redactar textos realistas e informativos: botones, mensajes, instrucciones, explicaciones y cualquier otro contenido que el usuario encontrará durante la experiencia.
El manual advierte específicamente contra el uso de Lorem Ipsum, porque un texto ficticio destruye parte del realismo que necesita el prototipo.
Por tanto:
Writer = contenido realista y comprensible.
En Goldilocks Quality no basta con que las pantallas parezcan reales. También deben leerse como si fueran reales.
Asset Collector / Reviewer
El Asset Collector / Reviewer proporciona los recursos que necesitan los Makers para mantener la velocidad de construcción.
Busca y recopila:
- imágenes;
- logotipos;
- iconos;
- referencias visuales;
- otros elementos gráficos necesarios.
Su función evita que los Makers interrumpan constantemente su trabajo para buscar materiales.
La lógica vuelve a ser la misma: repartir tareas para permitir que varias actividades se desarrollen simultáneamente.
Asset Collector = suministrar recursos para que los Makers puedan seguir construyendo.
19.3 El Interviewer: Preparar la Validación
Mientras buena parte del equipo está concentrada en construir el prototipo, el Interviewer comienza a preparar lo que ocurrirá el viernes.
Su misión principal durante el jueves es desarrollar la guía de entrevista y preparar las pruebas con usuarios.
Al final del día trabaja junto al Stitcher para comprobar que el prototipo funciona correctamente antes de exponerlo a personas reales.
El viernes su papel pasa a primer plano.
El Interviewer conduce las sesiones con los usuarios siguiendo la Entrevista de 5 Actos:
Bienvenida → Contexto → Presentación → Tareas/Pensar en voz alta → Cierre.
Durante la prueba debe mantener una actitud abierta y evitar guiar al usuario hacia la respuesta que el equipo desea obtener.
Por tanto:
Interviewer = preparar y conducir la validación.
Su objetivo no es vender el prototipo ni defender la solución.
Debe permitir que el comportamiento de los usuarios genere la evidencia.
19.4 Cómo Encajan los Roles
Los roles no son puestos jerárquicos aislados. Forman un sistema de responsabilidades complementarias.
Podemos resumirlo así:
Facilitador → protege el proceso.
Decider → toma las decisiones finales.
Makers → construyen las pantallas y elementos.
Stitcher → integra las piezas y protege la consistencia.
Writer → crea los textos realistas.
Asset Collector / Reviewer → proporciona los recursos visuales.
Interviewer → prepara y conduce la validación.
Esta distribución permite mantener una de las características esenciales del Design Sprint: trabajar rápidamente sin que todas las personas intenten hacer todas las cosas al mismo tiempo.
El jueves resulta especialmente representativo.
Mientras los Makers construyen, el Writer redacta, el Asset Collector busca materiales, el Stitcher integra y el Interviewer prepara el viernes.
No se trabaja de manera secuencial.
Se trabaja en paralelo sobre responsabilidades claramente diferenciadas.
El manual identifica precisamente estos roles como parte del reparto de tareas necesario para conseguir un prototipo en un solo día.
19.5 El Error de Confundir Responsabilidad con Poder
Una fuente habitual de errores consiste en pensar que quien facilita también decide o que quien construye puede modificar libremente la solución.
No es así.
La responsabilidad de cada rol está limitada por la fase y por el objetivo del Sprint.
El Facilitador tiene poder sobre las dinámicas, pero no sobre la solución.
El Decider tiene poder sobre las decisiones de negocio, pero debe respetar el funcionamiento y los timeboxes del proceso.
Los Makers tienen capacidad para construir el prototipo, pero trabajan a partir de un Storyboard ya decidido.
El Interviewer dirige la conversación con el usuario, pero no debe conducirlo hacia una determinada respuesta.
Esta separación evita que la autoridad formal, la capacidad de persuasión o el conocimiento técnico sustituyan al proceso estructurado.
| ★ QUÉDATE CON ESTO: Cada rol protege una parte distinta del Design Sprint. Facilitador = proceso. Decider = decisión. Makers + Stitcher + Writer + Asset Collector = construcción del prototipo. Interviewer = validación. La velocidad aparece cuando las responsabilidades están claras y pueden ejecutarse en paralelo. |
| ★ RECORDAR: Memoriza especialmente tres asociaciones: Facilitador → proceso y neutralidad; Decider → decisión final y Supervote; Interviewer → entrevista y validación. En el equipo de prototipado recuerda también las funciones de Makers, Stitcher, Writer e Interviewer, que el propio manual señala como conceptos que pueden aparecer en la evaluación. |
Módulo 20: Diez Errores y Confusiones Habituales en Design Sprint
Este módulo reúne algunos de los errores de interpretación más fáciles de cometer durante la certificación DSPC™.
El examen no se limita a preguntar definiciones. Con frecuencia presenta roles, técnicas o conceptos reales combinados de una forma incorrecta, de modo que varias respuestas pueden parecer razonables a primera vista.
La clave consiste en reconocer la regla exacta del Design Sprint, identificar en qué fase ocurre una actividad y distinguir responsabilidades que pueden parecer similares, pero que no son equivalentes.
20.1 Facilitador no es Decider
Una de las confusiones más importantes del examen consiste en atribuir al Facilitador la capacidad de decidir qué solución debe construirse.
El Facilitador controla el proceso:
- agenda;
- dinámicas;
- timeboxing;
- participación;
- energía del equipo.
Debe mantener una posición neutral respecto al contenido.
El Decider, en cambio, controla las decisiones de negocio, las prioridades y la elección final de la solución mediante el Supervote.
Por tanto:
Facilitador = proceso.
Decider = decisión.
Confusión habitual
Una respuesta afirma que el Facilitador debe resolver una discusión escogiendo la mejor propuesta.
Es incorrecto.
Si la discusión no puede resolverse mediante la dinámica prevista, el Facilitador debe proteger el proceso y recurrir al Decider.
20.2 Straw Poll no es Supervote
Durante la Sticky Decision aparecen dos votaciones diferentes que pueden confundirse fácilmente.
El Straw Poll es una votación informal realizada por los participantes para indicar qué propuesta consideran más prometedora.
Aporta información.
No decide.
El Supervote pertenece al Decider y tiene peso absoluto sobre la decisión final.
La relación correcta es:
Straw Poll → orienta.
Supervote → decide.
Trampa habitual
La pregunta indica que la solución con más votos del equipo se convierte automáticamente en la elegida.
Incorrecto.
La votación colectiva informa al Decider, pero la responsabilidad final continúa siendo suya.
20.3 Prototipo no es MVP
Otro concepto fundamental de la certificación consiste en diferenciar claramente:
Prototipo → MVP → Producto terminado.
El prototipo del Design Sprint es una fachada interactiva construida rápidamente para aprender.
No necesita backend real, no debe ser escalable y puede desecharse después de la prueba.
El MVP, por el contrario, es un producto mínimo pero real y funcional, lanzado al mercado para recopilar datos.
El producto terminado añade robustez, seguridad y escalabilidad.
Trampa habitual
Una respuesta indica que el jueves debe desarrollarse una versión funcional mínima con backend.
Eso describe un MVP, no el prototipo del Design Sprint.
20.4 Storyboard no significa volver a idear
Cuando el Decider ya ha utilizado el Supervote, la solución está seleccionada.
El Storyboard no sirve para volver a abrir el debate.
Su objetivo es convertir esa decisión en una secuencia suficientemente detallada para que el equipo pueda construir el prototipo al día siguiente.
El manual establece una regla explícita:
no introducir ideas nuevas durante el Storyboard.
Trampa habitual
Una opción propone aprovechar la creación del Storyboard para incorporar nuevas funcionalidades sugeridas por el equipo.
Incorrecto.
Si una idea no fue seleccionada durante la fase de decisión, no debería aparecer improvisadamente en el Storyboard.
Storyboard = documentar la decisión.
No = reabrir la ideación.
20.5 Divergir no significa debatir en grupo
La divergencia busca generar alternativas.
Pero Design Sprint evita deliberadamente buena parte del brainstorming abierto porque puede favorecer:
- pensamiento grupal;
- perfiles dominantes;
- presión jerárquica;
- autocensura.
Durante la divergencia los participantes trabajan principalmente de forma individual y silenciosa, generando alternativas antes de compartirlas.
El manual diferencia claramente divergencia y convergencia:
Divergencia → generar alternativas.
Convergencia → filtrar, votar y decidir.
Trampa habitual
La respuesta describe la divergencia como una gran sesión de brainstorming en la que todos construyen verbalmente una única idea.
No corresponde al principio de “trabajar individualmente, juntos”.
20.6 La Sticky Decision tiene un orden concreto
No basta con reconocer los nombres de las técnicas.
Hay que recordar su secuencia:
Art Museum → Heat Map → Speed Critique → Straw Poll → Supervote
Cada paso prepara el siguiente.
Primero se presentan los bocetos.
Después se indican silenciosamente las zonas interesantes.
Luego se explican rápidamente.
A continuación el equipo expresa su preferencia.
Finalmente decide el Decider.
Trampa habitual
Dos respuestas contienen exactamente las mismas cinco técnicas, pero intercambian Heat Map y Speed Critique.
Solo una es correcta.
Este tipo de pregunta comprueba si el candidato conoce el proceso, no simplemente el vocabulario.
20.7 Validar no significa buscar aprobación
El viernes no se intenta demostrar que la solución era correcta.
Se intenta descubrir qué ocurre cuando una persona real interactúa con ella.
El Interviewer debe mantener una actitud amigable y abierta, evitando conducir al usuario hacia determinada respuesta.
El equipo observa comportamientos y busca posteriormente patrones comunes entre las entrevistas.
El propio manual lo resume claramente: validar no significa conseguir que el usuario confirme nuestra idea inicial.
Trampa habitual
Una respuesta propone explicar al usuario las ventajas del diseño cuando muestra dificultades para que comprenda correctamente la solución.
Eso contamina la prueba.
El comportamiento correcto es observar, no enseñar al usuario cómo debería utilizar el prototipo.
20.8 La referencia es 5 usuarios
El modelo descrito en el manual utiliza 5 usuarios reales en sesiones individuales 1:1.
La finalidad no es realizar una investigación estadística masiva, sino encontrar rápidamente patrones de usabilidad y comportamiento.
El manual señala además que aumentar considerablemente el número de participantes genera rendimientos decrecientes.
Trampa habitual
Una respuesta propone entrevistar 15 o 20 personas porque una muestra mayor siempre proporciona resultados mejores.
Dentro del planteamiento DSPC del manual, esa no es la lógica buscada.
El Design Sprint prioriza:
velocidad + evidencia suficiente para decidir.
No intenta realizar un estudio cuantitativo exhaustivo.
20.9 Goldilocks Quality no significa máximo realismo técnico
El prototipo debe parecer suficientemente real para provocar una reacción natural del usuario.
Pero eso no significa construir un producto prácticamente terminado.
La Goldilocks Quality busca un punto intermedio:
ni demasiado tosco → ni demasiado desarrollado.
Un prototipo excesivamente pobre puede hacer que el usuario critique únicamente la apariencia.
Uno excesivamente desarrollado consume tiempo, genera apego a la solución y contradice la lógica de aprendizaje rápido.
Por eso se combina con la filosofía Fake It: simular una experiencia creíble sin construir el backend real.
Trampa habitual
Una respuesta afirma que un prototipo de mayor calidad siempre es preferible.
No necesariamente.
La calidad correcta es la mínima suficiente para obtener una respuesta válida del usuario.
20.10 Fracaso eficiente no significa Sprint fallido
Una hipótesis puede quedar:
- validada;
- parcialmente validada;
- rechazada;
- o producir resultados no concluyentes.
Que los usuarios rechacen una solución no significa automáticamente que el Design Sprint haya fracasado.
Si la prueba permite descubrir antes del desarrollo que una idea no funciona, la empresa ha evitado invertir tiempo y dinero en una dirección equivocada.
El manual denomina este resultado fracaso eficiente y lo considera un excelente resultado preventivo de negocio.
Trampa habitual
Una pregunta presenta una hipótesis rechazada por los cinco usuarios y pregunta si debe considerarse que el Design Sprint no produjo valor.
Incorrecto.
Produjo precisamente aquello para lo que fue diseñado:
aprendizaje antes de realizar una inversión mayor.
20.11 Cómo Evitar Estas Confusiones
Cuando dos opciones parezcan válidas, utiliza cuatro comprobaciones.
1. Pregunta quién tiene esa responsabilidad
¿La acción corresponde al Facilitador o al Decider?
¿Al Maker o al Interviewer?
Una responsabilidad correcta atribuida al rol equivocado convierte la respuesta en incorrecta.
2. Comprueba el momento del Sprint
Pregúntate:
¿en qué día estamos?
Si aparece un Supervote el martes o Crazy 8s el viernes, algo no encaja.
3. Reconstruye la secuencia
En procesos estructurados como Sticky Decision, Solution Sketch o la entrevista de 5 actos, comprueba el orden.
Una técnica correcta colocada en una posición incorrecta puede ser el distractor.
4. Busca la opción que protege el aprendizaje
Cuando dudes entre desarrollar más, debatir más o obtener evidencia antes, la lógica del Design Sprint normalmente favorecerá:
reducir incertidumbre, proteger el timeboxing y aprender antes de construir.
La preparación para la certificación insiste precisamente en comprender la lógica de las fases, la neutralidad del Facilitador y el aprendizaje rápido por encima de defender la solución inicial.
| ★ QUÉDATE CON ESTO:Las respuestas trampa suelen ser técnicamente plausibles. El error aparece al cambiar quién decide, cuándo ocurre una actividad, en qué orden se realiza o cuál es el objetivo real de la técnica. No respondas por intuición: reconstruye el método |
| ★ RECORDAR: Las respuestas trampa suelen ser técnicamente plausibles. El error aparece al cambiar quién decide, cuándo ocurre una actividad, en qué orden se realiza o cuál es el objetivo real de la técnica. No respondas por intuición: reconstruye el método |
Módulo 21: Glosario Visual DSPC™
Este módulo reúne los términos que conviene reconocer de forma inmediata durante la preparación para la certificación DSPC™.
El objetivo no es memorizar definiciones extensas, sino comprender qué significa cada concepto, en qué momento del Design Sprint aparece y qué función cumple dentro del método.
Buena parte de las preguntas del examen utilizan terminología correcta para construir respuestas incorrectas. Por eso es importante no limitarse a reconocer una palabra: hay que saber qué papel desempeña y con qué otros conceptos se relaciona.
El propio manual incluye un glosario específico con algunos de los términos de mayor importancia para el examen, entre ellos Solution Sketch, Crazy 8s, Decider, Design Spike, Facilitador, HMW, Heat Map y Supervote.
21.1 How Might We — HMW
How Might We (HMW), traducido habitualmente como “¿Cómo podríamos...?”, es una técnica para transformar problemas, dificultades o puntos de fricción en oportunidades de diseño.
Durante las entrevistas con expertos, los participantes escuchan información relevante y convierten los problemas detectados en preguntas abiertas.
Por ejemplo:
Problema: muchos usuarios abandonan un formulario demasiado largo.
HMW:
¿Cómo podríamos hacer que el proceso de registro parezca más rápido sin comprometer la seguridad?
La estructura evita plantear directamente una solución.
El objetivo es abrir un espacio de posibilidades.
En el manual, las notas HMW se agrupan posteriormente por temas y se votan para identificar las oportunidades de mayor impacto. Después, el Decider selecciona el Target sobre el que trabajará el Sprint.
Idea rápida:
HMW = convertir problemas en oportunidades.
21.2 Crazy 8s
Crazy 8s es una técnica de ideación rápida e individual.
Cada participante divide una hoja en ocho espacios y desarrolla:
8 variaciones de una idea en 8 minutos.
El tiempo limitado obliga a abandonar rápidamente la primera solución evidente y explorar alternativas.
No se busca calidad artística.
Tampoco se espera que las ocho propuestas sean completas.
El objetivo es forzar divergencia y pensamiento lateral antes de seleccionar una dirección prometedora.
Crazy 8s forma parte del proceso de boceto de cuatro pasos:
Notas → Ideas → Crazy 8s → Solution Sketch.
Idea rápida:
Crazy 8s = 8 ideas · 8 minutos.
21.3 Solution Sketch — Boceto de Solución
El Solution Sketch es el resultado final del proceso individual de bocetado.
Consiste en un boceto detallado, normalmente formado por tres paneles, que explica visualmente cómo funcionaría una propuesta.
Debe ser:
- anónimo;
- autoexplicativo;
- suficientemente detallado;
- comprensible sin que el autor tenga que defenderlo verbalmente.
Esta última característica es importante.
El equipo debe poder analizar una propuesta por su contenido, no por la capacidad de persuasión, jerarquía o personalidad de quien la creó.
El manual identifica expresamente el Solution Sketch como un dibujo detallado de tres paneles, individual, anónimo y autoexplicativo.
Idea rápida:
Solution Sketch = propuesta detallada que puede entenderse sola.
21.4 Heat Map — Mapa de Calor
El Heat Map forma parte de la Sticky Decision del miércoles.
Los Solution Sketch se exponen de forma anónima mediante el Art Museum y los participantes los revisan en silencio.
Cada persona coloca pequeños stickers sobre aquellas partes concretas de los bocetos que considera especialmente interesantes.
La acumulación de puntos genera visualmente zonas de mayor interés.
El Heat Map no selecciona todavía una solución completa.
Simplemente muestra qué elementos llaman especialmente la atención del equipo.
Idea rápida:
Heat Map = destacar silenciosamente partes interesantes.
21.5 Supervote — Supervoto
El Supervote es la herramienta de decisión final del Decider.
Después de que el equipo haya revisado las propuestas mediante:
Art Museum → Heat Map → Speed Critique → Straw Poll
el Decider utiliza sus votos especiales para seleccionar qué propuesta o qué elementos se convertirán en el prototipo.
Los Supervotes tienen peso absoluto dentro de la decisión.
Por eso no deben confundirse con los votos informales del equipo.
Idea rápida:
Straw Poll orienta.
Supervote decide.
21.6 Decider — Definidor
El Decider es la persona con autoridad suficiente para tomar las decisiones finales del Sprint.
Puede ser, por ejemplo:
- Product Owner;
- gerente;
- directivo;
- responsable de negocio;
- persona con capacidad real para asumir la decisión.
Su misión principal es evitar que el equipo quede bloqueado cuando varias alternativas parecen igualmente válidas.
El Decider proporciona dirección, resuelve bloqueos y utiliza el Supervote para seleccionar la solución final.
Su participación es obligatoria.
La diferencia fundamental es:
Facilitador = proceso.
Decider = contenido y decisión.
Idea rápida:
Decider = última palabra.
21.7 Facilitador
El Facilitador es el responsable de que el Design Sprint funcione como proceso.
Sus responsabilidades incluyen:
- controlar la agenda;
- proteger los timeboxes;
- explicar las dinámicas;
- gestionar la energía;
- moderar discusiones;
- mantener la participación;
- asegurar el cumplimiento de las reglas.
Pero existe una frontera fundamental:
el Facilitador no toma decisiones de contenido.
Debe mantenerse neutral respecto a las soluciones propuestas.
Si aparece un conflicto que el equipo no puede resolver, el Facilitador no escoge la solución.
Recurre al Decider.
Idea rápida:
Facilitador = lidera el proceso, no la solución.
21.8 Design Spike
Un Design Spike es una práctica utilizada dentro de contextos Agile o Scrum para explorar rápidamente una cuestión incierta del backlog.
Cuando existe una duda suficientemente importante sobre:
- experiencia de usuario;
- viabilidad;
- solución;
- arquitectura conceptual;
- comportamiento del cliente;
puede dedicarse un espacio específico a investigar y reducir esa incertidumbre antes de comprometerse con el desarrollo.
El manual define Design Spike como una práctica ágil mediante la que el equipo reserva tiempo para investigar una cuestión oscura o indefinida del backlog mediante exploración o prototipado rápido.
En este sentido, el Design Sprint puede funcionar como un spike táctico de gran intensidad antes de iniciar el desarrollo.
Idea rápida:
Design Spike = investigar antes de construir.
21.9 Storyboard
El Storyboard es el blueprint del prototipo.
Después de que el Decider haya seleccionado la solución mediante el Supervote, el equipo construye una secuencia detallada que representa exactamente la experiencia que se probará.
Normalmente contiene entre 10 y 15 paneles y puede incluir:
- textos;
- imágenes;
- botones;
- transiciones;
- pasos de interacción.
Su función es proporcionar suficiente detalle para que el jueves el equipo pueda prototipar sin volver a debatir el contenido.
La regla fundamental es:
no introducir ideas nuevas.
Idea rápida:
Storyboard = especificación visual del prototipo.
21.10 Fake It
Fake It es la filosofía que permite construir un prototipo creíble en un solo día.
No se intenta desarrollar el producto real.
Se simula únicamente aquello que el usuario necesita ver y utilizar durante la prueba.
Esto puede implicar crear:
- pantallas enlazadas;
- botones simulados;
- contenido ficticiamente dinámico;
- procesos que parecen automáticos;
- experiencias que no disponen de backend real.
El objetivo es obtener una reacción válida del usuario sin invertir previamente en desarrollo.
El manual establece claramente que la simulación debe parecer un producto final, pero sin codificar el backend real.
Idea rápida:
Fake It = simula lo necesario para aprender.
21.11 Goldilocks Quality — Calidad Ricitos de Oro
La Goldilocks Quality define el nivel adecuado de realismo del prototipo.
No debe ser:
demasiado tosco, porque el usuario podría centrarse en defectos visuales y no reaccionar con naturalidad;
ni:
demasiado perfecto, porque requeriría demasiado tiempo y esfuerzo de desarrollo.
Debe encontrarse en el punto intermedio:
suficientemente realista para provocar una reacción natural, pero suficientemente rápido y barato para ser desechable.
La Goldilocks Quality y Fake It trabajan conjuntamente.
Fake It explica cómo simular.
Goldilocks Quality determina cuánto realismo necesitamos.
Idea rápida:
Goldilocks Quality = ni demasiado poco, ni demasiado.
21.12 MVP — Minimum Viable Product
El MVP o Producto Mínimo Viable es un producto real y funcional que se lanza al mercado con el conjunto mínimo de capacidades necesarias para obtener aprendizaje.
Por tanto, es muy diferente del prototipo utilizado durante el Design Sprint.
Prototipo
- se construye rápidamente;
- puede simular funcionalidades;
- no necesita backend;
- es desechable;
- busca aprendizaje cualitativo inmediato.
MVP
- funciona realmente;
- requiere desarrollo;
- se utiliza en el mercado;
- permite recopilar datos;
- inicia un ciclo de aprendizaje más prolongado.
El manual diferencia expresamente prototipo, MVP y producto terminado.
Idea rápida:
Prototipo = simulación para aprender.
MVP = producto real para aprender en mercado.
21.13 Cómo Relacionar los Términos
El verdadero valor del glosario aparece cuando dejamos de ver los conceptos de forma aislada.
Podemos conectarlos siguiendo la lógica del Sprint:
HMW transforma problemas en oportunidades.
Crazy 8s genera alternativas.
Solution Sketch concreta una propuesta.
Heat Map identifica elementos interesantes.
Supervote permite al Decider elegir.
El Storyboard documenta esa decisión.
Fake It permite construir la simulación.
Goldilocks Quality define su nivel adecuado de realismo.
El Facilitador protege todo el proceso.
Y si necesitamos investigar una incertidumbre antes de desarrollo, podemos utilizar el Sprint como Design Spike.
Después de la validación, una solución suficientemente confirmada puede evolucionar hacia desarrollo real y, posteriormente, hacia un MVP.
Los términos forman así una cadena lógica y no un simple vocabulario.
| ★ QUÉDATE CON ESTO: Para preparar el examen, no memorices solamente qué significa cada palabra. Asocia cada término con una fase, una responsabilidad y un propósito. Si sabes cuándo aparece y para qué sirve, será mucho más difícil caer en una respuesta trampa. |
| ★ RECUERDA: Recuerda especialmente estas asociaciones: HMW = oportunidad; Crazy 8s = divergencia rápida; Solution Sketch = propuesta; Heat Map = interés visual; Supervote = decisión del Decider; Facilitador = proceso neutral; Storyboard = blueprint; Fake It = simulación; Goldilocks Quality = realismo suficiente; MVP = producto funcional real. El glosario del propio manual identifica varios de estos conceptos como términos de especial importancia para la certificació |