Billing refactor
Existing functionality - improved usability
A content-heavy project that included creating new or adjusting existing labels, updating content for all flows, headers, subheads and CTAs, new information architecture and navigation naming conventions and taking a more human approach to some of the tricky parts about billing, such as restrictions and payment failures.
You’ll learn about:
Legacy designs vs new prototype improvements
Baseline testing vs. updated usability testing - task completion skyrocketed due to label changes and design updates
Post launch analysis - All of the expected task completion rates jumped, one as high as 145%!
Problem
Legacy designs didn’t scale and online billing was a disconnected, frustrating experience.
Business goal
Improve UX to reduce calls for billing tasks that should be easy to self-manage online.
My role
I led content design. This means all content - from headers, CTAs, informational messaging, error states and more - were written, considered or edited by me. I also heavily influenced the information architecture, flows and design as I partnered with product designers.
Legacy Designs
Content issues I noted for improvements
H1 and navigation (bills) is interesting for enterprise-level account management
Account number feels hidden
Hierarchy between account number and address
Duplicating header and sub header on each card
Mentioning past due on every account
Ambiguous label: “posted on”
Large font and weight of amount due
Content that doesn’t follow style guide
Capital A in CTA
Auto Pay, not Autopay
Account details
When you selected ‘Manage Account Details’ on the main bills page, you were brought to Bills Account Details. At the top was a repeat of all of the same information, just in a full-width card.
The bottom contained saved payment methods. This is where Auto Pay is managed, but no one would like know.
Baseline usability
Before we began we did usability testing to get a baseline measurement of certain tasks. The findings did not surprise the design team.
Other findings
60% felt amount due should reflect payment immediately
80% missed messaging on confirmation modal that said it could take 24 hrs for amount due to reflect payment
71% were unable to find unenroll in Auto Pay. We had a bit of a deceptive pattern.
Other things we took away
Participants were looking for enroll in Auto Pay from the make a payment flow
The account number wasn’t apparent enough when enrolling in Auto Pay
Many participants thought they could enroll in Auto Pay from the add payment method flow
Usability heuristics
Testing helped us see where we should focus our attention to improve usability:
Visibility of system status
Error prevention
Recognition rather than recall
Aesthetic and minimalist design
Recognize, diagnose and recover from errors
Design goals
Where we planned to focus our attention:
Show pending payments in real time
Add account number and billing address to future flows for better recognition over recall
Add clearer launch points for paperless billing and statements
Eliminate bills details page and complexity of single vs. multiple billing account numbers
Add statement amount to statements table view
Add clearer CTAs and launch points for all aspects of Auto Pay
User flows
Because this was a refactor, user flows existed, which helped us prepare and eliminate steps.
Defining direction and strategy
Who: Design leadership: director, principal content designer (me!), principal product designer
How: We each started with a blank card component in Figma to re-imagine the account summary card. We time boxed for 20 minutes. Results: We were all pretty aligned in what should be on the cards and what hierarchy we should test
2 product designers focused on more “pixel perfect” vision
I (content design) focused more on hierarchy, brevity, clear labeling and CTAs
Prototype
Content updates on cards
I connected account number and billing address
Past due is mentioned only on past due accounts
Pending payments are front and center
Added launch points on card, eliminating the need for bills details page
Enroll and manage Auto Pay from cards
Followed style guideline for CTAs and naming conventions
Reduced amount due to a more reasonable size
Prototype usability
We couldn’t have been happier with the test results. They gave us the green light from leadership.
Baseline testing
Prototype testing
Heads down in Figma
This was by far the largest feature work our team has worked on together. There were lessons to be learned on organization, division of work and trust. Super duper props to Chris, Figma master! I updated all content within Figma.
API failure sample messaging
The lead developer, Thuy, was so helpful in providing all of the API failures that we had to plan for. We couldn’t have done this well without his great teamwork. (Thanks Thuy!)
Statement tab
First, to note that the H1 and navigation was updated from bills to billing. This update aligns to all of the things one can do in this section outside of paying a bill.
We also added some copy to guide them to what they can do on the page.
Adding ‘statement’ in pagination grounds users to what they’re looking at. Previously, it said “Viewing: 1 - 12 of 48”.
Right-aligning dollar amount for easy scanning. A huge win for style guide.
Previous CTA was ‘download’ but it opens in a new tab. Initially I suggested ‘view’, but accessibility preferred ‘view PDF’ so we rolled with it..
Added ‘payments’ to pagination.
To reinforce the desire to see pending online payments immediately, we included them in payment history. The tool tip reads “Payments can show as pending for up to 24 hours.”
Previously we used five bolded asterisks for data redaction. It was visually cluttered, so I suggested mid-line ellipses. This is now our style guideline for all data reduction needs.
Payment history tab
Auto Pay happy path
Revisiting some of the heuristics we planned to focus on and how they play out in Auto Pay.
Aesthetic and minimalist design
Launch point for managing Auto Pay is no longer hidden behind a more menu.
Instead of a simple on/off label, we decided to show a visual of what payment method was enrolled.
Recognition over recall
We created a standard to support the 50% of customers who identify their billing account by an account number and the other 50% who identify by an address by putting both in the heading box.
We also were consistent with informational copy under the H2 all throughout billing.
When saving a payment method, users can add a customized nickname so they can easily pick out the right method.
Visibility of status
We gave users their first Auto Pay date, here, but also repeated it on the billing card.
We reminded people that it may show as pending for up to 24 hours, repeating critical information in multiple stages in their journey.
Recognize, diagnose and recover from errors
We customized error messaging as much as was possible in the refactor, for example when someone leaves a field blank verses entering information wrong.
Please enter an account number.
Please double-check your account number.
Humanizing messaging throughout
Billing has a lot of messaging and scenarios, from restricted payment types, fully restricted accounts, inactive accounts, monthly credit card limits and more. This was the perfect time to touch up messaging, using a more empathetic approach.
We learned that payment methods can be restricted one day and unrestricted the next. Also, accounts can go into what’s referred to as “soft disconnect” for non-payment, but sometimes payments are entered into the wrong account or even delayed by mail. Empathy was critical.
Example 1:
Top was original, and this was placed under saved payment methods H2 (then called ‘stored payment methods’ - another content update I made).
Example 2:
The original lacked empathy and direction. If they can’t make online payments, how can they make payments? In the refactor we did a full-screen lockout so they didn’t start on the path of making a payment only to be blocked after effort was made. I also made sure there was no blame put on the user, that they knew what to do to resolve their blocker and continued the ‘at the moment’ language for softness.
Pending payments descoped
Once we started refinements, we learned of the API call lift it would take to show pending payments upon landing on the page. Leadership quickly descoped that from the project. Given that direction comes directly from customer data, we plan to revisit.
Impact
It was clear from the very first month that our efforts created a more user-friendly, friction-free experience. In a data pull from 25 days before launch to 25 days after launch, appropriate rates of engagement went up.
Here are a few highlights:
One time payment start - up 26%
One time payment complete - up 9%
Statement download - up 4%
Enroll in Auto Pay - up 10%
Turning on paperless billing - up 145%
Project reflection
This design-led project as we had PM staff transition. It made me more thankful for the work PMs do.
HUGE projects like this can’t be done well without an amazing dev collaboration to help define all of the possible errors or scenarios to design for. During our retrospective on this project, we all shared our great appreciation of each other and the design/dev maturity we brought to this project. Teamwork is dream work!
Content design + product design = true design partners. Our lines were very blurred here in the most spectacular way. Designers are designers!
Core team
This was a design-led project. On this team, we often blur the lines between content and product design when it comes to iteration and strategy and this project certainly fell into that camp. Including myself, there were three designers on this project.
Supporting teams:
Research
Product management
Development
Product owner
Research
Engineers
Accessibility
Analytics