Supply-chain collaboration · Toyota × o9
A shortage. Many people. One room.
When a part runs short, fixing it scatters across teams, spreadsheets, and calls. I designed the shared room where Toyota and its suppliers work through it together.
Workflow design
5 / 5Five questions, one place: 4 parts · SUP_Loc_1 · 2 OEM locations · both leads named · two owned reports · the pending decision and when it’s due.Prototype · sample data
01 / Context
Supplier teamKnows the constraint and the recovery plan.When can we recover supply?
OEM plannerKnows which plants and vehicles depend on the part.What does this mean for production?
Decision makerNeeds the risk, the owner, and the next action.Where do we need to step in?
Not a chat tool.
An operational response.
INPUT / 01A requirements tableIt named the pieces, but not how a person moves between them.
INPUT / 02Toyota reviewsEach direction was walked through with Toyota stakeholders.
INPUT / 03Platform & engineering reviewsWhat the product could build, reuse, and support.
INPUT / 04A user validation sessionA check that the connected journey made sense to its users.
02 / The disconnect
A planner could see a supply gap. What they couldn’t see in the same place was who was fixing it, what had changed, or which decision was still waiting.
The planning system held the numbers. Email, calls, and spreadsheets held the rest. Each team had a piece of the story, and every handoff meant piecing the situation together again.
Planning system
The gap by part, supplier site, plant, and week.
How big is the gap?
Email & calls
What is constraining the supplier, and what recovery looks like.
Why is it happening?
Spreadsheets
Which plants and vehicles are exposed, and how soon.
What will it cost production?
People’s memory
Who agreed to what, on which call, and who acts next.
Who is doing what next?
The information existed.
It just didn’t live in one place.
| Question | Where the answer lived |
|---|---|
| 01What’s short, and where? | Planning systemThe gap by part, supplier site, plant and week. |
| 02Who is on it? | People’s memoryWho acts next, and who agreed on which call. |
| 03What do we know? | Email & callsSpreadsheetsThe supplier’s explanation in one place, the plant impact in another. |
| 04What’s been decided? | People’s memoryWho agreed to what, on which call. |
| 05What happens next? | People’s memoryWho is doing what next. |
The room had to answer all five without a search.Sources: the four fragments above
UX lensA shared mental model
The problem wasn’t a lack of information. Each team held a different piece of it. The design had to make those pieces understandable together, while respecting the different decisions each side is responsible for.
03 / The brief
How I framed it
I translated the requirements into one connected journey: detect a gap, bring the right people together, assess the impact, agree on action, and close the loop. To hold that journey, every room needed three parts, each answering its own questions.
The planner selects the shortage rows in the planning workspace.
The planner reached the supplier by email and calls.
The room opens with the scope and both leads.
Run-out & supply gap report
Plant impact report
Both sides read both reports.
The decision goes on the record.
The room closes and stays a readable record.
Each lane is who acts. The shortage enters from the OEM’s planning rows and stays in the shared lane until the room closes. Before the room, the same work ran between the two companies off the record.
The room, as a plan
Three zones, five answers. The summary holds where the shortage stands and who owns it. The conversation carries what’s happening. The reports, one tab away, hold what each side knows.
A plan of the prototype’s room layout, simplified. The numbers are the five questions.
Answers 01 · 02
Where do we stand?
The exact supply problem and the people accountable for it, visible the whole time.
Answers 04 · 05
What’s happening?
One running record of updates, files, tasks, and decisions, tied to the issue it is resolving.
Answers 03
What do we know?
Two structured reports, one owned by each side, so comparable facts don’t get lost in the thread.
Constraints
The goal wasn’t another chat tool.It was one shared account of the shortage.
04 / The turning point
My first room looked organised: task counts, status cards, and a task grid. But a shortage doesn’t arrive as a tidy to-do list. People first need to explain what happened and work out a response.
Platform reviews added a second pressure: bespoke widgets would be costly to build and maintain. I moved the centre of the room to Pulse, the product’s existing conversation pattern, and kept the structured work beside it. Select a change to see where it moved.
The screens on this page are my designs, redrawn as low-fi in React with a neutral logo and sample names. Click through all 15 screens
Task counts and a task grid took the main workspace. Work was visible, but the explanation behind it had nowhere to grow.
The Pulse conversation became the workspace. Updates, files, and decisions build one shared account of the shortage.
Posts, tasks, and attachments were separate views, switched from a toolbar.
Files, tags, and tasks travel inside each post, so evidence stays next to the discussion it supports.
The two reports sat behind buttons in the header, one step removed from the room.
Reports became tabs of the room: one step away, never somewhere else.
The summary: status, the two leads, report completeness, and the affected parts.
It stayed beside the conversation in both directions. It’s the stable reference while the thread moves.
Force / 01 · People
A shortage starts as a question, not an assignment. People need room to explain before they can divide the work.
Force / 02 · Platform
Pulse, forms, and grids already existed. Bespoke task widgets meant more to build, integrate, and support.
The decision
The tradeoff was deliberate: less task-management prominence, more space to coordinate. It changed the information architecture, not just the layout.
My original design files show the shift from task widgets to a Pulse feed, a persistent summary, and report tabs; the screens here are redrawn from them. The project records describe stakeholder reviews and platform feasibility discussions as the inputs.
Reuse was a design decision too. It let people bring what they already knew about the product into a new workflow, and it limited how freely every interaction could be customised. I accepted that where a familiar pattern supported the work, and used hierarchy to give the room its purpose.
05 / Three decisions
Decision / 01
A / BLANK FORM
A standalone create pageFlexibleB / OPEN CHAT
A general channelFast to startC / FROM THE ROWS
From the selected shortageContext arrives with the roomMore dots = better for the person opening the room. A design judgement, not a measurement.
I placed room creation beside the supply gap. Selecting the affected rows sets the part, supplier location, and plant before anyone starts explaining the problem. People check what’s already there instead of remembering identifiers and typing them again.
The tradeoff: a room is tied to a concrete supply issue. It’s less flexible than a general chat, and much clearer about what the conversation concerns.
Recognition over recall
Decision / 02
A / ONE SHARED DOC
Everyone edits everythingOpenB / SEPARATE ROOMS
A room for each sideClear ownershipC / OWNED REPORTS
Shared visibility, owned reportsBoth sides see bothConfidentiality depends on a second rule: a room is shared with one supplier organisation only.
A supplier knows why a part is running out. A buyer understands what that means for production. Sharing a room shouldn’t blur those responsibilities, so each side owns one report and can read the other’s.
The boundary: collaboration is scoped to the room’s participants. A common workspace must never imply access across suppliers.
Clear ownership
Decision / 03
A / ALL IN THE FEED
Everything is a postComplete historyB / ALL IN TABS
Everything is a pageTidyC / FEED + SUMMARY
Feed beside a steady summaryThe story movesA conversation explains how a decision happened. It doesn’t make the current situation easy to find. I kept ownership, status, report completeness, and affected supply beside the discussion, so everyone has a stable reference as the thread grows. The detailed reports wait one step away, in tabs.
Recognition over recall
Progressive disclosure
Before → decision → after
Start the room from the selected shortage rows.
Share the room, separate the reports.
Put the conversation beside a steady summary.
06 / The experience
01 / Detect
A planner selects the affected part-location rows. The selection summary shows what the room will carry: one supplier, two plants, and the projected gap.
Continuity from finding a problem to acting on it
Open this step in the prototypeCreate a room from the shortage, switch between the Toyota and Denso views to see who can edit what, then close the room and watch it become a record. The data is sample data.
07 / Beyond the happy path
The harder questions appeared at the edges. A rule is only useful if people understand why it exists and what to do next.
Each boundary below blocks something for a reason, and each keeps the planner’s work instead of throwing it away. The recovery designs shown here are from the rebuilt prototype.
Boundary / 01 · Confidentiality
A selection that spans two supplier organisations can’t become one room. A shared shortage doesn’t make competitors one audience.
RecoveryKeep the selection and split it: “Keep Denso rows” or “Keep Aisin rows”.
Boundary / 02 · Continuity
A part and plant already in an open room shouldn’t start a competing conversation. The history and the ownership would split again.
RecoveryPoint to the existing room, or leave that row out and carry on.
Boundary / 03 · Lifecycle
Closing a room stops editing but keeps the record. Unfinished reports are called out first, and a related part stays monitored while another room is open.
RecoveryFinish or request the missing report, or close knowingly.
Review states,
not only screens.
UX lensError prevention & visible status
The open room looked finished long before its closed counterpart was. Defining what each state allows made the lifecycle coherent: a label, the available actions, and the explanation for unavailable ones all agree.
One-image summary
Spot the gap
↓Email the supplier
↓Re-explain the parts
↓Assess impact in a spreadsheet
↓Reconcile on a call
↓Decide · who owns it?Select the affected rows
↓Open a room with context and leads
↓Each side completes its report
↓Discuss beside the summary
↓Agree on the next step
↓Close with a readable recordWhat changed
A room tied to the affected supply, not a blank conversation.
Visible leads on both sides and separate report responsibilities.
The discussion beside the current situation, not apart from it.
A closed room that stays a readable, trustworthy record.
What I can say
The original artifacts show a connected workflow and a substantive change of direction. The project records describe an initial Toyota launch, then enhancements and productization.
What I don’t claim
A measured drop in resolution time, feature adoption figures, or engineering savings. The prototype’s analytics are sample data, and they’re labelled that way.
08 / Looking back
Platform feasibility pushed me to reconsider the room’s centre.
The room’s value depended on how context, authority, and lifecycle fit together.
Next, I’d test whether a returning participant can name the next action and its owner.
Less piecing it together.More moving it forward.