Dashboards de investigación: cuándo construir, cuándo evitar

El dashboard existe. El PI lo enseñó en la reunión del consorcio. El financiador lo destacó positivamente en la revisión intermedia. Seis meses después, nadie del equipo lo ha abierto. Los números trimestrales que debía actualizar están desfasados. Cuando alguien externo abre el enlace, la mitad de los gráficos no carga porque la fuente de datos cambió de formato.

La mayoría de dashboards de investigación acaban así. Construidos con buenas intenciones, usados brevemente, abandonados en silencio. El financiador no pregunta porque no sabe que ha desaparecido.

Antes de construir un dashboard, la pregunta correcta no es "¿qué debe mostrar?" — es "¿debe existir como dashboard?". Este artículo es un marco de decisión práctico para el dashboard de investigación en proyectos de investigación activos.

Por qué fallan los dashboards de investigación

Casi todos los dashboards de investigación abandonados fallan por una de cuatro razones.

1. La pipeline de datos detrás no se mantiene

Un dashboard es una ventana a un dataset. Si el dataset deja de actualizarse — porque el postdoc se gradúa, el script de análisis se rompe o el sistema fuente cambia — el dashboard se congela. Un dashboard congelado es peor que ningún dashboard, porque muestra números obsoletos como si fueran actuales.

2. La audiencia nunca lo usó realmente

El dashboard se construyó para un visualizador hipotético. El PI quería que "los stakeholders pudieran explorar los datos". En la práctica, los stakeholders leen PDFs, no dashboards interactivos. Las funcionalidades interactivas no se usan; las capturas estáticas se convierten en el entregable real.

3. El mantenimiento depende de una sola persona

La doctoranda lo construyó. Ella entendía el procesado de datos, la lógica de los gráficos y el despliegue. Ahora ya no está. Mantener el dashboard requiere leer 800 líneas de código sin documentación.

4. El dashboard responde preguntas que nadie hace

La propuesta decía que el proyecto produciría un dashboard, así que se produjo un dashboard. Pero las preguntas reales de investigación se respondían mejor con un informe anual con cinco figuras fijas. La flexibilidad del dashboard — lo que justificaba construirlo — no era lo que la audiencia necesitaba.

Si un dashboard va a fallar por una de estas razones, construirlo es tiempo perdido. La prueba honesta es: ¿cuál de las cuatro me preocupa más?

Cuándo SÍ es el dashboard la respuesta correcta

Tres patrones hacen que valga la pena construir un dashboard de investigación.

Patrón A: La audiencia hace exploración de datos genuina

Responsables de programa en una fundación revisando el progreso de 12 beneficiarios mensualmente. PIs multi-sitio comparando trayectorias de reclutamiento entre países semanalmente. Un comité científico asesor revisando hallazgos intermedios antes de cada reunión. Estas audiencias abren dashboards porque su trabajo implica comparar cortes de datos que no sabían que necesitarían comparar.

Si tu audiencia hace exploración de verdad, el dashboard aporta valor. Si lee los mismos cinco gráficos cada vez, un informe es mejor.

Patrón B: Los datos se refrescan de verdad

Progreso de reclutamiento de cohortes. Inscripción activa de pacientes. Métricas regionales de participación en un programa multi-sitio. Tasas de abandono en un ensayo. Estos se benefician de estar al día — la foto del mes pasado es materialmente menos útil que la de hoy.

Si los datos subyacentes se refrescan de forma significativa (semanalmente o más rápido), la propiedad de "siempre al día" del dashboard hace trabajo real. Si se refrescan anualmente, tienes un informe, no un dashboard.

Patrón C: El dashboard es la interfaz operativa, no solo un visor

Seguimiento logístico de un estudio multi-sitio. Monitorización de calidad de datos de campo. Estado activo del flujo de trabajo de una operación de investigación. Estas son herramientas que el equipo usa para hacer el trabajo, no para comunicar hallazgos.

Este es el caso más fuerte. El dashboard no es un entregable; es infraestructura. Los dashboards operativos justifican su mantenimiento porque el equipo que los usa nota cuándo se rompen.

Cuándo NO es el dashboard la respuesta correcta

Cuatro patrones sugieren que un dashboard es la elección equivocada — y una alternativa es más barata, más duradera y más útil.

Antipatrón 1: La audiencia es un financiador que lee dos veces

Si el dashboard es para un financiador que lo verá dos veces — en revisión intermedia y final — construye un informe estático. Un PDF con 8 figuras bien elegidas, una narrativa de 3 páginas y un anexo metodológico supera al dashboard interactivo para este caso. Además es archivable.

Antipatrón 2: Los datos son intermitentes

Si los datos del dashboard se actualizan 2–4 veces al año — en olas de recogida en campo, en cortes de cohorte anuales — la interactividad no se usa la mayor parte del tiempo. Un informe regenerado trimestralmente cubre el mismo objetivo con menos sobrecarga.

Antipatrón 3: El equipo no tiene plan de mantenimiento

Un dashboard sin plan claro de quién lo mantiene cuando se va el desarrollador original es un pasivo. Si el equipo no puede señalar quién se hace cargo durante los próximos dos años, construye un artefacto puntual. El software académico de investigación sin plan de mantenimiento muere en menos de 18 meses.

Antipatrón 4: Las preguntas que responde el dashboard están bien definidas

Si puedes escribir las 6 preguntas que la audiencia hará, la respuesta a cada una es un gráfico fijo, y esos gráficos serán los mismos dentro de 12 meses — eso es un informe. La flexibilidad del dashboard no compensa el coste de construcción ni la sobrecarga de mantenimiento.

Qué esperan realmente los financiadores

La mayoría de evaluadores no sabe qué quiere de un dashboard. Sí saben qué quieren de un proyecto de investigación: evidencia clara de impacto, metodología defendible, procesos transparentes. Un dashboard o aporta esas señales o no.

En concreto, los financiadores quieren ver:

• Estado actual del proyecto: dónde estás vs. dónde te comprometiste a estar
• Métricas comparables entre sitios o cohortes: cuando aplique
• Procedencia y cadencia de actualización: cuándo se refrescó por última vez, contra qué datos
• Transparencia metodológica: cómo se calcula cada métrica
• Accesibilidad a largo plazo: una URL estable que siga funcionando dentro de 3 años

El mayor desajuste que vemos: equipos construyendo dashboards optimizados para exploración de stakeholders cuando el financiador necesita evidencia de cumplimiento del programa. Las dos cosas requieren superficies distintas. Si el dashboard es realmente para el financiador, construye lo más simple — no necesita filtros, necesita confianza.

Decisiones de construcción: plataforma configurable vs construcción a medida

Cuando la respuesta es genuinamente "construir un dashboard", la siguiente pregunta es por qué vía.

Plataformas configurables (Vía A)

Looker Studio (gratis, autenticación con Google, lógica personalizada limitada), Metabase (open-source, autoalojado o cloud, buena UX SQL), Grafana (open-source, fuerte en series temporales, más débil para datos generales), Apache Superset (open-source, configuración más compleja, potente cuando está montado).

Elige cuando: los tipos de gráfico estándar sirven, tus datos viven en una base consultable, no necesitas UX a medida. Tiempo a primera versión: 1–2 semanas. Mantenimiento: bajo si tu infraestructura de datos se mantiene estable.

Construcción a medida (Vía B)

Next.js / React con librería de gráficos (Recharts, Plotly.js, Observable Plot, D3 para los ambiciosos), backend de API autenticado, desplegado en un servicio gestionado.

Elige cuando: el dashboard es operativamente crítico, las necesidades de UX son específicas, la audiencia es lo bastante grande para que la pulcritud importe, hay integración con sistemas de datos de investigación a medida. Tiempo a primera versión: 4–8 semanas. Mantenimiento: real, continuado — necesita runbooks documentados y alguien responsable.

La cuenta honesta para la mayoría de proyectos de investigación: vía A o ningún dashboard. La vía B es la correcta cuando el dashboard es el entregable, no solo una forma de comunicarlo.

Un ejercicio de decisión de 30 minutos

Bloquea 30 minutos. Responde:

1. ¿Quién es la audiencia real? Nombres, roles, número. Si no puedes listarlos, esa es la respuesta.
2. ¿Cada cuánto lo abrirán? Estimación honesta. ¿Trimestralmente, semanalmente, diariamente?
3. ¿Los datos subyacentes se refrescan de forma significativa entre sus visitas? Sí / no.
4. ¿Quién lo mantiene dentro de 18 meses? Persona concreta, con capacidad.
5. ¿Qué 5 gráficos fijos responderían al 80% de lo que necesita la audiencia? Listarlos suele ser suficiente — y una vez listados, normalmente un informe ya basta.
6. Si el dashboard no existiera, ¿qué usaría la audiencia en su lugar? Si la respuesta es "el mismo PDF que enviaríamos igualmente", el dashboard no aporta valor.

Si las respuestas son nítidas y un dashboard sigue pareciendo lo correcto, constrúyelo. Si son borrosas, construye un informe estático.

Dónde encaja Pragma

Construimos dashboards de investigación cuando el brief lo justifica — interfaces operativas, herramientas de monitorización de programa para fundaciones, trackers de reclutamiento multi-sitio. También decimos a los equipos cuándo no construirlo. Nuestro proyecto MVP de herramienta de investigación define la decisión construir-o-evitar en la primera semana y entrega el artefacto correcto en 4–10 semanas.

Si tienes una línea de dashboard en el plan de trabajo y dudas si construirlo, solicita una revisión de proyecto. El ejercicio de decisión de 30 minutos lo hacemos contigo en la llamada.

Tres cosas para hacer esta semana

1. Ejecuta el ejercicio de decisión de 30 minutos para el dashboard que estás considerando. Sé honesto en el ítem 4.
2. Lista los 5 gráficos que responderían al 80% de las necesidades de la audiencia. Si puedes escribirlos, tu respuesta honesta probablemente sea "informe, no dashboard".
3. Si la respuesta es genuinamente "construir", solicita una revisión de proyecto. Confirmaremos si va por la vía A (configurar) o la B (a medida) y cuál debe ser el plan de mantenimiento.

El fallo más caro en visualización de datos de investigación es el dashboard abandonado. El segundo más caro es el dashboard que nadie te dijo que era innecesario. Ambos son evitables.