Cuándo usarla
Antes de reclutar a nadie. El plan es lo que se acuerda con quien encarga el estudio: qué se va a averiguar, con qué método, con quiénes, cuándo, y qué decisión depende del resultado.
Su función real no es documentar: es que todo el mundo entienda lo mismo antes de gastar plata. Cuando un proyecto se descarrila, casi siempre se puede señalar la frase del plan que nadie leyó igual.
Dos a cuatro horas para la versión de una página. La versión formal con presupuesto y riesgos toma entre ocho y dieciséis, y la mayor parte de las veces no hace falta.
Antes de usarla
Una página es el objetivo, no el mínimo. Uno de los criterios de calidad de este entregable es que sea breve: si tu plan necesita diez páginas para explicarse, probablemente el alcance no está resuelto. La plantilla trae las secciones opcionales marcadas para que las borres, no para que las llenes.
Tres preguntas de investigación, tope. Si aparece una cuarta, algo está fuera de alcance o es otro proyecto. Es la restricción que más discusión ahorra después.
El método va después del problema. El error más común es al revés: llegar con "queremos hacer entrevistas" y recién ahí preguntarse qué averiguar. Si escribiste el método antes que las preguntas, devuélvete.
Y la etapa va antes que el método. Generativa para entender qué pasa, evaluativa para saber si algo funciona. Una investigación evaluativa necesita algo concreto delante: si todavía no existe el prototipo, no es que falte tiempo, es que el método es otro.
La logística no es administrativa. Presencial o remoto, moderado o no moderado, laboratorio o campo: esas decisiones cambian los datos que vas a obtener, y por eso van en el plan y no se improvisan la semana del campo.
Que el plan concluya "no hace falta investigar" es un buen resultado. Me ha pasado y sigue siendo lo más barato que puede ocurrir: descubrirlo acá cuesta una reunión; descubrirlo después cuesta el estudio entero.
Dos secciones no salen del equipo. Riesgos y presupuesto van marcados en el documento; se borran en la copia que ve el cliente.
Todo lo que va entre corchetes se reemplaza. El ejemplo trabajado está en esta página y no en el archivo descargable.
El documento
Esto es lo que descargas y completas.
{/* --- INICIO DOCUMENTO --- */}
Estudio: [nombre del estudio] Responsable: [nombre · rol] Contraparte: [nombre · rol] Estado: [Borrador / En revisión / Aprobado] Fecha: [DD/MM/AAAA]
1. Problema y contexto
[Qué está pasando, en dos o tres frases y sin jerga.]
Qué ya sabemos: [lo que dicen los datos que ya existen] Qué no sabemos: [el hueco que este estudio viene a llenar] Decisión que depende de esto: [qué se va a decidir con el resultado, y cuándo] Riesgo de no hacerlo: [qué se decide igual, con qué evidencia, y qué cuesta equivocarse]
Si la línea de la decisión queda vacía, el estudio no tiene para qué existir todavía. Que la respuesta sea "no hace falta investigar" es un resultado válido de este plan, y es mucho más barato descubrirlo acá que después de haber ejecutado.
2. Preguntas de investigación
Máximo tres.
| # | Pregunta | Método | Entregable |
|---|---|---|---|
| P1 | [¿…?] | [método] | [qué produce] |
| P2 | [¿…?] | [método] | [qué produce] |
| P3 | [¿…?] | [método] | [qué produce] |
Fuera de alcance: [lo que este estudio no va a responder, dicho ahora]
3. Método
Etapa: [generativa, para entender qué pasa · evaluativa, para saber si algo funciona] · [formativa, antes de lanzar · sumativa, para medir lo lanzado]
Se decide antes que el método, porque lo determina. Una investigación evaluativa necesita algo concreto delante; si todavía no existe, el método es otro.
Qué se pone delante: [nada · prototipo en baja · prototipo en alta · producto en producción] — solo si la etapa es evaluativa.
El nivel de fidelidad decide qué se puede concluir: en baja se prueba el flujo y la comprensión, no la interfaz ni el tiempo en tarea.
[Qué se va a hacer: cuántas sesiones, de cuánto, con qué instrumentos.]
Por qué este método y no otro: [una frase; es la que te van a pedir después]
Logística: [laboratorio · campo] · [presencial · remoto] · [moderado · no moderado] · Herramienta: [cuál]
No es un detalle administrativo: el contexto cambia los datos. Remoto es más accesible y pierde matices; no moderado escala y no deja preguntar por qué.
Instrumentos: [guía de entrevistas / screener / consentimiento / protocolo de testeo] — [enlaces]
4. Participantes
| Criterio | Definición | Cuota |
|---|---|---|
| [criterio de inclusión] | [definición conductual, no demográfica] | [n] |
| [criterio de contraste] | [definición] | [n] |
| [exclusión] | [quién no entra y por qué] | — |
Reclutamiento: [de dónde salen] · Incentivo: [monto] · Sobre-reclutar [20 %].
5. Cronograma
| Etapa | Fechas | Responsable | Requiere del cliente |
|---|---|---|---|
| Diseño e instrumentos | [semana] | [quién] | [qué necesitas de ellos] |
| Reclutamiento | [semana] | [quién] | |
| Campo | [semana] | [quién] | |
| Análisis | [semana] | [quién] | |
| Entrega | [semana] | [quién] |
La última columna es la que evita la conversación de "se atrasó el estudio".
6. Entregables
- [Qué recibe, en qué formato]
- [Qué recibe]
- [Taller de bajada de (X) min, si aplica]
7. Nota de método y limitaciones
[Qué va a poder decir este estudio y qué no. Si es cualitativo: describe razones y mecanismos, no proporciones.]
[Solo para el equipo · borrar en la copia del cliente]
8. Supuestos y riesgos
| Riesgo | Probabilidad | Mitigación |
|---|---|---|
| [riesgo] | [alta/media/baja] | [qué se hace si pasa] |
9. Presupuesto y horas
| Ítem | Horas | Monto |
|---|---|---|
| Diseño e instrumentos | [ ] | [ ] |
| Campo | [ ] | [ ] |
| Incentivos | — | [ ] |
| Análisis y entrega | [ ] | [ ] |
| Total |
{/* --- FIN DOCUMENTO --- */}
La versión llena
El mismo documento con un caso escrito de principio a fin: un estudio inventado sobre el registro de una app de finanzas personales. Sirve para ver qué nivel de detalle espera cada campo antes de enfrentarte a la versión vacía. Se descarga aparte.
{/* --- INICIO EJEMPLO --- */}
Versión interna. Incluye supuestos del equipo, riesgos y presupuesto. La versión que se comparte con el cliente omite las secciones 8 y 9.
1. Datos del proyecto
Project metadata
| Campo · Field | Valor · Value |
|---|---|
| Cliente | [Nombre del cliente] |
| Proyecto | [Onboarding app de finanzas personales] |
| Responsable | [Nombre · rol] |
| Contraparte cliente | [Nombre · rol] |
| Ventana de campo | [DD/MM/AAAA – DD/MM/AAAA] |
| Estado | [Borrador · En revisión · Aprobado] |
| Versión de la plantilla | v1.0 · última revisión [DD/MM/AAAA] · ver original en UXR |
2. Problema y contexto
Problem and context
La app tiene alto abandono en el registro. El equipo sabe que las personas se van, pero no en qué paso ni por qué. Los datos de producto muestran la caída agregada; no explican la decisión de cerrar la app.
Qué ya sabemos: [tasa de abandono global], [paso con mayor caída según analytics], [tickets de soporte relacionados].
Qué no sabemos: qué información falta al usuario en cada paso, qué genera desconfianza, y si el abandono es definitivo o postergado.
Decisión que depende de esto: [rediseñar el paso de vinculación bancaria vs. reordenar la secuencia de registro], con fecha de decisión [DD/MM].
3. Preguntas de investigación
Research questions
| # | Pregunta | Método | Entregable |
|---|---|---|---|
| P1 | ¿En qué paso se detienen y qué están pensando ahí? | Entrevistas con recorrido guiado | Matriz de hallazgos y severidad |
| P2 | ¿Qué información pide la app que la persona no tiene a mano? | Entrevistas + revisión heurística | Informe heurístico |
| P3 | ¿Qué tan extendida está la desconfianza al vincular el banco? | Encuesta a base instalada | Reporte de encuestas |
Máximo tres preguntas. Si aparece una cuarta, algo está fuera de alcance o es otro proyecto.
4. Método
Method
4.1 Etapa y qué se pone delante
Evaluativa y formativa: el registro ya existe y queremos saber por qué falla antes de rediseñarlo, no medir cuánto mejoró después.
Qué se pone delante: el flujo de registro en producción, en el teléfono del participante. Sin prototipo: el problema está en lo que ya está publicado.
4.2 Diseño
Cualitativo primero, cuantitativo después. [10] entrevistas semiestructuradas de [60] min con recorrido guiado sobre el dispositivo del participante, remotas por videollamada con pantalla compartida. Luego una encuesta de [8] preguntas a [n] usuarios de la base instalada, para dimensionar los patrones encontrados.
4.3 Por qué este método y no otro
Un test de usabilidad clásico mediría si la tarea se completa; ya sabemos que no se completa. Lo que falta es la razón, que aparece en la conversación durante el recorrido. La encuesta sola no sirve todavía: no sabemos qué preguntar.
4.4 Logística
Remoto, moderado, por videollamada con pantalla compartida. Remoto porque el segmento está repartido en varias ciudades; moderado porque la pregunta es el por qué y eso se pregunta en el momento.
4.5 Instrumentos
- Screener de reclutamiento — [enlace]
- Guía de entrevistas (interna y versión participante) — [enlace]
- Matriz de hallazgos y severidad — [enlace]
- Consentimiento informado — [enlace]
5. Muestra y reclutamiento
Sample and recruitment
| Criterio | Definición | Cuota |
|---|---|---|
| Abandonó el registro | Descargó y no completó la activación, últimos 60 días | 6 |
| Completó el registro | Activó la cuenta, últimos 60 días (grupo de contraste) | 4 |
| Ingreso variable | Independiente, freelance o boleta | mín. 4 |
| Exclusión | Trabaja en banca, fintech, diseño o investigación | — |
Reclutamiento: [panel propio / base del cliente / agencia]. Incentivo [monto] por sesión. Sobre-reclutar [20 %] para ausencias.
6. Cronograma
Timeline
| Etapa | Fechas | Responsable | Requiere del cliente |
|---|---|---|---|
| Diseño e instrumentos | [semana 1] | [UXR] | Aprobación del plan |
| Reclutamiento | [semana 1–2] | [UXR] | Acceso a la base de usuarios |
| Campo | [semana 3] | [UXR] | Ambiente de prueba estable |
| Análisis | [semana 4] | [UXR] | — |
| Entrega y taller | [semana 5] | [UXR + cliente] | Asistencia del equipo de producto |
7. Entregables
Deliverables
- Presentación de insights ([n] láminas) con recomendaciones priorizadas.
- Matriz de hallazgos y severidad, con esfuerzo estimado.
- Customer journey map del proceso de activación.
- Taller de bajada de [90] min con el equipo de producto.
8. Supuestos y riesgos
Assumptions and risks · solo equipo
| Riesgo | Probabilidad | Mitigación |
|---|---|---|
| No se logra contactar a quienes abandonaron | Alta | Reclutamiento externo con screener propio |
| El ambiente de prueba se cae durante el recorrido | Media | Prototipo de respaldo en Figma con los mismos pasos |
| El equipo espera cifras de abandono desde la parte cualitativa | Alta | Nota de método explícita en la entrega y en el taller |
9. Presupuesto y horas
Budget · solo equipo
| Ítem | Horas | Monto |
|---|---|---|
| Diseño e instrumentos | [ ] | [ ] |
| Campo ([10] sesiones) | [ ] | [ ] |
| Incentivos | — | [ ] |
| Análisis y entrega | [ ] | [ ] |
| Total | [ ] | [ ] |
10. Nota de método y limitaciones
Method note and limitations
Con [10] entrevistas los hallazgos describen razones y mecanismos, no proporciones de la población. La encuesta posterior dimensiona; la parte cualitativa explica. Ningún número de la fase cualitativa se presenta como porcentaje. El grupo que completó el registro se incluye como contraste, no como muestra representativa de usuarios activos.
UXR SpA · Investigación de usuarios [[email protected]] · [uxr.cl]
Plantilla v1.0 · revisada [DD/MM/AAAA] Original en UXR — revisa que tu copia no esté vencida
{/* --- FIN EJEMPLO --- */}
La versión de una página
Si el proyecto es chico o el equipo ya se conoce, el plan completo sobra. La versión corta conserva cuatro cosas y borra el resto:
- El problema y la decisión que depende del estudio.
- Las preguntas de investigación.
- El método en dos líneas.
- Quiénes participan y cuándo.
Eso cabe en una página y hace el trabajo que importa: que nadie descubra a mitad de camino que entendía otra cosa.
Un ejemplo trabajado
Estudio sobre el onboarding de una app de finanzas personales.
Problema: alto abandono en el registro. El equipo sabe que la gente se va, pero no en qué paso ni por qué; los datos de producto muestran la caída agregada y no explican la decisión de cerrar la app.
Decisión que depende: rediseñar el paso de vinculación bancaria o reordenar la secuencia de registro.
Preguntas: en qué paso se detienen y qué están pensando ahí; qué información pide la app que la persona no tiene a mano; qué tan extendida está la desconfianza al vincular el banco.
Método: diez entrevistas con recorrido guiado, y después una encuesta a la base instalada para dimensionar. Cualitativo primero porque todavía no sabemos qué preguntar en la encuesta.
Ese último criterio —cualitativo para entender, cuantitativo para dimensionar— es el que hace que la sección "por qué este método y no otro" se escriba sola.
Este ejemplo está solo acá, no en el archivo descargable.
Revisión antes de usarla
- ¿La línea "decisión que depende de esto" está llena?
- ¿Hay más de tres preguntas de investigación?
- ¿Escribiste el método antes que las preguntas?
- ¿La sección "fuera de alcance" dice algo concreto?
- ¿La columna "requiere del cliente" del cronograma está completa?
- ¿Borraste las secciones 8 y 9 en la copia que va al cliente?
- ¿Quedó algún corchete sin reemplazar?
Fundamento
Los componentes obligatorios y los criterios de calidad vienen de la ficha de Plan de Investigación de este sitio, donde están con más detalle.
La distinción generativa/evaluativa, la de formativa y sumativa —que viene de Measuring the User Experience, de Tullis y Albert— y las decisiones de logística de la sección 3 están desarrolladas en Cómo elegir la metodología de UX Research, donde cuento los seis criterios y en qué orden los uso.
Los instrumentos que el plan enumera tienen su propia plantilla: la guía de entrevistas, el screener, el consentimiento informado y, si la etapa es evaluativa, el protocolo de testeo.