Slik bygger du et dashboard: datakilder, nøkkeltall, diagrammer og tilgang

For å bygge et dashboard starter du med spørsmålene det må svare på og folkene som skal lese det, definerer et lite sett med målinger nøyaktig, kobler til dataene målingene kommer fra, og velger et enkelt diagram for hver. Deretter bestemmer du hvem som kan se hvilke tall. Et AI-byggeverktøy kan lage et polert dashboard på noen minutter; det vanskelige, og det som avgjør om noen stoler på det, er å få dataene og definisjonene riktige.

Start med spørsmål, ikke diagrammer

Et dashboard som prøver å vise alt, blir åpnet én gang. Før du tenker på diagrammer, svar på:

• Hvem er det for? Gründeren, et salgsteam, drift, investorer, kundene dine?
• Hvilke beslutninger støtter det? «Trenger vi å ansette en person til i support?» er et spørsmål et dashboard kan svare på. «Vis meg dataene våre» er ikke det.
• Hvor ofte vil de se på det? Daglige driftsdashboards trenger ferske data og varsler; en månedlig styrevisning gjør ikke det.

Skriv tre til fem spørsmål. Hvert av dem blir til en eller to målinger.

Definer hver måling nøyaktig

De fleste diskusjoner om dashboards handler egentlig om definisjoner. Skriv en kort definisjon for hvert tall:

Lim disse definisjonene inn i prompten din. Ellers velger et AI en rimelig beregning som kanskje ikke samsvarer med hvordan virksomheten din teller.

Hvor dataene kommer fra

To prinsipper gjelder overalt:

1. Hold nøkler på serveren. API-nøkler og databasepassord hører hjemme i appens miljøvariabler, aldri i kode i nettleseren.
2. Bestem hvor ferske dataene skal være. Å hente fra flere API-er ved hver sidelasting er tregt og kan treffe hastighetsgrenser. For de fleste forretningsdashboards er en synkronisering hver time eller over natten inn i din egen database, med et «sist oppdatert»-tidspunkt på siden, enklere og mer pålitelig.

Hvis API-er er nye for deg, forklarer hva er et API og hva er en database det grunnleggende.

Velg riktig diagram

• Ett tall med endring («$42 000, opp 8 % mot forrige måned»): et nøkkeltallskort. Det mest nyttige elementet på de fleste dashboards.
• Utvikling over tid: et linjediagram. Bruk søyler bare for et lite antall perioder.
• Sammenligning av kategorier: et horisontalt søylediagram, sortert etter verdi.
• Del av en helhet: et stablet søylediagram. Kakediagrammer fungerer bare med to eller tre skiver.
• Detaljer og avvik: en tabell med sortering, søk og filtre. Ofte mer nyttig enn noe diagram.

Hold fargene konsistente: én farge for «denne perioden», en dempet for «sammenligning», og rødt bare for ting som trenger oppmerksomhet.

Hvem som ser hva

Bestem tilgang før du bygger:

• Internt, alle ser alt: enklest. Krever likevel innlogging hvis det inneholder forretningsdata.
• Rollebasert: salg ser salgstall, økonomi ser marginer, ledere ser sitt eget team.
• Kundevendt: hver kunde ser bare sine egne data. Hver spørring må filtrere på kundens konto på serveren. Test det ved å logge inn som to forskjellige kunder.

Et dashboard med omsetnings- eller kundedata på en offentlig nettadresse uten innlogging er en datalekkasje som bare venter på å bli oppdaget.

En første prompt som fungerer

Bygg et salgsdashboard for et B2B-programvareselskap med 10 ansatte. Målgruppe: gründerne og salgssjefen, som sjekker det hver mandag. Oversiktsside: nøkkeltallskort for ny MRR denne måneden, total MRR, nye kunder denne måneden, kunder som har sagt opp denne måneden og pipeline-verdi, hver med endringen mot forrige måned; et linjediagram over MRR de siste 12 månedene; et søylediagram over nye avtaler per kilde. En Avtaler-side med en søkbar, sorterbar tabell (selskap, eier, verdi, fase, avslutningsdato) og filtre på eier og fase. Definisjoner: MRR er summen av aktive månedlige abonnementsbeløp, årsplaner delt på 12; frafall teller kunder der abonnementet ble avsluttet denne måneden. Bruk realistiske eksempeldata i en database foreløpig; vi kobler til Stripe senere. Vis et «sist oppdatert»-tidspunkt. Innlogging kreves. Ryddig sidenavigasjon til venstre.

Byggetrinn

1. Layout med eksempeldata. Bli enige om målingene og diagrammene mens dataene er falske og billige å endre.
2. Koble til én ekte kilde. Sjekk hvert tall mot kildesystemet for hånd. Hvis MRR avviker fra det Stripe viser, finn ut hvorfor før du går videre.
3. Legg til de andre kildene, én om gangen, og sjekk hver.
4. Planlagt oppdatering eller spørringer ved innlasting, med et «sist oppdatert»-merke.
5. Filtre: datointervall først, deretter en eller to andre som folk ber om.
6. Innlogging og roller.
7. Tomme og feiltilstander: hva siden viser når en kilde er nede, eller et filter gir ingen treff.
8. Del det med målgruppen, og fjern deretter alt ingen ser på etter en måned.

Gjør det raskt

Et tregt dashboard blir sjekket sjeldnere. Forhåndsberegn totaler som er dyre å regne ut (en daglig oppsummeringstabell i stedet for å skanne alle ordrer), paginer store tabeller, og last inn hovedkortene først slik at siden er nyttig før diagrammene er ferdige. Hvis et tall tar lang tid å regne ut, vis når det sist ble beregnet, i stedet for å regne det på nytt hver gang noen besøker siden.

Vanlige feil

• For mange diagrammer. Hvis alt er uthevet, er ingenting uthevet.
• Udefinerte målinger. To personer som leser samme dashboard, bør komme til samme konklusjon.
• Aldri å sjekke tall mot kilden. Ett feil tall, og folk slutter å stole på hele dashboardet.
• Å spørre hvert API ved hver sidelasting. Tregt, skjørt og noen ganger dyrt.
• Ingen datokontekst. Vis alltid perioden og sammenligningen.
• Hemmeligheter i frontend. En API-nøkkel synlig i nettleseren kan kopieres av hvem som helst som åpner siden.

Når et BI-verktøy er det bedre valget

Hvis dataene dine allerede ligger i en database eller et datalager, og hovedbrukerne er analytikere som vil utforske, skjære dem opp og bygge egne diagrammer, vil et BI-verktøy (Looker Studio, Power BI, Metabase og andre) tjene dem bedre enn et eget bygg. Mange SaaS-verktøy har også gode innebygde rapporter; sjekk dem før du bygger dem på nytt. Et eget dashboard vinner når det er for kunder eller folk uten analytisk bakgrunn, trenger logikk eller tilganger som BI-verktøyet ikke kan uttrykke, kombinerer kilder på en måte som er spesifikk for virksomheten din, eller hører hjemme i et produkt du allerede driver.

Hvis jobben i større grad er å endre poster enn å se tall, trenger du et adminpanel eller internt verktøy i stedet; se slik bygger du et internt verktøy. Og hvis tallene dine ligger i et regneark i dag, er slik gjør du et regneark om til en app en god neste lesning.

Bygge det med Mythex

På Mythex beskriver du dashboardet, og agenten bygger sidene og diagrammene i en live-forhåndsvisning, og starter med realistiske eksempeldata før den flytter til en dedikert Postgres-database når tallene må lagres. Dokumentenes brukstilfelle for dashboard har en startprompt. Ligger dataene dine i et verktøy som Google Sheets, kan du koble til kontoen via Connectors og be agenten lese den og bygge et dashboard fra den.

Det finnes ingen innebygde datalagerkoblinger for selve appen. For BigQuery, Snowflake, Stripe og lignende kaller appen deres API-er med nøkler du lagrer som prosjekthemmeligheter. Innlogging og roller for de som ser dashboardet, er en del av appen du bygger. For å starte fra en prompt, bla gjennom dashboard-malene, for eksempel måledashboardet.

Spørsmål