Working closely with external clients, every now and then you run into one that's especially creative. They'll come up with very specific names for certain features they came up with, that don't align with what they really are.

In fact, these names might require an explanation to become clear.

So does this help in making people remember said functionality/features? Will it help stand out? Or will it make it harder for users to find what they are looking for?

There must be some research out there about stickiness of "named features". If anyone could shed any light at all, or perhaps even link to some research that talks about this, that would be greatly appreciated.

  • 1
    In terms of statistics such users are outliers. Any additional efforts needed for name clearance are the evidence for improvements are needed. User testing could be the best research, especially tree testing for evaluating the findability. Commented Nov 29, 2013 at 7:35
  • In talking about site designs I've resorted to creating a diagram with labels of the areas of the site layout to go in reports and on the wall: for example this site (SE:UX) might have a 'top blue bar' and a 'top black bar' - and some made up labels for some of those standard bits right down at the bottom of the page...
    – PhillipW
    Commented Nov 29, 2013 at 16:56

4 Answers 4


You should always use the word which is common among the users, no matter if it is the technically correct one or not.

In Why the electronic land registry failed, Lauesen gave a very vivid example of this. This is a story of a large system which had to be made mandatory for use in real estate purchases in the whole of Denmark. The requirements were gathered from a few experts, among them an old judge specializing in real estate law. This judge made a very big point of using the proper legal terms for everything. As the requirements engineers had no access to real users and no political power to overthrow the judge's wishes, they put these terms into the specification.

In the post mortem, the author identifies this as one of the large problems with the project. The users of the system - who were real estate agents, not lawyers - had absolutely no idea what these terms are. They were completely confused and could not even start working with the system. In the end, the whole project flopped.

This was not the only usability sin committed in this project. The paper accompanying the conference talk is a worthy read (and probably explains it better - I don't even remember it well enough to be sure I got all details right), if it is not available without a paywall, the author may give you a personal copy on request.

But in general, this is a good lesson. If one of your users pushes for a non-intuitive word to be used in the interface, where other users will be confused, don't give in. If it is a system where all users will use this one word, even if technically wrong, use it. They really need their own language there.

Citation for the paper: Lauesen, Soren. "Why the electronic land registry failed." Requirements Engineering: Foundation for Software Quality. Springer Berlin Heidelberg, 2012. 1-15.

Here is an excerpt describing the situation above:

How do you register a condominium deed? There were several options in the menu: Single-family housing, cooperative apartment, farm – but no condominiums.

The professionals were stuck and called the e-LR hotline. It was busy, so they might wait for an hour and then try the next day at a different time. It might take three weeks to succeed. Once they got through, there was an immediate reply: Select single-family housing – it includes condominiums. Since hotline had got this question frequently, one might wonder why developers didn't change the menu. The reason was that the judge in charge of the entire project refused: the law was clear and the term single-family housing covered also condominiums.

Amazingly, the Land Registry was not aware that the essential waiting time was three weeks. To his staff, it looked as nobody waited for more than an hour.


Jacob Nielsen recommends straightforward naming conventions over "clever" ones.

Don't use clever phrases and marketing lingo that make people work too hard to figure out what you're saying. For example, the "Dream, Plan, & Go" category on Travelocity might sound catchy to a marketing person, but it's not as straightforward as "Vacation Planning." Every time you make users ponder the meaning behind vague and cutesy phrases, you risk alienating or losing them altogether. Users quickly lose patience when they must click on a link just to figure out what it means. This isn't to say that homepage text should be bland, but it must be informative and should be unambiguous.

Source: http://www.nngroup.com/articles/113-design-guidelines-homepage-usability/

If the user had to use a search on your site to find a specific feature, what word might they use?

This applies to the real world, too. For years, McDonald's offered a Grilled Chicken Sandwich and a Crispy Chicken Sandwich on their menu. They've since replaced both items with the McBistro Sandwich. If you had never heard of this item before and didn't have pictures to help you, how would you know what it was?


In the battle of branding vs. usability, I tend to err on the side of usability. That said, I take a holistic approach.

If most things are 'predictable' then a change of pace can draw attention and be memorable. However, most times when I encounter this it is the result of an overly creative approach to projects--as if the designer is a creative genius solving this problem for the very first time...Really?

Anyway, as far as web goes, I like to use interactive tours like those facilitated by jQuery Joyride to help make sense of features that worry me.

  • 1
    +1 — Amazon Prime is a good example, I think. It's one of the few branded features on their site, so once you learn what it is, you remember it. If everything was brand specific though, it would be overwhelming, but on it's own it helps to draw attention to this feature. Commented Dec 5, 2013 at 18:53

If it's really important for the client to have unique names, these names should still be usable, meaning that the users should still understand what they mean. So this specific requirement of the feature having a unique name should mean that additional time should be spent on usability testing to make sure that the name is understood by the users. It should not mean that it's ok that the users don't understand what the name means

Summary: have unique names. Make sure users understand them

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.