Listening to members

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.

The real question members were asking

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 existing experience

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.

From Figma to working prototype via Claude Code

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.

CLAUDE.md — briefing the AI before it builds

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 — markup
• CSS — styles
• data.js — content arrays
• app.js — behavior

It also specifies 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.

What the AI workflow taught me

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 results

We tested with real Kaiser members across a range of insurance literacy — not just people who already knew what a deductible was. Comprehension improved over the existing experience for both groups, and the gap between them narrowed, which was the actual goal. A redesign that only worked for members who already understood insurance wasn't doing its job.

Reflection

This project reinforced something I carry into every healthcare and enterprise engagement: the interface is never neutral. A claims screen that shows accurate data but explains nothing still isn't neutral — it works for members who already understand insurance and fails everyone else, in predictable ways. Designing for comprehension, not just accuracy, is an ethical call 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 aren't decorative — they're 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.