Cómo probar una idea antes de construirla

Para probar una idea antes de construirla, hay que enumerar lo que tiene que ser cierto para que funcione, elegir la creencia que es a la vez más importante y menos demostrada, y hacer la prueba más barata que pueda demostrar que es falsa. Se decide de antemano qué resultado cuenta como aprobado, se hace la prueba con personas reales en condiciones reales y después se elige entre continuar, cambiar o parar. No se está probando si a la gente le gusta la idea. Se está probando si se sostiene lo más arriesgado que se cree sobre ella.

Por qué «se lo enseñamos a la gente y le gustó» no es una prueba

La validación más habitual es una presentación seguida de aplausos. La gente es educada, sobre todo con los compañeros y sobre todo cuando la idea se presenta con esmero. Lo que la gente dice que haría y lo que hace en realidad suelen estar muy lejos.

Una prueba de verdad tiene tres rasgos. Apunta a un supuesto concreto. Tiene un umbral de aprobado acordado antes de que nadie vea los resultados. Y pide a la gente que haga algo, como dar su tiempo, dar información, cambiar un hábito o comprometerse, en lugar de opinar. Si la prueba no puede fallar, es una demostración.

Cómo probar una idea: siete pasos

1. Escribir la idea en una frase con un quién y un cambio

«Una app para estudiantes» es una categoría, no una idea que se pueda probar. «Los estudiantes de primer curso que faltan a clase pueden ponerse al día en 24 horas gracias a un breve resumen grabado por el profesor» sí se puede probar. Hay que nombrar para quién es, qué hará de forma distinta y qué mejora para esa persona.

2. Enumerar todos los supuestos que hay detrás

Se pregunta al equipo: ¿qué tiene que ser cierto para que esto funcione? Hay que apretar hasta llegar al menos a quince creencias. Se agrupan bajo tres preguntas habituales en la práctica del diseño: ¿la gente lo quiere? (deseabilidad), ¿podemos ofrecerlo? (factibilidad) y ¿podemos sostenerlo? (viabilidad). Los equipos suelen enumerar primero los riesgos de factibilidad porque resultan cómodos de discutir. Los riesgos que hunden ideas suelen estar más bien en la deseabilidad y la viabilidad.

Un premortem, la técnica de Gary Klein que consiste en imaginar que el proyecto ya ha fracasado y preguntarse por qué, es una forma rápida de sacar a la luz supuestos que la gente no se atreve a decir en voz alta.

3. Encontrar el supuesto más arriesgado

Se sitúa cada supuesto en dos ejes: cuánto importa para la idea y cuánta evidencia hay ya. Es el mapa de supuestos, popularizado por David J. Bland. La esquina superior izquierda, crítico y no demostrado, es donde se prueba primero. Se elige uno, como mucho dos. Todo lo demás espera.

Una comprobación útil: «Si esto resulta falso, ¿la idea muere o solo cambia?». Se prueban los que la matarían.

4. Convertirlo en una hipótesis con umbral de aprobado

Se redacta como una hipótesis con esta forma: Creemos que [quién] hará [qué] porque [motivo]. Sabremos que es cierto si [resultado medible] en [plazo].

El umbral se fija antes de hacer la prueba, y se pone por escrito. «Al menos 8 de cada 20 estudiantes que faltaron a una clase abren el resumen en un día» es un umbral. «Los estudiantes responden bien» no lo es. También hay que acordar qué se hará si el resultado se queda corto o cae en un punto intermedio. Los equipos que se saltan esto siempre encuentran la forma de leer el resultado como una buena noticia.

5. Elegir la prueba más barata que pueda demostrar que estás equivocado

La prueba se ajusta al supuesto, no a la herramienta favorita:

• ¿La gente lo quiere? Una puerta falsa (fake door: ofrecer el servicio o el botón y contar quién intenta usarlo, para después explicarlo con honestidad), una página de registro o un compromiso previo, como reservar una cita.
• ¿Lo usarán como esperamos? Un prototipo en papel o una prueba de usabilidad moderada con una versión tosca.
• ¿El valor se mantiene en el uso real? Un test concierge: prestar el servicio a mano a unas pocas personas, abiertamente, antes de automatizar nada.
• ¿Funciona la experiencia antes de que exista la tecnología? Una prueba del Mago de Oz: el usuario interactúa con lo que parece un servicio en funcionamiento mientras una persona hace el trabajo entre bastidores. El término lo acuñó John F. Kelley en la investigación sobre interacción persona-ordenador hacia 1980.
• ¿Cuál de dos versiones funciona mejor? Un experimento A/B, cuando ya hay suficiente tráfico o usuarios para comparar.

El coste se mide en días, no en dinero. Una buena primera prueba lleva de uno a diez días. Si necesita aprobación presupuestaria, probablemente se está construyendo, no probando. Para ideas sobre cómo hacer el propio artefacto de prueba, consulta el prototipo más barato que puedes hacer esta semana.

6. Hacerla con personas reales y observar

Hay que probar con las personas para las que es la idea, no con compañeros que las sustituyan. Las condiciones deben ser lo más reales posible: su lugar, su dispositivo, su presión de tiempo. Hay que fijarse más en lo que hacen que en lo que dicen.

Lo observado se recoge en una matriz de captura de retroalimentación: qué funcionó, qué no, qué preguntas surgieron y qué ideas nuevas aparecieron. Las sorpresas se anotan en el momento; al día siguiente se desdibujan.

Si una prueba implica al público, hay que explicar con claridad qué se está probando y obtener las autorizaciones que exija la organización. Probar no justifica engañar a nadie.

7. Decidir: continuar, cambiar o parar

Se compara el resultado con el umbral fijado. Después se toma en voz alta una de tres decisiones:

• Continuar: el supuesto se sostuvo. Se pasa al siguiente más arriesgado.
• Cambiar: se sostuvo en parte, o para otro grupo. Se ajusta la idea y se vuelve a probar.
• Parar: no se sostuvo. Se registra lo aprendido y se cierra. Parar una idea tras una prueba de dos semanas es un buen resultado; pararla tras un año construyendo, no.

Se escribe una nota breve: qué se probó, qué pasó, qué se decidió y por qué. Este registro es lo que permite a un equipo aprender de una idea a otra en lugar de empezar de cero cada vez.

Ejemplo ilustrativo

Ilustrativo. Una universidad de Australia quería construir una app de tutoría entre iguales para estudiantes de primer curso de ingeniería. El plan inicial era un desarrollo de seis meses.

El equipo enumeró 22 supuestos. En el mapa de supuestos, el más arriesgado no era técnico. Era este: «Los estudiantes de segundo curso dedicarán una hora a la semana a dar tutorías a los de primero a cambio de créditos, no de dinero». Si eso fallaba, la app no tenía nada que conectar.

Su hipótesis: «Si ofrecemos créditos, al menos 15 estudiantes de segundo se apuntarán a un turno de tutoría en una semana». Pusieron un sencillo formulario de inscripción en el boletín de segundo curso, lo gestionaron a mano como un test concierge y emparejaron a tutores y estudiantes por correo electrónico.

Se apuntaron nueve, por debajo del umbral. Pero las conversaciones posteriores fueron reveladoras: varios dijeron que darían tutorías en pareja, no solos, porque no estaban seguros de sus propios conocimientos. El equipo cambió la idea a tutorías en pareja, volvió a lanzar el formulario y consiguió 21 inscripciones. La app seguía sin construirse. La siguiente prueba era si los de primero se presentarían de verdad.

Qué hacer y qué evitar

Qué hacer

• Probar un supuesto cada vez y nombrarlo en el plan de prueba.
• Fijar un umbral y una regla de decisión antes de ver los resultados.
• Preferir pruebas en las que la gente actúa a pruebas en las que opina.
• Mantener la primera prueba por debajo de dos semanas.
• Tratar «parar» como un resultado útil y registrar por qué.

Qué evitar

• Presentar la idea y contar los cumplidos.
• Probar con compañeros cuando la idea es para clientes o ciudadanos.
• Construir un prototipo pulido para comprobar si alguien lo quiere.
• Mover el umbral cuando llegan los resultados.
• Engañar a los participantes; una puerta falsa debe terminar con una explicación honesta.

Preguntas frecuentes

¿Cuál es la forma más rápida de validar una idea? Encontrar el supuesto que, si es falso, mataría la idea, y hacer una prueba que pida a personas reales que actúen: reservar una cita, inscribirse o usar una versión gestionada a mano. Muchas de estas pruebas caben en una semana.

¿Qué diferencia hay entre un test concierge y una prueba del Mago de Oz? En un test concierge, la gente sabe que una persona está prestando el servicio a mano. En una prueba del Mago de Oz, el servicio parece automatizado para el usuario mientras una persona trabaja entre bastidores. El concierge prueba el valor; el Mago de Oz, la experiencia de un sistema futuro.

¿Con cuántas personas hay que probar una idea? En las primeras pruebas, que buscan problemas en una experiencia, un puñado de participantes suele sacar a la luz los principales. En las pruebas que miden la demanda, primero se fija un umbral en cifras y después se llega a suficientes personas para que esa cifra signifique algo.

Por dónde seguir

Empieza con el mapa de supuestos y la guía de la prueba de hipótesis, y después elige entre el test concierge y la prueba del Mago de Oz según lo que necesites aprender. Si todavía estás eligiendo qué ideas probar, lee cómo priorizar ideas y, para el conjunto completo de métodos, consulta qué herramienta de innovación usar.