Fallstudie · Großsysteme · Kunde vertraulich
Das Portal hatte viel zu viele Seiten, um sie einzeln zu gestalten, und das System dahinter musste Redakteuren standhalten, die den ganzen Tag damit arbeiten. Deshalb habe ich nicht mit Screens begonnen. Ich habe eine Token-Bibliothek gebaut und beide Produkte daraus wachsen lassen.
Teil einsProzess
Ich habe nicht zuerst Figma geöffnet. Ich habe die Anforderungen gelesen, bis ich sie jemand anderem erklären konnte, Workshops mit den Institutionen geleitet, deren Daten auf dem Portal landen, und herausgearbeitet, wer was braucht. Daraus entstanden die Entscheidungen unten, und sie prägten alles Weitere.
01Research
Bürger, Gemeinden, Forschende und Redakteure wollen von derselben Seite unterschiedliche Dinge. Ich habe aufgeschrieben, wer was braucht.
02Workshops
Ich habe Workshops mit den Institutionen hinter den Daten geleitet. Die Haftnotizen zeigten, was jede von ihnen wirklich braucht und wo sich alle einig sind.
03Analyse
Ich bin die Anforderungen Zeile für Zeile durchgegangen und habe ähnliche Portale verglichen, um zu sehen, was schon funktioniert und was noch niemand gelöst hat.
04Kartierung
Dann habe ich jeden Bereich, jede Seite und das System kartiert, das all das veröffentlicht.
05Entscheidungen
Daraus entstanden vier Entscheidungen. Ich habe sie früh festgehalten, und sie hielten bis zum Schluss.
06System
Alles andere auf dieser Seite ist aus diesen vier gewachsen.
Teil zweiDas Portal-Kit
Niemand öffnet ein Portal, um seine Komponenten zu bewundern. Man kommt wegen einer Zahl, eines Dokuments oder einer Frist. Das sind die Teile, die einen dorthin bringen, hier aus dem Prototyp nachgebaut, mit geänderten Namen und Daten.
01Datenanzeige
Eine Zahl ohne Quelle ist nur ein Gerücht. Jeder Wert auf dem Portal sagt, woher er kommt, wann er zuletzt aktualisiert wurde und ob er gestiegen oder gefallen ist, mit Pfeil und Vorzeichen, nicht nur mit Farbe.
02Diagramme
Partikel, Gase, Temperatur und Pollen sind für unterschiedliche Menschen wichtig, aber auf dem Portal teilen sie sich eine Karte: Titel, Zeitraum, Tabs, Diagramm und eine kurze Tabelle. Wer eine lesen kann, kann alle lesen.
03Navigation
Die Seitenleiste behält dieselben Einträge, Icons und Zähler, ob geöffnet oder eingeklappt, und die obere Leiste hält Suche, Assistent, Sprache und Einstellungen auf jeder Seite in derselben Reihenfolge. Niemand sollte die Navigation suchen müssen.
04Notifications
Eine kleine farbige Kachel zeigt, welche Art von Nachricht es ist, ein Punkt, dass sie neu ist, und ein Link leert alles. Dieselbe Zeile funktioniert im Benachrichtigungsfeld und im Posteingang, also musste ich sie nur einmal gestalten.
05Formulare und Bedienelemente
Felder, Auswahlmenüs, Checkboxen, Schalter und Stepper teilen eine Höhe, einen Radius und einen Fokusring. Ein Luftqualitätsalarm und eine Seite mit Barrierefreiheitseinstellungen bestehen aus genau denselben Teilen.
06Karten und Listen
Eine Icon-Kachel mit Titel, ein leerer Zustand mit einer klaren Aktion, eine Liste mit Links. Diese wenigen Teile wiederholen sich überall im Portal, deshalb ist ein neuer Bereich meist nur eine Frage der richtigen Auswahl.
Teil dreiZentrales System
Alles, was Menschen auf dem Portal sehen, wird hier geschrieben, geprüft und veröffentlicht, von Redakteuren, die jeden Tag darin arbeiten. Es nutzt dieselben Tokens wie das Portal, ist aber für Tempo und Kontrolle gebaut, nicht für den ersten Eindruck.
01Zugang
Redakteure melden sich mit einem zweiten Faktor an, sehen, wann ihr Passwort abläuft, und wissen, wann die Sitzung endet. Das klingt streng, aber es geht um offizielle Inhalte, und Menschen entspannen sich, wenn sie die Regeln sehen, statt sie zu erraten.
02Workflow
Entwurf, redaktionelle Prüfung, rechtliche Prüfung, geplant, veröffentlicht. Dieselben Status, Farben und Zahlen erscheinen in der Liste, im Editor und in Benachrichtigungen, sodass niemand im Chat fragen muss, wo ein Artikel steht.
03Rollen und Rechte
Wer was erstellen, bearbeiten, freigeben oder veröffentlichen darf, passt auf einen Screen. Die Administratorrolle lässt sich nicht versehentlich löschen, und eine privilegierte Rolle verlangt eine zweite Bestätigung. Beide Regeln gibt es, weil irgendwo irgendwann jemand alle anderen ausgesperrt hat.
04Seitenbaum
Redakteure verschieben Seiten im Baum, wählen eine Vorlage und entscheiden, wo eine Seite in der Navigation erscheint. Menüs und Breadcrumbs passen sich von selbst an, damit aus einer Änderung nicht fünf werden.
05Änderungsprotokoll
Wer was wann geändert hat, steht in klarer Sprache da. Bei offiziellen Inhalten ist das kein nettes Extra, sondern das Erste, wonach jeder fragt, wenn etwas schiefgeht.
Teil vierDie Bibliothek
Meine Designbibliothek gab es schon vor diesem Projekt. Neu ist die Bibliothek für diesen Bereich: shadcn/ui mit eigenen Tokens, Themes und Mustern, einmal festgehalten und von beiden Produkten genutzt.
01Token-Register
Komponenten fragen nie nach Orange oder Grau. Sie fragen nach --primary oder --muted-foreground, und das Register sagt, wofür jeder Name steht. Genau diese eine Gewohnheit macht die nächsten beiden Abschnitte möglich.
02Farb-Tokens
Hell, dunkel und hoher Kontrast ändern nur die Werte hinter den Namen. Die Komponenten merken es nicht einmal, und genau darum geht es, und deshalb ist Barrierefreiheit hier kein eigenes Projekt.
03Elevation
Ein kleiner Satz Schatten, jeder mit einer Aufgabe, von Karten bis zu Dialogen. Wenn jemand einen neuen will, hat meist das Layout ein anderes Problem.
04Komponenten
Alles, was man drücken kann, hat dieselbe Höhe, denselben Radius und denselben Fokusring, und jede Karte hat dieselben drei Zonen. Das ist absichtlich langweilig, denn langweilig ist, was Menschen schnell macht.
05CRUD-Layout
Ein Kopfbereich mit Aktionen, Filter, eine Tabelle, Paginierung und ein Bearbeitungsfeld an der Seite. Inhalte, Nutzer, Medien und Datensätze nutzen es, im Portal und im zentralen System.
06Schrift
Google Sans in vier Größen mit festen Zeilenhöhen. Niemand wählt eine Größe nach Augenmaß, deshalb hält die Hierarchie auf jeder Seite, auch auf denen, die ich nicht selbst gestaltet habe.
OutcomeWo es steht
Jeder Teil ist vollständig ausgearbeitet. Die Entwicklung ist auf elf Monate geschätzt, das Design dauerte etwa drei. Das Portal umfasst sehr viele Seiten und noch mehr Komponenten, und ganze Bereiche gibt es als fertige Blöcke, sodass jemand Neues eine Seite zusammenstellen kann, ohne bei einem leeren Screen anzufangen.
Was als Nächstes kommtSkalierung
Weil alles von einer Quelle ausgeht, beginnt der nächste Schritt nicht bei null, ob das zentrale System, eine mobile App, weitere Teams mit der Bibliothek oder etwas, worum noch niemand gebeten hat.
2026 · Jetzt
WebanwendungDas öffentliche Portal, gebaut aus Kit und Tokens.Jetzt
Zentrales SystemDas System hinter dem Portal, auf denselben Komponenten.Als Nächstes
Mobile SkalierungDieselben Tokens, angepasst an die Funktionsweise von Smartphones.Quelle der Wahrheit
Gemeinsame BibliothekDie Quelle, aus der jedes Produkt schöpft.Später
Eine neue LösungWas auch immer als Nächstes kommt, beginnt bei derselben Quelle.Das war von Anfang an das eigentliche Ziel. Produkte ändern sich, Teams ändern sich, und das Portal wird in fünf Jahren anders aussehen. Die Entscheidungen darunter sollten trotzdem noch Sinn ergeben.