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
amplimind GmbH — Audi × Lufthansa Industry Solutions (Remote, München)
2024 – Heute
Als Product Design Architect betreue ich das strukturelle End-to-End-Design einer umfassenden Enterprise-Softwareplattform – von der Informationsarchitektur und dem Design-System bis hin zur teamübergreifenden Koordination und der strategischen Abstimmung zwischen allen Stakeholdern.
Produktarchitektur
UX Strategie
Design System
Enterprise IT
Automotive / Mobilität
Agile
Cloud Platform
7+
Cross-functional Teams
Aligned on one product vision
███
Projektlaufzeit
NDA-geschützt
Kontext
amplimind ist ein Joint Venture von AUDI AG und Lufthansa Industry Solutions — angesiedelt am LabCampus München. Das Unternehmen vereint Automotive-Expertise mit modernem Cloud- und Software-Engineering.
Leitprinzip ist die sogenannte „4i-Software": intuitiv, individualisiert, innovativ und integriert — mit dem klaren Anspruch, Enterprise-Prozesse nutzerzentriert neu zu denken.
In diesem Umfeld — startup spirit, enterprise stakes — wurde ich als Product Design Architect in ein strategisch bedeutendes Projekt eingebunden, dessen spezifische Details unter strengster Vertraulichkeit stehen.
Die vorliegende Case Study beschreibt Methodik, Rolle und Ergebnisse, ohne sensitive Projektinformationen preiszugeben.
Die Herausforderung
Komplexität im großen Maßstab
Das Projekt adressiert eine organisational wie technisch vielschichtige Problemstellung im Enterprise-Kontext. Kernaufgabe ist es, eine neue digitale Plattform von Grund auf architektonisch und gestalterisch zu konzipieren — mit harten Anforderungen an Sicherheit, Skalierbarkeit und Nutzerakzeptanz.
Die zentrale Herausforderung besteht darin, eine adaptive Architektur zu entwickeln, die zwei völlig unterschiedliche Welten bedient: ein schlankes, benutzerfreundliches Interface für operative Endanwender und ein datenintensives Backend für Prozesseigentümer – und das alles unter Einhaltung der strengen Compliance-Vorgaben eines globalen Konzerns.
Heterogene Stakeholder
Business-Units, IT-Teams, Compliance und End-User mit teils diametralen Anforderungen müssen in einer kohärenten Product Vision vereint werden.
Fehlende Design-Sprache
Ein konsistentes Design System im Aufbau. Jede Feature-Entscheidung erforderte zunächst eine architektonische Grundlage.
Technische Komplexität
Strikte Cloud-Sicherheitsstandards, Legacy-Integration und Automotive-Anforderungen müssen in eine nutzerzentrierte Architektur überführt werden.
Agile Skalierung
Crossfunktionale Teams müssen auf eine einheitliche Product Vision eingeschworen und kontinuierlich mit Architekturentscheidungen versorgt werden.
Meine Rolle
Product Design Architect
Meine Rolle vereint strategisches Denken mit konkreter Gestaltungsarbeit — an der Schnittstelle zwischen Vision und Implementierung, zwischen Stakeholder-Management und Designentscheidungen auf Komponentenebene.
Ich agiere innerhalb eines spezialisierten Experten-Teams aus drei Designern. Wir arbeiten auf Augenhöhe, wobei jeder seine spezifische Tiefe einbringt, um die komplexen Business-Anforderungen ganzheitlich abzubilden.
Unser gemeinsamer Fokus liegt dabei strikt auf Business-Value: Jede Entscheidung wird im Spannungsfeld zwischen organisatorischen Zielen, technischer Machbarkeit und höchster Nutzerakzeptanz im Enterprise-Maßstab getroffen.
01
Informationsarchitektur & System Design
Strukturierung der gesamten Produktarchitektur: Navigation, Datenhierarchien, Nutzerflüsse und mentale Modelle — vom Whiteboard zum validierten IA-Blueprint.
02
Konzeption und Steuerung des Designsystems
Aufbau eines skalierbaren Designsystems als Erweiterung eines bestehenden externen Designsystems — Tokenstruktur, Komponentenbibliothek, Dokumentationsstandards und Team-Guidelines für konsistente Implementierung.
03
User Research & Validierung
Konzeption und Durchführung qualitativer Research-Formate mit internen Stakeholdern und Pilot-Usern. Ableitung konkreter Architekturentscheidungen aus Nutzerfeedback.
04
Teamübergreifende Koordination
Brückenbau zwischen Engineering, Product Management, UX und Business — Moderation von Architektur-Reviews, Design Critiques und Entscheidungs-Workshops.
05
Prototyping & Konzeptvalidierung
Erstellung hochdetaillierter interaktiver Prototypen für Usability Tests und Stakeholder-Alignment — von Lo-Fi-Sketches bis zu High-Fidelity-Flows.
06
Produktstrategie Support
Direkte Zuarbeit zur Produktstrategie: Feature-Priorisierung, OKR-Unterstützung und Roadmap-Visualisierung für C-Level-Präsentationen.
Prozess
Systemisches Redesign:
Architektur als Fundament
Phasen wie diese sind nie klar trennbar. Manche laufen parallel, manche bekommen mehr Zeit als erwartet — und das ist beabsichtigt. Teile des Produkts waren bereits in Entwicklung, während andere noch konzipiert wurden. Ein guter Architekturansatz muss das aushalten: dynamisch genug für ein lebendes Produkt, konsistent genug, um Teams zu führen.
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