UI Guidelines

A. User Interface Design Tips and Techniques

In this section we will cover a series of user interface design tips that will help you to improve the objectoriented interfaces that you create.

1. Consistency, consistency, consistency. The most important thing that you can possibly do is make sure that your user interface works consistently. If you can double-click on items in one list and have something happen then you should be able to double-click on items in any other list and have the same sort of thing happen. Put your buttons in consistent places on all of your windows, use the same wording in labels and messages, and use a consistent color scheme throughout. Consistency in your user interface allows your users to build an accurate mental model of the way that it works, and accurate mental models lead to lower training and support costs.

2. Set standards and stick to them. The only way that you’ll be able to ensure consistency within your application is to set design standards and then stick to them. The best approach is to adopt an industry standard and then fill any missing guidelines that are specific to your needs. Industry standards, such as the ones set by IBM (1993) and Microsoft (1995), will often define 95%-99% of what you need. By adopting industry standards you not only take advantage of the work of others you also increase the chance that your application will look and feel like other applications that your users purchase or have built. User interface design standards should be set during the Define Infrastructure Stage (Ambler, 1998b).

3. Explain the rules. Your users need to know how to work with the application that you built for them. When an application works consistently it means you only have to explain the rules once. This is a lot easier than explaining in detail exactly how to use each and every feature in an application step by step.

4. Support both novices and experts. Although a library-catalog metaphor might be appropriate for casual users of a library system, library patrons, it probably is not all that effective for expert users, librarians. Librarians are highly trained people who are able to use complex search systems to find information in a library, therefore you should consider building a set of search screens to support their unique needs.

5. Navigation between screens is important. If it is difficult to get from one screen to another then your users will quickly become frustrated and give up. When the flow between screens matches the flow of the work that the user is trying to accomplish, then your application will make sense to your users. Because different users work in different ways, your system will need to be flexible enough to support their various approaches. Interface-flow diagrams can be used during the Model Stage (Ambler, 1998b) to model the flow between screens.

6. Navigation within a screen is important. In Western societies people read left to right and top to bottom. Because people are used to this should you design screens that are also organized left to right and top to bottom. You want to organize navigation between widgets on your screen in a manner that users will find familiar to them.

7. Word your messages and labels appropriately. The text that you display on your screens is a primary source of information for your users. If your text is worded poorly then your interface will be perceived poorly by your users. Using full words and sentences, as opposed to abbreviations and codes makes your text easier to understand. Your messages should be worded positively, imply that the user is in control, and provide insight into how to use the application properly. For example, which message do you find more appealing “You have input the wrong information” or “An account number should be 8 digits in length.”? Furthermore, your messages should be worded consistently and displayed in a consistent place on the screen. Although the messages “The person’s first name must be input.” and “An account number should be input.” are separately worded well, together they are inconsistent. In light of the first message, a better wording of the second message would be “The account number must be input” to make the two messages consistent

8. Understand your widgets. You should use the right widget for the right task, helping to increase the consistency in your application and probably making it easier to build the application in the first place. The only way that you can learn how to use widgets properly is to read and understand the user-interface standards and guidelines that your organization has adopted.

9. Look at other applications with a grain of salt. Unless you know that another application follows the user-interface standards and guidelines of your organization, you must not assume that the application is doing things right. Although it is always a good idea to look at the work of others to get ideas, until you know how to distinguish between good user-interface design and bad user interface design you have to be careful. Too many developers make the mistake of imitating the user interface of another application that was poorly designed.

10. Use color appropriately. Color should be used sparingly in your applications, and if you do use it you must also use a secondary indicator. The problem is that some of your users may be color blind – if you are using color to highlight something on a screen then you need to do something else to make it stand out if you want these people to notice it, such as display a symbol beside it. You also want to use colors in your application consistently so that you have a common look and feel throughout your application. Also, color generally does not port well between platform – what looks good on one system often looks poor on another system. We have all been to presentations where the presenter said “it looks good on my machine at home.”

11. Follow the contrast rule. If you are going to use color in your application you need to ensure that your screens are still readable. The best way to do this is to follow the contrast rule: Use dark text on light backgrounds and light text on dark backgrounds. It is very easy to read blue text on a white background but very difficult to read blue text on a red background. The problem is that there is not enough contrast between blue and red to make it easy to read, whereas there is a lot of contrast between blue and white.

12. Use fonts appropriately – Old English fonts might look good on the covers of William Shakespeare’s plays, but they are really hard to read on a screen. Use fonts that are easy to read, such as serif fonts like Times Roman. Furthermore, use your fonts consistently and sparingly. A screen using two or three fonts effectively looks a lot better than a screen that uses five or six. Never forget that you are using a different font every time you change the size, style (bold, italics, underlining, …), typeface, or color.

13. Gray things out, do not remove them. You often find that at certain times it is not applicable to give your users access to all the functionality of an application. You need to select an object before you can delete it, so to reinforce your mental model the application should do something with the Delete button and/or menu item. Should the button be removed or grayed out? Gray it out, never remove it. By graying things out when they shouldn’t be used people can start building an accurate mental model as to how your application works. If you simply remove a widget or menu item instead of graying it out then it is much more difficult for your users to build an accurate mental model because they only know what is currently available to them, and not what is not available. The old adage that out of sight is out of mind is directly applicable here.

14. Use non destructive default buttons. It is quite common to define a default button on every screen, the button that gets invoked if the user presses the Return/Enter key. The problem is that sometimes people will accidentally hit the Enter/Return key when they do not mean to, consequently invoking the default button. Your default button shouldn’t be something that is potentially destructive, such as delete or save (perhaps your user really did not want to save the object at that moment).

15. Alignment of fields. When a screen has more than one editing field you want to organize the fields in a way that is both visually appealing and efficient. As shown in Figure 1 I have always found that the best way to do so is to left-justify edit fields, or in other words make the left-hand side of each edit field line up in a straight line, one over the other. The corresponding labels should be right justified and placed immediately beside the field. This is a clean and efficient way to organize the fields on a screen.

16. Justify data appropriately. For columns of data it is common practice to right justify integers, decimal align floating point numbers, and left justify strings.

17. Do not create busy screens. Crowded screens are difficult to understand and hence are difficult to use. Experimental results (Mayhew, 1992) show that the overall density of the screen should not exceed 40%, whereas local density within groupings shouldn’t exceed 62%.

18. Group things on the screen effectively. Items that are logically connected should be grouped together on the screen to communicate that they are connected, whereas items that have nothing to do with each other should be separated. You can use white space between collections of items to group hem and/or you can put boxes around them to accomplish the same thing.

19. Open windows in the center of the action. When your user double-clicks on an object to display its edit/detail screen then his or her attention is on that spot. Therefore it makes sense to open the window in that spot, not somewhere else.

20. Pop-up menus should not be the only source of functionality. Your users cannot learn how to use your application if you hide major functionality from them. One of the most frustrating practices of developers is to misuse pop-up, also called context-sensitive, menus. Typically there is a way to use the mouse on your computer to display a hidden pop-up menu that provides access to functionality that is specific to the area of the screen that you are currently working in.

B. Prototyping

Prototyping is an iterative analysis technique in which users are actively involved in the mocking-up of screens and reports. The purpose of a prototype is to show people the possible design(s) for the user interface of an application. As we see in Figure 2 there are four steps to the prototyping process:

1. Determine the needs of your users. The requirements of your users drive the development of your prototype as they define the business objects that your system must support. You can gather these requirements in interviews, in CRC (class responsibility collaborator) modeling sessions, in use-case modeling sessions, and in class diagramming sessions (Ambler 1995; Ambler, 1998a;

Ambler,1998b).

2. Build the prototype. Using a prototyping tool or high-level language you develop the screens and reports needed by your users. The best advice during this stage of the process is to not invest a lot of time in making the code “good” because chances are high that you may just scrap your coding efforts anyway after evaluating the prototype.

3. Evaluate the prototype. After a version of the prototype is built it needs to be evaluated. The main goal is that you need to verify that the prototype meets the needs of your users. I’ve always found that you need to address three basic issues during evaluation: What’s good about the prototype, what’s bad about the prototype, and what’s missing from the prototype. After evaluating the prototype you’ll find that you’ll need to scrap parts, modify parts, and even add brand-new parts.

4. Determine if you’re finished yet. You want to stop the prototyping process when you find the evaluation process is no longer generating any new requirements, or is generating a small number of not-so-important requirements.

C. Prototyping Tips and Techniques

I have covered the fundamentals of the prototyping process, so now I want to share with you several tips and techniques that you can use to create truly world-class prototypes.

1. Look for real-world objects. Good UIs allow users to work with the real-world objects they are used to. Therefore you should start by looking for these kinds of objects and identify how people interact with them.

2. Work with the real users. The best people to get involved in prototyping are the ones who will actually use the application when it’s done. These are the people who have the most to gain from a successful implementation, and these are the ones who know their own needs best.

3. Set a schedule and stick to it. By putting a schedule in place for when you will get together with your users to evaluate the prototype, you set their expectations and you force yourself to actually get the work done. A win-win situation.

4. Use a prototyping tool. Invest the money in a prototyping tool that allows you to put screens together quickly. Because you probably won’t want to keep the prototype code that you write, code that’s written quickly is rarely worth keeping, you shouldn’t be too concerned if your prototyping tool generates a different type of code than what you intend to develop in.

5. Get the users to work with the prototype. Just like you want to take a car for a test drive before you buy it your users should be able to take an application for a test drive before it is developed. Furthermore, by working with the prototype hands-on they will quickly be able to determine whether or not the system will meet their needs. A good approach is to ask them to work through some use case scenarios using the prototype as if it is the real system.

6. Understand the underlying business. You need to understand the underlying business before you can develop a prototype that will support it. Perform interviews with key users, read internal documentation of how the business runs, and read documentation about how some of your competitors operate. The more you know about the business the more likely it is that you’ll be able to build a prototype that supports it.

7. There are different levels of prototype. I like to successively develop three different types of prototypes of a system: A hand-drawn prototype that shows its basic/rough functionality, an electronic prototype that shows the screens but not the data that will be displayed on them, and then finally the screens with data. By starting out simple in the beginning I avoid investing a lot of time in work that will most likely be thrown away. By successively increasing the complexity of the prototype as it gets

closer to the final solution, my users get a better and better idea of how the application will actually work, providing the opportunity to provide greater and greater insight into improving it.

8. Don’t spend a lot of time making the code good. At the beginning of the prototyping process you will throw away a lot of your work as you learn more about the business. Therefore it doesn’t make sense to invest a lot of effort in code that you probably aren’t going to keep anyway