EU Regulation
EU Battery Passport initiative
Designing a scalable, regulation-compliant data platform from zero and building the design foundation for every future EU Digital Product Passport.
6
Months to MVP
Zero rework cycle
€2M
Estimated savings
System reuse strategy
40%
Faster approvals
Usability testing validated
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.
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.
73 data 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
Future proofing
Battery Passport is the first; more passports (tires, Environmental vehicle passport, ACC2 etc ) are coming
Figjam board created for demo purpose - indicating the problem space
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
Access method
Core need
Customer
QR code → Public portal
Battery data in plain, accessible language
Legitimate interest user
User specific portal
Structured data for resale, insurance, recycling etc
Regulatory authority
API
Complete, auditable compliance data
Super admin
Internal platform
System-wide configuration and oversight
Battery admin
Internal platform
Battery data lifecycle management
Data experts
Internal platform
Provide or validate individual field values
Legal experts
Internal platform
Final regulatory confirmation at 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.
Mural board for Product discovery - PM findings + UX hypotheses + Data flow mapping
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.
Figjam mapping created for demo purpose
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.
Early prototyping as the primary communication tool
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. Not everyone are comfortable with information dense Mural boards collaboration. So rather than waiting for complete specification, I built a rapid prototype of the core concept — not to validate the final design, but to create a shared language between design, engineering, business, and management.
"An imperfect prototype in front of stakeholders is worth more than a perfect spec document that no one reads."
Design principle that guided every alignment session in this project
Multiple iterations and validations results the final product
Solution
System thinking & design architecture
Framing the Design Space with HMW Questions
After synthesising research, I framed the design challenges as HMW questions to drive ideation and keep the team problem-focused.
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
6–9 months per passport
Separate codebases per regulation
Inconsistent user experience
No shared component library
Full rework for each new passport
Validation
Testing assumptions at every stage
With stakeholders and SMEs who found static documentation difficult to engage with, the prototype was the primary alignment tool throughout — not just at the end. I ran four distinct usability testing rounds, each targeting different user roles and design hypotheses.
The approval workflow pivot - my biggest wrong assumption
I had designed approval as a record-level operation. The real process was field-level.
Admins found the approval workflow confusing because it didn't match how data responsibility was actually partitioned across departments. The workflow I had designed was logically correct but mentally misaligned with how these people thought about ownership.
Admin configuration - before
Single approval count applied uniformly across all 73 fields
No department mapping — admins didn't know who owned what
No way to reflect how data ownership is distributed
Admins froze: "I don't know how many stages to choose"
Approver queue - after
Fields mapped to responsible departments with ownership clarity
Shared / Independent approval mode per data field group
Admin configures structure to match actual org practice
Task success rate improved from 40% → 94% in next test round
Before
Single approval count applied uniformly across all 73 fields at the inquiry level. So we can have a uniform approach across different department for battery data fetching and approval process.
After
Fields mapped to responsible departments with Shared / Independent approval mode per data field. Admin configures the full approval structure to match department level practice.
"Now I can see exactly which team is responsible"
By an admin
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
Designer involvement
My focus
Weeks 1–4
All stakeholder sessions, Mural research board, observing SME interviews
Leading sessions, modelling how to synthesise and ask the right questions
Weeks 5–10
Presenting their design areas to stakeholders and SMEs, facilitating feedback
Present but not leading — support only when needed, debriefs after each session
Weeks 11–20
Independently initiating SME contact, running usability tests, bringing insights to trio
Strategy, system-level decisions, cross-team alignment — trusting their execution fully
Post-MVP
Full ownership of their passport areas, beginning to mentor new team members
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
Designer involvement
Product Vision
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.
HMW Framing
Introduced problem framing via HMW questions — a practical shift from solution-first to problem-first thinking that many had never encountered before.
User Empathy
Walked through real user personas and research findings — making abstract "users" feel like specific people with specific frustrations and needs.
Prototype Walkthrough
Presented the current prototype focused on integration touchpoints relevant to their system — grounding the vision in something concrete and clickable.
Goal Setting
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
Business impact & organisational change
6
Months to MVP
Zero rework required
€2M
Estimated savings
System reuse strategy
40%
Approval efficiency gain
Usability testing validated
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
Retrospective
What I would do differently
Honest retrospectives are a mark of seniority. These are the four things I would change if I ran this project again — not as regrets, but as methodology improvements I'll carry forward.
Start prototyping in Week 1, not Week 3
The communication value of an interactive prototype is too high to delay even a few weeks. I would begin with the roughest clickable flow on Day 1 of discovery — purely as a thinking and communication tool, not a design artefact.
Run a collaboration style assessment at kickoff
Defaulting to Mural because it worked on a previous project cost us two weeks when subject matter experts struggled with the format. A 15-minute stakeholder style assessment at kickoff would have identified their preferred collaboration formats immediately.
Involve the receiving dev team earlier in discovery
The existing platform team should have been in discovery sessions before the reuse decision was made — so they felt like co-discoverers rather than people presented with a conclusion about their own system. That shift in ownership would have shortened the alignment phase significantly.
Formalise the application audit methodology
Running the 8-app audit as an ad-hoc investigation meant the methodology wasn't captured for reuse. The structured approach to finding reusable infrastructure is valuable enough to be a repeatable design practice — I would now template and document it for every future project.