A common language to understand 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 things like ‘service’, ‘product’, ‘user need’, ‘platform’, ‘channel’, ‘architecture’, ‘policy’, ‘data’ and ‘strategy’. We all have our own definitions.

A team in a large government department looked at ways to understand services and create a list of terms (a taxonomy) so that they can communicate more simply and clearly across large organisation.

Different parts of a service. Originally published at https://hodigital.blog.gov.uk/2016/12/21/creating-a-common-language-to-describe-services/  

The raw materials of a service

Services

A service helps users to do something. Public services exist because of underlying citizen needs, policy intent, user needs and the strategy of a particular organisation. Services help 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 for the UK Government include visit the UK, get a passport, learn to drive or register to vote.

Sub-services or stages

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. The aim is to describe what the data actually is using descriptive words, such as ‘National Insurance number’, avoiding acronyms.

Example of using a taxonomy for a service. Originally published at https://hodigital.blog.gov.uk/2016/12/21/creating-a-common-language-to-describe-services/  

What does a taxonomy do?

The goal was to create a common language to help teams and large organisations to work better together. The value is not so much in what the actual words are, but the value in making something like this together, as a multi-disciplinary group, and agreeing to try it out.

A common, agreed language helps teams have better discussions, spot commonalities, think about repeating design patterns and organise large portfolios of work more easily. It also provides a language to communicate how things could work differently in future.

[This post was first published in 2016 on the Home Office Digital, Data and Technology blog]