Leveraging Research to Make Users More Productive

The billing page in BriteCore is where our users go first when they need to answer a customer’s question about their insurance bill. Even though it's one of the most used pages in the application, it hadn't changed much since BriteCore launched in 2012.

Existing research we’d done with customers showed the page had major pain points, but it wasn’t on our product roadmap to rebuild. So, I proposed that we use BriteCore’s new design system to update the page. Once this new version launched, we leveraged a mixture of analytics and user research to iteratively improve the experience.

Jump to final prototype & results

An Overview of our Process

process diagram
For this project, we focused on leveraging research throughout the design process.

Hypothesis Creation

At the outset of this project, we knew we didn’t have the resources to dramatically change our system’s billing logic. Our hypothesis instead was that: 1) The billing page was a large pain point for our customers and 2) Many of these issues could be solved with a better user experience.

Initial Validation

We based this hypothesis on research done with one client’s billing department. They were just starting to roll out BriteCore, and said these issues might hurt their adoption of the system. We wanted to help them, but also wanted to better understand first if these issues were universal, or unique to this one client.

To find this out, we conducted a series of interviews and contextual inquiries with other clients. This research confirmed our hypothesis — the problems people were experiencing were shared, and they could be traced back to a poor user experience.

initial research results
Working with our UX Researcher, Maya Carroll, we collaboratively analyzed our initial research using an affinity diagram to group shared data points.

Research Findings

A few key pain points emerged from this work:

Future Invoices

For people using this part of BriteCore, one of their main tasks is to answer questions customers might have about their latest bill. But finding the right bill could be difficult because BriteCore displayed the latest invoice in a table alongside other invoices that hadn’t been billed yet.

This meant someone on the phone with a policyholder had to first find the invoice the customer was discussing. Sometimes, there could be up to 10-12 future invoices, if the policy was billed monthly.

initial research results
To answer a customer's question about their most recent bill, CSRs would often have to find the first invoice that didn't have a date in the future, which was a painful process while they were on the phone.

Payment Workflow Efficiency

In addition to answering questions, this page is often used to make manual payments on a policy for a customer. The payment form was linked from this page, but it had to be completed in another part of the application. As a result, contextual information about the customer’s bill, like how much was currently due, didn’t carry over, requiring the user to go back and forth between these two pages.

Make payment example
The "Make Payment" button in the bottom right led to another page, where the amount due on the policy had to be re-entered. This header also shows two of the multiple date range filters on the page, which users found confusing.

Voiding Payments

Under certain circumstances, invoices can be voided. Our research showed that our users wanted to be able to do this for payments as well. This feature request was out of scope for us, but we were able to influence the product team’s overall billing roadmap, and this was recently released.

Accountant Persona

We were also able to create from our findings an initial ‘proto-persona’ to represent the users of this page.

Accountant Proto Persona
As we gathered our initial research, we created a proto-persona of an accountant user to help guide our decision-making. Keeping the persona less refined upfront allowed us to frequently revisit our assumptions about our users.

Prototype and Initial Release

Based on this research, we decided to go ahead with updating the page, and tried to solve many of the problems our users experienced:

  • Future invoices were hidden by default, with the ability to show them using a checkbox.
  • The payment form was updated to prefill common payment amounts, such as ‘total due’.
  • The entire page was updated to use our new design system.

Another designer on my team, Allison Berels, worked on this initial mockup, with both of us collaborating through the process.

First Version of New Page
The first version of the page we released used BriteCore's design system. We later learned that the larger base font size of the page made it harder for users to navigate.

Embracing Critical Feedback

Initial prototype testing went well, but after we released the page, we learned clients were having issues. Some of this related to an important feature that hadn’t been carried over to the new design. I was able to use these comments to convince the product owner that it should be added back.

The other common feedback, though, was related to the length of the page. Generally, our users prefer compact designs and are used to legacy systems where dozens of pieces of information are displayed on a single screen.

“Not happy with the new billing page, have to scroll too much to see everything.”
Feedback we recieved in a customer survey shortly after launch.

The cause of this additional scrolling was our new design system, which uses a base 16px font size. Changing this wasn’t something I wanted to consider, for several reasons:

  • More than 90% of our users are on desktop, and when sitting further from a screen, a larger font size becomes more important.
  • BriteCore’s ease of use is a market differentiator for us, and embracing UX best practices is a critical piece of this.
  • We didn’t think making the page visually more compact would really address the underlying issue.

Instead of doing this, we launched a follow-up research study to better understand the way people were using the new page.

Leveraging Analytics to Inform Product Decisions

Around the time we launched the initial version of the page, we also added a new analytics platform to BriteCore called Pendo. This tool augmented our more qualitative user research in several important ways.

Participant Recruitment

First, we were able to reach out directly to people who were choosing to use the older version of the page. This allowed us to focus our usability testing on those experiencing the most friction with the new design.

Feature Usage

Second, we were able to use Pendo’s heatmaps and usage statistics to better evaluate how the page was being used. This proved invaluable in helping convince the product team to make further changes to the layout.

Pendo usage heatmap
Pendo's heatmap view, showing more user activity in warmer colors. This information, along with our qualitative research helped drive our iterative updates to the design.

Synthesizing Research into Real Insights

Throughout the research process at BriteCore, we try to include our product team counter-parts as much as possible. For this project, this meant the product owner joined most of our usability tests, and observed or helped take notes.

Afterwards, we included her and the product manager in a collaborative research session to jointly analyze the findings.

Some key takeaways:

  • The page itself scored well on usability, with a 95% task completion rate, on average.
  • Our interviews highlighted a few workflows that could be made more efficient through a better layout.
  • Analyzing Pendo results also showed how we could better focus the page on the most commonly used features.
Results from our collaborative research workshops
Working with our UX Researcher, we ran a collaborative research workshop, where we analyzed results collaboratively with the product team and other designers. Including our product team in the research process helped create buy in for many of our findings.

Incorporating our Research Insights

After collecting these findings, I prototyped a new layout and design for the page, working closely with the product team and engineers.

Redesigned Header

Based on analytics data, we thought the header could be simplified, and we also wanted to make it more compact, to address qualitative feedback. I’m hopeful that this type of header will become a standard component for other detail pages in BriteCore.

Redesigned Header
The 'actions' in the original header were not widely used, so we moved them from here, and were able to make the header more compact and standardized.

Updated Page Hierarchy

One of the other key findings from our research was that the page could be organized in a more efficient way for our users.

Although the product team was involved closely in our research, they felt larger layout changes were unnecessary. By talking them through my thought process, I was able to come up with a solution where we consolidated less used information, in order to move up the highly used “Balance Due” summary.

We also split the page into two tabs, to better separate billing setup details from the overview information.

An annotated prototype
Through close collaboration, we were able to make the "Balance Due" summary more prominent. I used these custom annotations to better explain my design rationale in context, which was more convincing for the product team than a standard Figma prototype.

Simplified Account History

Our analytics analysis also showed that users weren’t using many of the filtering and search tools on our account history table. After further discussion with the product team, we also decided that in many cases it didn’t make sense to sort or filter against all of these fields. This led to a more streamlined design for this part of the page.

Simplified Account History
We were able to remove several date range filters and sorting functionality from this table, simplifying and focusing the user experience.

Final Prototype & Results

The culmination of all our changes can be seen in this Figma prototype, and they are being released to our clients in early July. Once released, we will monitor the number of times users are returning to the old version of the page, in order to gauge whether or not we’ve solved some of the initial problems with the redesign.

For me, this project reinforced the value of shipping iterative improvements to a user experience. It also helped us show our product team how design research plays a valuable role in the product process.