Extraer necesidades de los usuarios y evidencias de las notas de entrevistas

Autor: AILesson9 min de preparaciónProbado con:ChatGPTRevisado el: 2026-08-28

Respuesta rápida

Vincula comportamientos, objetivos, restricciones y necesidades no satisfechas con evidencias de entrevistas sin convertir las solicitudes en requisitos. Proporciona: Registros de entrevistas, Marco del estudio, Reglas de análisis. Resultado esperado: Una tabla de evidencias con observaciones, formulaciones de necesidades, variaciones, confianza, contradicciones, vacíos y preguntas de seguimiento.

1

Añade tu contexto

Tu texto permanece en este navegador. AILesson Prompts no lo envía a un modelo ni a un servidor.

2

Tu prompt

Los campos sin rellenar permanecen visibles como marcadores de posición, para que puedas copiar y editar el prompt

Extrae fielmente las necesidades de los usuarios y las evidencias de los registros de entrevistas proporcionados.

Transcripciones o notas, identificadores de participantes, marcas de tiempo, contexto de la sesión, preguntas, correcciones, artefactos, consentimiento y vacíos:
[records]

Preguntas de investigación, muestra, reclutamiento, decisión, términos, hipótesis e interpretaciones excluidas:
[study]

Unidad de codificación, formato de las necesidades, permiso para citar, privacidad, confianza, evidencia mínima, casos negativos, proceso de revisión y esquema:
[analysis]

Mantén separados el relato del participante, el comportamiento observado, la evidencia de los artefactos, la pregunta del moderador, la interpretación del investigador y la solicitud de producto. Extrae situaciones recientes, desencadenantes, objetivos, acciones actuales, alternativas, fallos, restricciones, consecuencias, criterios de decisión, soluciones provisionales, progreso deseado y contraejemplos, con el participante y la marca de tiempo o localizador correspondientes. Formula las necesidades con su contexto y sin depender de una solución; no las presentes como estereotipos demográficos ni deseos de funciones. Una solicitud como «enviar recordatorios» es evidencia de una solución propuesta; infiere la necesidad subyacente solo como una hipótesis etiquetada que esté respaldada por el comportamiento y el contexto. Conserva las contradicciones dentro de una misma sesión y entre sesiones, las evidencias silenciosas o ausentes, las limitaciones de la muestra y el reclutamiento, y los efectos de las preguntas inductivas del moderador. No cuentes declaraciones repetidas de una persona como si procedieran de varios participantes. Para cada tema, indica los participantes únicos, los localizadores de las evidencias, los casos favorables y contrarios, el fundamento de la confianza, los roles y contextos afectados, las incógnitas y la siguiente pregunta de validación. Oculta los datos personales o de clientes cuyo uso no esté autorizado. Termina con los hechos que se pueden comunicar de forma segura, las interpretaciones que necesitan revisión y las afirmaciones que la muestra no permite sostener.
Probar en Playground
Privado de forma predeterminadaLa preparación del prompt se realiza localmente en tu navegador. Evita introducir información confidencial en cualquier servicio de IA, a menos que tu organización lo permita.

De la entrada al resultado

Un ejemplo completo

Mira cómo un contexto concreto convierte esta receta en un resultado que puedes usar

Entrada real

Registros de entrevistas
P01 12:10: una revisión reciente de un cliente permaneció en Ready durante tres días; P01 consultó Teams dos veces y escribió al responsable del proyecto porque no se mostraba ningún aceptante. A las 15:02 dice: «envíame correos hasta que responda». P02 08:40: dejar el estado en Ready durante la noche fue intencionado porque el cliente estaba en otra zona horaria; a las 10:15 dice que más correos serían ruido. P03 19:22: no vio un traspaso porque esperaba una @mención; la captura muestra al propietario, pero no al aceptante. A las 20:00, el moderador pregunta: «¿Los recordatorios automáticos solucionarían eso?». P03 responde: «probablemente». De P04 solo hay notas, sin marcas de tiempo: usa una cola diaria y dice que los elementos retrasados en Ready suelen estar esperando aprobación. Todos fueron reclutados entre contactos de soporte; se aprobaron las citas breves, pero no los nombres de clientes.
Marco del estudio
Pregunta: ¿qué situaciones generan estados Ready prolongados y qué información permite actuar? Decisión: explorar un recordatorio por correo electrónico, una indicación de responsabilidad o ninguna de las dos opciones. Cuatro participantes: dos propietarios, un aceptante y un solicitante; Reino Unido/Alemania. El reclutamiento entre contactos de soporte probablemente sobrerrepresenta los problemas. Se define aceptante como la persona autorizada para confirmar el siguiente estado. No inferir la prevalencia en el mercado ni la demanda de funciones.
Reglas de análisis
La unidad de codificación es una instancia reciente de traspaso. Formato de necesidad: Cuando (contexto), el rol necesita (progreso), para poder (resultado), según evidencia (comportamiento). Contar participantes únicos; exigir al menos dos para un tema transversal, pero conservar los casos individuales. Incluir casos negativos. Citas de menos de 15 palabras con participante/hora. Ocultar los clientes. Dos investigadores revisan las interpretaciones de forma independiente.

Ejemplo de salida

Tema 1 — identificar quién puede aceptar un traspaso, confianza media, 2 participantes únicos Evidencia: P01 consultó Teams dos veces y contactó con un responsable porque no aparecía ningún aceptante (12:10). P03 esperaba una @mención; el artefacto mostraba un propietario, pero no un aceptante (19:22). Hipótesis de necesidad: cuando un traspaso está listo, pero no está claro quién tiene la responsabilidad de aceptarlo, el rol que debe actuar necesita identificar al aceptante autorizado para poder dirigir la siguiente acción sin buscar entre distintas personas. Esto está respaldado por el comportamiento y el artefacto, pero hay que confirmar los roles y la frecuencia. Caso contrario: los elementos retrasados de P04 suelen estar esperando aprobación, lo que puede implicar que la autoridad se conoce en lugar de faltar.

Tema 2 — distinguir una espera intencionada de una acción omitida, confianza media, 2 participantes en contextos distintos P02 esperó intencionadamente por la diferencia horaria (08:40); P04 informó de una espera de aprobación. Hipótesis de necesidad: cuando un estado Ready se prolonga, los roles necesitan conocer el motivo y el siguiente acontecimiento esperado para poder decidir si esperar o intervenir. Esto no implica que se necesite un recordatorio.

Solicitudes de soluciones y efectos de las preguntas inductivas La frase de P01 «envíame correos hasta que responda» (15:02) es una sugerencia de función, no una prueba de que los correos repetidos satisfagan la necesidad subyacente. P02 es un caso negativo: «más correos serían ruido» (10:15). El «probablemente» de P03 sigue a la pregunta inductiva del moderador sobre los recordatorios (20:00) y constituye evidencia de baja calidad sobre la demanda; no debe contarse como validación independiente.

Hechos que se pueden comunicar de forma segura: dos participantes encontraron artefactos sin información visible sobre el aceptante; uno informó de una espera intencionada por la zona horaria y otro de una espera de aprobación. Las interpretaciones requieren la revisión de dos investigadores. La muestra no permite sostener afirmaciones sobre prevalencia, comparaciones entre segmentos o causalidad, ni recomendar la creación de recordatorios. Siguiente pregunta: en una muestra más amplia que haya dado su consentimiento, ¿se pueden clasificar las instancias recientes según aceptante conocido/desconocido, espera intencionada, aprobación externa, señal omitida y otras causas?

Por qué funciona

  1. 1

    Formular las necesidades sin depender de una solución evita que las solicitudes de funciones definan prematuramente la respuesta del producto.

  2. 2

    Contar por participante e incluir casos negativos evita confundir la repetición insistente con la prevalencia.

Comprueba el resultado

  • ¿Cada necesidad se remonta a un comportamiento y un contexto, y no solo a una solicitud de función?

  • ¿Se conservan los participantes únicos, los localizadores, los casos negativos y los efectos del moderador?

  • ¿Están claramente separadas la observación, la interpretación, la solicitud y la prevalencia sin respaldo?

Úsalo con confianza

Preguntas frecuentes

Respuestas prácticas sobre cuándo usar esta receta, qué debes proporcionar y en qué casos la revisión humana sigue siendo importante

¿Qué debo preparar antes de usar «Extraer necesidades de los usuarios y evidencias de las notas de entrevistas»?

Para usar «Extraer necesidades de los usuarios y evidencias de las notas de entrevistas», prepara los registros de entrevistas, el marco del estudio y las reglas de análisis. Sustituye los marcadores de posición solo con información que puedas verificar. Si se desconoce algún detalle, conserva explícitamente esa incertidumbre en vez de pedirle al modelo que lo infiera.

¿Cuándo no está listo para usarse el resultado de «Extraer necesidades de los usuarios y evidencias de las notas de entrevistas»?

El resultado no está listo si aún no ofrece, a partir de las evidencias proporcionadas, el resultado indicado —una tabla de evidencias con observaciones, formulaciones de necesidades, variaciones, confianza, contradicciones, vacíos y preguntas de seguimiento—, o si depende de supuestos sin resolver, aprobaciones pendientes o detalles inventados. Usa las comprobaciones como criterios de aprobación: revisa los datos de entrada o asigna la revisión a una persona identificada y autorizada, en vez de pulir un resultado sin respaldo.

¿Qué herramientas de IA tienen pruebas registradas para «Extraer necesidades de los usuarios y evidencias de las notas de entrevistas»?

El registro de pruebas publicado para «Extraer necesidades de los usuarios y evidencias de las notas de entrevistas» incluye ChatGPT a fecha de 2026-08-28. Esto confirma que hay ejecuciones registradas, pero no garantiza la compatibilidad ni resultados idénticos en versiones posteriores del producto. Para otra herramienta o versión, mantén visibles todas las restricciones y repite las comprobaciones del resultado antes de usarlo.

Mantén el trabajo en marcha