names like ‘Fee Remission’, we are designing them for use by experts, something that worked well when services were provided by trained expert humans, but means that they don’t work unassisted on the internet.
Instead we often find that other professionals willingly offer support to our users – at a cost. This happened with Fee Remissions, as it so often does with many of the more obtuse services, from insurance buying to visa applications – when several third-party providers offered their services in helping users apply for what should have been a free service.
In the past, we used advertising to ‘educate users’ in our nouns, forcing the kind of brand familiarity that came naturally to well-used objects like Sellotape, Hoovers or Biros. But unless you’re confident that you will get the kind of market ubiquity that comes from being a household name (and this happens to fewer companies than you’d think), your service is likely to be one of the thousands a user will use infrequently or once in their lives.
Equally, if you’re a household name that has more than one service, this tactic is out. Your users still need to be able to sift through the many things you do to find the one thing that they need, and they aren’t going to be able to do that if you’ve got a jumble sale of nouns to wade through.
Naming your service
Rather than using the words your organisation uses to describe the tasks it has completed, try to find out some of the words your user would use to describe what they’re trying to achieve. What names work for users will depend on two things:
1What your user wants to achieve
2How knowledgeable they are about what services might be available to help them achieve their end goal
For example, someone moving house might not think that the service ‘move house’ exists, based on their previous experiences, but instead might think to look for ‘removal companies’ or ‘estate agents’.
In areas where a service is less ubiquitous than moving house – for example, registering a trademark – a user’s knowledge of what they might be able to get help with might be so low that they may try to find the noun they think most applies to them and hope for the best. This obviously means they may end up using a service that isn’t applicable to them. Your job is to understand how that overall task breaks down into smaller tasks a user identifies as something they need help with.
It might help to think about the name of your service existing somewhere on a spectrum between verb and noun, where the thing users think to look for will inevitably be somewhere in the middle. Most importantly, base your name on a solid understanding of the words your users use.
1Avoid legal or technical language For example, rather than ‘fee remission’ use ‘help with payment’.
2Describe a task, not a technology Avoid words that describe a technology or an approach to technology that your service uses, such as ‘portal’, ‘hub’ ‘e-something’ or ‘i-something’. Your approach to technology is rarely of interest to your user, and words like these only serve to date your service to a particular era of technology.
3Don’t use acronyms Acronyms might make it easier for you to refer to your service, but they are the most impenetrable language for your user to decipher.
When searching for a service, what users look for is somewhere on a spectrum between what your organisation calls your service and what your user needs to do.
Changing what you call your service will change what it does
Most importantly, changing the name of your service might sound like a small thing, but aside from the huge effect on your immediate users, it will have a big effect on what your service does and how it operates in the long term.
Seeing your service as ‘stop paying tax on a vehicle’ instead of ‘SORN’ subtly shifts the purpose of that service closer to what a user understands as its purpose and the language your organisation uses to talk about it.
In summary
1When it comes to finding your service, nothing is more important than its name
2The name should reflect what users are trying to do
3Use words that your users will understand
2
A good service clearly explains its purpose
The purpose of the service must be clear to users at the start of using the service. That means a user with no prior knowledge must understand what the service will do for them and how it will work.
One of the easiest mistakes people make when they’re telling a story is to forget the beginning.
We’ve all been there; we’re sat in a bar with a friend, or watching a colleague give a presentation, and we realise halfway through the story they’re telling that we have no idea what it is they’re talking about. They’ve missed out where they were, who they were with or a vital fact that the whole story hinges on.
It’s an easy mistake to make, often because the audience we’re talking to is familiar, and we presume a piece of prior knowledge from them that they don’t have. The more familiar the audience, the more likely we are to forget.
The same goes for services. Sometimes we think our service is so familiar or ubiquitous that we forget to explain the most essential part of our service – what the service does.
The UK Driver and Vehicle Licensing Agency (DVLA) has experienced this problem with its ‘report a medical condition’ service. It’s hugely important that people who are driving on the roads around us are fit to do so, but we will all experience some form of medical issue at some point in our lives that may affect our ability to operate a vehicle. When this happens, the DVLA monitors your situation and allows you to return to driving if and when you’re fit to do so.
Most reports are made by people who report a medical condition that does need to be reported – things that affect your driving like having epilepsy or a stroke. However there’s a minority – and quite a sizable minority (close to 40% in fact) – who report medical issues that, if treated, don’t need to be reported at all. Things like ingrown toenails, broken bones and even miscarriages are reported by users who’d rather be safe than sorry when it comes to being on the right side of the law and their insurer.
The problem wasn’t just that users didn’t know which medical conditions to report, the problem was bigger than that. They didn’t understand why they were reporting those conditions in the first place. If they had known that they were supposed to be reporting issues that affected their vision, attention or motor skills to check if they could still drive safely, then it’s highly unlikely so many ingrown toenails would have been reported!
Not knowing the purpose of the service led users who didn’t need to use the service to use it anyway, meaning that thousands of declarations in the system led to delays in reviewing the cases of users who did need to have their condition monitored.
Realising this, the service design teams at DVLA set about identifying the conditions that were the most misreported and created