Skip to main content

What we’re doing to make the Service Manual community-led

A laptop screen showing a web page on contacting the Service Manual and Service Standard team

Previously, we wrote about taking a community-led approach to the Service Standard and Service Manual. Since then, we have spoken to service teams, conducted research, run workshops, updated guidance, and recently become part of a new organisation – the Central Digital and Data Office (CDDO). This blog post gives an overview of what we have done in the past 6 months, why we did it and what’s next.

Since completing our rediscovery in late autumn, we’ve not stopped learning about our users, their needs and their pain points. To do that most effectively, we reviewed the different ways users can give us feedback and improved our processes for responding to that feedback. We’ve also analysed thousands of feedback comments, matched them to existing knowledge and created a prioritised backlog of things to fix or investigate further.

Learning from established community-led models

We received feedback about shaping our contribution and governance model after the GOV.UK Design System’s. We took a close look, asked the Design System team lots of questions, and discussed what could work and what might not.

Then, we branched out and studied how other community-oriented online platforms like Wikipedia, Quora, and the navigation app Waze handle contributions. We wanted to know the following things:

  • who can contribute, and what motivates contribution
  • what the process looks like and what the barriers to contribution are
  • how these platforms build trust in the published content
  • how they show differing opinions, make changes and updates  
  • who decides that they are accurate and acceptable

From our desk research, we learned we should focus on topic-centred structured conversations, timeboxed periods for contribution on specific topics, and varied ways for people to contribute to suit differences in capacity, working styles and personalities.

In our analysis and subsequent reflection on community models, it became clear that we do not interact with one single community. We need to work with at least as many as there are topics in the Service Manual. Each community organises itself differently—some communities are not yet formally established. This means we need to interact with them differently which increases the complexity of our work.

To add further complexity, the Service Standard and Manual serve multiple user groups. These are not mutually exclusive. Instead, one person can wear multiple hats and interact with the standard and manual in different ways on a single day. 

It serves people who:

  • make decisions about services
  • design and deliver services
  • assure services against the standard
  • advise and support service teams
  • contribute to guidance

Working with community members to inform guidance

Over the past few months, we’ve used a range of ways to understand service teams’ realities in more detail and learn from their experiences. During Services Week in mid-March, we ran a workshop/show and tell-hybrid to understand how teams designed services in a crisis. We used virtual boards to capture how teams delivered quality at an extreme pace, how they were reusing things, and what principles and ways of working they followed.

In the same week, we wanted to hear from teams how the Service Standard can be applied to internal services. Again, we used virtual boards to understand what cross-government colleagues are working on, what challenges they face, and what points of the Service Standard are most difficult to follow.

Since then, we’ve gone back to workshop participants and other subject matter experts. We shared first guidance drafts with them, prepared and published related blog posts that extend and support the guidance in the making.

As our colleague Alison described in her blog post about how we’ve used user research to inform guidance, we used a different approach to update the guidance on data you must publish when the Performance Platform was retired. We worked with subject matter experts first and then asked service teams to take a look at various versions of guidance drafts, before sharing a refined version on the cross-government Slack and eventually publishing it. 

Additionally, we’ve updated, corrected, and clarified dozens of guidance pages. Among many other things, we’ve fixed broken links, reflected policy changes, and updated community pages. For example, we corrected how 26 pieces of guidance referred to disabled people, bringing them in line with government inclusive language guidance

Formulating a communities-centred vision, strategy, roadmap 

Based on the many inputs and interactions we had with our users and other stakeholders, we had an away day to agree on a common vision for our team:

We work with government to create the Service Standard and Service Manual. This helps organisations design and build safe, secure public services that work better for users, and waste less time and money for government.

To deliver against that vision, we:

  • learn from people building services to understand their challenges, needs and ways of working
  • co-create Service Manual guidance with service teams, communities and subject matter experts to gather and share good practice
  • take a community approach by facilitating ways for people to contribute to the Service Manual and Standard
  • proactively keep the Service Standard and Manual user-centred, up to date, accurate and relevant, and ensure they’re reflective of the developing ambition of government
  • improve the Service Standard and Manual’s usability, accessibility and navigability
  • work closely with the GOV.UK Design System, GOV.UK, Technology Code of Practice, Spend Controls and Assurance teams to ensure our guidance is consistent and accurate

Quarterly, we collectively define our team’s roadmap. For the latest iteration, we considered 3 lenses to prioritise work: work derived from user-centred problem statements, ongoing work, and work linked to organisational priorities.

Those led to the following deliverables for the coming months:

  • establish and communicate the community-contribution model
  • create and update content to make it more accurate and meet user needs
  • improve the user experience of the Service Manual

While these deliverables allow some flexibility to what work we pick up, they describe our priorities to senior management and fellow teams working in service assurance and assurance support. We’ve presented our roadmap in internal show and tells and made it available on the intranet for everyone to see and scrutinise.

Removing barriers to guidance and engagement

On a weekly basis, our team reports its progress through internal weeknotes which are also shared on the cross-government #servicemanual Slack channel every Friday. It increases accountability as it allows anyone in government interested in our work to see what we are doing and ask us questions about it. 

Learning from our users’ feedback, we’ve made it easier to get in touch with our team through various channels by creating a contact page. It’s linked from our beta banner which is visible on every single page in the Service Manual. We also started testing a new ‘Help improve this guidance’ section at the end of select highly-frequented pieces of guidance.

Diagram of multiple page flows related to providing feedback to the Service Manual team
A diagram of how Service Manual users can provide feedback on guidance – including a complicated as-is on the left and much-simplified to-be state on the right which has been largely implemented

Recognising that various pieces of guidance in the Service Manual were last updated years ago, we took a closer look at the impact of that on users. User research has shown that readers trust guidance less if it has an old ‘last updated’ date. However, the guidance has generally not been updated because it is still accurate. And having this date at the top of Service Manual pages can distract users from useful guidance.

So we decided to remove the ‘last updated’ date from below guidance page titles. We still have the date at the bottom of every page, but it’s no longer one of the first things the user sees. We’re also looking at other options, like updating the ‘last updated’ date when a page is reviewed or has minor updates. And, we’re working to find ways for service communities to get involved in reviewing guidance to identify content that needs to be updated. 

What’s next

A few weeks ago, we became part of a new organisation inside the Cabinet Office: the Central Digital and Data Office (CDDO). In a recent talk, our leaders spoke about the importance of improving end-user experiences with government and building further capability in the Civil Service. The Service Standard and Service Manual will play a key role in achieving these objectives.

As outlined in the roadmap that we mentioned above, we are formalising and documenting our community-led approach while working on various pieces of guidance. Join the #servicemanual channel on Slack to hear from us weekly and get in touch with us on any Service Manual-related matter.

Sharing and comments

Share this page


  1. Comment by john mortimer posted on

    Great article describing your approach.
    I have been designing government services since 2006, and I see that I have lots of experience from what went right and learning from what went wrong. I am still working to link gov service design to the reality of transforming services.
    I have a question. How can someone like myself, have the ability to input into this? As I work with different local authorities, I do not have a consistent email?

    • Replies to john mortimer>

      Comment by Martin Jordan – Head of Service Design, CDDO posted on

      Thanks for your comment and interest, John! We have created a little list of people who like to contribute. Happy to add you to it. What are the topic areas you’d like to contribute to? And are you on the local government Slack channel by any chance?

      • Replies to Martin Jordan – Head of Service Design, CDDO>

        Comment by john mortimer posted on

        Thanks for replying. I am not on the slack channel, as when I requested it, I was rejected because of my lack of a permanent email

        My specialism is designing services using systems thinking based approaches. Person centred design. Creating multi-functional hubs, and the role of information and Digital in local gov services.
        Integrating other specialisms into service design. Systemic leadership development, and multi-functional based team working.
        Complex based service design specifically in community health and social care, Childrens services, and people based services in general.
        The development of warm data, and how to communicate complex knowledge in end to end service delivery.
        My focus is on true transformation rather than piece-meal design.
        I only come across policy and central gov when it impacts the local gov service, and in two cases it has altered national policy.

  2. Comment by James Cattell posted on

    "...waste less time and money for government" is an interesting choice of words.

    Who exactly is wasting the time and money, please?

    • Replies to James Cattell>

      Comment by Martin Jordan – Head of Service Design, CDDO posted on

      We could have talked about effective and efficient use of public money, but we use plain language wherever we can. GDS has been talking about saving money for almost a decade. As you know, government has worked on service platforms, components, patterns and guidance that help to save time and money, but they continue to need improvement and could be adopted more widely.

  3. Comment by James Cattell posted on

    Really good blog post 🙂 I've wanted a community led approach to updating the service manula for ages. Will be watching this with intestest.