Wie gestaltet man ein Dashboard?

Kurz gesagt

Page Laubheimer (NN/g) definiert ein Dashboard als Datenvisualisierungen, die auf einer Seite zusammengestellt sind. Ziel ist, Nutzern auf einen Blick Information zu geben, damit sie schnell handeln können. Laut Laubheimer ist ein Dashboard nicht für freies Erkunden gedacht.

Man sagt auch Admin-Panel, Verwaltungsoberfläche oder einfach Panel. Ich beschreibe hier alles als ein Muster: Der Nutzer schaut auf den Screen, sucht die Antwort auf eine Frage und entscheidet.

Das häufigste Dashboard-Problem in meinen Audits ist Überfülle. Das Team stellt jede verfügbare Kennzahl auf den Screen, der Nutzer findet die eine Zahl nicht, die er sucht. Im Live-Beispiel unten messen Sie diesen Unterschied mit Ihrer eigenen Zeit.

Zuerst Publikum und Entscheidung

Ein Dashboard beginne ich nicht mit einem Diagramm, sondern mit einer Frage. Wer schaut auf diesen Screen, und welche Entscheidung trifft er danach? Können Sie die Antwort nicht aufschreiben, können Sie auch nicht entscheiden, was auf den Screen gehört.

Laubheimer unterscheidet zwei Arten von Dashboards. Ein operatives Dashboard liefert bei zeitkritischer Arbeit schnell die entscheidende Information. Ständig wechselnde Daten wie Serverstatus oder Patientenwerte sind Beispiele.

Ein analytisches Dashboard ist für weniger dringende Entscheidungen. Es zeigt, welches Thema genauer betrachtet werden sollte. Mischen sich beide Arten auf einem Screen, sind beide schwer zu lesen.

Kate Moran (NN/g) beginnt auch die Wahl des Diagramms mit derselben Frage: Was ist Ihr Ziel? Laut Moran ist eine Zahl ohne Kontext bedeutungslos, um sie zu deuten, vergleichen wir sie mit einer anderen. In Morans Beispielen sind das frühere Jahre, eine andere Funktion oder eine andere Nutzergruppe.

Vor dem Start schreibe ich eine kurze Liste:

• Wer schaut auf diesen Screen, wie oft? Haben Sie eine Persona, beginnen Sie dort.
• Welche Frage stellt die Person, wenn sie draufschaut? Schreiben Sie sie in einen Satz, etwa „Welche Region liegt diesen Monat unter dem Ziel?“.
• Was tut sie, wenn sie die Antwort sieht? Ruft sie jemanden an, öffnet sie einen Eintrag? Vielleicht tut sie auch gar nichts.
• Womit vergleicht sie jede Zahl? Mit dem Ziel, dem Vorzeitraum oder einer anderen Gruppe.

Beim Admin-Panel ändert sich die Frage etwas. Wer verwaltet, schaut oft nicht auf eine Zahl, sondern sucht einen Eintrag und bearbeitet ihn. Warum in B2B-Produkten die Person, die kauft, und die, die nutzt, auseinanderfallen, beschreibe ich im Beitrag UX bei B2B und B2C.

Rangfolge: wo die wichtigste Information steht

Die sichtbarste Stelle des Screens gehört der Antwort auf die Frage des Publikums. Alles andere kommt danach oder zieht auf eine andere Seite um.

Kate Kaplan (NN/g) schreibt acht Richtlinien für komplexe Anwendungen. Die letzte betrifft das Hervorheben wichtiger Information. Laut Kaplan reicht es dafür nicht, Betonung hinzuzufügen, man muss Überflüssiges entfernen.

In Kaplans Beispiel hat ein Dashboard neben den Zahlen Icons zum Thema Geld. Kaplan schreibt, dass diese zusätzlichen Grafiken die visuelle Suche erschweren und schlichte Zahlenkarten das Finden der Daten erleichtern. Die bunten Icons im überladenen Dashboard unten sind von dieser Art.

Bei Warnungen gilt dieselbe Regel. Laubheimer sagt, dass Dashboards, die große Datenmengen überwachen, die Aufmerksamkeit auf kritische Werte lenken sollten. Warnungen, die ohne Priorisierung aufeinanderfolgen, bewirken das Gegenteil.

Ich nutze diese Reihenfolge:

1. Ganz oben die Antwort auf die Frage: ein Satz oder eine Zahl, mit Vergleich.
2. Darunter das Diagramm, das die Antwort erklärt.
3. Ganz unten oder per Klick die Details: Tabelle, Aufschlüsselung, Verlauf.

Kaplan empfiehlt außerdem, Details zu zeigen, ohne den Hauptscreen zu verlassen. Ein Beispiel ist, den genauen Wert in einem Tooltip zu zeigen, wenn man über einen Punkt im Diagramm fährt. Wie sich die Zahl der Optionen auf die Entscheidungszeit auswirkt, beschreibe ich auf der Seite zum Hick-Hyman-Gesetz.

Live-Beispiel: gleiche Daten, zwei Dashboards

Unten steht das Monats-Dashboard eines Vertriebsteams. In beiden Zuständen sind die Daten gleich. Im überladenen Zustand verteilt sich die Antwort auf ein Ringdiagramm, eine Legende und eine eigene Zieltabelle. Im schlichten Zustand steht die Antwort ganz oben, und das Diagramm darunter zeigt sie.

Probieren Sie die Aufgabe zuerst im überladenen Zustand, dann im schlichten. Beim zweiten Versuch sind Sie schneller, weil Sie die Antwort kennen, rechnen Sie das ein. Trotzdem erwarte ich, dass der größte Teil des Unterschieds vom Design kommt.

Gleiche Daten, zwei Dashboards

Überladener Zustand

Zeitraum: dieser Monat Kanal: alle Beträge: Tsd. € Aktualisiert: 9:00 Vergleich: Vormonat

Gesamtumsatz

1.135 Tsd. €

Zum Vormonat +2 %

Besuche

48.210

Zum Vormonat −3 %

Conversion-Rate

2,4 %

Zum Vormonat +0,1 Punkte

Warenkorbwert

61 €

Zum Vormonat +1 %

Retourenquote

3,1 %

Zum Vormonat −0,4 Punkte

Aktive Kunden

9.874

Zum Vormonat +5 %

Umsatzanteil nach Region

• Süd 168
• West 236
• Mitte 198
• Nord 121
• Ost 412

Zielerreichung gesamt

103 %

Ziele der Regionen (Tsd. €)

Region	Ziel	Vormonat
Ost	380	395
West	250	241
Mitte	190	185
Süd	160	171
Nord	120	118

Warnungen (7)

• Lager: 14 Produkte auf kritischem Stand
• West: Sommeraktion beendet
• Antwortzeit des Servers gestiegen
• Neue Kundenbewertungen: 23
• Süd: Rückgang zum Vormonat
• Rechnungsschnittstelle verzögert
• Wochenbericht bereit

Schlichter Zustand

Filter: dieser Monat, alle Kanäle. Beträge in Tsd. €.

1 Region unter dem Ziel: West. Sie liegt bei 94 % des Ziels, es fehlen 14 Tsd. €.

Umsatz und Ziel nach Region, die Region mit dem größten Abstand zum Ziel oben

• West 236 / 250, 94 % Unter dem Ziel

• Nord 121 / 120, 101 % Im Ziel

• Mitte 198 / 190, 104 % Im Ziel

• Süd 168 / 160, 105 % Im Ziel

• Ost 412 / 380, 108 % Im Ziel

Umsatz dieses Monats Ziel

Gesamtumsatz

1.135

Ziel 1.100

Zielerreichung

103 %

Summe der 5 Regionen

Regionen im Ziel

4 / 5

Nur West liegt unter dem Ziel

Die Daten sind erfunden und in beiden Dashboards gleich. Starten Sie die Aufgabe und wählen Sie unten die Region, sobald Sie die Antwort haben; Ihre Zeit wird notiert. Wählen Sie dann den anderen Zustand und versuchen Sie es erneut. Ohne JavaScript stehen beide Dashboards untereinander.

Im überladenen Zustand ziehen Sie im Kopf Zahlen von zwei Stellen voneinander ab. Die Warnung, dass Süd zum Vormonat gefallen ist, lenkt die Aufmerksamkeit außerdem auf die falsche Region. Süd ist gefallen, liegt aber weiter über dem Ziel.

Im schlichten Zustand ist die Region unter dem Ziel auf drei Wegen zu sehen: mit Text, mit Etikett und mit Schraffur. Auch wer Farben nicht unterscheiden kann, liest die Antwort aus Text und Muster.

Die Wahl des Diagramms

Bei der Wahl eines Diagramms frage ich mich: Was wird der Nutzer darin vergleichen? Laubheimer schreibt, dass Menschen Längen und die Position in zwei Dimensionen recht genau schätzen. Flächen und Winkel schätzen sie dagegen schlecht.

Deshalb sind Balken- und Liniendiagramm die Grundwerkzeuge für Zahlenvergleiche. Das Balkendiagramm nutzt Länge, Linien- und Streudiagramm nutzen Position.

Frage des Nutzers	Diagramm	Hinweis
Was ist größer?	Balkendiagramm	Sortieren Sie die Balken. Bei langen Labels empfiehlt Moran waagrechte Balken.
Wie hat es sich über die Zeit verändert?	Liniendiagramm	Moran empfiehlt, die Punkte zu markieren, an denen Daten erhoben wurden.
Wie nah ist es am Ziel?	Bullet Chart (Balken mit Ziellinie)	Laubheimer empfiehlt es statt einer Tachoanzeige.
Verändern sich zwei Dinge gemeinsam?	Streudiagramm	Die Punkte werden nicht mit einer Linie verbunden.
Wie steht eine einzelne Zahl?	Große Zahl	Schreiben Sie Ziel oder Vorzeitraum daneben.

Auch die Diagramme, die ich meide, stehen fest:

• Kreis- und Ringdiagramm. Laubheimer hält das Kreisdiagramm für die meisten Kommunikationsaufgaben für schwach. Die Ausnahme ist, wenn ein Teil mit Abstand am größten ist. Das Ringdiagramm ist wegen des Lochs in der Mitte noch schwerer zu lesen.
• Tachoanzeige. Runde Anzeigen wie im Auto arbeiten mit Winkeln und brauchen viel Platz. Laut Laubheimer sind sie schwerer zu lesen als lineare Diagramme.
• 3D-Diagramm. Drei Dimensionen verzerren Formen und Ausrichtung. Laut Laubheimer ist bei 3D-Balken sehr schwer zu sehen, welchen Wert die Oberkante zeigt und wie sie sich an den Hilfslinien ausrichtet.
• Gestapelter Balken. Moran schreibt, dass sich Teile, die nicht am selben Punkt beginnen, schwer vergleichen lassen. Sie empfiehlt stattdessen für jedes Ergebnis ein eigenes Balkendiagramm.
• Treemap. Laut Laubheimer gibt sie auf kleiner Fläche einen Überblick über einen komplexen Datenraum. Zu einem einfachen, handlungsorientierten Dashboard passt sie nicht.

Auch Farbe nutze ich nicht, um Größe zu zeigen. Laut Laubheimer hat Farbe keine natürliche Reihenfolge. Farbton oder Sättigung taugen dagegen als zweites Zeichen für Gruppierung.

Leere, ladende und fehlerhafte Zustände

Die am meisten vernachlässigten Zustände eines Dashboards sind die Momente, in denen keine Daten da sind oder noch nicht angekommen sind. In der Designdatei ist jede Karte gefüllt. Im echten Konto ist das Dashboard eines neuen Nutzers leer, oder eine Abfrage liefert nichts.

Leerer Zustand

Laut Kaplan lässt ein leeres Dashboard den Nutzer im Ungewissen. Läuft das System noch, gab es einen Fehler, oder ist der Filter falsch? Kaplan empfiehlt, eine kurze Statusmeldung in den leeren Bereich zu schreiben: „Im gewählten Zeitraum gibt es keine Einträge.“

Kaplan empfiehlt zwei weitere Schritte. Der leere Bereich kann lehren, was hierher kommt. Er sollte auch einen direkten Weg zu der Arbeit bieten, die ihn füllt. In Kaplans Beispiel steht in einem leeren Warnungspanel ein Button „Erstellen“.

Den leeren Screen eines neuen Kontos beschreibe ich gesondert im Muster Onboarding und im Muster leerer Zustand.

Laden

Auch zum Laden hat Kaplan eine Warnung. „Keine Einträge“ zu schreiben, während der Inhalt noch lädt, führt in die Irre. Der Nutzer wartet, verliert Vertrauen oder verlässt die Seite, bevor der Inhalt kommt.

Samhita Tankala (NN/g) unterscheidet nach Wartezeit:

• Unter 1 Sekunde: weder Skeleton Screen noch Spinner nötig.
• 2 bis 10 Sekunden: Spinner für eine einzelne Karte, Skeleton Screen für die ganze Seite.
• Über 10 Sekunden: ein Fortschrittsbalken mit Zeitschätzung.

Im Dashboard laden Karten oft einzeln, deshalb zeichne ich für jede Karte einen eigenen Ladezustand. Auch Tankalas Warnung beachte ich: Schimmernde oder pulsierende Skeletons können ablenken und Barrierefreiheitsprobleme verursachen.

Fehler

Tim Neusesser und Evan Sunwall (NN/g) verlangen, dass eine Fehlermeldung nah an der Stelle steht, an der das Problem auftritt. Im Dashboard ist das die Karte, die ihre Daten nicht holen konnte. Ich schreibe die Meldung nicht oben auf die Seite, sondern in diese Karte.

Die Meldung ist in einfacher Sprache geschrieben und schlägt eine Lösung vor. „Die Umsatzdaten kommen gerade nicht an. Versuchen Sie es in ein paar Minuten erneut.“ statt „Fehler 503“ ist ein Beispiel. Laut den Autoren sollte ein Fehler nicht nur mit Farbe oder Animation gezeigt werden.

Hat eine Karte einen Fehler, sollten die anderen weiterlaufen. Wird wegen einer einzigen Abfrage das ganze Dashboard zum Fehlerscreen, verbirgt das auch die funktionierenden Daten.

Filter

Laubheimer verlangt bei Datentabellen, dass Filter leicht zu finden, schnell und mächtig sind. Für Dashboard-Filter denke ich genauso. Der Nutzer sollte Zeitraum oder Region nicht suchen müssen.

Wichtiger ist diese Regel: Ist ein Filter aktiv, muss der Screen das klar sagen. Laubheimer verlangt ein deutliches visuelles Zeichen, dass Filter aktiv sind. Fehlt es, hält der Nutzer die gefilterte Zahl für die Gesamtzahl.

Eine Falle sehe ich in Audits oft. Der Nutzer hat letzte Woche einen Regionsfilter gewählt, das Dashboard merkt ihn sich, und heute wirken alle Zahlen niedrig. Eine Zeile oben auf dem Screen wie „Filter: West, letzte 7 Tage“ verhindert diese Verwirrung.

Kaplan zeigt außerdem als Beispiel, wie Änderungen beim Bearbeiten eines Dashboards sofort in der Vorschau erscheinen. Der Nutzer muss nicht bis zum Ende warten, um zu sehen, ob das Ergebnis seiner Absicht entspricht. Zeigen Sie selten genutzte Optionen nur, wenn sie gebraucht werden; Kaplan nennt das gestufte Offenlegung (staged disclosure).

Barrierefreiheit: Diagramme, die nicht von Farbe abhängen

Gibt ein Diagramm Information nur über Farbe weiter, können manche Nutzer es nicht lesen. Laubheimer schreibt, dass bis zu 4,5 % der Bevölkerung eine Form von Farbenblindheit haben. Bei Männern ist sie deutlich häufiger als bei Frauen.

Das Kriterium 1.4.1 Benutzung von Farbe in WCAG 2.2 (Stufe A) verlangt, dass Farbe nicht das einzige visuelle Mittel ist, um Information zu zeigen. Unter den ausreichenden Techniken des W3C stechen für Diagramme zwei hervor. Die eine ist, Muster zusätzlich zur Farbe zu nutzen (G111). Die andere ist, die per Farbe gegebene Information auch im Text zu geben (G14).

Das Kriterium 1.4.11 Nicht-Text-Kontrast (AA) verlangt für die Teile eines Diagramms, die man zum Verstehen braucht, mindestens 3:1 Kontrast zur angrenzenden Farbe. Laut dem Beispiel des W3C fallen die Linien eines Liniendiagramms unter diese Regel. Sind die Werte von Kreissegmenten auf andere Weise angemessen angegeben, gelten die Segmente nicht als nötig zum Verstehen.

In der Praxis mache ich Folgendes:

• Neben jeden Balken schreibe ich Namen und Wert. Niemand muss in der Legende Farben zuordnen.
• Werte unter dem Ziel markiere ich zusätzlich zur Farbe mit einem anderen Zeichen: Muster, Icon oder das Etikett „Unter dem Ziel“.
• Das Diagramm bekommt eine Textentsprechung, die der Screenreader vorliest. Auch die per Farbe gegebene Information steht darin.
• Farben von Linien und Balken messe ich im Kontrastrechner gegen den Hintergrund.

Alle Kriterien und Stufen beschreibe ich im WCAG-Ratgeber.

Dashboard auf dem Handy

Auf dem Handy stelle ich Karten, die nebeneinanderstehen, untereinander. Die Reihenfolge folgt der Rangfolge auf dem Desktop: Die Antwort auf die Frage bleibt oben. Öffnen Sie das Beispiel oben auf einem schmalen Screen, sehen Sie die Karten untereinander.

Breite Tabellen bringe ich nicht durch kleinere Schrift aufs Handy. Ich mache aus jeder Zeile eine Karte oder zeige nur die zwei wichtigsten Spalten. Die Größe der Tippziele stelle ich nach der Logik des Fittsschen Gesetzes ein.

Checkliste vor dem Launch

• Publikum des Screens und seine Entscheidung habe ich in einem Satz aufgeschrieben.
• Die oberste Information ist die Antwort auf diese Entscheidung.
• Neben jeder Zahl steht ein Vergleich: Ziel, Vorzeitraum oder ähnliche Gruppe.
• Deko-Icons und 3D-Effekte habe ich entfernt.
• Statt Kreis, Ring und Tachoanzeige nutze ich Balken oder Bullet Chart.
• Für jede Karte sind leerer, ladender und fehlerhafter Zustand gezeichnet.
• Der aktive Filter steht als Text auf dem Screen.
• Die Diagramme sind auch ohne Farbe lesbar.
• Auf dem Handy stehen die Karten in der Rangfolge untereinander.

Die letzte Prüfung mache ich mit echten Nutzern. Ich stelle die eigentliche Frage des Dashboards und schaue, wie lange die Antwort dauert. Wie ich das aufsetze, beschreibe ich im Ratgeber zum Usability-Test.

Meine Notiz

Ob ein Dashboard gut ist, prüfe ich mit einem einzigen Test. Ich stelle der Person vor dem Screen ihre eigentliche Frage und zähle, nach wie vielen Sekunden sie die Antwort hat. Dauert es lange, ist das Problem fast immer Überfülle.

Teams finden es leicht, Karten hinzuzufügen, und schwer, sie zu entfernen. Jede Karte hat einen Besitzer, und niemand will, dass seine Kennzahl verschwindet. Deshalb empfehle ich Umziehen statt Löschen: Details gehen auf eine Unterseite, auf dem Hauptscreen bleibt die Entscheidung.

Und ich bitte um eines: Zeichnen Sie das Dashboard nicht mit den sauberen Daten der Designdatei, sondern mit echten, unordentlichen Daten. Wenn ein langer Regionsname, ein Nullwert oder ein fehlender Monat den Screen zerstört, wollen Sie das vor dem Launch sehen.