The IBM Cloud Billing & Cost Management team had just completed our State of Billing UX Research project (view case study); a design-led effort to build an understanding of our Cloud billing users, their needs, goals and biggest pain points.

Alongside a deep-dive audit of the as-is experience we:

Directly related to identifying the invoice experience as a primary source of pain for users was a platform-wide technical effort to unify our different cloud billing systems; a direct result of a platform built on multiple acquisitions. Because of this and the business impact we were able to demonstrate, getting stakeholder buy-in to fix the invoicing experience wasn’t a challenge.

As part of the initial research we were able to refine our billing archetypes into a specific target user, identify their core use cases as it relates to invoicing, and map them back to our previously identified Jobs to Be Done.

In collaboration with our UX researcher we identified 3 core billing personas that work in the Cost Management space.

While the responsibilities of each persona varies, there’s a good chance that all of the personas listed below engage with the invoice depending on the size of their company and the breadth of their responsibilities.

Leaders  often manage entire organizations dedicated to optimizing cloud spend, which usually consist of analysts, developers, and finance experts.

They are involved in the following Jobs…

Analysts either work in teams focused on optimizing cloud costs, or are lone wolves. They frequently have a development background, and coordinate with dev teams to analyze their costs and make cuts.

They are involved in the following Jobs…

Advocates often have a day job as a developer focused on managing resources for themselves or others in their organization. They alone are not responsible for costs, but will often take it upon themselves to alert others when they are spending money on things they’re no longer using (like ‘orphan drives’, for example).

They are involved in the following Jobs…

The Quote to Cash journey is a reflection of the many stages our developers and billing users go through when paying for their usage. It starts with locating a service and ends with paying for their usage of the service, and ultimately how they manage their payment methods.

This project focused on improving a few specific stages in the overarching Quote to Cash journey: Reconciling an invoice (primary goal) and Monitor usage (related goal).

To help the team better understand the needs of our end-users I created a few ideal flows for each of these stages; marrying what I knew to be true about our technical requirements with the needs of the end user. These flows acted as a Northstar for the remainder of the effort.

Quote to Cash Journey. Focus: Reconcile invoice & Monitor usage.

Alongside the journey mapping, I worked with our Researcher and Product Manager to synthesize the findings from our interviews into specific use cases and validate them with our customers, ultimately connecting them back to our Job to be Done statements.

Reconcile invoice use cases.

Similar to the ideal journey diagrams, these use cases would act as a critical measuring stick for the design work moving forward.

With a better understanding the user’s goals, we were also able to identify a handful of experience breaking pain points they faced on a regular basis.

Here’s what we found...

Equipped with an understanding of a billing user’s goals, use cases and pain points, I spent early phases of design exploration mapping out flow concepts for the Reconcile an Invoice job. I focused initially on ways we might minimize the overall number of steps required by the user, while making improvements to things like the page naming and content hierarchy.

Final selected flow concept.

Once the flows had been mapped, I shifted my attention to improving the invoice and invoices page. To do this, I needed to gain a better understanding of the common attributes that make up an invoice, as well as how users expected to see their charges grouped.

During our interviews we learned that most users expect the charges on their invoice to map to their understanding of our billing model. Unfortunately, this often is not the case. Unbeknownst to users there are multiple factors that go into the final charge they see on their invoice beyond the plan they’ve selected for a given service. To better understand this, I created a diagram that illustrates the factors that go into IBM Cloud’s billing model.

How services are billed on IBM Cloud.

After understanding the billing model, my next step was to determine the best way to group a user’s charges in a way that meets their expectations. To accomplish this, I mapped out various approaches we could take ranging from most granular to least granular.

Exploring how to group charges on the invoice.

With an initial perspective on the potential approaches to organizing the charges on the invoice I started creating different explorations based on each one.

Over the course of 6 months I went through 20+ iterations, making adjustments based on scope changes, feedback from Support Reps, feedback from the brand team and users.

Invoice evolution based on continuous feedback loop.

Outside of the initial recommendations I captured above in the Understanding the Problem section, a few additional improvements were identified in the sketching phase:

Before diving into the usability tests it’s important to note that a few key features from our initial designs had to be cut due to scoping issues, this includes:

These items would be prioritized for a future iteration.

After months of back and forth with our localization teams, developers and support, we were able to put together an invoice + invoice page prototype worthy of testing.

The concept tested ultimately grouped content by Service + Plan and then by Metric since providing Instance specific details would be out of scope, and separating the Plan from the service name was not possible for MVP.

Example above shows charges grouped by Service + Plan and then by Metric.

I worked with our researcher to synthesize the feedback from the user feedback sessions and translate into a final invoice template design and updated invoice page. Due to some technical scoping issues we were not able to address feedback related to line-item discounts and showing service instances; to be addressed in a future iteration.

Pictured below is an example of my final invoice template adopted for a US customer paying by Purchase Order. Worth noting, I worked extensively with the CIO office to ensure the template could be adapted to 18 different regions (and languages), any desired currency, and support both Purchase Order and Credit Card scenarios.

Along with the new invoice templates, I worked on delivering an over of the Invoices page in the IBM Cloud Billing experience. Outside of the updated visuals and layout improvements, we were able to fix bugs with the existing page and implement a number of quality of life improvements.

New single, scalable invoice template, to replace the 10+ existing invoice variations that exist across the platform and in countries IBM does business with (From 10+ to 1).

97% of users stick with the new Invoices page as opposed to reverting to the old one.

~37% decrease in visits to the invoice detail pages (a sign the new invoice works!).

2nd Place winner of the IBM Finance and Operations Client Advocacy Award.

[Coming soon]