Health and fitness is one of the few consumer categories where design work is consistently and seriously funded, and the reason has little to do with fashion. Care is moving out of expensive buildings, wearables now produce continuous data that nobody outside a clinic can interpret, and employers and insurers have discovered they will pay for tools that keep people well. Those three forces create products with a real user, a real payer and a compliance requirement. They also create a design problem with an unusual ethical weight, because the difference between motivating someone and shaming them is often a single sentence.
Why this category keeps getting funded
Understanding the money explains the briefs, and the briefs are more varied than the app store suggests.
Care is leaving the building
Every health system in a developed market is trying to treat more people outside hospitals, because hospital time is the most expensive resource they have. That produces remote monitoring, medication adherence, pre and post operative programmes, triage, and follow up. All of it needs interfaces used by people who are not clinicians, often while unwell.
Wearables produce data nobody can read
A watch now records heart rate variability, sleep stages, blood oxygen, temperature deviation and more. Almost none of that means anything to the person wearing it without interpretation. The gap between raw sensor output and a decision a person can act on is exactly where product design sits, and it is a genuinely hard translation problem rather than a charting exercise.
Someone other than the user is paying
Employers funding wellbeing programmes, insurers funding prevention, health systems funding adherence, clinics funding their own operations. That separation between payer and user is what turns a nice idea into a budget, and it is the same structural pattern that funds the strongest mobile categories generally.
It also creates a design tension worth naming early: the payer wants engagement data and outcome reporting, the user wants to be left alone unless something matters. Products that resolve that tension in the payer’s favour get abandoned by users, and then stop producing the data the payer wanted anyway.
The first decision: who this is actually for
Most health apps are designed, implicitly, for the person who least needs them.
The motivated minority problem
The people in the room designing a fitness product are usually people who enjoy exercise. Their instincts produce features for someone who already trains: detailed metrics, granular logging, performance charts, personal records. That user exists and is loud, but they are a small fraction of the addressable population and they are already served.
The larger and harder audience is the person who has been told to move more, is embarrassed about their current state, has failed at this before, and will open the app perhaps four times before deciding whether it is for them. Designing for them means fewer metrics, larger wins, and far more care with language.
Design for the bad day, not the good one
Every health product works on the day the user is enthusiastic. The product is decided on the day they are tired, behind, and slightly ashamed. What does the home screen say to someone who has missed six days? If the answer is a broken streak, a red chart and an empty ring, the product is optimised to lose exactly the people who need it.
The single most valuable screen in a health app is the return screen, and it is almost never designed. It should acknowledge the gap without dwelling, make the smallest possible next action obvious, and never require the user to catch up on backlogged logging before continuing.
Segment by intent, not by demographics
A useful split is not age or gender but why the person is here: someone rehabilitating an injury, someone managing a diagnosed condition, someone told to lose weight by a doctor, and someone optimising performance. Those four want different home screens. Asking one question during onboarding and branching the experience beats asking twelve and personalising nothing, which is the same restraint that makes any onboarding work.
Making sensor data mean something
This is the core design problem of the category, and most products fail it by presenting numbers instead of meaning.
A number without a comparison is noise
“Your HRV was 42” tells a person nothing. It becomes useful only against something: your own baseline, your last fourteen days, or what typically follows a night like the one you had. The design job is to supply that comparison by default rather than making the user construct it.
Lead with the interpretation and let the number support it. “Recovery looks lower than your usual” followed by the figure beats the figure followed by a chart the user must decode. The people who want the raw data will find it; the majority need the sentence.
Trends beat snapshots, and both beat precision
Day to day variation in most health metrics is large and mostly meaningless, so a product that presents each day as a verdict trains users to react to noise. Rolling averages, week over week movement and clearly marked bands of normal variation are more honest and more useful.
Precision is a trap here too. Reporting sleep to the minute or body fat to a decimal implies an accuracy consumer sensors do not have, and once a user catches the product being confidently wrong they discount everything else it says.
Chart choices that quietly mislead
Truncated axes make a trivial change look dramatic, which in a health context can genuinely frighten someone. Colour used decoratively rather than semantically makes red mean nothing. Cumulative totals always rise and therefore always flatter. Every one of these is a data visualisation decision with real consequences, and in this category the consequence can be a person changing their behaviour based on a misreading.
Habit design without the dark patterns
Behaviour change is the actual product in most of this category, and the standard toolkit contains some genuinely harmful defaults.
Streaks, and their cruelty
Streaks work. They also punish exactly the moment a person most needs support, and they create a quitting event: once a long streak breaks, a meaningful share of users stop entirely, because the thing they were maintaining is gone.
The humane versions are well understood. Allow a small number of forgiveness days. Count total days rather than only consecutive ones. Show the best streak alongside the current one so history is not erased. Or drop the mechanic where the behaviour is genuinely difficult, because for someone managing a chronic condition, a broken streak is a judgement on a bad health week.
Rewards that survive week three
Badges and confetti produce a short lift and then stop working. What sustains use is evidence of real progress: the same walk taking less effort, weights going up, resting heart rate drifting down, symptoms logged less often. Design the product to surface that evidence, because it is intrinsically motivating in a way that a virtual trophy is not.
Make the smallest action meaningful
Products that only count full workouts tell someone who managed a ten minute walk that they did nothing. Logging should have a floor low enough that a bad day still registers as something, which keeps the habit alive through the periods that would otherwise end it.
Language, and where motivation becomes shame
Copy carries more weight in this category than in any other consumer software.
The tone rules are simple to state and easy to violate. Never imply moral failure. Avoid the vocabulary of guilt, cheating and being good or bad, which is pervasive in nutrition products and actively harmful for anyone with a difficult relationship with food. Do not congratulate weight loss as an unqualified good, because you do not know why the weight changed. Describe behaviour rather than judging the person: “no walks logged this week” is a fact, “you have been lazy this week” is an insult, and plenty of shipped products sit closer to the second than their teams realise.
Get someone outside the team to read every notification and empty state aloud. Tone problems are obvious when spoken and invisible on a screen, and this is microcopy doing the heaviest lifting it ever does.
Sensitive data changes the design, not just the backend
Health data carries legal weight in most markets, and the consequences reach the interface directly rather than staying in the database.
What the rules actually require of the screen
Depending on jurisdiction and whether the product is clinically adjacent, you may need explicit rather than implied consent, granular control over what is shared and with whom, the ability to export and delete data on request, and clear statements of purpose at the point of collection. Each of those is a screen or a flow, and each is far cheaper designed in than retrofitted.
The practical rule is to collect the minimum that makes the product work. Every additional field is a liability, an obligation and a conversion cost, which is the same logic that makes short forms outperform thorough ones.
Sharing, consent and the family problem
Health products often involve more than one person: a partner, a parent, a carer, a coach, a clinician. Each relationship needs its own permission model, and the defaults must be private.
The scenario to design against is the one where a person’s data reaches someone they did not intend. A shared family account showing a teenager’s activity to a parent, a partner seeing fertility data, an employer wellbeing programme where individual figures become visible to a manager. Any of these can cause real harm, and the interface is the only place the boundary is visible to the user.
Analytics, notifications and the lock screen
Third party analytics in a health app is a genuine risk, because event names alone can reveal condition information. Be deliberate about what is tracked and where it goes.
The lock screen deserves specific attention. A notification reading “time for your HIV medication” visible to anyone who picks up the phone is a serious failure. Sensitive categories need generic notification text with detail only after unlocking, and that should be the default rather than a setting the user must find.
Accessibility is a functional requirement here
The audience for a health product skews towards people with impairments more than almost any other consumer category, because illness, age and disability travel together.
That means real contrast rather than fashionable low contrast grey, type that scales when the system font size is increased, touch targets usable with tremor or reduced dexterity, screen reader labels on every chart and control, and never using colour alone to carry meaning, since red and green are the most common encoding and the most commonly invisible. This is the standard baseline applied to an audience where failing it excludes precisely the people the product exists for.
Onboarding a health product
The first session decides retention, and health products load it with the wrong things.
Long medical questionnaires, permission requests before any value has been shown, and a tour of features all push the moment of usefulness further away. The better sequence is to deliver one useful thing immediately, ask for permissions at the moment they enable something visible, and gather the deeper profile progressively over the first week as it becomes relevant.
Be honest in that first run about what the product is and is not. A user who understands from the outset that this tracks and suggests rather than diagnoses is a user who will not feel misled later, and that expectation setting protects both parties.
Clinical adjacency, and the line you must not blur
There is a bright line between a wellbeing product and a medical device, and it is defined by claims and intended use rather than by technology.
The moment a product claims to diagnose, treat, prevent or mitigate a condition, it may fall under medical device regulation with everything that entails. Plenty of products sit deliberately just below that line, and the design consequence is that copy must be disciplined: describing patterns rather than diagnosing them, suggesting a conversation with a clinician rather than giving instructions, and never presenting an estimate as a clinical measurement.
Design the escalation path too. If a product ever surfaces something concerning, it needs a clear route to a human, and it must not be the only thing standing between a user and care. Our own work in this area sits on the clinical operations side, in a clinic system where the safety rules are tested code, and the same principle applies: the interface must never imply more certainty than the system has.
Wearables and the companion app
Most products in this category eventually pair with hardware, which introduces a specific set of problems.
Pairing is the highest risk moment in the product, because a user who cannot connect their device concludes the app is broken and stops. It deserves the same care as a checkout flow: clear prerequisites, visible progress, plain language for failures, and a route to help.
After pairing, design for absence. Devices run out of battery, get left at home, and stop syncing. The product needs a coherent state for stale data, showing the last sync time honestly rather than displaying old figures as if they were current. Reconciliation matters too: when a phone and a watch both recorded the same walk, the interface must not present it as two.
Food logging, the hardest interaction in the category
Nutrition products deserve their own treatment because logging food is the highest friction, highest abandonment interaction in consumer health.
Why it fails
A user must identify a food, estimate a portion, find it in a database of near duplicates, and repeat that for every component of a meal. Doing this honestly takes minutes per meal, several times a day, forever. Almost nobody sustains it, and the products know this, which is why so many of them push barcode scanning and photo recognition hard.
What actually reduces the friction
Meal reuse is the strongest lever: most people eat a small repertoire repeatedly, so surfacing “the usual” as a one tap entry captures the majority of logging in a fraction of the taps. Portion estimation should offer coarse, honest options rather than demanding grams, because a user guessing at grams is producing false precision anyway. Camera capture works best not as magic identification but as a fast record the user confirms and adjusts, which is the confirm before committing pattern applied to a plate.
The ethical dimension is unavoidable
Calorie counting products are used by people with eating disorders, and some standard features are actively dangerous to them: aggressive deficit targets, red warnings when a limit is exceeded, streaks that reward under eating, and public comparison. Responsible products cap how low a target can be set, avoid moralising language entirely, and provide a route to hide numeric goals. This is not a compliance requirement in most markets. It is a design decision about who you are willing to harm.
Mental health and the duty of care
Mental wellbeing is one of the fastest growing corners of this category and the one with the highest stakes per screen.
The design constraints are specific. The user may be in genuine distress while using the product, so every flow needs to work for someone with reduced concentration and low motivation. Crisis routing is mandatory rather than optional: any product touching mood, self harm or suicidal ideation needs an unmissable, always available path to human help, and it needs to work before sign up, not after.
Content and tone need clinical review rather than copywriting instinct. Guided exercises, reframing prompts and journalling suggestions all carry therapeutic assumptions, and getting them wrong is not a usability problem. Privacy expectations are also higher here than anywhere else in health, because the data is stigmatised: default to local storage where possible, be explicit about what a therapist or employer can see, and never surface content on a lock screen.
Finally, be honest about what the product is. A journalling app with breathing exercises is valuable and is not therapy, and saying so plainly protects vulnerable users better than any disclaimer buried in terms.
Community and social features, used carefully
Social features drive retention in fitness and cause harm in health, and the difference is whether comparison is the mechanic.
Leaderboards and public rankings work for people who are already competitive and already fit. For everyone else, being visibly last is a reason to leave. If comparison is used at all, compare a person to their own past rather than to strangers, and make any public visibility opt in with a clear preview of what others will see.
What does work broadly is cooperation rather than competition: shared goals where contributions add up, small private groups rather than global feeds, and accountability with one other person. The design lesson is that the social feature should make someone feel accompanied, not measured, and the tell for getting it wrong is a metric that rewards the strongest users with visibility paid for by everyone else’s discouragement.
Monetisation, and where the paywall goes
Almost every consumer product in this category is subscription funded, which makes paywall design part of the health design problem rather than a separate commercial concern.
Put the paywall after value, never before it. A user who has completed one useful session understands what they would be buying; a user who meets a price on screen two does not. Free tiers should be genuinely usable rather than crippled, because a product that blocks the core behaviour behind payment is asking someone to buy a habit they have not formed.
Be careful with health specific pressure tactics. Countdown timers on a discount, personalised “plans” that are the same plan, and results projections presented as forecasts are all common in this category and all corrosive. Projections deserve particular scrutiny: showing a user a confident future weight based on their first three days is presenting an extrapolation as a prediction, and it is the kind of thing that erodes trust the moment reality diverges.
Cancellation should be as easy as signing up. In several markets that is now a legal requirement rather than a courtesy, and in all of them a difficult cancellation flow produces refund requests, chargebacks and reviews that cost more than the retained subscriptions were worth.
Human in the loop, where the category is heading
The products with the strongest retention increasingly pair software with a person: a coach, a dietitian, a physiotherapist, a nurse. The software handles capture, reminders and reporting; the human handles judgement, encouragement and the moments where a person needs to be seen.
Designing this well means building two connected interfaces rather than one, which is closer to a two sided product than a consumer app. The professional needs a caseload view, a way to see who is struggling without reading every log, and message templates that stay personal. The user needs to know when a human will see something and when they will not, because assuming a person is watching when nobody is can be genuinely dangerous.
Response time expectations must be explicit. “Your coach replies within one working day” is a promise the interface should make and the operation should keep, and the design should never imply real time attention that the staffing model cannot deliver.
Measuring whether the product actually works
Engagement is the wrong headline metric in health, and optimising for it produces manipulative products.
Better questions: are users still active at week four and week twelve, since almost everything retains for a fortnight. Is the target behaviour changing, not just being logged. Do people who lapse come back, which is the return screen doing its job. And for products with a clinical or employer payer, does the outcome the payer cares about move at all.
A product where usage is high and behaviour is unchanged is a game, not a health product, and knowing the difference requires deciding what to measure before launch.
The offline and interruption reality
Health products are used in gyms with no signal, on trails, in hospital basements and in the middle of a set. That context is not an edge case, and treating connectivity as assumed produces a product that fails at the exact moment of use.
Logging must work offline and sync later, silently, with no lost entries and no duplicate entries when two devices reconcile. An active workout or a guided session must survive a phone call, a notification, the screen locking and the app being backgrounded, and it must resume where it was rather than restarting. Anything with audio needs to keep playing when the screen is off, because nobody holds a phone awake through a twenty minute session.
Interruption handling is the part teams skip and users notice immediately. Test every timed or in progress experience by locking the phone halfway through, taking a call, and switching apps. The failure rate on that simple test, across shipped products in this category, is higher than it should be, and it is the same category of neglect as the states that never get designed.
What we would build first
Pick one behaviour, for one intent segment, and make the loop excellent: capture it with minimal friction, reflect it back with meaning rather than raw numbers, and handle the missed day gracefully. That is a smaller product than most briefs describe and a far more likely one to survive its first month, which is the argument for narrow scope in any MVP.
Then validate with people who are not enthusiasts. Five sessions with users who have failed at this before will reshape the product more than any amount of internal debate, and it is cheap enough that there is no excuse.
Working with clinical stakeholders
If a clinician, a health system or an employer is involved, the process changes as much as the product, and teams that plan for a consumer timeline are consistently surprised.
Expect review cycles that have nothing to do with design quality: information governance, clinical safety sign off, legal review of every claim, and procurement. Expect the people who will use the professional side to be extremely busy and available in twenty minute windows, which makes research sessions short and precious. Expect the loudest stakeholder to be a manager rather than a practitioner, and design against that by insisting on time with the people who will actually hold the phone.
Build the evidence trail as you go. Screenshots of every state, a written rationale for safety relevant decisions, and a record of what was tested with whom. That documentation is tedious and it is what turns a sign off meeting from a debate into a review, which is the same discipline that gets a redesign approved anywhere.
The failures we see repeatedly
A dashboard of metrics with no interpretation. A streak that punishes illness. Copy that shames. Permissions requested before value. Charts with truncated axes that make normal variation look alarming. Sensitive detail on the lock screen. Onboarding that asks forty questions before doing anything. A product built for the person who already exercises, sold to people who do not. And, most often, a design that is beautiful on the good day and silent on the bad one.
Every one of those is fixable in design rather than in code, which is the useful part. None of them require a bigger budget either; they require someone in the room asking what the screen says to a person having a bad week.
If you are building in this space and want a straight read on where the ethical and regulatory lines sit for your specific product, describe what it does and who pays for it: hello@beconfidency.agency.
When the hard part is turning sensor data into something a person will act on, that is exactly what our product design service is for.