Preparación
01 · Definir la pregunta del sprint
02 · Seleccionar el equipo
03 · Reclutar usuarios para el viernes
04 · Reservar espacio y materiales
Proceso día a día
- Lunes — Mapear y elegir un objetivo
- El equipo mapea el problema: ¿quiénes son los actores involucrados? ¿cuál es el recorrido del usuario desde que reconoce el problema hasta que lo resuelve? El mapa hace visible lo que cada persona en la sala sabe individualmente pero el equipo nunca había articulado junto.
- Expertos internos y externos hacen breves exposiciones: "¿Cómo lo hacemos ahora? ¿Qué hemos intentado? ¿Qué saben los expertos que nosotros no?"
- El Decidor elige un objetivo específico del mapa: ¿qué parte del recorrido atacaremos esta semana? Esta decisión define el alcance de todo lo que sigue.
- Martes — Hacer bocetos de soluciones
- Cada persona trabaja individualmente —en silencio— para generar soluciones. El proceso de boceto tiene cuatro pasos: tomar notas (capturar lo interesante del día anterior), generar ideas rough (cantidad, no calidad), explorar variaciones crazy 8s (doblar una hoja 8 veces, dibujar 8 variaciones en 8 minutos), producir un boceto detallado de 3 paneles de la solución propuesta.
- Trabajar solo deliberadamente: el pensamiento en grupo produce la solución más obvia. El trabajo individual produce más variación y creatividad.
- Miércoles — Decidir (sin debates interminables)
- Por la mañana: el equipo revisa todos los bocetos usando el "museo de arte" —los bocetos se cuelgan anónimamente en la pared, cada persona los revisa en silencio y coloca puntos adhesivos en las partes interesantes. Luego hay una crítica rápida por boceto, seguida de una votación de 1 voto por persona.
- El Decidor tiene voto final —puede elegir el boceto más votado u otro. La regla es que decide, no debate.
- Por la tarde: crear un storyboard detallado del prototipo que se construirá el jueves. El storyboard tiene 10–15 frames que describen exactamente qué verá el usuario en las pruebas del viernes.
- Jueves — Prototipar
- Construir un prototipo "lo suficientemente bueno": realista para que los usuarios reaccionen genuinamente, pero no tan terminado que lleve semanas. Un prototipo de Keynote, PowerPoint o Figma suele ser suficiente para probar ideas de producto digital. Para servicios, puede ser una representación en papel o un roleplay guionizado.
- Regla de oro del prototipo: debe verse como si tomara meses construirlo, pero en realidad tomó un día. La ilusión de finalidad obtiene reacciones auténticas de los usuarios.
- Escribir el guión de entrevista para el viernes: ¿qué tareas pedirás a los usuarios que hagan? ¿qué preguntas harás?
- Viernes — Probar con usuarios reales
- Entrevistar a los 5 usuarios en sesiones individuales de 60 minutos. El entrevistador está solo con el usuario; el resto del equipo observa en vivo desde otra sala (o remotamente) y toma notas en un tablero compartido: observaciones positivas, negativas y preguntas.
- Después de las 5 entrevistas: el equipo identifica patrones. Buscar temas que aparezcan en 3 o más de los 5 usuarios —esos son señales. Los problemas de 1–2 usuarios son ruido.
- El equipo decide: ¿funcionó el prototipo? ¿Qué aprendimos? ¿Seguimos en esta dirección, volvemos a miércoles para elegir otra solución, o descartamos el enfoque?
Materiales
Sala con pizarras grandes o papel de rotafolio en las paredes
Post-its grandes (varios colores), marcadores, puntos adhesivos para votación
Cronómetro (Timekeeper es crítico: los sprints colapsan sin gestión del tiempo)
Herramientas de prototipado: Figma, Keynote, PowerPoint, o papel
Software de grabación de entrevistas (con consentimiento de los participantes)
Sala separada o remoto para observación de entrevistas
Herramientas digitales
Recomendaciones prácticas
Los primeros cuatro días son inútiles sin usuarios el viernes. Reclutar usuarios antes del lunes, no el miércoles cuando ya estás en el sprint. Cancelar las pruebas del viernes convierte el sprint en un ejercicio de design interno sin validación.
El Decidor debe estar en la sala los cinco días. Un sprint donde el tomador de decisiones "pasa por un momento" el miércoles produce decisiones que nadie tiene autoridad para defender el lunes siguiente.
No hay pantallas antes del martes por la tarde. Los equipos que abren laptops en lunes y martes terminan buscando referencias y distraídos. El sprint requiere concentración en el problema, no en soluciones existentes.
5 usuarios es suficiente. Nielsen Norman Group demostró que 5 usuarios detectan el 85% de los problemas de usabilidad. Más de 5 produce rendimientos decrecientes. La tentación de hacer más entrevistas para "más datos" es resistible.
El sprint no reemplaza la investigación. Un sprint responde si una solución específica funciona para usuarios en un contexto específico. No responde si estás resolviendo el problema correcto. Asegurarse de que el equipo entienda la diferencia antes del lunes.
Inspiración
Ejemplos de aplicación por contexto:
- Producto digital: Un equipo de salud digital hace un sprint sobre cómo presentar resultados de laboratorio a pacientes no médicos —descubriendo en el viernes que los pacientes no quieren ver los números, quieren saber qué significa el resultado para ellos.
- Servicio público: Un municipio hace un sprint sobre el proceso de renovación de licencias de conducir, descubriendo que el mayor punto de fricción no es el formulario online sino la incertidumbre sobre cuánto tiempo esperará en la sucursal.
- ONG: Una organización de microfinanzas hace un sprint sobre cómo presentar opciones de crédito a pequeños comerciantes, descubriendo que la principal barrera no es la tasa de interés sino el miedo a no entender los términos del contrato.
- Educación: Un equipo educativo hace un sprint sobre una nueva herramienta de evaluación formativa, descubriendo que los docentes la adoptarían si supieran que no aumentaría su carga de trabajo —y rediseñando la propuesta de valor en consecuencia.
Fuentes consultadas
- Knapp, J., Zeratsky, J. & Kowitz, B. (2016). Sprint: How to Solve Big Problems and Test New Ideas in Just Five Days. Simon & Schuster.
- Nielsen, J. (2000). Why you only need to test with 5 users. Nielsen Norman Group.
- Banfield, R., Lombardo, C. T. & Wax, T. (2015). Design Sprint: A Practical Guidebook for Building Great Digital Products. O'Reilly Media.
