Meine Rolle: UX/UI-Designer & Consultant (Freelance)
Leistungen: UX-Audit, Use-Cases, System-Architektur, UX- und Design-Patterns, Prototyping, Dokumentation, Design-System Governance
Tool-Stack: Figma, geteilte Bibliotheken, (Sketch), Jira
Arbeitgeber: Luzerner Kantonalbank (LUKB)
Zeitraum: 10 Monate, September 2022 – Juni 2023
Einheitliches Design-System – durch atomare Struktur
Die fragmentierte Sketch-Bibliothek der LUKB führte zu Inkonsistenzen in allen Banking-Applikationen. Durch atomare Design-Methodik, kollaborative Workshops und systematische Dokumentation bauten wir ein skalierbares Figma-Design-System auf, das UI-Design Umsetzungen beschleunigte und Konsistenz sicherstellte. Eine Quelle der Wahrheit. Weniger Missverständnisse. Messbare Akzeptanz.
Kern-Shift: Von Komponenten-Chaos zu atomarer Klarheit – durch strukturierte Governance.
3 Min. Lektüre
Wie wir die Probleme lösten
Drei Herausforderungen, drei Durchbrüche
Designer adoptieren keine Systeme. Sie adoptieren Tools, denen sie vertrauen.
Die bestehende Sketch-Bibliothek war kaputt. Nicht verlinkte Komponenten. Inkonsistentes Spacing, zu viele vage Möglichkeiten. Designer, die das System umgingen statt damit zu arbeiten. Wir migrierten nicht einfach nach Figma – wir bauten Vertrauen neu auf. Gestartet mit Core-Styles, die alle brauchten. Getestet mit echten aktuellen Projekten. Iteriert auf Basis echter Schmerzpunkte der Anwender. Schnelle Prototypen in Stakeholder-Workshops überzeugten auch PM und Fachbereich – nicht durch Präsentationen, sondern durch direkte Interaktion.
Ergebnis: Vom Design Team aktive genutzt und adoptiert. Vertrauen schlägt Perfektion. Immer.
Komplexität potenziert sich. Einfachheit skaliert.
Die Sketch-Bibliothek enthielt über 200 redundante Styles und ungenutzte Komponenten. Die Analyse zeigte: Die meisten wurden nie angefasst oder gebrochen sodass diese ihr Bindung verloren. Wir wendeten atomares Design an – zerlegten alles in essentielle Bausteine. Atome wurden Moleküle. Moleküle wurden zu Organismen. Klare Hierarchie. Vorhersehbare Patterns.
Die Kernkomponenten wurden um ~40% reduziert.
Nicht durch Funktionsverlust. Sondern durch Entscheidungsabbau.
Dokumentation ist nicht optional. Sie ist das System.
Designer fanden die richtigen Komponenten nicht. Nicht weil sie nicht existierten – sondern weil auf diese zurückgreifen konnte oder die Verwendung zu unklar war. Wir dokumentierten Nutzungs-Patterns. Fügten Such-Labels hinzu. Erstellten visuelle Beispiele. Machten Komponenten erkundbar.
Das System wurde intuitiver, weil wir es auffindbar und verständlicher machten. Architektur ohne Leitsystem ist bloss Chaos mit Struktur. Dokumentation ist aber auch Weitergabe. Ein System, das nur sein Schöpfer versteht, ist kein Asset – es ist ein Risiko.
Final Designs
Konsistenz zählt. Eine gute Brand-Experience umfasst jede Interaktion.
Atomare Struktur: Von Atomen zu Pages
Wir strukturierten das System nach Brad Frosts Atomic-Design-Methodik. Jede Ebene baut auf der Vorherigen auf – und schafft eine vorhersehbare, skalierbare Grundlage. Als technisches Ökosystem haben wir Angular-Material herangezogen.
1. Atome – Text, Icons, Farben, Spacing, …
2. Moleküle – Headings, Paragraphen, Buttons, Input-Felder, Chips, …
3. Organismen – Formulare, Tabellen, Diagramme …
4. Templates – Navigation, Footer, Onboarding, Beratungs-Flows, …
5. Pages – Mobile, Desktop, Grossbildschirm, native Apps, …
Standardisiertes Spacing & Alignment
Eine der grössten Inkonsistenzen war das Spacing. Wir integrierten strukturierte Regeln für Margins und Padding in Atome und Moleküle – mit spürbar mehr Konsistenz und schnelleren Design-Workflows.
Key Learnings
Was dieses Projekt mich gelehrt hat
Ein Design-System ohne User-Buy-in bauen bedeutet: für niemanden bauen
Die Struktur war da. Figma auch. Aber die Designer fielen in alte Muster zurück. Der Schmerz: ein System pushen, das niemand nutzen wollte. Was half: Entwicklung stoppen, Workshops durchführen und das System auf Basis echter Designer-Workflows neu aufbauen – nicht idealer.
Atomic Design funktioniert – aber nur, wenn man klein anfängt und bewusst skaliert
Wir versuchten, das gesamte System auf einmal zu bauen. Riesiger Scope. Langsamer Fortschritt. Null Akzeptanz. Was mich rettete: den Scope auf Core-Komponenten zu reduzieren, den Wert schnell zu beweisen und dann schrittweise auf Basis echter Projektbedarf zu erweitern.
Dokumentation ist Design-Arbeit – kein Nachgedanke
Designer fanden Komponenten nicht, auch wenn sie existierten. Such-Labels waren inkonsistent. Usage-Beispiele fehlten. Der Schmerz: zusehen, wie bestehende Komponenten neu gebaut wurden. Was funktionierte: Auffindbarkeit als erstklassiges Design-Problem behandeln – mit kollaborativen Naming-Workshops.
Warum das noch zählt
Ein System funktioniert nur, wenn die Menschen es nutzen
Design-Systeme scheitern nicht an schlechter Architektur – sondern an schlechter Akzeptanz. Die beste Komponenten-Bibliothek der Welt ist nutzlos, wenn Designer nicht finden, was sie brauchen, ihr nicht vertrauen oder nicht verstehen, wie und wo sie einzelne Komponenten einsetzen können. Erst für Menschen bauen. Dann für Struktur.
Danke bis hierhin
Bereit für ein Gespräch?
Verwandte Projekte
Tauche tiefer in meine Arbeit ein
Klarer Flow, weniger Abbrüche – auch bei Edgecases
Kollaboratives Whitelabel-Template, das Zusammenarbeit und Dev. Handover vereinfachte
© 2025 Matze Lenz. All rights reserved. Imprint