Tiremesù
ES
MétodosGuía práctica8 min de lectura

El prototipo más barato que se puede hacer esta semana

Cómo hacer un prototipo de bajo coste en días, no meses: elegir la pregunta, optar por papel, role-play, Mago de Oz o concierge, y probarlo con gente real.

Editores de Tiremesù

El prototipo más barato que se puede hacer esta semana

El prototipo más barato es lo más tosco que responda a la pregunta más importante, con personas reales delante. Para la mayoría de las ideas, eso significa papel, un role-play, una persona haciéndose pasar por el sistema o prestar el servicio a mano a unas pocas personas. Cualquiera de ellos se hace en un día y se prueba antes del jueves. Los pasos siguientes muestran cómo elegir uno y llevarlo a cabo.

Este artículo trata de construir la pieza. Para la cuestión más amplia de cómo planificar pruebas y leer las evidencias, ver el artículo hermano sobre cómo probar una idea antes de construirla.

Por qué en esta fase lo barato gana a lo bueno

Un prototipo es una pregunta con forma física. Al principio, las únicas preguntas que vale la pena hacer son las que podrían tumbar la idea: si la gente la entenderá, si la usará, si la usará como se espera. Un prototipo pulido no las responde mejor que uno tosco, y tiene dos desventajas. Cuesta más, así que el equipo se encariña con él. Y parece terminado, así que la gente se muestra educada. El trabajo tosco invita a la crítica sincera; salta a la vista que aún se puede cambiar.

Cinco prototipos baratos y cuándo usar cada uno

Prototipo Qué es Ideal para probar Tiempo de elaboración
Prototipo en papel Pantallas, formularios o cartas dibujados en papel Si la gente lo entiende y sabe moverse por él Horas
Storyboard Una tira cómica de la experiencia, de seis a ocho viñetas Si la idea tiene sentido y resulta atractiva Una o dos horas
Role-play Personas que representan el servicio con accesorios sencillos Conversaciones, traspasos, momentos presenciales Media jornada
Mago de Oz Parece automatizado; una persona hace el trabajo a escondidas Si la gente usa una función "inteligente" o digital Un día
Concierge Se presta el servicio a mano, abiertamente, a unas pocas personas Si el valor es lo bastante real como para seguir usándolo Un día de preparación

Una nota sobre los nombres: el término Mago de Oz (Wizard of Oz) lo acuñó John F. Kelley en su trabajo sobre computación en lenguaje natural en la Johns Hopkins, y apareció por primera vez publicado en su tesis de 1983. El libro de Carolyn Snyder Paper Prototyping (2003) sigue siendo una buena referencia práctica para los prototipos en papel.

Cómo hacer uno y probarlo esta semana

1. Escribir la pregunta única (lunes por la mañana). Enumerar lo que tiene que ser cierto para que la idea funcione y elegir el supuesto que sea a la vez el más importante y el menos demostrado. Convertirlo en una sola pregunta: "¿Encontrarán quienes solicitan por primera vez la lista de documentos correcta sin ayuda?". Si hay tres preguntas, hay tres prototipos. Se empieza por uno. Un Mapa de supuestos (assumption mapping) es una forma rápida de elegir.

El lienzo del Mapa de supuestos (assumption mapping)
El lienzo del Mapa de supuestos (assumption mapping)

2. Escribir qué haría cambiar de opinión. Antes de construir, acordar qué habría que ver para seguir adelante y qué llevaría a parar o cambiar de rumbo. "Si la mayoría no encuentra la lista sin preguntar, rediseñamos el punto de entrada." Dejarlo por escrito de antemano evita que el equipo reinterprete los resultados después. La guía de Prueba de hipótesis tiene un formato sencillo.

El lienzo de la Prueba de hipótesis
El lienzo de la Prueba de hipótesis

3. Elegir la forma a partir de la pregunta (lunes por la tarde). Usar la tabla anterior. Comprensión y navegación: papel. Atractivo general: storyboard. Interacción humana: role-play. Una función digital o automatizada: Mago de Oz. Si el valor es real: concierge. En caso de duda, elegir el que se pueda hacer más rápido.

4. Construir solo lo que la pregunta necesita (martes). Hacer la parte de la experiencia que la persona tocará durante la prueba, y nada más. Un prototipo en papel de un formulario necesita el formulario, el mensaje de error y la confirmación, no el portal entero. Un chat Mago de Oz necesita a una persona al otro lado con unas cuantas respuestas preparadas, no un chatbot. Bolígrafos, impresiones, un documento compartido, un teléfono. Si construirlo lleva más de un día, se está construyendo demasiado.

5. Reclutar a unas cinco personas reales (martes). Buscar personas que encajen con aquella para la que se diseña, no compañeros. El personal de primera línea a menudo puede presentárselas ese mismo día. Cinco sesiones suelen bastar para ver los grandes problemas; se buscan patrones, no porcentajes.

6. Hacer las sesiones: observar, no explicar (miércoles y jueves). Dar a la persona una tarea, no una visita guiada: "Tienes que renovar tu licencia. Enséñame qué harías". Y quedarse callado. Cuando se atasque, preguntar "¿Qué estás buscando?" en lugar de señalar. Que una segunda persona tome notas en una Matriz de captura de retroalimentación (feedback capture grid): qué funcionó, qué no, qué preguntas surgieron, qué ideas nuevas aparecieron. En una prueba Mago de Oz o concierge, quien hace el trabajo oculto o manual lleva un registro de cada petición, porque ese registro será después la especificación.

7. Decidir y dejarlo registrado (viernes). Comparar lo observado con lo acordado en el paso 2. Elegir uno de cuatro desenlaces: seguir, cambiar y volver a probar, cambiar de rumbo o parar. Escribir un párrafo que recoja la pregunta, lo observado y la decisión. Ese párrafo vale más que el prototipo.

Qué hacer y qué evitar

Qué hacer

  • Probar una sola pregunta por prototipo.
  • Mantenerlo visiblemente tosco: líneas a mano, palabras tachadas, cinta adhesiva.
  • Probarlo con quienes de verdad lo usarán, en el entorno real o cerca de él.
  • Ser transparente después: en las pruebas concierge la gente sabe que la está ayudando una persona. En las pruebas Mago de Oz, decir a los participantes al final que había una persona detrás y seguir las normas de la organización sobre consentimiento en investigación.
  • Guardar juntos el prototipo, las notas y la decisión.

Qué evitar

  • Preguntar "¿Te gusta?". Hay que observar lo que hacen.
  • Explicar la idea antes de que la prueben.
  • Arreglar el prototipo entre una sesión y otra, salvo que un problema impida por completo la prueba; se pierde el patrón.
  • Dejar que una prueba barata se convierta en un piloto encubierto. El Mago de Oz y el concierge funcionan solo a pequeña escala, por diseño.
  • Enseñar una maqueta pulida a la alta dirección como si fuera el producto. Lo que se enseña es lo aprendido.

Ejemplo ilustrativo

Ilustrativo. Un ayuntamiento de Australia tenía la idea de crear un "asistente de permisos de aparcamiento" que respondiera en línea a las preguntas de los vecinos y les rellenara la solicitud. El equipo digital calculó varios meses de desarrollo.

En lugar de eso, el equipo se hizo una sola pregunta: ¿usarían de verdad los vecinos un chat para hacer la solicitud o seguirían llamando por teléfono? Acordaron de antemano que, si la mayoría de quienes lo probaran abandonaban el chat y pedían el número de teléfono, la idea se descartaría.

Construyeron una versión Mago de Oz en un día: una sencilla ventana de chat en una página de pruebas, con un técnico de permisos al otro lado tecleando respuestas a partir de un guion breve. Imprimieron una versión en papel del resumen final de la solicitud. Durante dos días hicieron sesiones con vecinos reclutados en el centro de atención del ayuntamiento.

La mayoría usó el chat sin problemas, pero casi todos hicieron las mismas dos preguntas que el guion no cubría, sobre los permisos para visitas y sobre las mudanzas. El registro del técnico las mostraba con claridad. El equipo decidió seguir adelante, pero reescribiendo primero la página de requisitos, porque muchas de las preguntas del chat desaparecerían si esa página fuera más clara. La estimación de desarrollo se redujo, porque el asistente ya no tenía que atender preguntas que una página mejor podía responder.

Preguntas frecuentes

¿Qué es un prototipo de baja fidelidad? Una versión tosca y rápida de una idea, como un boceto, una maqueta en papel o un role-play, hecha para comprobar si la idea funciona antes de invertir en una versión detallada. La baja fidelidad se refiere a lo terminado que parece, no a lo útil que es.

¿Se puede prototipar un servicio, y no solo un producto? Sí. Los servicios suelen ser más fáciles de prototipar que los productos, porque se pueden representar. Los role-plays, los storyboards y las pruebas concierge son formas de prototipar un servicio con personas, un guion y unos pocos accesorios.

¿Con cuántas personas hay que probar un prototipo? Para un prototipo temprano y tosco, unas pocas sesiones suelen bastar para revelar los mayores problemas. Si varias personas tropiezan en el mismo punto, ahí está la respuesta. Después de cambiarlo, se vuelve a probar con un grupo nuevo.

Por dónde seguir

Las guías de Prototipo en papel, Prueba del Mago de Oz (Wizard of Oz) y Test concierge (MVP concierge) recorren cada una de esas formas en detalle, y el Storyboard (guion gráfico del servicio) es la manera más rápida de comprobar si una idea tiene sentido. Para ver dónde encaja el prototipado entre otras herramientas, leer qué herramienta de innovación usar y ver las 10 herramientas que todo equipo de innovación debería conocer.