Why This Mattered
MFA wasn't just a feature request. It was a dealbreaker.
Multiple healthcare organizations were holding off on adopting the platform entirely because it lacked multi-factor authentication, a hard requirement for handling patient health data. Leadership and sales confirmed this directly. These were real deals, stuck and waiting on this exact flow.
Once it shipped, more than thirty organizations adopted it, across multiple facility buildings and multiple countries. This design didn't just launch. It unlocked revenue that had been sitting stalled.
Context
MyHealth is a patient portal used by healthcare organizations worldwide, each running its own configuration of the platform.
The team needed to add multi-factor authentication to protect patient health records. The real challenge wasn't designing one secure sign-in flow. It was designing one system that could correctly represent dozens of different organizational policies, without the patient ever seeing a confusing or inconsistent experience.
Problem Statement
Every organization is different. Some require MFA for every patient. Some make it optional. Some support only email. Some support only SMS. Some let the patient choose. Some patients already have a phone number and email on file. Others have neither.
One shared component library had to hold up correctly across every one of those permutations, without engineering hand-building a new screen for every org's configuration.
And this is healthcare data. Every screen also had to satisfy real security and accessibility constraints, not decorative ones.
Design Goals
- Configurable, not one-size-fits-all. Support org-level settings for whether MFA is required, optional, or disabled, and which verification methods are available.
- Secure by default. Every screen designed defensively, assuming an attacker could be watching, not just designed to look clean.
- Accessible by default. Labels, error states, and navigation meet WCAG standards. Never color alone.
- Resilient to failure. Codes fail to send. Users mistype. Devices get abandoned mid-flow. Every failure mode gets a designed answer, not a dead end.
Three Experience Paths
1. The standard path
Sign in, optionally enable secure sign-in, verify with a code, done. Where MFA is optional, every step is skippable, and "Skip for now" is explicit, never hidden.
2. The missing-contact-info path
Organization requires MFA, but the patient has no email or phone on file. The flow collects it in place, as a required step inside account setup, not a full context switch. If the org supports both email and SMS, we collect both, so the patient has a choice going forward.
3. The failure-recovery path
Codes don't arrive. Codes get entered wrong. Attempts run out. Each gets its own screen, but every screen reuses the same components, the same code field, the same error banner, so the system stays consistent even under failure.
Designing for Failure Gracefully
A few decisions worth calling out came directly out of security or accessibility review, not visual polish.
- One code field, not six boxes. Six boxes silently reveal code length to anyone watching over the user's shoulder. I pushed back initially, since six boxes read cleaner and users often copy and paste codes, which behaves inconsistently across six separate inputs. In the end, the security argument won and one field shipped.
- Partial masking, everywhere. Email shows only first and last character. Phone shows only the last four digits. Patients confirm this is my contact info, without the full value ever appearing on-screen.
- Exceeded attempts reuses the sign-in screen. It's not a dead-end lockout page, but a temporary block, with an error banner layered on top. It's honest about what's actually happening: the user can come back and try again later.
- Failed delivery still shows the code field, live. Delivery failures aren't always accurate. A code may still arrive. The user isn't blocked from trying, and Cancel lets them switch methods instead.
- Errors link directly to the field. The field name is an inline link inside the error banner. A screen reader or keyboard user jumps straight to the fix, never relying on color alone.
- Labels sit above inputs, always. Placeholder-only labels disappear the moment a user types, and assistive tech doesn't announce them the same way. Every field got a persistent, visible label.
Validation
There were three dedicated review passes, each its own session rather than one combined check. An accessibility review against WCAG standards, a security sign-off on masking, lockout, and error handling, and stakeholder walkthroughs of every state with PM and engineering. Issues like the code-length exposure surfaced and got resolved before dev handoff, not after launch.
The security review is also where "Remember this device" got its final shape. Rather than a fixed trust period, it's an internal parameter each organization sets independently, how many days a device stays trusted before MFA is required again. A hospital handling especially sensitive records sets that window short. Another organization sets it longer for convenience. So configurable per organization wasn't just a UI idea. It went all the way down into the security model itself.
Outcome
This shipped to production and was adopted by more than thirty healthcare organizations, spanning multiple facility buildings and multiple countries. Several of those organizations had been stalled on adopting the broader platform until MFA existed, which leadership and sales confirmed directly. This didn't just ship a feature. It unblocked real business relationships that had been stuck.
The single biggest design challenge, and the thing I'd want a hiring manager to take away from this project, was building one coherent design system flexible enough to correctly represent every organization's security configuration, without that flexibility ever becoming visible or confusing to the patient using it. The patient should never have to know their organization's backend settings; they should just experience a sign-in flow that makes sense.
Post-MVP: What I Learned
- A design system is only proven once it survives real edge cases. The flow felt complete after the happy path and a couple failure states. It wasn't tested until we mapped every permutation, required vs. optional, email vs. SMS vs. both, missing contact info vs. complete. Post-MVP, the real work was stress-testing the component library, not adding new screens.
- Consistency has to be designed in, not cleaned up after. Once patients hit this flow repeatedly, small inconsistencies became visible in a way they weren't during initial review. Reusing the same components everywhere wasn't just faster to build. It's what made the experience feel trustworthy under repeat use.
- Failure states deserve attention up front, not backfilled. The screens I'm proudest of, exceeded attempts, failed delivery, invalid format, weren't in the original scope. They got added after real failure modes surfaced post-launch. I'd design those states first next time.
- "Optional" is a real design state, not a fallback. Skip had to be a first-class path, not an escape hatch. Treating configurability as core to the design, not bolted on later, made the system far easier to extend.
Reflection
This was my first large-scale project. I designed every screen and interaction pattern myself, but relied heavily on my PM's input to understand each organization's requirements, and on engineering and other designers to pressure-test decisions like the code field debate above. I leaned on that collaboration more than I might on a project I owned end-to-end today. Working across PM and engineering on this made clear how much of "good security UX" is actually about being honest with the user about what's happening, not hiding failure states behind vague messaging, and not asking users to trust a system that doesn't explain itself. The accessibility work also reinforced something I try to carry into every project now: color and placement are never a substitute for a real, persistent, programmatically-associated label.