Testeando sistemas con una caminata heurística

Testear el sistema es como hidratarse. Deberíamos hacerlo siempre, pero es muy fácil olvidarse y tomar solo el agua necesaria para no atragantarnos al comer o porque nos dio sed. Testear el sistema es igual, deberíamos hacerlo constantemente, pero pasa la vida y no siempre le dedicamos el tiempo que quisiéramos. Por eso, hoy te voy a presentar la caminata heurística, una forma de testear que implementamos en el proyecto que estoy trabajando en Unagi. Veremos la teoría del ejercicio y nuestros aprendizajes después de ponerlo en práctica.

Qué es una caminata heurística

Cada vez que digo “caminata heurística” me imagino al equipo cual los Beatles caminando por el sistema.

La realidad es que el ejercicio propuesto por NN/group está lejos de parecerse al GIF.

Cómo hacerla

1. Reunir a las personas participantes. Empezamos por conseguir personas que vayan a participar de nuestra actividad. Lo ideal sería conseguir unas 5 personas y que no estén relacionadas con el sistema, así nos dan feedback sin sesgarse. Nosotros, sin embargo, lo hicimos con el propio equipo.

2. Testear. Estas personas se ponen en el rol de usuario y prueban el sistema. Idealmente habría que definir un flujo o funcionalidad para que el alcance sea más reducido. En nuestro caso testeamos todo el sistema, jugamos a la situación ideal, a romperlo, al buscarle el pelo al huevo, toooooodo.

3. Documentar todo. Como documentar es nuestra religión, lo dejamos por escrito: indicamos qué pasa, dónde e idealmente adjuntamos captura de pantalla. Particularmente para esta ocasión utilizamos Docs de Google, para que cada cual pudiera escribir sin sesgarse.

4. Clasificar los datos recopilados. Luego viene la parte menos “divertida” de organizar toooodos estos datos para convertirlos en información valiosa. Juntamos todo lo que se reportó, vemos cuántas veces se repite cada cosa y les asignamos valores de gravedad. Manejamos una escala de 1 a 4, donde:

  • 1 es solo algo visual, que no afecta al funcionamiento.
  • 2 es algo básico que puede afectar al sistema.
  • 3 ya es algo importante que afecta a cumplir el objetivo.
  • 4 es un error fatal que no permite al usuario cumplir su objetivo.

5. Generar soluciones. Así, con todo clasificado, agrupamos por nivel y resolvemos de mayor a menos proridad. En nuestro caso, resolver consistió en buscar solución principalmente desde diseño, algunas en conjunto con desarrollo y, por último, implementarlas. Algunos ejemplos

En esta pregunta había radio buttons en lugar de checks y la respuesta era crucial para el paso siguiente del cuestionario.
Algo que nos pasaba y se repetía mucho era que el sistema cuenta con varios cuestionarios cada uno con varios pasos y, sin embargo, al acceder a cualquiera de ellos solo podías volver a la pantalla original y no al paso anterior o continuar a la pantalla siguiente. Para resolver esto se sugirió que el botón de “volver” volviera a la pantalla inicial y agregamos un botón de “anterior” para regresar a la anterior pregunta.

Beneficios

  1. En lo personal, estuvo buenísimo poder implementar algo que siempre se ve en teoría de UX y pocas veces se lleva a la práctica. Que al equipo le haya gustado, se haya copado y haya colaborado me pareció lo más enriquecedor y gratificante.
  2. El cliente se copó y supo verle el valor que aportaba. Lo cual fue valioso para el equipo y para el área de UX.
  3. En cuanto al proyecto, nos permitimos testear el sistema antes de sacarlo a producción y recalcular/mejorar/incorporar varias cosas. Fue un ejercico que se hizo rápido y en poco tiempo. Se prepararon las instrucciones, porque era la primera vez, después cada cual le dedicó un rato a testear y documentar y luego se dedicó tiempo para la clasificación y análisis de cada cosa reportada.
  4. Mejora la usabilidad del sistema. Al probarlo podemos recalcular y aprender, saber qué cosas mantenemos y cuáles cambiamos. Nos salimos de la teoría.
  5. Promueve la búsqueda de soluciones. Nos puso en la situación “incómoda” de ver nuestros propios errores o incoherencias y en la necesidad de buscarles soluciones.

Aprendizajes

Con el diario del lunes es muy fácil decir qué no hacer. Pero básicamente algunas cosas que aprendimos fueron:

  • La teoría tenía la razón y con probar 5 personas alcanzaba y sobraba. Nielsen dice que con testear con 5 personas cubrimos el 80% de las cosas que puedan surgir, que el resto es pérdida de tiempo. Tal vez, la próxima convenga mezclar potenciales personas usuarias, alguien de nuestro lado y alguien del lado del cliente. Más gente es mucho volumen de información a procesar para llegar a los mismos resultados, por lo que no vale realmente la pena.
  • Tenemos que pulir nuestra capacidad de enunciar problemas y limitarnos a enunciarlos antes de saltar a soluciones. Al procesar los resultados descubrí que todes habíamos hecho lo que queríamos con la consigna y en pocas oportunidades reportamos un problema como tal y ya (no solo me incluyo, sino que me pongo primera en la lista). Poníamos sugerencias, posibles soluciones, marcábamos hechos sin decir qué era lo que estaba mal o dejábamos opiniones y nos olvidábamos de explicar por qué estaba mal algo. En definitiva, fuimos capaces de ver todo lo que era mejorable o cambiable pero no de expresarnos con propiedad. Para que entiendan de lo que hablo les dejo algunos de mis ejemplos más graciosos y como deberían haber sido:

Claramente había un problema detrás de muchas de las cosas que reportamos y dijimos mal, pero hubo que hacer todo un trabajo de interpretación de qué era lo que estaba haciendo ruido en cada caso para poder solucionarlo.

  • Si repetimos el ejercicio estaría genial reducir su alcance. Analizar e implementar los cambios se tornó algo larguísimo, interminable y tedioso, pero porque habíamos mapeado más de 20 flujos. O sea, se nos fue la mano.

Estuvo buenísimo parar la pelota, ponernos en los pies de los usuarios y proponer mejoras y cambios necesarios. Al final, parar a tomar agua era necesario y los beneficios se ven a simple vista.