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.
Role
Lead UX Designer
- Help Program Managers to define features
- Conduct usability research
- Information architecture and copy
- Visual and interaction design
- Development collaboration
Stakeholders
- Finance management team
- Program Managers
- Development teams
- Internal invoice processing staff
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
Learnings
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).
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.
Conclusion
- Number of interactions required to submit an invoice reduced by at least 75% on average
- Time to submit an invoice was substantially less during user testing
- Once in use for a year, Microsoft's cost per invoice metric is expected to drop substantially
