SOFTWARE
yuuvis® Momentum: Wie ich das B2B „Enterprise-Monster“ durch Code und Empathie zähmte
Status: Ehemaliges Projekt (Strategisches Erbe): eine leistungsstarke Content Services-Plattform, die Milliarden von Dokumenten in Ihrer eigenen Systemlandschaft verwalten kann. | Rolle: Lead Product Designer
Stack: Figma, Design Systems, Responsives Design, Git, NPM, Angular, TypeScript & SCSS.
Der Hook (Das Ergebnis vorab)
Enterprise-Software muss nicht kompliziert aussehen, nur weil die Datenmenge massiv ist. Bei yuuvis® Momentum stand ich vor der Herausforderung, eine hochflexible Cloud-Architektur in ein Interface zu übersetzen, das für Administratoren intuitiv bleibt. Durch die Einführung eines Code-First Design-Systems habe ich nicht nur die Konsistenz gewahrt, sondern die Release-Zyklen für neue Features drastisch verkürzt. Der Impact auf einen Blick:
40%
effizienterer Developer-Handoff durch ein konsistentes
Design-System.
25%
schnellere
Task-Completion-Rate bei komplexen Admin-Workflows.
95%
Positives
Nutzerfeedback
Hier finden Sie Screenshots aus einem realen funktionierenden System. Im Folgenden zeige ich, wie ich zu diesem Ergebnis gekommen bin.
Das Problem definieren
Technisch war yuuvis® Momentum von Tag eins an ein Gigant: Eine cloud-native B2B-Plattform, bereit für Millionen von Dokumenten. Doch für die Menschen vor den Bildschirmen war dieser Gigant ein Labyrinth. Wir hatten ein System, das technisch alles konnte, aber dessen Komplexität die Effizienz der Nutzer im Keim erstickte. Administratoren verloren sich in verschachtelten Menüs, und die Suche in Millionen von Dokumenten fühlte sich träge und frustrierend an.
Discovery: Den Nutzerbedürfnisse verstehen
Ein System dieser Größenordnung kann man nicht raten. Ich begann mit einer intensiven Research-Phase:
-
User Research: Durch qualitative Interviews mit Systemadministratoren und Power-Usern identifizierte ich die größten Reibungspunkte: Datenüberlastung und langsame Suchprozesse.
-
Personas: Um die unterschiedlichen Anforderungen abzubilden, habe ich drei Kern-Profile geschärft: Daniel (CTO), der den Fokus auf technologische Skalierbarkeit und Cloud-Sicherheit legt; Robert (Accountant), für den fehlerfreie, effiziente Workflows bei der Dokumentenprüfung zählen; und Sales Manager Indra, die Informationen in Sekundenschnelle finden muss. Diese klare Differenzierung half uns, die Feature-Roadmap so zu priorisieren, dass sie sowohl strategischen als auch operativen Zielen gerecht wird.
-
Usage Requirements: Aus der Forschung leiteten wir klare funktionale Anforderungen ab: Minimierung der Klickwege, persistente Filter und eine massiv skalierbare Tabellenansicht.
Anforderungen in Logik übersetzen
Nachdem die Schmerzpunkte durch die Personas und Usage Requirements klar definiert waren, ging es darum, diese theoretischen Anforderungen in eine funktionale Architektur zu übersetzen.
User Journey Mapping: Auf Basis der identifizierten Kern-Profile (wie Robert und Daniel) habe ich eine umfassende User Journey Map entwickelt. Dabei lag der Fokus nicht nur auf dem „Happy Path“, sondern vor allem auf den kritischen Interaktionsmomenten, die ich in den Requirements identifiziert hatte. Das Ziel war es, die Klickwege für Routineaufgaben radikal zu verkürzen и „Sackgassen“ im Prozess zu eliminieren, bevor die erste Zeile Code geschrieben wurde.
Belastbare Informationsarchitektur (IA): Parallel dazu habe ich die Informationsarchitektur komplett neu strukturiert. Die Herausforderung war hier die technologische Skalierbarkeit: Die Struktur musste so modular und flexibel sein, dass sie sowohl in hochgradig restriktiven Private-Cloud-Szenarien als auch in offenen Public-Cloud-Umgebungen konsistent bleibt. Durch diesen Prozess konnten wir sicherstellen, dass das System trotz wachsender Datenmengen und komplexer Berechtigungslogiken für den Endnutzer flach и intuitiv bleibt.
Mein „Game Changer“: Warum Figma allein nicht reichte
In einem Enterprise-Projekt dieser Größe ist Zeit buchstäblich Geld. Um den Design-Prozess zu radikal beschleunigen und unnötige Korrekturschleifen beim manuellen Skizzieren zu umgehen, haben wir einen „Code-First“-Ansatz gewählt.
Statt jedes Element zeitaufwendig in Grafik-Tools nachzubauen, haben wir die UI-Bibliothek direkt als HTML-, SCSS- und TypeScript-Code erstellt. Dieser Ansatz garantierte, dass Design und technische Realität von der ersten Sekunde an zu 100 % deckungsgleich waren.
-
Angular & NPM Integration: Um die Skalierbarkeit für das gesamte Team zu sichern, habe ich das fertige Angular-Projekt im Node Package Manager (NPM) veröffentlicht.
-
Der Impact: Entwickler konnten das gesamte Design-System mit einem einfachen Befehl direkt in den Hauptcode von yuuvis® Momentum integrieren. Das sparte Wochen an Entwicklungszeit und eliminierte die typischen „Übersetzungsfehler“ zwischen Design und Code.
-
Skalierbarkeit: Neue Features müssen nicht neu erfunden werden – sie werden aus stabilen, bereits getesteten Code-Komponenten zusammengesetzt.
Die Bibliothek ist hier öffentlich einsehbar: 👉 @yuuvis/styles auf npm
Evaluation: Qualitätssicherung & Kontinuierliche Verbesserung
Design ist für mich nie „fertig“. Nach dem ersten Release habe ich das System auf zwei Ebenen kritisch geprüft, um sowohl die Usability als auch die rechtliche Konformität sicherzustellen.
A) Heuristische Evaluation (nach Nielsen).
Um Schwachstellen in der Benutzerführung aufzudecken, habe ich eine Analyse basierend auf den 10 Usability-Heuristiken durchgeführt:
-
Erkenntnis: Besonders bei der Heuristik „Visibility of System Status“ gab es Optimierungspotenzial – Nutzer erhielten bei Massen-Uploads von Dokumenten zu wenig Rückmeldung über den Fortschritt.
-
Maßnahmen: Ich erarbeitete ein Konzept für verbesserte Progress-Indikatoren und ein proaktives Fehlermanagement.
-
Next Steps: Diese Evaluation dient nun als Roadmap für kommende Versionen, um die User Experience iterativ zu steigern.
B) Barrierefreiheit & BITV-Prüfung.
Da yuuvis® Momentum im öffentlichen Sektor (Verwaltungen, Kliniken, Gerichte) eingesetzt wird, ist volle Barrierefreiheit nach EU-Recht zwingend erforderlich.
-
Der Test: Ich führte eine Selbstprüfung auf Basis des BIK BITV-Verfahrens (60 Prüfschritte) durch.
-
Ergebnisse: Ich identifizierte 14 Barrieren, die primär auf einer unsauberen HTML-Struktur basierten.
-
Lösung: Ich meldete diese Fehler sofort an das Entwicklungsteam. Gemeinsam korrigierten wir die Code-Struktur, um eine barrierefreie Bedienung (z. B. für Screenreader) zu garantieren.
Rückblick: Was bleibt und was ich heute anders machen würde
Ich arbeite heute nicht mehr an diesem Projekt, aber das Fundament steht noch.
Hätte ich das Projekt heute noch unter meiner Fittiche, würde ich eine LLM als „unsichtbaren Assistenten“ integrieren.
Idee: KI, die Dokumente beim Upload automatisch klassifiziert (Auto-Indexing), sodass Nutzer wie Robert gar keine Metadaten mehr händisch eingeben müssen.
Technik: Umstellung auf Design Tokens (via Style Dictionary), um das System komplett framework-agnostisch zu machen (weg von reinem Angular, hin zu React/Tailwind-Kompatibilität).