Skip to main content

Service manual discovery findings

Posted by: , Posted on: - Categories: Service manual

The team analysing research

The service manual team is reassessing who the users of the service design manual are and what they need from it. We spent 4 weeks in discovery and this post will cover what we found.

A little bit of background

The manual was published in April 2013 and continues to play an important part in providing guidance for teams creating government services. But two years on we wanted to understand what users’ needs are now and how we can meet those needs better. What we found in discovery will help us to build on that work and create a truly cross-governmental body of knowledge to help services meet the Digital Service Standard.

What we did

We analysed all the existing sources of data and qualitative feedback we could find. The whole team went out and spoke to lots of people across government, visiting 7 locations over 3 weeks. Patricia (user researcher on the team) will be writing more about that over on the user research blog soon.

What we found; the 6 themes

1. Finding things is hard

“There used to be this thing… maybe it’s gone?”

The strongest theme that emerged during the discovery research was users struggling to find what they needed in the manual. So we made finding things a key part of our focus for alpha. To help us do this, we have an information architect working as part of our team.

We want to make sure we develop a structure that allows users to find what they need, whilst also having a sense of what the section or the whole manual contains.

2. It is an introduction

“When I first started it was a great introduction. Its value becomes less over time.”

We found that people use the manual most when they first join their team (and sometimes even before that, when preparing an application or for an interview). For many, the usefulness of the manual decreased over time.

We want to understand more about what users need once they are in their role and if the manual has more of a part to play here.

3. Flexible, or not?

“The manual should explain where guidance is set in stone and where there is flexibility.”

Users of the manual were often not sure whether the information contained within it was something they needed to do to meet the Digital Service Standard, or was more open to interpretation.

The manual must make this clearer. Testing ideas about how we might meet this need better is another focus for our alpha research.

4. Evidence and examples

“I need to understand the rationale for GDS’s interpretation.”

People wanted more evidence about why something was recommended or required to meet the standard. We heard that examples helped to make the guidance more practical and relatable.

We plan to research this further and test how we can best structure and provide this type of information. We’ll also test structures that will allow us to include the best examples from across government to ensure we are sharing knowledge and learning from each other and not duplicating our efforts.

5. Trust

“Keep the manual up to date or it rapidly becomes counter productive.”

Some people weren’t sure how up to date the content was and wanted to know what had changed and when. Very few mentioned or saw the links to the GitHub history at the bottom of each page.

We need to think about how to show when content was last updated and how it has changed over time. We also need to make sure the structures are in place to continue to update and curate the best guidance from across government. We’ll also test how the discussion and feedback that takes place on wikis, like the design patterns hackpad, feeds into this evolution of the guidance.

6. Persuasion or education

“We used it to support our argument for open source.”

We heard that people had used the manual to help explain the way they worked to people outside their team. The service team in these examples weren’t the primary users of this content, they might send a link to someone or put a link in a document as supporting information.

From this, it became clear that the users of the manual are not only service teams, but people who work with and support service teams and we need to make sure these users are represented in our research recruitment plans.

What’s next?

We’ve been prototyping and testing out ideas over the last few months. We’ll blog more about what we’ve found out soon.

In the meantime if you have any questions or would like to be involved in our research (we always love more volunteers), please do get in touch.

Sharing and comments

Share this page