Cerebral

Insurance Cost Transparency: Surfacing Estimates Earlier in the Funnel

Role
Lead Product Designer
Duration
March 2026
Team
Growth

One of the most consistent friction points in Cerebral's insurance onboarding flow was also one of the most solvable: users didn't know what they'd pay until they were deep into checkout. By that point, the surprise cost (whether a copay, a platform fee, or both) was enough to push them out of the funnel entirely.

This project moved insurance cost estimates to the front of the experience, surfacing pricing information early enough to set expectations, reduce anxiety, and keep users moving toward booking. The feature is live on cerebral.com.


The entry point for Cerebral's therapy flow was cerebral.com/find-a-therapist. Before this project, the page had no cost estimate functionality. Users would begin browsing therapists with no sense of what their insurance would actually cover or what they'd pay out of pocket. That information only appeared later, deep in the checkout flow, long after a user had invested time finding a therapist they liked.

Drop-off data told the story clearly. The steepest abandonment in the search and schedule flow fell at the insurance question: the moment users were asked for their coverage details before receiving anything in return. They were being asked to give information without getting anything useful back.

The pain points were well-documented across multiple signals:

Users weren't necessarily leaving because the price was wrong. They were leaving because they didn't know what the price was, and the uncertainty was enough to stall them.

Before

Before

After

After


Sole product designer. I worked cross-functionally with a product manager, engineering, legal, and clinical operations across the full design lifecycle, from early discovery through final handoff. The entire project was scoped and delivered within a single two-week sprint.


Timeline

The project was scoped to one two-week sprint. That compressed window shaped design decisions from the start, including a deliberate choice to limit the number of response states in the first pass to reduce engineering lift, with a plan to expand them in future iterations.

Sohar integration

Cerebral was already using Sohar, a real-time insurance verification platform, deeper in the flow. This project brought that integration earlier in the experience, using a part of the Sohar product we hadn't tapped before. Competitors were already using Sohar in this way, which informed both the decision to pursue it and the confidence that it was technically feasible. The data Sohar could reliably return shaped what we could responsibly surface: not exact figures, but directional estimates that were honest about their nature.

Legal review

Because we were surfacing cost-related language in a healthcare context, every response state went through multiple rounds of legal review. Early versions used more specific cost ranges, but legal had concerns about stating figures we couldn't guarantee. The copy evolved significantly through that back-and-forth, landing on framing like "estimated copay," "avg copay per session," and "max estimated cost." This was framing that was honest about uncertainty while still giving users something concrete enough to act on.


The "Get a cost estimate" entry point

The centerpiece of the redesign was a short form added to the find-a-therapist page that asks users for their state and insurance information upfront. In return, they immediately receive a cost estimate before entering the full flow. This rebalanced the exchange: users give information and get something useful back right away, rather than being asked to commit before understanding the cost.

Flow with arrows

A full response state system

Because insurance data is never perfectly clean or complete, I designed four distinct response states to handle every possible outcome from the Sohar verification:

In-network Found In-network Found
Coinsurance: Met Coinsurance: Met
Coinsurance: NOT Met Coinsurance: NOT Met
Error Error
Medicare or Medicaid Medicare or Medicaid

For users who selected "cash pay" as their insurance option, the flow bypassed the estimate entirely and routed them directly into the therapy intake questionnaire, removing unnecessary friction for users who already knew their path.

Cash pay flow

Copy and framing

The design challenge here was as much about language as layout. "Your estimated copay" vs. "max estimated cost" vs. "avg copay per session" each carries a different implication about certainty and what the user should expect. I worked closely with legal and the PM to define which framing belonged in which response state, and designed the UI to reinforce the right level of confidence without overpromising.

Responsive design

All screens were designed to scale across mobile and desktop. The experience translates cleanly across device sizes without sacrificing clarity or usability at any breakpoint.


The bulk of iteration happened on the response screens. Early designs used more specific language and a broader set of response options than the first release could support. Two rounds of feedback shaped the final direction: legal pushed back on cost specificity, and engineering pushed back on the number of states scoped for the initial build. Both constraints led to tighter, more focused designs. The final screens are leaner than early explorations, and clearer for it.

Competitive analysis informed the project throughout. Because other platforms had already solved a version of this problem, I could reference existing patterns and focus design energy on how to adapt them to Cerebral's specific constraints and user context rather than starting from zero.


This project was a good reminder that the hardest design problems in healthcare aren't always the interaction problems. They're the language problems. The layout came together quickly. What took time was finding copy that a lawyer could approve, an engineer could build, and a user in a stressful moment could actually understand and trust.

The constraint of a two-week sprint also clarified priorities fast. Knowing we couldn't build everything in the first pass made the scoping decisions easier: launch a focused, well-designed first version and expand from there. That discipline shows in the final product.