Designing a self-serve configuration system for Volkswagen’s Measures platform
Measures is Volkswagen's internal platform for tracking improvement measures across Environment, Production and Cost Management. It has 26,000 users and more than 50,000 measures, and it has been running since 2011.
I led end-to end design for the Key User Tool, the part of the platform where brand teams create the fields and forms everyone else fills in. It shipped as a self-serve builder with its own logic, permissions and lifecycle rules.
*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
2023-2024
Client
Volkswagen Group
Role
Product Designer, Key User Tool
Work
Research, domain modelling, product
and interaction design, IA, design system
components, testing, handover docs
Team
Product Owner, product manager,
3 front end developers, 2 backend developers,
designer (me)
Solution Preview
Context
Measures isn't just a productivity tool, it's a reporting instrument.
Measures is measuring impact and reporting platform for all Volkswagen brands. The platform was mid-revamp, moving off thirteen years of hard-coded software towards something configurable. Its largest workflow is the forms brands fill in. Key Users own that workflow end to end: they decide which fields exist, brands complete them, and the results are exported to the teams entitled to see them.
Problem
The people accountable for strategy, couldn't build it.
Every field lived in the codebase. Changing one meant writing a specification, escalating to a Super User who also couldn't help, raising a service request, and waiting for a release serving nine brands.
The tool is thirteen years old and very much hard coded, making it difficult to adapt to quick changes.
- Alex, Product Owner, VW Wolfsburg
If the documentation is not checked before adding new fields from request , sometimes brands can end up with duplication of fields and we need to fix them again.
- Deeparam, Developer, VW Pune
What it cost
~50/mo
Strategy related support tickets to engineering team
space for edits directly by key users, every change only through engineering
What is the ideal scenario for our users:
Whenever there's a new wave setup requiring new reporting or new dependency set, I would like to govern my own fields, headers and masks without creating a ticket and and without letting one brand's edit break another brand's reported data.
What improvement do we want to see?
Defining the architecture
We believe that creating a play and plugin platform design would enable important users to avoid getting bogged down in backend details and use the frontend as a tool to create the components they need.
Solution building
Iteration
Feedback and Iteration Process
To make sure we were solving real problems, we used a hands-on research approach:
Weekly sessions with domain experts: A group of key users worldwide provided ongoing feedback.
In-person user testing sessions : We created quick prototypes to test out different views.
F.A.S.T. Methodology: We used the Focus, Attend, Summarize, Translate (FAST) approach to quickly iterate on designs.
Refining the constraints
We wanted to quickly test our assumptions to see if they align with the "job to be done." We received positive feedback for the concept, but we overlooked a few edge cases. We prioritized the ones that could have posed a high risk to task completion and usability issues.
Every field can have inter and intra dependency.
Every field has a value ID, hence saved master fields can be duplicated in other mask template, but not edited.
Key users cannot delete the components which are already in use in workshops, but can deactivate their future use.
Solution highlights
100% adoption with launch
Fig. 1 — Massnahmen workspace.
How can I create the form I need without raising a development request?
Build and structure the form into sections, or tabs.
As a Key User, I can create new fields or start from saved templates, then organise them into sections or tabs.
While building, I can see how the form will look for my users and make changes directly.
Fig. 2 - highlighting settings of input field
Fig. 3 - highlighting dropdown settings
How do I control what each field should capture?
Configuration settings matches field type needs
Different field types have different settings. I only see the options I need for the field I am working on.
A Number field can have a range, decimals or a custom symbol, while text, date and selection fields show settings relevant to them.
Fig. 4 - logic setup at form level
How do I make the form react to what the user enters?
Add dependencies to any set of fields or headers
I can define dependencies between fields, for example:
WHEN Topic Area is Energy
THEN show Energy Cycle
Fig. 5 - logic setup at field level
Flexible logic setup to any field to customise it further or add an action
So the tool supports both inter-field and intra-field dependencies, inc. tracking/recording of the field data for connected data points in previous forms.
Fig. 5 - logic setup at field level
Visualise setting up formulas
Set up formulas and check in preview quickly to see if they are working as intended and tweak them.
Fig. 6 - staircase elements check in preview
What will the Measure owner actually see in the form when published?
Preview before publishing
At any point, I can preview the form from the user's perspective.
I can check the structure, fields and behaviour before making the mask available, instead of finding problems after people have already started using it.
Fig. 7 - publish form flow
Who should be able to use it?
Control who can access it
As a Key User, I can define who can work with the configuration using Write role and Read role.
This allows a mask or component to be shared where needed while still keeping control over who can make changes.
What difference did we make?
Early signals and impact
Measures moved from a hard-coded workflow to self-service configuration system for Volkswagen's Key Users. The same three goals at the start now had clear outcome signals and post launch status.
Configuration Speed
TARGET
Days/Weeks to an afternoon
SIGNAL
Key users could create, preview and publish fields without raising a development request.
STATUS
Routine configuration changes no longer depended on developers.
Data accurancy and governance
TARGET
Make it safer to manage, reuse and retire fields.
SIGNAL
Dependencies, previews and lifecycle rules helped key users test changes before they reached production.
STATUS
Field usage became transparent across brands, making duplication easier to spot and shared components safer to reuse.
Cross-Brand Adoption
TARGET
A flexible system that could work across Volkswagen Group brands.
SIGNAL
92% satisfaction among key users in post-launch survery
STATUS
The tool launched as the self-serve configuration workflow for key users across the group.
Built for more than form creation
Report after the launch
Measures supports the exchange of improvement initiatives across the Volkswagen Group. The platform has historically been used to document and share environmental and energy measures across production sites.
Measures entered increased by 32%.
- Alex, Product Owner, VW Wolfsburg
1,700 measures documented in 2024 · €38M+ reported savings
Volkswagen Sustainability Report, 2024
Fin!
Final thoughts
With the Key User Tool, Measures moved away from a workflow where even small configuration changes had to travel through development.
Key Users can now build and maintain the forms they understand best, while reusable components, dependencies and access controls help keep the platform consistent across brands. An experience designed to stay flexible and easy to scale with Volkswagen Maßnahmen's team for years to come.