Making services in an emergency
When making services at a rapid pace due to a crisis like the coronavirus (COVID-19) pandemic it’s important for teams to meet the Service Standard and work in a user-centred way.
Using this guidance
This guidance only applies to public emergencies with a level of uncertainty like the COVID-19 pandemic. It does not apply to other situations with a rapid deadline where there is not much time to put a service live.
In a crisis or emergency situation you may need to put things live before they have been assessed but they will still be peer reviewed. Contact the assurance team at cddoassurance@digital.cabinet-office.gov.uk straight away to find out how your service will be assured.
You may have a short time before you need to go live. You may be creating a service at the same time the policy is being developed. So there is no time to spend on things that do not meet user needs. There is also no time to duplicate effort by making things and doing research activities that have already been done and can be reused.
The same principles apply: follow the phases of an agile project and follow the Service Standard and Service Manual to deliver a service that works for users.
Identify the user needs and your assumptions
In a crisis you may not be able to validate the needs before launch but it is important to spend some time identifying what they appear to be. This will help you with the other stages of the process.
Listing your assumptions is a good way to find out what areas of uncertainty remain.
As soon as possible, do research so you can change the service accordingly.
Reuse as much as possible
There is no time or need to reinvent things we already know work. You will save a lot of time and pain for your users by making use of elements and patterns from services that have already been tested with users.
You’ll need to work quickly so find out what tools, systems, skills, technology and design systems you already have access to.
Look at existing services
Before you start designing the service, look at existing government services with similar patterns or purposes. This will help you to:
- avoid creating something unnecessary if an existing service could be adapted
- find technology, design patterns and existing research that could be reused
HMRC’s existing Making Tax Digital platform allowed them to create services very quickly as they could make use of existing patterns and technology.
The Kickstart Scheme team at the Department for Work and Pensions designed a digital service to go live in one week by repurposing an existing service with similar patterns.
Reuse designs and patterns
Use the GOV.UK design system if possible. This has many benefits including improving the chance of your service being widely accessible. This will save you time. Other government design systems are also available.
Make sure any supplier you work with is familiar with Central Digital and Data Office (CDDO) and Government Digital Service (GDS) tools, technology and standards.
If there are needs your service has that cannot be met by the design system, contact other teams on cross-government collaboration tools like UK Government Digital Slack to see if they can help or have solved similar problems.
Reuse common components
Using common components makes it easier to build user-centred services because you do not have to invent your own solutions to problems. For example, instead of each service team getting a payment provider, we’ve created one payment product that can be used by everyone.
Reuse user research
Find out if teams have done user research on similar topics or use your organisation’s research library.
Even if you have to launch the service before you have tested it, do not skip user research. There are also things you may need to consider if you are researching emotionally sensitive subjects or choosing between face to face or remote research.
Consider using lightweight research methods such as pop-up research or highlighter testing.
Reuse available data
Existing data from GOV.UK can be very useful when designing or iterating a new service. For example, users often leave feedback on GOV.UK pages. Contact GDS if you do not have access to this information.
Reuse technology
Reuse technology as much as possible. You may need to make decisions about the short-term use of technology that are different from what you would do if you had more time. Keep a record of what decisions you have made due to time constraints. Then, when the immediate crisis has passed and you have more time, revisit these decisions to see what you should change.
If you decide to use freely available technology, or you are offered a paid technology solution for free, be very careful that this does not lock you into using a specific supplier in future that may choose to charge. Have an exit plan and the ability to migrate to different technology. Get advice from GDS if you are unsure.
Follow the guidelines for procurement in an emergency.
Reuse open standards
Use open standards as much as possible. This allows the service or product you’re designing to be interoperable from the outset so that it works seamlessly across government and the wider public and private sectors. Using an international open standard also makes it easier to exchange information.
For example, if your service will:
- share information between emergency services you should use MAIT as the open standard to exchange information about incidents
- refer people to other services, for example to tackle vulnerability issues at critical times such as in emergencies, use the OpenReferralUK standard
If your service uses contact information like addresses, use the open standards for government data and technology. This will make it quicker to build your service and get it assessed.
If you need help, contact the Data Standards Authority.
When the immediate crisis has passed and if you were unable to adopt some of the recommended standards, revisit your service journey or product specification to see what you should change.
Reuse APIs
Use existing UK public sector APIs. The API catalogue helps users across government find and access inter-departmental data exchanges. This can speed up the design and delivery of your service if the APIs form part of an existing data sharing arrangement.
Publish your code
Make your source code open and reusable. If, for operational reasons, you cannot develop in the open, act as though the code is already open. It is likely that the source code will be available under Freedom of Information laws. Make plans for publishing the source code as soon as possible as there are plenty of benefits to coding in the open.
Get advice from The National Cyber Security Centre (NCSC) about securely publishing code without revealing anything which could compromise the security of the project or the people working on it.
Communicate your intentions publicly. Publish blog posts about what you have developed and how people can provide feedback.
For example, NHSX blogged about the code behind the NHS Covid-19 app.
Prototype extremely rapidly
Make a rough prototype as quickly as possible, even if it is on paper. It will help avoid any misunderstandings about what the service is designed to do as well as show you what issues you’ll face.
Have the right capability in the team
During the COVID-19 crisis, a lot of organisations making services put their most experienced people into COVID-19 teams. That allowed them to get working quickly.
The best services were delivered by teams supported by their management. This support consisted of removing blockages and empowering the team to solve the problem in the way they thought best rather than sticking to a pre-agreed plan.
Support the team’s needs
Staff may be affected by the emergency themselves either directly or indirectly. The pace of sustained delivery in an emergency can be harmful to people’s wellbeing. Consider giving people regular opportunities to move onto or out of the team working on the services.
This means:
- people are less likely to experience burnout
- the team is unlikely to lose several people at once
- the team will keep the benefit of the outsider’s perspective when new people join
- fresh perspectives will regularly come into the team
Make sure everyone has line management in place and remind the team of the mental health and wellbeing support they can access.
Deal with uncertainty and change
The team must be able to be flexible with what they’re building as the situation changes - especially if policy is evolving, as it did during the COVID-19 pandemic.
Identify specific areas of uncertainty. What is subject to change? How will the team deal with uncertainty? What will the team do if it turns out that what they have been asked to build quickly is not what is needed?
Having a shared vision based on what real changes you want to see in the world rather than what you are delivering makes it easier for teams to adapt their approach when needed. The end goal is the same, they just have to change their way of reaching that goal.
Read about how GOV.UK used user feedback to feed into product development, public policy and operational efficiency during the COVID-19 pandemic.
Revisit policy
Government policy can accumulate over time as the crisis develops. Schedule time after the initial response to evaluate the impact of the accumulated policy to make sure it meets users’ needs.
Revisit designs
Peer review from outside your organisation can be a useful way of seeing if your service can be simplified.
Revisit teams as they scale
Actively monitor the size and role of teams, especially if you are working with a supplier. As the situation evolves it is easy for teams to become bloated or have overlapping purposes. Do regular retrospectives between teams to find out if this is happening.
Collaborate
Doing a quick experience map of the potential service area will show some of the teams you need to work with. Quickly start to connect up with policy teams across the service area across organisational boundaries and across government. Contacting policy and other relevant teams early reduces the risk of wasting time.
Identify decision-makers
Identify your decision-makers and senior stakeholders early. Tell them clearly what you need from them to be able to make a service at pace, along with the implications of delayed decisions.
Policy can evolve quickly during an emergency. Establishing these important relationships early will make sure the service is able to adapt when it needs to.
Use digital collaboration tools
Use the video call software and digital collaboration tools your organisation uses, if they’re already in place. Every organisation has different security and information assurance protocols so make sure the tools you use meet your organisational policies. Not having remote tools in place makes collaboration much harder and slower. However it may be possible to make your video conferencing tools work across government.
In the early stages of the COVID-19 pandemic, GDS led a project to identify which tools different organisations can use.
Check what your colleagues have access to, as different departments may have different technology policies. Make sure the tools you use are accessible. Ask people beforehand if there are any accessibility needs so you can make sure people can fully take part.
Build relationships
When working across different professions and organisations it’s important to build strong relationships in order to develop productive shared ways of working.
For example, The Vulnerable People Service was built over a weekend. As they scaled, the team collaborated with 40 partners across 8 departments, the NHS, local government and local delivery partners. They established data sharing agreements and had daily calls with co-service owners in the Ministry of Housing, Communities & Local Government (MHCLG) and weekly ones with healthcare (NHS Digital and the Department of Health and Social Care) to translate policy intent into a workable service proposition. They won the Civil Service Collaboration Award for this work.
Make sure the service team is regularly talking to operations as people start to use the service.
Include stakeholders in user research
Involving stakeholders in user research sessions can be a useful way of establishing a common understanding of users’ needs and problems in complex and fast-moving situations.
If you’re doing research when there is risk of COVID-19 you must think carefully about choosing face to face or remote research.
Use agile at pace
Use whichever agile ceremonies make most sense in your situation. You could have standups twice a day, for example, or prioritise retrospectives over planning if the situation is changing quickly.
It is also important to identify what current development processes if any will slow you down and need iterating.
Document your approach
It may seem counterintuitive to spend time documenting things like how decisions were made and when, as well as product aspirations and areas of uncertainty. However it will save you time and make it easier to demonstrate your service.
For example, the Driver and Vehicle Standards Agency (DVSA) used documentation effectively when working at pace and found that it helped them focus on the important decisions.
Accessibility: do an audit
Do an accessibility audit at the earliest point you can. Using the GOV.UK Design System will make it easier to make sure your service is accessible.
Build for scale and resilience
Consider how many people could use the service during peak demand and do load testing. Understand which user groups are most at risk so you can prioritise them. Include back-end systems in testing, and analyse how these back-end systems connect to other systems.
For example, the HMRC Self-Employment Income Support Scheme service team knew they would have about 3.5 million requests over a few days so they used invitations with time slots to stagger use and implemented a virtual waiting room during peak times.
If there could be unprecedented demand for the service how can that be mitigated? Think about what you’d do in the event of the service being overwhelmed.
For example, HMRC’s use of a content delivery network allowed them to enable queueing or throttle access to services if needed. You will need to put up messages telling users what is happening if you do this.
Security: contact NCSC
Security can be a challenge when making services at pace. As well as using technology effectively to secure your service and data, make sure to consider the risks of ‘social engineering’. NCSC defines social engineering as “manipulating people into carrying out specific actions, or divulging information, that’s of use to an attacker”.
Consider setting up a Vulnerability Disclosure Programme to allow people to report bugs directly to you securely.
Contact NCSC for an assessment early in development if your service is high profile and there is a risk of attacks.
Design content for a crisis
In an emergency, people may be afraid. They may doubt information that they read online. Their ability to understand information may be affected by their emotional state. Consider using fewer links, shorter sentences and more bullet points.
Show that your content is timely and accurate
You may need to timestamp pages to show when they have been updated so people know the content is up to date.
Plan for the future
Before the service goes live there should be a plan for what happens next. Is there a team to keep working on it? What roles and people will you have access to?
Teams should scale down once the immediate crisis has passed, especially if you are working with an outside supplier. But you must make sure there is a team with ongoing responsibility for maintaining and iterating the service - do not leave it unattended.
Plan for retirement
The situation may change in a way that means retiring your service. That might happen if it:
- is replaced with something that better meets the need
- becomes part of another service
- is no longer required
You must also keep checking analytics data and user feedback to see if your service is still needed.
If your service is not retired, it must have a beta assessment.
- Last update:
-
Guidance first published