Aplica las fases del design thinking para traducir problemas de negocio en requisitos técnicos que realmente resuelvan necesidades del usuario. Este enfoque evita el desarrollo de funcionalidades que nadie usa. Produce historias de usuario más precisas y soluciones técnicas con mayor impacto.
Cuándo usarlo: Definir requisitos técnicos con metodología de design thinking
Herramienta recomendada: Claude
Actúa como un líder técnico con formación en design thinking y experiencia en product discovery. Tu objetivo es ayudarme a usar la metodología de design thinking para definir requisitos de un producto o funcionalidad digital, asegurando que lo que se construye resuelve problemas reales. **CONTEXTO** En el desarrollo de software, es común construir funcionalidades basadas en suposiciones del equipo interno en lugar de evidencia real de los usuarios. El design thinking aporta un proceso estructurado para investigar primero, idear después y validar antes de escribir una sola línea de código. **PASO 1 — EMPATIZAR CON LOS USUARIOS REALES** Ayúdame a planificar una investigación de usuario ligera pero rigurosa: - ¿Qué técnicas de investigación son adecuadas para el tiempo y presupuesto disponible (entrevistas, encuestas, shadowing, análisis de soporte)? - Dame un guión de entrevista de 8-10 preguntas para descubrir los dolores del usuario con el flujo o funcionalidad existente. - ¿Cómo analizo y agrupo los hallazgos para encontrar patrones (affinity mapping, clustering)? **PASO 2 — DEFINIR EL PROBLEMA CORRECTO** Con los insights de la investigación, ayúdame a: - Escribir un Problem Statement técnico que incluya: usuario afectado, problema observado, impacto medible y contexto de uso. - Identificar las restricciones técnicas y de negocio que delimitan el espacio de soluciones. - Formular preguntas "¿Cómo podríamos...?" orientadas a la arquitectura y la experiencia de usuario. **PASO 3 — IDEAR SOLUCIONES TÉCNICAS** Facilita una sesión de ideación técnica: - Genera 10 posibles enfoques de implementación, desde los más simples (MVP mínimo) hasta los más sofisticados. - Para cada enfoque, estima el esfuerzo relativo (S/M/L/XL) y el valor para el usuario (bajo/medio/alto). - Aplica la matriz de impacto vs. esfuerzo para seleccionar las 2-3 mejores opciones. **PASO 4 — PROTOTIPAR ANTES DE CODIFICAR** Define la estrategia de prototipado técnico: - ¿Qué nivel de fidelidad es adecuado para validar la hipótesis central (paper prototype, wireframe, mockup interactivo, spike técnico, feature flag)? - ¿Qué partes de la solución tienen mayor incertidumbre técnica y requieren un spike primero? - Escribe los criterios de aceptación en formato BDD (Given/When/Then) para el prototipo. **PASO 5 — TESTEAR Y APRENDER** Diseña el plan de validación técnica y de usuario: - ¿Cómo monto un test de usabilidad técnico con usuarios reales o internos? - ¿Qué métricas de producto y de ingeniería me indican si la solución funciona? - ¿Cuál es el proceso para iterar: cómo incorporo el feedback sin descarrilar el sprint? **ENTREGABLE FINAL** Quiero que al final generes: 1. Un Problem Statement completo y validado. 2. Las 3 historias de usuario más críticas en formato "Como [usuario], quiero [acción], para [valor]". 3. Una lista de criterios de aceptación técnicos. 4. Un plan de sprint de discovery de dos semanas con tareas concretas. Empieza preguntándome por el contexto: ¿cuál es el producto o funcionalidad que quieres diseñar, y quiénes son los usuarios afectados?