GDS assessments – a guide for user researchers

What is a GDS assessment?

A GDS (Government Digital Service) assessment is a formal review carried out by expert assessors from across government. This process exists to check that a service has been designed and built to GDS Standards, which are a set of 14 criteria that support the development of user-friendly end-to-end government services.

Read the full set of GDS standards

A GDS assessment will happen at key stages of the service:

  • end of Alpha → Alpha assessment
  • end of Private Beta → Beta assessment
  • after Public Beta → Live assessment

After a service passes Live, it moves into a stage known as ‘continuous improvement’. A new ‘discovery review’ assessment is also being introduced to assess new services before they begin Alpha.

Why do they matter?

A successful GDS assessment:

  • makes sure government services are usable, reliable, and user‑centred
  • allows a team to move to the next phase of development and receive further funding
  • has a positive reputational impact for the organisation being assessed

Will my project go through assessment?

Factors that may influence the likelihood of a project going through assessment include:

  • volume and type of users of the service – public-facing services are assessed more than those used by NHS employees
  • how long the service has been in the Beta phase
  • how the project is funded

If you are unsure, ask your team or lead/senior UR if an assessment is expected on your project.

Who takes part?

Not all team members attend or are expected to participate in the assessment. However, the UCD team are often heavily involved in the preparing the content, delivering parts of the presentation to the assessors, and participating in the assessment.

Your assessment team usually includes

  • the delivery team (product owner, delivery manager)
  • the user-centred design team (user researcher, content designer, interaction designer, service designer)
  • the technical team (lead developer, technical or solution architect)

A performance analyst may join to discuss Standard 10 (performance data). Testers and business analysts may help during the preparation stage but are not usually part of the assessment on the day.

Who assesses you?

Department for Health and Social Care (DHSC) assess most NHSBSA services, often with assessors from DHSC, UK Health Security Agency (UKHSA) or NHS England. Large services may have a wider cross‑government panel.

Within the assessment team, the roles include:

  • lead assessor
  • UR assessor
  • design assessor
  • tech assessor

The lead assessor focuses on team delivery and management. They are also usually in charge of keeping the assessment on track, making sure each standard is given fair consideration on the day. UR and design assessors usually work together to assess the UCD input. In particular, the degree to which the UR underpins the design decisions. The tech assessor will focus on development and technical architecture.

What happens during a GDS assessment?

The assessment usually runs from 10am to 2:30pm. It consists of the team presentation, which is around one hour, followed by a question and answer session with each assessor. The UR section is usually 40 minutes long. It focuses on methods, findings, representations of key groups, plans for future research and how the UR has contributed to the designs process.

It is important to remain alert during the questions on the day as you may have to jump in during the design or tech sections if there is a question which has a UR element.

What happens afterwards?

Assessors meet privately in a session known as the ‘wash-up’ to gather their insights and discuss what the team did well and areas to improve. They then write a report which they aim to get to the delivery team within 5 days. In this report each standard is rated red, amber or green. These RAG ratings show whether a service is ready to move to the next phase.

  • All green ratings → the service has passed the assessment and can move to the next phase.
  • Amber or red ratings → this means the assessors have found issues and more work is needed.
    • Minor issues: a short follow‑up call in weeks.
    • Bigger issues: reassessment in a few months.

Failing is common. In 2024-2025, 57% of services did not meet all standards first time. Standard 1, which is related to UR, was not met 46% of the time.

Receiving an Amber/Red is normal and not a reflection on you as an individual. GDS assessments are a team effort and no one single person should feel responsible for an issue raised. It is important that you digest the feedback given by the assessors and use it to strengthen your work for the next time.

How should my team prepare for a GDS assessment?

Before a GDS assessment, internal NHSBSA assessors should review the slide deck and evidence at a mock assessment. Lead delivery managers are responsible for scheduling mock assessments, and they should take place around a month before the GDS assessment date. If your team do not have a mock assessment scheduled before a GDS assessment, speak to your lead UR.

About a week before the GDS assessment date, the delivery team submit their prepared slide deck and evidence pack to DHSC. The typical evidence provided by the UR team includes:

  • user needs log
  • personas and mindsets
  • UR plan for the next phase

Within the slide deck, UR should cover:

  • a research summary which includes methods and an overview of the demographics of participants
  • key research insights and user needs
  • personas and/or mindsets
  • a plan for the next phase which highlights gaps that you will address and when

Where to get help

Other NHSBSA colleagues will have gone through assessments before and will be able to share their experience and knowledge with you.

We have a team of trained GDS assessors at NHSBSA, particularly within the UCD team. These individuals are experts in the standards and what is expected at assessment and will be the assessors in your mock assessment. You can contact them through the Service Assessment Community of Practice on Teams.

Best practice documentation is accessible in the UR shared docs.

Other networks such as X-Gov Slack have best practice documentation and people you can reach out to for help.

Understanding the Service Standards for UR

It is important that you take time to familiarise yourself with the Service Standards for UR and educate your delivery team about them. The first 5 standards are most relevant to UR.

Standard 1 – Understand users and their needs

This is the main standard URs are responsible for. To meet this Standard, you must demonstrate:

  • research with a broad and diverse range of users, including under‑represented groups and those with access needs
  • use of varied methods (interviews, workshops, usability testing)
  • clear evidence that insights from research have shaped design
  • strong personas and mindsets
  • a detailed user needs log showing how you identified and met needs over time

For Standards 2 to 5, URs support designers by providing evidence and insight.

Standard 2 – Solve a whole problem for users

This Standard relates to how well the service supports users to complete a task from start to finish and find the information they need to do this. UR is important here as a team cannot be confident that they’re solving a problem without thoroughly understanding it.

UR input for Standard 2 includes:

  • users’ needs, motivations, and goals
  • tasks and pain points
  • how research informed the service direction

Standard 3 – Provide a joined up experience

Providing a joined up experience is about making sure the service flows smoothly when users have to engage with different government bodies in their journey. This might include different parts of the NHS, other government organisations (for example, HMRC) or even the same service over different channels (for example, a combination of online applications and paper forms).

UR should show research across:

  • various channels (online, phone, paper)
  • different organisations involved in the journey
  • users with low digital ability and accessibility needs

Standard 4 – Make the service simple to use

To help the team meet Standard 4, URs should make sure designers are well-equipped with insights from research. Specifically, to discuss how the service has been optimised to be simple and where UI and content changes have been made to serve users well. Usability testing should demonstrate iterative improvements over time. It’s vital that the UCD team work together to evidence how research has directly shaped design.

Standard 5 – Make sure everyone can use the service

This Standard is all about accessibility and inclusion. Specifically, making sure anyone with additional needs can access the service, and that the team has done dedicated work to enable this.

You need to show research with people with a wide range of access needs, including:

  • sensory (for example, visual impairments)
  • cognitive (such as dyslexia and autism)
  • motor (such as Parkinson’s)
  • physical disability

The UCD team must also consider and test the offline and assisted digital routes. Accessibility testing by quality assurance teams is helpful but not enough. You must conduct research with real users. Aim for at least 20–25% of research participants having access needs, as this mirrors UK population estimates.

Be aware that participants may not see themselves as someone with ‘access needs’ so it is worth checking with them during the session if they have any health conditions or disabilities that they feel impact how they use tech or online services.


Improve the playbook

If you spot anything factually incorrect with this page or have ideas for improvement, please share your suggestions.

Before you start, you will need a GitHub account. Github is an open forum where we collect feedback.