Standard 2 is where you decide, usually without realising it, which patients your product will work for and which it will quietly exclude.
It is the most consequential standard in the Design Factors group and the one founders most confidently get wrong. The reason is structural: the people you recruit for user research are easier to find when they are younger, more digitally fluent, more highly educated, and more available. Almost every DHT design process starts with these users. Almost no DHT design process corrects for it later.
The decisions you make about whose feedback shapes the product are also decisions about whose health outcomes the product will improve, and whose it won’t. Read this way, user acceptability becomes a lever that determines whether your DHT narrows or widens the digital health divide.
What Standard 2 actually asks
The wording is short and easy to dismiss. Standard 2 requires manufacturers to “describe how representatives from intended user groups were involved in the design, development or testing of the DHT” and to provide evidence that user acceptability has been appraised. It applies to all three tiers — A, B and C — and NICE explicitly notes that DHTs meeting IEC 62366-1 (usability engineering for medical devices) may already have demonstrated compliance.
It pairs in practice with Section D1 of the NHS Digital Technology Assessment Criteria (DTAC), which covers usability and accessibility. NHS England’s February 2026 DTAC refresh cut the form by roughly a quarter, but kept usability and accessibility intact — a signal that nobody at the system level thinks this is the place to deregulate. From 6 April 2026, the updated form is mandatory for all new submissions.
Behind those few lines of guidance, NICE wants to see three things. Who was involved — documented participants, their characteristics, and how they map to the intended user groups. What method was used — focus groups, usability testing, co-design, ethnographic observation, or iterative prototyping appropriate to the question being answered. And what changed — evidence that user input materially altered the product, not just validated decisions already made.
If you cannot answer the third question, you do not have a Standard 2 submission. You have a marketing testimonial.
Where this becomes an equity standard
The most recent Lloyds Consumer Digital Index puts around 1.6 million UK adults entirely offline, with roughly 23% of the population — more than 12 million people — at the lowest level of digital capability and likely to struggle with online services. NHS England’s framework on inclusive digital healthcare is blunter still: 77% of those who are digitally excluded are over 65, 69% have a disability or impairment, and uptake of the NHS App remains markedly lower in the most deprived communities.
These are the populations a typical DHT user research panel does not see. Participants recruited through online ads, condition advocacy groups, or pilot-site clinics skew younger, more confident, more digitally fluent than the population the product will eventually be deployed against. The product gets refined for those users, tested with those users, validated with those users — and then released across a real-world population the development team never engaged.
The aggregate clinical-effectiveness story can still look strong. The population-level effect is to widen the inequality the technology was supposed to narrow. A diabetes app that drops HbA1c by 0.8 percentage points in a young, motivated trial cohort delivers very little in a frail, multi-morbid, digitally novice population — and that is the cohort the NHS is paying you to reach.
Standard 2 is the standard where this either gets caught early or gets baked in for the lifetime of the product.
Where founders keep getting this wrong
Three structural pressures push DHT teams towards shallow user research, and pulling against them requires deliberate organisational design.
The first is recruitment friction. Including the people who need the product most — frail older adults, non-English speakers, patients with low digital literacy, people with sensory impairments — is harder, slower, and more expensive than recruiting the willing. Many product organisations do not carry the research-ops capability to do this properly. The result is convenience recruitment dressed up as user research, with a participant table that flatters the product and misleads the founder.
The second is the conflation of clinical advisors with usability research. A Chief Medical Officer and a clinical advisory board are not user research. Advisors shape strategy; usability research observes behaviour. Both matter, but they answer different questions, and submissions that lean only on advisor input look naive to assessors and rarely catch the workflow issues that kill clinical adoption.
The third is the accessibility-as-compliance trap. Companies build the product, then run a Lighthouse audit, then declare WCAG 2.2 conformance. A passing automated score tells you nothing about whether a patient who relies on a screen reader can complete the core task. A single observed session with a representative user reveals more than every automated scan combined. The companies treating accessibility as a design input rather than a compliance output produce better products for every user — not just those with declared access needs.
What good looks like
Strong submissions on Standard 2 demonstrate user research as embedded organisational practice, not a sequence of episodic projects. A few markers separate the mature approach from the box-ticking version.
User research is a function, not a project. There is a designated researcher, or a product team with explicit research capability, and studies are commissioned and synthesised against an ongoing research-ops system — not stood up ad hoc when an assessor asks.
Recruitment is intentional about inclusion. Panels are stratified across age, ethnicity, digital literacy, language and disability, and the recruitment strategy is documented. Where the intended user group includes carers, healthcare assistants, receptionists, or pharmacists, those people are in the research — not assumed to be served by patient input. NHS Digital’s guide to digital inclusion for health and social care is the lowest-effort reference for how to think about this; using it visibly in your submission also signals to assessors that you understand the system you are entering.
Formative and summative testing are both visible. Formative testing — iterative, scrappy, focused on learning — runs alongside development. Summative testing — pre-release, realistic conditions, predefined success criteria — validates the final design against the use cases that matter. Tier C DHTs add a documented usability engineering file aligned with IEC 62366-1, including hazardous use scenarios and validation studies.
The feedback loop survives launch. Deployment telemetry, support ticket analysis, and ongoing user interviews feed iterative improvement. This connects neatly to Standard 16 on usage measurement and signals an organisation that takes its users seriously beyond the sale.
The strategic case for taking this seriously
There is a commercial argument for Standard 2 that rarely makes it into a pitch deck. The NHS is a federated, opt-in system at the point of use. A clinician who finds the tool clunky will work around it regardless of whether their trust has procured it. A patient who finds the onboarding flow opaque will churn out before the first clinical signal reaches the dashboard. High user acceptability is not a soft attribute — it is the precondition for the engagement on which every clinical outcome and every reimbursement model depends.
There is also a regulatory direction-of-travel point. The MHRA’s increasing emphasis on human factors engineering, the EU AI Act’s human-oversight requirements, and the FDA’s evolving usability stance all converge on a single conclusion: products that fail their users are increasingly being treated as unsafe products, not just commercially weak ones. The line between Standard 1 (safety and quality) and Standard 2 (user acceptability) is narrowing fast.
For DHT founders, the practical implication is that user research capability should be funded and staffed as core infrastructure — not project-level activity bought when an assessor asks. The companies that scale through the NHS look structurally different from those that perpetually pilot. One of the structural differences sits right here, in Standard 2.
Conclusion
Standard 2 reads as a UX standard. It functions as an equity standard. The decisions DHT founders make about whose voices shape the product determine which patients the product is useful for — and which it quietly excludes. The cost of getting this wrong is not a failed NICE reassessment; it is a product that aggregates as effective and disaggregates as unequal.
The fix is not more user research. It is better-distributed user research, run as an organisational capability rather than a launch milestone, and documented as the audit trail Standard 2 actually expects.
If you are building a DHT and your last three research studies recruited the same kind of user, that is the next thing to fix. Healthonomix helps DHT companies design evidence and research strategies that align with the NICE ESF and produce products that scale across the population.
