Health design systems compared: what each covers and when to use it

A health design system is a published set of interface components, patterns and guidance a team can build from rather than invent from scratch. None of the six compared here was written for health products specifically except one, and that matters more than it might seem: the right starting point depends on who commissioned the product and which platform it runs on, not on which system is "best".

The six, side by side

• NHS Design System (service-manual.nhs.uk/design-system) - scope: components, patterns and content style guidance for NHS digital services. Audience: teams building or commissioning an NHS service, in England specifically. Format: component library with usage guidance and code snippets, published as part of the NHS digital service manual. Licence: Open Government Licence v3.0 (stated on the page) - reuse and adaptation are permitted with attribution.
• GOV.UK Design System (design-system.service.gov.uk) - scope: components, patterns and design principles for UK government services generally, not health-specific. Audience: any team building a service on GOV.UK or for a UK public body; the NHS Design System itself borrows heavily from it. Format: component library with code, plus a large pattern section (dates, addresses, errors, check-answers pages). Licence: Open Government Licence v3.0 (stated on the page).
• U.S. Web Design System, USWDS (designsystem.digital.gov) - scope: components and visual style for U.S. federal government websites, not health-specific, though HealthCare.gov and VA services are among its users. Audience: teams building a .gov site, including federal health agencies. Format: component library with code, built to meet Section 508. Licence: not stated on the page itself (unlike NHS/GOV.UK, no open-licence notice was found there).
• Apple Human Interface Guidelines (developer.apple.com/design/human-interface-guidelines) - scope: platform design guidance for apps on iOS, iPadOS, macOS and watchOS, not health-specific and not a component library with reusable code. Audience: any team building a native Apple-platform app, including the many consumer health and fitness apps distributed through the App Store. Format: written guidance and specification, not a component kit. Licence: Apple copyright, no reuse licence stated.
• Material Design (M3) (m3.material.io) - scope: Google's general-purpose, cross-platform design system covering components, layout and theming. Audience: teams building on Android or using Google's web/Flutter tooling; not health-specific, but the default starting point for many Android health apps. Format: component specification plus implementation code for several frameworks. Licence: no reuse licence stated on the design-guidance pages themselves.
• Nordhealth Design System (nordhealth.design) - scope: the one health-specific system here - a component library built for clinical and veterinary software products. Audience: teams building on Nordhealth's own product platform, or evaluating a ready-made health-software component set. Format: component library with code and usage guidance. Licence: Nordhealth Ltd copyright, no reuse licence stated.

What actually differs

Three things separate these six, and none of them is quality. First, government-published versus commercial: NHS, GOV.UK and USWDS are Open Government Licence or federal work, built for public accountability and free reuse; Apple, Material and Nordhealth are commercial products whose design guidance is published to help build on their platform, not to be copied elsewhere. Second, health-specific versus general-purpose: only NHS and Nordhealth were designed around clinical and patient-facing tasks (appointments, results, triage-adjacent flows); the other four are general-purpose systems a health team adapts. Third, component library versus guidance-only: NHS, GOV.UK, USWDS, Material and Nordhealth ship code you can implement; Apple's HIG is a specification a team implements itself using Apple's own frameworks.

Which fits which context

A team building a service commissioned by or run under the NHS starts with the NHS Design System, because its patterns (booking, results, eligibility checks) were built and tested against that exact kind of service. A team building a U.S. federal health service starts with USWDS for the same reason, applied to a different government. A team with no government mandate, building a general web product, most often starts from GOV.UK's design system or Material Design depending on whether the product is a web service or an Android app, then layers health-specific patterns on top by hand. A team building a native iOS health app works from Apple's Human Interface Guidelines because there is no substitute component library for that platform. A team evaluating whether to buy or build clinical software components looks at Nordhealth's system as one example of what a ready-made, health-specific set looks like, alongside other vendors, before deciding to build from a general system instead.

Common questions

• Is there one official design system for health apps generally? No. NHS Design System and Nordhealth are the only two built specifically for health work, and both are scoped to one context (NHS services, and Nordhealth's own product platform). Most health teams combine a general-purpose system with their own health-specific patterns.
• Can components be copied directly from these systems into a live product? Only where the licence allows it. NHS and GOV.UK are Open Government Licence, so their code and patterns can be reused and adapted with attribution. USWDS, Apple, Material and Nordhealth carry no stated reuse licence on their design-guidance pages, so a team should treat them as reference to build from, not as source to copy wholesale, and check the platform's own developer terms for any code they do ship.
• Do NHS and GOV.UK overlap? Yes, substantially. The NHS Design System is built on the same underlying principles as GOV.UK's and reuses several of its patterns (dates, addresses, error handling), then adds health-specific components such as results and eligibility patterns on top.
• Does using a general-purpose system like Material or Apple's guidelines mean ignoring health-specific needs? No, but it means a team has to add that layer itself: plain-language content, medication and result displays, and the accessibility checks a health context demands are not covered by a general platform system and have to come from elsewhere (see this site's Foundations articles and Showcase cards).

Further reading

• NHS Design System - NHS England - https://service-manual.nhs.uk/design-system
• GOV.UK Design System - GOV.UK - https://design-system.service.gov.uk/
• U.S. Web Design System (USWDS) - designsystem.digital.gov - https://designsystem.digital.gov/
• Apple Human Interface Guidelines - Apple - https://developer.apple.com/design/human-interface-guidelines/
• Material Design (M3) - Google - https://m3.material.io
• Nordhealth Design System - Nordhealth - https://nordhealth.design