NHSBT must adopt the Government Digital Service Digital by Default Service Standard

Transcription

1 NHSBT must adopt the Government Digital Service Digital by Default Service Standard The Government Digital Strategy committed the government to ensuring all new or redesigned digital services meet the Digital by Default Service Standard from April This is also aligned best practice. For NHSBT this means adopting a new approach to delivering and operating ALL digital projects (including zero spend). Obtaining approval from GDS (Cabinet Office) before starting any work (pre DBC and procurement) Following the GDS Service Design Manual (Agile) Following the GDS Digital by Default Standards (26 criteria) *

2 The GDS Service Design Manual is based on Digital by Default Standards (26 criteria) 1. Understand user needs. Research to develop a deep knowledge of who the service users are and what that means for digital and assisted digital service design. 2. Put in place a sustainable multidisciplinary team that can design, build and operate the service, led by a suitably skilled and senior service manager with decision-making responsibility. 3. Evaluate what user data and information the service will be providing or storing, and address the security level, legal responsibilities, and risks associated with the service (consulting with experts where appropriate). 4. Evaluate the privacy risks to make sure that personal data collection requirements are appropriate. 5. Evaluate what tools and systems will be used to build, host, operate and measure the service, and how to procure them. 6. Build the service using the agile, iterative and user-centred methods set out in the manual. 7. Establish performance benchmarks, in consultation with GDS, using the 4 key performance indicators (KPIs) defined in the manual, against which the 8. Analyse the prototype service s success, and translate user feedback into features and tasks for the next phase of development. 9. Create a service that is simple and intuitive enough that users succeed first time, unaided. 10. Put appropriate assisted digital support in place that s aimed towards those who genuinely need it. 11. Plan (with GDS) for the phasing out of any existing alternative channels, where appropriate. 12. Integrate the service with any non-digital sections required for legal reasons. 13. Build a service consistent with the user experience of the rest of GOV.UK by using the design patterns.

3 The GDS Service Design Manual is based on Digital by Default Standards (26 criteria) 14. Make sure that you have the capacity and technical flexibility to update and improve the service 15. Make all new source code open and reusable, and publish it under appropriate licences (or give a convincing explanation as to why this can t be done for specific subsets of the source code). 16. Use open standards and common government platforms (eg identity assurance) where available. 17. Be able to test the end-to-end service in an environment identical to that of the live version on all common browsers and devices. Use dummy accounts and a representative sample of users. 18. Use analytics tools that collect performance data. 19. Build a service that can be iterated on a frequent basis and make sure resources are in place to do so. 20. Put a plan in place for ongoing user research and usability testing to continuously seek feedback from users. 21. Establish a benchmark for user satisfaction across the digital and assisted digital service. Report performance data on the Performance Platform. 22. Establish a benchmark for completion rates across the digital and assisted digital service. Report performance data on the Performance Platform. 23. Make a plan (with supporting evidence) to achieve a low cost per transaction across the digital and assisted digital service. Report performance data on the Performance Platform. 24. Make a plan (with supporting evidence) to achieve a high digital take-up and assisted digital support for users who really need it. Report performance data on the Performance Platform. 25. Make a plan for the event of the service being taken temporarily offline. 26. Test the service from beginning to end with the minister responsible for it.

4 The GDS Service Design Manual is based on a Lean Agile software development approach From (waterfall) Requirements, cost and time are locked at the start of the project The first time users see the product is testing or when it goes live too late and all the money spent Not used anymore for digital projects To Deep user (public) engagement early on Fixed budget and time but devolved control and prioritisation Building and testing in small time-boxed sprints (benefits delivered quicker) High priority requirements are developed and release first Co-located dedicated team

5 The discovery phase is about researching the user needs The objective of discovery Gain a high level understanding of user needs (inc assisted digital) Understand the existing service Define what prototypes in Alpha will explore Discovery phase duration The discovery phase typically takes 4-8 weeks (for a simple project epics/programmes could be longer). At the end of this phase you should be setting up the scope of the project as a set of prioritised user stories, and deciding whether to proceed to alpha Outputs Prioritised user story cards Understanding of the team and capability required Maybe some rough paper prototypes and user personas Understanding of the existing context and service (business and technology) and begin setting KPIs

6 The alpha phase is about developing a prototype and testing is with a small group of users The objective of an alpha build a working prototype gain greater understanding of a service test design approach begin to form the team develop options for the assisted digital support for your service. the alpha doesn t need to be a complete, end-to-end transaction. You re looking to demonstrate just enough so users gain some understanding of the service. Alpha phase duration the alpha phase is another relatively short phase. GDS try to limit these to about 2 months, running in week-long sprints over a 6 to 8 week period. Outputs high level story cards plan for beta and running of the live service working basic system that provides limited functionality that can be shown to a number of users final analysis on the research you have commissioned on user needs

7 The beta phase is about building a fully working prototype which you test publicly with users The objective of a beta build a fully working prototype which you test publicly with users continuously improve/iterate the prototype until it is ready to go live with users (rapidly releasing updates during the phase) resolve any technical or process related challenges measure the impact of the change on KPIs Beta phase duration It depends on the size of the project, however, typically a Beta does not take more than a few months. Following the release of the Beta, you will spend time iterating the service ready to go live. Outputs a public, end-to-end prototype a collection of prioritised work to be done (your backlog) a tested and supported assisted digital plan

8 The live service should meet all security and performance standards The objective of Live provide a fully resilient service to all end users that meets performance standards and has full analytics transition or integration of any existing services liaised with GDS to make sure all their requirements are met Met the users needs defined in discovery, alpha and beta Live phase duration This is not the end of the process, and the service should be continuously improved. This could involve repeating the whole process for smaller pieces (discovery, alpha, beta, live) This phase should therefore not end until the service is withdrawn. Outputs Continuously optimised service

9 Key GDS and Agile Terms User needs Any thinking about a service, whether online or offline, must start with the question: what is the user need? Defining a user need must be strict and honest. It s the need the user has of government, not the need of government to impart information to the user. User stories expressing a users (actor) need as a story from the users perspective. Includes the goals and acceptance criteria. Story cards - A user story is represented through a story card that has a title and a few lines of text. Contains title, actor, narrative and goal User personas - a representation of the goals and behaviour of a group of users. In most cases, personas are synthesized from data collected from interviews with users. They are captured in 1 2 page descriptions that include behaviour patterns, goals, skills, attitudes, and environment, with a few fictional personal details to make the persona a realistic character. Assisted digital - An assisted digital user is someone unable to use a digital by default service independently. Assisted digital support will be provided for these users so that they can use digital by default services. Assisted digital users include people who are offline, and people who are online but genuinely can t complete a digital by default transaction by themselves. Prototype - Prototyping can start on paper with sketches. Hand-drawn sketches of what a service might involve are a good way to begin thinking things through. It s only when you start working in the same medium your users will be using (for online services that s generally a web browser) that you can really understand the experience you need to provide. Sprint - a set period of time during which a list on user stories are completed: typically 1-2 weeks. The sprint team will be co-located and have daily stand-ups, sprint planning, sprint reviews and retrospectives meetings. Epic a large use story (theme is also sometimes used for a collection of user stories) Open Development Using interfaces/apis etc. to make data available to other organisations/groups so that they can develop services using your data i.e. Transport for London make a lot of their travel data available to 3 rd party app developers.