Naming Teams and Services
I work as a content designer on services for the Department for Work and Pensions. As well as creating content for services, it’s part of my job to help teams communicate well. Melanie Cannon has blogged about this in Helping teams define their focus, which includes naming your service.
Something I haven’t heard much about is how to name your team, and how to name internal services.
Naming your team
As a general rule, team names should just be the same as the service name. In government we only use descriptive names for our services. This means all your colleagues know what the team is doing, and they don’t have to remember random team names. It makes things simple. The world-beating wonders in the photo were the Jamaican Women’s 100m Relay Team. Easy peasy.
The main exception is when a project is in discovery and the service hasn’t been defined. Whilst in discovery the team shouldn’t have a name which leads to or leans towards a solution. If you’ve come up with a mission statement and a problem statement, that might help you to come up with a team name that’s not solution-based.
A random team name can be useful if you can’t come up with a name that isn’t tainted by anticipated solutions.
It’s really important that random team names are inclusive.
If there’s an in-joke or a reference that you may or may not get, it’s not inclusive. As an example, Star Wars characters, football teams and soap stars aren’t inclusive. Colours, oceans and continents are. It might not be as much fun, but neither is feeling like an oddball because you have no idea who or what Hodor is, or the Sugababes are. Nobody likes a clique.
As soon as the project is out of discovery and you know what the service is, the team should take on the service name (if it hasn’t already).
Naming your service
The Government Service Standard has really clear guidelines on how to name your service.
Good service names:
- use the words users use
- are based on analytics and user research
- describe a task, not a technology
- don’t need to change when policy or technology changes
- are verbs, not nouns
- don’t include government department or agency names
- aren’t brand-driven or focused on marketing
These guidelines are evidenced and used across government.
Without a clear, descriptive name users won’t find the service, and services without an intuitive name won’t pass a government service assessment. So far so simple.
Internal services
Problems sometimes arise when naming internal services as they don’t have a service assessment and they are usually presented to their users — their users don’t have to find them.
I’ve witnessed various representations made as to why a particular internal service should sway from the guidelines. These vary from the users being used to a name (or an acronym), or that a verb just doesn’t make sense for a staff system. It’s true that the user doesn’t have to find the service from Google, but they still need to know what it is and what it does. A descriptive name is the easiest way to do that.
As you can’t rely on Google analytics to tell you what the name should be from search terms, it’s important to do user research with your internal users. The important thing being that they understand what it is and what it does — not whether they like the name.
If it’s hard to name something using the government guidelines that might mean that the thing isn’t really a service, or that it’s meeting a bunch of different needs in one place. Or worst case scenario — it’s not meeting any needs.
If your organisation is committed to user centred design these guidelines should apply to both internal and external services. Staff systems should be designed around user needs, which should make it relatively simple to name them.
Big services with multiple feature teams
Sometimes a service is too big for one multidisciplinary team, and has to be split down. There’s no reason why the team names and service names shouldn’t still be descriptive and follow the government guidelines.
The big service itself should be fairly easy to name. I’m assuming that the service is understood quite well if it has been deemed too big for one team.
The ‘feature teams’ might be more tricky. Sometimes people want the team to stay the same and have the same name when they move on to build a new feature.
The simplest thing to do is for the team to be named descriptively, after the thing you’re doing. As an example, “Book an appointment for a visa interview” could be a feature team of a full “Apply to come to the United Kingdom” service (I have no idea if this is a real service — sorry Home Office). If the team move on to build something else, the team name can change to reflect that.
