The User Interface plays an important role when using an application, be it a desktop application, a web or a mobile one. The book About Face, written by Alan Cooper, a thought leader in user interface design, provides interesting and useful guidance on creating a UI for an application. The following are some of the book’s most notable ideas.
Design for Intermediates Users
Cooper argues that the vast majority of users of any software product can be categorized as intermediate users - users who basically know how to use the product and generally use it for doing the same thing all the time. He estimates that such users are around 80% of the users who use the product, with the remaining 20% equally distributed between advance and beginner users.
However, he interestingly points out that although they are the majority of the users of the product, their needs are often neglected in the UI design. He states that management tend to advocate most for the needs of beginners since those are the users that they usually interact with, while developers are by definition expert users of the product and tend to think of end users as experts too. Cooper feels that intermediates tend to get lost in the mix, even though they are the majority of the users.
He explains that the needs of the three types of users differ due to their familiarity with the product. While experts want quick ways to do things and the ability to customize the application, beginners are most concerned with overviewing the basics of the tool. Intermediates tend to repeatedly do the same things with the tool and do not want to have their work processes obstructed by the interface.
Use Tools that Help Beginners to Become Intermediates
While only 10% of a product’s users are beginners, all users of the product must pass through the state of being a beginner user. Special attention should therefore be paid to designing the interface helping new users to learn the basics of the application.
Although migrating beginners to intermediates is a goal of the UI design, Cooper is quick to note that once a user has moved from the initial stage to the next one, the UI that helped him to achieve that will no longer be of much use. In fact, it will likely obstruct the user's workflow.
There are numerous products trying to educate beginners, but at the same time they are really annoying to intermediate users of the product. In VS2008 for example, we inserted comments into generated unit test code in order to help beginner users to understand the various components of a unit test. While they serve their purpose well, they get in the user's way once the components have been understood. We since removed them in VS2010.
To help users become intermediates, he suggests adding something to the UI that provides overview information to the user on how to use the product. He suggests that it should be possible to remove this information from the UI when the user wants to turn it off. This classically takes the form of a "getting started" video which overviews the features of the product.
Cooper thinks that online help and tooltips actually best serve intermediate users rather than beginners since their needs are slightly different. He suggests that intermediates search for reference educational documents, while beginners tend to be most interested in information that overviews those documents.
Less is More
I love this quote: "No matter how cool your interface is, less of it would be better."
Sometimes in UI design, I think that we forget that users use a product as a tool to accomplish a specific goal. Sometimes we get carried away with cool navigation tools such that we put too much of it in the UI. A purple hammer which glows in the dark is still useless if it can't effectively put nails into wood.
Cooper is an advocate of minimalist design where every options should be purposeful and direct. He advocates for fewer more direct options in an interface. He states that in a well orchestrated UI design, the UI becomes almost transparent to the user since it naturally follows their mental model.
Design for the Probable, Provide for the Possible
Cooper is an advocate for following the user's mental model when designing the product and optimizing for the mainline flow through the application. While this often means that one should eliminate more options from a dialog than a programmer may feel comfortable doing, it does not imply that there should not be ways to do more complex and sophisticated things, just that they should be more difficult to access.
If one were to outline the types of activities that a user can perform at any one stage in an application workflow, Cooper feels that there will always be one or two items that are the most likely to be performed. Thus, the interface should be optimized to help the user find these activities and guide them through this workflow rather than just listing all options at all times. There should be a way for the user to access non-mainstream activities, but the UI should not be optimized for its use.
I think the office ribbon did a fantastic job of optimizing for the probable but allowing for the possible. In the ribbon, the items that are likeliest for the user to want to use are 1 click away, the items that they will use less are 2 clicks away, the items that very unlikely to be used are 3+ clicks away. They clearly optimized their UI for the probable.
Eliminate Errors or Confirmation Dialogs
Keeping with the theme of following a user's mental model and removing obstacles that can obstruct intermediate user's flow, Cooper advocates for removing all error and confirmation dialogs from a product. He feels that applications should do what statistically has a good chance of being correct but provide users with an option to undo their actions.
Cooper states that users like to see their options available to them, perform an action, and then get confirmation that the action had successfully occurred. Without confirmation than an action occurred, users wonder if their actions actually took place. Rather than provide pop-up notifications, in order to communicate the result of actions, Cooper favors inline status alerts and positive auditory feedback.
While I agree that it would be ideal to get rid of confirmation dialogs in all circumstances, getting rid of them entirely feels too drastic for my taste. To implement what Cooper suggests, developers need to make each action that the user performs reversible, which is both costly and in my opinion, not needed. I would prefer to make the best effort to eliminate confirmation dialogs and make actions reversible, but in the case of drastic actions, like disk format and file delete, popping a confirmation dialog seems to be fine, in fact users may expect it.
On the other hand, I tend to agree with him that error dialogs should be entirely removed from the product. Although they make sense to a programmer, I think they tend to make little sense to the end user. I've seen many users getting very frustrated because their workflow is hampered when they appear. Cooper notes that while they are used to signal that something went wrong with the code, the user tends to interpret them as “I’ve done something wrong.” When users are told that they are wrong repeatedly, they start to hate your product. I've been playing with some of the Mac UI recently and have been surprised to see they seem to be constantly eating their exceptions. Sure, problems occur - they just don't surface to the user.
About the Author
Naysawn Naderi is a Program Manager on the Visual Studio Team Test at Microsoft. He is currently focused on building the right user experiences to allow manual testers to test better and collaborate more efficiently with members of their software team. He holds a Bachelors of Electrical Engineering from McGill University. He maintains the blog Testmundo.