Microsoft Admin Center: Billing Experience
Designing multiple Billing touchpoints for the Microsoft Admin Center
Note: Due to NDA, some designs have been omitted.
Case study focus: Product design, Interaction design, Visual Design
Timeline: 4 Months
My Role: Lead UX Designer of Admin Center Billing
Team: 3 Billing area PMs (One on the digital side, two on static invoice) Dev lead for Billing, Dev manager for Azure
Challenge:
Improve upon the billing experience of the Microsoft Administration Portal to support multiple personas (IT Admins, SMB owners, account managers, and more) to achieve their goals easily.
Problem:
Microsoft’s business clients have several different portals where they can purchase licenses, software, and services with separate billing experiences. The largest of these is the Windows Store for Business (SfB). The Microsoft Admin Center is a new platform for businesses that creates a singular place to purchase, maintain, and expense these products and services. My goal was to create a billing experience was flexible to fit all of the different product and service types while still being detailed enough to meet all of our different persona’s needs.
Understanding our users’ goals
Utilizing data we found from examining the existing billing experiences on the older portals being consolidated, and conducting user research with our clients and internal financial experts, we identified the various scenarios and requirements the billing experience should be able to accommodate.
Design Approach
From the research we gathered about the ways companies handle expenses, we separated the billing experience into two distinct touchpoints to enhance the overall billing experience for our users:
Static invoice
Serving as a snapshot of the billing information at the time it is generated, the static invoice is vital for legal and tax needs and provides a high-level overview of the charges.
Interactive Invoice
Enabling bill reconciliation and bill payment, the interactive invoice allows users to delve deep into specific charges and their subcharges, and shows the status of the bill and lets users pay if needed.
Tax needs
To help our users manage their tax needs, I designed the static invoice, a PDF that lists all expenses at a high level that is sent out assign account owners of organizations. From our research we found that usually these reports are printed by companies and stored in filing cabinets as a paper trail in time for filing taxes, or in case of audits. Both scenarios are typically handled by accounting departments, account owners, and sometimes legal teams. When designing the PDF, I wanted to make sure readers were able understand billing details quickly while still being legally compliant for tax purposes. This led me to focus on displaying high-level charges and leaving off more detailed charges beyond what’s legally required as those details would get in the way of its primary use case.
Header
1. Many corporate offices do not print invoices in color, so I had to be careful when deciding which brand colors to use to draw the eye to categories & titles.
Body
2. Companies set up their organizations into different “projects” that they name how they see fit (usually by department, function, or location) so they can better understand who is utilizing and paying for items.
3. The layout and design of the static invoice needed to be flexible to support right-to-left languages, multiple currency types, and work for multiple types of products.
Footer
4. The header and footer page both contain how to pay instructions as we found often times our users don’t print out the first page.
Bill reconciliation
The digital invoice lets users know the status of their bill, pay it if needed, and gives them a detailed view of their charges without overwhelming the user with too much information. I kept the design consistent with the static invoice to allow users to have a cohesive picture of their invoice when they compare the two touchpoints side by side.
The digital invoice lives in both the Windows Store for Business and the Microsoft Admin Center, so it needed to have a layout that would feel at home in both locations utilizing their two different design systems: Fabric and Fluent.
Microsoft Store for Business - Fabric Design System
Microsoft 365 Admin Center - Fluent Design System
Products need to be able to show 4 levels of details of subcharges to help our users reconcile their charges.
From examining our product catalogue and speaking with our users, we found that the vast majority of users needed to dive 4 or less sub-levels deep into a top-level charge to understand enough for what their purposes. If users needed more advanced ways of analyzing their bill there is a link to the Azure Cost Management system. For most of our users in-depth analyzation tools overcomplicated the UI and interfered with their journey so I opted to keep that complexity out of the Interactive Invoice.
With all these charges and subcharges, invoices can often be hundreds of line items long. To make sure I was creating easy to follow navigation and avoid having users becoming lost in their invoice, I tested a variety of navigation methods across invoices types from simple 1 or 2 item invoices to invoices with many multi-level charges.
An older navigation exploration where the invoice is broken up into projects using an L3. I moved away from this design as it complicated the users ability to search the invoice to search for an invoice and also interfered with the ability to look at two items in different projects, which was a common use case.
Bill payment
While many of our users have on auto-pay enabled for their invoices, many users manually pay their invoices on a monthly or quarterly basis. Bill payment can be done through a variety of payment instruments: ACH transfers, CC and Debit Cards, and Azure Credits, a pre-paid credit our clients can purchase that can only be applied toward Azure product and services, similar to a pre-paid cell phone plan. When creating these payment flows, I needed to make sure the payor understood why invoices were Azure Credit eligible, as well as designing for edge cases such as credit checks and credit increases.
When the user wants to pay with Azure Credit, there were many different scenarios to consider.
On an invoice thats only partly coverable with Azure credit, users are told how much of the invoice will be paid.
If users bill cannot be fully covered by Azure credits, whether it be because:
1) the items on the invoice are not eligible
2) the payor does not have enough credits
the user is informed how much will be left to pay and that they will have an updated invoice generated in 24 hours.
Retrospective:
We measured success for the project by examining the amount of support calls we received about billing. Measuring the amount of calls from before the experiences launched to 6 months after the launch, we found we had created a 10% reduction in billing related support calls.
Over the course of 4 months, I created a billing ecosystem that allows users to easily access their billing tax documentation, understand their invoice charges at a high level and detailed level, and pay their bill in a variety of ways.
Throughout the project one pain point was convincing stakeholders across various organizations of design decisions and making tradeoffs with them. We would often have circular conversations about many design ideas and formatting methods that would work for one product type, such as 3rd party items in the IT Admin Center, that wouldn’t work in other scenarios. This led me to creating an easily understandable well-documented requirements guide to show stakeholders why certain solutions wouldn’t work to avoid these conversations as well as to be a reference for later.