7 schlechte Tortendiagramme und wie man sie repariert
|
10
min. Lesezeit
Wenn ein Tortendiagramm das Signal verdeckt, liegt das Problem meist nicht allein an der Verzierung. Es liegt daran, dass das Diagramm ein Dashboard fertig aussehen lässt und die eigentliche Entscheidung erschwert. Eine Torte ist vertretbar, wenn sie sinnvolle Teile eines klaren Ganzen zeigt, mit sehr wenigen Segmenten, und die Lesenden nur eine einfache Teil-Ganzes-Aussage brauchen statt eines präzisen Vergleichs. Das ist ein engerer Anwendungsfall, als viele annehmen, besonders in der Arbeit an Datenqualität und Observability, wo Menschen Vorfälle priorisieren, Systeme vergleichen und entscheiden müssen, was zuerst behoben wird.
Deshalb ist der übliche Rat „nie Tortendiagramme verwenden“ zu grob. Eine neuere Übersicht hält fest, dass die Skepsis gegenüber Tortendiagrammen durch Edward Tuftes Anweisung „Don't use pie charts“ bekannt wurde und dass moderne Texte zu Diagrammen noch immer die Formel „Pie charts are evil“ wiederholen, obwohl die Forschung differenzierter beurteilt, wann Torten für einfache Teil-Ganzes-Urteile funktionieren können (Übersicht zur Kritik an Tortendiagrammen und aufgabenbezogenen Befunden). Für Teams, die Dashboards bauen, zählt diese Differenzierung genauso wie die Warnung.
Wenn Sie in Analytik, Observability oder BI arbeiten, gilt warum Visualisierung für das Marketing zählt auch für Sie. Dieselbe Diagrammwahl, die ein Kampagnen-Dashboard trübt, kann auch die Triage von Anomalien verzögern oder ein Schemaproblem verdecken.
Die sieben schlechten Tortendiagramme unten nutzen einen kompakten Test. Was ist gescheitert, warum führt es in die Irre, was nutzt man stattdessen und welche Maßnahme ergreift man, bevor das Diagramm in ein Dashboard oder eine Vorfallsbesprechung gelangt.
Inhaltsverzeichnis
1. Zu viele Segmente ohne Aggregation
Ein Tortendiagramm mit vielen kleinen Segmenten zeigt die Verteilung nicht klar. Es verdeckt die Arbeitsliste.
In Dashboards zu Datenqualität und Observability zeigt sich dieser Fehlschlag, wenn jeder Regelverstoß, jeder verspätete Job, jedes Schemaereignis und jeder Anomalietyp ein eigenes Segment erhält. Das Ergebnis wirkt vollständig, weil jede Kategorie vorkommt, doch das Diagramm trägt die operative Frage hinter dem Dashboard nicht mehr. Welche Problemfamilie treibt das Risiko, und wo sollte das Team mit der Behebung beginnen?
Der Entscheidungspreis ist ein Priorisierungsfehler. Dünne Segmente lassen sich schwer vergleichen, Beschriftungen überlappen, und die Lesenden müssen zwischen Segment, Farbe und Legende hin- und herspringen, bevor sie urteilen. Leitlinien zum Visualisierungsentwurf halten fest, dass Tortendiagramme scheitern, wenn sie viele Segmente enthalten, auf Legenden angewiesen sind oder Beschriftungen in kleine Bereiche zwängen. Sie werten auch einen großen „Sonstige“-Topf oder starken Farbeinsatz als Zeichen, das Diagramm zu überdenken (Leitlinien zum Scheitern von Tortendiagrammen und zur Überladung im Entwurf).
Ein verbreitetes Observability-Beispiel ist das Vorfallsvolumen nach Regel-ID. Zeigt das Diagramm 18 gescheiterte Regeln als 18 Segmente, sieht das Team, dass vieles schiefläuft, aber nicht, welche Fehlerklasse die Behebungszeit frisst. Gruppieren Sie dieselben Ereignisse in Vollständigkeits-, Frische-, Gültigkeits-, Schema- und Zugriffsprobleme, und es entsteht ein anderes Bild. Nun trägt das Diagramm Personaleinsatz, Eskalation und Ursachenprüfung.
Besserer Ersatz
Nutzen Sie ein sortiertes Balkendiagramm, wenn die Aufgabe Rangfolge ist. Nutzen Sie einen Donut nur, wenn die Botschaft eine einfache Teil-Ganzes-Zusammenfassung ist und die Zahl der Kategorien nach der Aggregation klein bleibt.
Das ist auch ein Datenqualitätsproblem, nicht nur ein Entwurfsproblem. Zu viele Segmente signalisieren oft, dass die Taxonomie für die Entscheidungsfläche zu feinkörnig ist. Sind Kategorien auf Ereignis- statt auf Handlungsebene definiert, spiegelt das Dashboard die rohe Protokollstruktur statt der operativen Bedeutung.
Praktische Regel: Lautet die Frage „was beheben wir zuerst“, nutzen Sie Balken. Lautet die Frage „wie teilt sich dieses Ganze auf“, reduzieren Sie Kategorien, bis die Aufteilung sofort lesbar ist.
Nach Behebungsweg gruppieren: Fassen Sie einzelne Fehlschläge zu Kategorien wie Vollständigkeit, Frische, Gültigkeit und Schema zusammen.
Nur den echten langen Schwanz zusammenfassen: Nutzen Sie „Sonstige“ für Kategorien mit geringer Wirkung, nicht für Probleme, die weiterhin um Engineering-Zeit konkurrieren.
Sichten nach Überwachungsziel trennen: Zeigen Sie Timeliness, Schemaänderungen und Anomaliemuster in getrennten Diagrammen, statt eine Torte mehrere Fragen tragen zu lassen.
Die Verteilung definieren, bevor Sie sie zeichnen: Teams, die einen klareren Rahmen brauchen, können diesen Leitfaden nutzen: wie man die Verteilung von Daten beschreibt.
2. 3D-Effekte und perspektivische Verzerrung
Ein 3D-Tortendiagramm fügt keine Information hinzu. Es verändert die wahrgenommene Größe.
In der Observability-Arbeit wird aus dieser visuellen Verzerrung eine operative Verzerrung. Ein vorn liegendes Segment kann dominant wirken, selbst wenn es einen kleineren Anteil gescheiterter Jobs, verzögerter Pipelines oder umgebungsspezifischer Vorfälle darstellt. Eine Vorfallsverantwortliche, die das Diagramm überfliegt, eskaliert womöglich zuerst die falsche Warteschlange. Ein Plattformteam ordnet Engineers womöglich der Kategorie mit der stärksten visuellen Präsenz zu statt jener mit den größten operativen Kosten.
Der Fehlschlag ist leicht zu übersehen, weil das Diagramm weiterhin geschliffen aussieht. Doch die Entscheidungsaufgabe hier ist keine Verzierung. Es ist Vergleich unter Zeitdruck. Geneigte Geometrie stört diese Aufgabe, weil sie Fläche und Winkel schwerer beurteilbar macht, besonders wenn Kategorien ähnlich groß sind.
Forschung zum Diagrammlesen stützt diese Sorge. Ein Experiment von 2019 fand, dass Tortendiagramme bei Vergleichsaufgaben langsamer und ungenauer waren als gestapelte Balkendiagramme, besonders bei kleinen Unterschieden zwischen Kategorien (kontrolliertes Experiment zu den Kosten von Tortendiagrammen). Ein 3D-Effekt legt einem Diagrammtyp, der bei präzisen Vergleichen ohnehin schlecht abschneidet, eine weitere Schicht Schätzfehler auf.
Die bessere Frage lautet: Welche Entscheidung soll das Diagramm tragen?
Muss das Team das Vorfallsvolumen über Regionen, Dienste oder Fehlerklassen vergleichen, nutzen Sie ein sortiertes Balkendiagramm. Braucht das Team eine schnelle Momentaufnahme der Zusammensetzung für einen Vorstandsbericht, kann ein flacher Donut funktionieren, aber nur, wenn die Kategorienzahl klein bleibt und die Beschriftungen direkt sind. In beiden Fällen bleibt die Geometrie ehrlich, was bedeutet, dass das Gespräch über die Behebung von der tatsächlichen Verteilung ausgeht statt von einer verzerrten.
Was Sie in der Praxis ändern
3D standardmäßig ausschalten: Deaktivieren Sie Perspektive und Neigung in Excel, Power BI, Tableau oder der Diagrammbibliothek interner Dashboards.
Diagramm zur Handlung passend wählen: Nutzen Sie Balken für Priorisierung, Rangfolge und teamübergreifenden Vergleich.
Betonung nutzen, die den Maßstab erhält: Heben Sie mit Reihenfolge, Anmerkung oder gezielter Farbe hervor, nicht mit Tiefeneffekten.
Alte Dashboards prüfen: Sehen Sie Vorstands- und Bereitschaftssichten auf alte 3D-Torten durch, besonders dort, wo Teams sie nutzen, um Untersuchungszeit oder Eskalationsaufwand zu verteilen.
3D-Gestaltung signalisiert meist ein tieferes Berichtsproblem. Das Dashboard optimiert auf visuelle Neuheit, während die Betreiberin Messgenauigkeit braucht. In Abläufen zu Datenqualität und Observability ist dieser Tausch teuer, weil kleine Wahrnehmungsfehler die Triage-Reihenfolge verschieben, die Ursachenanalyse verzögern und das Vertrauen in das Dashboard selbst schwächen können.
3. Zu wenig Kontrast und schlechte Farbwahl
Ein Tortendiagramm kann numerisch korrekt sein und dennoch die Entscheidung verfehlen, die es tragen sollte.
Denken Sie an eine Vorfallsbesprechung, in der ein Dashboard Datenqualitätsfehler in Kategorien wie fehlende Werte, Schemadrift, Frischeverzögerungen und doppelte Datensätze aufteilt. Teilen zwei benachbarte Segmente ähnliche Sättigung oder Helligkeit, hört das Diagramm auf, eine Zusammenfassung zu sein, und wird zur Aufgabe visueller Prüfung. Unter Zeitdruck ändert das Verhalten. Teams stecken Mühe in das Entschlüsseln der Darstellung, statt zu entscheiden, welcher Fehlermodus zuerst behoben werden muss.
Das Problem beschränkt sich nicht auf Ästhetik oder Barrierefreiheits-Checklisten. In der Observability-Arbeit trägt Farbe oft operative Bedeutung wie Schweregrad, Status oder Verantwortung. Ein kontrastarmes Tortendiagramm nimmt dieses Signal genau dort weg, wo eine Analystin, ein Engineer oder ein Product Manager Hintergrundrauschen von einem echten Dienstproblem trennen will. Kleine Segmente trifft es doppelt. Die Tortengeometrie erschwert ihren Vergleich ohnehin, und schwacher Farbkontrast lässt sie leichter übersehen.
Kodierung allein über Farbe bricht auch Übergaben. Eine Stakeholderin erinnert sich vielleicht, dass „das grüne Segment größer aussah“, ohne zu behalten, welche Kategorie Grün war, besonders in exportierten Berichten oder Screenshots. Das schwächt die Priorisierung genau dort, wo Teams eine gemeinsame Deutung über Funktionen hinweg brauchen.
Der bessere Ersatz hängt von der Aufgabe ab. Geht es um die Rangfolge von Kategorien, nutzen Sie ein sortiertes Balkendiagramm mit direkten Beschriftungen und zurückhaltender Palette. Geht es um eine kompakte Momentaufnahme der Zusammensetzung, behalten Sie Torte oder Donut nur, wenn die Kategorienzahl klein ist, Beschriftungen auf den Marken sitzen und der Kontrast auch bei Farbsehschwächen lesbar bleibt. Teams, die auf visuelle Datenprüfung zur Verbesserung der Produktqualität setzen, brauchen Diagramme, die Deutungsfehler senken, nicht solche, die sie hinzufügen.
Nutzen Sie vor der Veröffentlichung einen einfachen Prüfstandard:
Prüfen Sie die Lesbarkeit in Graustufen, nicht nur in voller Farbe.
Nutzen Sie Paletten mit klarer Helligkeitstrennung, etwa Okabe-Ito oder Viridis.
Ergänzen Sie für wichtige Kategorien ein zweites Erkennungsmerkmal, etwa direkte Beschriftungen oder Muster.
Testen Sie die exportierte Fassung, denn Folien und PDFs senken den Kontrast oft weiter.
Schlechte Farbwahl in einem Tortendiagramm ist ein Berichtsfehler mit nachgelagerten Kosten. Sie kann eine wachsende Fehlerklasse verdecken, die Triage verlangsamen und den Behebungsaufwand auf das falsche Problem lenken.
4. Fehlende oder irreführende Beschriftungen und Legenden
Ein Tortendiagramm kann eine kleine Kategorienzahl überstehen. Es scheitert viel schneller, wenn die Betrachtenden nicht erkennen können, wofür jedes Segment steht, wie groß die Vorfallsmenge ist oder welches Zeitfenster das Diagramm abdeckt.
Denken Sie an ein Dashboard, das während eines Datenqualitätsvorfalls genutzt wird. Die Torte zeigt ein großes Segment und mehrere kleine, mit einer Legende am Rand und im Export abgeschnittenen Beschriftungen. Eine Vorfallsverantwortliche muss nun Farben entschlüsseln, Kategorienamen erraten und nach der Gesamtzahl fragen, bevor sie entscheidet, ob sie Schemadrift, Null-Spitzen oder verzögerte Ladevorgänge eskaliert. Das Diagramm hat seine Aufgabe bereits verfehlt. Es hat Deutungsarbeit hinzugefügt, genau als das Team Priorisierung brauchte.
Der Nenner zählt ebenso wie die Kategorienamen. Ein mit 40 % beschriftetes Segment bedeutet sehr Verschiedenes, je nachdem, ob es 4 fehlerhafte Datensätze, 400 gescheiterte Prüfungen oder 40 % aller Produktionstabellen des letzten Tages abbildet. Ohne Gesamtzahl und Zeitraum kann ein Tortendiagramm weder Triage noch Kapazitätsplanung noch Nachbetrachtung tragen.
Aufgabenbezogene Leitlinien zur Diagrammwahl machen die Grenze deutlich. Torten- und Donut-Diagramme können bei einfacher Teil-Ganzes-Lektüre funktionieren, wenn die Segmentzahl klein und die Botschaft kategorial statt präzise ist, wie in dieser Einschätzung, wann Torten- und Donut-Diagramme vertretbar sind vermerkt. Nehmen Sie direkte Beschriftungen oder Kontext weg, und selbst dieser enge Anwendungsfall bricht zusammen.
Ein praktischer Prüfstandard hilft:
Setzen Sie den Kategorienamen auf oder direkt neben das Segment.
Ergänzen Sie Gesamtzahl der Vorfälle und Berichtszeitraum im Titel oder Untertitel.
Nutzen Sie Hinweise für kleine Segmente, statt sich auf eine abgesetzte Legende zu verlassen.
Ersetzen Sie die Torte durch ein sortiertes Balkendiagramm, wenn Beschriftungen nicht mehr sauber passen.
Prüfen Sie die exportierte PDF- oder Folienfassung, denn Observability-Reviews finden oft außerhalb des Live-Dashboards statt.
Für Teams, die operatives Reporting bauen, ist Beschriftung Teil des Diagrammentwurfs, nicht abschließender Feinschliff. Dieser Leitfaden zu wie man Datenqualitäts-Dashboards baut, die wirklich funktionieren ist nützlich, weil er Diagrammstruktur an Behebungsabläufe bindet statt an Dekoration.
Der praktische Ersatz ist meist einfach. Geht es um die Behebungspriorität, nutzen Sie ein sortiertes Balkendiagramm mit direkten Beschriftungen, Anzahlen und Prozentwerten. Geht es um eine kompakte Momentaufnahme der Zusammensetzung, behalten Sie die Torte nur, wenn jedes Segment direkt benannt werden kann und die Gesamtzahl sichtbar bleibt, ohne die Legende zu durchsuchen.
5. Mehrere Tortendiagramme nebeneinander vergleichen
Nebeneinanderstehende Tortendiagramme sehen nach Vergleich aus, doch sie schwächen den Vergleich genau dann, wenn ein Team eine Entscheidung braucht.
Der Fehlschlag ist in Berichten zu Observability und Datenqualität leicht zu erkennen. Ein Dashboard zeigt eine Torte für die Validierungsfehler dieser Woche und eine für die der Vorwoche, oder je eine für Produktion, Staging und Entwicklung. Die beabsichtigte Frage ist operativ: Wo hat sich die Zuverlässigkeit verschlechtert, und welches Problem sollte zuerst behoben werden? Getrennte Kreise erschweren diese Antwort, weil Lesende Winkel, Bogenlängen und Flächen über verschiedene Formen hinweg vergleichen müssen, statt gegen eine gemeinsame Grundlinie zu lesen.
Aus dem visuellen Problem wird ein Priorisierungsproblem
Das britische Office for National Statistics hält fest, dass Tortendiagramme für Vergleiche schlecht taugen, weil sie weder eine gemeinsame Achse noch einen Bezugspunkt haben, und dass reine Winkelurteile am schlechtesten abschneiden, während die Bogenlänge wichtige Information trägt (ONS-Analyse zur Wahrnehmung von Tortendiagrammen und zu Vergleichsgrenzen). In der Praxis heißt das: Ein Team spürt Bewegung, ohne sie präzise genug zu benennen, um zu handeln.
Eine Zuverlässigkeitsverantwortliche, die Vorfallskategorien über zwei Torten prüft, schließt womöglich, dass Schemafehler diese Woche „größer aussehen“. Offen bleiben die Fragen, die für die Behebung zählen: Nahmen Schemafehler in der Anzahl zu, stiegen sie anteilig, weil eine andere Kategorie fiel, oder blieben sie gleich, während die Gesamtzahl der Vorfälle sank? Trennt das Diagramm diese Fälle nicht, verschiebt sich die Besprechung von Diagnose zu Deutung.
Diese Mehrdeutigkeit hat operative Kosten. Teams können Rückstandspunkte falsch einordnen, Zeit mit der Debatte verbringen, ob eine Pipeline schlechter wurde, oder einen kleinen, aber bedeutsamen Anstieg in einer Kategorie mit hohem Schweregrad übersehen, weil er visuell nicht auffällt.
Nutzen Sie Diagrammtypen, die die Entscheidungsaufgabe erhalten
Wählen Sie den Ersatz nach der Frage.
Für den Verlauf: nutzen Sie ein Liniendiagramm, um Vorfallszahlen, gescheiterte Prüfungen oder verzögerte Ladevorgänge über die Zeit zu zeigen.
Für die Zusammensetzung über Zeiträume oder Umgebungen: nutzen Sie gestapelte Balken, damit jede Kategorie auf einer gemeinsamen Grundlinie sitzt.
Für den Vergleich Kategorie für Kategorie: nutzen Sie gruppierte Balken, wenn absolute Unterschiede mehr zählen als Anteile.
Für gemischte operative Reviews: trennen Sie Anzahl und Anteil in zwei Diagramme, wenn eine Sicht beides nicht sauber tragen kann.
Das zählt in der BI-Umsetzung ebenso wie im Entwurf. BI-Entwicklerwerkzeuge für Reporting-Abläufe sind nützlich, wenn sie Verlaufs-, Vergleichs- und Drilldown-Sichten leichter baubar machen als dekorative Torten.
Ein guter Ersatz verkürzt die Diskussionszeit und verbessert die Qualität der Behebung. Das Team sieht, ob Null-Wert-Fehler zunahmen, ob eine Umgebung ein Ausreißer ist und ob die Verschiebung groß genug ist, um eine Eskalation zu rechtfertigen. Das ist der Maßstab. Macht ein Diagramm Veränderung schwerer überprüfbar, ist es keine Zusammenfassung. Es ist Reibung im Entscheidungsprozess.
6. Tortendiagramme für Zusammensetzung, wenn das Teil-Ganzes-Verhältnis unklar ist
Ein Tortendiagramm kann sauber und beschriftet und dennoch für die Entscheidung falsch sein.
Der Fehlschlag entsteht, wenn Teams unverbundene Kennzahlen in eine Teil-Ganzes-Darstellung zwingen. In Reviews zu Observability und Datenqualität heißt das oft, Validierungsfehlerquote, Verzögerung der Timeliness und Häufigkeit von Schemaänderungen in einen Kreis zu packen, weil sie sich Dashboard-Fläche teilen. Diese Maße teilen kein gemeinsames Ganzes. Sie nutzen verschiedene Einheiten, beantworten verschiedene Fragen und weisen auf verschiedene Behebungswege.
Dieser Entwurfsfehler verändert die Besprechung. Prüfende fragen nicht mehr „Welches Problem wurde schlimmer?“, sondern „Welches Segment ist am größten?“. Das Diagramm drängt das Team, ungleiche Maße gegeneinander zu ordnen, obwohl ein Anstieg der Verzögerungsstunden und ein Anstieg gescheiterter Prüfungen getrennte Verantwortliche, getrennte Schwellen und getrennte Eskalationsregeln verlangen können.
Forschung zur Teil-Ganzes-Schätzung hilft, die Grenze zu klären. Eine Studie zu Anteilsurteilen fand, dass Tortendiagramme gut abschneiden können, wenn Betrachtende Anteile eines echten Ganzen schätzen, besonders wenn visuelle Anker verfügbar sind (Experiment zur Teil-Ganzes-Schätzung und zu visuellen Ankern). Diese Evidenz stützt Tortendiagramme im engen Fall, für den sie gebaut wurden. Sie rechtfertigt nicht, sie zu nutzen, um unabhängige operative Kennzahlen zu einer künstlichen Zusammensetzung zu verbinden.
Prüfen Sie das Datenmodell, bevor Sie das Diagramm wählen
Stellen Sie eine strengere Frage als „Passt das auf eine Karte?“. Fragen Sie, ob jede Kategorie denselben Nenner aufteilt.
Lautet die Antwort nein, kodiert das Tortendiagramm eine Beziehung, die es nicht gibt.
Nutzen Sie Alternativen, die zur operativen Aufgabe passen:
Unabhängige KPIs: zeigen Sie getrennte Karten oder kompakte Tabellen für Quoten, Anzahlen und Verzögerungen.
Gemeinsamer Nenner: nutzen Sie Balken nur, wenn Kategorien ein Ganzes aufteilen, etwa Vorfallsvolumen nach Ursache.
Verfolgung der Behebung: nutzen Sie Linien oder Balken, wenn die Frage Veränderung, Rückstandswachstum oder Konzentration nach Verantwortlichen ist.
Berichtsabläufe: Datenqualitäts-Reporting ist verlässlicher, wenn Vollständigkeit, Frische, Genauigkeit und Schemastabilität getrennte Maße mit eigenen Schwellen bleiben.
Der praktische Test ist einfach. Lässt ein Diagramm ungleiche Kennzahlen austauschbar wirken, verzerrt es die Priorisierung. Wahrt es Einheiten und Verantwortung, trägt es schnellere, besser begründbare Entscheidungen.
7. Herausgezogene Segmente ohne logische Hierarchie
Herausgezogene Segmente wirken analytisch, kodieren aber oft gar keine Entscheidungsregel. In einem Betriebs-Dashboard ist das kein Stilproblem. Es ist ein Priorisierungsfehler.
Denken Sie an ein Datenqualitäts-Review, in dem ein Segment für „Schemaänderungen“ herausgezogen ist. Wurde es abgesetzt, weil es gedrängt aussah, können Betrachtende es dennoch als größtes Risiko, als aktuellen Vorfall oder als das Team lesen, das zuerst Aufmerksamkeit braucht. Das Diagramm hat ein zweites Signal jenseits der Segmentgröße hinzugefügt, ohne zu definieren, was dieses Signal bedeutet.
Diese Mehrdeutigkeit zählt in der Observability-Arbeit. Teams nutzen Dashboards, um zu entscheiden, was sie triagieren, wer die Behebung verantwortet und welche Problemtypen Eskalation verdienen. Ein herausgezogenes Segment kann Aufmerksamkeit auf eine Kategorie ziehen, die weder die größte noch die schwerwiegendste ist. Kleine Kategorien werden dann überprüft, während Fehlschläge mit großem Volumen wie Frischelücken oder Null-Spitzen im Hintergrund bleiben.
Betonen Sie nur, wenn die Hierarchie ausdrücklich ist
Tortendiagramme erschweren feinkörnige Vergleiche ohnehin stärker als geordnete Position oder ausgerichtete Länge. Eine Übersicht zur Forschung über Diagrammwahrnehmung in einer Dissertation fand bei Vergleichsaufgaben schwächere Leistung in tortenbasierten Darstellungen als in einfacheren Alternativen wie Balken (Zusammenfassung der Diagrammgenauigkeit nach Aufgabe aus einer Dissertation). Das Absetzen erhöht die Auffälligkeit, ohne die Messung zu verbessern, sodass die visuelle Betonung die tatsächliche Reihenfolge operativer Wichtigkeit überwiegen kann.
Der praktische Maßstab ist einfach. Ist ein Segment herausgezogen, sollte das Dashboard die Regel im Klartext nennen.
Gute Regeln sind etwa:
höchste Vorfallszahl
höchste geschätzte Geschäftswirkung
Verletzung eines SLA oder einer Fehlerbudget-Schwelle
Kategorie, die derzeit zur sofortigen Behebung zugewiesen ist
Gibt es keine Regel, entfernen Sie den Effekt.
Bessere Alternativen für operative Dashboards
Nutzen Sie das Diagramm, das zur Entscheidung passt:
Prioritätsreihenfolge nötig: nutzen Sie ein sortiertes Balkendiagramm nach Vorfallsvolumen, betroffenen Assets oder geschätzter Wirkung.
Dringende Handlung nötig: halten Sie die Zusammensetzungssicht flach und legen Sie kritische Kategorien in eine eigene Vorfallswarteschlange oder ein Alarmpanel.
Klarheit über Verantwortung nötig: nutzen Sie eine Tabelle mit Kategorie, Schweregrad, Verantwortlichen und Status.
Veränderung über die Zeit nötig: nutzen Sie ein Linien- oder gestapeltes Balkendiagramm, damit Wiederholung und Drift sichtbar werden.
Ein Tortendiagramm kann Anteile zusammenfassen. Es sollte keine Hierarchie erfinden. In Abläufen zu Datenqualität und Observability macht unerklärte Betonung aus Dekoration eine falsche Priorität, und falsche Priorität verlangsamt die Behebung.
Vergleich von 7 verbreiteten Fallen bei Tortendiagrammen
Titel | Umsetzungsaufwand 🔄 | Ressourcenbedarf ⚡ | Erwartete Ergebnisse 📊⭐ | Ideale Anwendungsfälle 💡 | Wichtigste Vorteile ⭐ |
|---|---|---|---|---|---|
Zu viele Segmente ohne Aggregation | 🔄 Gering–mittel, einfach zu bauen, braucht Aggregationslogik | ⚡ Gering, Standarddiagramme; geringe Datengruppierung nötig | 📊 Diagramm wird unleserlich; verdeckt Prioritäten; verzögert Triage | 💡 Nur für ≤5–7 Kategorien oder nach Zusammenfassen kleiner Posten zu „Sonstige“ | ⭐ Leicht zu erstellen, aber ohne Aggregation diagnostisch wenig wert |
3D-Effekte und perspektivische Verzerrung | 🔄 Mittel, erfordert 3D-Rendering und Einstellungen | ⚡ Gering, keine Zusatzarbeit an Daten, aber visuelle Feinabstimmung nötig | 📊 Verzerrt Anteile; bringt Perspektivverzerrung; führt Entscheidungen in die Irre | 💡 In analytischen Dashboards vermeiden; allenfalls dekorativ ohne Entscheidungsbezug | ⭐ Nur visueller Schmuck; kein Genauigkeitsgewinn (für Observability meiden) |
Zu wenig Kontrast und schlechte Farbwahl | 🔄 Gering, Entscheidung zu Design und Palette | ⚡ Mittel, braucht barrierefreie Paletten und Prüfwerkzeuge | 📊 Senkt Lesbarkeit; schließt farbfehlsichtige Nutzende aus; erhöht Fehler | 💡 Farbfehlsichtigkeitsfreundliche Paletten, Kontrastprüfungen oder Muster nutzen | ⭐ Verbessert nach Korrektur Barrierefreiheit und Deutungstempo |
Fehlende oder irreführende Beschriftungen und Legenden | 🔄 Gering, Platzierung von Beschriftungen und Metadaten | ⚡ Gering, Beschriftungen und Einheiten ergänzen, Layout anpassen | 📊 Erzeugt Mehrdeutigkeit; erzwingt Blicke in die Legende; erhöht die kognitive Last | 💡 Segmente ab 5 % direkt beschriften; Summen, Einheiten und klare Legenden ergänzen | ⭐ Verbessert eigenständige Lesbarkeit und Vertrauenswürdigkeit deutlich |
Mehrere Tortendiagramme nebeneinander vergleichen | 🔄 Mittel, mehrere Grafiken und Ausrichtungsprobleme | ⚡ Mittel, besser durch Zeitreihen oder gruppierte Diagramme bedient | 📊 Schlechter Vergleich über Diagramme hinweg; hohe Fehlerquote beim Deuten von Verläufen | 💡 Für Vergleiche durch Linien-, gestapelte oder gruppierte Balkendiagramme ersetzen | ⭐ Nur für einzelne Momentaufnahmen nützlich; schwach für Verlaufsanalyse |
Tortendiagramme für Zusammensetzung, wenn Teil-Ganzes unklar ist | 🔄 Gering, Fehlanwendung statt technischer Komplexität | ⚡ Gering, erfordert die Wahl passender Darstellungstypen | 📊 Stellt Beziehungen falsch dar; suggeriert falschen Wettbewerb zwischen Kennzahlen | 💡 Torte nur, wenn Teile ein sinnvolles Ganzes ergeben; sonst getrennte Diagramme | ⭐ Als Zusammensetzungswerkzeug keiner; andere Diagrammtypen treffen die Bedeutung besser |
Herausgezogene Segmente ohne logische Hierarchie | 🔄 Gering, einfacher visueller Eingriff, braucht aber Begründung | ⚡ Gering, keine zusätzliche Datenverarbeitung, nur Gestaltung | 📊 Suggeriert unbegründete Wichtigkeit; stört den Anteilsvergleich | 💡 Nur mit Begründung herausziehen (z. B. Spitzenposten) und Grund dokumentieren | ⭐ Kann datenbasiert Aufmerksamkeit lenken; sonst irreführend und vermeidbar |
Machen Sie aus jedem Diagramm eine klare Entscheidung
Die Lösung für schlechte Tortendiagramme lautet nicht „Kreise für immer verbieten“. Sie lautet, die Darstellung an die Entscheidung anzupassen. Aggregieren Sie, wenn Kategorien wuchern. Halten Sie die Gestaltung flach und zugänglich. Beschriften Sie Nenner und Zeitraum. Wechseln Sie zu Balken, wenn die Aufgabe Rangfolge oder Kategorienvergleich ist. Wechseln Sie zu Linien, wenn die Aufgabe Veränderung über die Zeit ist. Lehnen Sie die Torte ganz ab, wenn die Daten kein sinnvolles Ganzes beschreiben.
Diese Ersatzlogik zählt am meisten in der Arbeit an Observability und Datenqualität, weil die Nutzerin das Dashboard nicht bewundert. Sie entscheidet, was sie untersucht, wen sie benachrichtigt und was sie zuerst behebt. Ein Diagramm, das diese Schritte verlangsamt, ist ein operativer Fehlschlag, selbst wenn die Zahlen dahinter stimmen.
Ein nützlicher Vorabcheck ist kurz:
Datenstruktur: Bilden die Kategorien ein echtes Ganzes?
Lesbarkeit: Kann jemand jedes wichtige Segment erkennen, ohne die Legende zu durchsuchen?
Barrierefreiheit: Funktioniert das Diagramm auch bei schwachem Kontrast oder farbfehlsichtiger Betrachtung?
Vergleichsaufgabe: Sollen Betrachtende ordnen, über Zeiträume oder über Umgebungen vergleichen? Wenn ja, nutzen Sie stattdessen Balken oder Linien.
Beabsichtigte Handlung: Können Betrachtende allein aus dem Diagramm erkennen, was als Nächstes zu tun ist?
Neuere Arbeiten zu Tortendiagrammen sind weniger absolut als das alte Internet-Klischee. Eine Fallstudie mit über 300 Teilnehmenden fand, dass Tortendiagramme gegenüber Balkendiagrammen die Entscheidungsergebnisse auf hoher Ebene bei Urteilen zu Fakultätsprofilen nicht bedeutsam veränderten, wohl aber die Eindrücke mit kleiner Effektstärke (Fallstudie zu Tortendiagrammen, Eindrücken und Entscheidungsergebnissen). Das ist eine nützliche Erinnerung. Das Risiko schlechter Tortendiagramme ist oft keine dramatische Katastrophe. Es ist stete Reibung, weicheres Urteil und schwächere Priorisierung.
Für Datenteams ist das Grund genug, streng zu sein. Halten Sie Anomalie-, Timeliness-, Validierungs- und Schemafragen getrennt, solange sie nicht ein Ganzes bilden. Nutzen Sie eine Plattform wie digna, passt diese modulare Trennung bereits zur Arbeitsweise. Das Diagramm sollte diese Struktur stützen, nicht verwischen. Für breiteres Denken zum Dashboard-Entwurf ist der Dashboard-Leitfaden von The Social Search eine gute Begleitlektüre.
digna stellt eine Unternehmensplattform für Datenqualität und Data Observability bereit, die in Ihrer eigenen Umgebung läuft, mit Modulen für Anomalien, Timeliness, Validierung, Schema-Tracking sowie Geschäfts- und Plattformüberwachung. Diese modulare Struktur erleichtert es, Diagramme zu wählen, die die Behebung stützen, statt unverbundene Signale in eine irreführende Sicht zu zwingen. Wenn Sie Monitoring-Dashboards um klarere Entscheidungen herum überarbeiten, besuchen Sie digna.
Dieselbe Disziplin gilt eine Ebene höher: Ein Diagramm kann nur so klar sein wie die Zahlen dahinter, und genau die sollen Datenqualitäts-Dashboards sichtbar machen.
Häufig gestellte Fragen
Wann ist ein Tortendiagramm tatsächlich vertretbar?
Wenn es sinnvolle Teile eines klaren Ganzen zeigt, sehr wenige Segmente hat und die Lesenden nur einen einfachen Teil-Ganzes-Eindruck brauchen. Außerhalb dieser Bedingungen lässt es ein Dashboard fertig aussehen und erschwert zugleich die darunterliegende Entscheidung.
Warum sind zu viele Segmente ein Problem?
Weil das Auge ähnliche Winkel nicht verlässlich ordnen kann, sodass ein Diagramm mit einem Dutzend Segmenten vermittelt „es gibt viele Dinge“ statt, welche zählen. Den Schwanz zu einer gruppierten Kategorie zusammenzufassen oder auf ein sortiertes Balkendiagramm zu wechseln, stellt den Vergleich wieder her, den die Lesenden tatsächlich brauchen.
Was ist falsch an 3D-Tortendiagrammen?
Perspektivische Verzerrung ändert die scheinbare Größe von Segmenten unabhängig von ihren Werten — Segmente vorn wirken größer als gleich große hinten. Die Verzierung fehlinformiert aktiv, was etwas anderes ist als bloß unnötig zu sein.
Warum sollte man Tortendiagramme nicht nebeneinander vergleichen?
Weil aus dem visuellen Problem ein Priorisierungsproblem wird. Winkel über getrennte Kreise hinweg zu vergleichen ist weit schwerer als Längen auf einer gemeinsamen Achse, sodass Lesende nicht erkennen, welche Kategorie sich am stärksten bewegt hat. Diagrammtypen, die die Entscheidungsaufgabe erhalten, etwa gruppierte oder gestapelte Balken, funktionieren besser.
Wann helfen herausgezogene Segmente?
Nur wenn die Hierarchie ausdrücklich ist — wenn ein Segment tatsächlich das Thema ist und der Rest Kontext. Segmente willkürlich herauszuziehen signalisiert eine Betonung, die die Daten nicht stützen, und auf operativen Dashboards ersetzt ein schlichtes sortiertes Balkendiagramm meist das Ganze.
