Tag: nhs design patterns

  • Designing for the NHS App Ecosystem: What Third-Party Health Developers Need to Know About NHS Design Patterns

    Designing for the NHS App Ecosystem: What Third-Party Health Developers Need to Know About NHS Design Patterns

    If you’ve ever tried to build a companion app or integration layer for the NHS ecosystem, you’ll know the experience is somewhere between solving a puzzle with missing pieces and navigating a labyrinth designed by committee. The documentation exists. The NHS Digital Service Manual is actually one of the better-maintained design systems in the UK public sector. The problem isn’t the documentation. The problem is that most health tech startups read it the way people read terms and conditions: quickly, selectively, and with total confidence they’ve understood the important bits.

    They haven’t. I’ve seen the same mistakes repeat across a dozen health tech projects, from GP appointment add-ons to mental health tracking apps trying to slot into NHS workflows. So let’s go through what’s actually being misunderstood, because some of these errors go beyond aesthetics into genuinely risky territory.

    Tablet displaying NHS design patterns in a clinical setting
    Photo by Matheus Bertelli on Pexels

    Why NHS design patterns are not just a visual style guide

    The first and most common misconception: teams treat NHS design patterns as a branding exercise. Copy the blue. Use the logo typeface (Frutiger, or the open-source Fraunhofer approximation). Borrow the card components. Job done, looks credible.

    That’s backwards. The NHS design system is built around a set of interaction principles and a specific clinical context that most commercial UI thinking doesn’t account for at all. The GOV.UK Design System, which shares some DNA, at least gets discussed in design circles (I wrote about what GOV.UK gets right that private sector UI libraries get wrong a while back), but the NHS variant has additional constraints layered on top, because the users and stakes are different.

    Consider one obvious example: error messaging. In a typical SaaS product, an error message is a minor friction point. In a clinical UI, an error message about a dosage input or an appointment slot could cause a patient to take the wrong action. The NHS Service Manual specifies error summary patterns precisely because the consequences of user confusion in health contexts are categorically different from, say, a failed checkout flow. The pattern is not decoration. It is a risk mitigation tool.

    What health tech startups consistently get wrong about accessibility

    WCAG 2.2 compliance gets mentioned in every NHS digital service assessment, and most teams know this, at least in theory. In practice, I see two failure modes.

    The first is treating accessibility as a checklist rather than a design constraint. Teams run an automated audit with axe or Lighthouse, fix the obvious contrast ratios, add some aria-labels, and declare compliance. But automated tools catch roughly 30-40% of WCAG issues. The remainder, focus order, screen reader narrative flow, meaningful alternative text, timeout behaviour for users with cognitive impairments, only surfaces in manual testing with real assistive technology.

    The second failure mode is misunderstanding the NHS user base. NHS app users are not a homogeneous tech-savvy audience. As I covered in my piece on designing for older users and accessibility, the over-55 demographic represents a huge proportion of NHS service users, and they interact with digital interfaces in ways that invalidate many assumptions baked into modern component libraries. Small tap targets, hover-only states, icons without labels, modals that trap keyboard focus badly: all of these become genuine barriers at scale when your user base skews older and potentially has reduced motor control or vision impairment.

    Developer writing code for NHS design patterns component library
    Photo by Harold Vasquez on Pexels

    The NHS explicitly requires user research with real patients as part of service assessments. Not personas. Not assumed user journeys mapped on a whiteboard. Actual sessions with actual people. Teams that skip this stage almost always pay for it later, either in failed assessments or in post-launch complaints that damage the trust relationship with NHS partners.

    Trust signals in clinical UI: where commercial design intuitions break down

    Here’s where it gets philosophically interesting. Commercial product design has spent the last decade optimising for conversion: clear CTAs, reduced friction, bright colour on primary actions, social proof via user counts and review scores. Health tech apps that import these patterns wholesale often end up looking untrustworthy to clinical users, and sometimes to patients.

    Clinical trust operates differently. A patient interacting with a mental health app doesn’t want it to feel like a productivity tool. They want it to feel safe, unhurried, and unambiguous. This means generous whitespace (which commercial designers sometimes read as “wasted space”), plain language at a reading age appropriate for a wide public audience, and absolutely no dark patterns near anything related to consent or data sharing.

    The NHS has very specific guidance on data handling UI precisely because health data is special category data under UK GDPR. The ICO and NHS England both publish guidance on this. If your consent flows borrow the kind of nudge patterns you’d find on a subscription cancellation screen (pre-ticked boxes, vague opt-in language, confusing toggle states), you are not just creating bad UX. You are potentially creating a legal and regulatory problem. I wrote about UK consumer protection and UX design in a different context, but the principle around manipulation through UI design is directly applicable here.

    The NHS digital service standard: what the assessment process actually demands

    Teams building apps that will connect to NHS systems, or carry NHS branding, typically need to pass a Digital Technology Assessment Criteria (DTAC) review. This is not the same as simply passing an NHS design assessment, and conflating them is a common error.

    DTAC covers clinical safety (DCB0129 compliance), data protection, technical security, interoperability (FHIR R4 where relevant), and usability. The clinical safety requirement alone, which requires a named Clinical Safety Officer and a documented hazard log, catches many startups completely off guard. This is not a box-ticking exercise. A hazard log means identifying the ways your software could harm a patient if it behaves unexpectedly, and documenting what you’ve done to mitigate each risk.

    I’ve seen teams, including a couple of otherwise well-run companies that handle complex integrations, treat the DTAC process as a hurdle to clear rather than a framework that makes their product genuinely safer. The distinction matters enormously when something goes wrong. Agencies building products with technical integration complexity, like Dijitul Developments, understand that integration architecture decisions made early have compliance implications downstream, and the same is true in spades for health tech builds touching NHS infrastructure.

    Component library choices and why “looks NHS” is not enough

    The NHS frontend library is open source and available on GitHub. It covers form components, navigation patterns, warning callouts, and action links. Using it is sensible. But a few nuances trip people up.

    First, the library is React-agnostic by design, but most health tech teams are building in React or React Native. The official components are vanilla HTML/CSS/JS. There are community-maintained React wrappers, but these are not officially supported, and their fidelity to the latest NHS frontend version varies. Teams need to own the maintenance overhead if they use them.

    Second, the NHS design system has specific guidance on what components to use for clinical decision support contexts versus patient-facing contexts. Using a summary card component (designed for showing appointment details to a patient) inside a clinician-facing dashboard creates cognitive dissonance for clinical staff who have built up a mental model of what each pattern means. Context collapse in UI is a real problem that purely visual pattern-matching doesn’t prevent.

    What building well actually looks like

    The teams I’ve seen do this well share a few habits. They read the NHS service manual properly, including the content design guidance, which is where a lot of the philosophy is actually explained. They involve a clinical safety lead from the start rather than bolting one on before submission. They conduct genuine usability testing with NHS staff and patients, not just developers who have become blind to their own interface.

    They also build with the understanding that NHS design patterns are living documents. The manual updates. Guidance around things like app accessibility and FHIR integration evolves. Setting up a process to track changes, rather than treating the design system as a one-time reference, is the difference between a product that stays compliant and one that quietly drifts out of alignment.

    Getting this right is genuinely hard. But the NHS has done a lot of the thinking for you, if you’re willing to engage with it seriously rather than skin-deep.

  • Designing App Interfaces for the UK’s Ageing Population: What WCAG Doesn’t Tell You

    Designing App Interfaces for the UK’s Ageing Population: What WCAG Doesn’t Tell You

    WCAG compliance is the floor, not the ceiling. I’ve reviewed dozens of digital products built by UK teams who ticked every accessibility checkbox, shipped their app, and then watched users aged 60 and over abandon it within two minutes. The guidelines cover contrast ratios and keyboard navigation. They do not cover the lived reality of designing for someone who has never used a smartphone until their late fifties, has some degree of age-related macular degeneration, and finds most app navigation patterns genuinely baffling. App design for older users UK accessibility is a specialist discipline, and treating it as a WCAG checklist exercise is where most teams go wrong.

    The UK’s Office for National Statistics puts the over-60 population at roughly 16 million, and that figure keeps climbing. NHS apps, council portals, financial tools, and retail platforms all need these users. They are not a niche edge case.

    Older woman using a tablet app, illustrating app design older users UK accessibility
    Photo by Teona Swift on Pexels

    Cognitive load is the real killer, not contrast

    Working memory declines with age. That is not a controversial claim; it is well-documented cognitive science. What it means for interface design is that the number of simultaneous choices, the density of options on a screen, and the length of multi-step flows all need to come down significantly compared to what you’d ship for a general adult audience.

    I tend to think about it like this: if a 35-year-old can hold four things in their head while navigating your onboarding flow, design as if your 68-year-old user can hold two. That means progressive disclosure is not just a nice UX pattern, it is load-bearing. Break multi-step processes into single-question screens. Put one primary action per view. Cut every secondary option that does not absolutely need to exist on that particular screen.

    The NHS App is a reasonable reference point here. Its appointment booking flow keeps each step minimal, labels are plain English, and the confirmation screen repeats key information rather than assuming users retained it from two screens back. That repetition feels redundant to a younger user and essential to an older one. You cannot design for both with the same screen, and that is fine. Design for the user who needs the most support and you will not alienate the one who needs less.

    Touch target sizing: the WCAG minimum is not enough

    WCAG 2.5.5 recommends a 44×44 CSS pixel minimum for touch targets. In practice, for users over 60, particularly those with any degree of tremor, reduced fine motor control, or arthritis, 44px is still small. Research from the Nielsen Norman Group puts comfortable touch target size for older users closer to 60x60px, with generous spacing between adjacent targets to reduce mis-taps.

    Mis-taps are a huge source of frustration. When a user taps the wrong button repeatedly, they lose confidence in the interface and in themselves. That confidence collapse is much harder to recover from in an older user than a younger one. I’d argue the emotional cost of a mis-tap is asymmetric across age groups, and that asymmetry should drive your sizing decisions.

    Some practical rules I use: make primary call-to-action buttons at least 56px tall, keep destructive actions (delete, log out, cancel) physically separated from confirmatory ones, and never place two tappable elements closer than 12px apart. On a related note, the accessible palette decisions UK product teams often get wrong apply doubly here, older users have reduced contrast sensitivity that compounds the touch accuracy problem when buttons are poorly differentiated visually.

    Font legibility goes further than size

    The standard recommendation is 16px body text minimum. For interfaces targeting users over 60, I’d go to 18px as a floor, with headings at 24px or above. But size is only part of font legibility. The typeface choice itself matters enormously.

    Age-related changes to the lens of the eye reduce sensitivity to fine detail, which is why highly stylised typefaces, thin weights, and fonts with low x-heights become genuinely difficult to parse. Avoid any font weight below 400 for body copy. Prefer humanist sans-serifs, Inter, Atkinson Hyperlegible, or system UI fonts, over geometric ones. Atkinson Hyperlegible was specifically designed for users with low vision and performs exceptionally well in this context; the British Dyslexia Association also endorses it for overlapping reasons.

    Line height matters too. Tight leading, common in sleek modern UI, forces the eye to work harder to track from one line to the next. Set line height at 1.6 or above for body text. And if you are using fluid typography with CSS clamp(), make sure your minimum clamp value never drops below 18px in older-user-facing contexts, even on small viewports.

    NHS-informed interaction patterns worth stealing

    The NHS design system is publicly available and genuinely excellent. The team that built it consulted heavily with patients across age groups, and the patterns reflect real-world usability testing rather than theoretical best practice. A few things in particular stand out.

    First: plain English labels over clever microcopy. “Continue” beats “Let’s go.” “Your appointments” beats “My health hub.” Older users map UI labels directly to mental models formed outside digital contexts. The closer the label matches the real-world concept, the faster comprehension happens.

    Second: explicit error messages that tell users exactly what to fix. “Invalid input” is useless. “Your date of birth should be entered as DD/MM/YYYY, for example, 15/03/1958” is useful. The NHS form patterns specify this level of specificity as standard, and it drastically reduces abandonment in older cohorts.

    Third: visible, persistent navigation. The hamburger menu is a learned pattern that many older users simply never learnt. If your app can run with a bottom tab bar or persistent side navigation rather than a hidden drawer, do it. The cognitive cost of remembering that the menu is behind a three-line icon is higher than it looks.

    You can read more about how strong institutional UI work informs everyday product design in my piece on the design principles behind BBC iPlayer, a lot of the same “reduce ambiguity, increase predictability” logic applies across user groups.

    Testing with real users, not assumptions

    The single most common mistake I see is teams designing for the mythical “older user” based on assumptions rather than running sessions with actual people aged 60 and over. It is not the same thing. The variance within that group is enormous, a 62-year-old software developer has completely different needs from a 78-year-old who has owned a smartphone for six months.

    Age UK runs digital skills programmes across the UK and has published research on common barriers older users face with digital services. Their findings consistently point to confidence and trust as primary blockers alongside the interaction design issues covered above. Users need to feel that the app will not do something unexpected, will not lose their data, and will always give them a clear way back. Irreversible actions without confirmation dialogs are particularly damaging to trust in this cohort.

    Recruit test participants through local libraries, NHS patient groups, or organisations like Age UK. Run tasks, observe without prompting, and note every hesitation. Those hesitations are your redesign brief.

    The data visualisation and information density decisions that come up in ageing-population app design also map directly onto the broader challenge of designing data-dense interfaces that actually work, the same principle of ruthless information hierarchy applies whether your user is 30 or 70.

    WCAG is necessary. It is not sufficient. Get the cognitive load right, size your targets properly, pick legible type, borrow from the NHS design system, and test with real older users. That is the actual brief.

The Latest