Case Study 01 · Insurance / billing · 2026
State Farm Customer Policy Change
Designing a self-service payment experience for customers adding a vehicle to an existing auto policy.
SF Policy Change · Scroll to explore
View full ↗Problem & context
§ 01
Problem statement & context.
When customers attempts to make a policy change — like adding a vehicle — they first have to complete the process through an agent. State Farm's billing system then automatically splits the cost adjustment across remaining months, resulting in unexpectedly higher bills with no explanation. This erodes trust and drives unnecessary agent follow-up.
A new capability was introduced to let customers settle the cost difference upfront with a one-time payment. We were tasked with designing and testing the self-service experience for this experience on StateFarm.com mobile web.
Alignment & research
§ 02
Alignment & research.
After intake, the effort launched with a cross-functional kick-off meeting bringing together designers, product owners, and business partners. The session established a project timeline and aligned the team around the expected deliverables: iterative designs, an end-to-end interactive prototype, and static designs for multivariate testing.
Testing status — complete
Moderated qualitative interviews and static comprehension testing are complete. Findings and recommendations are highlighted in the Phase 2 section below. This section of the case study continues to follow the early timeline of the project.
Research Objectives were defined in partnership with Enterprise Research to ensure the work was grounded in measurable customer outcomes:
- Understand customer comprehension of payment options and billing impact.
- Identify pain points or confusion in workflow navigation.
- Assess clarity and effectiveness of content.
- Measure customer satisfaction with self-service experience.
- Determine customer confidence and feeling of being informed post-transaction.
- Evaluate impact of payment option choice on perception of value and trust.
Design process
§ 03
Design process & solutioning.
Initial exploration
I used Figma Make as part of early ideation, entering project requirements and journey context to generate initial layout explorations and pull component concepts. Each prompt iteration produced a different structural take on the same problem — surfacing two payment options, an installment table, and a CTA — which gave the team concrete options to react to in working sessions, far faster than I could have hand-sketched.
Journey mapping & cross-team collaboration
Before designing the payment screen itself, I collaborated with the Personal Auto Quoting team to document their existing user journey — specifically the last touchpoint before the handoff into the billing workflow. Mapping this current-state flow was essential: it established realistic customer expectations at the moment of arriving at the payment selection screen, and surfaced critical content alignment issues earlier on.
Quoting
Quoting
Policy Change
Policy Change
Working sessions & iteration — payment selection considerations
The design process was shaped through several rounds of collaborative working sessions with stakeholders and designers, improving upon the rapid set of AI wireframes. These sessions were used to evaluate technical proofing, layout options, component behavior, and content framing. In establishing a solid foundation for the requirements and anatomy of the experience, I compiled several displays to discuss in tandem.
Content layout & radio selection
The khaki container creates a clear visual boundary between the installment schedule and the payment option(s). Customers would be able to identify that these numbers are grouped as their current policy details. Color contrast on the khaki surface is also important — dark body text and avoiding red typographic elements.
Touch targets and progressive disclosure state management: Bordered radio buttons were the existing library pattern that highlighted interaction and defined mobile-touch targets. The primary concern was viewport constraints on mobile — with two selections visible simultaneously being critical to helping customers compare their options side-by-side. Losing one option below the fold risked customers not understanding there was a choice to make.
Installment UI — three variants for multivariate testing
The installment table was the most debated element. We advocated between allowing full transparency on page load vs. nesting the table under other elements, saving real estate and having better visualizations of the two radio selections. While the relatively dense content was integral to the narrative of what customers would be opting into — there is a risk of information overload for the sake of clarity. As the initial phase of this effort is for data gathering, we wanted to allow customers full insight into current/future installment amounts across their premium.
Ultimately, we opted into three approaches to the installment table for multivariate testing.
Inline table (baseline for prototype testing)
The installment table is displayed inline alongside the payment selection radio button, with a minimum of three rows shown on load and an inline link to expand additional rows. Selected as the baseline because the khaki-toned container provides visual grouping and constraint, differentiating from the table figures representing estimated next installments. It also surfaces the full cost-of-change impact with maximum transparency, even at the cost of additional screen real estate.
Drawer with side-by-side comparison
The installment table is hidden within a drawer. A "Compare payment options" link opens both tables in a side-by-side overlay, enabling direct comparison without cluttering the selection screen. Designed for customers who want to actively compare before deciding.
Collapsible accordion
The table is revealed only when the user expands it beneath each option. This kept the interface visually clean but raised discoverability concerns — customers who don't expand may miss key billing context entirely.
Why Version A was selected as the primary direction
Customers needed to understand that the figures in the table represent what their future bills could look like — not an additional charge. By keeping the estimated next installment (ENI) fully visible on load, Version A prioritizes transparency over compactness. The team accepted the tradeoff of increased scroll depth in exchange for reducing the risk of customer confusion about what they were agreeing to pay.
Payment review
After customers make their selection, they transition to a review screen displaying the added vehicle, payment amount, payment method, and legal agreements. Because this screen reuses existing code from another product acquisition funnel, design considerations were more constrained. The primary focus here was legal compliance in informational alerts and a thorough content review to ensure all billing disclosures and disclaimers were accurate and complete.
Phase 2
§ 04
Phase 2 — iterative changes.
Following the round 1 customer report, a clear pattern emerged: customers were able to describe the difference between paying now and paying later — the core choice was landing. They were less consistent, however, when interpreting what the displayed amounts represented, which period those amounts covered, and how their choice would affect subsequent bills. The report recommended preserving the direct comparison approach while providing more clarity in the billing timeline and amount labels.
Round 1 — key findings
- 01
The core choice was understood
71% of 62 participants were able to explain both payment options after completing the interactive flow.
Interactive flow - 02
Total added cost read clearly
In static evaluation, 78% of 104 participants correctly identified the total added cost of the policy change.
Static evaluation - 03
Current monthly cost did not
Only 48% of participants identified the current monthly policy cost — the strongest signal that the displayed amounts needed clearer labels and grouping.
Static evaluation - 04
Concept A held its ground
71% of 104 participants ranked Concept A as their preferred choice, favoring the estimated bills table over the alternatives.
Preference ranking
Key takeaway
The findings crystallized into a single principle: show what is due today, what it covers, and how each choice impacts later bills.
Three recommendations set the scope for the iteration:
- Give each amount its own label and visual grouping.
- State that the options change payment timing — not the added premium or any discounts.
- Keep critical billing context visible by default — the amount due, what it covers, and the effect on later bills — and use expansion for supporting calculations and payment schedules.
Iterated design solution
The proposed solution continues the pattern of a future installment table for customers within the payment selection. A warning note adds the context that paying today does not affect amounts already billed — bills already sent must be paid separately.
To improve clarity in the values and labels, the current policy installment was removed from the selection screen: it provided no helpful context and added confusion. It now lives in a side drawer — clicking the "View breakdown" link (the same interaction as the "How is this calculated?" text) opens a payment breakdown where each amount carries a clear label, and the calculation walks from total cost of change down to the estimated next installments for both options. These changes build on relevant labels and grouping while positioning calculations as secondary information — supporting the decision instead of competing with it.
Each amount is labeled and grouped, the warning note covers already-billed amounts, and estimated next installments stay visible by default.
Opened from "View breakdown" or "How is this calculated?" — policy change summary, then the full calculation to estimated next installments for each option.
Hand off
§ 05
Hand off.
Deliverables — the effort produced a complete set of handoff assets, including:
- End-to-end interactive Figma prototype spanning quoting to payment confirmation and communications
- Annotated design snapshot file with finalized components and screen states for development
- Static design assets for multivariate A/B/C testing across three payment option treatments
- Content-reviewed and approved copy for all payment-related screens and billing communications
Production status
The proposed design solution was agreed upon by product partners and is now in development for a production test — moving beyond concept testing. Iterative changes and future research will continue as necessary, dependent on the static design assets for multivariate A/B/C testing across the three payment option treatments.
What's next
§ 06
What's next & measuring success.
The agreed design solution is currently in development for a production test. This experience is both customer-facing and agent-facing — agents will use the same flow to help customers understand the cost of a policy change during service interactions.
What we're tracking:
- Agent contact volume related to billing confusion following a policy change — the primary signal that the problem has been reduced
- Agent feedback on information hierarchy — specifically whether the payment option presentation helps agents convey cost-of-change clearly to customers
- New customer policy bind conversion rates — how often customers who enter the policy change flow complete the bind
- Drop rates through the policy change flow — where customers abandon between payment selection and confirmation
- Heat mapping across the policy change flow — where customers focus, hesitate, and interact on the payment selection screen
Reflection.
This project reinforced how much of the real design work lives outside the design file. The decisions that shaped the final experience — payment option presentation, content framing, technical scoping, legal compliance — were made in working sessions, not in isolation. Designing for clarity in a constrained, multi-team system requires as much communication and relationship management as it does craft. The most impactful thing I did on this project wasn't any single screen — it was ensuring the right people were in the room when tradeoffs needed to be made.
Challenges
§ 07
Challenges.
Tight delivery timeline
The project carried a strict deadline requiring rapid iteration across design, content, and prototype fidelity simultaneously. The intake was received in March with an expected development start in May. Using Figma Make for early ideation helped compress the exploration phase — enabling the team to react to a broader set of concepts earlier — without sacrificing range or quality.
Cross-team content alignment
Initially, the page headers were "Make a Payment" which was the default treatment across our B&P payment selection experiences. The quoting team raised concerns that using "Make a Payment" as the primary header could negatively impact conversion rates from their flow. We also identified that legal disclaimers present in the billing flow were absent from the quoting team's screens — requiring cross-team coordination to resolve before launch.
Scope management & technical constraints
Several design asks were flagged by the product owner as out of scope for Phase 1, primarily due to the technical boundary between the quoting platform and the legacy billing service. Rather than allowing these constraints to block progress, they were documented clearly in the design file as future iteration opportunities.