User Interface Design Essentials

Copyright 2000 by Gerhard Beck

Gerhard Beck

There are three pillars to an applications success: Features Function Face Features refers to what the application will do for the user. Features are the requirements for the software. Function refers to how well the software operates. Bug-free software will function perfectly. Face refers to how the application presents itself to the user - the applications user interface. Features, function and face can be restated as questions: Does the software meet the users requirements? (Features) Does the software operate as intended? (Function) Is the software easy to use? (Face) In this paper, I describe the essentials of user interface design. The goal of user interface design is to put a happy face on the application. Stated in more concrete terms, a successful user interface will require Zero Training and will be friendly not foreboding. Zero Training The goal of Zero Training could be considered as a sub-goal of friendly not foreboding. However, training costs are a major impediment to the usage of software making Zero Training an important goal by itself. There are two types of training involved in software design: software training and job training. Software training assumes the user knows how to do the job at hand and only needs to learn how to use the software to do the job. Job training teaches the user how to do the job - which can include more than how to use the application to do the job. The goal of Zero Training relates to zero software training. Job training can be integrated with software training, but results in a much more ambitious project. Friendly not Foreboding Almost everything you do to implement the goal of Zero Training will further the goal of being friendly not foreboding. However, some techniques for reducing training may slow up experienced users. For example, you could pop-up new user messages whenever the user lands in a particular field. Seeing the same message will get old after awhile; the experienced user should be able to dispense with the messages. Being friendly is an attitude and encompasses more than what is necessary for the Zero Training goal. Applications do have an attitude. For example, consider the following sets of application messages: Database does not exist I could not find database CorpInfo. If you are sure this name is correct, CorpInfo could be unavailable due to maintenance or LAN

problems. You should contact the help desk to see when CorpInfo will again be available. SQL access error 123 I could not save information to the database. You can try to save again to see if the error clears. If you call the help desk concerning this problem, tell them you have a SQL access error 123. I have run out of memory (RAM). This typically happens do to a bug in the program which causes it to lose memory over time. Save your game if possible. To free the memory you will need to reset the computer (turn it off and then on).

out of hunk1

The attitude of the first message is you did something that caused me a problem while the attitude of the second message is I have a problem. Could you give me a hand? Understanding Users You must understand the user to be able to put a happy face on your application. You should understand the users job, how the software fits in with that job and how the user goes about getting the job done. You need to approach the design of software from the users viewpoint not from an abstract requirements document. Specifically, you should understand what the user will be doing with the application. If you can think like a user, you can create a much better user interface. Here are some basic principles to remember about users: 1. Your software is like a hammer - the user doesnt really care how well crafted it is, the user just wants nails put in the wall. Users just want to do their job (or play their game). They dont care about you or your software. Your software is just an expedient tool to take the user where the user wants to go. 2. Given a selection of hammers to buy at the hardware store, the user will select the one which will be most fun to use. Of course, this varies by user - some will want the plastic handle, some the wood, some the green, etc. When evaluating your software, users are often swayed by looks, not function. Thus, steps taken to make the product look good (nice icons, pictures, good color scheme, fields aligned, etc.) will often favorably enhance evaluations of your software. 3. It had better drive nails. The user will not really know if your software is adequate to the job until the user has used the software to do actual work. From an interface perspective, the software should not look like it can do more than it can. 4. Some users will try to use a hammer to drive a screw. If your software is good, some user somewhere will try to use the software for some purpose for which you never intended it to be used. Obviously, you can not design a user interface to deal with uses you can not foresee. There is no single rigid model of the right way to use the software, so build in flexibility. 5. Users wont read an instruction manual for a hammer. They wont read one for your software either, unless they really have too. Users find reading instruction manuals almost as pleasurable as dental work.

This is an actual error message I was presented with in a game.

6. A user reading the instruction manual for a hammer is in serious trouble. When you create your help system (and printed manual), remember that the user will only resort to those materials if the user is in trouble. The user will want a problem solved as fast and as easily as possible. 7. Hammers dont complain. You should try to eliminate error messages and any error messages your program needs should have the right attitude. How to design a good user interface Designing a good user interface is an iterative process. First, you design and implement a user interface using appropriate techniques. Then you evaluate the design. The results of the evaluation feed the next design and implementation. You stop the process when you have met your design goals or you run out of time and/or money. Note that if you have different user communities (or the same user with different jobs), you may need different user interfaces, customizable user interfaces or both. For example, Microsoft Word provides four user interfaces: normal, outline, page layout and master. In addition, Microsoft Word provides a host of customization features for the keyboard, menu and toolbars. While design is important, the real key to creating a good user interface is in your evaluation techniques. Obviously, you should use your own user interface. If you cant use it, how can anyone else? Next, get feed back from your alpha testers, then from you beta testers. The best evaluations are done by watching over the shoulder of the user. The key here is watching. If you are telling the user what to do, you will never find out if your interface is easy to use. Let the user figure it out by himself. If the user has to ask you what to do or pauses to figure out what to do next, you may need to work on your interface. If the user grimaces, find out why. Learn from the experience. Some of my most innovative designs were shot down when the users could not figure them out. You will need both new and experienced users for testing your interface. The new users will help you determine if you meet the Zero Training goal. The experienced users will let you know if your methods for meeting the Zero Training goal interfere with getting work done once the user has learned the software. Tips Dont invite the user to make mistakes. If a function in you program is not currently available, dont let the user try to use it. For example, instead of providing an error message that the function isnt available, gray-out or hide the control that calls the function. Allowing the user to call a function which cant be used is inviting the user to make a mistake. Give the user a hint. If possible, provide the user with some insight into how your program functions. For example, if a process takes a long time, show the user what is actually happening. Providing tool tip help and describing what data fields are for in the status bar can also provide the user with valuable insight. Dont write a manual. A user is much more liable to lose a manual than read it. To avoid this problem, dont write a manual. Put the effort you would have taken to write a manual and put it into the help system. The help system will always be there for the user even if the manual isnt. Remember that help will only be consulted when the user has a problem. Your help system should make it easy

for users to find information needed to solve their typical problems. (OK, this requires a release of the software to find out what those typical problems are.) Train new users. Without a manual, you need to be more creative on how to train users. The key here is to train users - training materials should not get in the way of (irritating) experienced users. But even experienced users may need re-training or additional training on a previously unused feature. Thus, the training should get out of the way unless it is needed. Some common training methods are: Tip of the Day - Appears when the program starts. Gives the user information on program features which the user may be unfamiliar with. Tutorial - Guides the user through the software using a sample problem. Tutors - Provides a detailed list of steps to accomplish some task. A tutor is like a tutorial except that instead of showing the user how to solve a sample problem, the tutor shows the user how to solve the users problem. New User Messages - Advice which pop-up when the user tries to do something. For example, the message might pop-up when the user selects a button or enters a data entry field. Users definitely need a way to turn this feature off and on. Hints - Hints are reminders which are built into the software in an unobtrusive ways. Tool tips and status bar messages are prime examples of hints. Wizards - Summoned to perform some action for the user. Wizards typically ask the user what the user wants and then perform the necessary actions for the user. Wizards are not really a training device since the user will have no more idea how to do the job after the wizard is done than before (which is why they are called wizards - its like magic). So use a wizard whenever the user is unlikely to ever want to know how to actually use the features hidden by the wizard.

Provide useful interruptions. When are interruptions ever useful? The interruptions I am talking about are pop-up modal dialog boxes. They interrupt the user and demand the users attention. They can be used to either give information to or get information from a user. In either event, the most useful interruption is one that does not occur! Here are some specific ideas on eliminating interruptions or at least making them useful: Just do it. An error message should never say You must do X before you can use this Y function. The best way to avoid this is to just go ahead and do X for the user. If X involves substantial time or user interaction, you might ask the user if the user wants to do X now or cancel the action. Finally, you could gray out Y until the user has done X. The problem with graying Y out is that the user may not know that completing X is what turns Y on. Announce subtly. Message boxes which say Im done can be very irritating because the user has to get rid of them before going further. Signaling completion can be done in more subtle ways. For example: If a task is really modal (such as copying a file to disk), put up a dialog box showing progress. When the task is done, simply remove the progress dialog box and the user will know the task is done. Instead of a dialog box, use an hour glass and show progress on the status bar. When the task is done, remove the hour glass and put Task complete on the status bar.

 Use an in-process icon in a corner of the screen. Both Netscape Navigator and Microsoft Internet Explorer use this technique. Give explanations. Instead of displaying a error message number which is useless to the user, give the user a hint as to what the error is all about. The hint will probably also help your technical support personnel and might even jog your own memory. Tell user what to do. If you can determine the corrective actions which the user can take, you may as well let the user in on your little secret.

Satisfy curiosity. Users will try to learn your software by just trying things out. You should let users satisfy their curiosity without causing problems - for example, by providing an undo feature. Users generally look at the About box out of curiosity (or to find the version of the software). Here is a radical idea for your About box: use it to tell the user what your program is about! Follow standards. Following standard user interface conventions makes life simpler for the user. For example, which side of the road to drive on is a user-interface convention. It really doesnt matter if people drive on the left or the right hand side of the road, but it is awfully conventient if everyone drives on the same side of the road. In the Windows world, user-interface conventions are set by Microsoft.

Techniques This section presents some of my favorite techniques. The Big Red Arrow. The application involved loans which were always accessed through their loan number. In other words, the user had to enter a loan number to do anything with the application. Since the loan number was something the user would want to know while the application was running, I decided to get and display the loan number in the tool bar. Since the users worked on several loans at a time, I used a combo box which listed the last thirty loans worked on, with the most recent loan at the top. The user could either select a loan from the list or type in a new loan number. When I proudly showed off the application, the very first question I got was How do I start?. Before entering a loan number, the user could do nothing so the screen was blank between the toolbar and the status bar. I employed this space to give the user an unobtrusive hint of where to start with a big red arrow pointing to where to enter the loan number with the text Enter a Loan Number. The hint was unobtrusive because when the user enters a loan number, the big red arrow is replaced by information about the requested loan. And if the user closes a loan without selecting the next loan to work on (such as by pressing the new button), the unobtrusive hint of what to do next reappears.

 The To Do List. The big red arrow application also had about twenty screens the user needed to work with. Not all screens were needed by all types of loans. In addition, some screens were not needed until other screens had been completed. After considering a variety of navigation options (menu, combo box in tool bar, chaining one screen after another), we decided on a navigation window listing all of the appropriate data entry screens. We then added a drop down list box to get the type of loan. Thus, the user could see the data entry requirements for each loan type right on the navigation screen. We color-coded each screen in the list to show its status: black (*) for completed, red (>>) for suggested next screen, blue (>) for screens the user could access out of order and gray (blank) for screens the user could not yet access. The user could do data entry on any screen which was not gray. We then organized the screens in a logical work flow and labeled it the to-do list. Viola, we had our first work flow application. The Query Buttons. The next problem on the big red arrow application was how to debug the operation of the to-do list. The rules relating to when screens changed status were in a state of flux with constant discussion between the business group and the programming group. To solve some of the problem, I decided to make the process self-documenting. First, I attached explanatory text to each test for determining whether a screen was done. Next, when I evaluated whether a screen was done, I created a list of all the explanations of what still needs to be done. The idea was that the testers could examine the list and see if the tests were correctly coded. To pop-up the list, I added a question mark to the navigation screen. A tester could drag a screen to the question mark to find out that screens status and exactly what was needed to either complete the screen or make the screen available (ungray). When I showed it to the testers, this debugging tool became an immediate feature. It was a big hit with the users because it provided an appropriate insight into the operation of the program. The asterisk button was similarly used to show the overall status of the loan. Flying status bar. Some database applications take considerable time (10 to 60 seconds) to load up all necessary data from a variety of tables. The load speed can also depend on how much traffic the database server is getting. You can provide meaningful insight to the user by listing the current database table being loaded in the status bar. Ideally, the user will see a new table being loaded every few seconds and be mollified. After a while, a user watching the tables flash by will be able to tell is

the process is going faster or slower than usual. Finally, if the load gets hung up, the displayed table can provide valuable information about where the process broke down. Similar flying status bar reports can be used in imports and exports (Exporting record 123 of 456). Summary Understand how your application is used will help you to create a successful user interface which requires Zero Training and is friendly not foreboding. Further Reading Alan Cooper, About Face: The Essential of User Interface Design (IDG Books Worldwide, Inc., 1995). Brenda Laurel (Editor), Art of Human-Computer Interface Design (Addison-Wesley Pub Co, 1990) Donald Norman, Psychology of Everyday Things (Basic Books, 1988)