TOYOTA CONNECTED EUROPE | 2022 - 2026
Applying Toyota ways of working to my own practice
How Toyota’s problem-solving principles have shaped the way I think, collaborate and design.
Overview
Four years working within Toyota influenced more than the products I designed. It introduced me to a way of thinking about problems that I now apply to my own design practice. Toyota uses a number of principles developed through the Toyota Production System. While they originated in manufacturing, many translate surprisingly well to product design: understand problems at their source, remove unnecessary work, involve people early and continuously improve.
Genchi Genbutsu: Go and see
Understand what is actually happening before trying to fix it.
For me, this means not jumping straight into Figma.
I start by understanding the customer journey, existing experience, system behaviour and constraints around the problem. In connected vehicle products this was particularly important, as a simple screen could be affected by vehicle state, connectivity, permissions, backend services or market-specific rules.
Mapping those relationships first helped uncover edge cases and underlying causes before deciding what the interface should do.
Kaizen: Continuous improvement
Look for opportunities to make things better, even when a complete redesign isn't needed.
I apply this both to the products I design and to the way the team works.
That could mean simplifying an existing journey, improving a component, making UX copy clearer or improving the structure of a design file so that the next person can understand it more easily.
The question isn't always "How would I redesign this?" Sometimes it's simply "How could this work better?"
Muda: Remove unnecessary waste
Identify effort that doesn't create value and find ways to remove it.
I experienced this first-hand while inheriting large, poorly structured Figma files. On one project I estimated around 30% of my workload was being spent finding designs, understanding what represented the live experience and rebuilding a reliable source of truth.
That wasn't really a UI problem. It was a problem with the system around the design work.
Recognising that distinction led me to look at how we could improve versioning, approvals and design delivery rather than simply tidying individual files.
Nemawashi: Build alignment early
Bring the right people into a decision before the decision is made.
I don't see collaboration as presenting finished work and asking for approval.
I prefer to involve Product, Engineering, Research and other stakeholders while the problem is still being understood. Workshops, flows and early prototypes give everyone something tangible to react to and help surface constraints before they become expensive problems.
I've found this particularly useful when working in ambiguous areas or across multiple teams, where creating a shared understanding can be as important as creating the design itself.
A3 thinking: Tell the whole problem on one page
Create a shared view of the problem, its causes, the desired outcome and how you intend to get there.
A3 thinking brings many of these principles together.
I used the approach when investigating inconsistent Figma versioning and approval processes across our design team.
I started with what I had experienced myself, then spoke with other designers to check whether the same problem existed elsewhere — it did. Designers were using different approaches to file management and approvals, while stakeholders often struggled to identify which designs were current.
I then defined an ideal state: smaller design files, one source of truth, clear version history and a visible approval process.
Rather than rolling out a new process immediately, the A3 proposed testing a new Figma branching and approval workflow on a live project, gathering feedback, refining it and then embedding what worked.
The A3 below captures that thinking on a single page.
