Case Study · Microsoft CE&S BI · Spring 2026
Request Intake Redesign
Unified internal request intake for Microsoft CE&S BI — one lifecycle across desktop, mobile, and Teams.
2026 · Enterprise UX · Purdue Experience Studio · Not shipped
Sponsor-Approved Handoff
Role
Lead designer
Team
7-person studio team
Scope
Desktop · Mobile · Agentic
Status
Handoff-ready
Desktop, mobile, and Agentic request intake interfaces.
How might we improve the request intake experience, so that requesters can easiely and effiecnetly submit their requests across multiple platforms and mediums.
01
Overview
Microsoft's Customer Experience & Success BI team maintains the data platform and analytics tools behind reporting for 20,000+ client accounts. Employees file two kinds of requests with them: bug fixes and PBIs( Product Backlog Items), meaning new reports, updates, and enhancements.
Sponsored Purdue Experience Studio project across desktop web, mobile web, and an AI assisted agentic worflow so this could be done within a Teams chat.
Role
Product designer
Product design, interaction design, and prototyping with research, ideation, and AI-assisted design across the full project.
Scope
End-to-end redesign
Complete redesign of the desktop and mobile request experience, plus an AI-assisted agentic workflow using Adaptive Cards inside Microsoft Teams.
Timeline
16 Weeks
One semester from research to handoff: audit, reframe, prototype, multiple rounds of usability testing, final prototype and handofff.
Outcome
Shipped to Production
Sponsor-approved prototypes and documentation, validated on desktop and mobile, currently in production.
02
Problem
Requesters picked between scattered paths and unintuitive forms — with no feedback or tracking after submission
The problem compounded at every stage. Finding the right place to submit a request meant navigating a scattered workflow across portals and tools. The forms themselves were dense and hard to parse. And after submit, the system went quiet, no confirmation, no status, no way to edit.
(01)
Too many starts
Five product-specific routes before the first useful field.
(02)
Too much decoding
Acronyms and dense groups slowed infrequent requesters.
(03)
No closure
After submit, tracking and edits felt like a different system.
Previous state · (01)
Previous state · (02)
Forms were dense, acronym-heavy, and a third of the screen given to stock photography.
03
My Role
The one graduate designer on a seven-person studio team — I anchored the research synthesis, owned the shared request model, and turned it into the design system.
(01)
Research synthesis
Lit review, heuristics, and interviews — distilled into the requirements that reframed the brief.
(02)
The request model
One anatomy — entry, details, confirm, track, edit — kept identical across three surfaces.
(03)
System & handoff
Fluent-grounded components, grid, and guidelines — packaged for sponsor development.
(04)
Sponsor cadence
Weekly alignment on field rules, routing logic, and Adaptive Card scope.
04
Research
The research focused on the gap between what requesters could understand and what CE&S BI needed downstream to route and resolve work.
Forms are easier to complete when language, grouping, validation, and confirmation are predictable — so we used those criteria to guide form structure and feedback states.
What I learnt
(01) Language & fields
Internal names helped fixers route work — requesters spent time decoding labels, acronyms, and field groups before they could submit.
(02) Structure & timing
The fields sponsors needed were not the problem — when they appeared, how they grouped, and what happened next was.
(03) Status & closure
Receipt, progress, and edit access were part of the job — not a follow-up email days later.
(04) Surface density
Desktop could carry tables and filters; mobile needed card density; Teams needed the lightest Adaptive Card touch.
We were asked to fix a form. Research showed the form was the least broken part.
05
Design Process
Four moves from research to an implementation-ready intake system — structure first, Microsoft’s design language last.
SKETCHES & IDEATION
Turning research into early concepts
We started on paper — mapping Bug vs PBI entry, a stepped form, and status tracking — before Figma Make or Fluent polish.
AI-ASSISTED PROTOTYPING
Skeleton first, paint later
We fed our whiteboard outlines to Figma Make and had a clickable flow the same week — intentionally barebones, so testing judged structure and grouping, not styling. Parallel variants let us compare fixes as fast as feedback arrived.
Tight windows meant using AI in a controlled environment sped up the design process a lot — while giving us flexibility to quickly test and iterate across different surfaces.
DESIGN SYSTEM
Building the design foundation
After the flow held, we needed a foundation that could scale across desktop and mobile — and still speak Microsoft.
1. Typography from the Fluent 2 type ramps — 17 desktop styles in Segoe UI, 12 mobile styles in SF Pro, one scale across surfaces.
2. Color as roles, not swatches — CE&S BI brand ramps tinted 50–900 for accessible pairings, with text and accent duties from the Windows UI kit.
3. Grid system — a 12-column structure on a 4-point rhythm, so components, headers, and body text align the same way on every screen.
4. Component library — Fluent patterns adopted as-is where they fit; intake-specific pieces (entry cards, status chips, progress steppers) built to Fluent’s spec where they didn’t.
06
Design Decisions
DECISION 01
Tracking, after submission.
Submit stopped being a dead end — a dashboard with status chips, updates, and editing keeps every request visible until it’s resolved.
Rd 1 · “did it go through?”
DECISION 02
Progressive disclosure
The 20-field wall became guided one-column steps that reveal detail only when it’s needed — nothing the BI team relies on was cut.
Heuristic eval + Rd 1
DECISION 03
Bug or PBI, not five routes.
Five product-specific paths and dense legacy forms made people decode the system before submitting — the hub opens with two clear actions, then platform and details.
Research + heuristic eval
What I learnt….
Desktop, mobile, and Teams share that same backbone in Solution.
07
Solution
One request model, three surfaces — each rendered at the density its context can carry.
Surface A — Desktop
Desktop hub
Desktop hub — start, filter, track, and reopen requests in one place.
Surface B — Mobile
Mobile manager
Mobile manager — cards, pinned actions, and tabbed detail for field use.
Surface C — Teams
Teams Adaptive Cards
Teams Adaptive Cards — lightweight in-channel entry. Reviewed with sponsors; in-Teams testing still needed.
TEAMS · ADAPTIVE CARDS
The same request, without leaving the conversation.
Agentic intake: message the agent in Teams, it asks for what’s missing — bug or PBI, which platform — then returns a pre-filled Adaptive Card to review, submit, and track without leaving the chat. Sponsor-reviewed concept; not yet tested in a live thread.
Different screens, one anatomy — a request started on desktop can be tracked in Teams and edited on mobile without relearning a thing.
08
Impact
Sponsor-approved handoff — not shipped. The strongest evidence is design validation: clearer intake, confidence after submit, and one reusable model across surfaces.
Quality
Better intake
Guided selection and helper text reduce guesswork at submit.
Confidence
After submit
Confirmation, status, and edit access address follow-up confusion.
Reuse
One model
Desktop, mobile, and Teams share request logic — not three designs.
Handoff
For Microsoft
Screens, rules, testing insights, and next validation steps.
“The overall design was an excellent step forward for how we collect and route BI requests.”
Thomas Spensley · Microsoft CE&S BI sponsor
“Very impressive how you were able to ship three different designs for mobile and Adaptive Cards — this creates the ability to standardize across multiple projects.”
Ded Ajumbi · Microsoft CE&S BI sponsor
The final package connected screens, system rules, testing insights, and implementation notes.
09
Reflection
This project pushed me to treat enterprise UX as a comprehension problem and an implementation problem at the same time — clarity for requesters had to survive handoff to engineering and sponsor review.
(01)
Clarity before polish
KEY LEARNING
Polish never rescued a tester who entered through the wrong door — structure did. Entry, grouping, and feedback first; surfaces after.
(02)
AI for speed, not decisions
KEY LEARNING
Figma Make put a testable flow in front of users early — but every decision that survived came from research synthesis and sponsor review, not the model.
(03)
Jargon can be load-bearing
KEY LEARNING
“LOB” confused every student tester — and routed every fixer correctly. We clarified for newcomers without breaking the language the pipeline runs on.
More Projects
More Projects
