One Console

OneConsole

Redesigned key user flows in the user consent management tool, resulting in a projected 34% reduction in support requests and generating strong adoption interest from three major Volkswagen brands.

Background

Consent Management is a core part of Volkswagen's Identity Kit (IDK) Suite, managing user permissions and enforcing GDPR-compliant access in real time. Handling millions of consents daily, it’s vital to Volkswagen’s operations. The system includes four tools used by Integrators, Product Owners, Business Owners and Developers.

Challenges

1/ Flood of support requests

The lack of dedicated Designer in the team led to ad hoc feature additions by Developers, resulting in broken workflows, inconsistent UX, and overwhelming support requests. This adversely affected the productivity of Developers and left users frustrated and dependent on help.

2/ Extra permissions but missing control

The roles management system was inadequate. Developers had to either over-assign roles thereby risking security or hard-code additional permissions, increasing backend dependency and reducing control for business stakeholders.

Goals

1/ Reduce support requests and improve user satisfaction

by redesigning the Consent Management tools to deliver a consistent, intuitive experience and streamline broken workflows

2/ Build a new, secure Roles & Permissions model

that supports granular control through two levels
1. Access Group for senior stakeholders (e.g. Business Owners)

2. Application Level for middle management (e.g. Product Owners, Integrators)

My Role

Product Designer, Hexad GmbH

Duration

August 2022 - March 2023

Team

Product Owner, Business owner (VW Germany), Integrators (External Company)
5 Developers, 1 Product Manager, 2 Designers (Hexad GmbH)

Key Tasks

In collaboration with the second Designer

UX Audit, led workshops to validate proto-personas and define Roles & Permissions model, problem prioritisation

As the solo Designer

Defined workflow, created wireframes, ran design reviews, conducted usability testing and iterations, delivered high-fidelity designs, design handoff

Impact

I redesigned key user flows in the Consent Management tool, leading to a projected 34% drop in support requests and sparking strong interest from three major Volkswagen brands to adopt the improved workflows.

As one of the dedicated designers on the team, I led efforts to establish a structured design process introducing clear criteria like the Definition of Ready and Definition of Done for design tickets, and co-developing a strategy to manage ad hoc requirements. This helped the team better understand the hygiene needed when creating design tickets, reducing confusion and rework. The ad hoc strategy also enabled us to evaluate requests based on their alignment with prioritized problems, ensuring more focused and impactful design effort.

Analysing the existing design

My design teammate and I started by assessing the existing designs of all four tools. We fully immersed ourselves trying out tasks in the sandbox environment, digging through dense documentation, constantly checking in with Developers (who were absolute lifesavers!), gradually uncovering key areas where the design could be improved. We also worked closely with them to review support requests they had received over the past three months via email, Slack, and Teams to get insights into what users were complaining about.

Through UX Audit, we found several opportunities of improvement in the tools. Our next goal was to collaborate with the stakeholders to share our findings, identify any missed edge cases, and build a shared understanding of user needs. To be honest, getting all stakeholders in one single platform was one of they main challenges in this project; We facilitated a Proto-Persona workshop with one Product Owner, one Business Owner, two Integrators, and two Consent Developers. Together, we reviewed and critiqued the existing personas to determine what was still relevant, what was outdated, and what new expectations had emerged with the shift to a unified tool.

Broken Flows at the Heart of Consent Management

At the start, stakeholders assumed redesigning and merging all four Consent Management tools into OneConsole would reduce support requests. However, from the research it was clear that while every tool had its own set of issues, the real blockers were in the first two: Application Management and Permissions Configuration. These were the entry points to the entire flow, if users couldn’t create an Application or generate a Client ID, they couldn’t proceed. The confusion here was a major contributor of support requests. So instead of redesigning everything at once, we prioritized these two tools to solve the most critical issues first.

High level consent management user flow (1).png

A deep dive into the problems

1/ Unclear Feature Dependencies delaying Client ID creation

Adding Features to an Application was a critical step for generating Client IDs, but the flow was unclear and often confusing.
Feature dependencies weren’t clearly communicated, and users had no actionable guidance when issues were flagged.
Overwhelming, text-heavy documentation made it hard to resolve errors, leading to frequent support requests.

2/ Access Control Gone Wrong

Integrators were auto-assigned as Super Admins when creating Applications, adding unwanted access management tasks to their technical workload.
Due to limited permission controls, some users had to be given Admin access in certain Applications, while others relied on developers manually hard-coding permissions. This resulted in frequent support requests, security risks, and increased maintenance effort.
Business users lacked visibility across Applications, unless manually added, leading to delays and potential compliance issues

3/ Risky Toggles without approval process

Integrators were often confused about deploying Client IDs from Sandbox to Production, a critical step in going live with applications.
The existing toggle-based design lacked safeguards ; no confirmation, no status feedback, and no audit trail to track changes, making it risky and error-prone.
Ungrouped Client IDs created security and compliance concerns, as there was no clear ownership or structure to manage access.

User Profiles

Through our research, it became clear that different user roles had distinct needs within OneConsole. Integrators acted as the doers, handling hands-on tasks like creating Client IDs and Applications as part of their daily workflow. In contrast, Product Owners and Business Owners were focused on oversight and decision-making.

Design Explorations

CHALLENGE 1

How might we simplify the user flow of adding Features to Applications, so users can complete it confidently without confusion?

My design explorations focused on exploring multiple directions for adding Features in Applications; ranging from entirely new concepts to iterations that built on the existing design. I shared the ideas with the team to get their input on constraints and figure out together which direction made the most sense.

Contextual Help

A contextual help widget or chat assistant will be embedded within the Features List page to guide users who are unsure about which Features to select for generating Client IDs. This allows them to ask questions and receive support without leaving the workflow.

The Decision

We decided to explore Concepts 3 and 4 as they built on the existing design. This allowed the development team to leverage existing data to recommend or auto-add prerequisite features, making the solution technically feasible while ensuring a familiar experience for users.

Concept 1 was dropped as the value didn’t justify the cost of building a contextual help. The team liked Concept 2, but it required a complex outcome-based AI recommendation system, which we decided to explore in the future.

USABILITY TESTING

Guided selection versus Auto-add

I wasn’t certain which of the two concepts out of Concept 3 and 4 (guided prompt vs. auto-add ) would work better with users, so I decided to test both. I conducted usability testing with six Integrators having different levels of experience, our primary users involved in the Application and Client ID generation process.

Guided prompt

In this version, when users attempted to add a feature with dependencies, the system prompted them to first select the required pre-requisite features.The assumption was that this prompt would guide users, clarify the process, and reduce confusion around feature dependencies.

What Users liked

Users preferred Version 1 - Guided Prompt for giving them control over selecting prerequisites

Highlighting pre-requisite and recommended features simplified decision-making during selection..

What Users struggled with

Version 2 - Automatic feature addition caused confusion and anxiety.

Tick mark wasn't enough feedback that feature was added -> explicit Add/ Remove names for buttons

Users expected Features to get added after clicking on 'Add' button and not a modal -> rename the button

Users had difficulty tracking selected Features when they were spread across multiple scrollable pages -> give users possibility to review selected Features

Final Design

Essential vs. Advanced categorization helps users prioritize setup by clearly highlighting prerequisites.

Smart recommendations guide users to add required features first, reducing confusion and streamlining decision-making

Built-in warnings proactively inform users of the consequences when deleting essential features preventing accidental errors

CHALLENGE 2

How might we create a flexible roles and permission system that still ensures the right level of access?

1/ Conceptualization of roles and permissions model

Everyone was aware of the problems with the existing roles and permissions setup, but no real solution had taken shape. The main reason was the constant back-and-forth between business stakeholders and the technical team; proposals would be made, but often turned out to be unfeasible from a user experience or technical standpoint. These discussions only happened during scattered meetings or calls, often without all the key people present, and there was no documentation to keep track of decisions or ideas.

As designers, we knew we couldn’t move forward without first understanding what the team actually wanted from a new Roles & Permissions model. So I initiated and led a workshop to bring all stakeholders together in one space. The goal was to collaboratively define a clear roles and rights structure that could serve as a shared foundation for both design and development moving forward.

Alignment of technical, design, and business stakeholders on roles and responsibilities

Defined a foundational Roles & Permissions model to guide design and development

Introduced a Role-based Access model with:

Default (hardcoded) permissions tied to each role

Additional (optional) permissions assignable in specific use cases

The workshop brought together a cross-functional group: 4 developers, 1 Product Owner, 1 Business Owner, 2 Integrators, 1 Product Manager, and 2 Designers (including myself) who facilitated the session and captured insights. The focus was on aligning around the responsibilities of key user roles in the new Roles & Permissions model. Through collaborative activities, the team explored how they envisioned the model to work and worked together to begin conceptualizing its structure and behavior.

2/ Structuring the First Build

Once the Roles and Rights model was aligned, I translated it into high-level user flows covering key phases in One Console - user onboarding, Access Group creation, and Application setup. These flows captured steps like role allocation, approvals, and permission changes, highlighting role involvement and dependencies.
This helped the team align on MVP priorities for this new concept and identify what could be tackled in future iterations.

3/ The Design

Once we aligned on the prioritization of features for the Roles and Permissions model, I moved on to translating the roles and rights table and user journey into wireframes. This was a quite challenging phase as it wasn’t just a redesign but it was a completely new concept we were building from the ground up. What truly shaped this phase was close collaboration with the Tech team and business stakeholders. Together, we went through multiple iterations of the flows and wireframes, asking - is this layout considering user context? Should this trigger a warning or an approval? is this possible to implement within the timeline? etc etc etc

The final design is split into two parts: Role Management and Permissions Management

Permissions management is the highlight of the new Roles & Permissions model, offering a more controlled and flexible way to manage access at both the Access Group and Application levels.

Clear separation of access:
Permissions are split into Default (fixed per role) and Additional (customizable per user), giving Admins clear visibility into what can and cannot be changed

Granular control without role escalation:
Admins can assign Additional permissions for specific cases without changing the user’s role avoiding over-permissioning and reducing security risks.

Tighter control and better compliance:
Only Admins and Super Admins can now manage permissions, rather than any application creator strengthening governance and aligning with compliance needs.

All new users are assigned the Member role by default which is a base role with the minimum permissions needed for critical tasks like Client ID generation and Application creation.

Flexible Permission Model Without Role Switching:

Unlike the previous system that required role changes for edge cases (leading to over-permissioning and security risks), the new model allows users to retain the same role across Applications.
Role upgrades can now happen only:

During onboarding (user request)
Through My Profile or by Consent Team Developers

Customizable Additional Permissions (covered in the next section) ensure flexibility without compromising security, while also simplifying backend maintenance.

CHALLENGE 3

How might we ensure critical decisions are safeguarded by an approval process to prevent unintended changes?

A key use case that required Super Admin approval was when Integrators pushed Client IDs from the Sandbox to the Production environment. In the new design, this action automatically triggers an approval request to Super Admins. To reduce uncertainty, Integrators now receive visual feedback through clear status labels; Approved and Live, Pending, or Rejected giving them confidence and clarity during deployment.

The Outcome

Streamlined Client ID and Application creation process, empowering users
Flexible, secure role-based permissions with granular access control
Built-in approval workflows at critical decision points
Consistent, modern UI aligned with VW’s B2B design system
Defined design process with clear Definition of Ready and Done for design tasks
Improved designer-developer collaboration for handling ad-hoc requests strategically
Projected 34% drop in support requests; strong adoption interest from 3 major VW brands

Complex and unintuitive flow for creating Client IDs and Applications which were the most important preliminary steps in the Consent Management process
Rigid roles and permissions model led to over-permissioning and security risks
No approval workflows for key decisions involving higher-level management
Inconsistent UI due to lack of dedicated design support; developers handled design without following VW's B2B design system
Frequent ad-hoc support requests from brands with unclear requirements led to rushed, non-strategic solutions

Learnings

1. Designing for familiarity and confidence - learned that users of complex internal B2B tools like Consent Management are often hesitant to accept major workflow changes, even if the redesign improves efficiency. This resistance usually comes from concerns about the learning curve. As a designer, I had to put aside some of my preferred solutions in favor of what felt more intuitive to users. I kept the more advanced proposals in reserve for future iterations, once users grew confident with the redesigned experience.

2. Embracing Tradeoffs for Impact - In a complex project with common ad-hoc requirements and shifting priorities, aiming for perfection isn't always practical. We prioritized solving high-impact problems and accepted "good enough" solutions for lower-priority issues. This strategic focus ensured we delivered meaningful user and business value, while planning to revisit less critical areas in future iterations.

More Projects

One Press

Project Runway

Redesigning Myntra