Index
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
2024 – Present
As Product Design Architect, I lead the structural end-to-end design of a comprehensive enterprise software platform — from information architecture and design system to cross-team coordination and strategic alignment across all stakeholders.
Product Architecture
UX Strategy
Design System
Enterprise IT
Automotive / Mobility
Agile
Cloud Platform
7+
Cross-functional Teams
Aligned on one product vision
███
Project Duration
NDA-protected
Context
amplimind is a joint venture between AUDI AG and Lufthansa Industry Solutions based at LabCampus Munich. The company combines automotive expertise with modern cloud and software engineering.
The guiding principle is the so-called "4i Software": intuitive, individualized, innovative, and integrated with the clear ambition to reimagine enterprise processes in a user-centered way.
In this environment — startup spirit, enterprise stakes — I was brought in as Product Design Architect for a strategically significant project whose specific details are under the strictest confidentiality.
This case study describes the methodology, role, and outcomes without disclosing sensitive project information.
The Challenge
The project addresses a multi-layered organizational and technical problem in the enterprise context. The core task is to design a new digital platform from scratch — both architecturally and in terms of UX — with strict requirements around security, scalability, and user acceptance.
The central challenge is developing an adaptive architecture that serves two fundamentally different worlds: a lean, user-friendly interface for operational end users, and a data-intensive backend for process owners, all while complying with the strict compliance requirements of a global corporation.
Heterogeneous Stakeholders
Business units, IT teams, compliance, and end users with partly conflicting requirements must be united in a coherent product vision.
Missing Design Language
A consistent design system needed to be built from scratch. Every feature decision first required an architectural foundation.
Technical Complexity
Strict cloud security standards, legacy integration, and requirements must be translated into a user-centered architecture.
Agile Scaling
Cross-functional teams must be aligned to a unified product vision and continuously supplied with architectural decisions.
My Role
My role combines strategic thinking with concrete design work, at the intersection of vision and implementation, between stakeholder management and component-level design decisions.
I operate within a specialized expert team of three designers. We work as equals, each contributing their specific depth to holistically map complex business requirements.
Our shared focus is strictly on business value: every decision is made in the balance between organizational goals, technical feasibility, and the highest user acceptance at enterprise scale.
01
Information Architecture & System Design
Structuring the entire product architecture: navigation, data hierarchies, user flows, and mental models: from whiteboard to validated IA blueprint.
02
Design System Conception & Governance
Building a scalable design system as an extension of an existing external design system: token structure, component library, documentation standards, and team guidelines for consistent implementation.
03
User Research & Validation
Designing and conducting qualitative research formats with internal stakeholders and pilot users. Deriving concrete architectural decisions from user feedback.
04
Teamübergreifende Koordination
ridging engineering, product management, UX, and business: facilitating architecture reviews, design critiques, and decision workshops.
05
Prototyping & Concept Validation
Creating highly detailed interactive prototypes for usability tests and stakeholder alignment — from lo-fi sketches to high-fidelity flows.
06
Product Strategy Support
Direct contribution to product strategy: feature prioritization, OKR support, and roadmap visualization for C-level presentations.
Process
Phases like these are never cleanly separable. Some run in parallel, some take more time than expected. And that is intentional. Parts of the product were already in development while others were still being conceived. A good architectural approach must handle this: dynamic enough for a living product, consistent enough to guide teams.
Phase 01
Discovery
Stakeholder interviews, existing system analysis, technical constraints, market context. Everything architecture needs before it begins.
Phase 02
Information Architecture
IA mapping, user journey design, system flows, decision frameworks for all teams. The blueprint that every design decision refers back to.
Phase 03
User Research & Validation
Designing and conducting qualitative research formats with internal stakeholders and pilot users. Deriving concrete architectural decisions from user feedback.
Phase 04
Validation & Iteration
Regular validation loops with real users. Adjusting architectural decisions without destabilizing the overall structure.
Phase 05
Handoff
Engineering-close handoff, support during implementation, continuous design QA through to production release.
Ongoing
Governance & Enablement
Ensuring architectural consistency, continuously evolving the design system — enabling teams, not controlling them.
Architecture Deep Dive
One of the most complex requirements of the project is the design of a cross-module versioning system. Developed in close collaboration with the team, with my professional initiative as the starting point.
This intuitive metaphor was the starting point. The result was a well-thought-out versioning model that coordinates metadata, content, and module dependencies — ensuring that a versioned state is both binding and the foundation for each subsequent module.
Versioned State = Binding
A completed version of a module is immutable. It forms the authoritative data basis for all downstream modules, similar to a released document that can be referenced but not retroactively modified.
Modular Referencing
Downstream modules can access and reference released content from prior modules, but only the most recently released version. No implicit overwriting, no silent changes.
Metadata as a Wrapper
Metadata wraps all modules and versions. Updates to metadata flow into the system in a controlled manner without corrupting existing version histories.
External Input: Active Integration
External data is not automatically adopted. Users from Module 2 must actively integrate external content into the workflow — keeping control where it belongs.
Artifact — (Technical) Data Flow Architecture
System architecture: Data flow across four levels — External (input and data import), metadata, and modules. Modules 1–3 show input, process, and output structures with their respective metadata layers.
Compliance Problem in Module 2
In the original structure, different user groups operated within Module 2, with fundamentally different permissions and responsibilities. Some users had no decision-making authority but operated in the same module as those who were authorized to release versions.
This created a structural compliance problem: Who is allowed to mark a state as binding? Who sees which data? How do you prevent accidental releases by the wrong user group?
My Initiative
I proposed splitting Module 2 structurally and separating user groups into distinct areas. This makes it clear: those with decision-making authority work in a dedicated context. External input must be actively integrated by authorized Module 2 users: No automatic adoption, no compliance grey area.
This allows module versioning to function without permission conflicts, and every versioned state is clearly attributable to a defined, authorized group of users.
Artifact — Version Orchestration
Version orchestration: Versions V1.0 to V2.x with module references. Only current content is versioned. Subsequent modules reference released content from predecessor modules—never implicitly, always in a controlled manner.
Compliance by Design: By separating user groups in Module 2, compliance was implemented not as a retroactive rule, but as a structural characteristic of the architecture.
Clear Accountability: Every versioned state is attributable to a clearly defined, authorized group of users. Releases are traceable and cannot happen accidentally.
Scalable Module Structure: The versioning logic works regardless of how many modules are added in the future and the referencing logic remains consistent.
The Impact
Specific metrics are subject to confidentiality. The following outcomes describe the structural and qualitative results of the architecture work.
███%
Usability Improvement
7+
Teams aligned
All cross-functional teams work independently and consistently based on the shared architecture — design as enabler, not bottleneck.
███%
Stakeholder Efficiency
Recurring alignment conflicts between business and tech were structurally resolved through clear architectural decisions (NDA-protected).
Reflection
This project has fundamentally sharpened my understanding of product architecture as a discipline. It is never just structure, it is always also communication, trust, and the ability to translate complexity into clarity.
In an environment like amplimind, which deliberately navigates between startup mentality and enterprise requirements, a product architect must be capable of both: thinking fast and documenting thoroughly. Deciding and explaining.