Die weltweite Lieferkette verfolgen, eine Fahrt nach der anderen.

Die Herausforderung

Ein Marker auf dieser Karte ist nie nur eine Stecknadel. Es ist eine Palette Impfstoffe, ein Container mit frischer Ware, gegen die die Uhr läuft, oder ein Bauteil, das eine Produktionslinie stoppt, wenn es nicht rechtzeitig ankommt.

Brambles bewegt physische Assets durch mehr Lieferketten als fast jedes andere Unternehmen der Welt. Supply Chain Illumination (SCI), die Plattform, für die ich designe, existiert, um eine wirklich schwierige Frage in diesem Maßstab zu beantworten: Wo befindet sich ein bestimmtes Asset gerade, liegt es im Zeitplan, und ist es noch in einem akzeptablen Zustand – über mehr als 300.000 Lieferketten und 352 Millionen physische Einheiten in mehr als 60 Ländern hinweg.

Es war immer richtig, das gesamte Netzwerk auf einen Blick zu zeigen. Diese Größenordnung zu verbergen, wäre unehrlich gegenüber dem gewesen, was das Produkt tatsächlich leistet. Das schwierigere Problem, das eigentliche Designproblem, war Geschwindigkeit: Wie schnell jemand von „hier ist das gesamte Netzwerk“ zu „hier ist die Handvoll Assets, Standorte und Fahrten, die mich gerade jetzt brauchen“ gelangen konnte. Das ist dieselbe Spannung, für die ich in der Fallstudie Discovery designt habe: Was ein Bildschirm zeigt und was ein Nutzer tatsächlich wissen muss, ist selten dasselbe – und in dieser Lücke findet die eigentliche Designarbeit statt.

Das gesamte Netzwerk zu zeigen war der einfache Teil. Es schnell auf das Wesentliche filterbar zu machen war das eigentliche Designproblem.

Meine Rolle

Ich verantworte die UX für die Oberflächen Netzwerkkarte, Fahrten, Asset-Sichtbarkeit und Standorte auf SCI, als Principal Product Designer bei Brambles.

Das umfasst das Interaktionsdesign für einzelne Bildschirme, Fahrtzusammenfassungen, Zustandsdiagramme, Zeitleisten, Detail-Seitenleisten für Assets und Standorte, sowie die zugrunde liegenden Regeln, die das System im großen Maßstab zusammenhalten: was ein Cluster ist, wann er sich beim Heranzoomen auflöst, was Farbe über den Asset-Zustand aussagt, und wie diese Regeln konsistent bleiben, egal ob jemand eine einzelne Fahrt oder das gesamte Netzwerk betrachtet.

Das Kartensystem selbst ist über SCI hinausgewachsen. Es ist heute die gemeinsame Kartensprache hinter fünf Brambles-Produkten, gepflegt von 21 Mitgliedern des UX-Teams statt von der Designdatei einer einzelnen Person – der klarste Beleg, den ich habe, dass ein Pattern tatsächlich ein echtes Problem gelöst hat, statt nur die Spezifikation eines einzelnen Teams zu erfüllen.

Die Karten von SCI basieren auf Mapbox als zentraler Karten-Engine, gewählt wegen einer stabilen Basiskarte, starker Performance im großen Maßstab und flexibler Stilgebung, die helle und dunkle Themes unterstützt. Mapbox übernimmt Verschieben, Zoomen und das Standard-Ansichtsfenster. Alles, was ein Nutzer tatsächlich als „die SCI-Karte“ erkennt – die Marker, die Cluster, die Fahrtlinien, die Seitenpanels – ist eine Komponente, die ich auf diesem Fundament designe und spezifiziere, gebaut, um konsistent mit dem Brambles Design System zu bleiben, statt die visuellen Standardeinstellungen von Mapbox zu übernehmen.

Ich habe diese Komponenten außerdem im Code gebaut, mit KI-gestützten Tools, nicht nur in Figma, damit ein Team, das bei der Erkundung eines neuen Bildschirms oder einer neuen Funktion – bei SCI oder einem völlig anderen Produkt – auf das System zurückgreift, mit etwas arbeitet, das es tatsächlich einbauen und testen kann, nicht mit einer statischen Referenz. Die maßgebliche Figma-Datei und die Codebasis werden bewusst synchron gehalten – die eine ohne die andere zu aktualisieren, hebt den Sinn eines Designsystems überhaupt auf.

Die drei Regeln unten – was ein Cluster ist, was ein Marker ist, und was Farbe bedeutet – sind das Fundament, auf dem alles andere auf der Karte aufbaut, deshalb lohnt es sich, genau diese hier durchzugehen. Das größere System geht deutlich weiter: Verhalten des Ansichtsfensters, Suche, die Mini-Filter und das vollständige Filter-Panel, eine dynamische Legende, die immer nur zeigt, was tatsächlich auf dem Bildschirm sichtbar ist, sowie die Komponenten für Asset-Detail, Standort-Detail und Zeitleiste, in die diese Marker und Cluster führen, sind alle auf dieselbe Weise dokumentiert und komponentisiert.

Was ist ein Cluster?

Auf der Netzwerkkarte fasst ein Cluster mehrere Assets oder Standorte zusammen, die nah beieinander liegen, damit die Karte auf einen Blick lesbar bleibt, statt in einzelnen Stecknadeln zu ertrinken. Cluster verwenden Icons für das, was tatsächlich in ihnen steckt – ein Geschäft, ein Produktionsstandort, eine Mischung von Asset-Typen – statt eines einzelnen generischen Punkts, und diese Icons werden beim Heranzoomen spezifischer. Beim weiteren Zoomen lösen sich Cluster in einzelne Asset- und Standort-Marker auf, oder in kleinere, spezifischere Cluster innerhalb des ursprünglichen Clusters.

Was bedeutet Farbe auf der Netzwerkkarte?

Farbe zeigt einem Nutzer, in welchem Zustand sich ein Cluster oder Marker befindet, bevor er irgendetwas anklickt. Blau bedeutet bewegte Assets. Violett bedeutet Assets, die an einem bekannten, erwarteten Standort ruhen. Rot bedeutet einen nicht identifizierten Stillstand – ein Asset, das sich irgendwo befindet, wo es keinen Grund dafür gibt, was oft das erste Signal für einen Verlust oder Diebstahl ist. Das ist bewusst eine andere Farbsprache als die auf Fahrten verwendete, weil die Netzwerkkarte die Frage „wo ist alles und in welchem Zustand“ beantwortet, nicht „ist diese bestimmte Sendung im Zeitplan“.

Was ist ein Marker?

Ein einzelnes bewegtes Asset erhält seinen eigenen Halo- oder Puls-Marker, ein visuelles Signal dafür, dass etwas live und unterwegs ist. Sobald ein Asset aufhört, sich zu bewegen – ob an einem bekannten oder einem nicht identifizierten Standort –, gruppiert es sich in einen Cluster mit dem relevanten Standort-Marker, statt als einsamer Punkt auf der Karte zu verharren. Wir untersuchen außerdem, ruhende Marker nach der Dauer des Stillstands eines Assets zu skalieren, damit die Karte selbst irgendwann die Frage beantworten könnte, „welches davon schon zu lange hier ist“ – das ist aber noch nicht ausgeliefert, sondern eine Richtung, die wir aktiv testen, keine geltende Regel.

Was ändert sich, wenn eine Fahrt einzeln angezeigt wird?

Eine einzelne Fahrt für sich anzuzeigen, bringt eine Detailebene zum Vorschein, die die Cluster-und-Marker-Sprache oben bewusst ausspart: die Polylinie selbst, Richtungspfeile entlang ihr, ein Abfahrtsstandort, Stecknadeln für Halte-Standorte, eine Stecknadel für den zuletzt gesehenen Standort oder ein beweglicher Kreis, Infoblasen und Wegpunkt-Marker. Nichts davon ersetzt die Regeln oben, es ist dieselbe visuelle Sprache mit aufgedrehter Lautstärke, denn eine Sendung zu lesen ist eine andere Aufgabe als dreihunderttausend zu lesen, und das erfordert das zusätzliche Detail.

Das sind keine beiläufigen UI-Entscheidungen. Es sind die Regeln, die es derselben Kartenkomponente erlauben, egal ob sie 12 Assets oder 12.000 zeigt, zu funktionieren, und sie sind einmal dokumentiert, als Designsystem-Referenz, genau damit ein Designer, der zu einer anderen SCI-Oberfläche oder einem völlig anderen Brambles-Produkt hinzustößt, dieselbe Logik erbt, statt sie neu zu erfinden.

Ebenen – und für die nächste Funktion bauen, bevor sie existiert

Das Ebenen-Panel steuert, was die Karte anzeigt. Standardmäßig sind sowohl die Asset- als auch die Standort-Ebene aktiviert. Eine Ebene auszuschalten entfernt alles, was mit ihr verknüpft ist, in einer einzigen Aktion: Marker, Cluster, Filter, Suchergebnisse und Legendeneinträge – so zeigt oder filtert die Karte nie Daten, die ein Nutzer bewusst ausgeblendet hat. Ich habe inzwischen eine eigene Ebene für nicht identifizierte Stillstände im Code prototypisiert, damit ein Nutzer genau die Assets isolieren kann, die am dringendsten untersucht werden müssen, ohne vorher alles andere herauszufiltern – Fahrten ist der logisch nächste Ebenentyp, der zu designen ist, sobald das ausgeliefert wird.

Die jüngste Version von Ebenen hat einen Umschalter zwischen Globus- und Flachprojektion ausgeliefert: ein echtes Barrierefreiheits-Feature, keine visuelle Spielerei. Manche Nutzer reagieren empfindlich auf Bewegung durch eine rotierende Globusansicht, und manche logistischen Aufgaben – eine Route planen, Distanzen abschätzen – sind auf einer flachen Projektion einfach leichter, während andere – die Abdeckung eines Fernstrecken-Netzwerks verstehen – sich auf einem Globus besser lesen lassen. Beide Zustände sind klar beschriftet, per Tastatur erreichbar und screenreader-freundlich, und die Wahl der Projektion bleibt über jede Karte im Produkt hinweg bestehen, bis ein Nutzer sie erneut ändert. Dasselbe gilt für den Kartenstil: Welchen Basisstil ein Nutzer auch wählt, Hell, Dunkel, Outdoor oder Satellit mit Straßen, er wird als Präferenz gespeichert und auf jede andere Kartenoberfläche in SCI übertragen, sodass niemand ihn Bildschirm für Bildschirm neu einstellen muss.

Diesen Umschalter zu designen bedeutete, die Abnahmekriterien zu schreiben, bevor die Funktion überhaupt existierte: was „Globusansicht“ und „Flachansicht“ für einen Screenreader bedeuten mussten, wie sich der Fokus bewegen sollte, was beim Wechsel zurückgesetzt werden sollte und was nicht. Das ist dieselbe Disziplin, die hinter den Cluster- und Marker-Regeln oben steht: das Verhalten des Systems einmal schriftlich festlegen, damit jedes Team, das darauf aufbaut, denselben Standard erbt.

Eine Fahrt verfolgt die jüngste Reise eines einzelnen Assets: seinen Startstandort, jeden Stillstand dazwischen und seinen End- oder aktuellen Standort. Das ist eine andere Aufgabe als die der Netzwerkkarte, deshalb nutzt sie eine andere visuelle Sprache. Fahrtlinien zwischen Stillständen sind standardmäßig blau und wechseln zur Anzeige von Segmenten mit Schwellenwertüberschreitung gegenüber optimalen Dauer-Segmenten, sobald ein Nutzer den Zustand einschaltet, sodass ein Kunde genau sehen kann, wo entlang der Route ein Problem aufgetreten ist, nicht nur, dass eines aufgetreten ist. Standort-Marker auf einer Fahrt folgen derselben Logik: standardmäßig schwarz, und rot, sobald an genau diesem Stillstand eine Überschreitung erfasst wird – egal ob das Asset stillstand oder sich zwischen zwei Punkten bewegte.

Die Fahrtzusammenfassung wurde so gestaltet, dass die zwei wichtigsten Fragen – wo befindet sich diese Sendung, und ist sie noch in einem akzeptablen Zustand – beide ohne einen einzigen Klick beantwortbar sind. Route, Versandpunkt, zuletzt gesehener Standort, Dauer sowie Live-Temperatur- und Erschütterungszustand befinden sich auf demselben Bildschirm. Dieselbe Komponente skaliert dann herunter zu einer kompakten Zusammenfassung für eine Tabellenzeile und herauf zur vollständigen Detailansicht der Fahrt – ein Pattern, mehrere Dichten, statt eines zweiten, für jeden Kontext von Grund auf neu gebauten Designs.

Wenn tatsächlich etwas schiefgegangen ist, speisen dieselben Temperatur- und Erschütterungsdaten das Zustandsdiagramm darunter: die vollständige Fahrt, aufgetragen gegen optimale, risikoarme und risikoreiche Schwellenwertbänder, mit einem Zeitraum-Schieberegler und Zoom-Steuerung, um direkt zu dem Moment zu springen, in dem die Grenze überschritten wurde, statt eine ganze Reise mit dem Auge abzusuchen. Ein Erschütterungsausschlag kann eine harte Bremsung oder eine Kollision bedeuten, ein langsamer Temperaturanstieg kann eine ausgefallene Kühleinheit oder eine über eine lange Route offen gelassene Tür bedeuten, und dieselben Smart-Geräte können eine unerwartete Änderung von Licht oder Gewicht auf einer stehenden Palette melden – ein Signal, dass etwas geöffnet oder entfernt wurde, während sie geparkt war. Insights on Arrival, ein eigenständiges SCI-Modul, beantwortet die verwandte, aber eigenständige Frage, in welchem Zustand sich eine Sendung bei ihrer Ankunft am Zielort befand, unter Verwendung derselben zugrunde liegenden Daten.

Fahrt-Zeitleiste

Die Zeitleisten-Ansicht beantwortet „was auf dieser Fahrt tatsächlich passiert ist“ mit einer Routenkarte, nummerierten Halten, Verweildauer an jedem einzelnen und Vorfall-Markern, die direkt auf die Karte gesetzt statt in einem Protokoll vergraben werden. Eine separate Protokoll-Ansicht existiert für den Fall, dass jemand wirklich die rohe Abfolge der Ereignisse braucht, aber die Karte bleibt der primäre Weg, eine Reise zu verstehen, denn eine Route mit einem roten Marker erzählt eine schnellere Geschichte, als es eine Tabelle je könnte.

Die vertikale Zeitleiste auf der Karte hat auch ein horizontales Gegenstück, einen kompakten Straßenstreifen, der direkt unter dem Zustandsdiagramm auf der Fahrtzusammenfassung sitzt. Dieselbe Stillstand- und Standort-Logik, von links nach rechts statt von oben nach unten angeordnet: Ein violetter Balken markiert die Verweildauer an jedem Halt, und ein LKW-Symbol markiert die aktuelle Position des Assets – blau während der Bewegung, violett während des Stillstands, grün nach Zustellung, Scheinwerfer nur an, wenn es wirklich unterwegs ist. Es ist eine kleine Komponente, aber sie erlaubt es jemandem, der einen Temperaturausschlag auf dem Diagramm oben liest, mit demselben Blick zu erkennen, ob das Asset an einem Halt geparkt war oder tatsächlich in Bewegung, als es passierte.

Eine Fahrt besteht außerdem aus Etappen, dem Weg zwischen zwei beliebigen Standorten auf ihr, und das Erkunden der Etappen zerlegt die Route in diese einzelnen Segmente – Etappe 1, Etappe 2, Etappe 3 und so weiter –, jede mit eigenem Status: überschritten oder konform, statt eines einzigen Urteils für die gesamte Fahrt. Eine Fahrt mit nur einer schlechten Etappe von sechs sollte sich nicht genauso lesen wie eine Fahrt, die von Anfang bis Ende gescheitert ist. Auf der Karte wird eine Etappe durch ihre eigene quadratische Stecknadel markiert, zentral über der Polylinie dieser Etappe statt an einem Standort, sodass ein Nutzer auf einen Blick erkennen kann, welches Segment er gerade betrachtet. Das Auswählen einer Etappe hält Karte und Zeitleisten-Liste synchron, sodass ein Nutzer zwischen einer Etappe auf der Route und ihrem Detail in der Liste wechseln kann, ohne die Orientierung zu verlieren.

Ein Fluss ist eine regelmäßige Reise, die das Produkt eines Kunden auf unseren Paletten zurücklegt, eine Fabrik zu einem Geschäft, ein Lager zu einem Verteilzentrum. Eine Route ist eine Art, diesen Fluss tatsächlich zu betreiben: Fabrik direkt zum Geschäft ist eine Route, Fabrik über ein Lager und ein Verteilzentrum ist eine andere Route für denselben Fluss, und die meisten Flüsse haben mehrere. Eine Fahrt ist eine einzelne, abgeschlossene Instanz einer dieser Routen, an einem bestimmten Datum, mit einem bestimmten Asset. Derselbe Versandkorridor, drei unterschiedliche Linsen: Ein Fluss sagt Ihnen, ob der Korridor als Ganzes gesund ist, eine Route sagt Ihnen, welcher Weg hindurch der schnellste oder langsamste ist, und eine Fahrt sagt Ihnen, was auf einer Reise tatsächlich passiert ist.

Das Öffnen eines Flusses zerlegt ihn in seine Routen, jede derselbe Korridor auf unterschiedliche Weise befahren, mit eigenen relevanten Standorten und eigenen schnellsten, langsamsten und durchschnittlichen Zyklus- und Verweilzeiten. Hier liegt der nützliche Vergleich: zwei Routen, die denselben Fluss bedienen, eine davon durchgehend schneller, und jetzt ist dieser Unterschied sichtbar und zuordenbar, statt in einem einzigen vermischten Durchschnitt vergraben zu sein.

Keiner der beiden Bildschirme hat bislang eine Karte, und das ist bewusst so, kein Versehen – alles oben ist noch Liste-und-Tabelle-Arbeit, keine räumliche Arbeit. Es ist die nächste Kartendesign-Herausforderung auf diesem Produkt: dieselbe Cluster-, Marker- und Fahrtlinien-Sprache aus früher in dieser Fallstudie, eine Ebene höher angewendet, sodass die Stillstände einer Route und eine unterdurchschnittlich performende Etappe auf einer Karte genauso visuell offensichtlich sind wie die Überschreitung einer einzelnen Fahrt es bereits ist.

Assets und Standorte existieren auch als eigenständige Module, durchsuchbare Listen von genau dem, was bereits auf der Netzwerkkarte eingezeichnet ist, für Operations-Nutzer, die zuerst in Listen und erst dann in Karten denken. Keines der beiden Module erfindet dafür ein neues Pattern: dieselbe Sprache für Suche, Sortierung und Filter überträgt sich aus Fahrten und Flüsse, sodass ein Nutzer, der bereits gelernt hat, mit einer Liste zu arbeiten, auch schon weiß, wie er mit diesen umgeht.

Eine Zeile in einer der beiden Listen ist keine Sackgasse. Ein Klick auf einen Standort öffnet denselben Standort-Bildschirm, den ein Marker auf der Netzwerkkarte öffnet: Grenze, Adresse und Bewegungsmetriken über einer Live-Karte. Ein Klick auf ein Asset öffnet direkt die Reise-Zeitleiste dieses Assets, dieselbe Reise, die ein Nutzer durch einen Klick auf seinen Marker auf der Karte erreichen würde. Liste und Karte sind zwei Türen zu denselben Räumen, nicht zwei getrennte Funktionen, die gebaut und gepflegt werden müssen.

Illuminate schaltet die Netzwerkkarte in einen dunklen, kontrastreichen Modus, gebaut, um viele Fahrten gleichzeitig statt nur eine zu betrachten. Jede Fahrt auf dem Bildschirm wird nach Zustand dargestellt, überschritten in Rot, optimal in Grün, sodass eine Lieferketten-Verantwortliche, die das gesamte Netzwerk überblickt, sehen kann, wo sich Probleme konzentrieren, ohne eine einzige Fahrt zur Prüfung zu öffnen. Es ist dieselbe Rot-gegen-Grün-Sprache, die diese Fallstudie von einer einzelnen Fahrtlinie an verwendet hat, nur gleichzeitig auf ein paar Hundert Sendungen statt auf eine gerichtet.

Das Heranzoomen in einen bestimmten Bereich behält dieselbe Farbsprache bei, fügt aber eine Möglichkeit zur Eingrenzung hinzu: Ein Zustandsfilter schaltet die Karte zwischen optimalen, überschrittenen oder allen Fahrten um, und eine Fahrtliste rechts gruppiert alles gerade Sichtbare nach Status – nicht versandt, ruhend, in Bewegung, zugestellt –, sodass eine Lieferketten-Verantwortliche von „wo sind die Probleme“ zu einer gefilterten, zählbaren Liste gelangen kann, ohne die Karte zu verlassen.

So viele Fahrten gleichzeitig zu zeigen, verändert, was die nächste sinnvolle Ansicht tatsächlich ist. Der naheliegende nächste Schritt ist Heatmapping, das Bündeln der Überschreitungsdichte nach Geografie, sodass eine Region mit einer unverhältnismäßig hohen Zahl roter Fahrten auf einen Blick hervorsticht – dasselbe Prinzip „es erkennen, bevor es ein Ticket wird“ hinter der Cluster- und Marker-Sprache früher in dieser Fallstudie, angewendet im Portfolio-Maßstab statt für eine einzelne Sendung. Das ist noch früh, ein Umschalter und eine auf Fahrtebene bewährte Farbsprache, noch kein fertiges Heatmap-Produkt, aber es ist die Richtung, in die die Karte naturgemäß will, sobald Zustandsdaten für jede Fahrt in einer Lieferkette existieren, nicht nur für die eine, die zufällig jemand geöffnet hat.