Designing for Consequences: How Product Design Protects Users in Healthcare and Biometric Identity Systems

In regulated industries, an interface error means lost insurance coverage, a compliance violation, or compromised biometric data that can never be replaced. Anna NazarevskaSenior Product Designer, works in exactly these systems: at Keyo — a biometric identity platform with 20,000+ devices and tens of millions of scans worldwide, and at Volta Health — a student health management platform serving 25,000+ users at American universities under HIPAA and FERPA. Here, she explains how to design interfaces where every action has real consequences for a real person.

— You’ve designed products in two domains where an interface error causes real harm to real people. What does your work look like when the stakes are that high?

— Right now I’m a Senior Product Designer at Volta Health — a platform that American universities use to manage student insurance, immunization compliance, and waivers. I own end-to-end design for two core modules — insurance and immunization — from discovery through production. The platform serves over 25,000 users: students, administrators, insurance brokers, and clinical partners. Each operates under different permissions, and every action in the system is subject to HIPAA and FERPA requirements.

The way I design a flow directly determines whether a student can confirm their insurance, pass immunization compliance, or register for classes. A poorly designed rejection of a vaccination record can block a student’s access to education. An insurance cancellation without sufficient safeguards — and a person loses coverage and access to medical care.

Before Volta Health, I spent two years at Keyo — a biometric identity platform. Devices were deployed in hospitals, banks, and retail locations worldwide, processing tens of millions of scans. A user is handing over biometric data, and that’s a commitment, not a sign-up — so I designed every flow to make sure the system protected them at every step.

— How does designing for regulated systems differ from mainstream product work?

— In my work, every action in the interface carries consequences for the end users. A “reject” button on a vaccination record is a decision with an audit trail and a direct impact on a student’s access to education.

This is where proportional friction helps. Rejecting a vaccination record is reversible — a clear confirmation and a mandatory reason may be enough. Canceling insurance affects coverage, billing, and access to medical care — that requires explicit confirmation, a delayed effective date, and additional approval depending on the level of risk.

Administrators at Volta large volumes of records during peak registration periods. The goal is to place safeguards where the real risk lives, and to calibrate the tradeoff between friction and efficiency constantly.

— How did you approach designing trust in the biometric platform at Keyo?

— Trust in biometrics is structured into the product through consent flows, transparency patterns, and predictable handling of irreversible actions. At Keyo we covered the full journey — from onboarding and authentication to device management, recovery flows, and enterprise administration. Biometric data is highly sensitive, and trust, reliability, and error prevention are critical at every level.

I traveled to Texas to observe how users actually interacted with devices in their working environment. Remote research removes the environment, and the environment often is the product. On-site, I could see hesitation before interaction, confusion in body language, unofficial workarounds that staff had invented on their own. These are signals users don’t articulate in a remote session.

Trust behavior depends on context as much as on the interface. In one environment, people approached the device with immediate skepticism about privacy. In a corporate pilot, that resistance was dramatically lower. Same product, completely different trust dynamics. Adoption barriers are shaped by context and perception — and these insights from field research directly shaped the product roadmap.

— Can you walk through a specific design problem where getting it wrong would have had immediate real consequences?

— At Volta Health I designed the admin workflow for reviewing and approving student vaccination records. Every action is a structured decision flow where an approve or reject carries audit implications and affects the student’s compliance status. During peak registration periods, administrators process thousands of these records, and the design has to deliver both speed and the accuracy that HIPAA-compliant audit trails require.

We replaced a manual review process with a structured automated system that reduced errors and created a full audit trail. At the prevention level — proportional friction: every action gets safeguards proportionate to its consequences. Rejecting a record is reversible — a confirmation and a mandatory reason are enough. Canceling insurance affects coverage, billing, and access to care — that calls for explicit confirmation, delayed effective dates, and additional approval.

High-impact actions behave as state changes with a full audit history: who made the change, when, and what exactly changed. That covers both operational recovery and compliance expectations. And if a student believes a record was handled incorrectly, the system provides a clear path to request a review — in regulated environments, transparency and dispute resolution are critical.

— You’ve built design systems at both Keyo and Volta — two different products in different industries. What principles turned out to be universal?

— The products are different, but the principles behind building a design system are very similar. Foundations come before components: typography, spacing, color, sizing, interaction rules. If the foundations are solid, consistency follows naturally. Naming is built around purpose: “primary action” and “destructive action” survive product evolution, “blue button” becomes outdated the moment the brand changes.

Accessibility is non-negotiable at the component level. If accessible behavior is built into the core system, every product surface inherits it automatically. At Keyo I built the design system, introduced dark mode, and led the platform’s accessibility work to WCAG 2.1 AA, working with our legal team on compliance. At Volta I built the design system and presented it to engineering so that accessibility and compliance standards became part of implementation.

The strongest systems grow from real product patterns. If teams keep solving the same problem over and over, that’s a signal for a reusable component. If it’s a one-off, a component probably isn’t needed. Constraints are part of the value: a design system that supports endless variation doesn’t help anyone make decisions faster.

Components are the technical part, and that gets resolved relatively quickly. Alignment between designers and engineers, governance, version management, turning the system into a trusted source of truth — that’s where most of the time goes. I mentor designers through ADPList and other channels — I’m in the platform’s Top 50 mentors — and I see this constantly: the shift from making screens to systems thinking and product decision-making is the hardest part. One of my mentees transitioned from an internship into a full-time design role, and that shift was the turning point for her.

— AI is already entering healthcare and identity systems. Where do you see real opportunity, and where does AI become a liability?

— When you’re working with regulated data, every application of AI requires clear boundaries and verification. At Volta we designed an AI-powered search experience for students. Students ask contextual questions about insurance coverage, immunization requirements, symptoms, policies — and traditional navigation and static FAQs return documents, leaving students to find the right answer inside them on their own.

It’s a good AI use case because the scope is narrow and controlled. The AI interprets a student’s question and returns a plain-language answer from approved institutional content. It doesn’t diagnose, doesn’t make medical decisions, doesn’t update records, doesn’t act on the student’s behalf.

We defined upfront what task the AI solves, what sources it can draw from, and what’s explicitly off-limits — the model is constrained to curated content. The interface communicates the right expectations — AI states, contextual disclaimers, source transparency, fallback behavior when confidence is low, and an always-visible path to human support. In healthcare, trust is lost very quickly if the system sounds more authoritative than it actually is.

Users can trace an answer back to its original source, interactions are reviewed to identify failure patterns, and anything involving data changes, eligibility decisions, or compliance status stays in human-reviewed workflows with permissions and audit controls.

In my own workflow I also use AI — for accessibility audits, validating tickets against acceptance criteria, design system consistency checks, and documentation. Volta operates with regulated data, so I apply AI to processes where the output is traceable and verifiable. Judgment-heavy work — user research, design strategy, complex tradeoffs — stays with me.