Clearview Billing | 2021

The easy way to receive, pay and track all your GE Aviation service invoicing.

My Role

Lead Interaction Designer

I worked alongside a Product Designer, a Technical Product Manager, multiple Front End Engineers, and a team of Developers. 

Project Background

Clearview Billing is a billing tool used by GE Aerospace to send and receive contracts for use, servicing, and maintenance of jet engines. The tool cycles through billions annually in revenue, and is a high priority tool used by a very highly specialized billing analyst role internally. The billing process is incredibly complicated, and between the client and GE, there is an agreement to track a number of different flight conditions that factor into how the client is billed for work needed. Essentially it’s a way to estimate/gauge wear and tear on an engine. This relies on a lot of complicated formulas that are above my head. What’s important is that this tool has several important steps - some need to be done once, some need to be done per billing period. Usually that billing period is monthly, sometimes it’s annually. The current tool didn’t support this level of flexibility. Also, as it had been built over years, it was built on a monolithic backend that made making changes to the tool a risky endeavor. Often when pushing new builds live, things would break, slowing down the team’s productivity tremendously. The process of billing already took most of each month due to the complexity and the tool’s lack of support. This is where I come in.

The Problem

To Be Specific: About 50% of the billing process currently happens offline. Users use Excel for complex calculations, and the variability of contract terms means users are handling large spreadsheets per project.

~73% of the non-automated contracts aren't automated because of the complexity of their calculations.

~27% Remaining 27% not automated because of unsupported billing features (yearly reconciliations). 

The Goal

HMW Create an easy-to-use ecosystem that is flexible enough to scale to varied contract types within the same system?

• Percent of Contracts Currently (2021) Automated: 56%

• Expected Automation by Q2 2022: 75%

• Expected Automation by 2023: 90-95%

Research

There’s no support for complex calculations

Each month, billing analysts are creating highly technical, contract dependent calculations that the system isn't setup to receive. Users are forced to do these calculations offline, manually, and have no way to show their work to clients.

A number of contract types and edge cases aren’t currently supported

While standard contract types have been prioritized, a large portion of contracts fall into a number of other categories that haven't been considered.

It’s difficult to make changes due to the current backend

Because of the monolithic structure of the existing system, engineering has had difficulties implementing usability improvements for some time prior to the start of the project.

The users aren’t always experts

The current system design isn't intuitive or user friendly to new users, and the billing analyst position sees a higher than average turnover rate. The current system lacks documentation/guidance.

Design Principles

Provide only the needed information at each step - Invoicing is a long, complicated process no matter how much automation occurs, so reducing cognitive load by only giving users what they need to complete the current task allows them to break up the task into smaller parts.

Ensure the path is clear, and clearly marked - Because the process will span multiple modules, as well as different design systems, it's important that the user be well informed about where in the process they are currently at. 

Scalable doesn't mean adding more screens - As new contract automation feature improvements occur, we shouldn't be creating entirely new pathways, but rather working with the screens we've already built.  This will improve efficiency at scale.

Invoicing User Journeys

The experience of invoicing in Clearview Billing 2.0 begins with steps that, for the time being, are out of scope for improvement, so those elements (creating a contract, setting up certain yearly values) are unchanged.

The journey is separated into four parts, across two modules (micro-services). In the first part, the user will complete a series of one-time setup steps. In the second part, the user will input periodic data and calculate/send invoices. 

Our key strategy is to lead users through the process to prevent users getting lost or resorting to offline processes.

Key Solution Elements

Billing Groups - Groups of "custom" billable entities, multiple of which can exist within a single invoice. Gives users flexibility to bill by options such as plane fleets or parameters. Essentially, this gave the billing analysts flexibility to “bundle” different combinations of variables inside of one invoice, instead of having to send a number of similar, related invoices.

Spreadsheet Formatting by Parameter - Previously, clients submitted invoices with large quantities of jet engine data formatted inconsistently. Billing Analysts spent hundreds of hours manually formatting the data to upload. We added automatic spreadsheet formatting based on the specific (read: unique) data formatting defined by the client. This would reduce the time to format tremendously.

Invoice Display Formatting - Invoice display customization options, including multi-party invoice splitting, custom headers/footers, and the option to display specific data types on invoices.

Design Exploration

Working closely with internal super users, I created a series of rapid iteration low-fidelity designs to discover where and how the designs might break the complicated flow of the billing process — it was key for me to include this small group of users in the process as they were true SMEs and involving them helped build trust in the changes we were bringing.

Discovering “Adder Severities”

During testing for the invoice configuration module, we discovered that users expected Adders, which are line items with their own escalations and formulas, could also sometimes require their own severity matrices, but this would require users to do severity work in two different places. We decided to move all Adder creation into the severity module, but keep the second, more complicated step, inside of the invoice configuration.

User Testing

Custom Variable Confusion

During a step where users needed to build custom formulas that often included variables not in the system, we added a feature called custom variables, where users could add their own variables and use them to automate calculations. However, we placed this function above the builder, because we thought of it as: create variables, build using those variables.

What we learned was that users thought of it differently — They would often start building formulas, and when they came to a point where they needed a custom variable, THEN they would want to create them.

So we flipped the function below the formula builder and users felt it was more intuitive.

Complicated Data Upload

In an early version of the flow, we had users review a segment of user input data, then upload jet engine utilization data, then review all data. This confused users because they expected to just review all data at once, so we condensed the flow.

Billing Group Empty States

The concept of Billing Groups is new to the invoice flow, and users were confused about the functionality when encountering empty states. We added descriptive text to walk users through what they can do with billing groups.

Once users understood how to get started with billing groups, they felt the feature was invaluable.

Terminology Confusion

Certain terminologies differed between the user group and our team, so we adjusted drop down options to make things clearer. For example, "Aggregate" severity level became "Fleet Level" because it made sense to users.

Final Design

Flexible Step-by-Step Invoicing

The Results - Business Impact

75% (+20%) In Automated Contracts - The number of contracts capable of automation has increased from ~50% to up to 75%, with plans to increase that number further to 90-95%

5 Days (-66%) Estimated Time to Invoice - Based on testing results, the estimated time for a user to complete the full invoice cycle has dropped from 15 days to 5 days. 

Design Handoff

Organized, Detailed, Notated

To ensure a smooth handoff to engineering, I deliver well documented handoff documentation as well as tour points throughout prototypes to breakdown functionality that requires special clarification.

Smartprice T&M | 2021

The easy way to receive, pay and track all your GE Aviation service invoicing.

My Role

Lead Interaction Designer