Register with a GP Practice - Alpha Assessment

The report from the alpha assessment for NHS Digital's Register with a GP Practice service on 9 January 2017.

Stage: Alpha
Result: Met
Service provider: NHS Digital

The service met the standard with no mandatory recommendations before proceeding to private beta.

  • The team had a clear understanding of their users and had built the simplest viable prototype to meet user need
  • The team was cohesive, well-structured and with a clear vision. They expressed the choices they had made coherently and had commendable working practices.
  • The service is simple but high-value, and is a good enabler for future integration work with NHS systems.

About the service

Digital Leader: Gill Ayeling


The service enables users to register with a GP practice.

Service users

Any person looking to register with a GP practice in England.


Lead Assessor: Kit Collingwood-Richardson

User needs

The team had a good grasp of users and their needs. They understood the need to balance citizen need with the needs of GP practices, and coherently explained their approach to this. There was a gap around the need to understand the needs of users with access difficulties, which the panel expects to be addressed in the private beta phase (see recommendations). Overall, the team has a high degree of empathy with their user groups, which is heartening to see.


The team is to be commended on their thorough but pragmatic approach to preparing for the assessment. Their slides and demo are an exemplar of their kind and should be used to demonstrate service standard assessment prep to other service teams.

We also commend the team on their openness, particularly in their cross-government engagement, open show and tells, working with GDS, sharing team members with other services and integrating with the cross-government design community. They are to be congratulated on this approach.

The team is clearly passionate as well as knowledgeable about what they do, and the cohesiveness in the team was apparent even in a few hours. Their approach to research in particular was heartening, with regular and whole-team research sessions in place.

The panel notes that the team shape is soon to change, and recommends that the team members who are staying work hard to make sure the existing team culture and spirit prevails.

There are gaps for a number of technical roles, including webops and a technical architect. There is also a need for more time from a content designer as the current allocation means they can’t be involved in all product decisions.

The team should look to fill these positions and gaps in resource early in the private beta.


The panel recognises that the service is currently a prototype, and that the team will effectively rebuild it before going to private beta, which they aim to do in March. Nevertheless, the team should work quickly to get an approach to data management, storage, persistence and security, as well as monitoring/alerting packages as needed to allow them to assess service performance in early beta.

The team should review its hosting strategy as early as possible, making sure it can scale through beta. However the panel was pleased to see a focus on public cloud hosting and strongly encourage this as an approach. The team clearly has a good grasp of its technology and tooling, and should work to retain autonomy over this as the service scales.


The panel was satisfied with the design of the service, which has clearly gone through multiple iterations. The panel was impressed by the design lead on the service, who thoroughly grasped the implication of the design of the service and already has plans for further iterations. Parts of the service were at early stages and the team recognised the need to work on them. In particular, the free text field about health concerns struck the panel as something to make a focus of future research.

The panel noted that the team did not have full control over the start of the user journey, which is on the NHS Choices website. This isn’t a concern during private beta but the team should continue to build their relationship with the Choices team to make sure the service is easy to find for every user.


There was effectively no analytics in place on the prototype service. This isn’t currently a concern as there are no live users of the service, but the panel strongly recommends putting in basic analytics before any users begin to use the service in earnest. The product manager had a clear idea about KPIs for the service but these aren’t written down; this needs to be done urgently.


Early in the private beta phase the service team must:

  • Ensure all team members are in place for the team to sustain through the beta phase, with particular emphasis on developers, technical architecture, web ops and content design
  • Define their approach for managing service data, data persistence and security
  • Get advice on the Data Protection Act implications of the current service design
  • Decide on the core KPIs and metrics for private beta and find a way to measure them
  • Identify a range of GP practices as the first wave of private beta users, including practices in non-urban areas and those with a wider range of accessibility needs
  • Put a technical architecture in place which will allow the team to prepare for public beta

The service team should also:

  • Determine their initial approach to assessing assisted digital needs
  • Talk to the NHS Choices team about the entry point to the service, to make sure it’s easy for users to find and with as consistent an experience as possible between practices
  • Put a full plan in place for accessible design through the private beta phase, including multiple language needs and regular accessibility testing
  • Implement the recommendations of the content review appended to this report
  • Do more testing across different browsers, OS and device types and network conditions, including at the GP practice end.
  • Draw up an end to end journey map that includes ongoing system integrations.

Digital Service Standard points

Point Description Result
1 Understanding user needs Met
2 Improving the service based on user research and usability testing Met
3 Having a sustainable, multidisciplinary team in place Not met
4 Building using agile, iterative and user-centred methods Met
5 Iterating and improving the service on a frequent basis Met
6 Evaluating tools, systems, and ways of procuring them Met
7 Managing data, security level, legal responsibilities, privacy issues and risks Not met
8 Making code available as open source Met
9 Using open standards and common government platforms Met
10 Testing the end-to-end service, and browser and device testing Met
11 Planning for the service being taken temporarily offline Met
12 Creating a simple and intuitive service Met
13 Ensuring consistency with the design and style of GOV.UK N/A
14 Encouraging digital take-up Met
15 Using analytics tools to collect and act on performance data Not met
16 Defining KPIs and establishing performance benchmarks Not met
17 Reporting performance data on the Performance Platform N/A
18 Testing the service with the minister responsible for it N/A
Published 12 October 2017