Healthcare

ClearCalc

Accurate, upfront cost estimates for patients

Designing a rule interpreter to replace Excel, so patients’ out-of-pocket estimates stay accurate.

My role

Interaction Designer

Turned the client brief into flows and wireframes, then built the clickable prototype and wrote interaction notes for engineering.

Requirements
Flows
Wireframes
Prototype
Interaction notes

Teammates

Rahul & Nida

Rahul led design and product strategy. Nida led visual design, the style guide and the visual handoff.

Design lead
Visual design

Timeline

8 weeks

Discovery, workflows and sketches, wireframes, then visuals and a clickable prototype.

The problem

Estimates ran on rules kept in Excel

ClearGage’s cost estimator tells patients what they’ll owe before treatment.

The provider requests an estimate from ClearGage; ClearGage runs an eligibility check with the payer via EDI; the payer sends back a benefits response, coded differently by each payer; ClearGage interprets it with rules, before in Excel sheets that were slow and manual, after in ClearCalc, a fast rule engine; then calculates price times benefits and returns the patient’s estimate — How an estimate is made, and where the rules sit

Request
The clinic asks for an estimate for a patient and a service. The service’s CPT code sets its price.
Eligibility check
ClearGage asks the patient’s insurer what their plan covers, over EDI, the standard channel for health data.
Interpret
The insurer replies in its own coded format. Interpretation rules decide which copays, deductibles and coinsurance apply.
Estimate
ClearGage multiplies the price by the benefits that apply and sends the patient’s share back to the clinic.

Step 3 is where everything depended on the rules, and where Excel was slowing things down.

What the rules do
Every insurer reports benefits in its own coded format. Interpretation rules decide which benefits apply.
Why it broke
CG Admins kept the rules in Excel. As they multiplied, the sheets got slow, hard to track and risky to change.
How I learned it
ClearGage’s documents, the Excel sheets, screen shares of admins at work, and my own research.

The real problem wasn’t any one rule. It was keeping all of them straight.

The brief

What CG Admins needed

Working with the client, I turned what I’d learned into a design brief: one goal, and the needs that mattered most.

See every rule’s status at a glance
Active, pending, suspended, retired or draft.
Know who changed what, and when
A clear history for every rule.
Replace an old rule safely
Swap in a better rule without breaking estimates.
Catch clashing rules
Spot a rule that contradicts another before it goes live.

Design brief: the goal, five business problems, five CG Admin problems and an eight-week plan — The design brief I wrote with the client: one goal, the problems on both sides, and the plan.

Mapping the work

Eight tasks, eight flows

With the brief agreed, I listed everything a CG Admin needed to do in the tool. That came to eight tasks, from creating a rule to downloading rules as a spreadsheet.

Use casesRule management, download & upload, audit trail…
FlowsOrdered steps for each task

List of eight use cases: a CG Admin wants to create, replace, delete, suspend, retire, view the audit trail of, upload and download rules — Eight use cases, each written from a CG Admin’s point of view

I then mapped each task as a flow, screen by screen. Under every screen I wrote down three things: its goal, the design problems it raised (“how can we…?”) and the design opportunities it opened up (“what if…?”). Those problems and opportunities are what I solved next.

One opportunity shaped the whole product: what if creating a rule worked like IFTTT (“If This Then That”), the app where people set up automations as simple if-this-then-that sentences? That idea pointed toward the IF/THEN rule builder.

Create new rule workflow from login through payer library and payer rules to rule creation, with goals, descriptions, design problems and design opportunities under each screen — Create new rule: each screen with its goal, design problems and design opportunities

Replace rule workflow from login through payer library, payer rules, replace and confirm, with goals and design questions under each screen — Replace rule: from finding the rule to confirming its replacement

The other six workflows: delete, suspend, retire, audit trail, upload and download. Click any to view full size.

Design problems

Two of the problems I solved

Others, like seeing every rule’s status at a glance, setting rule order, bulk CSV edits and an audit trail, are part of the final designs.

Design problem 1 · How might we

…make creating a rule quick and intuitive?

I sketched three ways to build a rule and weighed each one.

Pencil sketch of rule creation as a guided set of questions: benefit, coverage, network, action, then conditions — Sketch: variation 1

Variation 1

Pros: Creating a rule is fast.
Cons: Hard to read: a rule’s conditions feel disconnected from its effects.

Pencil sketch of rule details on top with each condition as an expandable panel of field and operator chips — Sketch: variation 2

Variation 2

Pros: Keeps a rule and its effects together.
Cons: Makes people read lots of avoidable information while creating.

Pencil sketch of conditions first, then radio groups for benefit, coverage, network and action — Sketch: variation 3

Variation 3

Pros: Fixes variation 2 and is easy to understand.
Cons: Uses system language instead of plain phrases, so it feels unintuitive.

Variation 1’s guided questions became a step-by-step wizard in the wireframes. It was easy to follow. But only a handful of CG Admins would use the tool, and they needed to create and manage rules quickly. So we chose one screen: conditions on the left, the outcome on the right.

Because one rule can change many patients’ estimates, every save, replace or retire asks for confirmation first.

The wizard: six steps to build one rule (dropped)

Single-screen rule creation wireframe with IF conditions on the left and the THEN outcome on the right — One screen: conditions and outcome side by side (chosen)

Blank create rule screen with condition fields on the left and a THEN sentence builder on the right — Where it landed: conditions build the rule on the left, and the right side reads it back as a sentence

Design problem 2 · How might we

…let admins schedule changes without confusion?

Rules often need to change on a set date. My early sketches put retire, suspend and replace on every rule, with a confirmation that shows the full rule before anything changes.

Pencil sketch of a payer’s rules list with a menu of retire, suspend, replace and history on a rule — Sketch: each rule gets retire, suspend and replace

Pencil sketch of a retire rule dialog showing the full rule and a warning that it cannot be activated again — Sketch: confirm before retiring a rule

In the wireframes we tried two options: a rule with one queued change (an activation, suspension, replacement or retirement), and a rule with many. Many queued changes made the interactions complicated, so each rule gets one upcoming change that can be edited or cancelled.

Payer rules wireframe where each rule shows a single upcoming change — One action per rule (chosen)

Payer rules wireframe with several queued actions on one rule — Many actions per rule (dropped)

Final payer rules screen with Upcoming retirement, activation and replacement badges, and an Edit replacement dialog to replace on a date, replace now or cancel — Where it landed: one upcoming change per rule, which can be rescheduled, run now or cancelled

Activate later dialog with rule name, payer and activation date — Activate later: schedule when a rule goes live

Iterating

21 sketches to 54 screens

Getting to those answers took a lot of iteration. I sketched quickly, then wireframed the strongest ideas as eight clickable scenarios, one for each use case, to test them end to end.

21 sketchesQuick variations of the key screens
97 wireframesLo-fi screens to work out the logic, structure and patterns
54 hi-fi screensA clickable prototype that set the visual theme

A few sketches: the payer library and payer rules, three rounds each

Sketch: Payer library, v1 — Payer library, v1

Sketch: Payer library, v2 — Payer library, v2

Sketch: Payer library, v3 — Payer library, v3

Sketch: Payer rules, v1 — Payer rules, v1

Sketch: Payer rules, v2 — Payer rules, v2

Sketch: Payer rules, v3 — Payer rules, v3

A few wireframes: payer rules from first version to final

Wireframe: Payer library, v1 — Payer library, v1

Wireframe: Payer rules, v1 — Payer rules, v1

Wireframe: Payer rules, v3 — Payer rules, v3

Wireframe: Payer rules, v4 — Payer rules, v4

Wireframe: Payer rules, final — Payer rules, final

Wireframe: Create rule, one screen — Create rule, one screen

Final designs

From wireframes to a clickable prototype

Nida
Designed the final visuals and handed off a style guide, visual specs and assets.
Me
Worked on the hi-fi screens with Nida, built the clickable prototype, and checked every screen kept the wireframes’ functionality.
Handoff
Interaction notes describing every element and term, so ClearGage’s PM and engineers could build it without guessing.

ClearGage payer library with counts of active, pending, suspended, retired and draft rules above a payer table — Payer library: a status overview of every rule, by payer and location

BCBS New Jersey retired rules with one rule expanded into IF conditions and a plain-language THEN statement — Rule detail: IF conditions and THEN effects, read as a sentence

Replace rule screen comparing the replacement rule with the source rule — Replace rule: the new rule shown above the one it replaces

Audit log table with date, user, payer, location, rule and action — Audit log: who changed which rule, and when

Try the prototype

Click the highlighted spot to move through the flow. Click anywhere else to see where you can click.

Outcome

A rule interpreter, built from the prototype

In eight weeks, a spreadsheet process became a clear, safe tool. The clickable prototype and interaction notes went to ClearGage’s PM and engineers, who built the rule interpreter from them.

Weeks, brief to prototype: 8
Admin tasks designed end to end: 8
Rule states managed in one place: 5
Prototype handed off and built: 1

What changed for CG Admins

	Before: Excel	After: ClearCalc
Seeing status	Scroll through sheets to piece it together	Every payer’s rules counted by status, at a glance
Writing a rule	Written cell by cell in a spreadsheet	IF conditions that read back as a plain sentence
Changing a rule	Edited in place, with no side-by-side check	Replace side by side, or schedule one upcoming change
Mistakes	Hard to spot, hard to reverse	Confirmation before big changes, and Undo after
History	No record of who changed what	An audit log for every rule

What I learned

Learn the system before designing for it. Reading ClearGage’s documents, the spreadsheets and watching admins at work is what made the IF/THEN builder obvious.

Design for the user you have. A wizard would have suited newcomers. A handful of expert admins needed speed, with safety built in through confirmations and Undo.

Zoom out before zooming in. At times I lost the thread of a use case. Going back to the workflows and the whole app kept every screen consistent.

Every estimate a patient sees depends on rules being right. ClearCalc made getting them right quick, readable and safe.