At the beta and live assessments you also need to: Read these guides to help you create a service that’s simple: You must make the user experience consistent with GOV.UK to meet point 13 of the Digital Service Standard. A Government Service Design Manual for Digital ... It’s intended to be a good starting place to find information about building high quality digital services. Make a plan for the event of the digital service being taken temporarily offline. You’ll have to explain how you’ve done this at your service assessments. Read more of An extra assisted digital tool for service managers Use this data to analyse the success of the service and to translate this into features and tasks for the next phase of development. Our guides and tools help you design, deliver and manage government services. Report performance data on the Performance Platform, Improve service design with user research, Quality assurance: testing your service regularly, Designing for different browsers and devices, How user research improves service design, Understanding users who don’t use digital services, Assisted digital support: an introduction, Making your service accessible: an introduction, Encouraging people to use your digital service, Using data to improve your service: an introduction, helps users do the thing they want to do at the first attempt without having to understand government, is built on your users’ real needs, not your assumptions, the user needs you’ve found for your service in discovery and how you found those needs, including any needs for assisted digital users, research that identifies parts of the task which users find difficult - you’ll have to explain how you’ve changed the service to make these parts of the task easier for users and how you tested and researched to confirm this, any problems that you found in research which you’ll have to overcome to design the service, talk about the private beta, including how many users you tested with, how you recruited them, how you used analytics in your research, and what you learned that you didn’t find in alpha, explain who your users are and what you’ve done to understand their needs, including users who need assisted digital support, explain any changes to user needs you’ve identified as a result of researching with users, discuss the users of your service whose needs are most difficult to meet, and how you’ve been learning about those needs, talk about the design challenges your users’ needs pose for your service, talk about the research you’ve done in private beta, ie who you did research with, where and when - this should include research with users who need assisted digital support, give examples of user stories, personas or profiles for your service - ie identify people who need to use the service and what they use it for, including users who need assisted digital support, discuss research that identifies parts of the task which users find difficult - you’ll have to explain how you’ve changed the service to make these parts of the task easier for users and how you tested and researched to confirm this, discuss any problems that you found in research which you’ll have to overcome to design the service, explain the research you did to understand whether your support model meets user needs and how that research informed iteration and testing, show how the design of the service has changed over time because of what you found in user research, show research that identifies parts of the task which users find difficult - you’ll have to explain how you’ve changed the service to make these parts of the task easier for users and how you tested and researched to confirm this, talk about the research you did in public beta and how you’ll use the results to continuously improve your service, ie who you did research with, how often, when and where - include users who need assisted digital support, give examples of user stories for your service - ie identify someone who needs to use the service and what they use it for - include assisted digital users, show the user needs you’ve found for your service, including for users who need assisted digital support, check your service is helping users to do the tasks they need to do, keep improving the service based on users’ needs, what your private beta will look like and how you’ll use what you find to improve the service, you can pay for user research and usability tests throughout the design of the service and after it’s built, how often you’ll carry out research and usability tests and how you’ll use the results to improve the design of your service, a user research plan for private beta and a plan for carrying out user research on the live service, you can pay for user research and usability tests throughout the design of the service and you’ll be able to pay after the service is built, how often you’ll carry out research and usability tests and how the results will affect the way you design the service, a user research plan for the service at the next phase and a plan for carrying out user research on the live service, how you’ve done user research with people who have accessibility needs from the time you started designing the service, how you’ve tested with users who need assisted digital support, how you’re using analytics data in your user research plan for the service, any problems you’ve found through testing and how you solved them, any problems you haven’t been able to solve in beta and how you’ll handle them in public beta, describe your delivery team - you need to employ people in the following roles: service owner, product manager, delivery manager, technical architect, assisted digital lead, designer, user researcher, developer, content designer, web operations engineer, performance analyst, front-end developer, show you have a service owner with the knowledge and power to make day-to-day decisions to improve the service, show you have at least one user researcher working at least 3 days each week, explain how the separation of key roles in the team means that nobody is performing multiple roles, show you understand where gaps may emerge in the team and how to fill them, explain your plan to transfer knowledge and skills from contractors to permanent staff, show that there’s a person on your team who’s responsible for user research and usability tests, show you’ll have a team that can keep improving the service after it goes live, show the team fully understands the service after it’s gone live, are easy and convenient for people to use, you can change easily, eg if government policy or technology policy changes, you can keep improving, eg based on user feedback, explain how you’re working in an agile way, using agile tools and techniques, and how you’ll continue to do so when the service is live, explain how you and your team have reviewed and iterated the ways you work to fix problems, explain how your team is using agile tools and techniques to communicate with each other, give an example of how the team has responded to user research and usability testing, show that your governance is agile, based on clear and measurable goals, and has a clear focus on managing change and risk in real time, the design options you explored for your prototype and the reasons you discarded some, how the design of the service has changed over time because of what you found in user research, the design options you’re considering for your assisted digital support, any problems that you found in research which you’ll have to solve to design the service, and how you plan to solve them, easily respond to changes in policy which affect the service, make sure your service keeps meeting user needs, explain what you’ve built in that phase and why you built it, describe the lifecycle of a user story from user research to production, show you understand how your service is built to meet user needs, explain your process for identifying and prioritising insights from user research, show you can move user stories quickly and smoothly between user research and production, show there’s minimal risk associated with the technology you chose, prove you have the ability to deploy software frequently with minimal disruption to users, show you’re analysing user research and using it to improve your service, show you’re solving any technical problems you’ve found, how long you expect your service to be in beta and why, how you’re practising zero downtime deployments in a way that doesn’t stop users using the service, how you plan to have enough staff to keep improving the service, check any risks or constraints associated with them, avoid contracts that lock you in and stop you improving your service, build a sustainable system which you can easily manage after your service goes live, the languages, frameworks and other technical choices you’ve made in alpha, and how this will affect the decisions you make in beta, the set of programming tools you’d like to choose for beta and why, how you’ll get value for money when buying any tools, how you’re managing the limits placed on your service by the technology stack and development toolchain you’ve chosen, what you’ve bought and how you’re getting value for money, the support arrangements you have in place, in normal hours and out of hours, any decisions you’ve outsourced to third parties and why you chose to do this, describe the tech stack changes you made during beta and why, describe the development toolchain changes you’ve made during beta and why, explain how you’re continuing to get value for money from the systems you chose and bought at beta, explain or demonstrate how you’ll check if the service is healthy, explain the support arrangements that you’ve set up for live, explain any decisions you’ve outsourced and why you chose to do this, they can access their information in the service when they need to, how you’ve identified threats to your service, including potential pathways for hackers, and tested ways of reducing them, how you plan to keep up to date about threats to your service and how to deal with them, any threats of fraud (fraud vectors) which exist and the controls you’re prototyping, describe your team’s approach to security and risk management, describe the security and privacy threats to your service, explain the fraud vectors that exist and the controls you’re putting in place, describe how you’ve worked with the business and information risk teams, for example the senior information risk owner (, describe any outstanding legal concerns, eg how you’ll protect data or your policy on sharing it, present your cookie and privacy policy and explain how you arrived at it, describe your ongoing interactions with the business and information risk teams, eg, describe any outstanding legal concerns, eg data protection or data sharing, explain how you’re keeping your understanding of the threats to your service up to date, and explain how the threats have changed during beta, explain how you’re keeping your cookie policy and privacy policy up to date, other services can reuse the software you’ve created, other services don’t end up doing work you’ve already done and you reduce costs in government as a whole, you avoid starting technology contracts that you can’t end easily, explain how you plan to make all new source code open and reusable, confirm that you own the intellectual property, explain how someone else can reuse your code, explain how you’re making new source code open and reusable, show your code in an open internet source code repository, explain the licences you’re using to release code during beta, explain how a team in another department can reuse your code, explain how you’re using code from other teams or services, describe how you accept contributions and comments on the code, explain how you’re handling updates and bug fixes to the code, explain the licences you’re using to release code, explain the code you’ve not made open and why, save time and money by reusing things that are already available, such as, can move between different technologies when you need to and don’t get locked into contracts which are difficult to end, can quickly and easily change your service when you need to, can give your users a more consistent experience when using government services online - this builds trust, use open standards and common platforms to avoid getting locked into contracts, use common platforms for your system, such as, identify the common user needs your service meets and what you reuse from across government to help meet those user needs, manage what the service outputs to users is and in what format, manage common data you hold and your commitment to publishing it, manage the common data you hold and meet your open data responsibility, can create new environments quickly and easily, know the data that exists in your pre-production environments, are designing and testing your service to work with the devices and browsers your users use -, are testing your service in an environment that’s as similar to live as possible, know that your service can keep working when the number of expected users try to use it, including for users who need assisted digital support, understand the systems you need and the testing environments for non-digital parts of the service, are testing your service frequently - you’ll have to explain how you’ve decided how often to test, how users of the beta service would be affected if the service was unavailable for any length of time, how you’re selecting technology and platforms that meet your availability requirements, your data recovery strategy and how you’ve tested it, the most likely causes for the service going offline and how you plan to stop them from happening, your strategy for dealing with outages, including who’s responsible and the decisions they can make, how users would be affected if your service was unavailable for any length of time and how that’s changed since beta, how you’re making sure the technology and platforms you’ve selected still meet your availability requirements, your data recovery strategy and how often you’re testing it, the most likely ways the service could go offline and how you plan to stop them, show the majority of users of your service are succeeding the first time they try to use it, explain how you used research, testing and analytics to make substantial iterations to your service, including the assisted digital support model, explain all end-to-end user journeys, including assisted digital journeys, demonstrate that they work and how you tested them, explain the design options you’re considering for your assisted digital support, explain how you’ve designed your assisted digital support model to meet user needs and how you’re providing it - if you’re not providing it by telephone, face-to-face, talk through and on-behalf-of, you must explain why, explain how your assisted digital support will be sustainably funded and free to users, explain how you’ve done usability testing, including users with the lowest level of digital skills, explain what you learned by testing your assisted digital support model, explain how you made design and content decisions based on user research, usability testing and analytics, discuss how many rounds of usability testing you’ve done, the users you included, the tasks you set, and the materials you gave them to complete the task, explain how you’ve changed the interface design in response to usability testing, showing your build, measure, and learn cycles, the hypotheses you tested, what happened and how you reacted, show how most people can get through the service end-to-end without assistance, explain how you’ve tested your assisted digital support model (the way you plan to help people who lack the skills, confidence or internet access to complete the service on their own), discuss whether your usability testing included the supporting content and proposed start page for the service, explain how you tested whether the name of your service makes sense to your users, how you’ve used analytics and user research to reduce dropout rates for your digital service, users trust GOV.UK services because they recognise the style, you don’t have to build something entirely new so you save time and can focus on unique parts of your service, you’re using patterns and style which are based on data and user research, explain how your team has included designers, content designers and frontend developers, explain how the service has used the styles, components and patterns in the, the service is responsive and works on mobile devices, the headers and footers match the GOV.UK style, you’ve got a start and end page on GOV.UK and that both are optimised for users, save money by reducing the number of people using non-digital channels, eg call centres, help your users to develop their digital skills, give better assisted digital support to those who can’t use digital services on their own, the other channels your service is delivered through, the data you collect on your other channels, how you collect data on service usage for each channel, the organisations and groups that help your user with the existing digital or non-digital services, insights from research with real users, user demographics, attitudes, behaviours and channel preferences, and user journey maps, how each channel meets different users’ needs, how you’ve designed the digital service in a way that gives it clear advantages over other channels, explain how you plan to increase digital take-up during beta, show the evidence behind your plans for increasing digital take-up, show weekly analytics or metrics for usage volumes across channels, show how you’ve improved the way you communicate with users based on user insight, discuss analytics data that shows how your new ways of communicating have performed, explain how you’re planning to promote digital take-up, your plan for moving users to the digital service including yearly targets for increasing digital take-up for the next 5 years, your plan to phase out non-digital channels as digital take-up increases in the next 5 years, the evidence behind your plans for increasing digital take-up and phasing out non-digital channels, using the data to support improvements you make, explain how you decided the data you need to capture, where you need to capture it from and how you’ll capture it based on the projected size and shape of the service, show you have an ongoing roadmap for performance analysis and someone in the team responsible for identifying actionable data insights during alpha, including assisted digital support, show you’ve used qualitative and quantitative data to help improve your understanding of user needs and identify areas for improvement, explain how you’ve chosen suitable data analysis tools, show you’ve addressed information security and privacy issues appropriately, explain how you’ve mapped user journeys through the service and tracked them to identify completions and areas of poor performance, show how you’re measuring assisted digital support, explain the next user story related to performance analysis, show you’ve discussed a start page and feedback page with GOV.UK (beta assessment only), using data to support improvements you make, how you’ve set a performance baseline for the old service, if there was one, how you’ve assessed the potential for channel shift and the level of assisted digital your service needs, other metrics that you’ll measure, when you’ll start, and how you’ll use them to improve your service, where you’re getting the data for your metrics, how you’ve set up your analytics package to collect user journey data, how you’ve made sure all stakeholders are actively involved in promoting or supporting digital delivery of the new service, how you’ll track people moving from using the offline service to the online one (beta assessment only), make quick, data-driven decisions about how to improve your service, compare data across multiple government services, be open and transparent to the public about your service’s performance, registered your service with the Performance Platform, checked that it can support the metrics you want to present on your dashboard, your beta dashboard with baseline data, explain your audience for beta and describe how you’ve been using the dashboard during beta, the metrics that are uploading to the Performance Platform and whether they’re being uploaded manually or automatically, show your published Performance Platform dashboard, including metrics for the 4 key performance indicators (KPIs), and other metrics, explain what your other key metrics are and why you’ve chosen them. You’ll have to discuss how you’ve used agile methods at your service assessments.