Los equipos de desarrollo que participan en el discovery de usuario construyen mejor software porque entienden el contexto real de uso. Este prompt ayuda a diseñar un proceso de discovery técnico y research de usuario adaptado a los ritmos y competencias de un equipo de ingeniería. Obtendrás un sistema para que los desarrolladores aporten al research sin necesitar convertirse en researchers.
Cuándo usarlo: Integrar el discovery de usuario en el proceso de desarrollo de software
Herramienta recomendada: Claude
Eres un experto en discovery de producto, UX research y desarrollo de software ágil. Necesito tu ayuda para diseñar un proceso de discovery técnico y research de usuario que integre al equipo de desarrollo desde las fases tempranas de comprensión del problema. **Contexto del equipo:** - Tamaño del equipo: [NÚMERO] devs + [PM/Diseñador/AMBOS/NINGUNO] - Metodología: [SCRUM / KANBAN / DUAL-TRACK / OTRA] - Fase del producto: [NUEVO PRODUCTO / FUNCIONALIDAD NUEVA / DEUDA TÉCNICA / MEJORA] - Acceso a usuarios: [DIRECTO / A TRAVÉS DE CS / MUY LIMITADO] - Mayor problema de calidad actual: [DESCRIBE] **Lo que necesito:** 1. **Integración del equipo de desarrollo en el discovery** - Por qué el equipo de desarrollo debe participar en el research y no solo recibir specs - Cómo involucrar a los devs en el discovery sin bloquear el desarrollo - Técnicas de research que los desarrolladores pueden ejecutar sin formación especializada - Cómo estructurar el tiempo del equipo entre discovery y delivery 2. **Research técnico y de usuario combinado** - Exploración técnica: cómo investigar viabilidad técnica en paralelo al discovery de usuario - Entrevistas de usuario para devs: guía simplificada de preguntas técnicas relevantes - Cómo documentar los hallazgos de research en formato que sea útil para el equipo técnico - Spike técnico: cuándo hacerlo y cómo conectarlo con el discovery de usuario 3. **Definición del problema desde el equipo técnico** - Cómo traducir un problema de negocio en un problema técnico bien definido - Árbol de causas raíz (5 whys): cómo usarlo en el contexto técnico - Cómo identificar si un problema reportado es un síntoma o la causa real - Problem statement técnico: qué incluir y cómo validarlo con usuarios 4. **Prototipado y validación técnica temprana** - Tipos de prototipos técnicos: desde wireframes hasta POCs funcionales - Cuándo construir un POC vs. un prototipo de papel vs. un mockup - Criterios de éxito para validar una hipótesis técnica con usuarios - Cómo presentar un prototipo técnico a usuarios no técnicos para obtener feedback útil 5. **Síntesis de research para el equipo técnico** - Cómo transformar los insights de research en criterios de aceptación técnicos - User stories enriquecidas con contexto de research - Documentación de decisiones técnicas basadas en research de usuario - Cómo compartir los hallazgos de research con el equipo de una manera que genere empatía real 6. **Ciclo de discovery continuo** - Cómo integrar el discovery continuo en los sprints sin interrumpir el ritmo de entrega - Métricas de éxito del discovery: cómo saber si el proceso está funcionando - Señales de que el equipo está construyendo sin suficiente comprensión del usuario **Formato de respuesta:** Incluye una guía de entrevista de usuario simplificada para desarrolladores. Proporciona plantillas de síntesis de research adaptadas al lenguaje técnico. Señala cómo adaptar las recomendaciones según el acceso disponible a usuarios.