From build first to users first

At the Canadian Digital Service (CDS), we are excited to be working with government departments to build better services. We are also keen to share lessons we learn from these experiences to hopefully help folks with their own work.

We’re certainly not the first to do this. There are a lot of great resources out there (we’ve included some below). Taking inspiration from digital agencies who have come before us, we hope to add to this collection by sharing approaches that we’ve adopted when working in the unique space of Canadian government service delivery.

As always, we will start small and iterate often, beginning with the question we get asked most often: “Where the heck do we start?”

Simply put, a good place to begin is understanding a couple foundational pieces like, what is service design and user-centred design, how do they differ from what’s been done in the past, and what do they look like in action?

So let’s dip our toe in there.

From build first…

Governments have typically approached designing a service in linear stages based on the requirements of the organization.

When one stage of a project ends, the next stage builds on top of that work until the project is done and only then is the product launched for everybody to use. If you’ve noticed the service isn’t meeting the needs of the public after it’s fully built, it can be costly and complicated to fix.

…To users first

A different way is emerging where services are designed with the people who use them (the ‘users’) from the very beginning.

Methods like ‘service design’ and ‘user-centred design’ embrace this new approach. In a government context, this means improving all parts of a government service, even the hidden stuff that the public won’t ever see.

This is done first by talking to users to find out their needs, then testing ideas early and often with them. As new feedback comes up, improvements are continuously applied (known as ‘iteration’).

The details

Discovery: uncover user needs

Looking deeper into the problem, who the users are, and what they need

• Starting to plan a new service if the existing one isn’t meeting user needs and no other products available can do so
• Mapping the priority data, design, and technology capabilities that the new service should have (the ‘minimum viable product’) to meet the user needs
• It’s okay to run another discovery phase, or stop after Discovery if your findings show that’s the best thing to do

Alpha: test assumptions

Starting to design, build, and test the minimum viable product

• Exploring and experimenting in small ways, with the emphasis on testing ideas rather than building the solution
• Building and testing simple versions (‘prototypes’) of the minimum viable product in quick iterations with a small group of users to get feedback on what works and what doesn’t
• Considering accessibility, different device requirements, and a consistent English and French experience for all users when testing

It’s okay to run another alpha phase, or stop after Alpha if the product is not meeting user needs.

Beta: limited public release with regular improvements

Taking what was learned during Alpha and building a working service

• Continually testing and improving this product with a larger group of users in a controlled public environment
• Looking at analytics to see if the service is solving the original problem
• Refining the product and how it runs until confident that it can work on a large scale for all user groups

It’s okay to run another beta phase if the product is not meeting user needs. It’s also okay to stop after Beta, though less likely if you have proved the need for the product in earlier phases.

Live: full release

Putting the service out in the public domain, being used in real situations

• Remembering that just because a service is public, does not mean it is done: Live is an ongoing phase

At this point for CDS, we take a step back and the partner department maintains the service after Live. The partner continues to monitor analytics, test, and release new features as user needs change.

Other resources:

apolitical - The Digital Government Atlas
Government of Canada - Digital Playbook (Draft)
Ontario Digital Service - Service Design Playbook
Web Content Accessibility Guidelines (WCAG)

The resources will continue to grow. In the meantime, we want to hear from you. If you have feedback, or want to learn more about a particular topic, let us know!