Probar una experiencia antes de construirla: role play, Mago de Oz y test concierge

Puedes probar una experiencia de cliente mucho antes de que exista ningún sistema, formación del personal o reforma del espacio. Represéntala con tu equipo para encontrar los momentos incómodos (role play), simula la tecnología con una persona detrás de la cortina mientras clientes reales la usan (Mago de Oz) o presta el servicio completo a mano a unos pocos clientes reales (concierge). Cada prueba responde a una pregunta distinta, así que elige según lo que más necesites aprender y decide qué contará como aprobado antes de empezar.

Este artículo trata de experiencias: servicios, recorridos y momentos en los que las personas, los tiempos y las emociones importan tanto como las funcionalidades. Para probar ideas en general, empieza por Cómo probar una idea antes de construirla.

Por qué las experiencias necesitan su propio tipo de prueba

Un prototipo de producto te muestra si la gente sabe usar algo. Un prototipo de experiencia tiene que mostrarte algo más difícil: si la secuencia de momentos funciona cuando personas reales están cansadas, con prisa, nerviosas o acompañadas de su familia. También tiene que probar el lado del personal: quién hace qué, cuándo se produce el traspaso, qué información necesita la siguiente persona.

Nada de esto se ve en una maqueta de pantalla. Una bienvenida que se lee bien en papel puede sonar fría dicha en voz alta; un proceso de tres pasos puede venirse abajo porque el segundo depende de un compañero que está en otro edificio. Las pruebas de experiencia sacan a la luz estos fallos cuando todavía es barato arreglarlos.

Elige la prueba adecuada

El nombre «Mago de Oz» se suele atribuir al investigador Jeff Kelley, que usó la técnica a principios de los años ochenta para estudiar cómo escribiría la gente peticiones en lenguaje natural a sistemas informáticos que todavía no existían. El test concierge se popularizó en la práctica lean startup como forma de atender a mano a los primeros clientes antes de automatizar nada.

Una regla útil: el role play prueba el guion, el Mago de Oz prueba la fachada y el concierge prueba la oferta.

Cómo hacer una prueba de experiencia: siete pasos

1. Elige el momento que más te preocupa

No pruebes el recorrido entero. A partir de tu journey map o de tu service blueprint, elige el momento o los dos momentos en los que la experiencia tiene más probabilidades de fallar o más importa: el primer contacto, un traspaso entre equipos, el momento de dar una mala noticia, la espera. Prueba esos.

2. Escribe qué tiene que ser cierto y qué contará como aprobado

Escribe la creencia que sostiene el momento como una hipótesis: «Si una enfermera llama a los pacientes al día siguiente del alta, la mayoría planteará una inquietud que, de otro modo, habría llevado a urgencias». Después fija el umbral de aprobado antes de que participe nadie. La guía de prueba de hipótesis incluye una plantilla. Sin umbral de aprobado, cualquier resultado parece alentador.

3. Escribe el guion de los dos escenarios

Las experiencias tienen un frontstage, lo que ve el cliente, y un backstage, lo que hacen el personal y los sistemas para que ocurra. Escribe ambos. Un sencillo storyboard de seis a ocho viñetas basta para el frontstage. Para el backstage, enumera cada paso, quién lo hace y qué información necesita. En una prueba del Mago de Oz, el guion del backstage es lo que sigue tu operador oculto, así que hazlo preciso: tiempos de respuesta, redacción, qué hacer cuando una petición se sale del guion.

4. Construye solo lo que el momento necesita

El role play necesita una sala dispuesta más o menos como el espacio real y algo de atrezo. El Mago de Oz necesita una fachada creíble, como una ventana de chat, un número de teléfono o la pantalla de un quiosco, y un operador capaz de responder rápido. Un test concierge necesita una forma sencilla de recoger peticiones y una persona con tiempo reservado. La fidelidad debe ajustarse a la pregunta, no a tu orgullo.

5. Ensaya una vez y después hazlo con las personas adecuadas

Ensaya una vez con compañeros para detectar huecos en el guion. Después, hazlo de verdad:

• Role play primero con tu propio equipo. Intercambiad papeles para que quien diseñó el servicio haga de cliente. Después, si es posible, repítelo con dos o tres clientes reales que se interpreten a sí mismos. La guía de role play explica cómo preparar a los participantes.
• Mago de Oz con entre cinco y diez clientes reales que usen la fachada como usarían el servicio terminado. La guía de la prueba del Mago de Oz explica la preparación y las reglas del operador.
• Concierge con un puñado de clientes reales durante una a cuatro semanas, tiempo suficiente para ver si repiten. La guía del test concierge incluye una hoja de seguimiento.

6. Fíjate en las señales que importan

Asigna a una persona solo para observar. En las pruebas de experiencia, las señales más importantes suelen ser físicas o emocionales, así que anota:

• Las dudas, las preguntas repetidas y el momento en que la gente pregunta «¿y ahora qué pasa?».
• Dónde el personal, real o interpretado, tiene que improvisar porque el guion se acabó.
• Si la gente vuelve, lo recomienda o pide seguir usándolo (concierge).
• Cuánto tardó realmente el backstage en comparación con tu plan.

Recoge las reacciones justo después de cada sesión con una matriz de captura de retroalimentación: qué funcionó, qué no, qué preguntas surgieron, qué ideas nuevas.

7. Decide y actualiza el blueprint

Compara los resultados con tu umbral de aprobado y decide: construir, cambiar y volver a probar, o parar. En cualquier caso, actualiza el service blueprint con lo aprendido, sobre todo el backstage. Un test concierge casi siempre revela pasos, retrasos y dependencias que nadie había dibujado. Ese es el resultado más valioso: una imagen honesta de lo que cuesta prestar el servicio. Para elegir entre un journey map y un blueprint donde recogerlo, consulta ¿Customer journey map o service blueprint? Cuándo usar cada uno.

Ejemplo ilustrativo

Ilustrativo: una organización inventada, solo con fines explicativos.

Un hospital regional de una ciudad europea mediana quería reducir los reingresos de pacientes mayores tras el alta. La propuesta era un «acompañante de recuperación» digital: una app que haría un seguimiento diario y derivaría las inquietudes al profesional sanitario adecuado. Construirla llevaría un año.

Primero, en una mañana de role play, las enfermeras hicieron de pacientes y los hijos adultos de los pacientes se interpretaron a sí mismos. Se vio enseguida que la conversación del alta era demasiado apresurada como para que nadie recordara las instrucciones, y que quien respondería a los seguimientos solía ser un familiar, no el paciente.

Después, un test concierge de tres semanas: dos enfermeras llamaban cada mañana a veinte pacientes dados de alta, siguiendo un guion breve. El umbral de aprobado, fijado de antemano, era que al menos un tercio de las llamadas sacara a la luz una inquietud que el equipo pudiera resolver sin una visita al hospital. Las enfermeras registraron cada llamada y cuánto duraba.

El resultado superó el umbral, pero el registro mostró algo más útil: la mayoría de las inquietudes tenían que ver con los horarios de la medicación, y casi todas podía resolverlas un farmacéutico en lugar de una enfermera. El hospital cambió el diseño antes de construir nada: una llamada a cargo de un farmacéutico la primera semana y después un seguimiento digital más sencillo. El encargo de la app se redujo mucho.

Qué hacer y qué evitar

Haz esto

• Prueba el momento más arriesgado, no el recorrido entero.
• Escribe el umbral de aprobado antes de la primera sesión.
• Escribe el guion del backstage con el mismo cuidado que el del frontstage.
• Deja que quien diseñó el servicio haga de cliente al menos una vez.

Evita esto

• Explicar la experiencia a los participantes mientras la viven. Si tienes que explicarla, eso ya es un hallazgo.
• Mantener en secreto una prueba del Mago de Oz después. Cuando termine la sesión, di a los participantes que había una persona detrás, y nunca recojas datos personales sensibles mediante un sistema simulado sin el consentimiento y las garantías adecuados.
• Hacer un test concierge con amigos del equipo; serán amables.
• Tomar un buen role play como prueba de demanda. Prueba el guion, no si la gente quiere el servicio.

Preguntas frecuentes

¿Cómo se prototipa un servicio? Representa los momentos clave con atrezo sencillo (role play), simula las partes difíciles de construir con una persona oculta mientras clientes reales lo usan (Mago de Oz) o préstalo a mano a unos pocos clientes (concierge). Elige según lo que necesites aprender.

¿Es ética una prueba del Mago de Oz? Puede serlo, si no se pone en riesgo a los participantes, se les dice después que había una persona detrás y se tratan los datos con el mismo cuidado que lo haría un servicio real. Evítala en decisiones de salud, financieras o legales en las que un error causaría daño.

¿Qué diferencia hay entre un test concierge y un piloto? Un test concierge es pequeño, manual y sirve para aprender si merece la pena construir el servicio y qué exige. Un piloto pone en marcha una versión casi terminada a escala limitada para comprobar que funciona antes del despliegue completo.

Por dónde seguir

Elige tu prueba con las guías de role play, prueba del Mago de Oz y test concierge, y recoge lo que aprendas en un service blueprint. Para ver qué lugar ocupan las pruebas de experiencia en la construcción de una organización centrada en el cliente, lee Centrarse en el cliente es una práctica, no un eslogan: por dónde empezar. Para la investigación que te dice qué momentos probar, consulta Cómo entender de verdad a tus clientes.