Microsoft Invoice

Case study

Project description

I was given the opportunity to redesign the invoicing system used by suppliers to Microsoft. It currently facilitates 100,000+ suppliers who submit over a million invoices per year.


Lead UX Designer


The "Classic" experience

Hitting the ground running

When I began the project, the development team had already started production on an invoicing experience that had been segmented into eight separate steps (below), much like personal accounting software. It was an acceptable approach, but the redesign was supposed to replace a decade old "Classic" experience that had advanced enterprise functionality.

To get an understanding of how the current systems worked, I watched some moderate to advanced users create invoices with the "Classic" experience. There was a lot of manual work, like manually categorizing and adding details online items that were already in another system. Users were slowed down by extra steps and UI that was tacked on afterwards. With that in mind, it was time to go back to the drawing board, with a focus on how to speed up the workflow.

What was in development

The ramp up

I transitioned into research mode, which consisted of:

  • Reading documentation on current Microsoft financial systems
  • Technical discussions with developers
  • Gathering information about the user base
  • Discussions with Program managers
  • Discussions with users

Initial design process

From the ramp up, I developed several hypotheses:

  • If a purchase order could be associated with an invoice at the start of an invoice creation, a lot of data could be pre-populated from the purchase order (PO) system.
  • Using data from other systems could expedite the process as well, including supplier profile, payment system data, and potentially even previous invoice submissions.
  • Based on the optimizations above, the minimum number of reasonable steps was four.

Optimized workflow

Usability research plan and script

Usability testing

Upon creating the optimized workflow, I needed to validate the assumptions. I began by mocking up the system using a set of pre-built components in Figma, and supplemented it with building blocks from the Fabric design system. I then wrote a research plan, which involved testing with internal users using a functioning prototype with FramerX.

Prototype built with FramerX


After walking through the prototype with various users many times, it became clear that there weren’t any major roadblocks in the workflow, but there was still room for optimization. The development team also learned a lot from watching these sessions, as they were able to identify additional required functionality that was not currently on their radar (for example, more complex line item editing).

Visual Design

Interaction design

Help toggle for new users

Advanced line item editing

Collaboration with engineering

A good deal of time was spent working on a design integration strategy with the engineering team. We devised a phased approach that would have minimal impact on the work in progress, and allow everyone to become familiarized with the Fabric design system.


Back home