Vertraulichkeit & Umfang:
Dieses Projekt unterliegt einer strengen Vertraulichkeitsvereinbarung (NDA). Diese Fallstudie konzentriert sich auf die UX-Strategie, die Informationsarchitektur sowie die Methodik der Produktarchitektur. Alle ursprünglichen Markenelemente, Projektnamen, spezifischen Kundendaten und internen Logiken wurden abstrahiert, um das geistige Eigentum aller beteiligten Parteien zu schützen.
Case Study
EventClass GmbH (Dresden)
2022 – 2024
Als einzige Designerin habe ich bei EventClass nicht nur ein Produkt redesigned — ich habe Design als Disziplin in ein rein entwicklergetriebenes Unternehmen eingeführt. Von der ersten User-Befragung bis zum live gegangenen System.
Lead Designer (Solo)
Product Design
Design System
User Research
B2B SaaS
Event Management
Design Kultur
10
Tage Time-to-Market
(vorher 8 Wochen)
350%
Deployment
Häufigkeit gestiegen
100%
UI Konsistenz
White-label ready
Kontext
EventClass GmbH aus Dresden entwickelt seit Jahren eine Event-Management-Software, die weltweit bei wissenschaftlichen Organisationen, Forschungsinstituten und großen Kongressen im Einsatz ist — darunter Einrichtungen wie die TU Dresden und Fraunhofer- oder Max-Planck-nahe Konferenzen.
Das Produkt war über Jahre hinweg gewachsen: Feature für Feature, Jahrgang für Jahrgang, immer getrieben von Entwicklern, die ihr Handwerk verstehen — aber nie durch die Augen der Nutzer gebaut haben.
Das Ergebnis: Eine Software, die technisch funktioniert, aber deren Benutzerführung der Backend-Logik folgt, nicht dem mentalen Modell der Menschen, die damit täglich arbeiten.
Der Wunsch der Firma war klar: neu bauen, richtig diesmal. Weg von den Altlasten, weg von der Dev-Logik auf der Oberfläche — hin zu einem System, das man gerne benutzt.
Die Herausforderung
Das eigentliche Problem
war nicht das Interface
Oberflächlich betrachtet war die Aufgabe ein Redesign. Tatsächlich war die eigentliche Herausforderung eine andere: Design als Denk- und Arbeitsweise in ein Unternehmen einzuführen, das noch nie mit einem Designer zusammengearbeitet hatte.
Worte wie „Figma", „Design System" oder „User Research" waren im Team unbekannt. Es gab keine Tokens, keine Komponentenbibliothek, keine strukturierten Nutzerbefragungen — und einen Chef, der überzeugt werden wollte, dass die Lösung nicht einfach „größere, buntere Buttons" sind.
Jahrelange Altlasten
Das System war über viele Jahre gewachsen, ohne architektonischen Plan, ohne Design-Grundlage. Technische Schulden im Frontend machten ein zeitgemäßes Weiterentwickeln schwer.
Backend-Logik auf der Oberfläche
Die Nutzerführung spiegelte die Datenbankstruktur wider, nicht die Arbeitsweise der Anwender. Was für Entwickler Sinn ergab, war für Organisatoren und Teilnehmer verwirrend.
Kein Design System
Keine Tokens, keine Komponentenbibliothek, keine konsistente visuelle Sprache. Jede neue Seite war ein Einzelstück: Schwer zu warten, unmöglich zu skalieren.
Keine Design-Kultur
Das Team hatte noch nie mit einem Designer zusammengearbeitet. Prozesse wie strukturierte User-Befragungen oder Design Reviews existierten nicht.
Meine Rolle
Lead Designer (solo)
Ich war die einzige Designerin im Unternehmen. Das bedeutete: keine Übergaben, keine Reviews von Designkollegen, keine etablierten Prozesse, auf die ich hätte aufbauen können. Alles musste ich mitbringen oder aufbauen.
01
Discovery & Bestandsaufnahme
Gespräche mit Geschäftsführer und Entwicklern, eigene Durchläufe durch das bestehende System, Fragen gesammelt, Schwachstellen dokumentiert, bevor ich eine einzige Lösung skizziert hatte.
02
User Research von Null
Ich habe strukturierte Nutzerbefragungen konzipiert und durchgeführt. Das erste Mal in der Unternehmensgeschichte. Painpoints, mentale Modelle, Workflow-Muster: direkt aus den Gesprächen mit echten Anwendern.
03
Design System aufbauen
Aufbau einer vollständigen Design-Grundlage: Design Tokens, Komponentenbibliothek, Dokumentation — so strukturiert, dass Entwickler ohne Design-Background damit arbeiten konnten.
04
Dev-Onboarding & Tooling
Einführung von Figma im Team. Was ist ein Component? Was ist ein Token? Wie arbeiten wir zusammen, ohne ständig aneinander vorbeizureden?
05
Prozesse & Meeting-Struktur
Einführung von regelmäßigen, strukturierten Design-Meetings: kein Brainstorming ohne Agenda, keine Entscheidung ohne Grundlage. Zum ersten Mal gab es einen gemeinsamen Rhythmus.
06
Stakeholder-Überzeugungsarbeit
Mit Daten und Research überzeugen, dass gutes UX nicht „größere Buttons" bedeutet — sondern Struktur, Kontext und Nutzerverständnis.
Vorgehen
(K)ein sauberer Prozess
Die folgenden Phasen sind ein Orientierungsrahmen, keine saubere Abfolge. In der Praxis liefen Discovery und erste Konzepte parallel, während Teile des alten Systems noch in Betrieb waren. Research fand statt während ich schon erste Strukturvorschläge machte. Das ist die Realität eines lebenden Produkts, das weiterentwickelt wird während es läuft.
Phase 01
Discovery
Stakeholder-Interviews, Bestandsanalyse, technische Constraints, Marktkontext. Alles, was Architektur braucht, bevor sie beginnt.
Phase 02
Informationsarchitektur
IA-Mapping, User Journey Design, System Flows, Entscheidungsrahmen für alle Teams. Der Blueprint, auf den sich jede Designentscheidung bezieht.
Phase 03
User Research & Validierung
Konzeption und Durchführung qualitativer Research-Formate mit internen Stakeholdern und Pilot-Usern. Ableitung konkreter Architekturentscheidungen aus Nutzerfeedback.
Phase 04
Validierung & Iteration
Regelmäßige Validierungsschleifen mit echten Usern. Architekturentscheidungen anpassen, ohne die Gesamtstruktur zu destabilisieren.
Phase 05
Handoff
Engineering-nahes Handoff, Begleitung während der Implementierung, kontinuierliche Design-QA bis zum produktiven Release.
Ongoing
Governance & Enablement
Architektonische Konsistenz sicherstellen, Design System weiterentwickeln — Teams enablen, nicht kontrollieren.
Architektur Deep Dive
Eine der komplexesten Anforderungen des Projekts ist die Konzeption eines modulübergreifenden Versionierungssystems. Entwickelt in enger Zusammenarbeit mit dem Team, mit meiner fachlichen Initiative als Ausgangspunkt.
„Wie Excel: Wenn ich fertig bin, speichere ich ab, lege es in einen Ordner — und der Nächste kann darauf aufbauen."
Diese intuitive Metapher war der Ausgangspunkt. Das Ergebnis war ein durchdachtes Versionierungsmodell, das Meta-Daten, Inhalte und Modulabhängigkeiten koordiniert — und dabei sicherstellt, dass ein versionierter Stand verbindlich und gleichzeitig Grundlage für das jeweils nächste Modul ist.
Versionierter Stand = Bindend
Eine abgeschlossene Version eines Moduls ist unveränderlich. Sie bildet die verbindliche Datenbasis für alle nachfolgenden Module — ähnlich einem freigegebenen Dokument, auf das referenziert, aber nicht rückwirkend eingegriffen wird.
Modulare Referenzierung
Nachfolgende Module können auf freigegebene Inhalte vorheriger Module zugreifen und diese referenzieren — aber nur auf die jeweils aktuellste freigegebene Version. Kein implizites Überschreiben, keine stillen Änderungen.
Meta-Daten als Klammer
Meta-Daten umschließen alle Module und Versionen. Aktualisierungen der Meta-Daten fließen kontrolliert in das System ein, ohne bestehende Versionshistorien zu korrumpieren.
Externer Input: Aktiv einarbeiten
Externe Daten werden nicht automatisch übernommen. User aus Modul 2 müssen externe Inhalte aktiv in den Arbeitsprozess integrieren — so bleibt die Kontrolle dort, wo sie hingehört.
Artefakt — (Fachliche) Datenfluss-Architektur
Systemarchitektur: Datenfluss über vier Ebenen — Extern (Input und Datenimport), Meta-Daten und Module. Modul 1–3 zeigen Input-, Process- und Output-Strukturen mit jeweiligen Metadaten-Schichten.
Das Compliance-Problem in Modul 2
In der ursprünglichen Struktur waren in Modul 2 unterschiedliche Nutzergruppen unterwegs — mit fundamental verschiedenen Berechtigungen und Verantwortlichkeiten. Einige dieser User hatten keine Entscheidungsbefugnis, operierten aber im selben Modul wie jene, die Versionen freigeben durften.
Das erzeugte ein strukturelles Compliance-Problem: Wer darf einen Stand als verbindlich markieren? Wer sieht welche Daten? Wie verhindert man unbeabsichtigte Freigaben durch die falsche Nutzergruppe?
Das erzeugte ein strukturelles Compliance-Problem: Wer darf einen Stand als verbindlich markieren? Wer sieht welche Daten? Wie verhindert man unbeabsichtigte Freigaben durch die falsche Nutzergruppe?
Meine Initiative
Ich habe vorgeschlagen, Modul 2 strukturell aufzuteilen und die Nutzergruppen in separate Bereiche zu separieren. Damit ist klar: Wer entscheidungsbefugt ist, arbeitet in einem dedizierten Kontext. Der externe Teil muss aktiv durch die berechtigten User aus Modul 2 eingearbeitet werden — keine automatische Übernahme, keine Compliance-Grauzone.
So funktioniert die Versionierung der Module ohne Berechtigungskonflikte, und jeder versionierte Stand ist eindeutig einem verantwortlichen Nutzerkreis zuordenbar.
Artefakt — Versions-Orchestrierung
Versions-Orchestrierung: Versionsstände V1.0 bis V2.x mit Modulreferenzierungen. Nur aktuelle Inhalte werden versioniert. Nachfolgende Module referenzieren freigegebene Inhalte der Vorgängermodule — nie implizit, immer kontrolliert.
Compliance by Design: Durch die Trennung der Nutzergruppen in Modul 2 wurde Compliance nicht als nachträgliche Regel, sondern als strukturelles Merkmal der Architektur implementiert.
Klare Verantwortlichkeiten: Jeder versionierte Stand ist einem eindeutigen, berechtigten Nutzerkreis zuordenbar. Freigaben sind nachvollziehbar und nicht versehentlich möglich.
Skalierbare Modulstruktur: Die Versionierungslogik funktioniert unabhängig davon, wie viele Module künftig hinzukommen — die Referenzierungslogik bleibt konsistent.
Der Impact
Skalierbarkeit & Konsistenz
Spezifische Metriken unterliegen der Vertraulichkeit. Die folgenden Outcomes beschreiben die strukturellen und qualitativen Ergebnisse der Architekturarbeit.
███%
Verbesserung der Benutzerfreundlichkeit
Signifikant bessere Usability-Scores gegenüber dem Vorgängersystem (NDA-geschützt).
7+
Teams aligned
Alle crossfunktionalen Teams arbeiten eigenständig und konsistent auf Basis der gemeinsamen Architektur – Design als Enabler, nicht Flaschenhals.
███%
Stakeholder-Effizienz
Wiederkehrende Abstimmungskonflikte zwischen Business und Tech wurden durch klare Architekturentscheidungen strukturell gelöst (NDA-geschützt).
Reflexion
Meine Erkenntnisse
Dieses Projekt hat mein Verständnis von Product Architecture als Disziplin grundlegend geschärft. Es ist nie nur Struktur — es ist immer auch Kommunikation, Vertrauen und die Fähigkeit, Komplexität in Klarheit zu überführen.
In einem Umfeld wie amplimind, das bewusst zwischen Startup-Mentalität und Enterprise-Anforderungen navigiert, muss ein Product Architect beides können: schnell denken und gründlich dokumentieren. Entscheiden und erklären.
Index
LEBENSLAUF