GOV.UK Notify - Beta Assessment

The report from the beta assessment for GDS - Notify 1 February 2017.

Stage: Beta
Service provider: GDS

The service met the standard because:

  • The team has fully understood the needs of their users, and makes frequent iterations based on research.
  • The service has been designed well and the whole team is closely involved with designing, testing and iterating the service.
  • The technology behind the service is well supported, secure and open source. The team also has a good understanding of potential threats and best practice for data management.

About the service


GOV.UK Notify is a service to be used by civil servants to send their service users emails, text messages or letters (coming soon). It allows them to manage the content of the messages in real-time through templates in an admin interface. They can then submit contact details and other personalisation for each recipient, and send messages. The messages can be sent by uploading content into the admin interface, or by integrating with existing web services, back or front office systems using a number of client integration libraries that we provide.

Service users

The users of this service are civil servants building digital services.


User needs

The team has an excellent grasp of user need, doing research across the range of users they currently have. They are to be commended on their approach to research, which is comprehensive and well-designed. The team is documenting research well and sharing outcomes with others. It can, and does, make frequent iterations to the component without adversely affecting users.

The team has standardised its terms of use, which will make it easier to scale the component out to other service teams quickly.

The panel commends the team on its open backlog.


The team is the right size and shape for the component is building. It is stable and works together well. Their culture and methodology is open, iterative and positive, which is what the panel would expect to see from a GDS team working on a cross-government component. The product manager has a clear vision and roadmap for the component, and the team is united behind this.

The team has got a good view of how the service team will need to evolve over time, and is sustainable into public beta and beyond. It is funded for the remainder of the SR period.


The team has chosen a modern, well supported technology stack and is operating it securely. Everything is open source and they have blogged about their choice of API approach.

The team has a good understanding of the threats to the online service and is using this understanding in iterating the service. The team has followed best practice by minimising the data stored within the service. Data retention periods were linked to confirmed user needs.

The team is working well within the known constraints of SMS and email delivery, and are doing effective horizon scanning to see how the service can be improved on this basis.


The overall design of the service is commendable. The whole team has clearly worked closely and often to design, test and iterate their service to meet the needs of its users. The work to let users, especially those will lower digital skills, trial Notify was excellent.

Content templates for the most common types of notifications like confirmations, reminders and updates, are needed. Then teams can edit tested messages, rather starting from scratch.

This panel considers that without these templates, scaling good content in messages will be harder and inconsistent, especially for medium and smaller services with little or no content skills available to them.

Historically, software for civil servants to do their jobs has been difficult to use. Notify is the best example to date of designing for these users. Therefore it is important the team shares their work as patterns so services across government can copy and benefit from.

Design review


The team uses Google analytics as a standard package. They are able to measure their own service KPIs, and feedback from sending notifications gives them an end to end loop.

The screens the team has built for service administrators allow easy monitoring of the service from the service team side.


The service team should also:

  • Automate their billing process to allow their commercial model and administration to scale.
  • Mature suspension of account process and guidance for service teams about intervention for poor data or performance
  • Publish case studies for service teams to bring together research, establish best practice and build up recommendations for how best to implement the component
  • Find a way to scale the way they quality assure service teams’ content
  • Create standard templates for common types of notification
  • Continue to strengthen links with service teams to make sure they get end user feedback and can test their component end to end
  • Continue to share new design patterns they’ve created with the GaaP team, with GDS and with the rest of government
  • Do more work with service teams of all types to better understand user need end to end
  • Look at additional ways to support the following:

  • Situations where SMS is unavailable due to network coverage or restrictions placed on staff
  • Users who would prefer to use their own, stronger mechanisms such as U2F and authenticator apps
  • Teams who would prefer to manage authentication within the organisation, for example by piggy backing on workstation logins or smartcards

  • Find ways to allow service teams to self serve where practical if the 2nd factor authentication device is lost or unavailable. This may include separating the service team administrator role from the other roles so that the administrator can do things like recover accounts.

Next Steps

You should follow the suggested recommendations to improve the service before arranging your next assessment.

Submit feedback

Submit feedback about your assessment.

Get advice and guidance

The team can get advice and guidance on the next stage of development by:

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 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 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 Met
14 Encouraging digital take-up Met
15 Using analytics tools to collect and act on performance data Met
16 Defining KPIs and establishing performance benchmarks Met
17 Reporting performance data on the Performance Platform Met
18 Testing the service with the minister responsible for it Met

The service was also assessed against the GaaP requirements, and the panel had no concerns or specific recommendations regarding these.

Published 24 July 2018