My role
team
Product design, UX research, product strategy, engineering
Scope
Onboarding, home screen, and PDP
AltRx — Product Case Study
I designed the AltRx mobile app end to end, from onboarding through checkout. This case study walks through three pieces of that build, onboarding, the home screen and the product page, since these are the flows where conversion actually happens, the point where someone decides to trust the app enough to hand over their health information and buy. Onboarding and the home screen were redesigns of an existing flow, the product page was built from nothing, there was no PDP before this.
THE CONTEXT
AltRx connects patients with clinicians, prescriptions and ongoing coaching for weight loss, all through a mobile app. Before someone becomes a member, before there is any relationship with a doctor or coach, the product itself has to build the trust that would normally come from a person. That holds across onboarding, the home screen someone returns to every day, and the page where they actually decide to buy a prescription medication online.
The Problem
Across the app, the existing product worked, but it read like a generic subscription or fintech product that happened to be collecting health data, rather than something built for a weight loss and prescription program specifically.
• onboarding
Onboarding opened on a flat navy screen with no imagery, nothing in the visual language signaled health or care before asking for an email. Verification had three slightly different versions of the same screen back to back, a 4 digit OTP screen, then a 5 digit one, with the copy shifting between "Enter the OTP" and "Enter the code," which read as unfinished rather than intentional. Every field after that, name, date of birth, state, was its own full screen with a plain text input and a custom on screen number pad that duplicated the device's own keyboard, and there was no visible sense of progress anywhere in the flow.
• Homescreen
The home screen had a similar problem. It worked as a dashboard, a gradient card showed the current plan and a progress bar, a line chart tracked weight against a goal, and a text banner suggested upgrading to a longer plan. All functional, but nothing on the screen looked like it belonged to this specific product, it could have been almost any subscription app.
The product page did not exist at all. Prescription pricing, plan lengths and the trust information someone needs before buying a medication online had nowhere to live.
What I Was Solving For
• Make the app feel like it belongs to a health product, not a generic form or dashboard
• Fix the inconsistency in verification so the flow reads as one deliberate experience
• Replace manual data entry with more direct, tactile controls where it mattered
• Give people a way to skip questions they are not ready to answer yet
• Build in a sense of progress and trust at each step, including a product page that did not yet exist
• Onboarding
I started by mapping every data point the app actually needs before a person can reach the health intake: email, OTP, name, date of birth, weight, goal weight, height, health goals and medical history. Laying these out side by side made it clear that almost all of them were being collected the same way, as plain text in a form field, regardless of what kind of data it was. From there I went through each one and asked whether a more direct control existed for it. A date does not need a manual text field when a wheel picker already exists on the platform. A weight or height does not need to be typed when it can be dragged. A list of medical conditions does not need to be one long checklist when it can be grouped and chosen as chips.
Why the splash and verification changed
A flat navy screen with no imagery does not signal a health app before anyone has entered a single detail. The new splash uses a real photo and a one line promise instead, since a screen that looks more considered sets the expectation that the product is more considered, before a single interaction happens. Verification also had three inconsistent versions in the old flow, different digit counts, different copy, which read as unfinished rather than intentional. Making it consistent removes a small but real signal that the product was rushed.
Why biometric data moved off the keyboard
Date of birth, weight, goal weight and height were all typed into plain text fields in the old flow, the same treatment as an email address. None of these are neutral data points in a weight loss app. Weight in particular is often the first number someone has to admit to a stranger, so it now sits behind copy like "No judgment. Just a starting point," paired with a slider instead of a keyboard. Sliders and wheel pickers also match controls people already use elsewhere on the platform, so there is nothing new to learn, which keeps the flow moving instead of asking someone to stop and type.
Why medical history and health goals moved to chips
A medical questionnaire is the point in onboarding most likely to make someone feel like they are filling out paperwork. Splitting it into two themed groups instead of one long checklist, and using pill shaped chips instead of a list, breaks a heavy section into smaller decisions instead of one long one. Health goals got the same treatment, icon based cards instead of text, since scanning icons for weight loss or muscle building is a faster decision than reading through several lines. A skip option was added here too, so someone not ready to answer a medical question yet still has a way through the flow instead of being blocked by it.
• Homescreen
Why the hero moved from a gradient card to real photography
The old home opened on a solid gradient card with numbers on it. The new one opens on a photograph of two people, smiling, arms around each other, paired with a specific, timely offer. A home screen someone opens every day during a weight loss program is not just a dashboard, it is a daily touchpoint, and a photo of real people does more to reinforce that this is a supportive program than another chart can.
Why the weight projection became something you drag instead of something you read
The old home only showed a static line chart of weight already logged. The new home adds an interactive card, drag your current weight and see a projected loss by a certain date, directly in the feed. It turns a passive progress chart into something someone plays with, which keeps the weight loss goal active and personal every time the app is opened, not just something to check.
Why the zero state got its own design
Before this, someone without weight data yet would have hit a blank or broken looking chart. The new zero state replaces that with a grayed out placeholder chart and a direct call to action, "Login to add current & goal weight." An empty state is still a state someone will see, often on their very first visit, so it needed its own screen instead of being treated as an edge case of the populated one.
• Product Page
This page did not exist before, so it works differently from the other two. Instead of a before and after, it is about what the page had to do and why it ended up built the way it did.
AltRx sells a prescription medication through an app, which is a different kind of purchase decision than most product pages are built for. Someone landing here is not choosing a color or a size, they are deciding whether to trust an online platform with something they would normally only get through a doctor and a pharmacy.
Why the vial got a considered product shot
The product itself is a glass vial, which does not carry much visual interest on its own. Giving it a tilted, styled photograph with its own carousel treats it like a considered object rather than a lab specimen, which matters since this photo is the first thing anyone sees on the page.
Why pricing is a list, not a single price
Four plan lengths are shown together, 3 month, 6 month, 12 month and monthly, each with its own price per month and savings called out. Listing them together, longest commitment first, lets someone compare cost against how long they are willing to commit, rather than presenting one price and hiding the tradeoff.
Why the trust bullets sit directly under pricing
Online medical consultation, licensed clinician review, no hidden fees, no membership, these sit immediately after the pricing list, right at the point someone has just seen a number and is deciding whether to trust it. These are not generic benefits, they are answers to the specific concerns someone has buying a prescription medication online, is a real doctor involved, and is this harder to cancel than it looks.
Why the rest of the content is behind accordions
Usage instructions, results timeline and partner pharmacy information are all necessary, but not everyone needs them before deciding to buy. Keeping them collapsed keeps the primary path on the page short, get to the price, get to the trust signals, get to the button, while still holding all the information a prescription product needs to disclose.
Closing
None of these three pieces changed what AltRx actually needs from someone. The same information gets collected, the same plans get sold, the same progress gets tracked. What changed is how much of that process feels like using a considered health product versus filling out a form or reading a spec sheet. Onboarding, home and the PDP all had to answer some version of the same question, does this feel like it was built for the moment someone is actually in.
These three are part of a much larger app I designed end to end, including the full health intake with its conditional logic, accounts, and the checkout journey. They are the flows shown here because this is where conversion actually begins, the point where someone decides to open the app, trust it enough to hand over their health information, and choose to buy. The rest of the product was built with the same thinking, but it is these three that carry the weight of turning a visitor into a member.