Dashboard-Design, das Entscheidungen treibt, nicht Eitelkeit

Dienstag, 21:47 Uhr. Die Slack-Benachrichtigung. „Hey, dieser Bericht ist falsch. Unser MRR zeigt 4,1 Mio., aber Finance sagt 4,3 Mio. Könnten Sie mal nachsehen?"

Sie öffnen das Dashboard. Sie haben es seit sieben Monaten nicht mehr angefasst. Im Besitzerfeld steht „Sarah K.", und Sarah hat das Unternehmen im Oktober verlassen. Es gibt 14 Diagramme. Drei von ihnen behaupten, MRR zu zeigen, und alle sind unterschiedlich. Der letzte Besucher war vor drei Wochen, und das waren Sie, als Sie es geöffnet haben, um den Link in genau diesem Thread zu teilen.

Diese Benachrichtigung ist kein Datenqualitätsproblem. Es ist ein Designproblem. Wahrscheinlich Ihr Designproblem, aus einem Build, den Sie in einem Sprint geliefert haben, den Sie längst vergessen haben.

Die meisten BI-Tools berichten still dieselbe Zahl: Irgendwo zwischen 60 und 80 Prozent der Dashboards werden in ihrer gesamten Lebensdauer weniger als fünf Mal geöffnet. Lookers eigene Nutzungsdaten, Tableau Server-Admin-Logs, Hex's Nutzungsanalysen: überall dasselbe Bild. Der Friedhof ist größer als die lebendige Fläche. Und jedes tote Dashboard kostet Sie trotzdem: Warehouse-Abfragekosten für das geplante Aktualisieren, Vertrauensverlust, wenn Stakeholder widersprüchliche Zahlen finden, und Ihre Kalenderzeit, wenn jemand es um 21:47 Uhr wieder aufleben lässt.

Dieses Playbook ist die Designdisziplin, die Ihre Dashboard-Anzahl stabil hält oder reduziert, während das Vertrauen der Stakeholder wächst. Es ist das Handwerk erfahrener Analysten, kein BI-Anbieter-Theater.

Die Prinzipien, die den Kühlschrank-Dashboard töten

Bevor es konkrete Regeln gibt: drei Prinzipien. Wer diese verinnerlicht, schreibt den Rest selbst.

Eine Entscheidung pro Dashboard. Schreiben Sie die Entscheidung in den Titel. Nicht „Sales-Übersicht". Das ist ein Thema, keine Entscheidung. Schreiben Sie „Sollten wir die Q3-Sales-Planung überarbeiten?" oder „Welche AE-Pipelines brauchen diese Woche eine Manager-Prüfung?" Wenn Sie die Entscheidung nicht in einem Satz formulieren können, wissen Sie nicht, wofür das Dashboard da ist, und die Person, die es öffnet, auch nicht. Themen vermehren sich. Entscheidungen nicht.

Visuelle Hierarchie, keine visuelle Demokratie. Die Hauptkennzahl auf dem Dashboard sollte mindestens dreimal größer sein als alles andere auf der Seite. Eye-Tracking-Studien zu BI-Tools (Tableau Research, 2023) zeigen, dass Nutzer 60 % ihrer ersten 8 Sekunden auf dem größten Element verbringen. Wenn alles gleich groß ist, haben Sie dem Nutzer mitgeteilt, dass nichts wichtig ist. Wählen Sie die eine Zahl, die die Entscheidung beantwortet. Machen Sie sie groß. Alles andere ist unterstützende Information.

Farbdisziplin. Eine Akzentfarbe für die Marke oder die primäre Kennzahl. Grau für alles andere. Rot und Grün nur für Abweichungen gegenüber einem Zielwert, niemals für kategoriale Reihen. Wenn Ihr Diagramm „Umsatz nach Region" rote, grüne, blaue, gelbe und orangefarbene Balken hat, haben Sie dem Nutzer beigebracht, dass Rot nichts bedeutet. Wenn Rot dann tatsächlich „wir haben das Planziel verfehlt" bedeutet, kommt das nicht an. Farbe ist ein begrenztes Budget. Die meisten Analysten verbrauchen es im ersten Diagramm.

Diese drei sind das Fundament. Der Rest ist Anwendung.

Die 5-Kennzahl-Regel

Kein Dashboard wird mit mehr als 5 primären Kennzahlen geliefert. Punkt.

Das ist die Regel, gegen die alle kämpfen, und alle liegen dabei falsch. Das Argument ist immer dasselbe: „Aber der VP möchte X und Y und auch Z sehen." Gut. Bauen Sie sie irgendwo. Nur nicht auf derselben Oberfläche wie die Entscheidung.

Warum 5? Die Kognitionsforschung zur Arbeitsgedächtniskapazität (Miller, 1956; verfeinert von Cowan 2001 auf 4 plus/minus 1) bildet die Untergrenze. In einem Meeting, mit jemandem, der präsentiert, während Slack benachrichtigt, liegt die praktische Grenze noch niedriger. Ein Dashboard mit 14 Elementen wird nicht gelesen. Es wird überflogen. Der Nutzer greift sich die zwei, die überraschend aussehen, und ignoriert den Rest. Sie haben 12 Elemente gebaut und erhalten dafür zwei Elemente Aufmerksamkeit.

Die Regel, angewendet:

• Wenn Sie 5 primäre Kennzahlen haben und jemand um eine 6. bittet, bauen Sie zwei Dashboards. Eines dient Entscheidung A, das andere Entscheidung B. Trennen Sie sie.
• Wenn Sie nicht entscheiden können, welche 5 es sind, haben Sie noch nicht entschieden, welche Entscheidung das Dashboard bedient. Gehen Sie zu Schritt eins zurück.
• Detailaufschlüsselungen sind keine Kennzahlen. Eine anklickbare Hauptkennzahl, die eine Aufschlüsselung öffnet, ist eine Kennzahl, keine sieben. Behandeln Sie die Anzahl der Oberflächenelemente als Grenze.
• „Referenz"-Elemente (eine Definition, ein Aktualisierungsstempel, ein Filterbereich) zählen nicht zu den 5. Nur Elemente, die ein Stakeholder liest, um die Entscheidung zu treffen.

Ich habe Dashboards mit drei Kennzahlen geliefert. Drei. Der CFO öffnet diese wöchentlich. Ich habe Dashboards mit elf Kennzahlen geliefert. Der CFO hat diese einmal geöffnet und mich gebeten, „die wichtigste Erkenntnis zusammenzufassen". Das ist dasselbe Dashboard, das scheitert.

Kontext schlägt Visualisierung, immer

Hier ist die Ketzerei: Eine Zahl mit einer schriftlichen Analyse schlägt ein schönes Diagramm ohne Beschreibung. Jedes Mal.

„MRR: 4,18 Mio. (-4,2 % MoM)" mit einer einzeiligen Anmerkung (, „Rückgang durch 3 Enterprise-Abwanderungen in EMEA, alle drei beim QBR markiert; Expansion-Buchungen von 2,1 Mio. gleichen den Nettowert auf -1,8 % aus") ist nützlicher als das schönste Liniendiagramm der Welt. Weil das Diagramm Ihnen zeigt, dass etwas passiert ist. Die Anmerkung sagt Ihnen, was passiert ist, warum, und ob Sie in Panik geraten müssen.

Machen Sie das zur Regel für jedes Element, das auf ein Dashboard kommt, das ein Mensch liest: eine Zeile mit „Was hat sich verändert und warum". Kein Absatz. Eine Zeile. Wenn Sie sie nicht schreiben können, ist das Element noch nicht bereit zur Veröffentlichung.

Das ist der Teil, den die meisten Analysten überspringen, weil er sich wie Schreiben anfühlt, nicht wie Analyse. Es ist Analyse. Der Akt, „-4,2 % wegen drei Enterprise-Abwanderungen in EMEA" zu schreiben, zwingt Sie dazu, die Frage tatsächlich zu beantworten, anstatt das Diagramm zu präsentieren und weiterzugehen. Wenn die Antwort lautet „Ich weiß es noch nicht", ist auch das eine gültige Anmerkung. „-4,2 % MoM, Ursache bis Freitag zu klären, siehe #data-investigations" teilt dem Stakeholder mit, dass Sie es gesehen haben, daran arbeiten und er Sie nicht anschreiben muss. Die Benachrichtigung, die Sie nicht erhalten, ist der zeilenweise höchste ROI, den Sie diese Woche schreiben werden.

Tools, die das erleichtern: Hex's Textzellen neben Diagrammzellen, Lookers HTML-Element mit einem vorlagenbasierten Kommentar, Tableau-Dashboards mit einem Textfeld-Fußnotenkommentar pro Element. Alle unterstützen das Muster. Keines erzwingt es. Sie erzwingen es.

Die Nachbetrachtung zum „Dieser Bericht ist falsch"-Alarm

Irgendwann wird ein Stakeholder eine Zahl infrage stellen. Das ist unvermeidbar. Die Frage ist, ob Sie es wie ein Profi handhaben oder wie jemand, der einen Slack-Streit gewinnen will.

Hier ist das Protokoll. Prägen Sie es sich ein. Es wird Ihre Karriere mindestens zweimal retten.

Schritt 1. Innerhalb von 5 Minuten bestätigen, nicht in 5 Stunden. „Verstanden, ich schaue nach und melde mich bis EOD mit meinen Erkenntnissen." Das ist die gesamte Nachricht. Nicht verteidigen. Nicht streiten. Nicht erklären, warum Ihre Zahl richtig ist, bevor Sie tatsächlich nachgeprüft haben. Die Unsicherheit des Stakeholders sinkt sofort, sobald er „ich schaue nach" liest.

Schritt 2. Die Abfrage bestätigen. Öffnen Sie das zugrunde liegende SQL. Führen Sie es neu aus. Reproduzieren Sie die Dashboard-Zahl? Falls ja, lügt das Dashboard nicht. Es gibt immer noch die Frage, ob die Abfrage richtig ist, aber die Oberfläche ist konsistent. Falls nein, haben Sie ein Caching- oder Zeitplanungsproblem; melden Sie es und aktualisieren Sie.

Schritt 3. Die maßgebliche Datenquelle bestätigen. Was sagt Finance / RevOps / das System der Aufzeichnung? Ist Ihre mrr-Spalte von subscriptions.amount abgeleitet oder aus einer materialisierten Ansicht monthly_recurring_revenue, die 2022 von jemandem erstellt wurde, der das Unternehmen verlassen hat? Zieht Finance direkt aus Stripe, während Sie aus einer Fivetran-Synchronisierung ziehen, die 6 Stunden veraltet ist? 90 % der „Dieser Bericht ist falsch"-Tickets lösen sich hier auf, und die Auflösung ist selten „das Dashboard ist falsch" oder „Finance liegt falsch". Es ist: „Wir berechnen zwei leicht unterschiedliche Dinge und nennen sie beim gleichen Namen."

Schritt 4. Den Unterschied dokumentieren. Füllen Sie in der Nachbetrachtungsvorlage aus: Zeitstempel des Berichts, verwendete Abfrage (einfügen), Wert der maßgeblichen Datenquelle, Dashboard-Wert, Ursache (Definitionsunterschied / veraltete Daten / echter Fehler), Lösung (erneut ausführen / Definitionsänderung / neue Anmerkung) und Stakeholder-Kommunikation.

Schritt 5. Innerhalb von 24 Stunden eine Lösung oder einen Hinweis liefern. Entweder beheben Sie das zugrunde liegende Problem, oder Sie fügen eine elementbezogene Anmerkung hinzu, die die Abweichung erklärt. Beides ist akzeptabel. Was nicht akzeptabel ist: es liegen zu lassen, während zwei Unternehmensbereiche weiterhin mit unterschiedlichen Zahlen arbeiten.

Niemals in Slack-Threads streiten. Diskussionen in Threads sind das, wodurch Analysten den Ruf bekommen, „defensiv" zu sein. Verlagern Sie das Gespräch innerhalb von 30 Minuten in das Nachbetrachtungsdokument. Das Dokument ist das Artefakt. Der Thread ist der Lärm.

Ich führe ein laufendes Protokoll jeder Nachbetrachtung, die ich erstellt habe. Sie erneut zu lesen ist die wertvollste Weiterentwicklungsmaßnahme, die ich kenne. Ich sehe genau, welche Definitionsunterschiede immer wieder auftauchen (es ist immer die Umsatzerfassung, immer), und wo sich Investitionen in vorgelagerte Korrekturen lohnen. Jeder Alarm ist auch ein Signal dafür, welches Element eine dauerhafte Anmerkung braucht, damit die nächste Person nicht nachfragen muss.

Der Nutzungsgrad ist die Kennzahl, die beweist, dass das Dashboard funktioniert

Das Dashboard, das Sie letztes Quartal gebaut haben: Funktioniert es? Die meisten Analysten können diese Frage nicht beantworten, was seltsam ist, weil wir professionell besessen von Messung sind.

Messen Sie den Nutzungsgrad. Jedes BI-Tool hat die Daten:

• Looker hat System Activity, ein internes Explore. history.query_run_count, dashboard.view_count, user.id, alles abfragbar.
• Tableau Server / Cloud hat das Admin-Insights-Projekt. views_workbooks und views_dashboards liefern Öffnungen pro Asset und Nutzer.
• Hex hat integrierte Nutzungsanalysen auf der Seite mit den Workspace-Einstellungen.
• Mode hat die Discovery API und Admin-Berichte.
• Power BI hat Nutzungsberichte pro Workspace.

Verfolgen Sie drei Zahlen pro Dashboard, monatlich:

1. Eindeutige Besucher. Nicht Öffnungen. Menschen. Ein Dashboard mit 200 Öffnungen von 2 Besuchern ist ein Tab, den jemand angeheftet gelassen hat, kein funktionierendes Dashboard.
2. Zeit auf dem Dashboard. Ein Dashboard, das niemand scrollt, liest niemand. Die meisten BI-Tools protokollieren die Sitzungsdauer; unter 30 Sekunden bedeutet, dass jemand es geöffnet und sofort verlassen hat.
3. Wiederkehrende-Besucher-Rate. Von den Besuchern des letzten Monats: Wie viele sind diesen Monat zurückgekehrt? Die wiederkehrenden Besucher sind das echte Publikum. Alle anderen kamen einmal und gingen weiter.

Ein Dashboard mit weniger als 3 eindeutigen Besuchern pro Monat, zwei Monate in Folge, ist ein Kandidat für die Außerbetriebnahme. Kein „braucht eine Überarbeitung"-Kandidat. Ein Kandidat für die Außerbetriebnahme. Hören Sie auf, Dinge zu optimieren, die niemand öffnet.

Die nützlichste Übung, die ich quartalsweise durchführe: Ich ordne alle Dashboards, die ich besitze, nach wiederkehrenden Besuchern. Die Top 5 bekommen meine Zeit und Aufmerksamkeit. Die untersten 5 bekommen eine Außerbetriebnahme-Prüfung. Der mittlere Bereich bekommt wohlwollende Vernachlässigung, was in Ordnung ist. Vernachlässigung ist günstig, Außerbetriebnahme ist ehrlich, und aktive Pflege ist teuer. Investieren Sie sie dort, wo sie sich auszahlt.

Die 6-Monats-Außerbetriebnahme-Prüfung

Außerbetriebnahme ist ein Feature, kein Versagen. Wenn Sie das verinnerlichen, werden Sie sich nie wieder schlecht fühlen, wenn Sie ein Dashboard abschalten.

Alle sechs Monate führen Sie die Prüfung durch. Blockieren Sie einen halben Tag. Ziehen Sie die Nutzungsdaten für alle Dashboards in Ihrem Bereich. Sortieren Sie aufsteigend nach eindeutigen Besuchern. Dann:

1. Alles unter 3 Besuchern/Monat in den letzten 6 Monaten: archivieren. Nicht löschen. Archivieren. Verschieben Sie es in einen ausgeblendeten Ordner, veröffentlichen Sie eine Ankündigung in #data-archive mit den verschobenen Dashboards und verlinken Sie die Archivliste. Wenn jemand protestiert, können Sie es in 60 Sekunden wiederherstellen. Niemand wird protestieren. Sie haben es nicht geöffnet.
2. Alles zwischen 3 und 10 Besuchern/Monat: Eigentümerschaft erneut bestätigen. Schreiben Sie den genannten Eigentümer an. „Besitzen Sie das noch? Noch relevant? Gibt es noch eine benannte Entscheidung?" Wenn der Eigentümer das Unternehmen verlassen hat, sind Sie der neue Eigentümer. Entscheiden Sie, ob es sich lohnt zu behalten oder zu archivieren. Keine Antwort innerhalb einer Woche = archivieren.
3. Alles über 10 Besucher/Monat: behalten, Elementanmerkungen prüfen, veraltete Zahlen aktualisieren und die Entscheidung im Titel aktualisieren, wenn sich das Geschäft verändert hat. Das sind Ihre echten Arbeitsflächen. Sie verdienen Pflege.
4. Die Abschalteliste öffentlich machen. Eine kurze Nachricht im Datenkanal der Organisation: „Prüfung abgeschlossen: 12 Dashboards archiviert, 47 behalten, hier ist die Liste." Drei Dinge passieren: (a) Niemand beschwert sich, weil nichts, das tatsächlich genutzt wurde, verschwunden ist. (b) Andere Teams sehen den Rhythmus und beginnen, eigene durchzuführen. (c) Die Führungsebene bemerkt, dass jemand die BI-Instanz wie Infrastruktur behandelt, nicht wie einen Schrottplatz.

Als ich zum ersten Mal bei einem früheren Unternehmen eine solche Prüfung durchgeführt habe, archivierte ich 38 Dashboards. Zwei Personen schrieben mir, beide über dasselbe Dashboard, das ich in drei Minuten wiederhergestellt habe. Das ist die gesamte Risikofläche. Die Belohnung war eine BI-Instanz, die schneller lud, klarere Suchergebnisse hatte und deutlich weniger „Warten Sie, welches ist jetzt das echte Umsatz-Dashboard?"-Threads auf Slack produzierte.

In sechs Monaten sollte Ihre BI-Instanz weniger Dashboards haben als heute. Nicht mehr. Wenn sie mehr hat, funktioniert die Designdisziplin nicht und der Außerbetriebnahme-Rhythmus wird übersprungen. Beides ist behebbar. Beides ist Ihre Aufgabe.

Vorlagen, die Sie verwenden können

Dashboard-Spezifikation (eine Seite). Ausfüllen, bevor Sie bauen:

• Entscheidung, die dieses Dashboard beantwortet: (ein Satz, endet mit einem Verb)
• Zielgruppe: (benannte Rolle, nicht „Stakeholder")
• 5 primäre Kennzahlen, priorisiert: (1, 2, 3, 4, 5)
• Aktualisierungsrhythmus: (Echtzeit / stündlich / täglich / wöchentlich, passend zur Entscheidungsgeschwindigkeit)
• Eigentümer: (benannte Person, kein Team)
• Außerbetriebnahme-Kriterien: („archivieren, wenn unter 3 eindeutige Besucher/Monat für 60 Tage")

Nachbetrachtungsvorlage. Innerhalb von 24 Stunden nach jeder Herausforderung ausfüllen:

• Gemeldet von, wann, in welchem Kanal
• Erwartete Zahl des Stakeholders im Vergleich zur Dashboard-Zahl
• Verwendete Abfrage (vollständiges SQL einfügen)
• Vergleich mit maßgeblicher Datenquelle (Finance / RevOps / Systemwert)
• Ursache (Definition / Aktualität / Fehler / Nutzerfehler / tatsächlich korrekt)
• Ausgelieferte Lösung (Link zum PR oder zur Anmerkung)
• Kommunikation an Stakeholder (Antwort einfügen)

Checkliste für die 6-Monats-Prüfung. Blockieren Sie einen halben Tag und führen Sie die Prüfung durch:

• Nutzungsdaten für alle eigenen Dashboards ziehen
• Aufsteigend nach eindeutigen Besuchern sortieren
• Archivieren: unter 3 Besucher/Monat für 6 Monate
• Eigentümerschaft bestätigen: 3 bis 10 Besucher/Monat
• Prüfen und aktualisieren: über 10 Besucher/Monat
• Abschalteliste öffentlich machen
• Außerbetriebnahmeprotokoll aktualisieren (Datum, Anzahl archiviert, Anzahl behalten)

Diese drei Dokumente decken 90 % der Dashboard-Hygiene ab. Drucken Sie sie aus. Hängen Sie sie auf. Verwenden Sie sie.

Häufige Fehler

Einige Muster, die ich wiederholt bei jedem Team sehe:

• Aus der Anfrage bauen, nicht aus der Entscheidung. Der Stakeholder sagt „Ich möchte ein Diagramm der Conversion nach Quelle". Sie bauen es. Sie liefern es. Sechs Wochen später öffnet es niemand, weil die eigentliche Entscheidung „Sollten wir den Google Ads-Vertrag weiterführen?" war, und dafür wären CAC nach Quelle plus Bindungsüberlagerung nötig gewesen, kein Conversion-Balkendiagramm. Fragen Sie immer nach der Entscheidung, bevor Sie SQL schreiben.
• Das Executive-Dashboard mit 14 Elementen, weil der VP „alles sehen möchte". Der VP möchte nicht alles sehen. Der VP möchte sich informiert fühlen und die zwei Überraschungen erkennen. Geben Sie ihm ein 5-Element-Dashboard mit einer einzeiligen schriftlichen Zusammenfassung oben, und er wird Ihnen danken. Wahrscheinlich irgendwann befördern.
• Regenbogen-Paletten. Acht Reihen, acht Farben, alle mit derselben Sättigung. Der Nutzer liest nichts. Verwenden Sie eine Akzentfarbe, grauen Sie alles andere aus, heben Sie nur die Reihe hervor, von der die Entscheidung abhängt.
• Niemals außer Betrieb nehmen, nur hinzufügen. Das ist der langsame Tod. Jedes Quartal steigt die Anzahl. Jedes Quartal sinkt die durchschnittliche Dashboard-Qualität. Nach sechs Monaten ist die BI-Instanz nicht mehr durchsuchbar, und drei verschiedene Dashboards zeigen drei verschiedene MRR-Werte. Die Lösung ist der Prüfungsrhythmus. Ohne ihn häufen Sie für immer technische Schulden an.

Was „gut" aussieht

Sie haben das verinnerlicht, wenn:

• Jedes Dashboard, das Sie besitzen, eine benannte Entscheidung im Titel hat, kein Thema.
• Sie auswendig Ihre Top-5-Dashboards nach Nutzungsgrad und Ihre untersten 5 Außerbetriebnahme-Kandidaten aufzählen können.
• „Dieser Bericht ist falsch"-Benachrichtigungen von Quartal zu Quartal abnehmen, weil jedes Element eine schriftliche Analyse hat, die der Stakeholder zuerst liest.
• Die BI-Instanz in 6 Monaten weniger Dashboards hat als heute, nicht mehr.
• Ihr Nachbetrachtungsprotokoll mindestens 5 Einträge aus dem letzten Jahr enthält und Sie auf die vorgelagerte Lösung hinweisen können, die aus jedem hervorging.

Das ist der Maßstab. Nicht „Ich habe mehr Dashboards gebaut." Nicht „Stakeholder lieben meine Diagramme." Sondern: Ich habe Arbeitsflächen geliefert, die Menschen nutzen, ich habe die Fehler dokumentiert, und ich habe die abgeschaltet, die es nicht verdient haben.

Dashboard-Design ist keine ästhetische Übung. Es ist eine Aufmerksamkeitsbudget-Übung. Jedes Element kostet die Aufmerksamkeit eines Stakeholders. Jedes Dashboard kostet Ihre Wartungszeit. Gehen Sie mit beidem so um, als wären sie knapp, denn das sind sie.

Weiterführende Artikel

• Stakeholder-Management für Data Analysten
• SQL und Datenmodellierung, die skaliert
• Data-Analyst-Kennzahlen: Zeit bis zur Erkenntnis, Nutzungsgrad, Wirkung
• Data Analyst Stellenbeschreibungsvorlage