Simplifying Patient Login by Rethinking SMS Authentication

Healthcare

Usability Testing

WebApp

Company

HealthPrize offers a patient-facing platform that encourages users to log in daily to track their medications. This supports healthcare partners in improving medication adherence, leading to fewer critical health events and healthier patient outcomes.

Challenge

We introduced SMS login to make the experience smoother for mobile users—but the backend constraints told a different story. Because email was the only trustworthy identifier in our system, the proposed flow required users to verify their email before receiving a text message.

Users found this confusing, and it carried an obvious risk: more friction, more frustration, and more support tickets for something that should feel effortless.

One participant summed it up perfectly: “Why do I need to check my email to log in with my phone?”

To provide a seamless design to the user, I needed to show the results of my tests to our team and provide a better alternative.

Team

VP of Technology

Principal Architect

Product Manager

4x Developers

Skills

User Journey Optimization

UX & Interaction Design

UI Design

Systems & Data Analysis

Understanding the Problem Space

Initial discovery with our teams VP of Technology and Principal Architect revealed that the users email address is their key account identifier, and that phone numbers in our database were not as reliable as we would like. Because of this, a user would need to authenticate via email in a user flow they proposed. This was a secure approach, but our team also questioned what this would mean for the user.

01 - UX Risks

• After asking the user for a phone number to login, they received an email verification first—this would likely confuse users, and needed to be tested for feedback
• The login flow felt redundant, requiring multiple verification steps when users only expected one
• The steps felt out of order and inconsistent with typical SMS login patterns

02 - Data & Backend Issues

• Phone numbers in the backend were often inaccurate, outdated, or formatted inconsistently
• The system needed to accommodate cases where users would need to confirm or update their phone number

The takeaway: the login experience was functional, but required many steps, and would likely add friction to a login experience

Usability Testing

I created a simple prototype of the proposed flow and ran five usability tests to surface the severity of the issues.

What We Saw

All users confirmed the flow felt redundant
• All users felt the requirement to check email during “SMS login” created mismatched expectations
3/5 Users weren’t sure which step verified what
4/5 Users said they expected a “simple text code" and the login would be complete

These tests helped quantify and communicate the UX cost of launching the flow as-is, at best it would confuse users - and at worst it would result in frustration, support tickets and a cost heavy redesign.

Showing test results was essential for creating alignment across the team that we can not ship the current state flow.

Core Problems

With acknowledgement that this flow needed a redesign, I gathered all of the core problems and constraints this flow faces.

• Our phone number data is problematic, and email is our only true account identifier
• Email as our account identifier creates extra steps - because users enter in their phone number first on the login screen. We can’t be sure the phone number they enter is valid and theirs without reverting back to a magic link email
• Phone number data needed to be cleaned up, which can only be done by users themselves

Phone numbers had many different formats in our system. Some had international codes, some had parentheses around an area code, and so on.

Rethinking the Approach (Going Wide)

I started exploring SMS OTP login flows for other companies, searching for answers. I found some companies that use email address only on their login screen - and follow up with an SMS text message.

This approach got us thinking solved a key challenge we were facing:

• Email is the reliable identifier.
• Users can enter their email on the login screen, and their phone number can be corrected after login.
• Next time they login, they can receive a text message.

This shift aligned with our system and significantly reduced friction.

Aha Moment #1 - Email First, SMS Second

Instead of validating phone numbers up front—which resulted in an email follow up—we allow users to authenticate with email, log in, and then confirm or update their phone number inside the portal.

Aha Moment #2 - One Progressive Step-by-Step Module

Users have a string of tasks they usually come to the portal to perform. We also need them to clean up their phone number data so our clinical team could contact them.

I designed a single cohesive module that will guide the user on tasks they need to take when entering the portal. Essentially it is a progressive account building exercise, with critical tasks blended in.

This received strong support from leadership, including the company president, and will lay a scalable pattern for when critical tasks are necessary within the patient portal.

Design Process

With a successful discovery process and alignment across the team - the new user flow was fairly straight forward. I took our new concept to an extensively reviewed design with sign-off by senior leadership.

The Process:
  1. Create a new user flow, based on findings

  2. Early wireframes & feedback

  3. High fidelity wireframes & review by senior leadership

  4. Polished design specifications

New login flow

Progressive Step-by-step Module

Final Design Overview

The New Login Experience:

The login screen will ask for email only. Upon a successful login, all users will be asked to add or edit their phone number. The login screen will ask for email only.

Here is the fork in the flow that simplifies login:

Has a user added or edited their phone number?

If yes - send them a text message one time passcode to login.

If no - user logs in as normal with an email verification code, and is given an overlay asking them to add or edit their phone number.

Any remaining tasks (agreements, profile setup, etc.) appear in the unified progressive task module

Key Improvements:

Eliminates redundant verification steps
• Avoids confusion caused by mismatched phone number data
Reduces cognitive load with one structured task module
Aligns with modern authentication patterns used by consumer products

Creates a scalable “progressive task module” for new tasks in the future

Outcomes

This redesign prevented a higher-friction login experience from launching and replaced it with a much cleaner, predictable flow. This new flow was presented by the technology team to the company president and a board of senior members, who were pleased with the result (and that the phone numbers would be “cleaned” for our clinical & sales teams! 🙂)

Impact

  • The final design significantly reduced expected user confusion and login friction

  • Support anticipated far fewer login-related tickets due to the simplified verification logic

  • Engineering had a clear, reliable system for managing phone number updates

  • The flow launched in a much more user-centered state than originally proposed

This work also set a pattern for future onboarding flows that the organization will reuse.

Contact Me

Reach out, I love to chat.

Chris Godowski © 2026

Contact Me

Reach out, I love to chat.

Chris Godowski © 2026

Contact Me

Reach out, I love to chat.

Chris Godowski © 2026