Usability considerations

Usability matters, for all software. Unless you have a reliable way to force users to use your most crappy software, you better make sure that they enjoy it. But it doesn’t have to be a chore, and can actually be a very fun and fulfilling challenge.

For example, contrary to popular belief, usability does not necessarily come at the expense of software power, but can actually enhance it, as usability helps users find out about the functionality that is available, and use it more efficiently through the reduction of error occurences and impact. And usability can improve the efficiency of security systems, by reducing the odds that users will try to get around these in potentially harmful ways, instead of understanding them and making the most of them.

Now, if we want to improve the usability of something as big and general-purpose as an operating system, how do we get around it? Unfortunately, there is no set of Big Rules Set In Stone that will make every software usable in a straightforward way. But, over time, a number of rules of thumb have proven quite effective at making software more pleasant to use, and this blog post will be about discussing these.

Top-level principles: effectiveness, efficiency, and satisfaction

Let us start with some basic software design principles that must be part of any user-oriented software. These may sound like smashing open doors, but bear with me as the history of computer user interface disasters show that they are not obvious.

First of all, software must be effective at its task. It must give people the ability to do what they want with it. Note that this is about what users want, not necessarily developers: the history of software engineering is full of developers trying to solve a very interesting computer problem that no user was concerned about, and conversely, the single most frequently heard complaint about poorly-designed software is that developers must have never actually tried to use it for its intended purpose.

As an illustration of software effectiveness problems, consider the UI redesign that Microsoft Office underwent in its 2007 release. The problem that the Office team at Microsoft tried to solve, is that the Office user interface was so hard to explore that users ended up requesting features that were actually there after failing to find them. In this case, users didn’t manage to solve their problem at all, even if the underlying software should have been able to do it. The Office 2007 interface was thus designed as an attempt to make rarely-used features more discoverable, without compromizing the accessibility of most frequently used features too much.

A second guiding principle is that software should allow one to perform tasks efficiently, that is, in a straightforward and perceivably fast way. This principle is easy to get wrong, so let me clarify that I do not mean here that user interfaces should provide a direct shortcut to every single functionality in their interface, without any form of information hierarchy. That would just be a fast road to user mental breakdown. Rather, efficiency is achieved by making common user actions fast, and giving expert users a way to get around the chosen slowness of less frequently performed tasks (like scripting, record/replay interface automation or keyboard shortcuts).

Finally, software should be satisfying to use. Now, this parameter obviously varies a lot from one user to another, but it is still worth optimizing for, because it’s a core part of building a faithful software audience. The need for user satisfaction is the reason why “ARE YOU SURE YOU REALLY WANT TO QUIT ?” confirmation dialogs must be shot on sight, and why a keyboard response delay of ~50ms, even if it feels extremely short on the face of typical complex computation delays, must be eliminated.

More specific usability guidelines

After going into these broad principles, let’s try to explore a couple of more specific guidelines that can be use to optimize the usability of software, or improve it when it is shown in usability tests to be problematic.

A first concrete step is to spend some thought on information architecture. Cognitive psychology has established in the late 50s that the human brain can only process a very weak amount of information at once, which means user interfaces need to be designed so that users only have to think about a few things at once. This was, historically, the scientific basis for hierarchical menus, which allow users to explore a large number of commands by iteratively drilling down increasingly specific categories, but hierarchies have their own issues as we’ve seen before, so a number of alternate approaches have been tried over the ages. In particular, it’s important to emphasize organization schemes that provide quick access to most frequently used commands and contents.

Related to architecture, but distinct, is the notion of layout. The very same information can feel clear or confusing depending on the way it is presented, especially on visual supports, and in any case, too much information at once is always goint to be a pain for users. One should make sure to minimize the amount of information that is displayed at once (favoring approaches in which information is gradually revealed as needed), and then group together information that belongs together (e.g. an icon and the associated text) and separate information that doesn’t.

A vital point of software usability, but one which is excruciatingly painful to get right in practice, is consistency. Related objects should be always positioned at the same place, labeled in the same way, look similar, and behave at the same way, while conversely, unrelated things should be positioned differently, labeled differently, look different, and behave differently. Not only is this “right cognitive distance” feeling hard to get right the same time, it is even more difficult to keep across software evolutions, but good consistency dramatically reduces the amount of things users have to (re)learn through trial and error before they master software.

These benefits can be further extended by taking into account the things that computer users have learned on other software, aka usability conventions. These days, computer users don’t just from a software knowledge vacuum, they have used many other software, and from it formed a set of expectations about how software should look, speak, and work. This existing knowledge has to be taken into account when building new software, if one does not want to get this characteristic NIH interface feeling where software feels like it was designed by a race of aliens with little experience of humanity. It is also a core reason why standard GUI controls that remain the same across applications are so important.

Next, software should be informative. I’m not talking about providing users with yet another copy of the time of the day, weather forecasts, and top newspaper headlines here, but rather about how software should keep users in touch with what’s going on, what is asked of them and why, and what the software can do for them. Ideally, the information should also be as contextual as possible: when filling a form, for example, it’s better to only explain the current step with a transient legend, positioned next to the form field being field for clarity, than to overload the entire form with one permanent legend for every field. It’s also important not to overdo user feedback: no need to go overboard with full-screen animations and airplane sounds just to let a user know that they’ve sent an e-mail, for example…

A notion related to being informative is being comprehensible. Software is not art, so if most of its user base cannot understand the messages that it is sending, it is a problem that needs fixing. In practice, information clarity is achieved through the use of simple, concise, and conventional wording, that is adapted to the target user, and as explicit as possible. Icons are usually not a very good substitute for words, but rather an aesthetically pleasing complement to them, and they should be picked very carefully by accounting for all the existing usability conventions underlying every symbol that user are likely to be familiar with.

Well-designed software is also helpful. It guides the user around, provides a clear course of action for every foreseen use case, makes it clear how it is used. Conversely, it avoids misleading the user, using ergonomic conventions in the wrong way, and sending the user into traps like data losses. Being helpful also involves avoiding manual user action when it is easy to make the software automatically do the right thing instead.

Now, as software is used by imperfect humans, a sensitive issue that must be accounted properly is that of mistake management. The best way to handle these is to make sure that users make no mistakes, and good user interface design goes through great length to ensure this using such tricks as informative notes, well-picked controls, and careful labeling of any “dangerous” interface element so that users think twice before using it. The next best thing software can do is to automatically correct errors (but that is rarely possible), or make it as easy as possible for users to correct them. If possible, errors should be no big deal, and users should be able to notice them right after making them and correcting them on the fly before forgetting they have even happened, just like we all do when typing on a computer keyboard.

At this point, we start to get software that’s understandable, and the next step is as usual to make it fast. Busy humans hate feeling like they’re wasting their time, so interfaces should account for it with controls that are easy to target, quick access to common-case actions, elimination of unneccessary and repetitive intermediary steps (aka “next, next, next, next, next, install…” workflows). Also, as mentioned above, it’s important to provide “expert” access to frequently used functionality, allowing users who feel like it to use it even more efficiently, including through keyboard shortcuts, CLI operation, or scripting.

Another design mantra to keep in mind it that users must stay in control. It is not acceptable to build software that bypasses standard system functionality without a very good reason (e.g. cannot be easily closed), abuses mouse hovering action as an interaction primitive instead of waiting for users to click, makes it hard to cancel actions, forces users to watch passively through long animations (video games are VERY guilty of that one), involves very long wizards for simple things, does nontrivial things in the user’s back without asking, and overall invades user privacy a bit too much. Software is just a guest on someone’s computer, and must behave accordingly.

Software should also strive to be accessible to all kind of users, not just your mythical ideal human with perfect vision on both eyes, flawless hand-eye coordination, and very good earing. Though dramatic efforts have been expended on making websites available to the largest audience over the past 20 years, software is still awfully lagging behind on this front, and there still is a reflexion to be had on how one can make software more accessible to the widest population. Another kind of accessibility consideration that has gotten more important recently is that of technological accessibility: software must run on a very wide array of hardware configurations, ranging from 7″ tablets with specifications from the last century to monster desktops with multiple 30″ displays, and picking a smaller target within that can only be done in the case where the target user base is very well known and guaranteed not to change.

And finally, we’ve gone full circle back to satisfaction. That one is a bit of a subjective criterion, which makes it harder to define, measure and optimize for, but it is obviously a critical concern too as software that is boring or downright annoying to use won’t be used even if it has the best design in the world. Satisfaction can be optimized for by making software more useful (including in ways users may not have initially foreseen, pleasant surprises can be good if done right), aesthetically pleasing, fun to use, comfortable, respectful, powerful, and yes, technically flawless too. In the end, though, the only way it can be measured, as with any kind of usability parameter, will be through the subjective assessment of users on the working software products.

Who said “that’s why we need as much iterative development as we can afford”?


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s