1. Understand users and their needs

 

Begin by understanding the full context of the user needs. Instead of solving for solutions, solve for the entire problem that the user is experiencing.

Get to know the user early on in the process by developing data around user goals through:

-   User profiles: Understanding the user through their demographical information, age, income, location, etc

-   User research: Interview the user for their pain points in the existing system. Observe the user interaction without interference. Understand user goals, which ones are being met, and which ones aren’t. Create user stories, a prioritized list of tasks the user is trying to accomplish.

 

Meeting this standard

- Spend time with current and prospective users of the service

- Discuss user needs that are most difficult to meet

-  Identify parts of the service that users find difficult and the problems that need to be addressed to improve the service

- Test the service with real users

- Track the changes and iterations made at each stage

- Measure the performance of the service after it has been built, and iterate as needed

 

By the checkpoint, you should be able to demonstrate: 

- A list of a complete set of users and their needs

- Established metrics of success 

- That you have tested the MVP with users

- Changes made to the MVP after user testing, demonstrably iterated upon

- Show how the design has changed over time

- Show the research findings that drove the changes 

- How you will continue to test the system with users

- Data from the user testing, particularly pointing out pain points in the system and how you will address them 

- How you will continue to monitor the service and measure against your metrics

 

2.     Bring in an experienced and multidisciplinary team

 

Establish a clear product owner who has responsibility for the service, supported by a multidisciplinary team that can design, build, and improve the service. This does not necessarily mean a full-time staff working on digital government, but rather a team of dedicated people experienced at creating modern digital services. 

 

Meeting this standard

- Member(s) of the team have experience building digital services, designing mobile and web applications, and have experience with modern development and operations techniques like continuous integration and continuous deployment

- Expertise in agile methods to design, build and deliver projects

- Knowledge of the context around the problem being solved

- Continue to improve the service once it’s gone live

- Proven track record in defining, measuring, and maintaining good products and services

- Collaborate and share between public servants and contractors as one team 

 

By the checkpoint, you should be able to demonstrate:

- Examples of existing products and services built by this team

- A product owner who is leading the team

- Evidence of expertise in agile methodologies 

- Understanding of the full context of the service 

- Metrics and ability to meet these metrics 

- Proof of continued improvement and user research once the service has gone live

 

 

3.     Be agile and iterative

 

An agile delivery method is an approach that defines the desired outcome for each project but doesn’t deem to solve it fully from the start. Instead, it breaks the work down into pieces, called iterations. Through user research, prototyping, and user testing, improvements are frequently made. This methodology encourages a “fail fast” approach, where mistakes can be identified quickly, early, and inexpensively.

 

Meeting this standard

 

- Create a minimum viable product (MVP) to be deployed as soon as possible for user testing

- Run usability tests to see how the service works

- Support frequent iterations

 

By the checkpoint, you should be able to demonstrate:

- An example of how the team has responded to user research and usability testing

- That your service governance is agile, based on clear and measurable goals

- Design options for your prototype and why some are discarded

- How the design of the service has changed over time 

- That you have identified any problems found in research and solutions to improve 

- Clear descriptions of the lifecycle of a user story, from user research to production 

- A thorough understanding of the deployment process and how you are able to support frequent deployments with minimal impact to users

 

4. Understand the tools and systems 

 

Research, evaluate, and identify the tools and systems needed to build, host, operate, and measure the service, and how to adapt or procure them. Where possible, reuse existing technologies. The fast pace at which technology develops requires that the tools and systems chosen and built are future-proofed, flexible, and scalable enough not just to meet current demands, but also anticipate future requirements and demands. 

 

Meeting this standard

- Review the types of tools and systems already available and understand the existing IT systems, data stores and in-flight processes for the services 

- Choose software frameworks that are commonly used by private-sector companies creating similar services 

- Ensure that software can be deployed on a variety of devices

- Apply agile methodologies to the contract, so that the team can be iterative with the service, and not locked into one particular solution 

- Prepare procedures for ongoing operations, including iterations, maintenance, monitoring, patching and upgrading system components 

 

By the checkpoint, you should be able to demonstrate: 

- You have identified the potential development tools and software to build the product 

- You understand the development toolchain 

- You understand the existing IT systems, data stores, and in-flight processes for the system

- You know the initial and ongoing costs for proposed tools and systems 

- Procedures for ongoing operations, including iterations, maintenance, monitoring, patching, and upgrading system components 

- The total cost of ownership of the technology and preserve the ability to make different choices in the future - for example, reducing the chances of getting locked into contacts for specific tools and suppliers using open standards  

- An effective approach to managing any legacy technology the service integrates with or depends on 

 

5.     Embed privacy and security by design

 

Government digital services contain sensitive information, data that must be protected through the appropriate legal, privacy, and security measures. We must identify the data that the service will use, store, or create, and ensure that it is:

 

-  Secure

-  Confidential

-  Can be accessed by the user

-  Protected during and after the use of the service

 

The goal of this is two-fold: it fulfills the responsibility of the government to provide safe services for users, and it allows those users to feel confident in using the digital services that are offered, therefore encouraging the shift to a digital-first mindset.

 

Meeting this standard

- Determine what data is collected, why, how it is used, shared, stored, and secured

- Consider whether the user should be able to access, delete, or remove their information from the service

- Actively identify security and privacy threats to the service

- Use an approach to identify assurance and authentication that balances the risks in a proportionate way

- Work with business and information risk teams to make sure the service meets security requirements and regulations

- Carry out appropriate vulnerability and penetration testing

 

By the checkpoint, you should be able to demonstrate: 

- That you have determined exactly what data will be collected and why

- That you have determined how that data is used, shared, stored, and secured

- How people will be able notified about how personal information is collected and used, including a privacy policy if necessary 

- That you have conducted tests for security vulnerabilities 

- That there is a form for the public to report a security issue 

- Have a plan to manage security during the lifetime of the project 

 

6.     Make sure users succeed

 

The purpose of our services is that they make the lives of the users simpler and better. Using a government service should not be stressful or confusing; it is our job that the user succeeds the first time, with minimal help.

 

Meeting this standard

- Make the service accessible for users with the lowest level of digital skills

- Do usability testing before and after the service goes live

- Test the name and the flow of the service to see if it makes sense for the user

- Test all the parts of the service that the user interacts with – online and offline parts

- Design the service to work online with a range of devices that reflects the users’ behavior

 

By the checkpoint, you should be able to demonstrate:

- The majority of users are succeeding the first time they try to use it

- The frequency you will use research, testing, and analytics to make regular improvements to the service

- Proof of usability testing before the service goes live

- Proof that people can get through the service from start to finish without assistance

- Proof that you can scale your testing to match the importance of the service and the volume of users

- Proof that those with the least digital ability is able to navigate the website