Das Dashboard besitzen, nicht mieten.

Die Herausforderung

Die für Brambles' Kunden bestimmten Dashboards wurden auf zwei Arten gebaut, und keine der beiden gehörte uns wirklich. Manche lebten in Power BI – funktional, aber nie ganz auf die tatsächliche Arbeitsweise der SCI-Kunden zugeschnitten. Der Rest lief auf Brix, einem internen Dashboard-System, das auf dem Backend eines Drittanbieters aufsetzte, und dessen Gebühren hatten inzwischen ein Niveau erreicht, das das Unternehmen nicht länger zu zahlen bereit war.

Das ist ein vertrautes Problem: eine Fähigkeit, von der das Unternehmen abhängt, gestützt auf eine Lieferantenbeziehung, die wirtschaftlich keinen Sinn mehr ergibt. Die eigentliche Chance bestand nicht nur darin, „es günstiger zu bauen". Sie bestand darin, das Fenster der Vertragsverlängerung als Moment zu nutzen, um ein Dashboard-Erlebnis zu bauen, das Kunden wirklich selbst gestalten könnten – mit unseren Daten, unserem Frontend, gestaffelt nach Abonnement –, statt eines starren, von einem Lieferanten gelieferten Produkts.

Bevor dieser Rebuild beginnen konnte, stand zunächst eine kürzere, begrenztere Arbeit an: die bestehenden Brix-Dashboards im White-Label-Verfahren an die Optik von SCI anzupassen, damit Kunden ein stimmiges Produkt erlebten, während das eigentliche System im Hintergrund entstand. Ich habe diesen Übergang geleitet und ihn bewusst schnell und visuell konsistent mit SCI gehalten, gerade damit er nicht zu einer eigenen Geschichte werden musste. Das hat der eigentlichen Konstruktion die nötige Zeit verschafft.

Die Chance lag nicht in einem billigeren Dashboard. Sie lag in einem Dashboard, das unsere Kunden wirklich selbst bauen konnten.

Meine Rolle

Ich habe das Produktdesign für das anpassbare Dashboard-System von SCI verantwortet, in Zusammenarbeit mit den Teams für UX, Research, Implementierung und Kundenbetreuung sowie direkt mit dem Engineering, um es von einzelnen Bausteinen zu einem ausgelieferten, gestaffelten Produkt zu führen.

Das umfasste das Design-System-Fundament, auf dem der gesamte Build ruht: die Diagramm-, Tabellen- und Kennzahlenkomponenten, aus denen Dashboards zusammengesetzt werden, die Flows zum Erstellen, Bearbeiten und Anpassen eines Dashboards, und die Funktionalität, die festlegt, was ein bestimmter Kunde je nach Abonnement-Stufe tatsächlich bauen darf. Angesichts einer engen Frist habe ich Dmytro, einen der stärksten Designer, mit denen ich je gearbeitet habe, für die Datenvisualisierungskomponenten als engen Mitgestalter hinzugezogen statt als bloße Übergabe; wir haben diesen Teil gemeinsam entwickelt und eng mit den Teams für Implementierung und Kundenbetreuung zusammengearbeitet, um zu validieren, was Nutzer vor Ort – im Büro wie im Werk – tatsächlich brauchten, damit ein Dashboard es ihnen auf einen Blick sagen konnte.

Jedes SCI-Dashboard, unabhängig von Stufe oder Zielgruppe, wird aus demselben zugrunde liegenden Komponentensatz zusammengesetzt: Diagrammblöcke, Tabellenblöcke und Kennzahlenblöcke, jeweils mit einem eigenen Satz an Varianten je nach Datentyp und Dringlichkeitsgrad. Ein Supply-Chain-Manager, der ein Problem untersucht, braucht eine andere Lesart als jemand, der eine monatliche Leistungszusammenfassung für ein Kundenmeeting vorbereitet – die Baustein-Bibliothek musste also beiden dienen, ohne zu zwei getrennten Systemen zu werden.

Hier habe ich mich am stärksten auf KI-gestützte Werkzeuge verlassen – nicht um das Design-Denken zu ersetzen, sondern um das schiere Volumen an Varianten zu beschleunigen, das eine echte Komponentenbibliothek braucht. Angesichts der Frist habe ich Dmytro hinzugezogen, um gemeinsam mit mir die Datenvisualisierungskomponenten zu entwickeln, und zusammen haben wir KI-gestützte Werkzeuge genutzt, um die Diagramm-, Tabellen- und Kennzahlenblöcke in Figma auszubauen, damit ein kleines Team einen wirklich breiten Satz an Bausteinen samt ihrer Zustände in der Zeit produzieren konnte, die die Vertragsfrist tatsächlich zuließ.

Tabellen- und Kennzahlenblöcke folgten derselben Logik: eine Komponente, mehrere Dichten und Zustände, statt einer maßgeschneiderten Tabelle für jeden Screen. Eine Kennzahlenkachel, die eine einzelne Zahl anzeigt, muss sich gleich verhalten, egal ob sie die pünktliche Lieferung eines einzelnen Standorts oder eines ganzen Flows meldet – die Zustände „im Soll", „gefährdet", „verletzt" wurden also einmal entworfen und überall dort wiederverwendet, wo eine Zahl ein Urteil tragen musste, nicht nur einen Wert.

Nichts davon war Komponentenbau um seiner selbst willen. Jeder Block existierte, weil die Teams für Implementierung und Kundenbetreuung einen echten Nutzerbedarf dahinter validiert hatten – in direkter Zusammenarbeit mit den Menschen, die täglich Dashboards für Walmart, Costco und Tesco bauen, und mit den Archetypen am anderen Ende der Kette: einer Büroanalystin, die Zeit hat, eine Tabelle zu erkunden, und jemandem im Werk vor Ort, der eine einzige Zahl braucht, die ihm auf einen Blick sagt, ob er handeln muss.

Hier ist die vollständige Bibliothek, jede Variante von Kennzahl, Tabelle und Diagramm, ihre Größen und Zustände, genau wie in Figma dokumentiert. Klicken Sie darauf und scrollen oder pinchen Sie zum Zoomen, ziehen Sie zum Verschieben.

Kunden sollten nicht bei null anfangen müssen. Je nach Abonnement-Stufe konnte ein Kunde ein bereits gebautes Startdashboard erhalten und es dann anpassen, eine Kachel hinzufügen, eine entfernen, ein Diagramm gegen eine Tabelle austauschen, oder ein komplett neues aus derselben Baustein-Bibliothek bauen. Intern verfügten Account Manager über dieselbe Baufähigkeit, sodass ein Dashboard, das ein Kunde dringend brauchte, nicht auf ein Engineering-Ticket warten musste.

Die Staffelung nach Stufen wurde nicht nachträglich hinzugefügt. Was ein bestimmter Kunde bauen konnte – von einer Vorlage aus starten statt von Grund auf zu bauen, ein begrenztes Blockset statt der vollständigen Bibliothek – war von Anfang an fester Bestandteil des Flow-Designs, denn genau das ermöglichte es dem Unternehmen, auf jeder Abonnement-Stufe ein wirklich differenziertes Produkt anzubieten, statt eines einzigen Dashboard-Erlebnisses hinter einer Bezahlschranke.

Ein bestehendes Dashboard zu bearbeiten folgte derselben Bausteinlogik, nur umgekehrt: eine Kachel auswählen, ändern, was sie zeigt, sie in der Größe anpassen oder löschen, ohne das Dashboard selbst je für einen separaten Konfigurationsbildschirm zu verlassen. Das zählte mehr, als es zunächst scheint. Ein Kunde mitten im Gespräch mit den eigenen Stakeholdern musste in der Lage sein, das, was er gerade betrachtete, sofort umzugestalten – nicht eine Anfrage einzureichen und zu warten.

All das oben ist die Kurzfassung. Hier darunter die beiden vollständigen Figma-Flows dahinter, jeder Zustand, Sonderfall und jede Anmerkung, genau wie entworfen. Klicken Sie auf einen davon und scrollen oder pinchen Sie zum Zoomen, ziehen Sie zum Verschieben.

Sobald die Figma-Bausteine standen, arbeiteten Produkt, UX und Engineering direkt daraus – das Frontend wurde in React gebaut, wobei Claude in VS Code genutzt wurde, um eine dokumentierte Komponente schnell in funktionierenden Code zu verwandeln: Bau mir eine Seite, füge diese Kachel hinzu, verbinde diesen Flow. Dieser Workflow ist es, der die Baustein-Bibliothek in Wochen statt Monaten zu einem echten Produkt gemacht hat, ohne die übliche Lücke zwischen Entworfenem und Ausgeliefertem.

Dieser Workflow wurde noch schneller, sobald die Figma-Komponentenbibliothek selbst mit einer entsprechenden Code-Komponentenbibliothek innerhalb desselben KI-Playgrounds synchronisiert wurde. Jeder Diagramm-, Tabellen- und Kennzahlenblock aus Kapitel 01 existierte bereits als benanntes, dokumentiertes Pattern auf beiden Seiten, Design und Code, sodass das Hinzufügen eines davon zu einer Dashboard-Seite keine kleine Bauaufgabe mehr war, sondern zu einem einfachen Prompt wurde: Füge hier ein Balkendiagramm ein, ersetze diese Kachel durch eine Kennzahlenkarte, füge darunter eine Tabelle hinzu. Der Playground rät nicht, wie diese Komponente aussehen soll. Er liest denselben Block, der bereits vom Designsystem definiert wurde.

Die Stärke davon liegt nicht darin, dass sie das Engineering überflüssig macht, sondern darin, dass sie die Lücke zwischen einer validierten Design-System-Komponente und einer funktionsfähigen Seite schließt. Eine Diagramm-, Tabellen- oder Kennzahlenkarten-Kachel, die früher ein kleines Bau-Ticket bedeutete, dauert jetzt nur noch Sekunden, und weil jede Kachel weiterhin aus derselben synchronisierten Bibliothek stammt statt aus Ad-hoc-Code, kostet dieses Tempo nicht die Konsistenz, die der parallele Build aus Kapitel 04 beinahe gekostet hätte. Es ist dieselbe Disziplin wie im Rest dieses Builds, nur Prompt für Prompt angewandt.

Brambles testete zu dieser Zeit KI-beschleunigte Entwicklung in größerem Maßstab, und einer der Testzweige produzierte eine zweite Version des Dashboard-Builds – schnell mit KI-Tools gebaut, aber außerhalb des Designsystems und ohne die bereits validierten, produktiv laufenden UX-Patterns. Das ist ein leicht zu machender Fehler, gerade weil KI die Reibung beseitigt, die früher einen Kontrollpunkt erzwang: Ein paralleles System von Grund auf zu bauen dauerte früher lange genug, dass sich jemand fragte, ob es überhaupt existieren sollte. Mit KI ist das nicht mehr der Fall, sodass die Divergenz ausgeliefert werden kann, bevor sie irgendjemandem auffällt.

Das Ergebnis kam bei den Implementierungsteams als etwas an, das fertig aussah, aber nicht nutzbar war. Das ist der klarste und direkteste Beweis, den ich habe, dass ein System – so schnell es einen auch vorankommen lässt – sein Tempo nur verdient, wenn das, was es produziert, konsistent bleibt.

Ich bin dem direkt entgegengetreten, nicht um eine Design-Datei um ihrer selbst willen zu verteidigen, sondern weil bereits eine funktionierende, validierte Version existierte und ein paralleler Neubau von Grund auf das Unternehmen echte Zeit gegenüber einer Kundenfrist kostete. Ich habe die Entscheidung getroffen, den parallelen Build unter dasselbe System zurückzuholen, statt ihn weiter abdriften zu lassen, habe den Product Owner, den Lead Engineer und Dmytro wieder an einen Tisch geholt, und mir die nötige Unterstützung gesichert, um die Lücke schnell zu schließen, ohne die Frist zu verschieben, die er gefährdet hatte. Die Lösung war nicht, die KI-gestützte Entwicklung zu verlangsamen. Sie bestand darin, sie auf das System auszurichten, das bereits funktionierte.

Ich habe diese Neuausrichtung persönlich geleitet, indem ich mich direkt in den KI-beschleunigten Build selbst eingebracht habe statt ihn nur im Nachhinein zu überprüfen, in Zusammenarbeit mit dem Product Owner und dem Lead Engineer, und mit Dmytro wieder an den Datenvisualisierungskomponenten, um sicherzustellen, dass er auf derselben Komponentenbibliothek, denselben Figma-Blöcken und denselben validierten UX-Patterns aufbaute wie alles andere in SCI. Das ist der eigentliche Unterschied zwischen KI als Abkürzung, um einen guten Prozess zu umgehen, und KI als Beschleuniger dieses Prozesses: dasselbe Werkzeug, auf ein System statt daneben ausgerichtet, mit jemandem, der für diese Entscheidung verantwortlich ist.

Sobald diese Neuausrichtung abgeschlossen war, kehrten sich die Zahlen um, mit denen das Implementierungsteam gelebt hatte. Dashboards, deren Bau bis zu sechs Stunden dauerte und die trotzdem nicht stimmten, fielen auf wenige Minuten, weil das Zusammensetzen einer Seite aus validierten, dokumentierten Komponenten grundsätzlich schneller ist, als jedes Mal ein UX-Pattern von Grund auf zurückzuentwickeln, KI-gestützt oder nicht.

Die Komponentenbibliothek blieb auch nicht auf dieses eine Projekt beschränkt. Drei weitere Brambles-Produkte haben seither dieselben Dashboard-Komponenten und dieselbe Anpassungs-UX übernommen, um ihre eigenen Dashboards zu bauen, und die Bibliothek selbst wurde in das offizielle Designsystem von Brambles integriert – nicht als eine Handvoll atomarer Komponenten wie Buttons und Eingabefelder, sondern als vollständige Patterns: die Diagramm-, Tabellen- und Kennzahlenblöcke sowie die Flows zum Zusammensetzen, Bearbeiten und Anpassen eines Dashboards, aus denen andere Teams heute direkt Funktionen bauen können, statt sie von Grund auf zu entwerfen.