Pruebas de usabilidad de aplicaciones móviles: sus usuarios tienen una mano libre y media atención

Una mujer intenta volver a pedir un medicamento con receta. Sostiene a un niño pequeño con un brazo y el teléfono con el otro, con el pulgar estirado hacia un botón de la esquina superior, mientras el sol se refleja en la pantalla con tanta fuerza que tiene que entrecerrar los ojos. A mitad de la tarea le llega un mensaje, lo mira de reojo, pierde el hilo y cierra la aplicación. Nadie de su equipo vio lo que pasó, porque nadie de su equipo hace pruebas así.

Ese es el fallo silencioso que está en el centro de la mayoría de las pruebas de usabilidad de aplicaciones móviles: el método se toma prestado tal cual de la web, donde una sesión moderada significa un participante sentado ante un escritorio, con buena luz, las manos libres y prestándole toda su atención durante cuarenta y cinco minutos. Las pruebas de usabilidad de escritorio miden una versión de su usuario que no existe en un teléfono.

¿Cómo se hacen pruebas de usabilidad de una aplicación móvil?

Las pruebas de usabilidad de aplicaciones móviles consisten en observar a personas reales mientras intentan completar tareas reales en el propio dispositivo, en condiciones cercanas a las de su uso real del producto, y medir si logran terminar la tarea, cuánto tardan y dónde se atascan. El método cambia según la pregunta: sesiones moderadas en el dispositivo para entender el “porqué”, pruebas remotas no moderadas para ganar escala, pruebas de guerrilla para el contexto del mundo real y estudios de primer arranque para ese momento que solo ocurre una vez. Ningún método cubre los cuatro casos por sí solo; la mayoría de los fallos de usabilidad se esconden en el espacio que queda entre ellos.

Esa es la versión corta. La versión larga es que las pruebas de usabilidad de aplicaciones móviles no son una sola actividad, sino cuatro, y elegir la equivocada para la pregunta que realmente se está planteando es el motivo por el que muchos equipos terminan con un informe lleno de hallazgos que no predicen lo que ocurre después del lanzamiento.

Por qué el método de escritorio no sirve en móvil

Si realiza una sesión de usabilidad moderada estándar, está probando a una persona con las dos manos libres, una conexión estable, una pantalla grande, nadie hablándole y una batería que no supone ningún problema. Lleve el producto a un teléfono y esa misma tarea compite ahora con una parada de autobús, una notificación de Slack, una señal intermitente y un pulgar que tiene que abarcar una pantalla de 6,7 pulgadas sin que se le caiga nada.

Los datos confirman lo distinta que es la forma en que las personas sujetan y usan realmente estos dispositivos. En un estudio de campo muy citado con 1.333 personas que usaban dispositivos móviles en espacios públicos, el investigador Steven Hoober observó que, entre quienes tocaban la pantalla, el 49 % sostenía el teléfono con una mano, el 36 % lo apoyaba en una mano mientras pulsaba con la otra y solo el 15 % usaba el agarre a dos manos “en posición de rezo” que la mayoría de los diseñadores formados en escritorio dan por sentado (UXmatters, “How Do Users Really Hold Mobile Devices?”). Combinando esos agarres, Josh Clark calcula que los pulgares realizan el 75 % de todas las interacciones con el teléfono (A List Apart, “How We Hold Our Gadgets”). Si en su prueba de usabilidad le entrega el teléfono al participante y le deja usar ambas manos cómodamente sobre una mesa, ya ha probado una postura que describe aproximadamente a uno de cada siete de sus usuarios reales.

Luego está la atención. Un participante en una prueba de escritorio no recibe llamadas. Un usuario móvil muy a menudo sí, o va caminando, o está a una pestaña de distancia de consultar algo completamente distinto. Nada de eso es un comportamiento excepcional en móvil. Es lo normal.

Métodos de pruebas de usabilidad móvil: la matriz de selección

Cada método responde a una pregunta diferente y le deja ciego ante un conjunto distinto de problemas. Usar solo uno, normalmente la sesión moderada porque es la más conocida, significa que las otras tres preguntas nunca obtienen respuesta.

Ningún método sustituye a otro. Una sesión moderada que descubre que “los usuarios no entienden este icono” y una sesión de guerrilla que descubre que “los usuarios no pueden pulsar este icono a pleno sol” son dos errores distintos con dos soluciones distintas, y un plan de pruebas basado en un solo método solo encuentra uno de ellos.

¿Cuántos usuarios necesita para las pruebas de usabilidad de aplicaciones móviles?

Cinco usuarios por segmento y por ronda sigue siendo la cifra de partida adecuada. Procede de la investigación de Jakob Nielsen y Thomas Landauer, que Nielsen Norman Group sigue respaldando: una primera ronda con cinco participantes representativos suele sacar a la luz alrededor del 85 % de los problemas de usabilidad que encontraría un estudio mucho mayor, porque la mayoría de los problemas se repiten entre usuarios en lugar de ser exclusivos de una sola persona (NN/g, “Why You Only Need to Test with 5 Users”).

El matiz específico del móvil es qué cuenta como “un segmento”. Si su aplicación tiene grupos de usuarios realmente distintos (un flujo orientado a cuidadores frente a uno orientado a profesionales clínicos, una base de usuarios mayoritariamente de iOS frente a otra mayoritariamente de Android con dispositivos más antiguos), cada uno de ellos necesita sus propios cinco participantes, no cinco repartidos entre todos. Y en las pruebas remotas no moderadas, al ser más baratas por participante, suele merecer la pena superar los cinco y llegar al rango de 15 a 30, para obtener una variedad real de tamaños de dispositivo, versiones del sistema operativo y condiciones de red, en lugar de cinco personas que casualmente hicieron la prueba con un iPhone nuevo conectado a WiFi.

Un ejemplo de pruebas de usabilidad de aplicaciones móviles: el onboarding, línea a línea

Así es como se ve en la práctica uno de estos estudios, con un flujo de onboarding compuesto que refleja patrones que QAwerk observa repetidamente en clientes móviles, en lugar de un proyecto concreto con nombre propio.

El flujo evaluado: una secuencia de onboarding de cinco pantallas para una aplicación de creación de contenido (registrarse, conectar una cuenta de red social, elegir una plantilla inicial, completar un primer proyecto y llegar a la pantalla de guardar/exportar).

Tareas asignadas a los participantes: crear una cuenta sin texto de ayuda, conectar una cuenta externa y producir y exportar un primer contenido en menos de tres minutos, todo ello en su propio teléfono, con una mano y al aire libre.

Métricas registradas: tasa de finalización de tareas por pantalla, tiempo por tarea, número de toques hasta la primera exportación correcta y punto del embudo en el que cada participante abandonó (registrado mediante grabación de pantalla, no mediante autoinforme, porque lo que la gente dice que haría y lo que realmente hace rara vez coincide en un flujo de cinco pantallas).

Tres hallazgos y la solución para cada uno:

1. El paso “conectar cuenta” perdió al 40 % de los participantes, no porque la integración fallara, sino porque el botón de confirmación estaba en la esquina superior derecha, una zona que queda fuera del alcance cómodo del pulgar con una sola mano en la mayoría de los tipos de agarre. Solución: mover la acción principal al tercio inferior de la pantalla, la zona que todos los métodos de la matriz anterior señalaron como accesible sin cambiar el agarre.
2. Los participantes expuestos a la luz directa del sol no vieron un enlace de “omitir” de bajo contraste que se leía bien en interiores y desaparecía con el reflejo, así que recurrieron por defecto al camino manual, más difícil, en lugar del atajo. Solución: aumentar la relación de contraste y probarla al aire libre antes de darla por buena, ya que una revisión solo en interiores dará por válida una pantalla defectuosa.
3. Una llamada telefónica interrumpió tres de las cinco sesiones, y dos de esos tres participantes perdieron por completo su progreso en el onboarding y tuvieron que empezar de nuevo desde la primera pantalla. Solución: guardar el estado del formulario localmente para que una interrupción, que es un comportamiento normal en móvil y no un fallo de la prueba, no le cueste al usuario su progreso.

Ese tercer hallazgo es el que una prueba al estilo escritorio no puede producir por su propia estructura, porque a un participante de escritorio en una sala silenciosa no se le interrumpe en el momento justo. Solo aparece cuando el protocolo de prueba deja espacio para las condiciones del mundo real en lugar de eliminarlas a base de control.

Pruebas de usabilidad frente a pruebas de accesibilidad: preguntas distintas

Es fácil mezclar ambas cosas porque las dos implican observar a alguien usar una aplicación, pero responden a preguntas distintas con criterios de aprobación distintos. Las pruebas de usabilidad se preguntan si una persona puede completar la tarea y con qué facilidad. Las pruebas de accesibilidad se preguntan si todas las personas pueden hacerlo, incluida quien use VoiceOver, TalkBack o el control por botón, conforme a un estándar definido como WCAG 2.2. Una pantalla puede superar una prueba de usabilidad y aun así no cumplir con la accesibilidad, y también ocurre lo contrario. Para la parte de cumplimiento normativo, la lista de verificación y el proceso de pruebas con tecnologías de apoyo, consulte la guía de QAwerk sobre pruebas de accesibilidad de aplicaciones móviles.

Cuándo las pruebas de usabilidad de aplicaciones móviles no son la opción adecuada

No todas las versiones necesitan un estudio completo. Un pequeño cambio de texto o una corrección que solo afecta al backend no justifica reclutar participantes; un recorrido interno de cinco minutos con alguien que no conozca el flujo detectará los problemas evidentes. Y las pruebas remotas no moderadas son la herramienta equivocada cuando necesita entender por qué alguien no completó una tarea y no solo que no la completó; esa pregunta requiere una sesión moderada, aunque cueste más por participante. Usar el método caro para responder una pregunta que el barato ya responde es una forma habitual de agotar los presupuestos de usabilidad antes de llegar al flujo que realmente necesita ese escrutinio.

Cómo realiza QAwerk las pruebas de usabilidad de aplicaciones móviles

El proceso de pruebas de usabilidad de QAwerk combina pruebas de pasillo, evaluación heurística y sesiones estructuradas basadas en tareas en dispositivos iOS y Android reales en lugar de simuladores, y comprueba el flujo de navegación, el comportamiento de los elementos interactivos y si la aplicación cumple realmente el objetivo para el que el usuario la abrió. En Unfold, la aplicación de creación de contenido que ahora pertenece a Squarespace, esa combinación de pruebas funcionales y de usabilidad en 8 dispositivos iOS y 12 Android sacó a la luz más de 1.000 errores y más de 2.800 escenarios de prueba antes de lanzamientos que ayudaron a la aplicación a mantener una valoración de 5 estrellas en el App Store; el caso práctico de Unfold completo ofrece todos los detalles.

Como QAwerk realiza pruebas en cualquier fase, no solo cuando la compilación está terminada, las sesiones de usabilidad pueden hacerse sobre un prototipo navegable antes de gastar un solo sprint en construir el flujo equivocado, o sobre una aplicación en producción para detectar lo que solo aparece tras el lanzamiento. Consulte el proceso de pruebas de usabilidad completo o los servicios de pruebas de aplicaciones móviles en su conjunto si la usabilidad es solo una parte de una revisión más amplia previa al lanzamiento.

Lista de verificación de pruebas de usabilidad de aplicaciones móviles

Tanto si se trata de un estudio completo con cinco participantes como de una comprobación interna rápida, las pruebas de usabilidad de aplicaciones móviles se reducen a cinco aspectos que conviene verificar antes de dar un flujo por terminado:

• Alcance del pulgar: las acciones principales se sitúan en los dos tercios inferiores de la pantalla, no en las esquinas superiores.
• Tamaño de los objetivos táctiles: los elementos interactivos miden al menos 44x44pt (iOS) o 48x48dp (Android), con un espaciado real entre objetivos adyacentes, no solo un relleno visual.
• Recuperación de errores: una acción fallida (conexión perdida, toque equivocado, flujo interrumpido) le indica al usuario qué ha pasado y cómo volver a intentarlo, sin que pierda el punto en el que estaba.
• Resistencia a las interrupciones: el estado del formulario y del flujo se conserva tras una llamada telefónica, el paso de la aplicación a segundo plano o un aviso de batería baja.
• Uso con una sola mano: la tarea principal se puede completar con una sola mano, probada en el dispositivo real y no solo revisada en una réplica de la pantalla en un ordenador.

Preguntas frecuentes

¿Cómo se hacen pruebas de usabilidad de una aplicación móvil?

Reclute participantes que se correspondan con su base real de usuarios, asígneles tareas realistas en el dispositivo real (no en un simulador ni en una réplica en el ordenador) y combine al menos dos métodos, normalmente una sesión moderada para entender el “porqué” y pruebas de guerrilla o no moderadas para las condiciones del mundo real, ya que ningún método por sí solo detecta a la vez los fallos de razonamiento y los del entorno.

¿Cuáles son los métodos de pruebas de usabilidad móvil?

Los cuatro métodos principales son las sesiones moderadas en el dispositivo, las pruebas remotas no moderadas con captura de pantalla y rostro, las pruebas de guerrilla en el entorno real del participante y los estudios centrados en el primer arranque o el onboarding. Cada uno apunta a un tipo de fallo distinto, y la mayoría de los productos móviles necesitan más de uno a lo largo de su ciclo de vida.

¿Cuántos usuarios se necesitan para las pruebas de usabilidad de aplicaciones móviles?

Cinco participantes por segmento de usuarios y por ronda de pruebas suelen sacar a la luz la gran mayoría de los problemas de usabilidad en una primera pasada. Cada segmento de usuarios distinto necesita sus propios cinco; en las pruebas remotas no moderadas suele merecer la pena ampliar a entre 15 y 30 participantes para cubrir más dispositivos y condiciones de red.

¿Las pruebas de usabilidad de aplicaciones móviles son lo mismo que las pruebas de accesibilidad?

No. Las pruebas de usabilidad comprueban si un usuario típico puede completar una tarea con facilidad. Las pruebas de accesibilidad comprueban si los usuarios que dependen de tecnologías de apoyo pueden completarla en absoluto, conforme a un estándar como WCAG 2.2. La mayoría de los programas de QA móvil necesitan ambas, realizadas por separado.

¿Cuánto dura una ronda de pruebas de usabilidad de aplicaciones móviles?

Una ronda moderada con cinco participantes suele durar de una a dos semanas de principio a fin, incluidos el reclutamiento, las sesiones y un informe de hallazgos. Las rondas de guerrilla y no moderadas avanzan más rápido, a menudo de tres a cinco días, porque no hay que programar a un moderador.