Proven Compliance, Measured Usability

Medical billing isn't confusing because patients are careless. It's confusing because the system hands them separate, mismatched documents and expects them to reconcile everything alone.

How I researched without interviews

I didn't have access to patients or billing teams, so I built the evidence base from published research: government and nonprofit sources first, then industry reports and vendor surveys. I tagged every source by how much I trust it, because vendors that sell billing software have an interest in how problems are framed.

I looked for patterns that repeated across different sources and years rather than relying on any single number. Treat the result as a well-sourced starting hypothesis, not as proof.

What the evidence says

Five findings repeated across sources:

• Bills are confusing to a large share of patients. In one survey of about 2,000 US adults (commissioned by a billing-technology company), roughly 38% called their bills somewhat or extremely confusing. An older survey of 355 patients found over 60% rated bills confusing, and about half were frustrated by how provider bills relate to insurer statements.
• Errors are hard to catch and costly to resolve. A survey on behalf of a payments company found fewer than a third of people felt very confident spotting a bill error, and most of those who fixed one spent more than two hours.
• Denials are common and rarely challenged. KFF reported that insurers on the federal marketplace denied about one in five claims in 2023. Fewer than 1% of denied claims were appealed, and KFF notes many people don't know they have the right.
• Challenging a denial can work. Roughly half of adults who challenged coverage denials in one Commonwealth Fund survey got some or all of the service approved.
• The burden hits providers too. Industry reports show initial denials are common and mostly overturned, and providers spend heavily on rework. Missing or inaccurate claim data is cited as a leading cause.

From pain points to design opportunities

Who I'm designing for

The strongest evidence concerns patients, so the primary user is an insured adult trying to make sense of a bill. A lighter secondary user is the billing office that receives their questions, included because a good patient experience depends on both sides.

Primary (composite persona): Maya, insured through her employer

• Goals: understand what she really owes, check whether anything is wrong, know what to do next
• Frustrations: a bill and a statement that disagree, jargon, no one to ask

Secondary (composite persona): Chidi, billing coordinator at a small practice

• Goals: fewer repeat questions, cleaner patient communication
• Frustrations: patients who are confused and upset, missing information on claims

Both are composites based on the research, not real people. The secondary persona rests on weaker evidence, and I say so.

Design principles

1. Plain language first. No codes without a translation.
2. One clear next step. Every screen ends with what to do.
3. Calm, not alarming. Say “possible issue,” never “error” or “overdue” in red.
4. The whole picture. Show what happened, not just a balance.
5. Only what's needed. Collect the minimum, protect the rest.

Information architecture

My first map copied an email inbox: a list of bills, newest first. Walking Maya's problem through it showed the flaw: a list of documents repeats the original problem, because the documents still live apart.

The final architecture is built around the care event: one visit or treatment that groups its bill, statement, estimate, and any denial into one place, with a single summary on top.

Mapping the flows

I wireframed every core flow in grey before any visual design.

• Add a bill or statement to a care event
• See what I owe and why
• Compare the bill with the insurer's statement
• Understand a denial and decide whether to appeal
• Ask the billing office a question
• Explore payment options or financial help

How to show a bill that doesn't match the statement

Problem: Patients get two documents that disagree and no explanation.

Options I explored

• A. Show both documents side by side. Honest, but the patient still has to do the reconciling.
• B. A single timeline of what happened. Clear sequence, but it doesn't answer “what do I owe?”
• C. A plain-language summary of what I owe and why, with differences flagged. Original documents stay one tap away.

Choice: C. Patients need an answer first and proof second.

How to present a denial

Problem: A denial looks final, and most people don't know they can challenge it.

Options I explored

• A. Show the denial reason exactly as written. Accurate, but unreadable.
• B. A plain-language reason plus a short list of what you can do. Includes appealing, with a deadline reminder.
• C. A chat assistant that answers questions. Flexible, but it hides the options and is harder to trust.

Choice: B. It turns a dead end into a decision. The app helps draft the message, and the patient stays in control of what is sent.

This is not legal advice: the app explains options and links to official resources.

The final screens

With structure and decisions settled, I designed six core screens with one type family, one accent colour, and an 8px grid.

1. Home. Care events as cards, each with a status and a next step
2. Care event summary. What you owe and why, in plain language
3. Compare. Bill vs insurer statement, differences flagged as “possible issues”
4. Denial explainer. Plain-language reason plus what you can do
5. Message helper. A draft question or appeal the patient can edit and send
6. Payment options. Pay now, a payment plan, or ask about financial help

All data is synthetic: invented clinics, fake amounts, fictional insurers.

One component, every state

The care event status is the heart of the product, so I built it as one component with every state defined.

• Nothing to do
• Needs review
• Possible issue
• Denied, you can appeal
• Payment due
• Resolved
• Light and dark

Care and privacy by design

Billing data reveals health information, so it needs more care than most data.

• Calm wording. “Possible issue,” never accusations. No red alarm styling.
• Honest limits. The app explains and helps; it doesn't give legal or medical advice, and it links to official resources.
• Minimum data. Only what's needed to explain a care event.
• Quiet notifications. No provider names, conditions, or amounts in notifications or page titles.
• Consent and control. Clear consent before connecting an insurer or provider, and an easy way to delete everything.

Outcomes, validation, and reflection

This is a concept built on secondary research, so I don't claim results. What I can show:

• 8 sources → 4 pain points → 6 screens → 1 reusable status component
• Planned validation: five short interviews asking: “Tell me about the last medical bill you didn't understand. What did you do next?”

What I learned

• Starting from the visit, not the document, simplified the whole structure.

Next steps

• Interview patients and billing staff to test the research
• Check legal and compliance assumptions with a qualified expert
• Explore how the app could connect to real insurer and provider data