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.
The users of this service are civil servants building digital services.
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 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.
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.
You should follow the suggested recommendations to improve the service before arranging your next assessment.
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
The service was also assessed against the GaaP requirements, and the panel had no concerns or specific recommendations regarding these.