Una ficha de experimento de producto convierte un «deberíamos probarlo» en una prueba que el equipo puede interpretar. Define el supuesto, la actividad con la que se pondrá a prueba, la evidencia que se recogerá y la decisión que podría cambiar. Lo difícil no es encajar esos campos en una ficha, sino asegurarse de que la prueba responde a la pregunta planteada.
Mantén el supuesto y la decisión prevista juntos en un espacio compartido de planificación de producto. El siguiente ejemplo sigue a un equipo que prueba un recordatorio de cita con un enlace para cambiarla sin ayuda. Antes de ampliar su uso, el equipo quiere saber si las personas entienden ese enlace y pueden utilizarlo cuando cambian sus planes.
Elige un supuesto que la prueba pueda examinar
Imagina un servicio en el que los clientes reservan una cita y reciben un recordatorio. Actualmente, quienes necesitan otro horario deben contactar con el equipo. El recordatorio propuesto les permitiría cambiar la cita por su cuenta.
«Mejorar los recordatorios reducirá las ausencias» es una afirmación demasiado amplia para una primera prueba con un prototipo. Una ausencia puede deberse a un olvido, un problema de transporte, un horario inadecuado o un cambio que el cliente no pudo comunicar. Un prototipo interactivo no reproduce todas esas circunstancias.
Empieza con un supuesto más concreto: cuando necesitan cambiar una cita, los clientes pueden reconocer la opción del recordatorio y elegir otro horario adecuado sin contactar con el servicio. Este supuesto trata sobre la comprensión y la realización de una tarea. Saber si la función reduce las ausencias requiere otra evaluación posterior, con citas reales.
Si el equipo todavía no ha elegido qué incertidumbre es más importante, empieza con un taller de mapeo de supuestos. La ficha se utiliza después de esa elección; no sustituye la decisión sobre qué problema merece atención.
Completa la ficha del experimento
La Test Card de Strategyzer propone definir la hipótesis, la prueba, la medición y el criterio de éxito. En una prueba de producto, añade contexto suficiente para que otra persona entienda qué encontrarán los participantes y qué hará el equipo con los resultados.
| Campo | Ejemplo del recordatorio de cita |
|---|---|
| Decisión | ¿Se entiende lo bastante bien la opción para cambiar la cita como para pasar a un piloto limitado con usuarios reales? |
| Supuesto | Los clientes que necesitan otro horario pueden encontrar la opción y elegir una alternativa sin ayuda del personal. |
| Participantes y contexto | Invita a personas que utilicen servicios de citas similares. Incluye los dispositivos y las necesidades de accesibilidad relevantes. Usa datos de citas ficticios, no información de otros clientes. |
| Actividad | Muestra el recordatorio en un contexto de mensajería realista. Explica que el horario reservado ya no les viene bien y pregunta qué harían. |
| Evidencia | Registra la primera acción, el recorrido sin indicaciones, las peticiones de ayuda, la interpretación de la confirmación y cualquier malentendido crítico. |
| Criterio de decisión | Revisa el recorrido si las confusiones repetidas impiden completar la tarea sin ayuda o aparece un malentendido crítico sin resolver. Considera un piloto limitado solo si el recorrido se comprende en las situaciones relevantes estudiadas. |
| Pregunta pendiente | Esta prueba no demuestra una mejora de la asistencia, la fiabilidad del sistema en producción ni la disponibilidad de suficientes horarios alternativos. |
El criterio no es un umbral numérico universal. Antes de buscar participantes, acuerda con el equipo qué se considera un malentendido crítico, qué situaciones deben estar representadas y qué evidencia bastará para tomar la siguiente decisión. Un estudio cualitativo pequeño no debe convertirse en una tasa precisa de éxito de toda la población.
Plantea la tarea sin revelar la respuesta
«Pulsa el enlace para cambiar la cita y elige otro horario» ya indica adónde ir. Comprueba si se pueden seguir unas instrucciones, no si el recordatorio comunica la opción. Una consigna más útil sería: «Ya no puedes acudir a esta hora. Muéstrame qué harías a continuación».
Mantén un punto de partida lo bastante coherente como para interpretar las diferencias. Quien empieza en la página de la cita ya ha superado el problema de encontrarla desde la bandeja de entrada. Registra el punto de inicio, el dispositivo, el contexto del mensaje y cualquier intervención de la persona que modera.
Cuando alguien dude, deja que esa duda se manifieste. Si necesita ayuda, anota qué ocurrió antes y después. Terminar tras escuchar «prueba el enlace de abajo» no equivale a encontrar el recorrido de forma independiente. Ambas observaciones pueden orientar el diseño, pero sumarlas en una única cifra de tareas completadas oculta el problema.
El prototipo también necesita un estado final creíble. Si la prueba termina al elegir un horario, el equipo no sabrá si la persona entiende que su cita original ha cambiado. Incluye la confirmación propuesta y pregunta qué cita cree tener ahora.
Separa lo que ocurrió de su posible explicación
Coloca las observaciones junto a las interpretaciones, en lugar de sustituirlas por un veredicto. La tabla muestra cómo distintas observaciones cambiarían el siguiente paso.
| Posible observación | Interpretación que investigar | Consecuencia para el diseño |
|---|---|---|
| Una persona abre el mensaje, busca un teléfono y no ve el enlace para cambiar la cita. | El mensaje puede parecer meramente informativo. | Revisar el texto y la ubicación del enlace y observar cómo funciona el nuevo recordatorio. |
| Una persona encuentra el enlace, pero cree que elegir otro horario crea una segunda cita. | No queda clara la relación entre la cita original y la nueva. | Aclarar el cambio y su confirmación antes del piloto con citas reales. |
| Una persona entiende el recorrido, pero ningún horario disponible le sirve. | La disponibilidad, no la navegación, impide completar la tarea. | No atribuir el resultado a una interfaz confusa; investigar por separado la limitación del servicio. |
| El enlace del prototipo falla antes de mostrar las opciones. | La persona no ha podido acceder a la tarea prevista. | Corregir el material de prueba y marcar ese intento como no interpretable para el supuesto sobre navegación. |
Un comentario favorable como «parece útil» no responde a la misma pregunta que una acción sin indicaciones. Del mismo modo, no completar una tarea no identifica automáticamente su causa. Conserva la secuencia para distinguir un problema de redacción de la falta de horarios o de un prototipo que no funciona.
Organiza la prueba y la evidencia en Boardmix
En una pizarra de Boardmix, sitúa la decisión sobre una ficha de experimento compacta. A su derecha, muestra el recordatorio y el recorrido propuesto para cambiar la cita. Debajo, crea zonas separadas para observaciones, interpretaciones y la siguiente decisión. Usa etiquetas de texto además de colores para que el significado se conserve en una captura o en otra pantalla.
En este ejemplo, conecta «entiende la opción de cambio» con el recordatorio, y «sabe qué cita conserva» con la confirmación. Esas conexiones muestran qué parte del diseño aporta la evidencia relevante. Mantén la pregunta sobre asistencia fuera del área de resultados de esta ficha: completar una tarea en el prototipo no equivale a demostrar un efecto en el negocio.
Abre una pizarra de Boardmix y organiza la ficha alrededor de la siguiente decisión real del equipo. Usa fragmentos anonimizados o datos ficticios en una pizarra compartida; cuando el material de investigación necesite acceso restringido, enlaza a los registros con los permisos adecuados.
Decide qué permite hacer el resultado
La Learning Card de Strategyzer distingue la hipótesis comprobada, las observaciones, la interpretación y la acción resultante. En este caso, el siguiente paso puede ser revisar el recordatorio, cambiar la confirmación, iniciar un piloto o realizar otra prueba porque faltaba una situación importante.
Supón que las personas entienden cómo cambiar la cita, pero no encuentran otro horario adecuado. Volver a redactar el enlace no resolvería esa limitación. La siguiente investigación debe centrarse en la disponibilidad y en la operación del servicio. Si el recorrido funciona en el prototipo, un piloto puede examinar qué hacen los clientes al cambiar una cita real. Esa evaluación posterior necesita sus propias medidas y precauciones; la primera ficha ya ha respondido a una pregunta más acotada y útil.
