BLUE SHIELD OF CALIFORNIA
Single Check Out
TOOLS
Figma, Jira, UserZoom, Components, Hi-fi prototyping
SYNOPSIS
UX Design responsive web solution for data detected problem indicating the desire to pay for multiple plans (Medical, Dental, Vision) in a one-time payment, including A/B testing research
TIMELINE
4, 2 week sprints, total of 2 months
ROLE
Senior Interaction Designer
USER TESTING
Our team engaged our internal UX Researchers to perform an A/B test with 3 new prototypes that varied in method of how a member is able to select the payments they'd like to make and our at-the-time current payment handling experience as a baseline.
PROTOTYPE A
The member can choose to pay for the current plan they're currently navigating through on the portal or for all plans that have a balance due in 1 payment.
PROTOTYPE B
The member can pick and choose which plans they'd like to pay for.
PROTOTYPE C
The member can choose to pay for all plans or they can open the second "Select premiums" accordion where they will then pick which plans to pay for.
PROTOTYPE A
Rated 4.04 out of 5
PROTOTYPE B
Rated 4.31 out of 5
PROTOTYPE C
Rated 4.19 out of 5
.png)
.png)
.png)
FINAL HAPPY PATH VIDEO
We reached the end of our design process and accounted for error scenarios and finally we were read to push it live in the next release.
MEMBER USE INSIGHTS
We gleaned insights from the first 30 days (12/20/22 - 1/20/23) of live activity and examined the funnel.
We found that once entering the single checkout experience, only 408 members bounced. Members found the interface intuitive and easy to understand as evidenced by the .26% that dropped between the plan selection page and the payment form. Our success can only be attributed to the validating User Research and fantastic problem solving teamwork and critical thinking.
THE CONTEXT
Blue Shield of California regularly reviews and catalogs comments from members that provide guidance for the Product and UX teams prospective projects. Prior to this project, our Digital team launched an initiative allowing members to switch from one plan to another with only a drop-down. After this initiative, feedback from members saw growth in this feature, requesting to pay all of their plan balances in 1 payment.
"Honestly, it seems cumbersome, fragmented & annoying to have to have separate accounts with you for health insurance & dental insurance. Especially since I was getting messages from you on my health insurance account about being late for my December payment for my dental insurance (which I wasn't allowed to pay there, I had to create a dental insurance account. Only, when I did that, it said I didn't own any money. It makes my head hurt.)"
"Combine all my accounts on one so I don't go to the wrong account when I want to pay my dental. It is a horrible website. Thank you"
Working with both the Product and Development teams, we aimed to create a seamless experience for our members, that was intuitive. We intended to provide members with a simple way to get in, pay all of their bills, fill in their payment information 1 time, with no extra steps.
Our team consisted of myself, Senior Interaction Designer, alongside a Visual and Content Designer at BSCA. I coordinated requirements with the Product team, as well as hand-off and review rounds with the Development team. The research was performed by BSCA's UX Research team.
After receiving the initial project scope and context, I brought on our Visual and Content Designers to get a sense of the work load for the UX team. We planned for user flows, user testing, as well as error states and messaging.
We created our first iteration of designs and presented them to both the Product and Development teams.
THE TASK & APPROACH
THE GOAL
THE RESULTS
All of these experiences had a success rate of 85% or higher. This gave us great confidence no matter what way we moved forward.
Members rated the experiences on "ease of completing tasks" out of 5.
The baseline (the existing experience) was rated 3.65 out of 5.
Some other key insights:
-
50% of users picked C as their preferred experience. While members may choose what they prefer visually, we couldn't ignore that Prototype B won out in actual ease of use.
-
Responders who were 65+ (10 users) preferred C but overall ease ratings were lower here. This is expected in this demographic.
With the data behind us and a Research presentation to key stakeholders, we earned ourselves more time and resources allowing us to move forward with Prototype B.
DEVELOPER HAND-OFF
Well, let's be realistic, we didn't just "hand-it-off." That implies we passed and dashed! We stuck by our development team providing feedback through their entire process addressing any issues and error states that came up along the way. While I'd like to include all of the issues we faced, I'll give you a few of the main highlights.
ERROR MESSAGES
Creating and mapping error messages required in-depth partnership between the Interaction Design, Content Design, Product, and Development teams. First, the development team audited all errors coming back in the code. We then partnered to understand what each error really meant and which errors required the same action item to resolve and thus could be combined using one message. We then crafted a user friendly messages to provide the issue to the member and give them next steps while trying to avoid creating additional abrasion.
When a member has no amount due or is unable to pay for a specific plan due to one of the following reasons, the plan is grayed out. Upon click of the arrow, the follow message slide out and below.
SYSTEM ERROR
Displayed to a member when we have a service issue on the page.
MAXIMUM PAYMENT
Displayed when payment due is larger than what is able to be processed.
ACCOUNT BLOCKED
Displayed when a credit or debit card in the member's saved "Wallet" has expired or when a members bank account has previously triggered an insufficient funds error.
ACCOUNT BLOCKED - VELOCITY REACHED
Displayed when too many payments have been made within one billing cycle.
NO PAYMENT REQUIRED - FUTURE BILL
Displayed when no payment is necessary but future details are available.
NO PAYMENT REQUIRED - NO FUTURE BILL
Displayed when no payment is necessary and a future bill is not available.
We also addressed improper card details on the payment form page, and error scenarios when at least 1 of the payments in a multi-plan payment fails.
Each payment, while only requiring one entry of payment details, is run separately as Subscriber IDs are linked to their own confirmation numbers. This threw in an interesting twist on our confirmation pages but was easily solved for by labeling which plan payments were unsuccessful.
NEXT STEPS
If you’ve made it this far, thank you! There's a lot going on here — not too much more I promise! Looking to the future, we have a few next steps on the road map.
-
Expand to the native app: This initiative was only scoped for responsive web. While we designed for all screen sizes, our development team did not have the native app resources to implement on iOS and Android. Luckily, this experience is easily adaptable to the BSCA app as we've already designed for the small 375 resolution screen.
-
Update old and include new error messaging: The entire billing and payments flow, both existing and the new single checkout flow needs a content re-vamp. We're already in talks about completely auditing and rewriting all old and untouched error content. In addition, wherever we see new errors we hadn't accounted for, we're updating as needed.
-
FAQs: If feedback or comments arise around specific problems or interest in the functionality, we've suggested implementing a "Frequently asked questions" page that address these problems.
-
Monitor abrasion points: Along the vein of frequently asked questions, if we find members struggling in the flow, we plan to address these pain points as they arise and prioritize in order of commonality.
-
Payment receipt: The payment receipt is currently just a PDF, so we've suggested a re-design of this receipt for a more user-friendly look and feel.
-
iOS Applepay: The current experience doesn't allow members to use Applepay as it's a strictly responsive web experience. Once we've implemented the experience in the Native app, we've suggested implementing Applepay when available for members.
-
"Wallet" use: Following the lead of Applepay, we've recommended incorporating the "wallet" (The company's version saved cards) into the experience. This will make the payment form a much simpler experience. Hopefully this will also address the drop off between the payment form & review payment pages.
-
Update the existing payment flow: When a member elects to pay for only the plan they're currently on the portal for, they're routed to the existing 1 plan payment flow. We've suggested a UX re-design of this flow to match the look and feel of the new Single Checkout flow and implement new and more intuitive affordances. We are looking to include this on the road map next year.
INITIAL DESIGNS
We looked at other insurance sites that had the possibility to pay for multiple coverage plans as well as other billing sites. On these other sites users are offered options to pick and choose what to pay for at one time. We designed and gave our initial presentation using existing Design System radio selection components. We received feedback regarding our potential development limitations mainly due to time constraints. Giving the member the option to pick and choose the plans they wanted to pay for seemed out of reach. With limited time to develop, our ideal solution was potentially too heavy a load for our development team to deliver.
This prompted our team to create 2 alternatives to our original design for user testing and potentially garner support from stakeholders for either more resources or more time.
