Research Plan for UX Research

A note on language

The downloadable template is in Spanish. This page explains what it contains and the reasoning behind it, so you can judge whether it fits before translating.

When to use it

Before recruiting anyone. The plan is what you agree with whoever commissioned the study: what will be found out, with which method, with whom, when, and which decision depends on the result.

Its real job is not documentation, it is that everyone understands the same thing before money is spent. When a project derails, you can almost always point at the sentence in the plan that nobody read the same way.

Two to four hours for the one-page version. The formal version with budget and risks takes eight to sixteen, and most of the time it is not needed.

Before you use it

One page is the target, not the floor. One of this deliverable's quality criteria is brevity: if your plan needs ten pages to explain itself, the scope is probably unresolved. The template marks the optional sections so you delete them, not so you fill them.

Three research questions, maximum. If a fourth appears, something is out of scope or it is another project. It is the constraint that saves the most argument later.

Method comes after the problem. The most common mistake is the other way round: arriving with "we want to run interviews" and only then asking what to find out. If you wrote the method before the questions, go back.

And the stage comes before the method. Generative to understand what is going on, evaluative to find out whether something works. Evaluative research needs something concrete in front of the participant: if the prototype does not exist yet, it is not that you are short of time, it is that the method is a different one.

Logistics are not admin. In person or remote, moderated or unmoderated, lab or field: those decisions change the data you get, which is why they belong in the plan and are not improvised the week of fieldwork.

A plan that concludes "no research needed" is a good outcome. It has happened to me, and it is still the cheapest thing that can happen: finding out here costs a meeting; finding out afterwards costs the whole study.

Two sections do not leave the team. Risks and budget are marked in the document; they get deleted in the copy the client sees.

Everything in brackets gets replaced. The worked example lives on this page and not in the downloadable file.

The document

This is what you download and fill in. It is in Spanish.

{/* --- 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.

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

Reclutamiento: [de dónde salen] · Incentivo: [monto] · Sobre-reclutar [20 %].

5. Cronograma

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

9. Presupuesto y horas

{/* --- FIN DOCUMENTO --- */}

The worked version

The same document with a case written end to end: an invented study on the sign-up flow of a personal finance app. It shows what level of detail each field expects before you face the empty version. It downloads separately, and it is in Spanish.

{/* --- 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

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

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

Reclutamiento: [panel propio / base del cliente / agencia]. Incentivo [monto] por sesión. Sobre-reclutar [20 %] para ausencias.

6. Cronograma

Timeline

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

9. Presupuesto y horas

Budget · solo equipo

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 --- */}

The one-page version

If the project is small or the team already knows each other, the full plan is overkill. The short version keeps four things and deletes the rest:

1. The problem and the decision that depends on the study.
2. The research questions.
3. The method in two lines.
4. Who takes part and when.

That fits on a page and does the work that matters: nobody discovers halfway through that they understood something different.

A worked example

A study on the onboarding of a personal finance app.

Problem: high drop-off during signup. The team knows people leave, but not at which step or why; product data shows the aggregate drop and does not explain the decision to close the app.

Decision that depends on it: redesign the bank-linking step, or reorder the signup sequence.

Questions: which step they stop at and what they are thinking there; what information the app asks for that people do not have to hand; how widespread the distrust of bank linking is.

Method: ten interviews with a guided walkthrough, then a survey to the installed base to size it. Qualitative first because we do not yet know what to ask in the survey.

That last criterion — qualitative to understand, quantitative to size — is what makes the "why this method and not another" section write itself.

This example lives here only, not in the downloadable file.

Check before using it

• Is the "decision that depends on this" line filled in?
• Are there more than three research questions?
• Did you write the method before the questions?
• Does the "out of scope" section say something concrete?
• Is the "requires from the client" column of the timeline complete?
• Did you delete sections 8 and 9 in the copy that goes to the client?
• Any bracket left unreplaced?

Grounding

The required components and the quality criteria come from this site's Research Plan entry, where they appear in more detail.

The generative/evaluative split, the formative/summative one — which comes from Measuring the User Experience, by Tullis and Albert — and the logistics decisions in section 3 are worked through in How to choose a UX Research methodology, where I go through the six criteria and the order I use them in.

The instruments the plan lists have their own templates: the interview guide, the screener, the informed consent and, if the stage is evaluative, the usability test protocol.