A health product is rarely used on a good day. People open it when they are worried, tired, in pain or caring for someone else. That changes what good design means.
This article covers the design points we pay most attention to in healthtech. It is design guidance, not medical, legal or regulatory advice. Where a decision touches safety or the law, you need a specialist, and we say where below.
Audience types
Most health products have more than one kind of user, and they want different things.
- Patients or consumers. They want to understand, not to learn medical terms. Many are anxious. Some have low vision, low literacy or little experience with apps.
- Caregivers. Often family members, managing someone else's care in the gaps of a busy day. They need quick access and clear permissions.
- Clinicians. They are short on time, use many systems and read fast. They want dense, accurate information and few clicks.
- Admin and operations staff. Scheduling, billing and records. They work in long sessions and care about speed and accuracy.
Do not design one interface for all of them. Decide who each screen is for and write for that person. A patient summary and a clinician view of the same record should look and sound different.
Talk to real users from each group. If you cannot reach patients directly, work with the people who can, such as a clinic or a patient group, and treat consent and privacy in that research seriously.
Plain language
People often understand less health language than you expect, and they are most likely to misread it when they are stressed.
- Use everyday words first. "High blood pressure", then the medical term in brackets if needed.
- Write short sentences. One idea each.
- Put the most important thing first. If a test result needs action, say so at the top.
- Explain numbers. A value without context is not useful. "Your reading is 142. Your target range is below 130" says much more than the number alone.
- Avoid blame. "You missed your dose" feels harsher than "A dose was not logged yesterday."
- Be careful with tone. A cheerful message next to bad news feels wrong. Match the mood of the moment.
Test the words, not just the layout. Ask a few people from your audience to read a screen and tell you in their own words what it means. Where they disagree with your meaning, fix the text.
Any wording that explains a condition, a risk or a treatment should be reviewed by a qualified clinician. Designers can make text clear. They should not decide that it is medically correct.
Privacy cues
Health data is among the most sensitive data there is. Users know it, even if they cannot say why. Design should show that you do too.
- Say what you collect and why, at the moment you ask. Not only in a long policy.
- Ask for the minimum. If a field is not needed for this step, do not ask for it.
- Make consent clear and separate. Do not bundle consent to share data with consent to use the product. Use plain wording and a real choice.
- Show who can see what. If a caregiver or a doctor has access, display it, and let the user change it.
- Handle shared devices. Many people share a phone or a computer. Auto-lock, hidden previews in notifications and clear log-out help.
- Avoid sensitive content in notifications and emails. "You have a new message" is safer than a message that names a condition.
- Offer export and deletion, where the law or your policy provides for it.
The rules depend on where your users are and what kind of data you handle. In the US, rules such as HIPAA can apply to some health organizations and their vendors. In the EU and UK, health data is a special category under GDPR. These are starting points to raise with a qualified adviser, not a summary of your obligations. Your legal or privacy lead should review consent flows, data retention and sharing before launch.
Accessibility
Many health users have a condition that affects how they use screens: poor eyesight, tremor, hearing loss, cognitive fatigue, or an injury. Accessibility is part of the basic job here.
The standard reference is the Web Content Accessibility Guidelines. WCAG 2.2 became a W3C Recommendation in October 2023, and you can read it at w3.org/TR/WCAG22. Practical points that matter for health products:
- Readable text. Good contrast, a comfortable base size, and support for users who enlarge text.
- Large tap targets. Especially for medication logging, timers and emergency actions.
- Do not rely on color alone. A red value should also have a label or icon.
- Clear forms. Visible labels, helpful errors and no time limits that are too short.
- Screen reader support. Proper labels, headings and focus order.
- Support for different input methods. Keyboard, voice and switch controls.
Test with real assistive technology and, if you can, with people who use it every day. Automated checkers find only part of the problems.
Alerts
Alerts in health products can help or harm. Too many, and people mute them. Too few, and something important gets missed.
- Rank by importance. Make it obvious which alerts are urgent and which are information. Use different looks and different channels.
- Be specific. "Blood sugar reading is low. Check your levels now" is better than "Attention needed".
- Give a next step. What should the person do? Who can they call?
- Do not use fear. Calm and clear works better than red flashing text.
- Let users set quiet times, and keep a way for truly urgent alerts to come through.
- Do not give medical advice you are not qualified to give. If the product suggests an action based on health data, a clinician and your regulatory adviser must approve the logic and the wording.
Think about failure, too. What does the user see if sync fails, a sensor disconnects or data is old? Show the age of data. A reading that looks current but is two days old is a safety risk.
When to get specialist review
We design the product experience. These things need people with the right training:
- Clinical content. Anything that explains symptoms, results, risks or treatments.
- Regulatory status. Some health software is regulated as a medical device in some markets. If your product gives diagnosis or treatment guidance, ask a regulatory specialist early. It affects design, testing and documents.
- Privacy and security. Data handling, hosting, consent and retention need legal and security review.
- Safety-critical flows. Dosing, emergency features and anything where a mistake could hurt someone need formal review and testing.
Bring these people in while you design, not after. It is much cheaper to change a sketch than a shipped product.
If you are working on a health product and want an outside look at a key flow, our UX audit is a fixed-price way to start, and our SaaS design page shows how we work with product teams. For a first look at one screen, you can ask for a free design review at /contact.
