Diseno de dashboards SaaS: mostrar datos sin saturar al usuario

Un dashboard SaaS es la pantalla de inicio de un producto: una sola vista que le dice al usuario que esta pasando y que necesita una decision ahora. Stephen Few, autor del libro de referencia sobre el formato, lo define como la informacion mas importante para lograr un objetivo, dispuesta en una unica pantalla y legible de un vistazo. Los buenos lo consiguen en cinco segundos. Los malos muestran todo lo que la base de datos puede producir y dejan que el usuario se las arregle.

Esa segunda version es la mas comun. Un equipo lanza un producto, los datos crecen y cada responsable pide solo un grafico mas. A los seis meses el dashboard tiene treinta widgets, cuatro filtros y un scroll que no termina. Los usuarios dejan de leerlo: abren el unico informe en el que confian e ignoran el resto. Este articulo trata de las decisiones de diseno que mantienen un dashboard legible mientras crecen los datos que hay detras.

Por que un dashboard saturado te hace perder usuarios

La sobrecarga de informacion es el problema mas reportado en los dashboards, y tiene una causa mecanica. La memoria de trabajo humana retiene pocos elementos a la vez. En 1956 George Miller fijo el numero en siete, mas o menos dos; es una observacion sobre la memoria, no una regla rigida de interfaz, pero la direccion es correcta: pasado cierto umbral, la gente deja de comparar elementos y empieza a pasarlos por alto.

Un dashboard que muestra cuarenta numeros no informa cuarenta veces mejor que uno que muestra seis. Informa peor. El ojo no tiene un ancla, la metrica importante pesa igual que la inutil y el usuario gasta atencion en decidir donde mirar en vez de decidir que hacer. El coste no es estetico. Es mas tiempo hasta la primera accion, mas tickets de soporte que preguntan donde veo X y una funcion que nadie abre.

Por que anadir un filtro no lo arregla

Cuando un dashboard se siente saturado, el reflejo es anadir controles: un selector de fechas, un menu de segmentos, un interruptor por equipo. Los filtros ayudan al usuario experto que ya sabe que busca. No hacen nada por quien abre la pantalla en frio y necesita saber de un vistazo si hoy va bien o arde. Has movido el trabajo al usuario en lugar de hacerlo en el diseno. Mas controles tambien significan mas estado que recordar, lo contrario de lo que necesita una pantalla ya sobrecargada.

La misma trampa vale para anadir un segundo dashboard y luego un tercero. Ahora el usuario tiene que recordar que pantalla responde a que pregunta. El problema nunca fue el espacio. Era la jerarquia.

Que funciona de verdad

Empieza por el resumen y revela el detalle a demanda

La divulgacion progresiva (progressive disclosure) es el patron mas fuerte aqui. Muestra primero los pocos numeros que importan y deja que el usuario haga clic, expanda o profundice para el resto. Jakob Nielsen, que dio nombre al patron, lo describe como aplazar a una segunda pantalla las opciones avanzadas o poco usadas, para que las principales reciban toda la atencion. En un dashboard esto se ve como una fila superior con tres a cinco metricas clave, cada una de las cuales abre una vista de detalle al hacer clic. El fundador obtiene el estado en segundos. El analista sigue teniendo cada capa, a un toque.

Un dashboard, una tarea

Decide para quien es la pantalla antes de disenarla. Un dashboard pensado para un fundador que sigue el crecimiento y otro pensado para un responsable de soporte que vacia una cola no pueden ser la misma pantalla con widgets distintos pegados encima. Las vistas por rol reducen el numero de widgets, porque casi todas las metricas son irrelevantes para casi todos los roles. Si no puedes nombrar la unica pregunta que responde un dashboard, ese es el fallo, y ningun diseno lo arregla.

Respeta el numero, pero agrupa en vez de recortar

Apunta a unos cinco a nueve elementos en una sola vista. Tomalo como una senal de alerta, no como una ley: las opciones en pantalla no hay que memorizarlas porque siguen visibles, asi que el objetivo real es agrupar. Reune las metricas afines en secciones con etiqueta, para que el ojo lea tres grupos de cuatro en vez de doce fichas sueltas. Un grupo bien etiquetado de numeros relacionados se lee como una sola unidad: asi caben mas datos en una pantalla sin anadir carga.

Construye una jerarquia visual real

Pon la metrica mas importante donde el ojo llega primero, arriba a la izquierda en los disenos de izquierda a derecha, y dale mas tamano y contraste. Todo lo secundario baja de peso. Usa el color con mesura: una paleta donde cada ficha es de un color intenso distinto no tiene jerarquia, porque cuando todo grita nada destaca. Reserva el color saturado para el unico estado que pide una accion, un incumplimiento o una alerta, y deja en calma el resto.

Haz que cada numero signifique algo

Un numero solo no es informacion. 1.240 registros no dice nada hasta que sabes si sube o baja, y respecto a que. Acompana cada metrica clave con contexto: una comparacion con el periodo anterior, una linea de objetivo o una flecha de tendencia. Una metrica con un umbral, como 83% de la cuota con verde por encima del 80%, permite juzgarla sin hacer cuentas. Ese unico habito quita mas confusion que cualquier eleccion de tipo de grafico.

Disena los estados vacios y de carga

Los dashboards se ven tambien antes de tener datos: una cuenta nueva, una consulta lenta, un filtro que no devuelve nada. Si esos estados son una ocurrencia tardia, la primera impresion del producto es una pantalla que parece rota. Un esqueleto durante la carga, un claro aun no hay datos con una linea sobre como conseguirlos cuando esta vacio, y un fallback rapido cuando una consulta se ralentiza mantienen al usuario orientado mientras llegan los numeros.

Quita las metricas sobre las que nadie actua

Para cada metrica del dashboard, haz una pregunta: si este numero cambiara, alguien haria algo distinto. Si la respuesta es no, es una metrica de vanidad, y su sitio es un informe que se saca a demanda, no la pantalla que se mira cada dia. El total de registros de siempre da gusto y no cambia ninguna decision. Los registros de esta semana frente a la pasada cambian si hay que preocuparse. Recortar el primer tipo es la via mas rapida para liberar espacio y afinar la pantalla, y suele ser la mas dificil, porque cada una la pidio alguien.

Como se ve en la practica

Toma una herramienta de soporte cuyo antiguo dashboard tenia dieciocho widgets en un solo scroll. Lo reconstruimos alrededor de una pregunta que el responsable de soporte se hace de verdad cada manana: la cola esta bajo control. La nueva fila superior muestra cuatro numeros: tickets abiertos, tickets que incumplen el SLA, tiempo mediano de primera respuesta y resueltos de hoy. Los incumplimientos de SLA son el unico elemento rojo de la pantalla. Bajo el pliegue, tres secciones etiquetadas contienen el detalle: carga por agente, desglose por etiqueta y tendencia de los ultimos catorce dias. Todo lo que antes era un widget de primer nivel ahora esta a un clic dentro de una seccion. La pantalla se lee de un vistazo y el detalle sigue ahi para el analista que lo quiere. Los datos no se redujeron. La jerarquia hizo el trabajo.

Nada de esto es antes que nada un problema de diseno grafico. Es un problema de edicion. Un buen dashboard es sobre todo un conjunto de decisiones sobre que no mostrar en la primera pantalla. Movimiento, color y diseno refuerzan esas decisiones, pero vienen despues.