miércoles, 15 de agosto de 2012

Algunas ideas a considerar a la hora de diseñar un dashboard

En dos líneas: algunas ideas y buenas prácticas a la hora de ponerse a diseñar un dashboard, y por diseño no estoy sólo hablando de los gráficos sino de los conceptos detrás de estos.

Hace unos días publicaba un post sobre un concurso de diseño de dashboards y he recibido algún mail en el que se me comentaba que el post no daba ninguna opinión de cómo vemos en CYD Consultores este aspecto del Business Intelligence cada vez más de moda a través del hype conocido como "visualization".

No pretendo escribir un manual sobre el tema, simplemente dejar algunas semillas en la mente del amable lector cuando pase a su rol de diseñados/consultor, por cierto, que estas ideas son tan válidas para el que trabaja con una potente solución de Business Intelligence como el que lo hace con una hoja de cálculo Excel.

En fin, aquí van algunas ideas al respecto:
  • Ten siempre muy claro qué van a hacer los usuarios con la información del dashboard, no es tan fácil como parece ya que hay muchos usuarios que no tienen claro que necesitan y, por otra parte los diseñadores / consultores suelen caer en el error de establecer un dashboard según lo que ellos piensan que necesita el usuario/s. No hay una respuesta clara a este problema salvo que el responsable del diseño en muchas ocasiones ha de ser paciente en su rol de evangelista y, al tiempo, estar dotado de una buena capacidad de escucha activa a la hora de entender qué narices quiere el cliente.
  • Para responder al primer punto ten siempre una "check list" con preguntas del estilo: ¿qué es lo que llevaría al usuario a utilizar este dashboard?, ¿de qué perfil de usuario hablamos?, ¿con qué periodicidad se utilizaría el dashboard?, ¿que tipo de decisones se van a tomar partiendo de este dashboard?, ¿se va a utilizar desde dispositivos tipo "mobile"?, ¿debe incorporar alarmas? en el caso de que la solución de BI lo permita, etc...
  • Hay que tener siempre al usuario en mente, debe ser central en el diseño, porque la inmensa mayoría de los usuarios deciden si les gusta o no un dashboard cuando lo ven y por motivos que me parecen las más de las veces basados en la mera intuición, le preguntas a un cliente ¿por qué te gusta más este dashboard que las propuestas anteriores? y rara vez te van a contestar con claridad, les gusta o no y ya está y hay que asumirlo.
  • Para evitar problemas graves con el punto anterior hay que aplicar cierto sentido estético, aunque hablemos de una herramienta de trabajo no tiene por que ser extremadamente fea, confusa o utilizar colores y texturas "agresivos".
  • De las tres ideas anteriores se deduce una tercera, la comunicación con el usuario es clave, hay que hablar con él de modo continuo durante el proceso de diseño e implementación, si se genera una comunicación abierta y sincera con el usuario este tenderá a considerar el diseño del dashboard como algo propio ¿y no es así como debe ser?.
  • Muchas veces hemos oído el dicho "una imagen vale más que mil palabras", pues se puede aplicar a los dashboards en su versión "un buen gráfico vale más que mil tablas numéricas", nuestro cerebro funciona mejor estableciendo relaciones basadas en tamaño, posición relativa, colores u otros atributos espaciales que estableciendo relaciones meramente numéricas. Hay que orientar el diseño para que los usuarios puedan "descubrir" patrones en los datos que proporciona el dashboard.
  • Ante el diseño previo de un dashboard siempre hemos de preguntarnos si es lo suficientemente consistente para que el usuario pueda usarlo sin dificultades y que entienda la información que proporciona.
  • Si te es posible utiliza colores y tamaño para llamar la atención del usuario sobre lo realmente importante, cada empresa y cada usuario es un mundo, pero hay que identificar cómo codifican lo importante para así poder usar esa codificación a la hora de construir "calls to action". Si un dashboard no llama la atención sobre lo realmente importante no merece la pena y, lo que es peor, nadie lo utilizará como herramienta para la toma de decisiones.
  • En el punto anterior hablaba de "codificación", hay que determinarla antes de ponerse con el diseño, esto no sólo aplica a colores, tipo de gráficos, etc... sino a aspectos tan "nimios" como el uso de los decimales, negritas, fuentes, uso de subtotales,.... En esto no hay reglas sino casos individuales, me remito a la experiencia de cualquier lector cuando ha trabajado en distintas empresas (o departamentos dentro de una empresa) y ha comprobado como los gustos en este tema presentan una gran variabilidad.
  • Se debe tener en cuenta como se generan "rutas" entre consultas y dashboards / scorecards, el consultor sabe que el usuario puede verse confundido por cambios en la tipología de gráficos, colores, etc.. cuando pasa de un dashboard a otro para intentar buscar respuestas, en definitiva, hay que mantener cierta coherencia.
  • Comprender con claridad los indicadores (KPIs) y como representarlos gráficamente, de nuevo parece obvio, pero os prometo que no lo es tanto.
  • Cuidado con las proporciones en los distintos ejes de un diagrama.
  • No todo el mundo comprende bien ciertos gráficos "3D", supongo que es un tema generacional.
  • Las "microcharts" son una gran herramienta para resumir la evolución de indicadores. 
Ejemplo dashboard con aplicando microcharts, fuente: http://www.juiceanalytics.com/
  • Al final hay que testear los diseños una y otra vez hasta que se consigue acertar, la "usabilidad" es la clave.
Os dejo además el siguiente vídeo resumen de un curso de diseño de dashboards, está en inglés y data del 2009 pero creo que puede resultaros de mucho interés:

No hay comentarios: