Case /01 · 2026

Pax Versicherung

Eine neue Identität braucht mehr als eine neue Startseite. Das System dahinter habe ich zusammen mit der UX/UI-Designerin von Pax gebaut: eine UI-Komponenten-Library, in der die Marke eine Variable ist.

TypMandat
Im Team von Pax · ~1 Jahr
RolleSenior Frontend-Architekt
Designsystem · UI-Library
UmfangPortal-Redesign · Refactoring
84 Komponenten
StackAngular 19 · Nx
Style Dictionary · Storybook
Live pax.ch
ui.pax.ch

Gegeben

Eine Marke hält nur, wenn der hundertste Button aussieht wie der erste.

Angefangen hat es beim Kundenportal my.pax.ch: darunter Jahre an Anbau und eine Architektur, die sich gegen jede Änderung wehrte. Jedes neue Feature dauerte länger, als es sollte. Der Auftrag war zweierlei auf einmal: ein neues UX/UI und ein Refactoring, tief genug, um das Portal von der alten Architektur zu lösen und den Code wieder einfach zu machen. Dann kam der Brand Refresh, und die Komponenten aus diesem einen Portal wurden zur Keimzelle einer gemeinsamen Library, die heute in mehreren Pax-Produkten läuft.

  • /aDerselbe Button muss auf der Marketing-Website und in einem internen Werkzeug gleich aussehen und sich gleich verhalten, auch nach der nächsten Anpassung der Marke.
  • /bDer neue Auftritt trägt auf zwei Farben: einem grünen Primary und einem tiefvioletten Secondary. Verdrahtet man die fest in hundert handgebaute Komponenten, wird jedes Rebranding zur Suche durch jede Datei.
  • /cDie öffentliche Website und die internen Apps teilen sich keine Laufzeitumgebung. Eine Library musste überall rendern, serverseitig gerenderte Seiten eingeschlossen, ohne dass ein Compiler im Browser landet.
  • /dEine echte Produktoberfläche braucht Dutzende Komponenten, jede auf demselben Qualitätsniveau. Sonst vertraut niemand dem System genug und jeder baut sich seine eigenen.

Beweis

Die Marke ist eine Variable. Komponenten nennen nie eine Farbe. Ein Button fragt nach --background-brand, ein Eingabefeld nach --border-focusring. Diese semantischen Namen lösen sich über eine Token-Pipeline aus Figma auf das Pax-Grün und das tiefe Violett auf. Tauscht man die zwei Markenwerte, kleidet sich die ganze Library neu ein, hell und dunkel, ohne dass eine einzige Komponentendatei angefasst wird. Das ist die Grenze zwischen einem Komponenten-Baukasten und einem Designsystem.

ein System zwei Markenwerte alles zieht nach
CHF 250'000|
Aktiv Leben 3a Police ansehen

#8ccd0f primary#3c0078 secondary--background-brand löst den Rest auf

/02

Zwei Markenfarben, eine ganze semantische Schicht.

Grün und Tiefviolett sind die einzigen Markenentscheide. Flächen, Text, Rahmen, Fokusringe und Zustände lesen alle aus semantischen Tokens, die sich gegen diese zwei auflösen. Design entscheidet in Figma, der Code folgt. Ändert man die Marke an einer Stelle, zieht alles nach, weil unterhalb der Token-Schicht niemand weiss, dass es Hex-Werte gibt.

Primary#8ccd0f
Primary · Kontrast#579e00
Primary · dunkel#003018
Secondary#3c0078
Secondary · dunkel#2a0754
Inktext-default

Brand-Primitives → semantische Tokens → Komponenten

/03

Hell und dunkel aus einer Quelle.

Ein Theme ist nichts weiter als ein zweiter Satz aufgelöster Werte. Weil Komponenten semantische Tokens konsumieren und nie rohe Farben, ist der Dark Mode kein zweites Stylesheet, das jemand pflegen muss. Er fällt aus demselben Mechanismus heraus: automatisch über prefers-color-scheme oder erzwungen über ein Data-Attribut.

light
dark

Dieselbe Komponente, zwei aufgelöste Themes

/04

Wie die Library auf jede Oberfläche kommt

Die Library ist vollständig ahead-of-time kompiliert und serverseitig renderbar, also tragen dieselben 84 Komponenten die öffentliche Website und die internen Apps aus einem Paket. Jede Komponente bringt eine Storybook-Story auf ui.pax.ch mit. Das System ist ein durchblätterbarer Katalog.

01 pax.ch · öffentliche Website
02 interne Pax-Applikationen
03 ui.pax.ch · lebende Komponenten-Doku
eine Library · 84 Komponenten

Eine Quelle, jede Oberfläche

Umbau

Ein unwartbares Portal, auf dem sich wieder schnell bauen lässt.

Das Kundenportal my.pax.ch war über Jahre zu etwas gewachsen, das sich gegen jede Änderung wehrte. Jedes neue Feature kostete mehr, als es sollte. Der Umbau löste es von der alten Architektur und vereinfachte es so weit, dass Features wieder schnell hineinfallen und die Developer Experience von Reibung zu Fluss wechselte. Die Komponenten-Library wuchs im selben Umbau, also war jedes neue Primitive an dem Tag in einem echten Produkt bewiesen, an dem es geschrieben wurde.

vorher
  • An die alte Architektur gekoppelt
  • Jedes Feature dauerte länger als nötig
  • Jede Änderung zog sich durch den ganzen Code
  • DX: Reibung
nachher
  • Entkoppelt und wartbar
  • Features fallen schnell hinein
  • Library im echten Produkt erprobt, während sie wuchs
  • DX: Fluss

Stimmen

/01
Nahezu eigenständig verantwortete er das Redesign unseres Kundenportals. Das Portal diente als Grundlage für eine gemeinsame Komponenten-Bibliothek, die heute produktiv in mehreren Applikationen eingesetzt wird.
Lucas MoldovanyiProduct Owner · Pax
/02
Zu zweit haben wir ein Designsystem inklusive eigener Angular-UI-Library im Brand Refresh aufgebaut und erfolgreich auf mehrere digitale Produkte ausgerollt. Besonders geschätzt habe ich sein Mitdenken und seine proaktive Arbeitsweise.
Sarah AusobskyUX/UI-Designerin · Pax
/03
Du hast einen wesentlichen Beitrag zur Entwicklung und Einführung unserer Pax UI Libraries geleistet und erfolgreich die Brücke zwischen Digital Sales und Software Engineering gebaut.
Claude EisenmannLeiter Software & Data Engineering · Pax

Q.E.D.

Der Rest löst sich auf Komponenten-Library öffnen