Erst der Prozess, dann das Produkt
Als Designer gestalte ich nicht nur Ergebnisse, sondern die Wege dorthin. Welches Vorgehen eine Aufgabe braucht, ist selbst eine Entwurfsentscheidung, und sie fällt für jedes Vorhaben neu.
1 · Die Methode ist Teil des Entwurfs.
Ich halte mich an kein Verfahren dogmatisch. Verschiedene Werkzeuge erfüllen verschiedene Zwecke, und jedes lässt sich anpassen. Also entscheide ich für jede Aufgabe neu, welches Vorgehen zu ihr passt und zu der Organisation, die sie lösen soll.
2 · Erst den Bestand kartieren.
Bevor etwas Neues entsteht, muss das Vorhandene sichtbar sein: was existiert, was widerspricht sich, was wird tatsächlich benutzt. Ohne diese Karte gestaltet man an der Wirklichkeit vorbei.
3 · Das Neutrale zuerst, die Marke danach.
Wer mit der Markenfarbe beginnt, baut ein System für eine Marke. Wer mit der neutralen Grundlage beginnt, baut eines, das viele tragen.
4 · Architektur ist ein eigenes Artefakt.
Sie steckt nicht implizit in Komponenten, sondern wird aufgeschrieben, damit man über sie streiten kann, bevor sie gebaut wird.
5 · Werkzeuge bauen, wenn Handarbeit nicht skaliert.
Wiederholt sich ein Schritt, gehört er automatisiert. Früher als Plugin, heute als lauffähige Anwendung. Das Werkzeug ist kein Nebenprodukt der Arbeit, es ist Teil davon.
6 · An Mustern validieren.
Ein System beweist sich an echten Fällen, nicht an Meinungen im Review. Erst wenn Muster tragen, wird ausgerollt.
7 · Es muss gekauft werden.
Ein System, das niemand versteht, wird nicht übernommen. Erklären, präsentieren und überzeugen sind kein Nebenprodukt der Arbeit, sondern die Bedingung dafür, dass sie wirkt.
Was bleibt, ist nicht das Verfahren, sondern die Haltung dahinter. Die Methoden wechseln mit der Aufgabe, die Prinzipien nicht.
Prinzipien sind wohlfeil, solange niemand sie an einer Arbeit nachvollziehen kann.
Der Dark Mode über 16 Marken. Bei Telefónica habe ich die Dark-Mode-Architektur weitgehend eigenständig aufgebaut: erst die Kartierung des Bestands und eine Übersetzung von Alt nach Neu, dann eine neutrale Palette als Grundlage, darauf die Marken. Am Ende steht jede Marke in Hell und Dunkel auf derselben Architektur.
Umgeschaltet wird an einer einzigen Stelle auf oberster Ebene der Seite. Es gibt keine zweite Codebasis, keinen Sonderfall je Marke und keinen Schalter, der im Produkt gepflegt werden müsste. Wer die neutrale Architektur zuerst baut, bekommt den dunklen Modus als Konsequenz, nicht als eigenes Projekt. Dabei bekommt jede Marke ihre eigene neutrale Palette: o2 und blau landen im dunklen Modus nicht beim selben Grau, sondern bei einem, das zur jeweiligen Marke passt. Gemeinsame Architektur, eigener Ton.
Der Token Explorer. Das ONE Design System überschreibt Werte über sieben Schichten hinweg, von der globalen Basis bis zur einzelnen Komponente. Von Hand ist kaum zu ermitteln, welcher Wert am Ende greift, welcher dabei überschrieben wurde und was der ursprüngliche gewesen wäre. Also habe ich ein Werkzeug gebaut, das die vollständige Auflösungskette eines Tokens zeigt, rückwärts sucht, welche Komponenten es verwenden, und zwei Entwicklungsstände direkt vergleicht. Es liegt im Storybook des Design Systems und steht damit dem ganzen Team offen. Größenordnung: knapp 5.000 Tokens je Marke und Modus, allein 3.828 davon auf Komponentenebene.
Und die eigene Praxis. Diese Website ist selbst der dritte Beleg: ein tokengesteuertes System, das dieselbe Seite in mehreren Gestaltungsprofilen trägt, vollständig im Redaktionssystem pflegbar, ohne fest verdrahtete Inhalte. Dazu ein Konfigurator, der für jede Bewerbung eine eigene, geschützte Fassung mit kuratierter Projektauswahl erzeugt.
Die Umsetzung entsteht KI-gestützt, die Entscheidungen nicht. Was ich beanspruche, sind die Architektur und die Regeln dahinter. Dazu gehört auch, Dinge zu beenden: Eine eigene Anwendung zur Logo-Animation habe ich gebaut, mit dem Markt verglichen und eingestellt, weil ein vorhandenes Werkzeug es besser konnte. Das ist kein Scheitern, sondern das Ergebnis derselben Prüfung, die ich an jede Lösung anlege.