Blog

820

Juicio experto 

 La evaluación heurística fue creada por Jakob Nielsen y sus colegas a mediados de los años noventa. Su objetivo es hallar, antes de hacer tests de usuario, los problemas más comunes de usabilidad en el diseño de interfaces.

Hay muchas maneras de evaluar un sistema interactivo. En los métodos empíricos hay personas reales probando el software. También es posible tener métodos formales en los cuales se construye un modelo de cómo se comportan las personas en una situación particular. Si no puedes construir un modelo formal cerrado, también puedes probar tu interfaz con simulaciones y hacer pruebas automatizadas que pueden detectar tanto errores de uso como diseños efectivos. Esto último funciona bien para cosas específicas, aunque no tanto para cosas más generales.

En este artículo me voy a concentrar en hablar de los enfoques basados en la crítica, donde las personas hacen críticas directas basadas en su experiencia o por medio de heurísticas. También recibe el nombre de juicio experto. Se puede recibir el análisis heurístico o juicio experto en cualquier etapa del proceso de diseño, pero cabe destacar un par de etapas particularmente valiosas:

  • antes de hacer pruebas con usuarios: esto evita que desperdicies el tiempo de los usuarios con detalles que ellos notarán automáticamente. Es mejor enfocar los valiosos recursos de las pruebas con usuarios a cosas que los expertos no son capaces de captar.
  • antes de rediseñar la aplicación, porque puede demostrar que partes son más problemáticas y merecen rediseñarse. A veces hay problemas y son necesarios datos para convencer de hacer los cambios a los otros interesados. El juicio experto puede ser un buen modo, especialmente si está estructurado, de recibir la retroalimentación necesaria para hacer los cambios que se necesitan.
  • antes de lanzar el software, porque ayuda a hacer un lijado final de todo el diseño.

Al igual que la mayoría de las evaluaciones, usualmente es útil comenzar con un objetivo claro, incluso si lo que al final aprendes es completamente inesperado. Es una técnica realmente valiosa porque te permite recibir retroalimentación muy rápido. La idea básica es que vas a proporcionar a un conjunto de personas, los interesados en el proyecto u otros expertos en diseño externos, un conjunto de heurísticas o principios, y van a usarlos para buscar problemas en tu diseño. Primero, cada uno de ellos va a hacer esto de forma independiente y al final del proceso se van a reunir para hablar sobre lo que encontraron. Este “independiente primero, reunidos después” es la forma de obtener una sabiduría de las multitudes. Algunos problemas serán identificados por pocos evaluadores (errores difíciles de detectar) y otros problemas serán detectados por casi todos (errores fáciles de detectar). Ningún evaluador será capaz de encontrar todos los problemas, y algunos encontrarán más problemas que otros. A medida que añades más evaluadores, se encuentran más problemas; pero con el tiempo empezarán a repetirse, y finalmente se pierde el beneficio de añadir evaluadores. ¿Cuándo llegamos al máximo de esta curva? Dependerá de la interfaz de usuario con la que estés trabajando, de cuánto le pagues a las personas, del tiempo invertido… La regla de oro de Jakob Nielsen es de tres a cinco personas. En un estudio realizado por Jakob Nielsen, estimó que el costo de los problemas encontrados mediante la evaluación heurística era de 500.000 dólares y que el costo de llevarla a cabo fue de un poco más de 10.000. Estimó una razón de beneficio-costo de 48 para esta interfaz en particular. Obviamente, este es un número preliminar y tus cálculos variarán. Puedes pensar en cómo estimar el beneficio de algo así si cuentas con algún tipo de herramienta interna para medir incrementos en la productividad. Si estás creando un sistema de reporte de gastos o un sistema interno que haga que las personas usen el tiempo de manera más eficiente, podrás medir las ganancias creadas por el uso de tu sistema. Si es software que estás planeando que esté disponible en el mercado, puedes pensar en los beneficios de las ventas y cosas similares. Con un grupo pequeño de personas es muy probable que detectes los errores más importantes.

Por otro lado, esta es una técnica que se puede usar indistintamente en interfaces o en bocetos. Así, la evaluación heurística funciona muy bien en conjunto con prototipos de papel y otras técnicas de baja fidelidad que puedes usar para obtener ideas de diseño rápido. Si comparamos la evaluación heurística con una prueba con usuarios, veremos que la evaluación heurística puede ser mucho más rápida. Solo nos toma una o dos horas por evaluador, mientras que las pruebas con usuarios pueden tomar más tiempo. Además, los resultados de la evaluación heurística pueden ser ‘pre-interpretados’ porque los evaluadores están entregando directamente problemas y cosas que arreglar y te ahorran el tiempo de tener que inferir cuál podría ser el problema o la solución. Sin embargo, la otra cara es que cuando los expertos usan tu sistema, estos pueden generar falsos positivos que de hecho no sucederían en un entorno real.

Estas son las fases de una evaluación heurística:

1/ Exploración: el primer paso será dar información a los evaluadores sobre la historia detrás de tu software, cualquier conocimiento del dominio que vayan a necesitar, y contarles algo del escenario a través del cual les vas a pedir que transiten. Después indica a los evaluadores que usen tu diseño para ejecutar un par de tareas, y haz que cada uno realice cada tarea con cuidado, paso a paso, varias veces. Cuando estén haciendo esto, deben tener la lista de principios de uso como recordatorio de las cosas a las que deben prestar atención. Las diez heurísticas de Nielsen son una buena lista, pero puedes aumentarlas con cualquier otra cosa que sea relevante para tu dominio. Si hay metas particulares de diseño que estás buscando, o cosas que has visto que funcionan en otros diseños, esas también son metas importantes y pueden incluirse en la lista de heurísticas.  Puede ser necesario que los evaluadores revisen dos veces el sistema o proceso: en la primera obtienen una idea del escenario y en la segunda pueden enfocarse en elementos más específicos.

2/ Evaluación individual: cada uno de los evaluadores asignan de forma independiente una calificación a cada uno de los problemas que hayan detectado. Las clasificaciones de los evaluadores van a combinar: frecuencia, impacto y ubicuidad del problema que están viendo en la pantalla. Es decir, si es algo que aparece solo una vez y que es un error pequeño o si es algo que aparece en toda la interfaz. Para cada problema detectado hay que especificar lo siguiente:

  • Principio heurístico que no ha sido respetado.
  • Descripción del problema, que detalla cómo reproducirlo, o da una explicación de la dificultad que provoca.
  • Captura de pantalla, para mayor claridad.
  • Severidad del problema. Se asignará un número siguiendo este criterio:

0 – es algo peculiar, pero no un problema de usabilidad.
1 – problema meramente estético.
2 – problema de usabilidad leve.
3 – problema de usabilidad severo. Es importante solucionarlo.
4 – problema de usabilidad catastrófico. Es necesario solucionarlo.

3/ Evaluación grupal: a continuación hay que reunir a los evaluadores y producir un informe agregado con toda la información. En esta fase se combinan todos los problemas que se han detectado, quitando los que están repetidos. También pueden ser agrupados y ordenados por frecuencia.

4/ Análisis con el equipo de diseño y desarrollo: se discuten los problemas generales de la interfaz y se exponen las problemas particulares. Aquí tienes la oportunidad de revisar punto por punto y de sugerir mejoras sobre cómo abordar estos problemas. En la sesión de análisis será valioso para el equipo de desarrollo estimar el esfuerzo requerido para arreglar esos problemas. Por ejemplo, si tienes algo con una calificación de uno y no es tan importante pero es fácil de corregir, simplemente corrígelo. Hay otras cosas cuya importancia relativa en relación al costo simplemente no las hace tan relevantes de arreglar al momento. Esta sesión de análisis puede ser una excelente ocasión para sugerir ideas para diseños futuros, especialmente si todas las personas clave están reunidas.

 

Comentarios ( 820 )

    The comments are now closed.