Insights

Es gibt eine bestimmte Art von Dashboards, die auf den ersten Blick beeindruckend wirkt. Viele Daten. Schöne Farben. Irgendwo eine Karte. Und dann schaut man es einen Moment lang an und merkt — man weiß nicht genau, was es eigentlich sagen will.
Das ist kein Datenproblem. Es ist ein Designproblem. Konkret passiert es dann, wenn ein Dashboard um die Frage „Welche Daten habe ich?“ herum gebaut wird, statt um die Frage „Was sollen die Menschen verstehen?“
Ein kartenbasiertes Dashboard zu gestalten ist gar nicht so anders als eine Karte zu machen. Man braucht ein Thema, eine Botschaft, ein Publikum und einen Pfad. Der Unterschied ist, dass ein Dashboard von Natur aus interaktiv ist — es lädt Menschen ein und muss sie dann irgendwohin führen. Damit das gelingt, lohnt es sich, vier Dinge zu klären, bevor man das Interface auch nur anfasst.

Dies ist der zweite Beitrag in einer Reihe über kartenbasiertes Dashboard-Design. Den ersten — Was ist ein kartenbasiertes Dashboard? — empfehlen wir als Einstieg.
Die erste Frage lautet nicht „Welche Daten habe ich?“, sondern „Was sollen die Menschen verstehen?“ Diese Verschiebung — klein in Worten, groß in der Wirkung — verändert jede Entscheidung, die folgt.
Meistens gibt es nicht nur eine Sache zu sagen. Es gibt eine Kernbotschaft und eine Reihe ergänzender Erkenntnisse, die zusammen das vollständige Bild ergeben. Die Arbeit besteht darin, sie zu ordnen: Welche öffnet das Dashboard? Welche geben ihm Tiefe? Welche sind Hintergrundinformation?
Je spezifischer jede Botschaft ist, desto besser. „Grünflächen sind nicht gleichermaßen zugänglich“ ist ein Ausgangspunkt. „Grünflächen sind im Münchner Norden schlechter zugänglich als im Süden — und die Lücke ist am größten für Bewohner ohne Auto“ ist ein Dashboard. Die erste Aussage zeigt, dass es ein Thema gibt. Die zweite zeigt, dass es mindestens drei Dinge zu zeigen gibt: die Gesamtverteilung, das Nord-Süd-Muster und die Mobilitätsdimension.
Die Botschaften vor dem Designstart zu formulieren lohnt sich. Nicht als Aufzählungspunkte zum Anzeigen, sondern als interne Anker — das, was jemand mitnehmen soll. Sind diese klar, fallen Layer, Grafiken und die Reihenfolge der Nutzererfahrung fast von selbst an ihren Platz.
Dasselbe Dataset kann sehr unterschiedliche Geschichten erzählen, je nachdem, wer es liest. Ein Dashboard für Politiker sieht anders aus als eines für Planer — und wieder anders als eines für Bürgerinnen und Bürger. Nicht weil sich die Daten ändern, sondern weil sich die Fragen ändern.
Nehmen wir die Grünflächenzugänglichkeit in München. Die Daten sind dieselben. Aber was jedes Publikum davon braucht, ist unterschiedlich.
Ein Politiker möchte ein klares, vollständiges Bild: Wie schneidet München im Vergleich zu anderen Städten ab? Wie viel Prozent der Bewohner sind unterversorgt? Etwas, dass das Ausmaß des Problems kommuniziert und eine Entscheidung stützt. Eine Planerin möchte das Muster verstehen — welche Stadtteile zurückliegen, welche Bevölkerungsgruppen am stärksten betroffen sind, wo eine Maßnahme den größten Effekt hätte. Bürgerinnen und Bürger wollen wissen, was das für ihre Straße, ihre Kinder, ihren Alltag bedeutet. Eine Forscherin interessiert sich vielleicht am meisten für die Methodik: Wie wurde Zugänglichkeit gemessen? Was gilt als Grünfläche? Was sind die Grenzen des Modells?

Das sind Beispiele, keine festen Kategorien. Forscherinnen und Forscher arbeiten oft eng mit Planern zusammen und brauchen Antworten genauso wie Methoden. Eine Bautabteilung und ein Gleichstellungsteam sitzen vielleicht im selben Raum mit sehr unterschiedlichen Prioritäten. Der Punkt ist nicht, Zielgruppen in Schubladen zu stecken — sondern anzuerkennen, dass dieselbe Karte für verschiedene Menschen verschiedene Dinge bedeutet. Und für alle gleichzeitig zu gestalten, bedeutet meistens, niemandem wirklich zu dienen.
Die meisten Dashboards haben am Ende mehr als eine Zielgruppe. Das ist in Ordnung. Aber es bedeutet, dass Prioritäten gesetzt werden müssen. Wer die primäre Leserschaft ist, löst die meisten Designkonflikte im Voraus — was zuerst gezeigt wird, wie viel Detail sichtbar sein soll und wie stark die Nutzerin geführt oder zur freien Erkundung eingeladen werden soll.
Dashboards haben unterschiedliche Zwecke, und es lohnt sich, diesen zu benennen, bevor man anfängt.
Manche existieren, um eine Situation zu überwachen — damit Entscheidungsträger wissen, was passiert, ohne fragen zu müssen. Andere sind gebaut, um zu informieren und Erkenntnisse einem breiteren Publikum zugänglich zu machen. Wieder andere sollen eine konkrete Entscheidung stützen: Wo bauen? Was priorisieren? Wo sind die Lücken?
Zurück zu Münchens Grünflächen: Wenn die primäre Zielgruppe Planerinnen sind, ist der Zweck wahrscheinlich nicht Monitoring — sondern Entscheidungsunterstützung. Welche Stadtteile sollten bei neuen Grünflächeninvestitionen priorisiert werden? Diese Frage prägt alles: was das geospatiale Dashboard zeigen muss, wie detailliert es sein soll — und vor allem, was es nicht zu zeigen braucht.
Dieser letzte Punkt ist entscheidend. Ein Dashboard kann — und sollte nicht versuchen — ein Raumanalyse-Tool zu ersetzen. Es beantwortet bekannte Fragen, die regelmäßig gestellt werden, nicht jede mögliche Frage. Stell es dir wie ein Armaturenbrett vor: Geschwindigkeit, Kraftstoff, Temperatur. Es erklärt nicht den Motor. Wenn etwas Ungewöhnliches auftaucht, geht die Analyse tiefer — anderswo.
Der Versuch, ein Dashboard zu bauen, das alles kann, erzeugt etwas, das zu komplex ist, um es zu nutzen. Die Nützlichsten sind fokussiert. Sie beantworten: Sind wir auf Kurs? Was hat sich verändert? Wo sollten wir genauer hinschauen? Wenn eine Planerin die Daten jede Sitzung neu schneiden muss, um eine andere Frage zu beantworten, ist das Analysearbeit — und dafür gibt es bessere Tools.

Wenn Botschaft, Zielgruppe und Zweck klar sind, bleibt eine letzte Frage: Wie soll sich der Nutzer durch das Dashboard bewegen?
Zunächst lohnt es sich klarzustellen, was diese Frage für ein kartenbasiertes Dashboard besonders macht. Bei einem herkömmlichen Dashboard erzählen die Grafiken die Geschichte — man liest Diagramme, Tabellen und Zahlen, und die Karte (wenn überhaupt vorhanden) illustriert die Daten. Bei einem kartenbasierten Dashboard ist die Beziehung umgekehrt. Die Karte nimmt den meisten Platz ein. Sie ist nicht nur eine Visualisierungsebene — sie ist die organisatorische Struktur des gesamten Interfaces. Die Grafiken führen nicht, sie reagieren auf das, was die Karte zeigt. Statt zwischen Tabs oder Filtern zu navigieren, bewegt sich die Nutzerin durch den Raum — und Zoomstufen übernehmen einen Großteil der Arbeit, die sonst Buttons und Menüs leisten.
Das verändert das Denken über die Nutzererfahrung grundlegend. Beim Schreiben dieses Artikels bin ich auf ein Bild gestoßen, das es gut einfängt.

Es hilft, drei Modi zu unterscheiden. Eine traditionelle Geschichte — wie eine Story Map — führt die Leserin durch eine festgelegte Abfolge. Das ist eigentlich kein Dashboard, es ist eine Erzählung. Am anderen Ende lässt die freie Erkundung der Nutzerin völlig freie Hand: Layer ein- und ausschalten, Daten mit Grafiken nach eigenem Ermessen verbinden, zu eigenen Schlussfolgerungen kommen. Zwei Menschen können dasselbe Dashboard benutzen und mit unterschiedlichen Erkenntnissen herausgehen. Dann gibt es noch die geführte Safari — die Nutzerin kann noch erkunden, aber Layer sind mit bestimmten Grafiken und Tabs verknüpft, sodass das Einschalten eines Layers irgendwohin gezielt weiterleitet. Es gibt Freiheit, aber das Ziel ist ungefähr dasselbe.
Für das Münchner Grünflächen-Dashboard, das auf Planerinnen ausgerichtet ist, passt eine geführte Safari am besten. Die Einstiegsansicht zeigt die stadtweite Verteilung — welche Stadtteile gut versorgt sind, welche nicht. Hineinzoomen in einen Bezirk lässt das Detail entstehen: einzelne Parks, Bevölkerungsdichte, Gehwege. Noch weiter gezoomt erreicht man die Straßenebene, wo die Frage konkret genug wird, um eine echte Entscheidung zu stützen. Die Grafiken aktualisieren sich je nachdem, wo man sich auf der Karte befindet. Das Gebiet ist kein Hintergrund — es ist das Argument.
Ein Dashboard, das seine Botschaft, sein Publikum, seinen Zweck und seinen Pfad kennt, ist nicht nur einfacher zu bauen. Es ist einfacher zu benutzen. Und es ist viel wahrscheinlicher, dass es das tut, wofür Daten gedacht sind: Zahlen in etwas verwandeln, auf das eine Person tatsächlich reagieren kann.
Dies hat maßgeblich dazu beigetragen, wie wir Dashboards in GOAT gestalten. Die Karte ist immer das primäre Interface. Die Grafiken reagieren darauf. Die Zoomstufe ist die Navigation. Im nächsten Beitrag betrachten wir, was ein Dashboard zum Leben erweckt – die visuellen und interaktiven Elemente, die Nutzern helfen, sich zurechtzufinden, die Botschaft zu verstehen und die gewünschten Fragen zu stellen.
Wer an einer raumplanerischen Aufgabe arbeitet und sehen möchte, wie ein kartenbasiertes Dashboard in der Praxis aussieht, kann GOAT erkunden →
.webp)
Insights


.jpg)
.jpg)
.jpg)
.jpg)
Schließen Sie sich Planerinnen, Planern und Städten an, die GOAT bereits nutzen, um bessere Entscheidungen zu treffen – schneller.