Kate Xu
Case Study 01 · Reading deck
Enterprise · BofA private cloud · internal platform hosting 1,000+ apps
Cloud Service
Ordering.
Before — ordering success
11%
→
After — ordering success
34%
Context
Losing users at every step.
Engineers order hosted services through a 12-step wizard — Glassbox session data showed the funnel narrowing at every stage.
The process
12 steps to place one order.
Placement, OS, hypervisor, hostnames, NAS mounts, storage, maintenance windows — before an engineer ever reaches submit. Power users walk this every week.
The recording runs in real time — the tedium is the point.
First instinct
Can we shorten
the wizard?
If we lose users at every step, fewer steps should mean fewer losses. So I opened calls with the engineers and put every step on the table.
Drop steps entirely — which ones are truly required?
Ask later — could some questions wait until after submission?
Merge screens — fewer stops, same inputs?
First instinct · verdict
Dead end —
nothing could be cut.
I took the three hypotheses into working sessions with engineering and the PM and we walked the wizard together — step by step, all twelve.
12/12
steps confirmed required before provisioning
H1 — Drop steps entirely
Engineering, field by field: every input is a required technical parameter — placement, storage, compliance. Provisioning cannot start without them.
H2 — Ask later
Deferring any question just moves the block downstream — the build stalls until the answer arrives. Same wait, worse place.
H3 — Merge screens
The PM and engineers were right: cramming twelve steps of required inputs onto fewer screens made each screen worse, not the flow shorter.
The turn
“Which steps can we cut?”
“Who is walking these steps — what’s on their mind?”
Quantitative data showed where users left. Only qualitative research could show why — so I went to the users.
Research · setup
Two interns,
one protocol.
I staffed the study with two UX interns and directed the research. Before a single session was approved, we sat down together and aligned on exactly what data we were collecting — so every interview would produce evidence, not anecdotes.
Aligned before user research
Who counts as a power user — ordering frequency, not job title.
What we observe — time per step, re-entered configurations, workarounds, where hands hesitate.
What we listen for — hearing them talk is the priority: it’s the one thing session tracking can never capture.
What counts as a pattern — a behavior repeated across sessions, tagged per wizard step.
Research
10 solid interviews, three disciplines.
1 — Watch
Watch what they do
Sit beside real sessions — no survey, no brainstorm. Hands don't perform for researchers.
2 — Observe
Observe the patterns
Across sessions, one behavior repeated: re-entering a configuration they already knew.
3 — Listen · the priority
Listen to what they say
Glassbox already records what hands do — what it can never capture is what users are thinking. The interviews existed for this part.
Research
7/10
said some version of the same thing, unprompted
“I just want to repeat my last order — or place the same one for my teammates.”
The wizard treated every order as novel. Most orders aren't — they're repeats of a standard setup shared across a team.
Iteration
Attempt 1 — ordering on behalf.
The idea
Let one power user place a standard order for teammates — matching exactly what users asked for.
Cut at the proposal stage
Engineering review killed it before a single screen was built: every provisioning call authenticates with the requester's identity token — entitlements, quota, and compliance bound to whoever clicks submit. Separating requester from owner meant re-architecting entitlements across a dozen downstream systems. Quoted: two quarters.
Iteration
Attempt 2 — vouchers. Achievable, but ungovernable.
The idea
If the approval is what transfers, make it a thing: configure a standard order once, mint vouchers. A teammate redeems one and orders under their own identity — no wizard, no identity problem. Engineering's first read: achievable.
What the review surfaced
A voucher lives outside the platform — passed around in chat and email, it can be redeemed by someone the approval was never meant for. In a bank, an approval that travels unattached to identity is a governance gap, not a shortcut.
✕ Steps happen off-platform, outside the audit trail
✕ Risk of misuse — a voucher can be shared or reused
✕ Entitlement rules get bypassed instead of enforced
On top of that, every voucher carried its own lifecycle — mint, validate, track, expire, reconcile — firing backend calls on each redemption.
Solution
Pre-approval tickets.
A standard order requested once, approved by the tech owner who owns the AIT. The requester gets an approval email and orders without the wizard — identity stays the requester's own, so the backend is untouched.
1 — Request
One checkbox at the end of ordering
2 — Approve
Tech owner reviews under My Approvals
3 — Order
Requester gets the email — and skips the wizard
Design · entry point
One checkbox in the existing wizard.
Request pre-approval ticket — tracked in My Open Tickets
Same ordering screen as before — the only addition sits in the Summary panel.
No new flow to learn: the order they just configured becomes the template. Smallest possible surface change, biggest behavioral change.
Design · information architecture
Two new tabs — and who sees them.
All roles
My Open Tickets
Every pre-approval ticket you've submitted, with its status. You can delete one while it's still waiting — nothing else. A requester can't approve their own request.
Tech owner only
My Approvals
Every ticket requested under their AIT — approve, reject with a reason, or decide in bulk across the whole queue.
Solution · role-based access
The requester sees one tab.
Status and delete only — a requester can never approve their own request.
Solution · role-based access
The tech owner sees both.
Approve, reject with a reason, or decide in bulk across the AIT.
Impact
One path before — a branch now.
Before — one path for every order
Now — a branch for repeats
Outcomes
The outcomes.
+23%
ordering success rate after launch — 11% → 34%
−32%
average ordering time
Reflection
Dead ends led to the method.
Three walls, three turns — each one narrowed the question until the answer was the only thing left standing.
01 — THE WALL
Nothing could be cut
Engineering and the PM proved all 12 steps were required. The funnel wasn't long by accident.
→ Stop asking which steps to remove. Ask who is walking them.
02 — THE WALL
Identity couldn't move
Ordering on behalf died in review: every provisioning call is bound to the requester's own token.
→ It's the approval that transfers, not the person.
03 — THE WALL
Vouchers left the platform
Shareable, reusable, unauditable — a governance gap dressed as a shortcut.
→ Keep the approval inside the system, under the requester's identity.
Quantitative data showed what to fix. Qualitative patterns showed the way in — and the walls decided the shape.
Kate Xu · katexu.com