When we talk about service design in government, the conversation is focused on creating amazing citizen-facing services. This is true to our core purpose - we work to serve citizens and therefore need to create services that put citizens at their core.
But what about the things that go on behind the curtain? The outward-facing services that public servants deliver to Canadians rely on the internal services that enable the delivery of their missions, yet we don’t often associate them with great service design or user experience.
How can we expect public servants to effectively serve Canadians if they cannot easily get access to the things they need to do their jobs?
If you’re trying to do things in government, there are really only two ways to get it done: hire someone or pay someone to do it (i.e. buy the service). Unfortunately, those of us in internal services like HR and Procurement typically break one of the fundamental principles of good service design. We tend to build services that meet our internal needs, rather than the needs of those that are using our services.
That means we put more emphasis on the rules and policies in place and forget that there are people who use this service who not only aren’t aware of the policies we’re bound to, but don’t particularly want to have to learn them to get their job done. And to be frank, they shouldn’t have to. Ironically, in our pursuit to ensure rules are followed, we end up designing processes that are so complicated that users either don’t follow them out of frustration, or give up trying.
It’s important that we’re able to strike that balance of ensuring we comply with our obligations, while making it as easy as possible to do the business of government.
There’s a fundamental need for growing service design within government and applying the same user-centric lens to our internal services as we do to our citizen facing ones .
At Public Services and Procurement Canada (PSPC), we serve Canadians by serving government. That’s why when we started our work to modernize government procurement, we knew it was critical that we develop and hire design researchers and service designers to make buying in, and selling to government better.
Finding service design talent willing to work on internal services was tough, but we now have a great team of service designers and user researchers supporting Procurement Modernization, and we’re hoping to grow that team further. We trained existing employees, recruited talent from within government and are pulling in external talent through TalentCloud - the Government of Canada’s experimental new hiring platform for project-based or “gig” employment.
Our initial efforts to build a modern service experience for buying in government have been humbling.
We started by doing user research with what we call “the buying community,” talking to the administrative professionals who do the day-to-day buying for their offices. We asked them to tell us about how they actually buy and to share their experience with the processes that are currently in place.
What was really critical was that these folks were shocked that we were even talking to them. One individual told us “This is the first time that anyone’s asked me about what I do.” Our team gained so much empathy through his process and it really helped us do the work with heart. Talking to real users really helps a team build empathy.
We also learned about how important language really is. In internal services, we have our own lexicon and it’s easy to assume that our clients speak the same language. Most of the time, they don’t.
We considered what our buying community did as procurement, but they didn’t. You don’t procure a pen, you buy a pen. The word procurement was not one they used to describe their work.
This had some interesting implications. For example, if departmental procurement guidelines or policies are written and titled “Procurement Guide,” they may not think it would apply to them. Likewise, through our supplier research, we’ve found that while suppliers typically will look for a “Request for Proposal”, we’ve been calling opportunities to do business with government “Notices of Intended Procurement.” This showed the dissonance between the language we were using versus what the people looking to engage with us were expecting to see.
Taking a service design lens to the business of procurement has been both a touch challenge and eye-opening experience. Throughout our journey, we’ve learned some key lessons that we’d like to share:
- Build a budget for service design into your project/program to ensure it’s at the forefront and not an afterthought.
- Service designers and researchers are in hot demand, so recruiting talent will take a while. Give yourself time to bring together the right team and leverage platforms like TalentCloud to engage external talent.
- Build internal capacity by sending your team members on training. Modern public servants need to understand the fundamentals of user research and design.
- Be relentless in ensuring your team talks to the people that will use the service. Resist the convenience of designing in isolation.
- Make good service design the responsibility of the entire project team, not just the designers.
- Sometimes you need to get creative and do the best you can within the constraints you have. Capacity, schedules, and budgets may not always allow for the textbook approach.
- Advocate the work that your team does and share it widely across all mediums possible.
I’m encouraged to see the beginnings of a focused effort to apply service design to the business of government. For us, we’re excited to start delivering on our work to make buying better, show the results of our service design efforts, and prove that yes, even internal services like procurement can be a delightful experience.
Want to know more about how CDS hires researchers? You can find job posting for Design Researchers and Quantitative Design Researchers on the CDS Talent Handbook. Additionally, feel free to reach out to CDS’s Talent team at CDSRecruitment.RecrutementSNC@tbs-sct.gc.ca for more details.