Information

You appear to be using an unsupported browser, and it may not be able to display this site properly. You may wish to upgrade your browser.

What you need to do in beta

Meeting the Digital Scotland Service Standard

During beta there are pieces of evidence you will need to collect to meet the Service Standards. The following sections explain what you can do to meet each Service Standard.

Understand users and their needs

You should:

  • demonstrate what primary research activities you have undertaken to test your service
  • provide an overview of any usability testing and improvements made

Solve a whole problem for users

You should:

  • document user needs that will not be delivered at this stage so they can be used as a continuous improvement opportunity
  • demonstrate how policy teams have been involved with the development of the service

Design and deliver a joined up experience

You should:

  • demonstrate how the channels the service uses meet the needs of their different user groups
  • show that the offline experience (for example, paper forms or telephone) delivers the same results as the online experience for users
  • ensure your service works on the most commonly used mobile devices and browsers
  • provide a resourced plan for continuous improvement activities once the service is live

Help users succeed first time

You should:

  • explain how the design has changed based on responses to usability testing in beta
  • describe any problem identified and how they were resolved
  • outline how you’ll carry out research and usability tests as part of continuous improvement

Make sure everyone can use the service

You should:

  • demonstrate that you have undertaken user testing with organisations and groups who help users access existing services
  • explain how you tested your assisted digital support model and what you learned
  • describe how you engaged a broad range of users and how you recruited participants from hard to reach groups
  • demonstrate that your service materials use simple language to ensure accessibility and understanding for all user groups
  • show how users can request alternative formats or support to access your service

Have a multidisciplinary team

You should:

  • document the make up of your team in terms of resources, full time equivalent staff and skills
  • provide evidence of a resource plan for transitioning from beta to live
  • provide examples of their team way of working and communication practice in operation

Iterate and improve frequently

You should:             

  • evidence that the service is not constrained by time and can be continuously improved once live
  • demonstrate that you have solved any technical problems and the senior responsible owner has accepted the level of technical debt being carried through to the live service
  • show how the service has further developed in beta and that the minimum viable product will meet the highest priority user needs

Create a secure service which protects users’ privacy

You should:

  • demonstrate that business and information governance stakeholders have been involved in securing the service and agree with the approaches taken
  • evidence that the service meets the security requirements set out in legislation, guidance or policy
  • demonstrate your approach to security risk management for the live service
  • show how your service will deter cyber attacks, hackers and fraud
  • provide a data protection impact assessment
  • provide evidence of how security testing will be undertaken for continuous improvement

Define what success looks like and publish performance data

You should:

  • show that the data points and key performance indicators used in service development will also be available for the live service
  • evidence that the service has performance management as a core feature
  • show how your service performance data will be published and shared with appropriate channels

Choose the right tools and technology

You should:

  • be able to describe the component parts of the service and how data and Application Programming Interfaces (APIs) are managed
  • explain how technical governance will work during the live phase and how risks will be managed
  • show that you considered different technical choices for the live phase and how they are value for money
  • evidence you are using public cloud services or provide justification why you are not using them
  • be able to show contracts in place with vendors including performance and progress reports
  • demonstrate how the environmental impact of your service is being measured and reported

Make new source code open

You should:

  • write code in the open from the start
  • understand when you should not publish code
  • describe how you’ll do open source
  • make source code you’ve created available for reuse

Use and contribute to shared digital practices, processes, components, standards, patterns and platforms

You should:

  • evidence that any code, components, patterns, insights or knowledge created have been shared
  • evidence that your service meets data standards
  • explain your approach to data quality and how you will monitor and improve this in the live phase
  • justify why any data will not be published

Operate a reliable service

You should:

  • carry out quality assurance testing regularly
  • plan for major events
  • maximise uptime and speed of response for the online part of the service
  • deploy software changes regularly without significant downtime
  • put processes and tools in place to operate the service in case of any incidents

Ensure sponsor acceptance

You should:

  • provide a current version of your service governance framework
  • evidence that you have tested your end to end service with the senior responsible owner
  • demonstrate a communications plan for internal and external stakeholders for when the service is live

Related guides

Back to top