[ Before you read ]

This isn't a copy-paste case study.

It's a real project, with real insights, real trade-offs, and a real reframe that took me weeks to see.

If you're here to skim, this won't land. If you're serious about understanding how I think — you'll need the password.

[ Call Joy · +91-96234 65096 ]

Turning 40+ shattered Microsoft demo files into one live design system BDMs actually wanted to use.

Role
Senior UX Designer
Team
3 designers, 2 devs
Timeline
~6 months
Tools
Figma, FigJam

Microsoft Data & AI DREAM Demos are clickable industry stories Microsoft sellers walk customers through. When I joined, files were chaos — and the demos showed it.

[ Note · Visuals on this page are representative recreations. Original Microsoft work is under NDA. ]

[ 01 / The shift ]

What changed, in one frame.

[ Before → After ]
Scattered Figma files & inconsistent UI across 40+ demo screens
Live atomic design system, one shared shell, predictable handoff
~60%
Drop in design-related support tickets
Dev team's internal support dashboard, 3 months before vs after rollout.
~3×
Faster shipping for new DREAM demos
New demos reused 70+ components instead of redrawing from scratch.
70+
Atomic components shipped
Across Foundations, Atoms, Molecules, Organisms, Templates, Pages.
[ 02 / The reframe ]

The chaos wasn't the problem. It was the symptom.

Two weeks in, I started seeing the same problem from two different angles. They turned out to be the same problem.

What I saw in Figma
  • One Figma file per demo, no shared library
  • No naming convention — "final," "final v2," "copy of"
  • Every new demo started by copying assets from the last one, then modifying
  • No design system, no tokens, no source of truth
What I saw in support tickets
  • Most tickets weren't bug reports
  • They were "how do I do this?" questions
  • BDMs couldn't navigate the demos confidently
  • The flow itself was unteachable
[ The connection nobody had named ]

The messy files weren't a designer problem. They were producing a customer problem.

Every demo was a one-off. So BDMs had to relearn every demo. So they kept asking the team how to navigate them. So the support tickets kept coming. The chaos in Figma wasn't slowing the design team down — it was slowing the sales motion down.

[ 03 / Decision 01 ]

From one Figma per demo to one system for all demos.

I restructured the file architecture around atomic design. Every component lives once, in one place. Updates propagate everywhere.

Before · one Figma per demo
📄 Demo_AzureOpenAI.fig
📄 Demo_AzureOpenAI_v2.fig
📄 Demo_AzureOpenAI_final.fig
📄 Demo_AzureOpenAI_final_v3.fig
📄 copy_of_Demo_OpenAI.fig
📄 Demo_Vision.fig
📄 Demo_Vision_old.fig
📄 Demo_Search.fig
📄 Demo_Speech_DRAFT.fig
↳ buttons replicated across files ↳ cards replicated across files ↳ nav rebuilt every time
📁 (no shared library)
After · one system, one file
📁 01 · Foundations
Colors · Type · Grid · Tokens
📁 02 · Atoms
Buttons · Inputs · Icons · Labels
📁 03 · Molecules
Cards · Nav items · Search · Tabs
📁 04 · Organisms
Top nav · Left nav · Hero
📁 05 · Templates
Demo shell · Live demo layout
📁 06 · Pages
Demo screens (instances only)
🔗 1 library · all demos consume it
File model
one per demoone library, many demos
Components
replicatedreused as instances
Source of truth
noneshared library
[ Why atomic, specifically ]

I picked atomic methodology because the demos shared most of their UI — same nav, same cards, same demo shell. Atomic lets the shared parts live once, while still letting each demo's content sit on top. A flat component library would have given us reuse, but not the layered composition the demos actually needed.

[ 04 / Decision 02 ]

From a feature grid to a story moment.

The old live demo dumped all AI capabilities on one screen with technical labels. The new one walks through a real customer question, with each capability appearing at the moment in the story where it solves a problem.

Before Feature-first, tech labels
  • All AI capabilities shown at once
  • Technical labels (model names, APIs)
  • BDM has to narrate the connection between cards
After Story-first, customer question
  • One AI capability per story step
  • Plain language, customer question on top
  • The flow narrates itself, BDM stays in story mode

"A live demo is not a feature list. It's a narrative the BDM performs in front of a customer. The screen has to do the storytelling, so the BDM can focus on the audience."

Retail AI Demo · Style Assistant
JN
Demo
Overview
Architecture
Live demo
Resources
Step 3 of 4 · Recommendation
Customer question
"I have a friend's wedding in London in August. What outfit would you suggest?"
AI reasoning
London average in August: 17°C, light rain likely. A wedding is semi-formal. Suggesting layered outfits with a structured jacket, neutral tones, weather-resilient fabrics.
Suggested looks
Tailored blazer
Stone · UK 10
Midi dress
Dusk · UK 10
Block heels
Tan · UK 6
Powered by conversational AI · weather · product catalog
Top nav

Same across every DREAM demo. BDMs learn it once.

Left nav

Same four sections, same labels, same order.

Step indicator

Shows the BDM and customer where they are in the story.

AI reasoning

Makes the AI's logic visible, so the BDM can narrate it.

[ 05 / Outcome ]

What changed once the system shipped.

~60%
Drop in design-related support tickets
Tracked on the dev team's internal support dashboard. Compared 3 months before vs 3 months after the system rollout.
~3×
Faster shipping for new DREAM demos
New demos built on the system reused 70+ components instead of redrawing from scratch. Measured against pre-system delivery cycles.
Stakeholder reception
"The new demos are easier to walk customers through."
Consistent feedback from BDMs and Microsoft stakeholders during demo reviews after the rollout.
70+
Atomic components shipped
40+
Demo screens restructured
1
Shared demo shell (nav, header, footer)
WCAG 2.1
Accessibility baseline applied
[ Looking back ]

I'd have run a structured BDM interview round before building the system, instead of validating with stakeholders after. The system would have been the same, but I'd have had user quotes anchoring every component decision — and that would have shortened the internal sell.