Cómo construir dashboards empresariales que el equipo realmente usa

El 80% de los dashboards que se construyen terminan abandonados en menos de seis meses. Después de haber visto ese patrón repetirse, aprendí dónde están los errores y cómo evitarlos.

El síndrome del dashboard hermoso e inútil

He visto el patrón demasiadas veces. Un equipo directivo pide un dashboard. El desarrollador construye algo visualmente impresionante, lleno de gráficos y métricas. En la entrega todos están emocionados. Tres meses después nadie lo abre.

El problema casi nunca es técnico. El dashboard funciona correctamente, los datos son precisos, la interfaz es moderna. El problema está en el proceso de definición: se construyeron métricas que se ven bien, no métricas que generan decisiones.

Por qué los dashboards mueren

Después de construir más de 15 dashboards empresariales, las razones del abandono son predecibles:

El proceso que uso para diseñar dashboards que funcionan

Antes de escribir una línea de código, hago las siguientes preguntas con el equipo que va a usar el dashboard:

1. 1.
   ¿Qué decisión tomarías diferente si supieras X?
   Si la respuesta es "ninguna", X no va al dashboard principal. Esta pregunta filtra el 60% de las métricas que se piden inicialmente.
2. 2.
   ¿Con qué frecuencia vas a revisar este indicador?
   Las respuestas definen la arquitectura técnica. Un indicador que se revisa cada hora necesita actualización en tiempo real. Uno que se revisa mensualmente puede ser un job nocturno.
3. 3.
   ¿Cuál es el umbral que te haría actuar?
   Si una métrica cae al 70% del objetivo, ¿qué haces? Si no hay una respuesta clara, el indicador no está bien definido aún. El umbral convierte un dato en una alerta con consecuencias.
4. 4.
   ¿Quién más necesita ver esto?
   Los datos tienen dueños. Cuando defines quién es responsable de actuar sobre cada métrica, el dashboard cobra relevancia para esa persona en particular.

Principios de diseño que hacen la diferencia

• Jerarquía visual clara. El KPI más importante debe ser el más grande. Si todo tiene el mismo tamaño visual, nada es importante.
• Comparación siempre presente. Un número sin referencia no dice nada. Siempre muestra vs. período anterior, vs. objetivo, vs. misma semana del año pasado.
• Color como semáforo, no como decoración. El verde significa "bien", el rojo significa "actúa ahora". Si usas colores solo para que se vea bonito, confundes al usuario.
• Drill-down para los que necesitan profundidad. El resumen ejecutivo en la pantalla principal, el detalle disponible con un clic. No fuerces a nadie a ver más de lo que necesita para tomar su decisión.
• Alertas proactivas. El mejor dashboard no es uno que tienes que abrir para revisar, sino uno que te avisa cuando algo necesita tu atención. Las alertas por correo o WhatsApp multiplican el valor del sistema.

El test de los 3 meses

Antes de declarar un dashboard exitoso, espero 3 meses y pregunto: ¿el equipo lo abrió sin que alguien se los pidiera? ¿Tomaron alguna decisión basada en lo que vieron? ¿Alguien pidió agregar algo porque lo necesitaban?

Si la respuesta a todas es sí, el dashboard cumplió su función. Si no, hay algo en el proceso de definición o en la arquitectura del dato que falló, y vale la pena entenderlo antes de construir el siguiente.

Un dashboard que nadie usa no es un problema técnico. Es un síntoma de que el proceso de entendimiento del negocio fue incompleto. Y ese es exactamente el problema que evito atacando primero las preguntas de negocio, antes de pensar en qué gráfico usar.