Un dashboard que alguien usa de verdad
Siete principios para diseñar un dashboard útil: audiencia, decisión, jerarquía, estado de datos, contexto, detalle y definiciones compartidas.

Un dashboard útil tiene destinatarios definidos, responde preguntas concretas y apoya una decisión o reacción. La vista principal debe tener una jerarquía clara; los detalles pueden estar más abajo o en vistas separadas según el rol.
No es una diferencia tecnológica. Un panel se diseña desde la pregunta, no desde los datos disponibles.
Por qué mueren los paneles
Cuatro causas frecuentes: no tienen destinatario («para todos» no responde a la pregunta de nadie); muestran demasiados gráficos equivalentes; contienen datos desactualizados o inciertos sin explicarlo; o no indican qué hacer con lo que se ve. Un descenso aislado en un gráfico no conduce a acción si falta referencia y norma.
Siete principios que lo corrigen
1. Una vista, una audiencia y una pregunta
Antes de diseñar preguntamos: ¿quién mira esto y qué decisión toma con ello? «Dirección, para saber qué ocurre» no basta; hay que llegar a algo como «la responsable de ventas decide el lunes por la mañana dónde concentrar la semana». Distintas audiencias pueden compartir datos y definiciones, pero necesitar vistas, detalle y frecuencia de actualización diferentes.
2. La respuesta a primera vista
La cifra principal debe encontrarse con facilidad y mostrarse con el contexto adecuado: periodo anterior u objetivo. «Ventas 240 mil» suele ser insuficiente; «240 mil, 12% menos que el mes pasado, ante objetivo de 280 mil» permite valorar antes la desviación.
3. Pocos indicadores en la vista
El resto va a detalle. Un indicador se mantiene si responde a la pregunta de la audiencia, tiene una definición fiable y conduce a una acción; el test se describe en métricas de vanidad.
4. Estado visible de los datos
Muestra cuándo se actualizaron los datos y si una fuente no responde. Es fundamento de confianza: un panel que presenta el último dato conocido sin aviso puede inducir a error. «Datos de las 6:00; fuente X no disponible» es valor, no una avería.
5. Contexto, no solo gráfico
Elige la referencia según la decisión: periodo anterior, el mismo periodo del año anterior si hay estacionalidad o intervalo operativo acordado. Sin contexto, la dirección del cambio dice poco; una subida de coste puede ser un problema y una caída de solicitudes tras automatizar, un éxito.
6. Posibilidad de llegar al detalle
Un indicador muestra que ocurrió algo; algunas decisiones requieren causas. La vista debe llevar al desglose, los registros fuente o un recorrido de diagnóstico documentado. No toda persona necesita drill-down completo, pero la forma de verificar el número debe conocerse.
7. Mismas definiciones para todas las personas implicadas
Si dos personas llegan con definiciones distintas de una cifra, la reunión se convierte en reconciliar datos. Las vistas pueden diferir, pero deben usar definiciones versionadas, información de actualización y reglas de corrección comunes.
Qué ocupa tiempo en un proyecto así
| Etapa | Qué determina el trabajo |
|---|---|
| Acordar preguntas e indicadores | número de roles, decisiones y definiciones contradictorias |
| Acceso a datos y colectores | número de fuentes, API, calidad y frescura |
| Ordenar y acordar definiciones | falta de responsables, duplicados y reglas de corrección |
| Interfaz | número de vistas, accesibilidad, filtros y detalle |
La dificultad suele estar en la tercera fila: «ventas» en dos sistemas puede significar cosas distintas, con o sin impuestos, fecha de pedido o factura, con o sin devoluciones. Quien implementa puede guiar el acuerdo, pero la persona responsable del proceso en la empresa cliente debe aprobar el significado del indicador.
Cómo sabemos si funciona
Lo sabemos por uso, no por declaraciones: quién entra y con qué frecuencia después de varios ciclos de decisión; qué indicadores se consultan y cuáles no; y si desaparece el informe manual. Las entradas muestran adopción, el uso de vistas muestra ajuste y dejar de hacer informes manuales prueba sustitución del proceso anterior.
Cuándo un dashboard no es la respuesta
- Cuando la pregunta se plantea raramente y no requiere alertas: un informe bajo demanda puede ser más barato.
- Cuando primero hay que empezar a recoger datos: el primer proyecto es la capa fiable de captura, definición y control de calidad; el panel viene después. Diseñamos ese alcance en datos y analítica.
- Cuando el problema es falta de decisión, no de datos: un panel no obliga a resolver nada.
- Cuando las preguntas tratan de contenido y no de números: «qué contiene este contrato» es una tarea para second brain, no para un dashboard.
Cuánto cuesta
Nuestras horquillas para agosto de 2026: dashboard con integración de varias fuentes 15.000–40.000 PLN netos, plataforma analítica con colectores e informes automáticos 40.000–120.000 PLN netos, capa predictiva como módulo desde 20.000 PLN netos, mantenimiento 2.000–7.000 PLN netos/mes. El precio depende de número y calidad de fuentes, acuerdo de definiciones, frescura requerida e historial a conservar.
Preguntas frecuentes
¿No es más barato usar una herramienta de reporting ya hecha?
A menudo sí. Compara conectores, licencia, permisos, versionado de lógica y capacidades del equipo. Un panel dedicado tiene sentido cuando un requisito concreto no cabe en esos límites o poseer la interfaz es parte del producto.
¿Qué frescura deben tener los datos?
Es una decisión empresarial y técnica. Casi tiempo real puede exigir otra arquitectura, monitorización y gestión de eventos atrasados. Pregunta qué decisión tomarías de otra forma con un dato de hace un minuto frente a uno de hace un día, y cuánto vale esa diferencia.
¿Se pueden añadir predicciones?
Sí, como módulo separado si hay historial suficientemente largo y fiable y forma de evaluar la predicción con datos fuera del entrenamiento. Primero define horizonte de decisión, referencia y coste del error; un gráfico de tendencia no es aún una previsión útil.
Mantenemos una plataforma analítica y predictiva propia en TimescaleDB, con colectores monitorizados e informes cíclicos. Las interrupciones son posibles; diseñamos alertas y relleno de huecos para que sean visibles y gestionables. Consulta datos y analítica y nuestra plataforma.

Autor
Maciej Szukalski
Fundador de Condictor · arquitecto de sistemas · investigación y desarrollo
Diseña y desarrolla productos digitales desde 2014. Se especializa en arquitectura, investigación y aplicaciones con capas de automatización e inteligencia.
Conoce su experiencia y forma de trabajo¿Tienes un problema que resolver?
Veamos cuál es el mejor primer paso
Describe tu situación en unas frases. Volveremos con preguntas o una propuesta concreta para el siguiente paso.
