Elevance Health Dynamic Voice Agent
Key Words: Agentic AI, Voice AI, Service Blueprint, Workshop Facilitation, Conversational UX, Iterative Design, Healthcare AI
Most AI assistant projects start with a demo. This one started with a harder question: how do you design trust into a system that handles protected health information, makes real-time benefit decisions, and talks to people during some of the most confusing moments of their healthcare journey? Elevance Health needed to transition their existing rule-based voice assistant to an Agentic AI, and before a single line of code was written, someone had to make visible how that system would think, respond, comply, and fail gracefully. That became the Service Blueprint.
Elevance Health
Client
Agentic Voice Dynamic Virtual Assistant (DVA) Benefits Pilot Workshop facilitation, Blueprint design, Internal review cycles, Client walkthrough
Scope
My Role
UX Designer, Service Blueprint design and Figma execution lead
Tools
Figma
Feb 2026 - Apr 2026
Duration
Real Problem (a.k.a. the challenge)
Elevance Health's existing DVA operated on rule-based logic. It could follow a script, but it couldn't reason. The shift to Agentic AI meant the assistant would now need to interpret ambiguous member requests, apply compliance constraints in real time, handle mid-conversation intent shifts, and know when to escalate gracefully to a live agent.
This created a design challenge that couldn't be solved with screen flows alone:
The system had multiple invisible layers, including intent detection, response selection, policy governance, backend execution, and analytics, that all had to work together in real time
HIPAA compliance and benefit accuracy requirements governed every response, including what could and couldn't be said, such as dollar amounts vs. percentages, verification disclaimers, and error handling
The team needed a shared language between UX, engineering, compliance, and the client, a single document that could answer "what does the system do in this exact situation and why?"
The blueprint had to serve two timelines simultaneously: a tightly scoped POC for internal demo, and a Pilot for production with real members, without conflating the two
HIPAA and compliance throughout: Every response, every data point, and every error message had to account for regulatory requirements. "Usually covered at no cost" was removed, dollar amounts were replaced with percentages, and a disclaimer ("Verification of benefits is not a guarantee of payment") was added to every scenario
Agentic AI complexity: Unlike a rule-based system, the DVA's reasoning process had to be visualized, not just what it says, but why it makes the decisions it makes
Live product trajectory: The blueprint had to distinguish clearly between what was in POC scope, what was planned for Pilot, and what was deferred to Post-Pilot, without losing the full picture
Multiple stakeholder audiences: Internal IBM technical reviews required different levels of detail than client-facing walkthroughs, and the same document had to serve both
Iterative delivery under timeline pressure: Four internal review cycles across five days (Mar 6–10) before client review, with the blueprint evolving as a living document throughout
Constraints
Design Decisions
Building a proprietary design language for AI reasoning
Rather than using generic service blueprint conventions, we designed a layered visual system that made the AI's reasoning process legible to non-technical stakeholders:
5 System-Level Reasoning Layers, each mapped to a distinct function: Intent and Confidence, Response Function Decision, Policy and Governance, Execution and Backend, Analytics and Learning
7 Tone Principles defining how the DVA should sound across different conversational moments
8 DVA Response Characteristics typing every system output (Greeting, Latent, Guidance, Confirmation, Error, Clarification, Follow-up, Feedback) so the team had a shared vocabulary for design and engineering decisions
Scenario design that maps the full range of AI behavior
6 scenarios were designed to cover the spectrum from ideal to degraded system states:
S1 (Authentication): 3-factor verification happy path, scoped deliberately for POC
S2 (Identity Verification): full auth flow with read-back confirmation to handle alphanumeric mis-recognition
S3 (Specific Request): colonoscopy coverage with real benefit values, in-network and OON branching
S4 (Ambiguous Request): DVA narrowing a vague question to physical therapy through clarification, including barge-in and unintelligible utterance handling
S5 (Out of Scope): mid-conversation pivot from benefits to claims appeal, graceful scope boundary with agent transfer placeholder
S6 (System Outage): API failure with immediate escalation offer
S7 (OON Clarification): percentage-only coverage disclosure with branching for visit limits and referral requirements
Each scenario was designed with POC, Pilot, and Post-Pilot scope explicitly marked, so the simplified POC version and the full production version coexisted in the same file without confusion.
Backstage architecture as a design artifact
The blueprint's backstage wasn't just a technical spec. It was organized into three domains that mapped directly to stakeholder concerns:
Legal Requirements: 5 columns covering identity and privacy compliance, benefit accuracy, policy alignment, eligibility disclosure, and auditability
Technical Requirements: data readiness, real-time infrastructure, reliability, and governance
DVA Capabilities: coverage interpretation, cost explanation, care journey constraints, conversational understanding, and trust signals
This structure meant compliance, engineering, and UX were all looking at the same document from different entry points, reducing misalignment across a team working across multiple disciplines simultaneously.
Real Impacts
Process scale
Workshop in Chicago with Elevance Health and IBM teams to complete Service Blueprint in under 2 weeks
4 internal review cycles across 5 days (Mar 6–10), with the blueprint evolving iteratively through each
6 scenarios × 5 reasoning layers = 30+ system logic decision points designed and documented
Proprietary design system built: 5 reasoning layers + 7 tone principles + 8 response characteristics
Stakeholder alignment
Blueprint used as the primary alignment artifact across UX, engineering (BRD), compliance, and client stakeholders, replacing the need for separate documentation streams
Client review conducted using the blueprint as the primary walkthrough document
Achieved 90% completion sign-off from IBM senior leadership in client review prep session
Scope management
Successfully defined and documented the distinction between POC (lab environment, happy path only), Pilot (production, invited users, additional auth paths), and Post-Pilot (full agentic and legacy hybrid), preventing scope creep while preserving the full vision in the file
Deferred features including Benefits Explainability API, full claims appeal flow, and Pilot V2 agentic-to-legacy transition were documented and preserved for future phases
I learnt…
Designing for Agentic AI is fundamentally different from designing for deterministic systems. A rule-based assistant has a script. An agentic assistant has judgment, and that judgment has to be made trustworthy before it touches a real member's health information. The blueprint was the tool that made that trust visible: to engineers building the system, to compliance teams approving it, and to a client deciding whether to move from POC to production.
The other thing this project reinforced is that in complex multi-stakeholder programs, a well-designed artifact is a meeting replacement. Every internal review cycle started with the blueprint, not a slide deck. When questions came up about HIPAA handling or system behavior in edge cases, the answer was already in the document. That reduced friction across four rounds of review in five days, a pace that wouldn't have been possible with looser documentation.
It also deepened how I think about the relationship between UX and AI. The scenarios, the reasoning layers, the response characteristics, none of those are UI decisions. They're product decisions that happen to live in a design file. That's the territory Senior UX designers need to be comfortable in as AI products become the norm.