Confidentiality & Scope:
This project is subject to a strict Non-Disclosure Agreement (NDA). This case study focuses on UX strategy, information architecture, and product architecture methodology. All original brand elements, project names, specific client data, and internal logic have been abstracted to protect the intellectual property of all parties involved.
Case Study
EventClass GmbH (Dresden)
2022 – 2024
As the sole designer, I didn't just redesign a product at EventClass — I introduced design as a discipline into a purely developer-driven company. From the first user interview to a live system deployed worldwide.
Lead Designer (Solo)
Product Design
Design System
User Research
B2B SaaS
Event Management
Design Culture
100%
In-house development
Full-stack solution
2 Years
Project duration
Completely new development
>10.000
participants per event
on average
Context
EventClass GmbH from Dresden has been developing event management software for years, deployed worldwide at scientific organizations, research institutes, and major conferences, including institutions such as TU Dresden and conferences affiliated with Fraunhofer or Max Planck.
The product had grown over years: feature by feature, year by year, always driven by developers who know their craft, but who never built it through the eyes of the users.
The result: software that works technically, but whose user guidance follows backend logic rather than the mental model of the people who work with it every day.
The company's goal was clear: rebuild it properly this time. Away from legacy constraints, away from dev logic on the surface and toward a system people actually enjoy using.
The Challenge
On the surface, the task was a redesign. In reality, the true challenge was different: introducing design as a way of thinking and working into a company that had never worked with a designer before.
Words like "Figma," "design system," or "user research" were unknown to the team. There were no tokens, no component library, no structured user interviews and stakeholders who needed to be convinced that the solution wasn't simply "bigger, more colorful buttons."
Years of legacy
The system had grown over many years without an architectural plan or design foundation. Technical debt in the frontend made modern development difficult.
Backend logic on the surface
The user guidance mirrored the database structure, not the way users actually work. What made sense to developers was confusing to organizers and participants.
No design system
No tokens, no component library, no consistent visual language. Every new page was a one-off: hard to maintain, impossible to scale.
No design culture
The team had never worked with a designer. Processes like structured user interviews or design reviews simply didn't exist.
My role
I was the only designer in the company. That meant: no handoffs, no reviews from design colleagues, no established processes to build on. Everything had to be brought in or built from scratch.
01
Discovery & Audit
Conversations with the CEO and developers, my own walkthroughs of the existing system, questions collected, weaknesses documented — before sketching a single solution.
02
User Research from Zero
I designed and conducted structured user interviews. The first time in the company's history. Pain points, mental models, workflow patterns: directly from conversations with real users.
03
Building a Design System
Building a complete design foundation: design tokens, component library, documentation — structured so developers without a design background could work with it.
04
Dev-Onboarding & Tooling
Introducing Figma to the team. What is a component? What is a token? How do we work together without constantly talking past each other?
05
Processes & Meeting Structure
Introducing regular, structured design meetings: no brainstorming without an agenda, no decision without a foundation. For the first time, there was a shared rhythm.
06
Stakeholder Persuasion
Using data and research to make the case that good UX doesn't mean "bigger buttons" — it means structure, context, and user understanding.
Process
There was no linear process. No clear "first research, then IA, then design system." Foundation, design basis, and product development had to be created simultaneously while the system continued to operate and new requirements arose.
Discovery and initial concepts ran in parallel while parts of the old system were still running. Research took place while I was already making initial structural proposals. That's the reality of a living product that evolves while it's running.
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