User experience often defaults to asking how to make life easier for the end user. Geoff Meads explores times where it’s actually preferred to make life more difficult for the end user and why the industry might do that.

If you’ve read one (or more) of my previous columns on user experience (UX), you’ll know I try to be a champion for the user, and that normally means campaigning for things to be made easier for them. From interfaces to support contacts, from pushing aside technical complexity for new levels of usability and delight, my mantra is to reduce friction and ensure what we do as smart home engineers really enriches people’s lives.

But, are there times when adding friction, hiding features, or making things less accessible is the right way to go? Let’s discuss…

When there’s just too much “stuff”

Back in the days when I worked for a manufacturer of AV receivers, the sheer number of functions some products offered was mind-boggling.

Sometimes, even the technical sales team didn’t know what absolutely every button did, especially when the function of a button or command changed depending on the context or current setup. This often meant that factory remote controls were a sea of buttons with little, if any, visual hierarchy.

Add in the need for icons instead of words (for space or multilingual reasons), and you have a remote that was, at best, intimidating and, at worst, unusable.

I recall Sony must have been aware of this, as they once made a rather clever TV remote that had all the buttons on one side and a much smaller set of essential controls on the other. When rounded off with a rigid plastic case that you could fit so that only one side showed, you had a near-perfect solution. Though I’m sure it wasn’t cheap to make.

Sometimes, hiding non-essential functions, only to reveal them when absolutely needed, is certainly a justifiable course of action.

When you need to discourage some users

While some of the control systems we build are completely custom, a lot of the time, budgets just don’t allow for that. In these cases, we often have no choice but to offer a factory default set of commands/controls on touchscreens or remote handsets.

When this is the case, I find there are two types of users. The first will shy away from things they don’t understand for fear of breaking something or ending up on a screen they can’t find a way out of. The second are those whom we might term fiddlers.

With this second set of users, we have a problem. If there is a slider, switch or dropdown on the interface, they assume they can change it (and they do, sometimes just to see what happens). The AV receivers we mentioned earlier are prime cases for this, and it doesn’t take much fiddling by the user to destroy a carefully made calibration.

A once-perfect system can quickly start sounding poor as a result. You can, of course, tell the customer not to touch certain settings, write manuals that back this up, and even leave signs on equipment racks to the same effect. Sadly, though, at least in my experience, these actions rarely put the fiddler off.

When this occurs (or if you suspect it might), I’d make a strong case for password-protecting some important system settings where possible. Getting a fiddler to admit they’ve changed things (and even more so, getting them to pay an invoice for you to go to the site and put things right again) is going to be a hard task.

When you need to completely prevent access

There are some cases where certain types of users absolutely must not be given access to certain systems or content. This has been common for years in corporate IT, where certain data is access-controlled, like payroll and other financial data. However, with the internet bringing a whole new set of access conundrums, we need to have robust plans in place to restrict access (or content) when necessary.

Examples of this type of thing, quite obviously, include preventing minors from seeing adult content. It might also mean restrictions on gambling services (another common one for company IT technicians).

Finally, even though I’m UK-based, I’m aware of legal changes relating to the access of social media for young people in Australia. It’s now a hot topic for debate in the UK too. While much of this access control will be provided at the login level of the service provider themselves, it certainly wouldn’t hurt to have separate access controls at the system level as well.

When you want to delight someone

If you’re a gamer (or know someone who is), then you’ll be aware of something called Easter Eggs in some games, films and TV shows. These are little extras that the user isn’t expecting and are not in the advertising but are nice or fun when you find them.

A rather famous Easter Egg is in the film E.T. (1982) where, when riding in Elliott’s bicycle basket, dressed as a ghost on Halloween, E.T. spots a child in a Yoda costume, points and says “home”.

There are a number of Easter Eggs that smart home engineers might deploy. How about a hidden screen that shows the past ten results of a user’s favourite sports team, or maybe one that turns the interface into the user’s favourite colour, or shows a birthday message on their special day?

Wherever your creative spirit takes you with Easter Eggs, part of the secret to making them effective is to make them hidden, lying in wait for the user to discover at some future time. It’s all part of the fun and can really add latent value to a system.

When there’s a premium service

And for our final situation, we have premium services. There are simply countless examples of this type of thing, support packages being one of them.

If you’re running a support or after-sales service, maybe a monthly package or something similar, it makes sense for your response to be slower, or not as complete, when a customer is paying you less or nothing at all.

Obviously, we need to encourage customers to pay for these services to stay in business; however, the balance of what to provide free and what to charge for is often a tricky one. On the one hand, we want to encourage people to take up the premium service, and it’s therefore tempting to put the most used features in the premium service only, but your lesser services must also prove your worth, enough that customers are motivated to pay you for the premium.

Conclusion

I hope the above examples are useful, and I’m sure you can think of a bunch more.

My final thoughts on this subject are that, yes, there are legitimate situations when it’s right to make something more difficult; however, we must always ensure that the user agrees we have been both fair and justified in our decision-making.