Skip to main content

Brittan’s Rules of Software Usability

Posted by pbrittan on August 1, 2003 at 7:39 AM PDT

I am not going to pretend that I am a usability guru. There are plenty of folks who have studied the issues of software usability far, far more rigorously than I have, people like Jakob Nielsen, Tog, and Alan Cooper, among many others: Joel has solid advice on User Interface Design for Programmers, the Interface Hall of Shame is very entertaining as well as educational.

However, usability has long been a central interest of mine, and it has been a hallmark of all my companies. For the first two companies, it was the usability of our software products that helped set us apart. In my current company, it’s about enabling developers to deliver highly usable software to their customers. I believe that usability matters – big time. If users can’t use software, there’s no point in writing it. I think this comes from simply caring about what I do and wanting to do a good job. “Quality is caring,” as Bob Waterman points out.

The experience that I and my colleagues have had in these three companies has led me to boil down good usability into three rules about what really matters most:

  1. Perspicuity. Merriam-Webster: “plain to the understanding especially because of clarity and precision of presentation”. Perspicuity in software means making it clear to the user what choices are available to him or her. This was the big improvement of GUIs over command-line interfaces: menus, buttons, radios, and checkboxes let the user know what commands and what choices were available at any given time. The GUI lays it all out.



    I often hear people say that such-and-such software “has too many features” which makes it difficult to use, and that the software would be improved by removing features. I rather assume that all the features are useful at one point or another and that removing them would degrade the software, not improve it. The problem that these users are grappling with is that too many choices are laid out on the same level – they have lost the sense of what is more important and what is less. It is unclear how to accomplish a simple straightforward task because there are so many controls for advanced tasks mixed in with the controls for the common tasks.



    My colleagues and I have often talked about the perfect user interface, one which appears extremely simple at first glance with just the core functions of the application in evidence. But then, as the user pushes the app and demands more of it, more detail and advanced features seamlessly appear out of the woodwork, as it were.


  2. Alignment with personal workflow. This is really important and takes many forms. Generally speaking it is about letting the user move through the software and accomplish his or her tasks in a way that makes sense with how the user works. It means putting the user in control of the flow, and not fighting with them.



    Although wizards seem like a good idea on the surface, users often find them very annoying. That’s because they brutally take control of the workflow from the user. This often happens when an app designer is having trouble with perspicuity and feels the need to take the user by the hand to lead him or her through the minefield.



    Personal workflow does not refer only to how a user moves through the functions of an application, it also refers to how a user interacts with the controls of the application. For instance, smart parsing is a feature that my users have always enjoyed. My first company’s product was designed for use by currency traders. These folks have a whole specialized lingo to describe their world, and it was important for our app to be able to understand that lingo. For example, if a trader needed to enter a currency type, such as French Franc, into a field, we would let them enter “french”, “franc”, “frank”, “france”, “français”, “paris”, “FF”, or “FRF” into that field, all words that traders commonly used, parse it and then redisplay the value as a standardized “French Franc” to let the user know that what they typed had been understood by the program. The program is operating on the user’s terms.


  3. Style. Yes, style. Charisma. If products don’t look good and appeal to users, users won’t feel good about using them. We all like interacting with good-looking things: cars, gadgets, people… I have heard extreme cases where a programmer simply added some color to a drab application, and the users reacted as if the app had been incredibly enhanced. I am a real stickler about this. An app should look sharp. If the correct spacing between two components is 3 pixels, then 2 pixel spacing doesn’t cut it.



    People generally like apps that have native OS look & feel, particularly for business apps. They get uneasy if the app doesn’t fit in with the other apps on their desktop. Style deviance can distract the user and force him or her think more about the app than about their task at hand. Having consistent apps for the user’s desktop OS also means that the user will be able to perform basic functions intuitively (cut & paste, get help, etc.). Some core controls, such as drop-downs, can vary surprisingly in how they work in different OSes or different GUI toolkits.



    Unfortunately, when we’re under the gun of a tough deadline (and it seems like that is always the case), style considerations are usually the first thing to get ditched. Getting style right actually takes a lot of time. And it seems like a luxury when the heat is on. But if user acceptance is important for your app, it’s no luxury -- it’s a necessity.

Having rules helps, but don’t get me wrong – developing highly usable software is darn hard. My colleagues and I struggle with it all the time. Even with the guidance of rules, the correct path is often difficult to discern, and we find ourselves sweating to make the right decisions. But that sweat is well worth it.

Related Topics >>