Because everyone and their grandma is coming out with a book on “usability for people who aren’t user interface designers,” I’ve decided that I too am qualified to say something on the matter. I’ve been writing some docs in preparation for my hiatus from Etna, and below I’ve included some snippets from those docs. This is high-level advice for programmers that have to make do with their own interfaces, and want a good starting point for designing UIs.
UI design is about usability, not aesthetics. Often, what works well also looks good, but they are not necessarily one and the same. While the two seldom conflict, never sacrifice usability for artistic “flare.” We’re engineers, not artists. The difference is that the end product is useful.
Think like a user. Don’t make things for the sake of making them. Users have goals. Think about each goal a user may have in every stage of your application, then build it to make achieving those goals easy. You’ll find you have a much clearer idea of how to organize your UI if you think about use cases and user goals.
Maximize visibility. Show what’s happening, but only what’s important. Use your intuition and your set of use cases to expose states, available actions, and information. Can a user tell, at a glance, what the state is? What valid states can come next? What can be manipulated, and what is display-only?
Be responsive. When something happens, make it obvious its happening. Visual feedback is extremely important – progress bars, Ajax spinners, whatever. Similarly, never perform a mutate or state transition without some visual cue or message.
Optimize for the common case. Think about what gets used the most, and make that as effortless as possible. Word 2007’s most oft-clicked button is “paste” – is it any wonder that its a giant clipboard button on the left side of the home ribbon? Identify usage patterns and make them easy to repeat.
Minimize effort. Count the number of clicks it takes to do a task. Count how many times the average user would switch between keyboard and mouse to perform an action. If you can lower the click count or input switch count, you’re probably improving usability. Bonus: Use your mathematical skills to lower the average expected number of clicks for a set of related actions.
Don’t break convention without a good reason. It helps to use a lot of software to glean ideas that you can borrow. Some things on a computer are inherently unintuitive, so you need to make sure you adhere to commonly accepted conventions. How the hell is someone who has never used a computer supposed to know that double-clicking a word highlights it? Everyone who’s familiar with computers knows this, and they don’t think about it. It’s just a convention. Don’t break it unless there’s a good reason.
User Model, Meet Application Model
Users form ideas about how your software works by interacting with it. You are responsible for teaching, and then reminding, the user how the program “works.” The user’s idea of how your application works is called the user model.
The User Model
The user model is not a “simplified” view of how the application works. It’s the minimum information needed to understand and predict the application’s behavior. It can be completely wrong, but still useful. For example, a steering wheel is designed to promote a certain user model — the illusion that turning the steering wheel turns the car. The exact mechanism – whether there’s an actual steering column or it’s drive-by-wire, doesn’t matter.
You can make your user model easier to learn and remember if you use common analogies. For example, the ecommerce “shopping cart” analogy is very commonplace. The benefit of this model is that users intuitively pick up right away that they are building a list of things they want to buy, and can check out and pay for them all at once. But even more importantly, it gives them all kinds of implicit guarantees, like the fact that quantities won’t randomly change in their cart, and things won’t randomly appear and disappear from the cart.
The Application Model
The application model is how your program “actually” works. The most important thing about usability is that the application model and the user model must be compatible. Whenever there’s a disparity between the two, usability suffers. You can ensure the user model closely matches the application model by reducing ambiguity in your interface, and adding subconscious hints to the UI.
When you hover over a link, the cursor changes from an arrow to a pointer icon. This indicates that an action is available. You can actively throw this off by behaving counter to conventions, such as with this link.
As before, a good analogy in your UI helps portray the application model correctly: buttons are for clicking, checkboxes are for ticking, input fields for typing.
For more complicated user interfaces, the best way to increase usability is to decrease the probability of performing an incorrect action. One can do this by providing hints as to the correct action, and de-emphasizing or removing hints that lead to an incorrect action. A well-designed door handle is crafted so that the required action of pulling or pushing is clear from its shape:
Clearly, this is a good example of bad design. The metal plate is sufficient to afford pushing; the presence of a handle that is clearly shaped to support pulling confuses the user. The percent of people who try to pull the handle would probably be the same if the words “push” wasn’t etched there at all.
Usability for Humans
The new conventional knowledge is that users aren’t going to read the manual; nor should they have to. Almost all software can be designed so that the user can accomplish his goals without needing extensive training in how to interact with it. Just as you should understand how a stove or a car works without reading the manual, one should be able to crop a family photo or send an email without poring over the help file.