Dashboards de recerca: quan construir, quan evitar

El dashboard existeix. El PI el va ensenyar a la reunió del consorci. El finançador el va destacar positivament a la revisió intermèdia. Sis mesos després, ningú de l'equip l'ha obert. Els números trimestrals que havia d'actualitzar estan desfasats. Quan algú extern obre l'enllaç, la meitat dels gràfics no carrega perquè la font de dades va canviar de format.

La majoria de dashboards de recerca acaben així. Construïts amb bones intencions, usats breument, abandonats en silenci. El finançador no pregunta perquè no sap que ha desaparegut.

Abans de construir un dashboard, la pregunta correcta no és "què ha de mostrar?" — és "ha d'existir com a dashboard?". Aquest article és un marc de decisió pràctic per al dashboard de recerca en projectes de recerca actius.

Per què fallen els dashboards de recerca

Gairebé tots els dashboards de recerca abandonats fallen per una de quatre raons.

1. La pipeline de dades darrere no es manté

Un dashboard és una finestra a un dataset. Si el dataset deixa d'actualitzar-se — perquè el postdoc es gradua, l'script d'anàlisi es trenca o el sistema font canvia — el dashboard es congela. Un dashboard congelat és pitjor que cap dashboard, perquè mostra números obsolets com si fossin actuals.

2. L'audiència mai el va usar realment

El dashboard es va construir per a un visualitzador hipotètic. El PI volia que "els stakeholders poguessin explorar les dades". A la pràctica, els stakeholders llegeixen PDFs, no dashboards interactius. Les funcionalitats interactives no es fan servir; les captures estàtiques esdevenen el lliurable real.

3. El manteniment depèn d'una sola persona

La doctoranda el va construir. Ella entenia el processament de dades, la lògica dels gràfics i el desplegament. Ara ja no hi és. Mantenir el dashboard requereix llegir 800 línies de codi sense documentació.

4. El dashboard respon preguntes que ningú es fa

La proposta deia que el projecte produiria un dashboard, així que es va produir un dashboard. Però les preguntes reals de recerca es responien millor amb un informe anual amb cinc figures fixes. La flexibilitat del dashboard — el que en justificava la construcció — no era el que l'audiència necessitava.

Si un dashboard fallarà per una d'aquestes raons, construir-lo és temps perdut. La prova honesta és: quina de les quatre em preocupa més?

Quan SÍ és el dashboard la resposta correcta

Tres patrons fan que valgui la pena construir un dashboard de recerca.

Patró A: L'audiència fa exploració de dades genuïna

Responsables de programa en una fundació revisant el progrés de 12 beneficiaris mensualment. PIs multi-seu comparant trajectòries de reclutament entre països setmanalment. Un comitè científic assessor revisant troballes intermèdies abans de cada reunió. Aquestes audiències obren dashboards perquè la seva feina implica comparar talls de dades que no sabien que necessitarien comparar.

Si la teva audiència fa exploració de debò, el dashboard aporta valor. Si llegeix els mateixos cinc gràfics cada vegada, un informe és millor.

Patró B: Les dades es refresquen de debò

Progrés de reclutament de cohorts. Inscripció activa de pacients. Mètriques regionals de participació en un programa multi-seu. Taxes d'abandonament en un assaig. Aquestes es beneficien d'estar al dia — la foto del mes passat és materialment menys útil que la d'avui.

Si les dades subjacents es refresquen significativament (setmanalment o més ràpid), la propietat de "sempre al dia" del dashboard fa feina real. Si es refresquen anualment, tens un informe, no un dashboard.

Patró C: El dashboard és la interfície operativa, no només un visor

Seguiment logístic d'un estudi multi-seu. Monitorització de qualitat de dades de camp. Estat actiu del flux de treball d'una operació de recerca. Aquestes són eines que l'equip fa servir per fer la feina, no per comunicar troballes.

Aquest és el cas més fort. El dashboard no és un lliurable; és infraestructura. Els dashboards operatius justifiquen el seu manteniment perquè l'equip que els usa nota quan es trenquen.

Quan NO és el dashboard la resposta correcta

Quatre patrons suggereixen que un dashboard és l'elecció equivocada — i una alternativa és més barata, més duradora i més útil.

Antipatró 1: L'audiència és un finançador que llegeix dues vegades

Si el dashboard és per a un finançador que el veurà dues vegades — a revisió intermèdia i final — construeix un informe estàtic. Un PDF amb 8 figures ben triades, una narrativa de 3 pàgines i un annex metodològic supera el dashboard interactiu per a aquest cas. A més és arxivable.

Antipatró 2: Les dades són intermitents

Si les dades del dashboard s'actualitzen 2–4 vegades l'any — en onades de recollida en camp, en talls de cohort anuals — la interactivitat no es fa servir la major part del temps. Un informe regenerat trimestralment cobreix el mateix objectiu amb menys sobrecàrrega.

Antipatró 3: L'equip no té pla de manteniment

Un dashboard sense pla clar de qui el manté quan se'n va el desenvolupador original és un passiu. Si l'equip no pot assenyalar qui se'n fa càrrec durant els pròxims dos anys, construeix un artefacte puntual. El programari acadèmic de recerca sense pla de manteniment mor en menys de 18 mesos.

Antipatró 4: Les preguntes que respon el dashboard estan ben definides

Si pots escriure les 6 preguntes que l'audiència farà, la resposta a cada una és un gràfic fix, i aquests gràfics seran els mateixos d'aquí a 12 mesos — això és un informe. La flexibilitat del dashboard no compensa el cost de construcció ni la sobrecàrrega de manteniment.

Què esperen realment els finançadors

La majoria d'avaluadors no sap què vol d'un dashboard. Sí saben què volen d'un projecte de recerca: evidència clara d'impacte, metodologia defensable, processos transparents. Un dashboard o aporta aquests senyals o no.

En concret, els finançadors volen veure:

• Estat actual del projecte: on ets vs. on et vas comprometre a estar
• Mètriques comparables entre seus o cohorts: quan apliqui
• Procedència i cadència d'actualització: quan es va refrescar per última vegada, contra quines dades
• Transparència metodològica: com es calcula cada mètrica
• Accessibilitat a llarg termini: una URL estable que segueixi funcionant d'aquí a 3 anys

El desajust més gran que veiem: equips construint dashboards optimitzats per a exploració d'stakeholders quan el finançador necessita evidència de compliment del programa. Les dues coses requereixen superfícies diferents. Si el dashboard és realment per al finançador, construeix el més simple — no necessita filtres, necessita confiança.

Decisions de construcció: plataforma configurable vs construcció a mida

Quan la resposta és genuïnament "construir un dashboard", la pregunta següent és per quina via.

Plataformes configurables (Via A)

Looker Studio (gratuït, autenticació amb Google, lògica personalitzada limitada), Metabase (open-source, autoallotjat o al núvol, bona UX SQL), Grafana (open-source, fort en sèries temporals, més feble per a dades generals), Apache Superset (open-source, configuració més complexa, potent quan està muntat).

Tria quan: els tipus de gràfic estàndard serveixen, les teves dades viuen en una base consultable, no necessites UX a mida. Temps a primera versió: 1–2 setmanes. Manteniment: baix si la teva infraestructura de dades es manté estable.

Construcció a mida (Via B)

Next.js / React amb llibreria de gràfics (Recharts, Plotly.js, Observable Plot, D3 per als ambiciosos), backend d'API autenticat, desplegat a un servei gestionat.

Tria quan: el dashboard és operativament crític, les necessitats de UX són específiques, l'audiència és prou gran perquè la polidesa importi, hi ha integració amb sistemes de dades de recerca a mida. Temps a primera versió: 4–8 setmanes. Manteniment: real, continuat — necessita runbooks documentats i algú responsable.

El càlcul honest per a la majoria de projectes de recerca: via A o cap dashboard. La via B és la correcta quan el dashboard és el lliurable, no només una manera de comunicar-lo.

Un exercici de decisió de 30 minuts

Bloqueja 30 minuts. Respon:

1. Qui és l'audiència real? Noms, rols, nombre. Si no els pots llistar, aquesta és la resposta.
2. Cada quan l'obriran? Estimació honesta. Trimestralment, setmanalment, diàriament?
3. Les dades subjacents es refresquen de manera significativa entre les seves visites? Sí / no.
4. Qui el manté d'aquí a 18 mesos? Persona concreta, amb capacitat.
5. Quins 5 gràfics fixos respondrien al 80% del que necessita l'audiència? Llistar-los sol ser suficient — i un cop llistats, normalment un informe ja n'hi ha prou.
6. Si el dashboard no existís, què faria servir l'audiència en lloc seu? Si la resposta és "el mateix PDF que enviaríem igualment", el dashboard no aporta valor.

Si les respostes són nítides i un dashboard segueix semblant el correcte, construeix-lo. Si són borroses, construeix un informe estàtic.

On encaixa Pragma

Construïm dashboards de recerca quan el brief els justifica — interfícies operatives, eines de monitorització de programa per a fundacions, trackers de reclutament multi-seu. També diem als equips quan no construir-ne. El nostre projecte MVP d'eina de recerca defineix la decisió construir-o-evitar a la primera setmana i entrega l'artefacte correcte en 4–10 setmanes.

Si tens una línia de dashboard al pla de treball i dubtes si construir-lo, sol·licita una revisió de projecte. L'exercici de decisió de 30 minuts el fem amb tu a la trucada.

Tres coses per fer aquesta setmana

1. Executa l'exercici de decisió de 30 minuts per al dashboard que estàs considerant. Sigues honest a l'ítem 4.
2. Llista els 5 gràfics que respondrien al 80% de les necessitats de l'audiència. Si els pots escriure, la teva resposta honesta probablement sigui "informe, no dashboard".
3. Si la resposta és genuïnament "construir", sol·licita una revisió de projecte. Confirmarem si va per la via A (configurar) o la B (a mida) i quin ha de ser el pla de manteniment.

El fracàs més car en visualització de dades de recerca és el dashboard abandonat. El segon més car és el dashboard que ningú et va dir que era innecessari. Tots dos són evitables.