Cómo probar la usabilidad de una app con personas reales

La reserva está ahí, pero nadie se decide a cambiarla

Imagina que has reservado una clase de entrenamiento y, de pronto, tienes que moverla al jueves. Abres la app, encuentras tu reserva y ves una opción para cambiarla. Hasta ahí, todo bien. Pero ya habías pagado una señal: ¿se mantiene al elegir otra fecha o se pierde si cancelas la actual?

Es una situación inventada, no un caso de un cliente de Appfyl. Sirve para distinguir dos cosas que solemos mezclar. La función puede estar bien programada y, aun así, dejarte sin la seguridad necesaria para utilizarla. Una comprobación técnica confirma que el cambio se guarda. Una prueba de usabilidad revela si alguien entiende lo que está a punto de hacer.

Por eso conviene observar una tarea en lugar de preguntar solo si la pantalla gusta. La respuesta amable puede ocultar una duda muy concreta. Este trabajo forma parte del proceso de diseño de experiencia de usuario, pero puedes empezar con una sesión sencilla y bien enfocada.

Decide qué quieres aprender antes de invitar a nadie

«Queremos saber si la app es fácil» parece un objetivo suficiente. En la práctica, abre demasiadas preguntas. Quizá el participante encuentre la reserva enseguida, pero no comprenda las condiciones. Otro puede entenderlas y no encontrar dónde cambiar la fecha. No arreglarías ambos problemas de la misma manera.

Para una primera ronda, acota la pregunta: ¿puede una persona cambiar una reserva pagada y explicar qué pasará con su señal? Ahora puedes observar un recorrido y tomar una decisión sobre él. No necesitas repasar todas las pantallas ni conseguir una valoración general del producto.

Define también, en tus notas, qué considerarás un resultado correcto. En nuestro ejemplo, la persona encuentra la reserva adecuada, elige otra fecha y entiende qué queda reservado y qué ocurre con el pago. No le leas esa definición al empezar: contiene parte de la respuesta.

La prueba tiene límites. No demuestra que exista demanda para tu negocio; eso se aborda en la validación de la idea. Tampoco sustituye la revisión de errores técnicos. Entender una función y comprobar que funciona son trabajos relacionados, pero distintos.

Elige una versión que permita responder a la pregunta

No siempre hace falta una app terminada. Si quieres comprobar el orden de las pantallas y el sentido de las palabras, un prototipo navegable puede bastar. Si la duda tiene que ver con el teclado, una notificación o una conexión inestable, necesitarás una versión funcional. La comparación entre prototipo y MVP ayuda a decidir qué preparar.

Deja una cuenta de prueba con una reserva creíble. Así la sesión empieza en el problema que te interesa, no en un registro interminable. Utiliza datos ficticios y evita pagos, cancelaciones o mensajes reales. No merece la pena descubrir una confusión a costa de cobrarle algo a un participante.

Ten claras las limitaciones del prototipo. Si un enlace no está construido, no interpretes su falta de respuesta como un fallo de comprensión. Pero tampoco expliques todas las pantallas antes de probarlas. Que el producto esté incompleto no impide investigar si sus opciones se entienden.

Busca experiencia relevante, no solo buena disposición

Tus compañeros conocen el proyecto. Es posible que encuentren una sección porque recuerdan una reunión, no porque la etiqueta resulte clara. Tus amigos pueden querer ayudarte y suavizar sus críticas. Ambos sirven para ensayar la sesión, pero no representan por defecto a tus futuros clientes.

En una app de clases, interesa alguien que haya reservado una actividad y haya tenido que modificarla. Pregunta por una ocasión reciente: cómo lo hizo, qué dispositivo utilizó y qué le preocupó. Esa conversación es más útil que «¿te gustaría una app para entrenar?», que invita a imaginar y a complacerte.

La orientación de Nielsen Norman Group sobre el número de participantes sitúa los grupos pequeños dentro de una investigación cualitativa e iterativa. Cinco personas adecuadas pueden ofrecer una primera ronda útil para un público concreto. No son una representación estadística de todo el mercado.

Si mezclas clientes, entrenadores y administradores, cada perfil tendrá tareas diferentes. No cuentes el grupo conjunto como si hubieras estudiado bien las tres perspectivas. Es mejor tener una pregunta pequeña bien respondida que una conclusión amplia sin suficiente apoyo.

Plantea la situación sin enseñar el camino

«Entra en Mis reservas, pulsa Editar y elige el jueves» parece una tarea. En realidad, es una explicación de la interfaz. La persona ya no necesita descubrir dónde está cada cosa: tú se lo has contado.

Un buen enunciado aporta el contexto necesario para decidir, pero no nombra los controles que quieres evaluar. El artículo de NN/G sobre escenarios de tareas desarrolla esta diferencia. Estos ejemplos son propios y siguen nuestra reserva de entrenamiento:

La persona puede decidir no continuar porque no entiende las condiciones. No tiene por qué llegar al final para que la sesión aporte algo. Quizá acaba de mostrarte el motivo por el que un cliente real llamaría al centro en lugar de terminar en la app.

Observa sin convertirte en un manual de ayuda

Aclara al principio que estás probando la aplicación, no examinando a la persona. Explica si vas a grabar y pide permiso. Si utiliza su móvil, pueden aparecer mensajes privados; acordad cómo evitarlos o excluirlos de la grabación. La guía de pruebas moderadas de GOV.UK recoge estas preparaciones.

Después llega la parte incómoda: dejar que piense. Desde fuera, unos segundos de silencio pueden parecer eternos. Si enseguida dices «mira abajo», ya has cambiado lo que estás midiendo. Puedes ayudar cuando sea necesario para seguir la sesión, pero registra que hubo una pista.

Pregunta «¿qué esperas que pase?» o «¿cómo interpretarías este mensaje?». Evita «¿has visto que conservas la señal?», porque proporciona la interpretación correcta. Tampoco felicites cada paso por el recorrido previsto. El participante puede empezar a buscar tu aprobación en lugar de actuar como lo haría por su cuenta.

Las notas de los investigadores de GDS sobre moderación son una buena lectura para quien conduce su primera sesión. Si alguien te pregunta qué significa un texto, averigua antes qué cree que significa. La duda merece quedar registrada antes de resolverla.

Prueba en el móvil, no solo en tu imaginación

Una pantalla puede parecer cómoda en la presentación y comportarse de otra manera en un teléfono normal. El teclado tapa la acción siguiente, una fecha larga ocupa dos líneas o la persona no llega bien al botón con una mano. El problema no está necesariamente en el recorrido; puede estar en las condiciones en las que se intenta recorrerlo.

No prepares una carrera de obstáculos artificial. Observa primero una situación normal y después comprueba lo que tenga sentido para ese público. Si suelen cambiar reservas durante un trayecto, investiga qué sucede tras una breve interrupción. Si utilizan texto ampliado, activa ese ajuste y repite la tarea.

La lengua también forma parte del uso. Hay que probar las etiquetas y confirmaciones que verá el público local, no validar una traducción mediante una sesión en inglés. Y una ronda general no sustituye el trabajo específico con personas que utilizan tecnologías de apoyo. La guía de accesibilidad de apps permite preparar esa revisión.

*Una ilustración del enfoque: localizar el punto donde alguien se detiene antes de ayudarle a continuar.*

Describe el problema antes de escoger la solución

«El botón necesita ser más grande» no siempre es un hallazgo. Puede ser tu primera explicación. Una nota más útil sería: la persona abrió dos veces la reserva, leyó la línea del pago y se detuvo. Al preguntarle qué esperaba, dijo que perdería la señal si cambiaba la fecha. En esta situación hipotética, un botón enorme podría dejar la misma duda intacta.

Separa el comportamiento observado, tu interpretación y el cambio que propones. Quizá las condiciones aparecen demasiado tarde. Una explicación breve antes de confirmar sería entonces una hipótesis razonable, no una solución demostrada. Habrá que verla en otra sesión.

Anota si la tarea se completó sin ayuda, con ayuda o no se terminó. Añade la consecuencia: tiempo perdido, una fecha equivocada o una posible cancelación no deseada. «Dos de las cinco personas de esta ronda necesitaron una pista» describe lo que viste. No equivale a decir que el 40 % de todos tus clientes fracasará.

La prioridad depende también de la gravedad. Una confusión que puede cancelar una reserva merece atención aunque aparezca una sola vez. Varias preferencias sobre un color pueden esperar. No se trata de contar quejas, sino de entender qué impide o pone en riesgo la tarea.

Haz un cambio que puedas volver a comprobar

Si modificas a la vez la navegación, los textos y la distribución, quizá todo vaya mejor, pero no sabrás por qué. Empieza con la causa más plausible y una intervención concreta. En nuestro ejemplo, aclara el tratamiento de la señal donde la persona necesita decidir.

Para estudiar el primer uso, conviene contar con participantes nuevos: quien ya aprendió la ruta puede repetirla de memoria. Los anteriores sirven para otras preguntas, siempre que tengas claro qué estás investigando. Pide además que expliquen el resultado final. Llegar a una confirmación no prueba que sepan qué reserva sigue vigente.

Tras publicar, la analítica de la app puede señalar dónde se abandona un recorrido. Las sesiones ayudan a interpretar esos datos y la prueba de una versión beta amplía los dispositivos y situaciones observados. Son piezas complementarias.

Para empezar basta una página con la pregunta, los participantes, unas pocas tareas, la cuenta preparada y el próximo cambio a decidir. Si necesitas apoyo de desarrollo, explica la incertidumbre a Appfyl o inclúyela en un breve formulario de proyecto. «No entienden qué ocurre con la señal» aporta más que pedir otra pantalla sin explicar para qué.

Preguntas frecuentes