The 2026 Guide
Index

User research

User research means learning what the people who will use a service actually need, by studying and testing with them, instead of guessing. The Government of Canada puts this first among its digital standards: research with users to understand their needs, and test with them to guide what gets built. A service built on what a few people assume users want is the most common way services fail. The decisions about who to learn from and what to find out are made early and repeated as the service changes.

What good looks like

  • Real users are studied before the design is set, so the service solves a need they actually have.

  • The service is tested with real people throughout, including before launch and as it changes.

  • The people researched reflect who actually uses the service, including people who use assistive technology and people who face barriers of language, literacy, or distance.

  • Findings are shared with the team and turned into prioritized work.

  • Research runs across the whole life: discovery, build, testing, and after launch.

  • After launch, client feedback and analytics keep showing what to improve.

  • A "stop" is a valid result: if research shows the service is not needed, that counts as success.

  • Research is planned and funded, with consent, privacy, and fair compensation for participants.

Why it matters

Most government software that fails, fails because it was built on what a few people assumed users wanted, rather than on what users need. Research is the cheapest way to avoid building the wrong thing, which is why it is framed as risk reduction for the people who fund and own services. It is also required: the Design with users standard sets the expectation, and the Directive on Service and Digital makes the designated official responsible for ensuring client feedback and user-experience testing are collected and used to improve the service. The usual causes of failure are ordinary: guessing at needs, testing too late, and hearing only from stakeholders.

Whose job it is

User research is shared across the team, with each role holding a different part:

  • User researchers and service designers plan and run the research and turn it into findings the team can act on.
  • Designers and content authors turn those findings into the design and plain-language content.
  • Developers build what is tested and iterate on what the research finds.
  • The business owner of the application makes sure research is planned, funded, and acted on, and accepts a "stop" as a valid result.

A closer look

Comparison

Two ways to do user research

Pax

Meet Pax, a program officer. They researched the grant portal with the people who would use it:

  • interviewed real applicants in discovery to learn what they actually needed
  • tested prototypes with about five users each round, including someone using a screen reader, and fixed what they found
  • shared findings with the team and kept a feedback channel open after launch

The result: applicants could complete a claim on their own, calls dropped, and changes were small because the big problems were caught early.

What User research looks like in each phase

The research changes shape across the life of a service.

The most valuable research happens before much is built. The team works out who the users are, interviews and observes them to find the real need, and tests early prototypes with a handful of people each round. This is also where a "stop" can be the right answer: if the research shows the service is not needed, that is a result worth having before money is spent. The Design with users guidance walks through the Discover and Build stages.

The official instruments behind user research

Everything official this subject brings with it, and where in a service's life each one comes up. The full detail, including who does the work and what the business owner personally does, is in the table on the home page.

  • Identity and credential assurance levelsOnly ifAssessment

    Two ratings, from one to four, of how sure the service has to be about who someone is, and how strong the sign-in has to be. They are set from the harm that would result from getting it wrong, and they decide what the sign-in has to do, so they constrain the design from the beginning.

    • DiscoveryCheck
    • AlphaGatherFill
    • GrowthKeep current

Further reading

For how to actually do it, Ontario's User Research Guide and Service Design Playbook are reusable Canadian references on what to plan, fund, and expect. To see federal research in practice, Canada.ca's research summaries show how the Government of Canada tested real services and what it changed as a result. For the basics of learning about users and their needs, the UK Service Manual walks through writing and validating needs, and the Interaction Design Foundation's plain-English primer on user research is a good first read if the discipline is new to you.

See also

Assumptions this page makes

You are already working to the Government of Canada Digital Standards, design with users, iterate and improve frequently, work in the open, use open standards, address security and privacy, build in accessibility, empower staff, be good data stewards, design ethical services, and collaborate widely, and to the law on privacy, security, official languages, and accessibility. The standards say how the government works in the digital world. The six Government of Canada digital competencies say what every public servant has to be able to do to work that way, and the team page covers them. This guide builds on those.