Naming services is an important part of digital transformation. Service names need to be clear, concise and related to the task people are completing. But this can become harder when the situation becomes more complex.
This can include:
-
complex landscapes, where you are naming a service sitting within a wider technical platform, or where services sit within other services
-
services with multiple user groups with vastly differing needs
-
multi-transactional services
It’s important to make sure that the stakeholders you’re working with understand what goes into naming a service, and why it’s important to use the language that people are using.
In this post I’ll share some of our approaches to naming services in complex situations and how we use ‘naming workshops’ to support teams.
Starting with best practice
There’s lots of useful guidance in the GOV.UK service manual for naming services, including things like:
-
using a verb to show the action being taken in the service
-
researching what people are searching for
-
understanding how users perceive the task they’re completing
Using the service manual as a starting point, teams can use research findings and examples from other services, as well as those learned across government and other sectors about searchability.
Services hosted on GOV.UK are a little more straightforward, but carefully considering other services similar to yours is important. In bigger departments where multiple similar services are hosted this is particularly important, as you don’t want your service getting lost or confused with something else.
If your service is not sitting on GOV.UK, understanding the context of the website your service will live within helps build a picture. Consider the site people need to visit to access your service, what else is there, and where your service will best fit within that existing context.
Adjusting to the environment you’re in
What’s harder to find is examples of service names that don’t quite match up to best practice – where the reality of a situation might, and often is, very different.
In more complex situations, the best approach is to work closely with your team and to work in the open. Use the knowledge you have of the environment to decide which activities will be useful. This means thinking about:
-
the level of design maturity
-
complexity of stakeholder hierarchy
-
who has power and influence
-
who you have in your team
-
which stakeholders need bringing onboard
-
how much you can influence in your position
-
technical complexity that will influence things
There may be a pre-conceived idea of what something will be called. It’s important to identify any internal terms being used and weave these into your research early so you can show these insights when you come to name your service. Having research insights to back up why you want to move away from any internal language being used will give you a starting point to show the direction you think the name needs to go in.
Introducing naming workshops
One of the most powerful ways I’ve helped navigate service naming is through a workshop format. We’ve run this a number of times with teams in different government departments dealing with more complex service naming.
The need to convene people around a workshop format recognises that it can be difficult to work with stakeholders who don’t have experience of naming best practice or the importance of your service name.
A typical naming workshop plan and activities will include
-
sharing a variety of research and naming examples
-
capturing naming suggestions, dot voting potential names to discuss
-
discussing any suggested names, including those that don’t follow usual conventions
-
reaching a consensus on next steps
It’s helpful to set rules around your activities to keep things on track. This could include any language you know your users don’t respond well to and having a car park for things to discuss at a separate time.
1. Share a variety of insight
Start by presenting a variety of information in your workshop. Use research insights which include:
-
user language and terms your users have said in research sessions
-
any language needs you’ve identified
-
examples of names you’ve tested if you have them, or examples of potential names if not
2. Use examples and explanations
Next, use examples to explain the complexity of naming services, like:
-
examples of any complexity involved, such as if your service has two sets of very different users, technical constraints, or services hosted outside of GOV.UK
-
examples of how we name services using best practice and why
-
examples of names of other similar services and the actions associated with them
-
lists of actions people use your service to complete
-
explanations of why we use actions and verbs vs nouns
3. Agree on your naming conventions
Finally, work towards a consensus on naming and/or next steps by:
-
capturing, voting, and considering a range of naming options
-
planning further research needed
-
defining what happens next and who needs to be involved, for example, developers to add the name to the service, policy, comms and wider engagement
Demonstrating the value of good service naming
You can show the value of carefully considering how to name your service by thinking about this early, and adapting research activities appropriately, such as asking about search terms and asking people to describe the action they have completed.
Starting with best practice and adapting to context and complexity allows you to consider everything you need to when choosing a service name.
An engaging naming workshop is a way of making sure that everyone has the same level of knowledge of what’s involved in this task, and the importance of it. Getting important stakeholders involved and as close as possible to this work will set you up for success.
