Si nadie abre el dashboard que montaste, casi nunca es un problema de diseño. Es que responde preguntas que nadie se estaba haciendo. Un cuadro de mando se usa cuando alguien tiene que tomar una decisión concreta y sabe que ahí está el dato que la desbloquea.
La reacción habitual es rediseñar: más gráficos, mejores colores, un filtro más. Y el uso sigue igual, porque el problema estaba antes de la primera pantalla.
La señal de que el dashboard no se usa
No es que nadie lo abra: es que te siguen preguntando a ti. Cuando alguien te pide por chat un número que está en la primera fila del dashboard, ese dashboard no existe para esa persona.
Si tienes acceso, mira el historial de visitas del informe. Lo normal en un cuadro de mando que ha fallado es un pico los tres primeros días —cuando lo presentaste— y una línea plana después.
Motivo 1 — Responde preguntas que nadie hace
Es, con diferencia, el más frecuente. El dashboard se construye con las métricas que la herramienta trae por defecto, no con las que alguien necesita para decidir.
El síntoma es reconocible: un panel con sesiones, usuarios, tasa de rebote y páginas vistas. Son datos correctos y no responden a ninguna pregunta de negocio. Nadie decide nada distinto porque las sesiones suban un 8%.
La prueba rápida: por cada bloque del dashboard, pregunta qué se hará distinto si ese número se mueve. Es el mismo ejercicio que ordena un plan de medición. Los bloques sin respuesta sobran.
Motivo 2 — Nadie sabe leerlo
El dashboard está bien y el problema es de vocabulario. Quien lo mira no sabe si «usuarios activos» incluye a los que entraron una vez, o por qué las conversiones no cuadran con el CRM.
Ante la duda, la reacción no es preguntar: es dejar de mirarlo. Un dato que no se entiende del todo se percibe como un dato en el que no se puede confiar, y con razón.
Esto se arregla con una capa de contexto en el propio informe —una nota corta bajo cada bloque explicando qué mide y qué no— y con formar al equipo en la lectura de los datos, que es más barato que rehacer el panel cada seis meses.
Motivo 3 — El dato no es fiable y el equipo lo sabe
Este es el peor, porque envenena todo lo demás. Basta con que una cifra haya estado mal una vez y se haya comentado en una reunión para que el dashboard entero quede marcado.
Recuperar esa confianza cuesta mucho más que construir el panel. Y no se recupera con explicaciones: se recupera arreglando la medición y avisando de que está arreglada. Antes de montar nada conviene descartar los errores de configuración más comunes.
Motivo 4 — Llega en el momento equivocado
Un informe mensual que se revisa el día 10 no sirve para decidir sobre campañas que terminaron el día 30. La decisión ya se tomó, con intuición.
El ritmo del dashboard tiene que coincidir con el ritmo de la decisión, no con el del cierre contable. Si el equipo ajusta pujas los lunes, el dato tiene que estar el lunes.
Cómo se construye uno que sí se usa
Empieza por la decisión, no por los datos. Siéntate con quien va a usarlo y pregúntale qué decisiones toma cada semana y qué le falta para tomarlas con menos dudas. De ahí salen entre tres y cinco preguntas reales.
Después, una pantalla por pregunta, con el número que la responde arriba y grande, y el desglose debajo. Si el panel va en Data Studio, esa jerarquía se monta en cinco minutos. Si necesitas cruzar métricas y dimensiones para llegar a ese número, hazlo en la fuente de datos y no en la vista.
Y un límite que ahorra disgustos: si el panel no cabe en una pantalla, no es un dashboard, es un archivo. Lo que hay que revisar de un vistazo tiene que verse de un vistazo.
Un ejemplo concreto
Un ecommerce pedía un panel «completo» de ventas. La conversación real duró veinte minutos y sacó tres decisiones: qué campañas pausar los lunes, qué productos reponer y si el envío gratis a partir de 50 € estaba saliendo rentable.
El panel final tuvo tres bloques en vez de los catorce del anterior, y pasó de abrirse dos veces al mes a abrirse cada lunes. No mejoró el diseño: mejoró la pregunta.
Preguntas frecuentes sobre dashboards que no se usan
¿Cuántos gráficos debería tener un dashboard?
Los que quepan en una pantalla sin hacer scroll, que en la práctica son entre tres y seis bloques. Si hacen falta más, casi siempre es que se están mezclando dos audiencias distintas en un mismo informe y conviene separarlas.
¿Es mejor un dashboard por equipo o uno general?
Uno por equipo, porque las decisiones son distintas. Un panel general que intenta servir a dirección, marketing y ventas a la vez acaba sin servir a ninguno: cada uno ignora dos tercios de la pantalla.
¿Cada cuánto hay que revisar un dashboard?
Una revisión corta cada trimestre, para quitar lo que ya nadie mira. Los cuadros de mando crecen solos: alguien pide un bloque nuevo, se añade, y nunca se retira nada. En un año el panel vuelve a ser ilegible.
¿Sirve de algo formar al equipo si el dashboard está mal planteado?
Poco. Si el panel responde preguntas que nadie se hace, la formación solo consigue que el equipo entienda mejor por qué no le interesa. Primero se replantea el panel, después se forma en leerlo.
¿Cómo mido si un dashboard se está usando de verdad?
Por dos señales: las visitas recurrentes del informe y, sobre todo, si han bajado las peticiones manuales de datos. La segunda es la que cuenta, porque es la que indica que el equipo se está contestando solo.
Conclusión
Un dashboard que nadie usa no se arregla con diseño. Se arregla averiguando qué decisión tenía que desbloquear, comprobando que el dato es fiable y ajustando el ritmo al de quien decide.
Tres bloques que responden preguntas reales valen más que catorce que describen la web.
¿Tienes un cuadro de mando que nadie abre y quieres saber por qué? Escríbeme y lo vemos juntos.
