Appeals and Grievances

Complexities

• No requirements, short turnaround time. There was no BRD, no existing flow, and not sufficient time to run a discovery phase before the demo meeting.
• Domain knowledge lived in people, not documents. A&G rules — timelines, escalation triggers, reviewer roles — were accessible via SME interviews, but did not live in existing team artifacts.
• Multiple reviewer roles, one case. Nurse Reviewers, Nurse Managers, and Care Coordinators each touch an appeal at different stages with different authority.
• A design system that specified components, not behavior. The system defined components, typography and color palette. It did not define system or interaction design — when a form is inline versus modal, how confirmation works, what a destructive action does. Without clear instructions or guidelines, Claude Design made its best guess.
• Ensuring cross-platform consistency. With two existing products within the company's ecosystem, consistent interaction patterns were vital for enterprise-level package sales where users are toggling between multiple integrated platforms in a given workday.

Process

Appeals and Grievances is the escalation path a member takes when disputing a coverage decision. Cases are set against regulatory guidelines and CMS turnaround deadlines. Given the regulatory constraints, it was vital that we leaned on SME input to accurately calculate case expiry and when to surface dormant or priority items.

SME interviews with Nurse Reviewers, Nurse Managers, and Care Coordinators informed the A&G workflow — intake, clinical review, determination, escalation paths and NCQA requirements around response times. These insights became the BRD.

A BRD paired with a flow chart and the design system provided three essential inputs for the AI prompt: what the product needed to do, how a case moves through it, and how to draft a UI in alignment with existing products' look and feel.

Claude Design built the flows and applied the design system with high fidelity, producing working screens in a fraction of the time a manual first pass would have taken. The team found bugs within the tab functionality but were still able to use the code provided by Claude Design as a jump point. Developers were able to focus their time on specific, complex engineering problems instead of investing a large portion of their bandwidth to get basic functions up and running.

When it came to interaction design, some manual reconciliation in Figma was required to close the gap between the Claude Design output and the established system design of the company's existing Care Management and Utilization Management platforms. The components were correct; the behaviors weren't always — inline forms where our platforms use modals, and similar mismatches. Within Figma, I manually created screens that aligned with the existing system design and passed it to dev for implementation into the prototype.

The learning: a design system alone is not enough input for AI-assisted implementation. To create high fidelity outputs that match both UI components and interaction design, authoring interaction guidelines the AI could reference ("Skills" in Claude Design) was a necessary step to avoid manual adjustments on the backend. Consistency across a product suite lives in interaction and system design documentation — and if that documentation doesn't exist, the AI will invent something reasonable and wrong. When it comes to prototyping with AI, I now treat that documentation as a required deliverable, not a nice-to-have.

Results

The prototype was completed in time for the sales demo and led to a contract which funded the formal build of the Appeals and Grievances platform.