Creating usable applications – ten do’s and don’ts

If I had a penny for every person who said “usability is just common sense”, I’d have a pretty reasonable stack of pennies – maybe 30 or so. Clearly I’m not going to be able to retire on this, but at least it demonstrates that many people have misconceptions about how usable interfaces are designed.

It would make my life a lot easier if building a usable interface really was just a matter of applying “common sense”. Sadly, there is more to it than that. It requires a deep understanding of human behaviour. We humans are complicated creatures that interpret the world around us – sometimes consistently, sometimes inconsistently, we develop habits, have emotions and can usually be relied upon to do things we’re not expected to do. All of this makes common sense somewhat inappropriate as a design approach.

This article is a brief introduction of how you can ensure a degree of usability in your applications. It’s not a fixed rule book and reading this article isn’t going to bestow upon you some bountiful abundance of usability knowledge. Similarly, I can’t give you a one sentence rule or catchy slogan that you can regurgitate to convince people of your usability prowess.

But if you’ve got five minutes, and a receptacle filled with a beverage of your choice, this article might give you a rough sense of what usability is all about in a few easy to digest do’s and don’ts. Let’s start with the do’s.

Do take time to understand the problem you’re trying to solve

In all the years I’ve been working in usability, the most common problems I’ve encountered have not been in the details of poorly implemented user interfaces, but in the fundamental design of the application itself.

If you don’t make the effort to understand what a user is really trying to achieve, then you’ll end up adding needless functionality or convoluted interactions. The result will be an application that doesn’t do what the user really wanted and doesn’t integrate with their workflow. As a result, it will fall short of their expectations.

Spend time with your users; shadow them as they go about their tasks. It’s only when you can see them work in their environment, see what they are trying to achieve and experience their frustrations that you’ll understand what your product really needs to do.

Do offer sufficient affordance

Once you’ve got a great idea of what your product needs to do, and know the critical paths through your application, your next concern has to be with affordance.

Affordance is just a fancy name for making sure your application gives you clues about what everything is, both at a macro and micro level. If you can’t understand quickly what each section of your application is for and how you interact with it, then it’s failed an affordance test. If the phone rings while you’re using an application, or someone asks you a question that stops you mid flow, it must be abundantly clear, when your attention returns, where you are and what you were doing. Cryptically named menu items and buttons, or mysterious icons, all fall into the poor affordance category – you’re obfuscating functionality.

Do ensure you’re consistent

Humans are creatures of habit. We’re comfortable when we have routines and we learn quickest when we’re building upon our current knowledge. Deviating from a routine is at best disorientating and at worst likely to result in accidents and mistakes.

Imagine that you swapped the brake and accelerator pedals on your car. You know about this and you’ve even had a practice session in your back yard. Regardless, when you’re out on the open road, those years of habituation will kick in, and when that llama runs out in front of your car, it’s guaranteed that you’ll hit the accelerator and send the daft animal prematurely into llama heaven. Far from ideal.

In applications, this is similarly true. Swap a Cancel and OK button around in a few locations and you’ll find that your user will click the wrong one, or slow down unnecessarily. If you have similar functionality across your application, but different ways to interact with it, you’re upping the learning curve and increasing the risk of errors.

Sometimes though, choosing not to be consistent can result in a better interface. For example, you might have a consistent way to bring up a set of features in your application. But one of these features is sufficiently unusual to warrant a different access route. Knowing when it’s better to break from being consistent is tricky and judgement calls will have to be made, but generally speaking, consistency will improve usability.

Do provide adequate feedback

Another great human trait is the expectation of simple cause and effect. When we interact with something, we expect to see some kind of effect. This relationship is so deeply ingrained in our psyche that we even assume connections between unrelated events if they happen to occur close together. For example, I might execute a command and see nothing happen, so decide to move onto another task. Just as I perform that second task, I see the result of my first command, but now I’m convinced my second task caused it.

What bearing does this have on interface design? Well, it means that there should be immediate feedback for pretty much every user-initiated input. If there isn’t, a whole heap of uncertainties and misinterpretations will ensue, and with them come furrowed brows and computer/monitor/mouse/keyboard related abuses.

Feedback also relates to returning relevant and desired status information. Don’t hide the key information in a bunch of other unwanted bumf, and make sure that information is in an appropriate format – if it needs to be acted upon. For example, if my only indication that everything is running smoothly is hidden in a nasty block of text, it takes time to digest this and filter out the less pertinent information.

Progress indicators need to predict the wait involved as accurately as possible and, ideally, shouldn’t be modal. Clever application design might allow the user to be getting on with other things whilst they wait for a certain event to finish.

Do allow for increased expertise

If you’re designing an application for a technical audience it’s tempting to think that these experts will be able to work it out no matter how complicated it is. This is a dangerous assumption.

The expertise of your user base will follow a bell shaped curve. Everyone will start as a novice. They’ll quickly become beginners if you’ve done a reasonable job with the UI. Beyond that, most users spend their time as intermediaries. They know as much as they need to know in order to do their job, but rarely have the time or inclination to put in that extra effort to become an expert. Even if they do, they may become an expert in only one area and will remain a complete novice in another area of the application.

So, a good application design allows users to quickly gain a degree of competence and start being productive. Nobody wants to be a novice for long, and forcing more experienced users through a route designed for a novice, can be frustrating and insulting. For this reason, I recommend that you use wizards only for rarely used tasks where more support is needed, and not for operations that are frequently performed.

It also follows that it’s a good idea to provide shortcuts and other time saving features. These may be optional routes through your application, but they ensure that as your user learns more, they don’t find your application insults their newfound skill.

On a similar note, you may find that your application as a whole is rarely used, and as such a user who may once have been an intermediary, reverts to being a novice or beginner. You should find out the likely usage level of your application and use it to inform the level of support that a user will need to be productive with your tool.

Don’t assume you know what the user wants

This assumption can get you into a lot of trouble, and it’s one of those traps that is very easy to fall into. I’ve been in countless meetings where a bunch of people are all trying to decide what the user wants. More often than not, there’s a difference of opinion and a lot of time can be wasted.

It may not be appropriate for every situation, but it’s often cheaper and quicker to go back to your user base and get the answers from them. This doesn’t mean that your users are designing the application, but that you are extracting from them the information you need in order to make an informed decision.

Taking key decisions without first testing the water with your users is a sure-fire way of ensuring that your application fails to meet your users’ needs.

Don’t assume the user has time to puzzle out your application

It’s a widely held belief that usability is just about dumbing down your application so that stupid people can use it. But wait a second – you’re a user and you’re not stupid are you? There has to be some other reason why an intelligent person might struggle with your application – and there is. Whilst you may know every square pixel of your application, real users are busy and they don’t know and love your application in the same way you do. To them, it’s just another application that they have to use and they’re quite happy to cuss, curse and give up on it before they fathom out the arcane way you chose to implement something.

This is why your application has to present its information in the least complex way possible. For Red Gate, this is especially true, since we only sell our tools online. If a user can’t get results within a few minutes of downloading it, they quickly conclude that the tool doesn’t do what they need or that it’s not worth the effort to find out if it can. A good positive first experience is vital and this means good affordance and clearly signposted routes through the application.

Don’t inflict errors on users

The best kind of error is one that never occurs. This is kind of obvious and it’s also not rocket science to expect that the underlying code should be robust enough to prevent application crashes or other unexpected events.

The easy option is to wait till your user does something unexpected and then throw up an error dialog box. However, every error you inflict on a user is like a slap around the face with a wet haddock – and many of these fish slaps are simply unnecessary. There are a great many times in the UI where you can decide whether an error state is reached or what should happen given a certain set of user actions. If you’re clever about the way you present the interaction, you can “design out” any chance that the user can make the mistake in the first place.

For example, you can disable confirmation buttons until the required input has been made. Similarly, you can define fixed choices instead of freeform input and you can offer the format you want the user to provide. These are just a few examples, but with careful design, you can usually prevent most trivial errors from occurring.

Where errors are unavoidable, you can at least mitigate their negative effect by being helpful and polite. Whilst this is often seen as obvious, and even jokingly sidelined during development, an error message is more than just a polite notification that something has gone awry. Firstly, an error message is only the start and is pretty unhelpful if you don’t also offer a resolution. Sure, you could just explain what the error might be, but why shouldn’t you put the user immediately back to where they can actually influence the error? This is why modal error dialogs are quite so painful – you have to clear them down and then go hunting for the resolution, during which time you’re relying on short term memory to remember what the message was. It’s far kinder to present the error at the exact spot where the user can immediately correct it without having to remember anything.

Don’t rely on icons

I once worked at a company where one of the manufacturing plants independently designed one of the most baffling user interfaces I’d ever encountered. They made a product that had a worldwide market and, cunningly, they decided that in order to save on the costs of having to translate their UI into various different languages, they’d make a UI that consisted entirely of icons. Now there are uses for icons, but if you ever wanted to encrypt a user interface so that it was unusable, having it completely icon-driven is likely to be the most successful.

The problem is that one person’s interpretation of an icon is not always the same as another’s – and that’s assuming that they can make it out at all. So whilst this user interface could proudly claim to not need translating, it could also not so proudly claim to be unfathomable by all but the designers of the UI.

This is an extreme case, but it’s worth noting that icons can often disguise the functionality of your application. Tool tips are just a bandage on something that is already broken as you’ve already slowed down the interaction. This type of design has been termed “mystery meat navigation”, meaning that don’t know what something is, unless you try it.

There may be a few icons out there that have transcended the recognition barrier (new, open, save and print) but even some of these, presented out of context, can still be misinterpreted. It’s taken years for these icons to be widely recognised and even so, their physical position within the interface is a major factor in why you would recognise them. So why have icons at all? Icons can help to make an interface look more approachable, and when accompanying a text label, they can improve performance. In this situation, they act as a visual signpost that draws your attention to the text label. Together, they confirm you’ve found the function you need.. Relying on an abundance of icons without labels is a sure-fire way to slow down the user and increase frustration.

Don’t skip usability testing

If you only do one thing as a result of reading this article, I hope that usability testing is it. As a starting point, and as something to build into your development process, usability testing is probably the best “bang for buck” strategy. Buy a book or two or research how to do it online, grab some users and test your application.

You don’t need to herd all your users into fancy labs with one-way mirrors in order to learn valuable insights about how your application is used. You’ll spot most (if not all) of the major problems just by working with a small handful of users (5-7 is ideal, as you’ll get diminishing returns working with more).

There is nothing more enlightening than getting a fresh pair of eyes staring at your application. They will show you more problems in 5 minutes than you and your colleagues will find in 5 hours. It’ll challenge your assumptions about what your users do with the product and you’ll learn where the biggest stumbling blocks are.

Usability testing can be carried out at many stages of the development process, starting from paper prototypes of your initial ideas, right up to final acceptance testing. You should carry it out frequently and quickly iterate your designs to accommodate any changes you make as a result.

And if you’re looking at the perfect way to break the ice with the development team, try running usability sessions on one of your competitor’s applications. Your team will be far more open to acknowledging usability criticism themselves if they’ve first sunk their teeth into the problems of a competitor’s product.

Conclusion

Creating usable applications is not easy. Changing your development process to pay more than lip service to usability is also not easy. Getting support from within your company for usability to be taken seriously can take time and usually has to be demonstrated through positive results.

However, the rewards are worth the effort. As technology evolves, and companies find their market niche becoming crowded with competitors, usability becomes an important differentiator. With all other things being equal, would you rather use the product that probably could get the job done, but baffles you from the moment you fire it up, or the one that is pleasant to use and actually does help you get the job done?

Technology is meant to enable us and free our time of boring, dangerous or complicated activities. Somewhere along the way, we seem to have forgotten this and, slowly but surely, technology, far from saving us, has made the whole situation more complicated. By paying careful attention to how we interact with our world, you can develop more natural feeling tools that work with our human oddities, rather than against them. That’s the role of usability and that’s why it’s important to build it into your application design before you even write a single line of code.