Evaluación Heurística (PARTE II)

Profundizamos en la teoría y la metodología que rodea a esta técnica fundamental a la hora de diseñar sistemas interactivos.

Group 5 Created with Sketch. 7 min
Comparte f in Created with Sketch.
Comparte f in Created with Sketch.

Gracias a la primera parte de esta doble publicación sobre las Evaluaciones Heurísticas, ya tenemos claro qué son y cuáles son sus principios más relevantes. Ahora toca centrarnos en la metodología para llevarlas a cabo. Para ello, casi como si de una noticia se tratara, se detallan una serie de preguntas clave para arrojar luz sobre el proceso de ejecución de una Evaluación Heurística (de ahora en adelante EH).

¿Cuándo?

La EH es relativamente rápida y ágil, por lo cual se puede realizar prácticamente en cualquier momento del ciclo de avance de un proyecto.

  • En fases iniciales de un proyecto, es cuando se adapta mejor y se obtienen mejores resultados. Como no hay material suficientemente firme para efectuar un test con usuarios, se pueden proporcionar maquetas sobre papel o prototipos para detectar los primeros problemas de usabilidad. 
    Se recomienda que antes de realizar un test con usuarios se haga una EH, para así detectar rápidamente errores potenciales que seguramente se confirmarán a posteriori en los tests.
  • Durante el desarrollo se pueden realizar EH sobre primeras versiones, para localizar y corregir errores a bajo coste.
  • Sistemas en funcionamiento. Las EH suelen ser una muy buena ‘carta de presentación’ a la hora de vender servicios de consultoría de UX a clientes con aplicaciones o webs ya implantadas.

¿Por qué?

  • La EH proporciona un feedback rápido y relativamente económico, en comparación con otras técnicas. Ya que además de emplear pocos recursos materiales y humanos, requiere de menor tiempo de preparación y ejecución que otras técnicas.
  • Se puede aplicar en cualquier fase del proyecto, obteniendo sobre todo buenos resultados en fases tempranas del proyecto.
  • Existe la posibilidad de combinarla con otras metodologías de test de la usabilidad. De hecho, como se ha comentado, se recomienda que se haga una EH antes de un test con usuarios.
  • Es intuitiva y resulta fácil motivar a los evaluadores potenciales involucrados.
  • Se requiere de conocimiento y experiencia para aplicar los heurísticos de forma efectiva.
  • Por lo anterior, y en comparación con otras técnicas más de ‘guerrilla’, las EH pueden llegar a consumir recursos temporales. Sobre todo por lo que se refiere a la búsqueda de expertos de usabilidad, ya que o bien son difíciles de encontrar o bien de formar.
  • A veces, puede ser difícil aislar la subjetividad de los expertos evaluadores.
  • A menudo, muchos de los errores identificados pueden resultar ‘falsos positivos’, que realmente no corresponden a errores de usabilidad. Por ejemplo, en el artículo ‘Usability testing vs. heuristic evaluation: A head-to-head comparison’ de Robert W. Bailey et al., se postula que el 43% de los problemas identificados en una EH no son ‘problemas reales’. De hecho, solamente el 33% se podrían clasificar como problemas genuinos de las características del diseño de la UI.
  • Al participar distintos expertos, existe un esfuerzo extra a la hora de recopilarjuntar y sintetizar sus distintos informes de resultados.

¿Dónde?

Seguramente, este sea el punto menos trascendente a la hora de realizar esta técnica. Tanto si se está realizando una EH de ‘guerrilla’ como una de más académica con profesionales y evaluadores del sector, no se necesitará nada más que un terminal con el que visualizar la aplicación a evaluar (ya sea una aplicación móvil a través de un smartphone, como una página web desktop a través de un ordenador o portátil).

Como mucho, es conveniente que el entorno en el cual se desarrollará la EH sea similar para las distintas sesiones de inspección y para todos los evaluadores (espacio físico, condiciones ambientales, hora del día…), a fin de minimizar el impacto de factores externos que puedan afectar la capacidad cognitiva de los evaluadores.

Con esto se quiere remarcar que para ejecutar esta técnica no se necesitan muchos recursos. Intentando huir de una falsa percepción que, a veces, envuelve al universo UX, donde se piensa que solo se pueden realizar estudios en el marco de un laboratorio de usabilidad súper equipado.

¿Quién?

Uno de los puntos más cruciales a la hora de realizar una EH es la creación del equipo de evaluadores que la llevará a término. Que, recordémoslo, serán los encargados de analizar la interficie, interactuando con ella como si fueran usuarios medios reales.

Hay dos factores muy importantes, que en función de la naturaleza del proyecto, influirán directamente en la selección de este grupo: el número de participantes y su perfil.

Número de participantes

Una EH se puede realizar tranquilamente por un solo evaluador. Sin embargo, varios estudios de Nielsen y Landauer (1993) indican que se obtienen resultados bastante pobres cuando se depende de evaluadores individuales.

Asimismo, también llegaron a la conclusión que es mucho más ventajoso disponer de diversos expertos y evaluadores, ya que se encontrarán muchos más y diferentes problemas de usabilidad. No obstante, tal y como se aprecia en la gráfica de la figura 1, el número recomendado de expertos es entre 3 y 5. Ya que, disponer de más evaluadores no implica forzosamente a aumentar el número de hallazgos. De hecho, se aprecia en la gráfica que la curva de problemas detectados tiende a estancarse a medida que se aumenta el número de participantes.

(Figura 1) Cálculo promedio de problemas de usabilidad para seis interfaces. Fuente: “How to conduct a Heuristic Evaluation” (J. Nielsen).

Perfil de los participantes

Inicialmente, según la metodología tradicional de Nielsen y Molich, se sugería que se debía contar con evaluadores que tuvieran algún conocimiento mínimo sobre los principios de usabilidad. Posteriormente, se creyó que el método podía ser más efectivo cuando los evaluadores eran expertos en usabilidad.

Sin embargo, algunos autores sostienen que los profesionales de la usabilidad suelen detectar problemas que no responden al uso real de la aplicación, y es por eso, que plantean que es mejor que la inspección la lleven a cabo diferentes perfiles de evaluadores, como por ejemplo:

  • Desarrolladores. Tienen el inconveniente que suelen concentrarse en problemas técnicos, sugiriendo cambios que están fuera del alcance de la interacción persona-ordenador y que se relacionan más con la funcionalidad que con la interfaz del sistema.
  • Usuarios potenciales. A priori, los usuarios inexpertos pueden ser bastante confusos al realizar una EH. No obstante, se ha observado que si los usuarios conocen medianamente el sistema a evaluar o están involucrados en el proceso de diseño o desarrollo, entonces tienden a detectar problemas de usabilidad muy eficazmente.

¿Cómo?

Ahora que ya tenemos todos los ingredientes, solamente hace falta ver cómo los ligamos para llevar a cabo una EH de un sistema interactivo concreto. La metodología de trabajo propuesta, consta de tres fases: preparación, ejecución y análisis. A continuación, se enumeran las sub-tareas para cada una:

Preparación

  • Conocer el sector. Antes de empezar, es importante hacer un estudio del ámbito y contexto del sistema. Cada sector (finanzas, e-commerce, retail, administración, compañías de seguros, etc.) tiene sus normas o convenciones, que forzosamente se reflejarán en la interfaz del sistema a analizar y por supuesto, en la manera que trabajan sus usuarios reales.
  • Elección de los principios heurísticos. Se deben escoger los principios heurísticos que creamos que responderán a las necesidades del análisis. Un buen punto de partida es utilizar los celebres heurísticos de Nielsen, los cuales se recomienda actualizar y modificar con las directrices que creamos adecuadas para el proyecto.
  • Definición de las subheurísticas. Cada principio heurístico puede traducirse en una serie de preguntas de evaluación que harán más fácil el ‘mapeo’ entre los problemas de usabilidad y los principios. Para cada respuesta se establecerá una escalera de valores.

Como ya se vio en la Parte I de esta publicación, se recomienda usar la plantilla elaborada por Deniese Pierotti, de Xerox Corporation. (Si esta plantilla se rellena informáticamente, el proceso será mucho más ágil.)

(Figura 2) Ejemplo de plantilla elaborada por Deniese Pierotti, de Xerox Corporation. Fuente: ‘Heuristic Evaluation, A System Checklist’
  • Selección de los evaluadores. Siguiendo las directrices comentadas anteriormente y el volumen del sistema a analizar, se reclutará a un equipo específico en número y perfil.
  • Formar a los evaluadores. Se debe realizar una sesión informativa para estandarizar el proceso y garantizar que todos los evaluadores reciban las mismas instrucciones. De lo contrario, pueden salir resultados sesgados.

Ejecución

  • Puesta en marcha y entrenamiento. Una vez terminada la fase de planificación, los evaluadores procederán a la inspección de la interfaz individualmente. De este modo se asegurarán unos resultados imparciales e independientes.

Es importante que los expertos examinen la interfaz un par de veces antes de empezar la evaluación. Así podrán familiarizarse con la aplicación y sus distintos perfiles de usuarios.

Según J. Nielsen, se recomienda que una sesión de EH dure aproximadamente de 1 a 2 horas para cada parte de la interfaz que se quiere analizar. También es especialmente relevante que todas las sesiones se hagan en las mismas condiciones y entorno de trabajo.

  • Evaluación. Los evaluadores expertos proceden a evaluar la interfaz con el objetivo de detectar errores de usabilidad. Para ello deberán priorizar los hallazgos detectados indicando un grado de severidad para cada uno. Al tratarse de una medida subjetiva, estos grados deberán ser consensuados antes. J.Nielsen recomienda usar las siguientes tres medidas de valoración:
  1. La frecuencia con la que el problema ocurre. “¿Es común o poco frecuente?”
  2. El impacto del problema cuando sucede. “¿Es fácil o difícil de superar por los usuarios?”
  3. La persistencia del problema. “¿El problema se resuelve la primera vez que se usa el sitio web o aparece reiteradamente?”

Para ayudar a la jerarquización de la gravedad de los problemas detectados, Nielsen también plantea una escala de calificación adicional:

0- No es un problema de usabilidad.

1- Problema sin importancia. No necesita arreglarse a menos que haya tiempo de sobra.

2- Problema de poca importancia. Arreglarlo no tiene mucha prioridad.

3- Problema grave. Es importante arreglarlo.

4- Catástrofe. Es imprescindible arreglarlo.

Análisis

  • Informe final. Finalmente, todos los evaluadores harán una puesta en común de los resultados y puntuaciones individuales, con el fin de redactar un único informe final, donde se ordenarán los hallazgos de los más problemáticos a los que menos y se eliminarán los que sean duplicados o similares.

Para cada hallazgo se confeccionará una ficha compuesta por:

  • Descripción del problema de usabilidad detectado.
  • Propuesta de mejora del problema.
  • Pantallazo ilustrativo de la aplicación.
  • Lugar de la aplicación dónde ocurre.
  • Indicador numérico de la severidad del error.

Siguientes pasos

La EH solo sirve para vislumbrar posibles problemas de usabilidad. El siguiente e imprescindible paso es ratificar estas hipótesis en tests de usabilidad con usuarios reales. Una vez tengamos la certeza que uno de los hallazgos es un punto de dolor para los usuarios, procederemos a su resolución en el diseño e implementación de la herramienta.

Conclusiones

En esta doble publicación sobre las Evaluaciones Heurísticas, he querido profundizar en la teoría y la metodología que rodea a esta técnica fundamental a la hora de diseñar sistemas interactivos.

Según el balance de ventajas y desventajas anterior, se ha visto que lo convierte en un método barato, útil, indoloro y casi que diría, que imprescindible.

De modo que, si no lo conocías o bien aún no lo habías aplicado, no te lo pienses dos veces y ¡úsalo en tu proyecto! Eso sí, siempre con el usuario como centro de todo el proceso.

Group 5 Created with Sketch. 7 min
Comparte f in Created with Sketch.
Comparte f in Created with Sketch.