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.
An Overview of our Process
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.
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.
A few key pain points emerged from this work:
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.
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.
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.
We were also able to create from our findings an initial ‘proto-persona’ to represent the users of this page.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.