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.
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.
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.