Designing a health tech SaaS: patient side, clinician side, consent and accessibility

Most SaaS products have one kind of user, or a few who want roughly the same thing. Health products rarely do. The same system often has to work for a patient checking a result at night on an old phone and for a clinician clearing a queue between appointments. The stakes are higher, the data is regulated, and some of the people using it are not at their best. That changes how you design almost every screen.

This guide covers the parts that differ from other SaaS: the two audiences, consent, accessibility and trust, plus what to ask a design partner before you hire one. It’s about design principles, not legal or clinical advice. Which rules apply to your product depends on where you operate and what data you handle, and that call belongs to your compliance and clinical reviewers.

How is designing a health product different from other SaaS?

Four things change at once. The stakes are higher: a confusing screen can mean a missed dose or a wrong appointment, not just a lost conversion. The users are more vulnerable: people may be in pain, worried, older, or using the product on behalf of someone they care for. The data is regulated, so how it’s collected, shown and shared is constrained. And there are often two audiences with opposite needs in the same product.

None of this means a health product has to look clinical or timid. It means the design has to explain more, reassure more and check more than a typical dashboard, and do it without getting in the way.

Two users, two experiences

Treat patients and clinicians as two experiences on one system. They share data and a brand, but almost nothing about how they use a screen.

• 01Patients: plain language, one task per screen, reassurance, large touch targets. Say what happens after every action, explain medical terms when you have to use them, and never leave someone guessing whether a message was sent.
• 02Clinicians: density, speed, keyboard flows, and a clear view of what changed since they last looked. They know the domain, they’re interrupted constantly, and every extra click repeats across a full day of patients.
• 03Shared: one design system, so both sides feel like the same product.

The common mistake is designing one interface and hoping it stretches. A patient app with clinician density is overwhelming; a clinician tool with patient spacing is slow. Split the experiences early, at the level of navigation and layout, and keep them related through shared tokens, components and voice.

The places where the two sides meet deserve the most attention. A message a clinician writes shows up on a patient’s phone. A symptom a patient logs lands in a clinician’s queue. Design those handoffs on both ends at once: what the clinician sees before they send, and how it reads when it arrives.

Where does consent show up on screen?

Ask for consent in context, at the moment it matters, in plain language, with a clear way to change it later. Avoid one long form at sign-up.

A wall of checkboxes on day one teaches people to click through without reading. Consent that appears when it’s relevant, like when someone is about to share a record with a new provider or connect another app, is easier to understand and means more.

• 01One decision per prompt. Say what is being shared, with whom and why, in a sentence or two.
• 02Make “no” a real option. The product should keep working, with a clear note on what won’t be available.
• 03Show the current state. Wherever a setting applies, people should be able to see what they agreed to.
• 04An easy-to-find settings page where every consent can be reviewed and changed without contacting support.
• 05A history view, so patients and your team can see what was agreed and when.

Your legal and compliance reviewers decide what consent is required. Design decides whether people understand what they’re agreeing to.

Accessibility is not optional

Design to WCAG 2.2 AA from the start: contrast, text size, screen readers, motion settings. Many patients use assistive tech.

Retrofitting accessibility is expensive, because it touches colors, type, components and layouts all at once. Building it into the design system from the first screen is cheap by comparison. The people a health product serves include people with low vision, tremors, the fatigue of illness or medication, or simply an old phone with a cracked screen.

• 01Contrast and size: body text people can read without zooming, and contrast that holds up in every state, including disabled and error states.
• 02Never color alone: a result marked only in red or green fails people with color blindness. Pair color with text or an icon.
• 03Screen readers: real labels on every control, a logical reading order, and charts with a text summary.
• 04Motion: respect reduced motion settings, and never let an animation carry meaning on its own.
• 05Targets and timeouts: large touch targets, and session timeouts that warn first and don’t throw away a half-filled form.

Test with assistive tech, not only with an automated checker. Automated tools catch missing labels and low contrast. They don’t catch a flow that makes sense visually but not when it’s read aloud.

What builds trust in a health product?

Trust comes from four answers people can find without searching:

• 01Who is behind the product: the company, and where it applies, the clinical team or partners involved.
• 02How data is protected: in plain language on the screens where data is entered, with a link to the full policy.
• 03Which regulations apply, such as HIPAA or GDPR, stated accurately and only where they actually apply to your product.
• 04How to reach a human: a visible path to support or a clinician, especially on screens where something might go wrong.

Tone matters as much as badges. Calm, specific copy builds more trust than a row of logos. Error messages, empty states and reminders are where a health product sounds either careful or careless.

In a health product, the error message is part of the care.

What should you ask a health tech design partner?

• 01How do you design for two very different audiences? Look for separate flows and layouts, not one interface resized.
• 02How do you handle consent and accessibility in the UI? Look for consent shown in context, and accessibility built into components rather than checked in a final audit.
• 03How do you work with clinical and compliance reviewers? A good answer covers when reviewers see the work, how their feedback is tracked and who signs off.

For the general version of this checklist, see Choosing a design partner when AI can make anything.

A short checklist before you design

• 01Map both audiences and the moments where their work meets.
• 02List every point where data is collected or shared, and decide where consent belongs.
• 03Set accessibility rules in the design system before the first screen.
• 04Agree on how clinical and compliance reviews fit into each sprint.
• 05Write the trust copy early: who you are, how data is handled, how to reach a human.

If you’re planning a patient app, a clinic dashboard or a health SaaS, send your brief.

• Health tech
• Product
• Accessibility