Diseño de dashboard: un panel para todo el equipo que nadie abría
Caso real · Departamento de marketing con un cuadro de mando conectado y correcto que el equipo esquivaba para volver a su Excel
Un dashboard interno que nadie usa casi nunca tiene un problema de datos. Tiene un problema de diseño: enseña todo lo que hay y no responde a lo que cada persona necesita saber. El equipo lo abre, no encuentra su respuesta en unos segundos y vuelve a la hoja de cálculo que controla.
El coste no aparece en ningún presupuesto. Se invirtió en conectar fuentes y montar el panel, y además se siguen pagando las horas de exportar, copiar y rehacer vistas cada semana. Arreglarlo no pide más datos ni otra herramienta, sino diseñar la interfaz alrededor de las decisiones que toma cada perfil.
El punto de partida: un panel correcto que no ayudaba a decidir
«Tenemos herramientas internas y paneles que el equipo no usa porque son confusos; acaban volviendo al Excel.»
Un departamento de marketing de una empresa de distribución, con inversión en varios canales y un cuadro de mando conectado a sus fuentes principales. La parte técnica estaba bien resuelta: los datos llegaban a tiempo y cuadraban.
El panel enseñaba más de treinta métricas en una sola vista. Todas con el mismo tamaño y el mismo peso visual. Encontrar las tres cifras que importaban a cada persona exigía recorrer toda la pantalla.
No había ninguna señal de qué requería atención. Una campaña que se desviaba del objetivo tenía el mismo aspecto que una que iba bien. Para saberlo había que comparar mentalmente cada cifra con su referencia.
Cada perfil necesitaba algo distinto y todos veían lo mismo. El responsable de campañas, dirección y el analista abrían la misma pantalla con preguntas diferentes, y ninguna estaba contestada a la vista.
El resultado era previsible. Casi todo el equipo exportaba a Excel y se montaba su propia vista, cada semana. Había tantas versiones de los datos como personas, y en las reuniones se discutía qué cifra era la buena antes de hablar de lo que había que hacer.
Tres costes que nadie había sumado
Horas de consolidación. Cada exportación, limpieza y montaje de la vista propia consumía tiempo que se repetía cada semana y en cada persona. Sumado, era una parte relevante de la jornada del equipo.
Decisiones tardías. Las desviaciones se detectaban cuando alguien revisaba su Excel, a veces días después. Con la inversión en medios corriendo, cada día de retraso tenía un coste.
Discusiones sobre el dato. Con varias versiones en circulación, las reuniones empezaban por conciliar cifras. La inversión en el cuadro de mando, pensada para evitar eso, no había cambiado nada.
Lo que descartamos
Formar al equipo en el uso del panel. Era la propuesta de la dirección. Si una herramienta interna necesita un curso para leerse, el problema es la herramienta. La formación habría mejorado el uso unas semanas y, después, cada uno habría vuelto a su hoja.
Añadir más métricas y más filtros. Cada queja se había resuelto hasta entonces añadiendo algo. Por eso el panel tenía treinta indicadores. El problema no era la falta de datos, sino el exceso sin jerarquía.
Cambiar de herramienta de business intelligence. Culpar a la plataforma era tentador, porque había otra en la empresa con mejor fama. Pero la misma información sin jerarquía se ignora igual en cualquier herramienta.
El objetivo real era que cada persona encontrara la respuesta a su pregunta habitual sin salir del panel.
La condición que decide el proyecto: diseñar para la decisión, no para el dato
Un panel interno se diseña al revés de como suele construirse. En lugar de partir de los datos disponibles y buscar cómo mostrarlos todos, se parte de las decisiones que toma cada persona y se muestra solo lo que las informa.
| Perfil | Pregunta habitual | Qué necesita ver primero |
| Responsable de campañas | Qué hay que corregir esta semana | Desviaciones frente al objetivo, por canal |
| Dirección | Si la inversión rinde lo previsto | Resultado del periodo y tendencia, sin detalle |
| Analista | Por qué se ha movido una cifra | El detalle, a un clic, con sus fuentes |
Cómo diseñamos el dashboard alrededor de las decisiones
1. Empezar por las preguntas, no por las métricas
Nos sentamos con cada perfil a ver cómo trabajaba de verdad: qué miraba el lunes por la mañana, qué le pedía dirección, qué hacía con su Excel. De ahí salieron pocas preguntas, siempre las mismas. Todo lo que no respondía a ninguna de ellas pasó a un segundo nivel.
2. Jerarquía y estados en lugar de tablas
Decidimos que lo importante tenía que verse grande y primero, y el detalle quedar disponible sin estorbar. Añadimos señales de estado para que una desviación se viera sin interpretar una tabla: qué va bien, qué requiere atención y qué necesita una decisión.
Esta decisión fue la que más cambió el uso. La pregunta dejó de ser qué dice el panel y pasó a ser qué tengo que hacer.
3. Una vista por perfil, sobre los mismos datos
En lugar de una pantalla con todo para todos, diseñamos una vista de entrada por perfil. Los datos son los mismos y la fuente es única, así que las cifras coinciden siempre. Lo que cambia es el orden y el nivel de detalle. Es el mismo principio que aplicamos cuando el panel lo comparten marketing, ventas y dirección [enlazar a /casos/dashboard-compartido-marketing-ventas].
4. Probar con el equipo antes de construir
Antes de tocar el panel real, probamos un prototipo con las personas que lo iban a usar, haciendo sus tareas habituales. Si alguien no encontraba su respuesta en unos segundos, se reordenaba. Varias decisiones que parecían evidentes en la mesa de diseño no resistieron esa prueba.
5. Medir el uso, no la entrega
Acordamos que el proyecto no terminaba al publicar el panel, sino cuando el equipo dejara de exportar. Medimos quién lo abría, con qué frecuencia y cuántas exportaciones seguían haciéndose, y ajustamos durante las primeras semanas.
Resultado
El uso semanal del panel pasó de una minoría del equipo a la gran mayoría en el primer trimestre.
Las exportaciones a Excel para montar vistas propias casi desaparecieron. Quedaron las necesarias para análisis puntuales, que es su sitio.
Las desviaciones de las campañas empezaron a corregirse en días en lugar de semanas. Las señales de estado hacían visible lo que antes había que buscar.
Las reuniones dejaron de empezar por conciliar cifras. Con una sola fuente y vistas coherentes entre sí, la conversación pasó directamente a qué hacer.
El equipo recuperó horas de consolidación cada semana, sobre todo el analista, que dejó de preparar vistas para otros y volvió a analizar.
Lo que más pesa a medio plazo es que la inversión en datos, que ya estaba hecha, empezó a devolver algo. El panel dejó de ser un proyecto técnico terminado y pasó a ser la herramienta de trabajo del equipo.
Por qué lo hacemos así
Que un equipo use sus herramientas internas no depende de tener más datos, más formación ni una plataforma distinta. Depende de tres cosas:
- Partir de las decisiones que toma cada perfil y no de los datos disponibles.
- Dar jerarquía y señales de estado para que lo importante se vea sin interpretar.
- Probar con quien lo va a usar y medir el uso real después de publicar.
Dónde no aplica: si los datos del panel no son fiables o no cuadran con otras fuentes, el primer problema es el dato y ningún diseño lo compensa. Y en equipos de dos o tres personas con una sola pregunta habitual, una hoja bien hecha puede ser suficiente.
Preguntas frecuentes
¿Por qué el equipo no usa el dashboard y vuelve al Excel?
Normalmente porque el dashboard enseña todos los datos disponibles y no responde a la pregunta concreta de cada persona. Si encontrar una cifra exige recorrer treinta indicadores con el mismo peso visual, es más rápido exportar y montar una vista propia en Excel. El problema no suele estar en los datos ni en la herramienta, sino en el diseño de la interfaz y en la falta de jerarquía.
¿Cómo diseñar un dashboard que el equipo use de verdad?
Partiendo de las decisiones que toma cada perfil y de las preguntas que se hace cada semana. Con eso se decide qué se ve primero, qué queda a un clic y qué sobra. Las señales de estado ayudan a ver sin interpretar qué requiere atención. Antes de construirlo, conviene probar un prototipo con las personas que lo van a usar mientras hacen sus tareas reales.
¿Cuántos KPI debe tener un dashboard?
Los que responden a las preguntas de quien lo usa, que suelen ser menos de los que se incluyen. Un dashboard con decenas de indicadores al mismo nivel obliga a buscar y acaba ignorado. Es preferible una vista de entrada por perfil con pocas cifras principales y el detalle disponible un nivel más abajo, siempre sobre la misma fuente de datos para que todas las vistas coincidan.
¿Hace falta cambiar de herramienta de business intelligence para mejorar el uso?
Casi nunca como primer paso. Si el panel no tiene jerarquía ni responde a las preguntas de cada perfil, la misma información se ignorará igual en otra plataforma. Cambiar de herramienta tiene sentido por motivos técnicos, como conectores, rendimiento o coste, pero no resuelve un problema de diseño. Conviene rediseñar primero y decidir la herramienta con el uso ya medido.
¿Cómo saber si una herramienta interna tiene un problema de usabilidad?
Las señales son claras: el equipo exporta los datos para trabajarlos fuera, hay varias versiones de las mismas cifras en circulación, las reuniones empiezan por conciliar números y pocas personas abren la herramienta cada semana. Para confirmarlo, lo más útil es observar a cada perfil intentando responder su pregunta habitual con la herramienta y ver dónde se atasca o abandona.
¿Sirve formar al equipo para que use mejor el dashboard?
Ayuda poco si la herramienta es confusa. La formación mejora el uso durante unas semanas y después cada persona vuelve a su método habitual, porque el esfuerzo diario sigue siendo el mismo. Tiene sentido para explicar cómo se calculan los indicadores o qué fuentes se usan, pero una herramienta interna bien diseñada debería entenderse sin curso previo por quien la usa a diario.
¿Cuántas personas de tu equipo abren el cuadro de mando cada semana y cuántas prefieren su propio Excel? Si no lo sabes, es probable que la respuesta no te guste.
Cuéntanos qué herramientas internas tiene tu equipo y cómo las usa de verdad, y en la primera conversación sabremos si el problema está en el diseño de la interfaz, en los datos o en otra parte.
Otros casos de uso
Otros proyectos donde resolvimos el mismo tipo de problema.