Merging consent tools into one suite to setup GDPR compliant VW applications.
Consent sounds simple from the outside: ask a user for permission and store their answer.
Consent management in Volkswagen ecosystem had evolved into a suite of four interconnected internal tools, used by different people at different stages of the process, from developers integrating consent into products to legal owners maintaining the documents behind it.
As GDPR requirements evolved, the system needed to become easier to understand, safer to operate and more consistent across Volkswagen Group brands.
I worked on bringing clarity to that ecosystem, starting with the developer experience and gradually addressing the workflows, roles and dependencies surrounding it.
*To comply with my non-disclosure agreement, I have omitted and obfuscated confidential information in this case study. All information in this case study is my own and does not necessarily reflect the views of Volkswagen.
Year
March 2022 - December 2023
Client
Cariad - Volkswagen Group Company
Role
Product Designer, Consent cluster
Work
Research, domain modelling, product
and interaction design, IA, design system
components, testing, handover docs
Team
Business Owner, Product Owner,
product manager, 2 front end developers,
2 backend developers,
designer (me)
What difference did we make?
Current state
What prompted us to reimagine the workflows?
Fragmentation
Configuring consent for one application took multiple roles and they had 0 to no transparency into each other's workflows.
Nothing in the chain could see the chain. The developer couldn't tell whether the client IDs they had generated already carried scopes and purposes in Consent Self-Service. The product owner couldn't confirm the client IDs were created in the right application, they just saw them sitting in a pile marked ungrouped.
The trigger was organisational. The Developer Portal: the first, mandatory step for integrating IDKit was moving into the Consent team. That gave us a rare opening: to look at the whole path from zero to go-live as one thing, and ask why it cost so much to walk it.
Research
How seamless is the current experience?
We mapped it end to end to understand every product interaction within and outside consent cluster.
Design language
Four tools, four vocabularies, four design systems. Every tool had its own interface and was very difficult to find connection to the previous tool in the roadmap.
Data model structure
The model connecting the four products existed on nobody's screen. When we dreew the data model during research, the team had to rely on integrators to explain. If people building it cannot see the structure clearly, the user is guessing by definition.
Consequences
When a step failed there was no way to tell whether you had made a mistake or the system had, so people stopped trusting the screen and asked a human instead.
When the screen can't be trusted, people ask a human instead. The team becomes the interface.
Every VW brand integrating IDKit and arrived at support with the same questions. "I created an application but still can't generate client ids."
06 - Regrounding the research
Our old personas have expired.
The discovery work I inherited was thorough — journey maps, a data model, a roles audit. It was also two years old, and the product it described had moved. Before designing against personas I hadn't met, I went back and interviewed [N] people across [roles / brands] to find out who was actually using these tools now.
[What changed at the highest level — one or two sentences. The version of the user in the old research vs. the one who showed up in the interviews.]
03 — The approach
One shared model, then one shared surface.
We started by mapping every consent state into a single model the four teams could agree on. Only then did we design the interface — a calm, dense console that let operators move through a full case without ever leaving the screen.
Fig. 2 — The unified One.Console workspace.
What can we do?
The north star was one suite; a single surface where identity, consent, and legal text share one model and one language. And with introduction of Developer Portal to the cluster, we decided to investigate how welcoming developer portal could help solving some serious user and business pains and additionally resolve some security issues.
04 — Process
01
Form a hypothesis
If we create a starting point from Developer portal and create better flows around it, we can guide user from 1 tool to another without overwhelming them.
02
Align on the questions that drive us.
Rewrote the state machine so every team spoke the same language.
03
Map expectations
Prototyped the console in-browser and tested it with real operators.
04
Define success.
Migrated the four tools behind a single surface, with zero downtime.
05 — Outcome
One console, adopted across every market.
Within two quarters the four legacy tools were retired. Operators moved faster, compliance reviews stopped catching mismatched states, and the shared model became the backbone other teams began to build on.
Fig. 3 — Live monitoring across markets, one shared surface.