Jeremy Zawodny’s Surprising User Expectations post and Jeff Atwood’s UI is Hard post draw attention to a big problem in software development: Developers rarely design good UI’s. I have come to the conclusion that UI design should be handled by people who understand how users think, interact and model problems. This is more of a human factors problem than a coding problem.
I am a big proponent of making usable software. It’s one of my crusades. Usability is not defined by developers, it is defined by users. We recently completed our second phase of usability testing on a new product. It’s always a learning experience watching regular people trying to use software. It can be frustrating when it’s software I helped to develop. To make better UI’s, developers need to appreciate the obstacles that confront users and try remove the obstacles. Usability testing and reading people like Cooper, Nielsen and Norman can give you a better perspective.
Here are a couple guidelines I compiled from my own experiences and from people smarter than me:
- Be flexible: Allow for multiple ways to get something done. Use main menus, toolbars, right-click menus, task panes and hyperlinks. This allows the user to choose the way most comfortable to them instead of forcing them to learn your way. Keep in mind that for any given user, the preferred method could change over time.
- Be explicit: Don’t force the user to guess or explore the UI. Use verbose captions, messages and explanations.
- Be proactive: Don’t wait until the user gets into trouble, keep the user from getting into trouble in the first place. Why wait until the end of a process to inform the user they made a mistake at the beginning?
- Be forgiving: Make it possible for a user to recover from an unwanted action. People make wrong choices. Recovering from a bad choice with most of your data intact is far better than being forced to recreate something from scratch.
- Be simple: Simple, focused screens and dialogs are easier to learn and allow users to get things done faster.
- Be consistent: Make use of the fact the users can learn how to do things. Don’t force them to re-learn how to do the same or similar things.
None of these points is revolutionary or even original. But it’s amazing how few applications implement them.
Jeff’s post has some good links to other articles that are worth checking out. He also brings up the concept of UI First development. I definitely agree that the UI should be given some focus early in the project. Unless your building an engine or library, the end-user is going to equate the UI with the software. If the UI is bad it won’t matter how good the code is behind the scenes.
Update: For those interested, a co-woker pointed me to another UI First design methodology at Human Factors International (HFI).