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.
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
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.
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.
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.