Microsoft internal request system.

• 01

  Project leadership

  • Led the weekly sponsor reviews on field rules, routing and Adaptive Card scope.
  • Led both rounds of usability testing, and presented the work to the CE&S BI team.
• 02

  Product strategy

  • Distilled the research into three requirements: request tracking, feedback after submit, and a simpler form.
  • Kept one request model across desktop, mobile and Teams.
• 03

  Design

  • Owned the request model: entry, details, confirm, track, edit, the same on every surface.
  • Fluent-grounded components, grid and guidelines, handed to CE&S BI engineering.
• 04

  AI prototyping

  • Ran the AI-assisted prototyping in Figma Make that the first test round used.
  • Built the Adaptive Cards from JSON with the two teammates who code.

1. 01 · Literature reviewFive rules for a good form.

   The reading gave us five rules for a good form.

   We read up on form design, decision-making and cognitive load, and sorted it on an affinity board. Five principles came out: plain wording, a logical order with clear sections, feedback, helpful error messages, and the right input for each field. We judged the old form by them.

   
2. 02 · Heuristic evaluationWhere the old form broke them.

   The old bug form broke our own five rules.

   We walked through filing a bug on the old form and marked where it broke those principles. Three problems: acronyms like LOB, MBR and QBR; related fields, like the reproduction and error details, kept apart; and a crowded two-column layout. So: grouped sections, in one column.

   
3. 03 · Competitive analysisStatus you can read at a glance.

   Good tracking tools make status readable at a glance.

   From screenshots, we compared ticketing tools (Salesforce, Jira, Zendesk, Freshdesk), dashboards (Trello, ClickUp, Smartsheet), BrightWork 365, which Microsoft uses internally, and bug report templates. Three patterns carried over: color-coded status chips, clearly categorized fields, and long forms split into groups.

   
4. 04 · User interviewsFields that didn’t say what they wanted.

   The fields didn’t say what they wanted.

   We interviewed one Microsoft employee and two students acting as requesters.

   • Input field confusion

     The Microsoft employee explained the issue in the open Description box and ignored the other formatted fields.

     So we kept the open Description field and moved the rest into grouped sections.

   • Field ambiguity

     “Business Target Date” and “Expected Completion Date” weren’t clearly different.

   • Redundant guidance

     Placeholders repeated the field label instead of giving an example.

     Round 1 found the same gap at the title field (Validation, in 04).

• Language & fields

  Internal names helped the fixers route work. Requesters spent their time decoding labels, acronyms and field groups before they could submit.

• Structure & timing

  The fields sponsors needed were never the problem. The order, the grouping, and what happened after submit were.

• Status & closure

  Receipt, progress, and edit access were part of the job, not a follow-up email days later.

• Surface density

  Desktop could carry tables and filters; mobile needed card density; Teams needed the lightest Adaptive Card touch.

1. 01Answers problem 01: Four paths in

   Two entry points: bug or PBI.

   The hub opens with two clear actions, then platform and details.

2. 02Answers problem 02: Too much decoding

   The dense form became guided one-column steps.

   Detail appears only when it’s needed, and acronyms are spelled out on first use.

3. 03Answers problem 03: Stopped at submit

   Submit stopped being a dead end.

   Status chips, updates and editing keep every request visible until it’s resolved.

BeforeAfter

WebDesktop hub

Start, filter, track, and reopen requests in one place.

01030203

Watch the desktop walkthrough · 0:28

MobileMobile manager

Cards, pinned actions, and tabbed detail for field use.

01030203

Watch the mobile walkthrough · 0:23

AgenticTeams

The agent pre-fills the request in Teams. You submit it.

Microsoft is bringing Adaptive Cards to its agentic workflows: cards that pre-fill a request for you, in Teams, in Outlook, and beyond. We built ours in Teams. I co-designed the flows, and the cards are built from Adaptive Card JSON.

Three steps, all in the chat.

1. 1YouMessage the agent in Teams.
2. 2AgentAsks for what’s missing, then pre-fills the card.
3. 3YouReview the card, submit it, and track it.

How the agent behaves

• It asks only for what it can’t tellBug or PBI, which platform, and which report. To track a request, which request.
• It fills the card for youA pre-populated form card arrives in the chat, and you add the details it couldn’t know.
• You submit, not the agentOnce every required field is filled, you review the entries and submit. A confirmation follows, with a card to view the request.
• It knows when to stopIf it still can’t tell after a few tries, it stops asking and sends you to the web app.

Three cards: Form, every field a new request needs, in a clear order; View request, the status at a glance, the details one step away; Edit, pre-filled, with the longer fields folded.

Built on the Microsoft Teams UI Kit and reviewed with our sponsors. Usability testing of the agent is the recommended next step.

Teams agent · Track

You message the agent, it asks for what’s missing, and it returns a pre-filled card to review, submit and track, without leaving the chat.

Words, fields and help counted on the team’s own screens, before and after.

• 01

  Meet users where they are

  Iteration and AI prototyping are fast now. Listening is still the step that matters. In enterprise UX that means learning exactly what people are used to, and redesigning around it, not around best practices that don’t fit them.

• 02

  Own the product

  This was an internal Microsoft tool. Before recommending anything, I learned it inside out, and that is what let me be bold with people who had used it for years.

• 03

  Collaborate, and ask

  We were a seven-person team, so we started by recognizing each person’s core skills and worked together around them. Then we asked our stakeholders for what we lacked: developers, walkthroughs, users to test with. That took steady communication with the platform owners and our sponsor.

• 04

  Establish context

  Making it easy for the requester started with context: for the team, for the sponsors, and in every screen we shipped.