Så bygger du en dashboard: datakällor, nyckeltal, diagram och åtkomst

För att bygga en dashboard börjar du med de frågor den måste besvara och de personer som ska läsa den, definierar ett litet antal mätetal exakt, kopplar datan som dessa mätetal kommer från och väljer ett enkelt diagram för varje. Bestäm sedan vem som kan se vilka siffror. Ett AI-byggverktyg kan skapa en snygg dashboard på några minuter; det svåra, och det som avgör om någon litar på den, är att få datan och definitionerna rätt.

Börja med frågor, inte diagram

En dashboard som försöker visa allt öppnas en gång. Innan du tänker på diagram, svara på:

• Vem är den till för? Grundaren, ett säljteam, drift, investerare, dina kunder?
• Vilka beslut stödjer den? ”Behöver vi anställa ytterligare en supportperson?” är en fråga en dashboard kan besvara. ”Visa mig vår data” kan den inte.
• Hur ofta kommer de att titta? Dagliga driftdashboards behöver färsk data och larm; en månatlig styrelsevy gör inte det.

Skriv ner tre till fem frågor. Varje blir ett eller två mätetal.

Definiera varje mätetal exakt

De flesta diskussioner om dashboards handlar egentligen om definitioner. Skriv en kort definition för varje siffra:

Klistra in dessa definitioner i din prompt. Annars väljer ett AI en rimlig men kanske felaktig beräkning som inte matchar hur ditt företag räknar.

Var datan kommer från

Två principer gäller överallt:

1. Håll nycklar på servern. API-nycklar och databaslösenord hör hemma i appens miljövariabler, aldrig i webbläsarkod.
2. Bestäm hur färsk datan ska vara. Att hämta från flera API:er vid varje sidladdning är långsamt och kan träffa hastighetsbegränsningar. För de flesta affärsdashboards är en synkning varje timme eller över natten till din egen databas, med en tid för ”senast uppdaterad” på sidan, enklare och mer pålitligt.

Om API:er är nya för dig förklarar vad är ett API och vad är en databas grunderna.

Välj rätt diagram

• Ett enskilt tal med förändring (”42 tkr, upp 8 % mot förra månaden”) – ett nyckeltalskort. Det mest användbara elementet på de flesta dashboards.
• Trend över tid – ett linjediagram. Använd staplar endast för ett litet antal perioder.
• Jämföra kategorier – ett horisontellt stapeldiagram, sorterat efter värde.
• Del av en helhet – ett staplat stapeldiagram. Cirkeldiagram fungerar bara med två eller tre skivor.
• Detaljer och avvikelser – en tabell med sortering, sökning och filter. Ofta mer användbar än något diagram.

Håll färgerna konsekventa: en färg för ”denna period”, en dämpad för ”jämförelse”, och rött endast för sådant som behöver uppmärksamhet.

Vem som ser vad

Bestäm åtkomst innan du bygger:

• Intern, alla ser allt – enklast. Behöver ändå inloggning om den innehåller affärsdata.
• Rollbaserad – försäljning ser försäljningssiffror, ekonomi ser marginaler, chefer ser sitt eget team.
• Kundvänd – varje kund ser endast sin egen data. Varje fråga måste filtrera på kundens konto på servern. Testa genom att logga in som två olika kunder.

En dashboard med omsättnings- eller kunddata på en offentlig URL utan inloggning är ett dataläckage som bara väntar på att upptäckas.

En första prompt som fungerar

Bygg en försäljningsdashboard för ett B2B-mjukvaruföretag med tio anställda. Målgrupp: grundarna och säljchefen, som kollar den varje måndag. Översiktssida: nyckeltalskort för ny MRR den här månaden, total MRR, nya kunder den här månaden, förlorade kunder den här månaden och pipelinevärde, var och en med förändringen mot förra månaden; ett linjediagram över MRR de senaste 12 månaderna; ett stapeldiagram över nya affärer per källa. En sida för affärer med en sökbar, sorterbar tabell (företag, ägare, värde, steg, avslutsdatum) och filter per ägare och steg. Definitioner: MRR är summan av aktiva månatliga prenumerationsbelopp, där årsplaner delas med 12; churn räknar kunder vars prenumeration upphörde den här månaden. Använd realistisk exempeldata i en databas tills vidare – vi kopplar Stripe senare. Visa en tid för ”senast uppdaterad”. Inloggning krävs. Ren sidonavigering.

Den anger målgruppen, varje mätetal med sin definition, diagrammen och dataplanen – och börjar med exempeldata, så att ni kan komma överens om designen innan ni kopplar riktiga källor.

Byggsteg

1. Layout med exempeldata. Kom överens om mätetal och diagram medan datan är påhittad och billig att ändra.
2. Koppla en riktig källa. Kontrollera varje siffra mot källsystemet för hand. Om MRR skiljer sig från vad Stripe visar, ta reda på varför innan du går vidare.
3. Lägg till de andra källorna, en i taget, och kontrollera varje.
4. Schemalagd uppdatering eller frågor vid sidladdning, med en etikett för ”senast uppdaterad”.
5. Filter – datumintervall först, sedan de ett eller två andra som folk frågar efter.
6. Inloggning och roller.
7. Tomma och felmeddelanden – vad sidan visar när en källa är nere eller ett filter ger inget resultat.
8. Dela den med målgruppen, och ta sedan bort allt som ingen tittar på efter en månad.

Gör den snabb

En långsam dashboard kontrolleras mer sällan. Förberäkna totaler som är dyra att räkna ut (en daglig sammanfattningstabell i stället för att skanna varje order), paginera stora tabeller och ladda huvudkorten först så att sidan är användbar innan diagrammen är klara. Om ett tal tar lång tid att räkna ut, visa när det senast beräknades i stället för att räkna om det vid varje besök.

Vanliga misstag

• För många diagram. Om allt är markerat syns ingenting.
• Odefinierade mätetal. Två personer som läser samma dashboard ska komma till samma slutsats.
• Att aldrig kontrollera siffrorna mot källan. En felaktig siffra och folk slutar lita på hela dashboarden.
• Att fråga varje API vid varje sidladdning. Långsamt, skört och ibland dyrt.
• Ingen datumkontext. Visa alltid perioden och jämförelsen.
• Hemligheter i frontend. En API-nyckel som syns i webbläsaren kan kopieras av vem som helst som öppnar sidan.

När ett BI-verktyg är det bättre valet

Om din data redan ligger i en databas eller ett datalager och de huvudsakliga användarna är analytiker som vill utforska den, dela upp den och bygga egna diagram, tjänar ett BI-verktyg – Looker Studio, Power BI, Metabase och andra – dem bättre än ett eget bygge. Många SaaS-verktyg har också bra inbyggda rapporter; kontrollera dem innan du bygger om dem. En egen dashboard vinner när den är till för kunder eller icke-analytiker, behöver logik eller behörigheter som BI-verktyget inte kan uttrycka, kombinerar källor på ett sätt som är specifikt för ditt företag, eller hör hemma i en produkt du redan driver.

Om uppgiften handlar mindre om att visa siffror och mer om att ändra poster, behöver du en adminpanel eller ett internt verktyg i stället – se hur du bygger ett internt verktyg. Och om dina siffror ligger i ett kalkylblad i dag är hur du förvandlar ett kalkylblad till en app nästa bra läsning.

Bygga det med Mythex

På Mythex beskriver du dashboarden och agenten bygger sidorna och diagrammen i en livevy, med början i realistisk exempeldata och en övergång till en dedikerad Postgres-databas när siffrorna behöver sparas. Dokumentationens användningsfall för dashboard har en startprompt. Om din data ligger i ett verktyg som Google Kalkylark kan du koppla kontot via Connectors och be agenten läsa det och bygga en dashboard utifrån det.

Det finns inga inbyggda datalagerkopplingar i appen själv – för BigQuery, Snowflake, Stripe och liknande anropar appen deras API:er med nycklar som du sparar som projekthemligheter. Inloggningar och roller för personerna som tittar på dashboarden är en del av appen du bygger. För att starta från en prompt, bläddra bland dashboard-mallarna, till exempel mätetalsdashboarden.

Frågor