Civil servants are user research participants too

Print Friendly, PDF & Email

Carrying out user research across the public sector is not the same as carrying it out with members of the public. That at least has been my experience of carrying out half a dozen different civil service-focused Discoveries.

As the Government Digital Service here in the UK likes to point out, civil servants are users too. But it’s a broad sector and my research projects have included central, devolved and local government, agencies, the police, and the NHS. Here are my experiences in light of the new guidance for services for civil servants.

Planning user research for civil servants

The first thing I do for all projects is meet the team and host a research question workshop. Where this differed from other workshops is how we thought about users.

We quickly decided that ‘civil servant’ was too broad a term for users and looked at the Civil Service profiles and Departmental IT profiles.

We found when reviewing civil servant personas from previous research that some are often just their job titles. So we did two things.

First, we adapted the job titles into roles to reflect that users across different teams may have the same fundamental duties and needs but different titles. This allowed us to see patterns and groups.

Second we wrote our potential users and their stories not just ‘As a…’ But ‘As a…’ ‘+ Who’ (eg” as an assistant who is in charge of a team’s room bookings”).

This helped us to really narrow down who our users were. It also helped us resolve one debate we had about who were end users of a service and who were our chief users for one Discovery, which to our surprise were not the same.

We also had a fairly clear idea about the end users but for the Discovery we determined it was more important to know who would implement and make decisions about the proposed service and their needs.

Cross-government help

What really saved time was posting what I was working on to the cross-government user research Slack channel and mailing list.

While my team had contacts, other user researchers put me in touch with their teams when relevant. In some cases they even had previous user research I could look at — with room bookings, for example, I had 3 different previous projects I could study and borrow form.

As you may be aware, government has a lot of meetings and forums and groups. Going along and inviting myself to relevant meetings helped in multiple ways: I got research from the meetings; I got contacts; and I got people to spread the word about what I was doing.

The tricky bits of civil service research

User research is mostly for getting information from users, but on my projects the civil servants I spoke to expected more from interviews, particularly if a team member was present.

In some interviews it did get bogged down when team members wanted to defend or tell why the problem the user mentioned was, and that’s not the aim of interviews. The decision has to be taken on the value of having a team member be there to take part in research and how to control the research session.

Confidentiality was also a concern. It’s hard to be truly frank as a user if the person who designed the system you’re criticising is in the same room.

One strategy was to allow for time at the end for Q&As between the team and users, and to shut it down if it went too off-topic.

This was even trickier in workshops, yet one reason we could get so many participants to attend was that our team of experts would be there. It was a question of balancing your desire to get information while rewarding the fact that professionals were giving up their time and so expected something in return.

Participants were also keen to know the next steps. Asking product managers to vow to blog at the end of the Discovery, Alpha or Beta meant I could tell users that there’d be a digest of learnings, and I invited many to the final Show and Tell.

What I learnt

We don’t share enough with other user researchers. And a lot of user researchers across government have worked on similar projects with similar problems and needs.

Contacting others can be easier due to Slack, public blogs, meet ups and so on but it requires more chasing and more channels to monitor. Combine this with projects using the same users and there can be a case of research fatigues for participants.

Some blockers were technical and unique to the civil service. GDS doesn’t have .gsi in its email (a ‘government secure initiative’ that’s going anyway in favour of better cyber security behaviour), and lacked a landline. For some not up to speed with the latest policies this was a red flag and was told I “couldn’t be trusted” with a response.

With so many departments and agencies (despite decentralisation) along with local authorities it can be tempting to stay in London and its area to meet users.

Yet bursting the London bubble and travelling the country was essential.

Hangouts, Appear.In and other remote tools are great but opportunities to observe other working areas were essential to get a proper view of work. They were often keen to meet someone who was willing to come see them so it was a positive session for all.

Overall it’s been an enjoyable experience. Civil servants are not just users, they’re people too. Shocking, I know.

Researching in government is rewarding as you have experts in their fields and they love talking about their work. Even those who are unhappy usually end their interviews with “sorry for the rant” despite having given you reams of information.

And you hope that by the end of the project your team will have had insights and findings that will help a range of talented people across the country do a better job and so help the public.

Note: this was originally written for the GDS blog but due to team changes got lost to the aether.