Facilita un design sprint completo para validar ideas de producto antes de construirlas: el proceso de 5 días de Google Ventures adaptado a equipos pequeños y startups.
Cuándo usarlo: Planificar y facilitar un design sprint de 5 días para validar soluciones de UX antes de construirlas.
Herramienta recomendada: Claude
Eres un facilitador experto en design sprints con experiencia en equipos de producto y diseño de startups y empresas de tecnología. Necesito que me ayudes a planificar y facilitar un design sprint para resolver un problema de UX o validar una idea de producto. Mi contexto: - El problema o pregunta que quiero resolver con el sprint: [describe el reto de diseño o la hipótesis a validar] - Equipo disponible para el sprint: [roles que pueden participar: diseño, producto, desarrollo, negocio, etc.] - Disponibilidad real del equipo: [5 días completos / 5 tardes / formato condensado de 3 días] - Recursos para el prototipo y el test: [presupuesto para reclutamiento de usuarios, herramientas de prototipado disponibles] - Restricciones importantes: [plazos de desarrollo, decisiones ya tomadas, partes del problema que no están en juego] Con ese contexto, dame: 1. DÍA 1: COMPRENDER Y MAPEAR EL PROBLEMA Guíame en el diseño del día 1 del design sprint: cómo estructurar la sesión de entendimiento del problema (las entrevistas con expertos internos, el customer journey map, el mapa del sprint), cómo definir el objetivo a largo plazo y las preguntas sprint usando el formato "¿Podríamos... para que...?", y cómo elegir el foco del sprint (el momento crítico del journey donde testear). Dame la agenda hora a hora con los ejercicios, materiales y tiempos de cada actividad. 2. DÍA 2: DIVERGIR Y BUSCAR SOLUCIONES ¿Cómo facilitar la sesión de ideación del día 2 para que sea productiva y no derive en sesión de brainstorming caótica? Dame la secuencia de ejercicios: el lightning demos (búsqueda de soluciones existentes en otras industrias), el sketch de cuatro pasos (notas, ideas, crazy 8s, solución detallada) y cómo crear el ambiente que permita al equipo técnico y al de negocio contribuir en igualdad de condiciones. 3. DÍA 3: DECIDIR Y PLANIFICAR EL PROTOTIPO ¿Cómo tomar la mejor decisión sobre qué solución prototipar cuando hay varias propuestas sobre la mesa? Dame el proceso de decisión del día 3: el museo de arte (sticky decisions), el mapa de calor, la votación supervisada y cómo el decider toma la decisión final sin que el equipo sienta que ha sido ignorado. Incluye cómo crear el storyboard del prototipo: cuántos pasos necesita, qué nivel de fidelidad es suficiente y cómo dividir el trabajo de construcción entre los miembros del equipo. 4. DÍA 4: CONSTRUIR EL PROTOTIPO REALISTA EN UN DÍA ¿Cómo construir un prototipo suficientemente realista para el test de usuario en un solo día? Dame las herramientas y el proceso: cómo usar Figma, Keynote o incluso herramientas no digitales para construir un prototipo de alta percepción con bajo esfuerzo real, cómo dividir los roles del equipo durante la construcción y qué calidad mínima necesita el prototipo para generar aprendizaje válido en el test del día 5. 5. DÍA 5: EL TEST CON USUARIOS REALES Guíame en el diseño del test de usuario del día 5: cómo reclutar cinco usuarios representativos en 48 horas, el guión de la sesión de test (introducción, tareas, preguntas de seguimiento sin leading), cómo observar y tomar notas de forma sistemática con el equipo y cómo hacer el análisis de resultados en tiempo real usando el método de patrones. Dame las señales que indican que la solución funciona y las que indican que hay que volver a iterar. 6. DESIGN SPRINT ADAPTADO A EQUIPOS PEQUEÑOS ¿Cómo adaptar el design sprint cuando el equipo tiene 2 o 3 personas en lugar de 7? Dame el formato condensado para equipos pequeños: qué ejercicios eliminar, cuáles comprimir, cómo compensar la falta de diversidad de perspectivas (invitar a stakeholders puntuales, entrevistas rápidas a usuarios al inicio) y qué nivel de fidelidad del prototipo es razonable con recursos limitados. 7. ERRORES QUE HACEN FRACASAR UN DESIGN SPRINT Lista los seis errores más frecuentes que hacen que un design sprint no genere aprendizaje útil: elegir un problema demasiado grande o demasiado pequeño, no tener el decider en la sala, un prototipo que el equipo construyó con cariño pero que no responde a la pregunta del sprint, reclutar usuarios que no representan al cliente real y no saber qué hacer con los resultados cuando el test muestra que la solución no funciona.