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
100%
Eigenentwicklung
Full-Stack-Lösung
2 Jahre
Projektlaufzeit
Komplette Neuentwicklung
>10.000
Teilnehmer pro Event
im Durchschnitt
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 und hin zu einem System, das man gerne benutzt.
Die Herausforderung
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 Stakeholder, die überzeugt werden wollten, 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
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
Es gab keinen linearen Ablauf. Kein klares „erst Research, dann IA, dann Design System." Fundament, Design-Grundlage und Produktarbeit mussten gleichzeitig entstehen, während das System weiterlief und neue Anforderungen hereinkamen.
Discovery und erste Konzepte liefen 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.
Deep Dive
Die bestehende Navigation war eine klassische Side-Navigation, gewachsen über Jahre, Feature für Feature. Das Ergebnis war ein riesiger Navigationsbaum, der vor allem für Nutzer mit vielen Berechtigungen unüberschaubar wurde. Je mehr jemand sehen durfte, desto unübersichtlicher wurde es.
Das System bediente vier grundlegend verschiedene Nutzergruppen: interne Entwickler bei EventClass, Organisatoren, Externe und Teilnehmer. Die ersten drei teilten dieselbe Grundoberfläche, sichtbar oder unsichtbar geregelt über ein komplexes Berechtigungssystem. Was auf der Oberfläche wie eine einheitliche Anwendung wirkte, war darunter ein Geflecht aus Rollenlogiken.
Der Teilnehmerbereich war ein eigenes Kapitel: Ein Hybrid aus Mail-Versand, Altsystem und einer extra entwickelten App, die noch in den Kinderschuhen steckte. Auch hier gab es viele Unterrollen — Besucher, Vortragende und weitere — mit jeweils unterschiedlichen Bedürfnissen und Zugängen.
Artefakt — Neue Struktur
Der wendepunkt
Die erste strukturierte Nutzerbefragung war ein Schlüsselmoment. Plötzlich hatten wir nicht nur Meinungen: Wir hatten Daten. Entwickler, die vorher intuitiv nach eigener Logik gebaut hatten, sahen zum ersten Mal, wie ihre Nutzer wirklich mit dem System interagierten. Das veränderte die Gesprächskultur im Team grundlegend.
Methoden angepasst an die Realität
Formale Methoden wurden dort eingesetzt, wo sie wirklich etwas brachten und konsequent angepasst, wo sie nicht passten.
Card Sorting wurde intern mit dem Entwicklungsteam durchgeführt, nicht primär als klassische IA-Methode, sondern weil es geholfen hat, sichtbar zu machen, wie viel eigentlich passiert. Für viele im Team war es das erste Mal, dass die Komplexität des eigenen Systems auf einem Tisch lag.
Mit den direkten Anwendern, vor allem im Organisator-Kontext, arbeitete ich mit einem Schulterblick-Ansatz: lautes Denken, Aufgaben live durchführen und gleichzeitig kommentieren. Keine Fragebögen, sondern direktes Arbeiten mit den Menschen, die täglich damit umgehen mussten.
Zu den Teilnehmern gab es keinen direkten Zugang, da dieser Kontakt über die Organisationen lief. Als Ersatz wurden strukturierte Steckbriefe entwickelt und intensiv mit den Kolleginnen und Kollegen aus dem Live-Support gearbeitet, die bei Veranstaltungen direkt mit Teilnehmern telefonierten und deren Probleme und Fragen aus erster Hand kannten.
Die zentrale Entscheidung, die ich in diesem Projekt stark vorangetrieben habe: eine modulare Architektur.
Statt einer einheitlichen Oberfläche mit Berechtigungen, die Teile davon ein- oder ausblenden, entstand ein System, das für verschiedene Nutzergruppen tatsächlich unterschiedliche Oberflächen erzeugen kann. Wer als Vortragende in eine Veranstaltung eingeloggt ist, sieht eine andere Welt als eine Organisatorin. Nicht weil etwas versteckt wird, sondern weil die Architektur von Anfang an auf diese Trennung ausgelegt wurde.
Das war keine selbstverständliche Entscheidung. Aber sie war die Grundlage dafür, dass das System skalierbar, wartbar und für alle Nutzergruppen tatsächlich benutzbar werden konnte.
Der Impact
Das Produkt ist live und wird aktiv genutzt: Weltweit, bei wissenschaftlichen Organisationen, Forschungsinstituten und internationalen Großkongressen. Die Ergebnisse sprechen für sich.
70%
Weniger Customization-Kosten
10
Tage Time-to-Market
Vorher: 8 Wochen. Das modulare System erlaubt neue Features ohne Eingriff in die Kernarchitektur — Deploy ohne Regression.
350%
mehr Deployments
Die neue Architektur hat die Release-Frequenz mehr als verdreifacht. Neue Module können deployt werden, ohne die Kernstruktur zu berühren.
Reflexion
Bei EventClass habe ich verstanden, dass Design-Arbeit in einem Unternehmen ohne Design-Tradition zu einem großen Teil Überzeugungsarbeit ist. Nicht im Sinne von Verkaufen, sondern im Sinne von gemeinsam ein neues Verständnis entwickeln.
Die technischen Deliverables — Design System, Tokens, Komponenten — waren das sichtbare Ergebnis. Das unsichtbare Ergebnis war wichtiger: Ein Team, das heute weiß, warum man Nutzer befragt, bevor man baut.
Index