Digital health design checklist
10 checkpoints to run through while you design for health - not a compliance audit, not a substitute for your team's own review.
Same content is also available as a free PDF ↓
Health design has no fixed workflow - every product is different. What doesn't change is a set of things worth checking before you call a screen done. The checkpoints below aren't phases and don't have to be worked in order: use them as a list to run through, on your own or with your team, at any point in the design.
Would this work for someone using a screen reader, a keyboard only, or with low vision?
- Colour is never the only way status is shown (WCAG 2.2 SC 1.4.1)
- Every tap target is at least 24×24px (SC 2.5.8)
- Keyboard focus is never hidden behind a sticky header (SC 2.4.11)
- A drag gesture has a tap alternative (SC 2.5.7)
Is there one clear next step, with no time pressure?
- Every screen has one clear purpose, not several competing ones
- Nothing depends on remembering something shown on an earlier screen
- A mistake is easy to spot and undo before it is submitted
- The same wording and layout describe the same action everywhere in the product
- How to check: W3C's cognitive accessibility (COGA) guidance, a walkthrough while distracted.
Could someone stressed, unwell, or new to the topic read this in one pass?
- Sentences average about 20 words, one idea each
- The most important thing comes first, not last
- Medical jargon is explained the first time it appears
- Every number has its unit shown next to it
Would a misread dose or number be easy to catch?
- A dose always carries a leading zero before a decimal (0.5 mg) and never a trailing one after it (5 mg, not 5.0 mg)
- The unit sits next to the number itself, not only in a column header
- Look-alike drug names are told apart by more than their first few letters (tall man lettering: hydrALAZINE / hydrOXYzine)
- Ambiguous abbreviations, like "U" for units or "QD" for once daily, are spelled out in full
- How to check: ISMP's dose-designation guidance, read the number back out loud.
Does the reading say what it means, not just show a number?
- A result is shown against its reference range, not as a bare number
- Where the system allows it, the range is personalised to the patient, not a generic bracket
- A plain-language reading ("within the expected range") sits next to the value, not only the figure
- A result outside the range is visually distinct from one a patient can read at their own pace
- How to check: The PMC11347896 systematic review of lab-result displays, show it to someone without clinical training.
If someone gets this wrong, can they undo it?
- Every validation error is listed in one place, not only shown beside its field
- A failed submission moves keyboard focus to that list, not back to a blank form
- A critical action (delete, send, submit an order) has a confirmation step, an undo window, or both, not silence and no way back
- The same wording describes the same error everywhere it appears
- How to check: NHS design system's error summary pattern, a keyboard-only submit test.
If this alert fires 50 times a day, does it still get acted on?
- Every alert names the action to take, not just the problem
- Severity is shown by more than colour (shape, word, position)
- The alert appears at the moment of the decision, not before or after
- Low-value alerts are grouped, not sent one by one
Is consent written in plain words, not implied?
- Saying yes and saying no are equally easy to find and the same size
- Nothing is pre-ticked on the person's behalf
- Each purpose is asked for separately, not bundled into one toggle
- Withdrawing consent later takes the same number of steps as giving it
- How to check: ICO's guidance on valid consent, try withdrawing consent yourself before shipping.
Was this checked with older or less digitally confident users too?
- The design was tried by someone outside the project who does not already know how it works
- At least one test participant has low digital confidence or is unfamiliar with the topic
- The flow still works without a stable address, a printer, or a second device
- A human alternative (phone, in person) exists for someone who cannot finish the task online
- How to check: GOV.UK's guidance on designing an inclusive service, recruit one participant outside your usual panel.
Has anyone who isn't on the project tried this?
- Tested with people who match the real users, not colleagues
- Tested in a realistic setting: interrupted, low light, small screen
- The highest-risk tasks were tested specifically
- Findings changed something before ship, not just got logged
Raise with your wider team: is this a regulated medical device where it will be used, clinical risk sign-off, technical security, data interoperability, what happens after launch. This checklist is about the design decisions, not the paperwork around them.