EU Regulation
EU Battery Passport Initiative
Designing a scalable, regulation-compliant data platform from zero to MVP in 6 months
Overview
Project overview and impact
Mercedes-Benz needed to comply with EU Regulation 2024/1257 (Euro 7), which mandates a Digital Product Passport (DPP) for all new vehicles sold in the European Union from late 2026 onwards. As the first regulation in the Digital Product Passport ecosystem to reach our company, the Battery Passport became the flagship initiative — and a blueprint for every passport to follow.
I was brought in as Lead Product Designer to build not just a single product, but a scalable design foundation that could serve the entire DPP ecosystem. This meant navigating uncharted territory: no comparable internal platform existed, the regulation was still being interpreted, and the stakeholder landscape spanned six countries, multiple departments, and external suppliers.
6
Months to MVP
Zero rework required
€2M
Estimated Savings
System reuse strategy
0
Rework Cycles
Design-first approach
My role
Leading UX strategy, discovery, and design culture across teams
As the lead designer, my responsibilities extended far beyond interface design. I owned the full product discovery process, design strategy, stakeholder alignment, cross-functional facilitation, and the scaling of design systems across the ART (Agile Release Train).
Design & Strategy
Led product trio (PM + PA + Designer) from discovery
Led design-first approach across the ART
Defined product discovery process from zero
Built scalable design system (MBUI-based)
Owned user research and persona development
Facilitated ideation and usability testing
Leadership & Collaboration
Drove management alignment via prototypes
Onboarded new teams via design workshops
Partnered with PM and PA as product trio
Connected experts across Germany, Spain, India
Presented system reuse case to management
Context
Understanding the regulation and problem space
Before designing a single pixel, I needed to understand the regulatory landscape. EU Regulation 2024/1257 mandates that all new on-road vehicles sold in the EU must carry a Digital Product Passport — a structured data record covering the vehicle's environmental footprint, component traceability, and end-of-life information.
For the battery specifically, 73 distinct data fields are required — covering chemistry composition, CO2 footprint, supply chain origins, performance data, and recyclability metrics. This data must be collected from internal systems, external suppliers, service centers, and manufacturing lines — then validated, approved, and made accessible to customers, regulators, and third parties.
The Regulatory Requirement
Regulation (EU) 2024/1257 requires that before a vehicle is sold, its Battery Passport must be complete, validated, and available to three classes of users: customers (public-facing QR scan), users with legitimate interest (API access with authentication), and regulatory authorities (API data provision). Failure to comply risks blocking vehicle sales across the EU — a multi-billion euro commercial risk.
Mapping the Problem Space
I approached this with a five-day intensive discovery sprint alongside the PM. We built a shared Mural board combining regulatory requirements, stakeholder mapping, data flow assumptions, and competitive references. By day five, we had enough clarity to frame the core problem dimensions:
Data Collection: 73 fields from 5+ source systems, internal departments, and external suppliers
Data Validation: Multi-stage approval workflows with regulatory-grade audit trails
Data Sharing: Three distinct access tiers with different authentication and display requirements
Scale: Millions of vehicles across the EU — performance and availability are non-negotiable
Future-proofing: Battery Passport is the first; more passports (tires, CO2, components) are coming
Building the User Landscape
One of the first things I had to establish was a clear picture of who this system serves — and who operates it behind the scenes. The regulation defines three external user classes, but the real complexity lives in the internal roles required to make the data pipeline function reliably.
User type
Customer
Legitimate Interest User
Regulatory Authority
Super Admin
Battery Admin
Data experts
Law experts
Access method
QR Code → Public Portal
Authenticated API or Portal
API
Internal Platform
Internal Platform
Internal Platform
Internal Platform
Core need
Transparent battery data in plain language
Structured data access for resale, insurance, recycling
Complete, auditable compliance data
System-wide configuration and oversight
Battery data lifecycle management
Provide or validate data field value
For the final data confirmation in passport level
Process
Discovery, Research & Collaboration
Building Shared Understanding
The project started with an intensive knowledge-building sprint. The PM had initial stakeholder connections and regulatory awareness; I had UX process expertise and a prior track record on the EU Battery CO2 regulation under Article 7. We ran parallel research tracks — PM focused on stakeholder connections and management alignment while I dug into the regulation, built user flows, and mapped the data architecture implications.
The Co-Creation Rhythm
Every day for the first two weeks, we added findings to a shared Mural board. PM would return from stakeholder interviews with business constraints; I would add user flow implications and UX hypotheses. By day five, we had enough to frame a clear problem statement. This daily exchange rhythm became a model for the rest of the project.
Stakeholder & Expert Mapping
Identifying the right people was one of the hardest challenges. Battery data in a large automotive company spans multiple departments, geographies, and decades-old processes. No single person understood the full picture — which meant I had to stitch together a system understanding from many partial views.
I ran internal research through company channels while the PM worked management relationships. Within the first month, we had connected with subject matter experts in Germany, Spain, and India — covering battery engineering, regulatory compliance, supplier management, and data systems.
Competitive Analysis & Market Positioning
We systematically analyzed how competitors — Siemens, Circular, Volvo, and Porsche — were approaching Battery Passport compliance. This revealed a critical strategic opportunity that shaped the entire direction of the project.
First Major Challenge: Justifying Internal Development
Problem
Multiple third-party vendors were ready to offer Battery Passport solutions. We faced pressure to simply purchase an existing tool rather than build internally. Management questioned whether the development investment was justified.
Resolution
Deep competitive analysis revealed that existing vendors only solved the display layer — they would show your data once you provided it. The 80% of the problem — collecting, validating, and managing complex data from dozens of internal and external sources — was entirely unaddressed by vendors. This gap became our strategic anchor. We demonstrated that building the collection and validation system internally was not just cheaper long-term, but necessary to maintain data control and regulatory compliance.
From Understanding to Hypothesis: The First Prototype
With enough understanding to start forming hypotheses, I began building user flows and mapping the information architecture. I then tried to use Mural — the tool that had worked so well with the PM — to collaborate with business stakeholders and subject matter experts on refining these flows. This is where I hit my first significant mistake.
Design Decision: Early Prototyping as Communication Tool
Rather than waiting for complete specification before designing, I built a rapid prototype of the core concept — not to validate the final design, but to create a shared language between the design team, engineers, business stakeholders, and management. An imperfect prototype in front of stakeholders is worth more than a perfect spec document that no one reads.
Solution
The Design Solution: System Thinking & Architecture
Framing the Design Space with HMW Questions
After synthesising research, stakeholder input, and regulatory requirements, I framed the design challenges as How Might We questions to drive ideation and keep the team focused on problems rather than jumping to solutions:
HMW connect with all source systems for automatic data synchronisation?
HMW design a validation workflow that ensures data readiness before vehicle sale?
HMW enable suppliers and service centres to contribute data with minimal friction?
HMW provide customers and legitimate interest users with differentiated, appropriate access?
HMW integrate the battery passport with in-car digital experiences?
HMW build a system that scales gracefully to future passport types?
The 8 Application Audit & the Reuse Insight
One of the most consequential things I did on this project was run a systematic audit of 8 existing internal applications. The hypothesis was simple: in a company this large, the data collection, approval, and handover workflow we needed almost certainly existed somewhere already. We just had to find it.
The audit confirmed the hypothesis. One internal platform — used in a different department for a different purpose — had a flow structure that matched over 70% of what we needed. I mapped our required user flows against its existing architecture and brought those findings to the trio.
The Moment the Trio Proved Its Value
The reuse breakthrough only happened because the PA was embedded in discovery alongside me. I could see the UX flow match — the PA immediately saw the architectural implications: whether the existing system could support regulatory-grade audit trails and EU-scale data throughput. The PM translated the combined finding into a business case. None of us could have made that call alone. The trio model is what converted a UX insight into a €1M strategic decision.
Proposing Reuse — and Getting Pushed Back
Once the trio aligned on the reuse strategy, we expected the path forward to be straightforward. It wasn't. Presenting the idea to the team who owned the existing platform revealed a challenge I had not anticipated.
The existing team didn't want to be responsible for our compliance deadline
Problem
When I presented the reuse proposal to the team behind the existing platform, they pushed back hard — not because they disagreed with the logic, but because they were worried about risk. Would their system handle EU-scale traffic? Could they meet a regulatory deadline they hadn't been planning for? Were they taking on a compliance liability that belonged to another team? I had prepared a UX argument and a cost argument. I had not prepared for a risk argument.
Resolution
Rather than continuing to pitch the idea externally, I focused on making the existing team feel seen and de-risked. I built a prototype specifically demonstrating how integration would work — not to convince management, but to help the existing team understand what we were actually asking of them. I ran a walkthrough session with their full team, gave them space to raise every concern, and framed it as a co-build rather than a dependency. Once they felt ownership rather than liability, they became the advocates with management. Their endorsement landed far better than mine would have.
The Architecture: Two Platforms, One Ecosystem
With reuse confirmed, the trio designed the full system architecture: an Internal Data Management Platform handling collection, validation, and approval; and an External Access Layer providing the customer QR experience, legitimate user portal, and regulatory API. These were connected through a shared data store with a regulatory-grade audit trail baked into every write operation.
The PA proposed a horizontal scaling architecture with an adapter pattern — each passport type connecting via its own adapter to shared core infrastructure. That single decision made my design ambition for ecosystem-wide scalability technically credible. Every design decision from that point was tested against one question: "Will this also work for the tyre passport?"
Trio in Action: Presenting to Management
We presented as a trio — each covering our domain. I walked through user experience consistency and design system scalability. The PA presented technical architecture and feasibility evidence. The PM framed the business case and cost impact. This unified front was itself a signal: not a design pitch or a tech pitch, but a product decision made by people who understood all three dimensions. Management approved.
Scalable Design: From Battery Passport to DPP Ecosystem
The most strategically significant design decision was building for the ecosystem, not just the immediate product. Working in trio sessions, the PA surfaced data on upcoming EU passport mandates — tyres, CO2, materials, components — and observed that they all shared the same regulatory logic: collect structured data, validate it, make it available to tiered users. That observation changed the entire design brief. We were building the first instance of a DPP platform, not a one-off compliance tool.
I designed the component library and interaction patterns to be passport-agnostic — grounded in MBUI but extended with DPP-specific components that could be configured for any passport type with minimal rework. This required convincing management of the value of upfront design investment that would not be visible in the MVP, which I did using a before/after comparison of development effort with and without the scalable foundation.
Without Scalable Architecture
6–9 months per passport
Separate codebases per regulation
Inconsistent user experience
No shared component library
Full rework for each new passport
With Scalable Architecture
2–3 months for subsequent passports
Shared horizontal architecture
Consistent cross-passport UX
Reusable DPP component library
Adapter pattern for new data types
Validation
Testing Assumptions at Every Stage
Prototype-Driven Alignment
With stakeholders and subject matter experts who found static documentation difficult to engage with, the prototype was the primary alignment tool throughout — not just at the end. I ran three distinct types of sessions, each serving a different purpose.
Usability Testing
Every battery data field must be approved before a vehicle can be sold in the EU — making this the most commercially critical part of the platform. My first design handled it at inquiry level.
"An approval process configured by the admin per battery type. Admin selects the number of approval stages — fixed and applied uniformly across all data fields."
It was a reasonable interpretation. It turned out to be wrong.
I had designed approval as a record-level operation. The real process was field-level.
Problem
Admins froze during configuration — not because the UI was unclear, but because the regulation was new to everyone. They didn't know which departments owned which fields, so they had no basis for choosing a number of stages.
Resolution
The approval model moved from inquiry level to data field level. And it can configure the responsibility in each level.
Admin Configuration
Before
Single approval count applied uniformly across all 73 fields. No department mapping, no way to reflect how data ownership is actually distributed across the organisation.
After
Fields mapped to responsible departments with Shared / Independent approval mode per data field. Admin configures the full approval structure to match organisational practice.
Approver Queue
Before
All fields in one undifferentiated queue regardless of the approver's expertise. No co-approver visibility, no regulatory context.
After
Queue scoped to the approver's field groups. Co-approver status visible in Shared mode. Inline regulatory context for each group.
Fixing the Existing System
The reused internal platform had significant usability debt — it had been built incrementally by engineers to solve technical problems, not designed around the people using it daily. Through four rounds of usability testing and iteration, we addressed the four most critical issues. These improvements benefited not just the Battery Passport, but the existing system's entire user base — which is what ultimately turned that team into advocates for our approach.
Eg: Approval Workflow: No Visible Status or Queue
The approval workflow had no visual status system. Approvers had no queue — they searched manually for records assigned to them. This caused regular missed approvals and deadline failures, which was commercially unacceptable under a regulation that required data to be ready before a vehicle could be sold.
Before
Status stored in a plain text field. No queue for approvers. No indication of stage, required action, or deadline. Teams tracked deadlines in external spreadsheets.
After
Visual pipeline showing all approval stages. Personalised approver queue. Status badges with colour coding. Overdue items surfaced automatically. Full inline audit trail.
The Study
Fixing these four issues was not a side effect — it was a deliberate strategy. By demonstrating that our approach would improve the daily working life of the existing platform's users, those users became advocates for the system reuse approach with their own management. The usability improvements converted a sceptical team into champions. When we needed internal support for the management approval, we had it — because we had already earned it.
Team and design leadership
Growing the Team While Protecting Strategic Focus
Two new designers in business discussions
It would have been faster and easier to bring designers up to speed on completed research and then assign them work. I chose not to because I had seen what that produces: technically correct designs with no sense of the human context behind them. By including both designers from the first stakeholder sessions, their work carried the weight of direct understanding from the start. They made design decisions I wouldn't have anticipated — and those decisions were better for it.
Phase
Weeks 1–4
Weeks 5–10
Weeks 11–20
Post-MVP
Battery Admin
Designer Involvement
All stakeholder sessions, Mural research board, observing SME interviews
Presenting their design areas to stakeholders and SMEs, facilitating feedback
Independently initiating SME contact, running usability tests, bringing insights to trio
Full ownership of their passport areas, beginning to mentor new team members
My Focus
Leading sessions, modelling how to synthesise and ask the right questions
Present but not leading — support only when needed, debriefs after each session
Strategy, system-level decisions, cross-team alignment — trusting their execution fully
Design leadership across the ART — made possible by their independence
Onboarding the New Development Team
When management approved system reuse, the existing platform team joined — strong technical expertise, but pure feature-delivery culture. I led a full-day orientation workshop with the PM and PA, starting not with what to build, but why — the regulation, the stakes, the people depending on this system.
Phase
Product Vision
HMW Framing
User Empathy
Prototype Walkthrough
Goal Setting
Designer Involvement
Shared the complete DPP ecosystem vision — not just Battery Passport — so the team understood they were building infrastructure for a platform, not a single deliverable.
Introduced problem framing via HMW questions — a practical shift from solution-first to problem-first thinking that many had never encountered before.
Walked through real user personas and research findings — making abstract "users" feel like specific people with specific frustrations and needs.
Presented the current prototype focused on integration touchpoints relevant to their system — grounding the vision in something concrete and clickable.
Collaboratively refined PI (Program Increment) goals based on the shared vision — building team ownership of the goals from the very first day.
The onboarding workshop visuals
Result
Results and business impact
6
Months to MVP
Zero rework required
€2M
Estimated Savings
System reuse strategy
4×
Usability Rounds
Existing system improved
2
Designers Grown
Into independent owners
Product Impact
MVP delivered in 6 months, on schedule
All 73 EU-mandated data fields covered
Full EU accessibility compliance - WCAG 2.1 AA
Zero rework cycles — unprecedented in department
4 critical usability issues in existing system resolved
Organisational Impact
Product Trio model adopted as ART standard
Design-first culture embedded across ART
2 designers grew into independent product owners
New team onboarded with product mindset
Scalable DPP design system established
Framework ready for 5+ upcoming passport regulations
What I Would Do Differently
Start with interactive prototypes in week one — not after initial research synthesis. The communication value is too high to delay even for a few weeks
Run a stakeholder collaboration style assessment at kickoff. Identifying preferred communication formats before defaulting to tools that worked on a previous project would have saved two weeks
Involve the receiving development team earlier in discovery — before the reuse decision was made — so they felt like co-discoverers rather than people presented with a conclusion about their own system.
Formalise the application audit methodology from the start rather than running it as an ad-hoc investigation. The structured approach to finding reusable infrastructure is valuable enough to be a repeatable practice.