Why names matter
We talk a lot about access and inclusion in public services, but we do not always consider the role of our service names. The name you give your service could be the difference between making things clear for users or leaving them lost or confused.
A government service needs a name that:
- helps users identify and find the service
- uses users' language
- feels familiar to existing users of the service
- makes sense to those with no prior knowledge or experience
- works for all user journeys
- can be used on guidance pages, touchpoints and even URLs
- meets the government design principles
When to rename your service
There are many reasons why you may be considering renaming your service. Perhaps your research has shown you that people do not relate the existing name to the task at hand or use it naturally, perhaps they do not even really understand it. Maybe your data or usability testing suggests that some users are struggling, or failing, to find the service at all.
Equally, there are many reasons why services have ineffective names, but often they are based upon the internal jargon that was used when the idea of the service was first floated.
Sometimes, a bad service name has become so familiar to its users that it may actually be detrimental to change it.
Six steps to renaming an existing service
We recently looked into renaming our two related services: claim reimbursement of import duties, VAT and other customs charges and claim repayment or remission of charges on rejected imports.
The names were not plain English and they were quite a mouthful. The words ‘reimbursement’ and ‘remission’ tested poorly with users as they were:
- not associated with the task at hand
- unfamiliar
So, we took the following six steps.
- learning from the naming experts
- learning from existing users
- considering the wider user base
- testing potential names
- taking a step back
- ongoing testing and monitoring
1. Learning from the naming experts
This Service Manual guidance was a great starting point as it sets out the design principles behind a good service name, as well as giving tips on how to test a service name before and after go-live.
2. Learning from existing users: how do people currently find the service?
In collaboration with the performance analyst, we looked at data from Google Analytics and Splunk and this gave us a good idea of what users were searching for before they reached the GOV.UK guidance and start pages. However, these insights were biassed as they only showed the searches that successfully reached the relevant pages. If you’d failed to reach the page, you were not counted. We could not therefore take these searches as representative of all potential users and needed to conduct further analysis.
3. Considering the wider user base: searching online
We used Wordstream search engine analysis and Google’s ‘people also ask’ feature to see the search terms used by all those attempting to reach the service, regardless of whether they were successful or not.
We analysed the Wordstream data to come up with the most commonly used verbs and nouns. These findings were very different from the Google Analytics and Splunk data suggesting that some would-be users were not reaching the relevant GOV.UK pages. We also reflected both Google’s suggested search terms and those used by novice users testing the end-to-end journey in our user research. This gave us confidence that we were on the right track.
4. Testing potential names: where would you click?
Taking into account the insights from data analysis, qualitative research and government design principles, we created a shortlist of service names to test. We mocked up four different variants of a Google search results page which was then used in a first click test with the following scenario:
You think you have paid too much tax on some goods you ordered from abroad. You search for what to do. Please click on the link that you would think would be most helpful in this situation.
We were very careful not to use any of the potential names in the scenario to avoid biassing the results. 271 HM Revenue & Customs (HMRC) users participated in the first click test. Users were selected from those working in relevant fields and those with no experience to ensure the chosen name would be accessible to all.
5. Taking a step back
Once we had the results from the first click test, we took a step back. We needed to consider how the top performing names met our service needs. Our chosen name had to:
- have performed well in all our research to date
- be plain English and make sense even if you know nothing about the service
- use the words users use – is this how users would describe the task?
- work for all our different user groups and user journeys or service variants
- be unambiguous, it should not be open to interpretation or risk misleading
- describe a task, not a technology
- be future proof - no need to change when policy or technology changes
- be a verb, not a noun
- avoid government department or agency names or acronyms
It is better to have a name that makes sense to users than one that exactly describes the HMRC processes. We opted for ‘claim back import duty and VAT’. One of the services that will come under this umbrella was originally called ‘claim repayment or remission of charges on rejected imports’. Claim back is not exactly synonymous with remission but it makes sense to users.
We decided not to use the popular word ‘refund’ in the service name as it could be misleading. However, we will use it in the meta description and guidance, where relevant, to help with findability.
6. Ongoing testing and monitoring
This work isn’t over. We’ll keep testing the new name through usability testing and data analysis. For example, when the new guidance and start pages are in public beta, how are users reaching them? Have the metrics changed since the name change? Is there close alignment between what people are searching for on search engines, internally on GOV.UK and how they are reaching the pages?
How else could you find the right name for your service?
The six steps above worked well for our service but may not be right for yours. Here are some other methodologies you might like to consider.
- Open or closed tree testing, or card sorting. This is particularly helpful where a service has multiple sub-tasks or functions. For example, an open card sort could help you understand how users would naturally group tasks and what they would call each group in their own words, while a closed one could help you understand what functionality or tasks users would associate with a particular name.
- Task based testing to evaluate how a user would explain the service in their own words based on a basic diagram or description of the service. Think very carefully about how you describe it so that you are not putting your ideas for a name into the user's mind.
- A short questionnaire to inform opinions and discover potential or preferred names.
- An expert review of names of other related services - it makes sense to go with something familiar if you have evidence that it works well for users.
Who can help you?
Like everything else in user-centred design, this should be a team effort. Include your:
- service designer
- content designer
- performance analyst
- interaction designer
- wider service team
- and most importantly, your users!
If you have any other suggestions for renaming an existing service (or naming a new one) please let us know in the comments below!
Further reading:
Good services are verbs, bad services are nouns
How to name a service
1 comment
Comment by shimu posted on
Clear, user-centered approach. Vital for gov't to prioritize accessibility & clarity.