I really like this next axiom in our Design Philosophy for a couple of reasons: as a user it’s really a quite common annoyance in software of all kinds, across all industries; and, we have first-hand experience learning this lesson the hard way.

While this tenet has been in our style guide for quite some time, it was only recently promoted to “Philosophy” status. I promoted it when we almost broke this rule a second time. While I was talking with one of the other Product Managers, we both had one of those “oh duh” moments when we realized we were about to screw up on something big and repeat a past mistake.

So, here we go. In summary, this part of our Design Philosophy recommends that you take great care in naming page elements. Exciting stuff. Cheers.

Be really (really) careful how you name things. And, NEVER use the same word to describe two different things.

Sloppy naming can lead to minor frustrations, or it can lead to some really big problems for your users. The road to sloppy naming is paved by the careless use of synonyms or by naming two different things with the same word or phrase.

First of all, let’s look at synonyms (the more obvious of the two naming blunders). When considering a naming framework for your software, it’s important to remember that your name choices actually constitute a set of instructions to the user whether you, or they, actively realize it or not. Put a different way, what you name something is an implied instruction.

Synonyms are especially painful in Navigation. For example, don’t name one of your navigation elements “Reports” and the other “Metrics”. While it is entirely possible that they serve completely different functions in your software, their names mean pretty much the same thing to a lot of people. As a result you’re going to confuse the heck out of your users.

Since this is so important yet easy to avoid, I’d like to illustrate this point with a few real-world examples from two existing software applications. There’s a certain (very popular) sales software application that has one tab for “Leads” and another for “Opportunities”. What’s the difference between a lead and an opportunity to a salesperson? If I call you up and say I want to demo Newton, which tab would you click in your sales application? Another more baffling example I saw the other day was in a competing recruiting software application: it has a tab for Jobs, and another for Requisitions. What’s the difference between a Job and a Requisition? Should you have to ask?

Having used this very popular sales application for quite some time, we were keen to avoid the synonym booby-trap. But we’ve fallen victim to the siren song of its sister: inadvertently naming two different things with the same word or phrase. Be careful, because you can easily do this on accident, and it will completely screw things up for you.

We learned this particular lesson the hard way. A while back we had a User Type, “Hiring Manager”. Jobs also had Hiring Managers too. A Hiring Manager User and a Hiring Manager assigned to a job had nothing in common (confused yet?). This seemingly minor oversight meant that I had to explain user rights over and over again: “if you are a Hiring Manager user then you can be a Hiring Manager on a job, but not all Hiring Manager Users will be Hiring Managers on jobs” (I should add that one of our Design Principles also states that if you need to explain something it’s probably poorly designed). Once I smartened-up and removed the dual-naming from Newton the problem solved itself immediately, no training required.

While we’ll probably all agree that synonyms help make our language more colorful and interesting, and that word-efficiency can shorten/simplify content at times, nothing is more important to a user than clarity.

Respect the word.