KAISER PERMANENTE • REDESIGNING THE MEDICAL CLAIMS EXPERIENCE FOR PATIENT UNDERSTANDING
I joined Kaiser Permanente to redesign the member-facing medical claims experience across web and mobile, with a focus on making billing information comprehensible to patients navigating complex insurance coverage.
Kaiser had the data. The problem was that it wasn't being surfaced in ways patients could understand. Members receiving bills after a hospital visit had no reliable way to understand what they were being charged, why the number was what it was, or what to do next. The result was predictable: confusion, anxiety, and a high volume of support calls from people who weren't disputing their bills — they just didn't understand them.
Medical billing is one of the most anxiety-producing experiences in American life. The language is opaque, the numbers are large, and the stakes are personal. Most insured members have a reasonable assumption: if they have insurance, it pays for their care. Deductibles, plan phases, copays, coinsurance — these are concepts that feel like fine print until a bill arrives.
A well-designed claims experience doesn't just reduce support calls. It reduces fear. It gives people agency over something that otherwise feels completely out of their control.
Research involved listening sessions on member support calls and review of claims-related call volume data. What emerged was a clear and consistent pattern: the gap between members who understood their claims and those who didn't wasn't about education level or financial sophistication. It was about whether the interface had ever explained anything to them.
Members who understood insurance — who knew what a deductible was, what a plan phase meant, what copay versus coinsurance meant — navigated the existing experience adequately. Everyone else was lost. And the existing design made no attempt to bridge that gap. It surfaced transaction codes, remark descriptions, and clinical terminology without translation.
One member calling in had just lost a family member and couldn't understand why she owed anything on his final claim as the account holder. The system gave her numbers. It gave her nothing else.
That research anchored every design decision that followed. The question wasn't "how do we display claim data?" It was "how do we help someone understand what happened to them financially after a medical visit?"
The prior claims interface showed members a table of line items — procedure codes, charge amounts, and remark descriptions — with no plain-language interpretation. Codes like "[24] Pmt adjusted, charges covered under capitation agreement / managed care plan" appeared without explanation. Members saw numbers but not meaning. The experience assumed insurance literacy that most members didn't have and didn't need to have.
The redesigned claims list surfaces the information members need before they click anything: service date, what care was received, status, and what they owe. Status badges — Pending, Approved, Denied, Needs Payment, Payment Resolved — are visually distinct and placed consistently so members can scan the list and understand the state of each claim at a glance.
The badge system uses two slots: a primary status badge on the left indicating the insurance decision, and a secondary financial badge on the right indicating whether action is required. A card with no secondary badge means nothing is owed. The two slots together answer both questions — what happened, and what do I need to do — without requiring a click.
The list is available in both card view and table view, toggled by the member. Card view surfaces more context per claim. Table view enables faster scanning across a longer claims history. Both views open the same claim detail overlay.
Every element visible in the claims list is a properly constructed Figma component — not a collection of static frames. Each badge variant is built with auto layout, named layers, and design tokens applied to every fill, stroke, and text style. The claim card is a parent component with nested badge instances, allowing any card in the design to be updated by swapping a badge variant from the properties panel rather than editing individual layers.
The card component exposes its nested properties — badge state, financial badge state, your share amount, service date, care received text — so that any instance can be configured from the right panel without double-clicking into the component structure. This is the difference between a design system that scales and a collection of frames that has to be manually maintained.
Naming conventions follow a consistent slash-separated hierarchy throughout the file — badge/pending, badge/approved, badge/denied, card/default, card/hover, card/selected — so that Claude Code, when reading the file via Figma MCP, can navigate the component structure accurately and generate code that references the right component at the right state rather than approximating from a screenshot.
The original experience was table-only. Rather than abandoning the table entirely, the redesign preserves it as an option for members who prefer scanning a dense list — power users, those tracking a specific claim, anyone who finds cards too spacious.
The redesigned table replaces procedure codes and remark descriptions with plain-language care descriptions, and applies the same badge system as the card view. Both primary and secondary badges appear inline within each row, so status is immediately scannable regardless of which view the member prefers.
Rather than navigating members away to a full detail page, the design surfaces claim detail in an overlay — accessible directly from the list without losing context. At this level, the overlay shows the services included in the claim, each with the member's share clearly labeled, and the ability to expand any line item for a full cost breakdown.
The overlay leads with the most urgent information: claim number, status, service date, provider, and the member's total share — large and unambiguous. When a balance is due, the "View and pay your bill" button appears immediately adjacent to the amount. The action lives where the motivation is.
Reframing cost as savings rather than debt was a deliberate tone decision. A member who understands that their $30 copay comes after Kaiser absorbed $155 of a $185 charge has a fundamentally different relationship with that bill. The design makes that visible — every time, for every claim.
Denied claims require a different tone. The member needs to understand not just what they owe, but why the claim was refused and what they can do about it. The overlay surfaces a plain-language denial reason for each affected service, the appeal window (180 days), and a direct link to the appeal process.
The "Why do you owe what you owe?" section adapts its language to the claim's status — for denied claims, it explains the denial reason specifically rather than defaulting to the generic deductible explanation. The design responds to context rather than showing the same template regardless of what happened.
The mobile experience collapses the four-column card grid to a single column, with the same card component and the same badge system. No information is removed. The recent claims activity section collapses to a single carousel card. The list view is not available on mobile — card view is the default and the only option, which simplifies the experience for the context in which mobile users most commonly encounter it: checking on a specific claim after receiving a notification.
The overlay adapts to the mobile viewport with the same content hierarchy as desktop — claim number and status at top, amount and pay button immediately below, services expandable, deductible progress at the bottom. The information architecture doesn't change; only the layout does.
Returning to this project in 2026, I rebuilt the entire design system from scratch in Figma — proper design tokens, a two-layer primitive and semantic token architecture, auto layout components with named layers and variants, and a component set covering every badge state and card configuration.
I then used Claude Code with Figma MCP to read the design file directly and generate a fully functional HTML prototype. The Figma MCP connection gives Claude Code access to the actual design data — component names, token values, layer structure, spacing — rather than just a screenshot. The code it generates references your real token names, not approximated hex values.
Before writing a single line of code, I created a CLAUDE.md file in the project directory — a plain-language briefing document that Claude Code reads at the start of every session. It defines the file structure (HTML for markup, CSS for styles, data.js for content arrays, app.js for behavior), the exact color tokens, typography specifications, component dimensions, badge logic rules, and which SVG assets are available in the assets folder.
This single file prevented most of the iteration cost that would otherwise come from Claude Code guessing at design intent. When Claude Code knows the rules before it starts, it builds to spec rather than building its best approximation and waiting for corrections.
The highest-value moments in the build were not when Claude Code got things right automatically — they were when I identified what it got wrong and corrected it precisely. The badge SVG icons, the deductible progress bar segmentation, the overlay centering on mobile — these required specific, directed prompting that came from understanding both the design intent and the constraints of the implementation.
AI-assisted prototyping compresses the time between design decision and testable artifact. But the judgment about what the artifact should be, and whether it succeeded, remained entirely human.
Usability testing was conducted with actual Kaiser members across a range of insurance literacy levels. Results showed measurably improved comprehension over the existing claims experience. Members understood what they owed, why, and what to do next at significantly higher rates than with the prior design. The gap between high-literacy and low-literacy members narrowed substantially — which was the goal. The design was not doing its job if it only worked for members who already understood insurance.
This project reinforced something I carry into every healthcare and enterprise design engagement: the interface is not neutral. A claims screen that shows accurate data but explains nothing is not a neutral experience — it is an experience that works for some users and fails others along predictable lines. Designing for comprehension, not just accuracy, is an ethical position as much as a design one.
The work also sharpened my instinct for emotional context in functional design. A billing interface is not just a transaction tool. It arrives in people's lives during moments of physical vulnerability and financial stress. The plain-language cost explanation, the deductible phase tracker, the appeal guidance on denied claims — these are not decorative. They are the design doing its most important work.
Rebuilding this in 2026 added a different kind of reflection. The design thinking held up. The original decisions — badge-first scanning, overlay over navigation, plain language throughout — were sound. What changed was the execution and its reach. Previously, I would hand off this work as static screens linked together in a prototype — useful for communicating intent, but limited in what it could demonstrate. Today, I can build a working prototype with AI tools like Claude Code that functions as a real application: the overlays open, the data populates, the views toggle, the layout responds to the screen. That's more useful for engineering teams who need to understand interaction behavior before building, for product and business stakeholders who need to experience the product rather than imagine it, and for me as a designer to understand how my decisions actually function and how my audience will move through them. The gap between what I design and what I can put in someone's hands has closed considerably.
LinkedIn
Dribbble
Medium
Behance
