Five platforms. One ecosystem. Zero specs.
Unifying the digital workspace of the world’s largest brewer by turning prototypes into the spec — and a design system into the production line.
(Material Management dashboard)
(second platform view)
The Challenge
ABInBev is the world’s largest brewer — roughly 630 beer brands across 150 countries. Its operators’ daily work was scattered across at least five fragmented internal platforms. The mission was to fold them into a single ecosystem so people could stop tab-switching and start working. The catch lived in the constraints: no direct access to the operators, no contact with the product managers, and briefs that read more like wishes than requirements — each one due as a full prototype, fast.
Working blind
Picture it: you and your design partner, alone in a room. Paper, markers, a laptop, and a door. A bell rings and a note slides underneath — “We need a new feature.” You write back “What should it do?” and slide it through. Days later, the reply: “Users should be able to create an assortment. PS — we need the full prototype in two days.” You’ve never seen an assortment. You ask what it should show, whether something similar already exists. The most-feared answer comes back:
“We don’t know.”
No specs. No live feedback. No questions resolved. Just a door, a deadline, and trial and error. So I stopped waiting for certainty that was never coming — and started prototyping.
The Bet
If no one could tell me what to build, I’d build it — and let the prototype ask the questions. High-fidelity Figma screens became the spec, the discovery tool, and the thing stakeholders finally reacted to. The design system underneath let me turn a vague request into a first full prototype in two days — then iterate from there until it was right.
- Defined ambiguous features through iterative prototyping
- Eliminated unnecessary features before they were ever built
- Delivered a unified ecosystem the product team approved
51
Platforms unified
2
Days to the first full prototype
0
Specs at start prototypes became the spec
1
Design system shipped
The Process
Just keep prototyping
With no specs to follow, ambiguity was the medium we worked in. The answer was a four-beat loop: workshop, prototype, review, refine — and a design system to make every loop faster than the last.
-
1
Workshop
- Moderated timed sessions in Miro and Google Jam
- 10–20 min of rapid market research and insight sharing
- 20-min sketch sprints to surface as many directions as possible
-
2
Prototype
- Skipped lo-fi and went straight to high-fidelity in Figma
- Used the screen as the discovery tool, not the destination
- Assembled prototypes from the design system in days, not weeks
-
3
Review
- Sent prototypes to Product Owners as the requirements artifact
- Used reactions to elicit the functional constraints no brief had named
- Cut features the team didn’t actually need
-
4
Refine
- Iterated until the feature set was approved by the product team
- Folded approved patterns back into the design system
- Handed off a unified platform ready for engineering
Strategy & Ideation
When the spec is missing, ideation is the spec
With no requirements to follow, I designed the workshops to be short, opinionated, and impossible to leave without a direction. The point wasn’t consensus — it was a concept solid enough to start prototyping the moment the workshop ended.
A workshop format you can’t hide in
To bridge the gap between vague requests and concrete solutions, I moderated timed ideation sessions in Miro and Google Jam. Strict structure, ruthless time-boxing, maximum output:
- Research — 10 to 20 minutes Rapid market scan and insight sharing. Just enough context to argue from facts, not feelings.
- Ideation — 20 minutes Each participant sketched as many directions as they could before the timer ran out. Quantity first, judgement second.
- Selection The room voted concepts up or out. The strongest moved straight into high-fidelity in Figma.
(Product ID & assortment screens)
(Returns & Materials flows)
Every screen started on paper — the fastest way to throw an idea at a door and see what came back.
The design system that made two days possible
A two-day first prototype isn’t a heroic sprint — it’s a system. In parallel with the work, I built a standardized library of components: colors, icons, buttons, and patterns the team could assemble instead of redraw. Every approved screen fed new parts back into it, so each loop was faster than the last. The design system turned iteration speed into the team’s biggest asset — and meant the first full prototype could land in two days, then sharpen with every loop after.
(icons, buttons, components)
Execution & Validation
The prototype is the spec
With no specification documents to start from, the prototype review was the requirements phase. The screen went out; the reactions came back; the requirements wrote themselves.
Material Management — one of the final approved screens, assembled from the design system and handed to engineering.
A feedback loop instead of a brief
With nothing written down to build against, we ran a continuous cycle in place of a spec document:
- Review Prototypes went to Product Owners to elicit the specific functional constraints nobody had been able to articulate up front.
- Refinement I iterated on the designs until the feature set was approved by the full product team — and only then was anything “decided.”
Only when the full product team signed off did a feature stop being a question — the prototype had quietly done the spec’s job.
Takeaways
What this project proved
Key Takeaway
The fastest way out of ambiguity isn’t more certainty — it’s making something real, then letting people react to it.
- Prototyping is your strongest tool. When no one can tell you what to build, a prototype asks the question for you — and shows which features to keep and which to drop.
- A design system pays for itself fast. Standardized parts turned a vague request into a first full prototype in two days, then sped up every loop after.
- Concrete beats certain. A real screen turns vague approval into specific, nameable constraints — the closest thing to a spec we ever had.