Die meisten SaaS-Dashboards werden von Entwicklern gebaut, die die Daten verstehen. Selten werden sie von Menschen gestaltet, die verstehen, was ein neuer Nutzer sieht, wenn er sich zum ersten Mal einloggt, nichts vorfindet und den Tab schließt.
Diese zwölf Muster decken den gesamten Lebenszyklus der Dashboard-Nutzung ab – vom Empty State, den ein neuer Nutzer sieht, bis zur datendichten Ansicht, die ein Power User nach sechs Monaten braucht.
Der Empty State ist der Screen, den Nutzer beim ersten Login sehen, bevor sie Daten hinzugefügt haben. In den meisten SaaS-Produkten ist es auch der Screen mit der höchsten Abbruchrate.
Ein guter Empty State leistet drei Dinge:
Er zeigt, wie der befüllte Zustand aussieht. Kein trauriges Icon mit „Noch keine Daten“. Sondern eine Vorschau darauf, wie das Dashboard aussehen wird, sobald Daten hinzugefügt wurden. Nutzer müssen den Mehrwert sehen, auf den sie hinarbeiten.
Er bietet genau eine Aktion. „Verbinden Sie Ihre erste Integration“ oder „Erstellen Sie Ihr erstes Projekt“. Eine Aktion, ein Button. Nicht drei Optionen und ein Hilfeartikel.
Er erklärt, warum der Zustand leer ist. „Ihre Analysedaten erscheinen hier, sobald Sie das Tracking-Snippet installiert haben.“ Kontext verhindert die Verunsicherung, ob etwas kaputt ist.
Der Empty State ist Onboarding. Behandeln Sie ihn auch so.
Der häufigste Dashboard-Fehler ist, alles auf einmal zu zeigen. Jede Kennzahl, jeden Filter, jede Ansicht für Sonderfälle auf dem Standard-Screen.
Progressive Disclosure bedeutet: das Wesentliche zeigen, Details bei Bedarf einblenden.
Eine praktische Umsetzung: Eine Übersichtskarte zeigt die zentrale Kennzahl. Ein Klick klappt die vollständige Aufschlüsselung, den Trend und die Exportoptionen auf. Nutzer, die die Übersicht brauchen (die meisten Nutzer, die meiste Zeit), bekommen sie sofort. Nutzer, die Tiefe brauchen, bekommen sie einen Klick weiter.
Das wirkt sich messbar auf die Aktivierung aus. Nutzer, die am ersten Tag ein einfaches, klares Dashboard sehen, aktivieren häufiger als Nutzer, die ein komplexes sehen – selbst wenn die komplexe Version technisch mehr Mehrwert bietet.
Overlays (modale Touren, Spotlight-Walkthroughs) eignen sich für Funktionen, die sich nicht von selbst aus der UI erschließen. Wenn Sie erklären müssen, wie die Navigation funktioniert, ist die Navigation falsch. Wenn Sie einen nicht offensichtlichen Workflow erklären müssen, ist ein Overlay angebracht.
Inline-Hilfen (kontextbezogene Tooltips, Hilfetexte direkt in der UI) sind besser für dauerhafte Unterstützung, die Nutzern jedes Erfahrungslevels hilft. Ein „?“-Icon neben der Definition einer komplexen Kennzahl ist nützlicher als eine einmalige Tour, die 70 % der Nutzer durchklicken, ohne sie zu lesen.
Der typische Fehler: Overlays einsetzen, um eine unklare UI auszugleichen. Wenn Nutzer die Tour regelmäßig brauchen, um das Produkt zu verstehen, gestalten Sie das Produkt neu, nicht die Tour.
Ein Dashboard ist keine Tabellenkalkulation. Nicht alle Kennzahlen sind gleich wichtig. Die visuelle Hierarchie Ihrer Kennzahlenkarten sollte die geschäftliche Hierarchie der Kennzahlen widerspiegeln.
Primäre Kennzahlen (die ein oder zwei Zahlen, die Erfolg definieren) erhalten die oberste Position, die größte Darstellung und das klarste visuelle Gewicht. Das sind die Zahlen, die Ihre Nutzer jeden Morgen prüfen.
Sekundäre Kennzahlen (Einflussfaktoren, Aufschlüsselungen der primären Kennzahl) erscheinen darunter, kleiner und mit weniger visueller Betonung.
Tertiäre Kennzahlen (Diagnosedaten, Sonderfälle, Admin-Zahlen) gehören in eine Detailansicht oder einen separaten Bereich, nicht auf das Haupt-Dashboard.
Ein häufiger Fehler: alle Kennzahlen gleich zu behandeln, weil das Entwicklungsteam alle zugrunde liegenden Daten gleich schätzt. Nutzer brauchen Hierarchie, um zu wissen, worauf sie sich konzentrieren sollen.
Beides ist legitim. Die Wahl hängt davon ab, was Nutzer mit den Daten tun müssen.
Verwenden Sie Tabellen, wenn:
Verwenden Sie Karten, wenn:
Viele Dashboards verwenden Karten, wo Tabellen angebracht wären, weil Karten in einem Dribbble-Mockup besser aussehen. Bei großer Anzahl (50+ Einträge) lassen sich Karten langsamer überblicken und schwerer vergleichen als Tabellen.
Die meisten SaaS-Dashboards werden Desktop-first und Mobile-last gebaut. Die mobile Version ist ein Nachgedanke, der das Desktop-Layout in eine einzige Spalte zusammenschiebt und das für erledigt erklärt.
Ein wirklich responsives Dashboard definiert das mobile Erlebnis neu, statt es nur herunterzuskalieren:
Mobil werden weniger Kennzahlen gezeigt. Das vollständige Kennzahlenset des Desktops ist für einen 390-px-Bildschirm zu dicht. Die mobile Ansicht sollte standardmäßig die drei wichtigsten Kennzahlen zeigen, mit einem Link „Alle anzeigen“.
Aktionen erscheinen anders. Desktop: Aktionen stehen in einer Reihe. Mobil: Aktionen befinden sich in einem Bottom Sheet oder einem ausklappbaren Menü.
Tabellen werden zu Karten. Eine zwölfspaltige Tabelle auf dem Desktop wird mobil zu einer Liste ausklappbarer Karten. Jede Zeile wird zu einer Karte, auf der die wichtigsten Attribute sichtbar sind.
Diagramme nutzen mobiloptimierte Formate. Liniendiagramme funktionieren mobil. Komplexe Diagramme mit mehreren Datenreihen nicht. Passen Sie das Format an, nicht nur die Größe.
Der Ladezustand ist das, was Ihr Nutzer zwischen dem Klick und dem Ergebnis erlebt. Die meisten Dashboards behandeln ihn als technische Notwendigkeit statt als Gestaltungschance.
Skeleton Screens (Platzhalterformen in etwa der Größe der ladenden Inhalte) verkürzen die gefühlte Ladezeit im Vergleich zu Spinnern deutlich. Der Nutzer sieht die Struktur entstehen, statt darauf zu warten, dass überhaupt etwas passiert.
Optimistic Updates (die UI wird sofort mit dem erwarteten Zustand aktualisiert und anschließend vom Server bestätigt) lassen Interaktionen unmittelbar wirken. Das ist nur angebracht, wenn die Aktion sehr wahrscheinlich gelingt.
Fortschrittsanzeigen mit Kontext („Ihre Daten der letzten 90 Tage werden abgerufen …“) sind besser als Spinner, wenn der Vorgang tatsächlich lange dauert (>3 Sekunden). Nutzer wissen, warum sie warten.
Dashboards sammeln Warnungen an. Ein Produkt ohne Hierarchie lässt alles wie einen Notfall aussehen – und damit wirkt nichts mehr wie einer.
Vier Stufen, jeweils mit eigener visueller Behandlung:
Kritisch (rot, dauerhaft): Etwas ist kaputt und erfordert sofortige Aufmerksamkeit. Sparsam einsetzen, sonst verliert es seine Bedeutung.
Warnung (gelb-orange, ausblendbar): Etwas könnte bald Aufmerksamkeit erfordern. Auf zwei oder drei gleichzeitige Warnungen begrenzen.
Info (blau, blendet sich automatisch aus): Nützlicher Kontext, der aber kein Handeln erfordert. Verschwindet nach 5–7 Sekunden.
Erfolg (grün, blendet sich automatisch aus): Bestätigung, dass eine Aktion funktioniert hat. Verschwindet nach 3–5 Sekunden.
Verwenden Sie Rot nie für etwas, das nicht wirklich kritisch ist. Sobald Sie Nutzern beibringen, dass Rot auch bei Kleinigkeiten erscheint, erregen kritische Warnungen keine Aufmerksamkeit mehr.
Power User bedienen Dashboards vor allem über Filter und Suche. Ihr Erlebnis verschlechtert sich drastisch, wenn diese langsam, eingeschränkt oder schlecht gestaltet sind.
Die Suche sollte universell und schnell sein. Ein Suchfeld, Antwortzeit unter 200 ms, Treffer über alle relevanten Entitäten hinweg. Fuzzy Matching (Ergebnisse auch bei Tippfehlern) für jedes Produkt mit mehr als 100 Einträgen.
Filter sollten bestehen bleiben. Wenn ich auf „letzte 30 Tage“ filtere, zu einer Unterseite navigiere und zurückkehre, sollte der Filter noch gesetzt sein. Persistente Filter sind der Unterschied zwischen einem Werkzeug und einem Spielzeug.
Der Filterzustand sollte in der URL kodiert sein. Gefilterte Ansichten sollten sich teilen lassen. Ein Teamleiter, der eine bestimmte gefilterte Ansicht mit seinem Team teilen möchte, sollte die Filterkonfiguration nicht beschreiben müssen – er sollte eine URL einfügen können.
Die meisten Dashboards verwenden zu viele Diagrammtypen. Das ist ein Komplexitätsproblem, das das Verständnis verringert.
Die drei Diagrammtypen, die 90 % des Visualisierungsbedarfs in Dashboards abdecken:
Liniendiagramm – Trends im Zeitverlauf. Der Standard für alles mit einer Zeitdimension.
Balkendiagramm – Vergleich zwischen Kategorien. Verwenden Sie es, wenn Sie mehrere Einträge miteinander vergleichen.
Ring-/Kreisdiagramm – Verhältnis von Teil zu Ganzem. Nur verwenden, wenn das proportionale Verhältnis die eigentliche Aussage ist. Nie für mehr als fünf Segmente.
Alles andere (Flächendiagramme, Streudiagramme, Heatmaps, Funnel-Diagramme) ist eine Spezialisierung, die in einen eigenen Analysebereich gehört, nicht auf das Haupt-Dashboard. Im Zweifel wählen Sie das einfachere Format.
Der Export wird oft als Nebensache behandelt und gehört doch zu den meistgewünschten Funktionen jedes Teams, das ein SaaS-Tool für den geschäftlichen Einsatz kauft.
Jede Tabelle sollte sich als CSV exportieren lassen. Jedes Diagramm sollte sich als Bild (PNG) oder mit den zugrunde liegenden Daten (CSV/JSON) exportieren lassen. Jede gefilterte Ansicht sollte sich in ihrem aktuellen Filterzustand exportieren lassen.
Das ist technisch nicht komplex. Es signalisiert Enterprise-Käufern, dass Sie ihre Daten ernst nehmen, reduziert Einwände wie „Das können wir für unser Reporting nicht nutzen“ und erhöht mit der Zeit die Wechselkosten Ihres Produkts.
Gute Dashboards verfallen. Funktionen kommen hinzu, Kennzahlen vermehren sich, und das Dashboard wird nach und nach zu einem Friedhof von Daten, die sich niemand ansieht.
Ein vierteljährliches Dashboard-Audit stellt drei Fragen:
Was sieht sich niemand an? Nutzen Sie Analytics in Ihrem eigenen Produkt. Welche Karten, Diagramme und Tabellen hatten in den letzten 30 Tagen keine einzige Interaktion? Entfernen Sie sie.
Wonach suchen Nutzer, ohne es zu finden? Ihre eigenen Suchprotokolle sind eine Produkt-Roadmap. Wenn Nutzer nach etwas suchen, das es im Dashboard nicht gibt, fügen Sie es hinzu.
Worauf beziehen sich Support-Tickets? Wenn Nutzer immer wieder Tickets zum selben verwirrenden Verhalten einreichen, lässt das Dashboard sie im Stich.
Einfachheit ist kein Designtrend – sie ist eine Wartungsverpflichtung. Die Dashboards, die Nutzer halten, sind diejenigen, die kontinuierlich entfernen, was ihnen nicht dient.
Sie bauen ein SaaS-Dashboard und möchten eine zweite Meinung zu Ihren Designentscheidungen? Sprechen Sie uns an – wir prüfen die UX Ihres Dashboards und sagen Ihnen, was Sie Aktivierung kostet.
Wir nehmen jeden Quartal eine begrenzte Anzahl von Projekten an. Erzählen Sie uns, was Sie bauen.
Typografie-Hierarchie, zu viele Stockfotos, inkonsistente Farben, fehlende Vertrauenssignale: acht konkrete Gründe, warum Startup-Websites billig wirken, und wie Sie jeden davon ohne kompletten Neubau beheben.
Wir haben 10 Top-Marketing-Websites zerlegt (Linear, Stripe und mehr): Core Web Vitals, Hero-Texte, Social Proof und was Sie für Ihre eigene Website übernehmen können.
