https://hodigital.blog.gov.uk/2016/12/21/creating-a-common-language-to-describe-services/

Creating a common language to describe services

When we build teams to work on services, the individuals may have never worked together before, and may have different ways of describing their work.

When we try to get to a common understanding of a service and its constituent parts – or what they could be in future – the words we use matter.

It takes time to understand what everyone means when they say ‘service’, ‘product’, ‘user need’, ‘platform’, ‘channel’, ‘architecture’, ‘policy’, ‘data’ and ‘strategy’, for example, as we all have our own definitions.

We’ve looked at ways to understand services and create a list of terms (our taxonomy) so we can communicate more simply and clearly across the Home Office.

A list of terms including: services, sub-services, technology, date and user neeeds
Some of the terms we all use, but need to be more consistent with

The raw materials of a service

Services

A service helps users to do something. It also helps government achieve policy intent on behalf of its citizens with whom it has a social contract. Services are best identified as verbs (visit the UK), rather than nouns (biometric residence permit).

Examples in the Home Office include coming to the UK, hiring people who need permission to work or getting a travel or identity token e.g. a passport

Sub-services

Often the things we work on are just one step in a bigger process. We’ve called these sub-services, and examples include:

  • applying for a visa
  • applying for a licence
  • granting or refusing permission
  • revoking someone’s permission

Capabilities

A capability is having all resources required to carry out a task – such as skilled staff and specialist tools – and also considers capacity and maturity.

Appointment booking, for example, is a capability that requires:

  • an appointment booking system, which may be a technical capability
  • physical locations or phone support to host the appointments
  • a process for changing or cancelling appointments
  • skilled people to host appointments

The Australian government’s Digital Transformation Agency has a useful capabilities guide, which is used to measure the maturity of delivery teams.

Activities

Activities are the things people do in relation to using a service, including:

  • finding out how something works
  • calling people for help
  • applying for something
  • gathering evidence
  • waiting and worrying about what might happen
  • being notified about a result
  • calling to find out what’s happening

We’ve also used the term to describe the things that need to happen to make a service work:

  • checking eligibility
  • checking suitability
  • making a decision
  • notifying someone about a decision
  • revoking permission

Activities should describe what happens, but not how it happens, by whom or with what. So, we’d use ‘notifying someone’ rather than ‘sending a letter’ and ‘making a decision’ rather than ‘casework’.

That gives us freedom to think about how the service could be re-imagined to work in a simpler, faster way, or with entire sections removed.

Technology

We’ve used ‘technology’ to mean the digital systems, products, tools, hardware and applications we build, maintain and buy. Technology exists to support activities and capabilities – and enables us to deliver faster, clearer, simpler services.

Technology includes:

  • applications
  • products
  • platforms
  • legacy systems
  • hardware
  • data

Data

By data we mean the actual information that’s either generated by or used to carry out activities and services. We try to describe what the data actually is using descriptive words, such as ‘National Insurance number’, and avoid acronyms.

What does a taxonomy do?

Our goal is to create a common language to help us – the Digital, Data and Technology organisation – and the wider department work better together. The value is not so much in what the actual words are, but the fact that we made this together as a multi-disciplinary group, and that we all agree to try it out.

This will enable us to have better discussions, spot commonalities, think about design patterns and organise large portfolios of work more easily. It also provides a language to communicate how things could work differently in future.

If you find these definitions useful, or have different ways of understanding services, we’d love to hear about it in the comments below.

For more on service design, follow Kate Tarling on Twitter. The sketches were made by service designer, Ayesha Moarif.

3 comments

  1. Comment by Peter Jordan posted on

    Really like this, but have two comments:
    1. Find the 'capability' example a bit confusing, ie the appointment elements seem to be outputs that require different capabilities.
    2. Re data - we've been thinking about making the distinction between the data that is collected from the service and the (meta)data that is generated by call centres (type of call) or digital analytics (browser, user journey) etc.

    Reply
    • Replies to Peter Jordan>

      Comment by Kate Tarling posted on

      Hi Peter,
      This is a fair challenge. Changing 'appointment management' for 'appointment booking', of which a booking system is perhaps a technical capability. And interesting to hear about your data categories, especially for live services. I'd also think about measurement in relation to policy intent, desired outcomes, value and other measures e.g. how well we're meeting user needs.
      Thanks for posting.

      Reply
      • Replies to Kate Tarling>

        Comment by Peter Jordan posted on

        Hi Kate, re the latter - absolutely. The performance analysts in GDS have been trialling 'performance framework' workshops to help teams think about these issues and have to get the data and measure....

        Would love to talk in the New Year.

        Reply

Leave a comment

We only ask for your email address so we know you're a real person