GOV.UK Notify - Alpha Assessment
The report from the alpha assessment for GDS's Notify service, user notifications feature on 22 March 2016.
| Assessment stage | Alpha |
| Assessment result | Pass |
| Service provider | Government Digital Service |
| Service features | User notifications |
Outcome of service assessment
GOV.UK Notify met the alpha Digital Service Standard and the draft Government as a Platform principles. The component has therefore passed its assessment.
The team shows an excellent understanding of its users and their needs. They are a strong, multidisciplinary team who are empowered to develop in the interest of their users. They have a strong alpha and a clear, well-expressed vision for their private beta; they should now be given the space to succeed.
About the service
Service Manager: Henry Hadlow
Digital Leader: Stephen Foreshew-Cain
This service is a component of Government as a Platform. It allows government services to build and send text messages and emails to service users. In the future it will allow services to send letters to users, but this functionality is out of scope for the current assessment.
Detail of the assessment
Lead Assessor: Kit Collingwood-Richardson
Design: Eddie Shannon
Research: George Papatzanis
Technology: Kevin Humphries
The panel assessed the component against the 18 points of the service standard assessment. It also assessed the component against five draft principles for Government As a Platform (GaaP) components:
- Meet technical and design standards - Components should be designed to meet the Digital Service Standard and the Technology Code of Practice. This will make integration with services easier.
- Avoid being tied down to one supplier - If components use suppliers, service teams should be able to choose from multiple suppliers and change quickly from one to another.
- Make it easy for the user - Components should support services to provide a high quality, straightforward user experience.
- Be independent - Components should be run for the benefit of government as a whole, not just a specific service or department.
- Meet a common need - Components should meet a simple and common need, shared by a wide range of services across government.
The panel discussed these principles and how they may usefully be iterated with the GaaP team after the assessment, but have not provided separate commentary in this assessment write-up.
Researching and understanding user needs [point 1, 2, 10]
The team has a strong grasp of user need and their research methodologies are excellent. They have done comprehensive research with departments to understand their notification needs and have built an alpha which is already meeting those needs. They correctly assert that government service teams are their primary users and have built the component with that in mind.
The team has a strong view of balancing user need between competing departmental priorities, which is essential for the success of this component. They have worked to ensure they are meeting core, common needs between departments, and have resisted pressure to create bespoke features or work for one particular department.
Running the service team [point 3]
The team is the right shape for the current stage of the component. The team is co-located, shares a common culture of openness and flexibility, and is clearly enjoying its work. They have a physical wall in their workplace showing everything from research hypotheses to definitions of success by phase, which is heartening to see.
The team is a strong group of digital professionals with relevant experience working on government services. They have the right blend of skills, in a mixture of dedicated and pool team members. They are well supported and have the freedom they need to act in the interest of their users, and to iterate at the right rhythm for the component. They have excellent support from the wider GaaP team.
Designing and testing the service [points 4, 5, 11, 12, 13, 18]
The design of GOV.UK Notify is already strong despite the early stage of the build, reflecting a significant design presence in the team. The team acknowledges that there is more work to do on design, and the panel wants to see far more thorough testing across the browsers and devices that civil service teams use when beta begins (see recommendations below).
Technology, security and resilience [points 6, 7, 8, 9]
The assessment panel has no concerns about the technologies the team are using. Their technology stack is the right one for the product at its current stage - lightweight, loosely coupled technologies (mainly Amazon or Amazon-friendly) which allow for swift deployment and can easily be built on as the component scales.
Improving take-up and reporting performance [points 14, 15, 16, 17]
The panel commends the team for the work it has done to advertise its existence and gather interest from departments. This has included blogging and writing about what the component is, appearing at events, specific research activity, and numerous field trips and visits to departments and operational centres.
Recommendations
There are no actions that the panel feels the team must undertake before they begin their private beta; the following are recommendations, split into urgent and non-urgent.
Upon entering the next phase, the team should urgently:
- Undertake a comprehensive review of content within the service, with particular emphasis on placeholder text, the use of templates, and guidance to help users not familiar with the technical aspects of integration.
- Begin comprehensive browser and device testing on a range of government technologies, acknowledging that these differ from those listed in the GDS service manual.
- Develop a more mature understanding of the fraud and risk factors which could affect GOV.UK Notify and act to mitigate these.
- Develop their knowledge of SMS and email providers to make sure that, as the component scales, it is taking full advantage of a maturing market.
- Do targeted research with high-churn operational centres and teams, ensuring the component and its accompanying guidance is appropriate and that teams can self-serve.
Over time, the team should also:
- Diversify their provider base for email.
- Develop a beta-appropriate service support model, which allows them to gather, theme and implement user feedback quickly and easily.
- Look again at the ‘manage team’ and ‘notification activity’ functionality, making sure both can scale and continue to meet user need as the service user group grows through beta.
- Be more specific about what their KPIs are and aren’t.
- Do more research with end users as part of understanding a user’s wider service journey, to better appreciate the role of GOV.UK Notify in these journeys.
- Ensure they continue to share their ongoing design pattern and concept work with other similar digital teams across government.
- Implement the accessibility recommendations the team have been given separately.