Why it matters

The standard helps:

  • define what good digital practice looks like in Ontario
  • identify the steps teams need to take to get there

The standard is built on the aspirations and experiences of teams across the Ontario Public Service and other jurisdictions, for example:

  • Canadian Digital Service and other provinces and territories
  • UK’s Government Digital Service
  • Australia’s Digital Transformation Agency
  • United States Digital Service and 18F

Release in phases

Ontario’s service design journey follows design and release phases. Each phase is driven by user needs and prioritizes several points from the standard. Learn more about how to work in design and release phases in the Service Design Playbook.

User
needs
DNA strand metaphor with user needs woven throughout the helix which twists four times, for each phase of service design

Discovery

Conducting user research to understand user needs

DNA strand metaphor with user needs woven throughout the helix which twists four times, for each phase of service design

Alpha

Testing our hypotheses with users using prototypes, models, examples or mock-ups

 

DNA strand metaphor with user needs woven throughout the helix which twists four times, for each phase of service design

Beta

Developing a minimum viable product or service that adds immediate value for users while the team develops and improves features.

DNA strand metaphor with user needs woven throughout the helix which twists four times, for each phase of service design

Live

Continuing to improve the service or product based on user feedback and data

1. Understand users and their needs

Start with users to define the problem. Do research to develop a deep understanding of who the users are, how they behave and what that means for the design of the service or product.

Why it matters

Understanding the needs of people who use the service or product is critical to building something that works for them. It’s easy to make assumptions about users or be influenced by personal experiences. It’s important to include people with different experiences and perspectives.

It’s also important to do user research with the people who will be end users. This is different from research and testing with internal government staff (unless they are the users) or other stakeholders. Staff and stakeholders have valuable user insights, but they also have information and experiences that makes them different from the end users themselves.

It's especially important to design and test early with people with disabilities, people who use alternate technology and people with diverse or unique needs.

Get to know your users and their needs from their point of view. Watching users complete a task, or fail to complete a task, leads to insights you may not discover by asking people about their behaviour, likes and dislikes.

Taking the time to understand the people who use your service will help:

  • discover additional opportunities and insights
  • deliver better solutions and service or product experiences
  • prevent wasted effort implementing the right idea in the wrong way

It’s helpful to define who your users are and who the atypical users may be.

Atypical users, also known as edge cases, include those who may:

  • be extremely satisfied or extremely dissatisfied with the service or product
  • have much more or much less digital literacy or access than your typical users
  • use or access the service or product much more or much less frequently

These users are a great source of insight. Their needs are generally amplified in some way.

Use the needs of atypical users as a compass to help articulate the challenges that typical users may not experience in the same way. Addressing atypical user needs becomes critical to building tools that work for everyone. It will also help avoid inequalities introduced by digital services or other channels.

To inform what features to build, interview users and gather data to develop:

  • user needs as goals in this format: As a [user type], I want/need [goal] so that [reason]
  • user personas that summarize example user groups with descriptions of their habits, personality, attitudes, abilities and motives, gender, age, location, income and family size

How to meet this standard

At a minimum:

  • list all your user groups and their needs and expectations
  • address any gaps when testing during the alpha and beta stages
  • give examples of user personas for the online service
  • identify areas users find difficult and any problems that need to be overcome
  • observe user behaviour in testing to improve your understanding of users and their needs

In the next stage:

  • test and observe real users interacting with the service/product and be able to explain:
    • any new insights and lessons
    • how test participants were recruited
    • how analytics were used in research
    • number of test participants and their basic demographics
    • number of test participants who experienced accessibility challenges or needed assisted digital support
  • explain any changes identified as a result of researching with users
  • discuss user needs that are the most difficult to meet
  • talk about the design challenges that user needs pose for the service/product

In the live stage:

  • show research that identifies parts of the task users still find difficult
  • demonstrate improvements to those areas and how they were tested and researched
  • talk about how research results will be used to continuously improve user experience, for example, participants, frequency, location, timing

2. Establish the right team

Put in place a sustainable multidisciplinary team who can design, build and continuously improve the digital service or product led by a skilled product manager who is empowered to make decisions.

Product managers set the strategy for and define features of a digital product. They are responsible on an ongoing basis and until a service or product is decommissioned.

It’s not the same role as a project manager who is focused on the delivery of a temporary, less iterative process and project.

A digital service or product is anything created for a defined group of users. In this standard, product refers to any online information or transactional part of a service used by people in Ontario.

Why it matters

It’s important to have a strong multidisciplinary team in place led by one person who is accountable and has the authority to make decisions based on the outcomes of research and testing.

The team’s skills and focus need to evolve as the service or product is designed and developed. The team also needs to adapt its structure based on service or product needs and the phases of work.

To be successful, build a team with:

  • a broad mix of skills and roles from the start
  • quick decision-making processes and the ability to change and adapt
  • the ability to deliver and the resources needed, including senior or executive support

How to meet this standard

At a minimum:

  • work collaboratively
  • identify gaps in the team and fill them
  • transfer knowledge and skills to others
  • dedicate one user researcher to the service/product
  • build a team with expertise in agile, lean and digital service delivery, technical, user experience and policy skills
  • embed expertise from other business areas and ministries, for example, finance, legal, policy, correspondence, to achieve desired outcomes
  • have a product manager with the ability to make day-to-day decisions to improve the service
  • continue to improve the service or product after it’s gone live
  • involve the maintenance team for the service or product in the early design phases
  • make sure the team has senior and executive sponsorship to support their decisions, goals and vision for the service or product

3. Be consistent

When the public interacts with the Ontario government, their experience should feel cohesive, positive and consistent.

Why it matters

Using standard platforms and design is a cost-effective and consistent way of providing public services and makes the most of public resources. Additionally, users need to know and trust when they are:

  • on an official government website
  • using an official government service or product

From branding to tone of voice and error handling, users should feel confident in their ability to complete their tasks properly and in our ability to guide them to the completion of those tasks.

Use Ontario’s Design System. It establishes styles and components that follow usability and accessibility best practices and are aligned with Ontario’s visual identity standards.

How to meet this standard

At a minimum:

Laws and rules to follow

4. Design the service from start to finish

Understand what users are trying to do and design the simplest, fastest way for them to complete their task and achieve their goal. Where possible, each step of the journey should be completed online.

Why it matters

It’s important to understand what users are trying to do when they access a service and how that service fits within the broader context of their life.

The service design experience is much more than what people interact with on screen. It begins when they first hear about a service or product and it doesn't end until they achieve their goal or complete their task.

Understand, streamline and refine the complete end-to-end journey users take to complete their objective, including the actions they take in every channel, for example:

  • online
  • by phone
  • by mail
  • in person

Every encounter — whether it’s online or offline — needs to be carefully considered to help the user get closer to their end goal.

How to meet this standard

At a minimum:

  • ensure prototypes (models or mock-ups) incorporate the end-to-end user experience
  • examine all channels to understand the steps users take to complete their goal and where your service fits into their journey
  • show a journey map of all the touch points in a user’s experience from awareness of the service or product to completion of their goal
  • have a user research plan that spans every stage of service design up to the launch of a live service or product, including next phases for improvements
  • apply lean service design skills to reduce the number of steps a user must take in their end-to-end journey before you begin prototyping
  • have a plan for error recovery at each step, for example, if a user gets stuck, how will they ask for and get help?
  • demonstrate the results of user research, for example problems found through usability testing, and explain how this informs solutions and improvements to design
  • explain the frequency of research and testing, and how results will be applied
  • do user research from the start with people who have accessibility needs
  • use the inclusive design cards to help you sketch, plan, prototype and design
  • test with users who need help to access digital tools
  • use analytics data in user research and service or product improvements planning

5. Ensure users succeed the first time

Using a government service should be an intuitive and stress-free experience. Good service should be so simple that users can succeed on their very first attempt without the need for assistance.

Why it matters

It’s important to make sure a service, product or task is as simple and straightforward as possible. All users, even those who have accessibility needs or lack digital experience, should be able to complete each step easily.

If a service or product is complex or unclear, users will be forced to contact that organization for help or visit an office in person to complete their task. They may even avoid using the service or product altogether.

Not only does this lead to higher operational costs, but it can also lead to user frustration and a loss of confidence or trust in government.

How to meet this standard

At a minimum:

  • explain the service or product and include who it is for, why it exists and how to use it
  • include contact information so users can get help if they need it
  • make sure most users will succeed the first time they try to use it
  • demonstrate how often you will use research, testing and analytics to improve to the service or product regularly or continuously
  • demonstrate that the end-to-end user experience on all channels work and test each of them, including for people who need support accessing digital tools
  • do usability testing at least once before and after the service or product goes live and make improvements accordingly
  • scale your testing to match the importance of the service or product and the volume of users
  • make design and content decisions based on research, testing, analytics and user needs
  • make sure people can find the service or product, including by testing its name to know if it makes sense to users
  • use analytics and user research to reduce the number of people who didn’t complete the task they set out to do online, for example, to renew their driver’s licence or licence plate sticker

6. Test the end-to-end service

Continuously test the end-to-end service to make sure that it remains available to users and free of errors.

Be sure to test with the browsers and devices people will use to access the service, including assistive devices. An assistive device is a piece of equipment a person with a disability may use to help them with daily living, for example a screen reader or a hearing aid.

Why it matters

Users expect digital services to be simpler, faster and always available. Don’t wait until users discover an error. Monitor the online service and make sure it doesn’t go down at the times when users may be using it. More satisfied users will maintain their trust and confidence in government services.

How to meet this standard

At a minimum:

  • design and test the service or product to work with users’ browsers and devices, including assistive devices
  • use a testing environment and context as close as possible to those that users will experience
  • provide developers with tools and supports to test the service or product during the build and after its launch
  • design a service or product that can accommodate an expected number of users and can scale and support more users if demand increases
  • separate content, design and functionality so updates can be made independently
  • follow the recommended best practices for coding in your chosen technology and tools
  • document how the service or product was built and how it will be maintained, including how this documentation will be kept up-to-date
  • have a process for:
    • testing updates or changes made to the service or product regularly
    • monitoring the service or product even when changes are not being made
    • handling failures, for example bugs and outages, and one for notifying users

7. Make it accessible and inclusive

Accessible and inclusive digital design is good for everyone. Make sure the service or product is accessible to all users regardless of their abilities, device, environment or quality of access.

The Accessibility for Ontarians with Disabilities Act defines an accessible government website as one that meets all the World Wide Web Consortium’s Web Content Accessibility Guidelines (WCAG) 2.0 level AA success criteria.

Why it matters

All users, including users with disabilities or people who need help accessing digital tools, should be able to complete their task quickly and easily the first time.

It is also important to look at how factors such as race, gender, cognitive or physical abilities or socio-economic circumstances impact a user’s experience. Use an anti-discriminatory approach and inclusive design best practices to help ensure that users can access the service or product.

When users find it difficult to complete their task the first time, they struggle unnecessarily and may contact the organization for help, impacting the success and satisfaction rates and increasing costs needed to support users trying to access the service or product.

How to meet this standard

At a minimum:

  • have a plan to ensure the service or product meets the WCAG success criteria
  • make the service or product accessible, including for users with lower levels of digital skills and limited internet access or connectivity
  • integrate automated testing tools into the processes for development and maintenance
  • make sure the service or product is usable by people with disabilities by testing it with them, including by testing it manually, with an automated checker, a screen reader and by zooming in to 400% or using a screen magnifier
  • make it easy for people with disabilities to get alternate formats if they need them, or to contact the service or product team with any problem they encounter in their journey
  • include people with different abilities, including people with different and diverse needs, experiences and backgrounds, using different devices in your user research and testing
  • demonstrate how your team will be equipped with a knowledge of barriers to accessibility and be trained to assist users with disabilities in completing tasks and accessing information
  • make sure that when new technology platforms are considered you find out about any WCAG 2.0 AA compliance issues and efforts to implement the Authoring Tool Accessibility Guidelines 2.0 (ATAG) Part A & B
  • use plain language so services are easier for people to read, understand and use, for example avoid or define legal or technical language and don’t use acronyms

Laws and rules to follow

8. Be agile and user-centred

Design and build the service or product using an agile and user-centred approach. Agile is an approach to building services that breaks the work into smaller chunks known as iterations. Build and test one feature of the service or product at a time and work towards continuous improvement.

Working in agile is a much lower-risk approach than build-and-approve-it-all-at-once, also known as waterfall. Frequent and incremental iterations expose any flaws in the original plan faster, for example that:

  • approvals delayed action
  • resources didn’t meet the needs of the service or product
  • the team experienced barriers that prevented them from addressing user needs

User research methods such as usability testing put the focus on making services and products that are easy to use. A user-centred approach makes sure that user needs and business needs are considered together. This helps to increase digital service or product uptake and success.

Why it matters

Agile methods build services that:

  • meet user needs
  • can be prototyped quickly and tested with users regularly for feedback
  • can change easily if, for example, government policy or technology changes
  • can keep improving based on user feedback and scale if or when demand increases
  • can be built quickly with a minimum set of features and enhanced with more features after the service or product goes live

How to meet this standard

At a minimum:

  • work in an agile way, using agile tools and techniques and continue to do so when the service or product is live
  • make sure the team reviews and iterates on the way problems are fixed
  • be able to give an example of how the team has responded to user research findings
  • demonstrate that the service or product is agile and based on clear and measurable goals
  • explore design options for your prototype and explain why some are discarded
  • demonstrate how the design of the service or product has changed over time because of user research findings or in response to user needs
  • identify any problems found in research and solutions to improve the service or product
  • have a quality assurance testing and rollback plan that supports frequent iterations
  • use a phased approach to test changes to parts of the service or product when feature-based changes are not feasible

9. Use open standards and common platforms

Use open standards, open source software and common government platforms where available.

Open standards are created through collaboration and consensus by an active community of experts, including many large technology companies. The community aims for data operability between various products and services. These practices also consider security, reliability and removing blockers to data sharing within an organization.

Open source software is published publicly and is freely available for anyone to use. It is developed and maintained using a collaborative approach between users, organizations and large companies.

There are many well-established open source tools and products that are considered industry standard.

Why it matters

Using open standards and common government platforms will help the government:

  • save time and money by reusing things that are already available
  • move between different technologies when needed
  • quickly and easily change a service or product when needed
  • give people a more consistent experience using government services or products online
  • access a wider range of both open source and proprietary software vendors
  • eliminate restrictive long-term contracts

How to meet this standard

At a minimum:

  • identify and use open standards and common platforms
  • favour open tools that are accessible and have strong developer community support
  • understand common user needs with other services and meet those needs consistently with the rest of government
  • demonstrate what the service or product provides to users and in what format or formats
  • use common government platforms, for example Ontario.ca for web content
  • use APIs and integrate them with any legacy systems where possible or necessary

Laws and rules to follow

10. Embed privacy and security by design

Identify the data the service or product will use, store or create. Put appropriate legal, privacy and security measures in place so that users feel confident that their personal information will be kept secure and their privacy will be respected.

Why it matters

Users expect government services to:

  • be secure
  • be confidential
  • allow users to access their information in the service when they need to
  • make sure the privacy and security of users protected while they use a service or product and afterwards

How to meet this standard

In the early stages of development, explain:

  • what data is being collected, for example name, address and postal code
  • how the data is being transmitted
  • where and how the data is being stored
  • how the data will be used
  • security threats, including potential pathways for hackers, and tested ways of reducing them
  • how you plan to keep up-to-date on threats and how to deal with them
  • any threats of fraud that exist and the controls being prototyped

Also describe your:

  • approach to security and risk management
  • security and privacy threats
  • interactions with business and information risk teams, for example security and privacy reviews or Information, Privacy and Archives
  • privacy and security regulations and how those will be met without putting delivery at risk
  • any outstanding legal concerns, such as data protection or data sharing
  • privacy policy and terms of use and rationale
  • process for security updates for servers and software
  • plan and process for applying security updates
  • plan to monitor and address suspicious activity

When the service is live, describe:

  • the approach to security and risk management
  • ongoing interactions with the business and information risk teams for example, Corporate Security and Information, Privacy and Archives
  • any outstanding legal concerns, such as data protection or data sharing
  • the process for understanding new or ongoing threats and how those changed during beta
  • how the privacy policy and terms of use will stay up-to-date

Laws and rules to follow

11. Support those who need it

Put tools in place across all channels to support people who cannot use digital services or products on their own.

Assisted digital support means providing support to those who can’t use digital services or products on their own. This may include options to help people navigate an online experience, such as offering support for those who need it through another channel, for example by phone or in person.

Why it matters

Not everyone will have the same access, comfort and skill level to use digital services or products. Understand how and where users require support and make that support available and easy to find.

How to meet this standard

Do user research as early as possible to:

  • understand users’ digital skill, confidence and access levels
  • find out why some users can’t use the digital service or product independently, for example due to language, literacy, or access to internet barriers
  • find out more about specific user needs for support

At a minimum:

  • make it easy to get assistance either by phone or alternate technology
  • make sure assisted digital support is:
    • sustainable and free to use
    • well understood and documented
    • supported by appropriate recruitment and research methods
    • selected and explained through user needs and personas of the people who need it
  • conduct research and testing with users who:
    • already use or would use the service or product
    • have the lowest level of digital skills, confidence and access
    • currently seek assisted digital support from others, for example, friends and family, colleagues, companies or charities
  • respond to user research by:
    • learning from it and supporting continued testing to improve assisted digital support
    • designing an assisted digital support model to meet user needs
    • committing to participate in ongoing user research to discover digital support needs

Laws, rules and guidelines to follow

12. Measure performance

Understand the metrics you will need to capture. Monitor performance data continuously to inform ongoing service or product improvements.

Why it matters

Measuring performance helps a team continuously improve a service by:

  • learning its strengths and weaknesses
  • using data to support changes

How to meet this standard

At a minimum:

  • understand how each channel meets different users’ needs
  • describe the data collected on other channels and how usage data is collected for each
  • use web analytics to capture information about user behaviour online
  • determine data needs, sources and collection
  • monitor and evaluate user feedback and complaints, including from other service touch-points such as in person or by phone, surveys or social media
  • analyze performance and identify actionable data insights as early as possible
  • use qualitative and quantitative data to understand user needs and identify areas for change
  • define performance metrics for the service or product early in the design process
  • regularly review the technology used and the processes that support the service or product
  • base your service or product review frequency on the volume of users
  • use data to determine the cost per use for each channel and account for the cost to build and sustain ongoing maintenance and supports
  • demonstrate how the service or product performance compares to other similar government and private sector ones
  • share your review findings with leadership

13. Be a good data steward

Follow the rules and best practices when you organize and manage data, including making data open by default.

Why it matters

In Ontario data is open by default. Delivery teams must be fully transparent about their data assets and the ways they are acquired and used. We also recognize that people own their personal data and have a stake in how it is used.

This is important because it allows data to be available to everyone equally, creating opportunities for the development of better government services, including across government.

How to meet this standard

At a minimum:

  • collect data once and reuse it where possible
  • make sure data is used in ways that respect privacy, security and cultural awareness
  • understand and follow the Ontario Digital and Data Directive and how it applies to the digital service or product your team is developing
  • use clear and plain language to tell users what data is being collected and used and let them know if or when it will be published
  • engage users and make sure they understand how and why data is collected and shared
  • make sure the data collected is stored properly, using proper record keeping principles and make sure your team has a plan for data recovery in case of data loss
  • strive to improve the quality of the data as a public asset in accordance with its value and user needs
  • find ways to collect and share data across ministries or areas of government to reduce the burden for users and improve their overall experience

Laws and rules to follow

Next steps

Continue to apply the standard as needed when you:

  • update services or products
  • incorporate user testing and feedback
  • scale or implement backlog items

Contributing to the standard

We test the Digital Service Standard to gather user feedback and improve it.

Share your feedback, thoughts and ideas or volunteer for future testing by email at digital.standard@ontario.ca or by forking our GitHub repository

If you email us:

  • send plain text formats like text files, Word documents and Google docs
  • do not send HTML, PDF, printed paper or handwritten notes
  • tell us what section your suggestions are for and include the original and proposed changes to text if you are sending a text file
  • use track changes or suggest mode if you are sending Word or Google documents
  • include the reasons for your suggestions and the benefits you expect for users or ministries