15 errores frecuentes en un test de usabilidad con usuarios

Hacer un test de usabilidad es muy simple y, en el formato más clásico, requiere poca logística y un costo muy bajo. Lo más simple sería estar sentado al lado de un usuario y pedirle que haga algo – una tarea – con un producto o interfaz (un sketch, wireframe, diseño acabado o sitio web, aplicación móvil, tótem, etc.).

Si es tan simple, ¿significa que cualquiera lo puede hacer? En teoría, sí.

En la práctica, un test con usuarios puede presentar cierta complejidad y los resultados y la interpretación se pueden ver afectados por una serie de errores comunes. A continuación te presentamos algunos errores que hemos visto a lo largo del tiempo y consejos para no caer en la trampa.

1. No tener una pauta o protocolo de testeo

La base para empezar a testear es definir qué se va a testear, cómo y con quien. Que el test de usabilidad sea remoto o presencial, el protocolo de testeo debe incluir detalles como:

• el mensaje de bienvenida / introducción,
• las tareas específicas, si las hay,
• las instrucciones para el usuario,
• las instrucciones para el moderador o facilitador y
• aspectos importantes a observar.

Ser sistemático no significa dedicarle demasiado tiempo a esta etapa de planificación, es ser riguroso para sacarle mayor provecho al proceso de testeo.

2. Ser demasiado rígido con la pauta o el protocolo

Por la naturaleza de la prueba, esta situación se da más seguido en modo presencial que remoto: el moderador sigue al pie de la letra el protocolo y pierde oportunidades.

Para sistematizar y tener resultados comparables, es importante seguir la pauta y el protocolo. Sin embargo, el moderador de un test de usabilidad presencial debería tener la autonomía y la agilidad para identificar oportunidades más allá de las instrucciones iniciales, y aprovechar estas oportunidades mientras cuenta con el usuario disponible para llegar a nuevos hallazgos.

Digamos que estamos testeando un sitio eCommerce donde tenemos que validar algunas hipótesis, entre otros objetivos del test. Si seguimos las instrucciones, probablemente podamos validar los supuestos, pero si dejamos que el usuario haga otras tareas libremente, seguramente surgirán otros hallazgos.

3. Olvidarse de testear el protocolo y calibrar

Cualquiera sea el tipo de test de usabilidad que estás llevando a cabo, presencial o remoto, es importante testear el protocolo para validar las instrucciones, asegurarse de que las tareas que se deben completar se entendieron y que el lenguaje utilizado es simple y claro.

Dicho en otros términos, hay que testear el test. De otra forma, si nos equivocamos en la elección de una palabra y lo vemos cuando ya el moderador realizó varias sesiones, estamos perdiendo tiempo y dinero ya que hay que aumentar la cantidad de usuarios participantes.

4. No considerar distintos segmentos de usuarios que tienen comportamiento y necesidades diferentes

Una vez nos dijeron “cada vez que hacemos cambios drásticos y pensamos mejorar, estamos colapsando el call center”. Eso significa que, si bien el equipo de diseño y desarrollo en cuestión estaba haciendo mejoras y simplificando la interfaz, el usuario frecuente ya conocía las "manías” del software y estaba acostumbrado a apretar 3 veces seguido Enter para llegar a la pantalla principal, por lo que cambiarle este flujo significó sacarlo de su rutina. Se perdía y por eso llamaba al call center.

A veces, es el pasaje necesario a muy corto plazo para generar mejoras de la experiencia a mediano plazo. Otra veces, es un riesgo que hay que asumir si a la larga se quiere mejorar la experiencia del usuario. En este caso, un segmento importante a considerar son los usuarios nuevos quienes, si tienen problemas, es porque no conocen la interfaz y no están acostumbrados a ella. Por lo tanto, el periodo de aprendizaje es lento.

5. Obsesionarse con la segmentación sociodemográfica y el perfilamiento

El foco es testear, obtener insights y resultados concretos para, finalmente, mejorar una interfaz y la experiencia del usuario, no filtrar bases de datos.

Ocupar demasiado tiempo y recursos filtrando bases de datos de clientes para reclutar a EL usuario perfecto y elegirlo con pinzas, no es siempre un proceso rentable. A lo mejor, conviene más invertir estos recursos en construir más escenarios de testeo y probar con una mayor variedad de usuarios para conseguir más hallazgos.

6. Influenciar o alterar los resultados a través de las instrucciones

Aquí podríamos indagar más, y lo haremos a futuro, pero un detalle a planificar cuidadosamente es la elección de las palabras en la comunicación con el usuario durante el testeo, la formulación de las instrucciones y evitar la entrega de “ayuda” o “tips” durante la ejecución de las tareas.

7. Esperar que el usuario nombre el problema

Durante el test de usabilidad podemos identificar una serie de problemáticas. En algunos casos los problemas son evidentes: el usuario no encuentra la información, no ve dónde está ubicado el carrito de compras, no entiende una etiqueta, etc.

En otras situaciones el problema es más complejo e identificar que hay un problema y cuáles son sus causas es la tarea del moderador y del analista o del consultor (puede ser la misma persona).

8. Esperar que el usuario nos diga cómo solucionar el problema

Proponer soluciones a un problema de usabilidad puede ser una tarea desafiante, pero una cosa es cierta: es el trabajo del equipo que está detrás de la interfaz y no del usuario.

Una vez más, el test con usuarios no es un focus group (donde sí se podría pedir a los participantes que pensaran en alternativas posibles).

Si dentro del protocolo de testeo hay una pregunta de tipo “¿Cómo harías este paso más simple?”, deberías considerar eliminarla y dedicarte a observar mejor, analizar los resultados o mejorar el diseño y volver a testear.

9. No complementar el análisis con otra fuente de data

Pensar que el test de usabilidad es LA fuente de información que te dirá qué hacer para optimizar los resultados y confiar solo en esta metodología es ilusorio.

Algunas otras metodologías de investigación y fuentes de data relevante que deberías analizar son:

• métricas de tráfico (de Google Analytics, por ejemplo),
• mapas de calor de aplicaciones como Clicktale o Crazyegg,
• grabaciones de secuencias de navegación,
• análisis de casos partiendo de solicitudes recibidas a través del correo o redes sociales,
• análisis de performance de contenido,
• investigación cualitativa a través de entrevistas,
• encuestas de satisfacción,
• benchmarking,
• investigación con usuarios internos como ejecutivos de atención o vendedores, etc.

10. No tener indicadores de éxito

Si bien un test de usuario puede ser exploratorio en una primera etapa, es importante definir indicadores a la hora de sistematizar el proceso y los resultados.

¿Qué se va a evaluar? Algunos indicadores de resultados para un test de usabilidad:

• Tasa de éxito en la resolución de una tarea.
• Tiempo necesario para completar una transacción.
• Tiempo necesario para encontrar una información.
• Tasa de abandono de la tarea.

11. No comparar alternativas de diseño

Cuando estamos realizando un test de usabilidad para una interfaz nueva, hay un desafío en cuanto a las propuestas de flujos de interacción que se van a probar. Contar con una sola alternativa puede limitar demasiado los resultados del test.

¿El flujo transaccional debiese tener 3 o 4 pasos? ¿El llamado a acción es claro y concreto? Es preferible tomar este tipo de decisiones de diseño comparando la efectividad de varias alternativas.

12. No seguir testeando después

Felicitaciones, empezamos a testear, tenemos una lista de tareas pendientes y prioridades de trabajo para las próximas semanas. ¿Y ahora?

Si estamos mejorando la experiencia del usuario en una interfaz digital existente, seguramente aún queda mucho por hacer. Si, de lo contrario, estamos diseñando un sitio web o aplicación, es importante integrar el testeo como parte del proceso de diseño y testear en las etapas principales pre y poslanzamiento.

En ambos casos, recordemos que el test en sí no es una finalidad sino que un medio para diseñar experiencias notables.

13. Confundir la metodología

El test de usabilidad con usuarios no es lo mismo que la investigación con usuarios. No es lo mismo que “salir a la calle”, en lenguaje de startup, para testear un producto mínimo viable (PMV). No es una prueba de compatibilidad en navegadores, un test A/B, una encuesta de satisfacción, un focus group, una prueba de gustos o preferencias, etc.

Entender las diferencias entre cada método y saber explicar internamente o evangelizar, es asegurarse de que todos los actores involucrados manejen un lenguaje común.

Ojo con querer testear alternativas tipo botón amarillo versus botón rojo. Para testear diferencias pequeñas y obtener data significativa a partir de una muestra mayor, es preferible considerar pruebas tipo A / B testing. El test de usabilidad no es la mejor metodología para medir el impacto de este tipo de variable.

14. Extrapolar la tasa de éxito a otros KPIs más complejos o simplemente diferentes

Pensar que un test de usabilidad exitoso significa transacción exitosa, conversiones alucinantes o ventas una vez que la interfaz esté en producción, es asumir una relación de causalidad ignorando el impacto de otras variables.

Nos hemos encontrado con situaciones donde a raíz de un test con usuarios se mejora (y se valida que se mejoró) un flujo transaccional, pero que, una vez “al aire”, los resultados dejan qué desear. Pocos usuarios realmente ocupan el flujo respectivo, lo que genera pocas transacciones y, finalmente, el equipo interno declara que no se cumplieron los objetivos; es casi un fracaso.

¿Significa que el resultado del test fue equivocado? ¿O que la transacción está mal diseñada? No necesariamente. Los bajos indicadores de resultados (o, KPIs de key performance indicators, en inglés) pueden atribuirse a otras causas como, por ejemplo, una arquitectura de información deficiente: dentro del mar de información del sitio, la transacción se pierde.

A diferencia de la instancia del testeo, cuando el usuario debe cumplir con la tarea de llevar a cabo una transacción, un pago en línea por ejemplo, partiendo desde el paso 1 y terminando al paso x, cuando el pago está en producción y el usuario debe pasar por la home, el acceso a la transacción “compite” con otros elementos de contenido. Otro ejemplo: cuando la nueva funcionalidad está al aire, el lanzamiento coincide con problemas de hosting, por lo que el tiempo de carga de la página aumenta y los usuarios abandonan la transacción.

Para evitar este tipo de falso problema causa – efecto, es importante analizar en profundidad qué está pasando y contar con fuentes complementarias de información, tanto cualitativa como cuantitativa.

15. Esperar más de lo que se deberia de los resultados de un test de usabilidad

Si estás pensando que un test de usabilidad eliminará todos los riesgos frente a un cambio mayor de diseño, va a asegurar el éxito de una salida a producción o será sinónimo de un aumento en las ventas, deberías volver a reconsiderar el proceso y asegurarte que estás eligiendo el método correcto para el objetivo correcto.

Si, al contrario, para ti está claro, entonces estás en condiciones de comunicar a tu cliente y equipo de trabajo por qué estás haciendo un test con usuarios y qué deberían esperar de los resultados.

¿Qué otros errores frecuentes has observado en tests de usabilidad con usuarios?