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.

This next installment in our Design Philosophy is going to sound a little counter-intuitive. At Newton, we think that the people who use our software the most aren’t necessarily the people that are critical to its success. Our “Critical User” is the person that uses Newton intermittently, every now and then, once a day, once a week, or maybe even less.

Up to this point, companies have designed business software almost entirely for what we might call a “Power User”, i.e. people that are going to use it day in and day out. If you have ever trained a new hire on one of your company’s programs, you may have noticed this before. Your new co-worker is impressed, perhaps even amazed, at your vast software knowledge because you are able to navigate complexity with relative ease.

For a business process like recruiting where 90% of the users don’t hire all of the time and therefore don’t use recruiting software day in and day out, this design focus leads to 10% user adoption. Casual users don’t have the time or usage frequencies that foster retention of complex features.

This is why at Newton we put a great deal of emphasis on casual users. In fact, we build our application in direct contradiction to the software design zeitgeist: our software design starts with casual users, and then trickles up to power users.

Our goal has always been that when a client deploys Newton to their team the person buying the software is proud of their decision because everyone likes it. We want their co-workers to say, “Wow, this is really simple and easy. Thanks for making my day better.” We think this happens with Newton because we care a great deal about all of the people using the software, not just the power users.

And this leads us to the next installment of our Design Philosophy…enjoy.

Ignore power users when designing features.
I.E. Keep it simple.

Keep in mind that software applications aren’t bicycles. You don’t learn them once and remember them forever.

One axis of the learning curve is time. The majority of the people using Newton to hire have other job responsibilities and don’t have time to learn our software, and they’ll forget a lot of what they’ve learned between logins. They are going to get an opening, use Newton for a few weeks, fill the job and then not use Newton until they are hiring again. Here’s what the learning curve might look like for our users:

A crude rendition of how we remember things.

So be very careful when you design a feature or a page. If someone other than a power user is going to need to use it, it better be really simple. Simply put, features for non-power users must almost always be one click and done. Every page should have an obvious intention. If something requires training or explanation people will become frustrated and won’t use it. As below:

Avoid the "Ugh" zone.

How to Test Your Designs
Always test your design by mocking it up, and then afterward ask someone that knows absolutely nothing about Newton to take a look at it. Your only question should be, “What do you need to do here?” If the answer is predicated by “Hmmm…,” you should probably go back to the drawing board. If your page or your feature can stand by itself without explanation, you’ve done a good job and have avoided the Ugh zone.

In summary,

If you need to explain how something works, it probably won’t.