Role
Design system lead,
Product designer
Client
Toyota Motor Europe
Team
Designers, Developers, QA, Product
Year
2024 - 2025
TL;DR
As Toyota’s first omnichannel car-buying experience was being designed and developed at pace for two markets, Figma, Storybook, and the emerging product began to drift out of sync.
I led the creation of a shared design system that aligned design and code through clearer foundations, 30+ reusable components and a shared design–development workflow. It later provided a flexible foundation for Lexus.
400+ cars sold
Through the omnichannel experience in its first 3 months
€18m+ revenue
Across digital and retailer-assisted EV purchases
30+ components
Fully aligned across Figma and Storybook
A design system for Toyota's first omnichannel car-buying experience
Before this project, Toyota customers could configure and save a car online, but the journey ended there. The new experience allowed them to continue through purchase digitally or move between online and retailer support without starting again.
When I joined, core journeys were already being designed and delivered sprint by sprint for two markets: France and Spain. The bZ4X had a distinct brand expression for Toyota’s electric offering, while the underlying experience needed to remain flexible enough to support future markets and brands.
As design system lead, I worked across Figma foundations, Storybook alignment, component documentation, design QA and design–development collaboration.
The team was moving fast, but it was also drifting out of sync
New areas of the experience were expected each sprint, leaving little time to consolidate patterns. With two designers working in parallel, similar problems were being solved in different ways, creating inconsistencies across Figma, Storybook and the product itself.
The gaps showed up in developer comments: missing states, accessibility concerns, unclear component names and uncertainty about which version was final. These were not cosmetic inconsistencies. They created build questions, slowed implementation and added to technical debt.
Market differences across France and Spain introduced another layer of complexity, including localised content, legal requirements and different approaches to pricing information.
If we kept designing new journeys without aligning the foundations first, we would only scale the inconsistency.
I focused on where design and code were misaligned most
I started by auditing Figma against Storybook and the product in build, looking at typography, colour, spacing, repeated components, states, and interaction patterns.
Typography became one of the clearest examples of the design-code gap. Font weights in Figma, such as Book, Normal, or Medium, didn't always map cleanly to CSS values. Even when developers inspected the design, the value shown in Dev Mode could behave differently in code.
Speaking the same language as developers became essential. It improved collaboration and helped me document components in terms that translated more clearly into implementation.
We rebuilt the foundations around clearer typography tokens, spacing rules and better-defined colour usage. From there, we expanded the system across buttons, form fields, cards, modals and price summaries, with states defined consistently across Figma and Storybook.
Explore a snapshot of the design system, including foundations, component documentation, states, and usage guidance.
The system worked because the process stayed lightweight
A heavyweight governance model would not have worked for a team delivering new journeys every sprint. Instead, we established a simple contribution flow: Propose → Review with design and development teams → Document → Build → QA → Publish.
Developers were involved early, allowing us to surface assumptions before components reached build. I regularly compared Figma with Storybook, raised mismatches through tickets, paired with developers where needed and used design–development syncs to review progress.
We built a design system that was flexible enough for designers, solid enough in its foundations for developers, and helped us all speak the same language.
Radu Micu
Technical Director and Web Practice Lead @ Valtech
The strongest proof for success came with Lexus
The strongest test of the system came when the same team began a discovery for Lexus. Lexus needed the same core experience, but with a more premium expression across typography, spacing, density, colour, component styling and layout.
The Toyota foundations gave us a strong starting point. We retained the component logic while adapting the styling and presentation for a more luxury-focused audience. The system was specific enough to support the bZ4X, but flexible enough to inform a distinct Lexus direction.
What changed
The clearest impact was in how the team worked. Designers could begin new journeys with established patterns instead of reopening foundational decisions. Developers had better-defined states and fewer ambiguities to resolve during implementation. Regular comparison between Figma, Storybook and the product made alignment part of delivery rather than a one-off clean-up exercise.
The system also gave the team a common foundation across France and Spain, making consistency part of everyday delivery rather than something repaired retrospectively.
What I learned
The most valuable part of leading this work was not creating the component library itself. It was diagnosing where collaboration was breaking down and building a system the team could confidently use.
Working more closely with Storybook, DevTools, and implementation made me a stronger design partner to developers. It changed how I document decisions, discuss constraints, and bridge the gap between design intent and the experience customers ultimately receive.