While user interface (UI) reviews often occur at the end of the development cycle, I recommend that you get involved early in the process, preferably when the designers create the initial wireframes or paper prototypes. Why? Making changes early in the process reduces development costs. Plus, if you identify usability issues early, it’s much more likely the team can remedy them before launch, preventing bad reviews like that shown in Figure 1, negative word-of-mouth, and the lost sales that result from them.
Before reviewing an application’s user interface, make sure you know who the users will be, have clear goals in mind, and remember, it’s all about improving the user experience.
What Does a Comprehensive UI Review Involve?
Based on my experience working with desktop, enterprise, and Web applications over the past decade, I’ve identified five general areas you should consider when reviewing a user interface:
- design elements
- text elements
- link elements
- visual elements
- user interactions
Reviewing Design Elements
“Design is not about decoration. It’s about communication and problem solving.”—Garret Dimon, in “Improving Interface Design”PDF
from Web Visions, 2007
When assessing the design elements of a user interface, you need to consider their overall aesthetics—Do they look good?—and functionality—Do they work well?
In many ways, what makes a user interface look good is entirely subjective. What looks good to me might not look good to you. But reviewing certain elements in the overall design of a window or Web page removes much of this subjectivity—for example, the labels; the size, placement, and alignment of user interface elements; and the way a user interface communicates its workflows.
Your company or product user interface guidelines should cover all of these design characteristics. Then, you can objectively judge whether a product’s UI design follows the guidelines, and your review has nothing to do with your personal opinion. Consistency is an important design element of user interfaces. Developing UI guidelines helps ensure consistency.
Tip—If your company does not have user interface guidelines or a style guide, create them. Creating guidelines or style guides is a big undertaking. To save a lot of effort, base them on the standards from Microsoft, Apple, or Sun, and document only the exceptions that are specific to your organization. Whether you’re working on desktop or Web applications, a wide variety of style guides is available online.
Guidelines for Design Elements
When reviewing design elements, consider the following:
- Are all user interface elements labeled?
- Are related features or functions grouped together and labeled appropriately?
- Are there visual cues that separate elements from one another and from other groups of elements—for example, group boxes, tabs, expandable sections, or areas with different background colors?
- Are all labels correctly aligned with their user interface elements? Check the horizontal alignment of labels with boxes, check boxes, and option buttons. Use a screen ruler like Screen Ruler from Micro Fox Software to confirm alignment if you aren’t sure.
- If most of your users are from Western cultures, does the placement of user interface elements follow the reading pattern from upper left to lower right?
- Does the user interface accommodate users from other cultures who read from right to left?
- Is the vertical spacing between individual elements the same for similar elements? Use a screen ruler to measure the spacing if you’re not sure.
- Is there sufficient space in windows, on Web pages, on tabs, or in boxes to accommodate labels and other text in all required languages? For example, labels in German can take up to 30% more space than English labels. Have the developers allowed for the possibility of other languages, or have they hard-coded fixed-length values and labels? To test whether a text box has a fixed length, try typing more characters than it appears it can contain.
Here are some examples of the kinds of problems you might find when assessing design elements. The tabbed page shown in Figure 2 contains misaligned labels, check boxes, and text boxes, as the dashed lines show.
Figure 3 shows examples of command buttons that are too small for their labels and buttons for which there isn’t sufficient space.
The form in Figure 4 is a jumble. Text boxes and combo boxes have different heights, descenders are cut off, arrow buttons aren’t the same size, and labels are in title case, are overly long, and aren’t parallel. (See “Reviewing Text Elements” for more information about text issues.)
Assessing Logical Flow
When reviewing a user interface, you must assess its logical flow. By logical flow, I mean whether the user interface is logical to your audience. Ask these questions:
- When a user presses the Tab key, where does the focus jump? Does it jump all over the user interface, or does it follow your audience’s expectations based on their reading patterns—for example, left to right, top to bottom?
- Which element has the focus when a page, window, or tab first appears? Is it on the first element, the OK or Cancel button, or some other element? Is the focus sufficiently visible, so users can easily see where any insertion point is by default?
- Can users access all elements in the user interface using the Tab key or other keys? Are there elements users can select only using a mouse or other pointing device?
- Can a screen reader such as JAWS read the user interface?
- Can users control the user interface using voice commands?
- Do users have to scroll horizontally or vertically to see the entire user interface, even on a screen of the target resolution and size? (Vertical scrolling is usually acceptable, but generally, horizontal scrolling is not.)
Reviewing Text Elements
When reviewing text user interface elements, consider these three Cs of communication:
- clarity—The textual messages a user receives from an application must be clear.
- consistency—Use terms and labels for user interface controls that are familiar to users.
- conciseness—Be as brief as possible, but don’t sacrifice meaning for brevity.
Getting each of these aspects right for every text element in a user interface helps reduce that other C—confusion.
When reviewing a user interface, be sure to review these textual elements:
- title bars
- status bars
- sidebars
- navigation and menu items—all levels
- items in list boxes and drop-down lists
- group box labels
- headings
- text box labels
- column headers
- icon labels
- button labels
- ToolTips
- link text—usually in Web applications
- graphic elements containing text
- user assistance text
- Help text
- confirmation messages
- error messages
Consistency in Terminology and Spelling
When reviewing a user interface, look for:
- misspellings and typos
- consistent spelling of product names and terms
- appropriate use of case and capitalization, as specified by your style guide
Many languages have distinct regional variations in spelling to which a user interface might need to conform. For example, if your user interface is in English, should the spelling conform to US English or British English?
Remember that correctness means the user interface complies with your company or product style guide.
Correct Punctuation
Review the punctuation of text elements for correctness and consistency. In particular, look for the following:
- inconsistencies in word hyphenation
- appropriate use of closing punctuation for text elements
For example, your style guide probably specifies a closing colon following a text box or list label. Make sure all labels conform to the guidelines.
Appropriate Use of Fonts
When reviewing user interface text, check the following:
- Is the font family appropriate to the application and familiar to the audience? For example, Times New Roman rarely, if ever, appears in a desktop application, and Comic Sans never appears in an enterprise Web application.
- Are bold, italics, and underlining used consistently, in compliance with your style guide? For example, Web style guides specify that no text in a user interface should be underlined unless it is a link.
- In Web applications, can a user increase or decrease the font size, or is the size hard-coded?
Appropriate Use of Language
Check the use of language in a user interface:
- Ensure the user interface uses simple language.
- Ensure the use of language is appropriate for the expected audience.
- Watch out for abbreviations and acronyms. Avoid using them unless you are absolutely sure your audience understands them.
- Look for parallel structure in text elements such as headings, lists, and the labels of text boxes, check boxes, and option buttons. For example, do they consistently use the gerund form, ending in -ing, or the imperative form of verbs? See Figure 5 for an example of parallel labels.
Assessing Internationalization and Localization Issues
When reviewing text elements, consider what impact other languages and alphabets might have on how the interface text displays.
- Is the space for titles, labels, and values in fields flexible enough to allow for other languages? Or might labels wrap badly, overlap, and be obscured by other labels or other user interface elements or be truncated so they are unreadable?
- What happens to text when it’s translated to a right-to-left or double-byte language?
- Is the user interface text hard-coded into the application, or is it stored in linked resource files? When developing a new application, make sure developers use linked resource files—even if they aren’t currently considering future support for other languages. In the long-term, maintaining text in resource files is much easier for everyone—particularly developers, technical writers, and technical editors—even if the application never gets translated.
- Is there anything culturally specific about the user interface text? For example, the United States uses ZIP code when referring to a postal code, but other countries use other terms for postal codes. In the finance industry, many terms, abbreviations, and acronyms apply only in specific regions, even when countries use the same language. For example, the United States has the IRS, while Australia has the ATO; the United States refers to IRAs and retirement funds, while Australia refers to superannuation.
- Are there any regional language differences within a single country you need to consider? For example, does a drop-down list of beverages use soda or pop or another other word for a carbonated drink?
Reviewing Error Messages
Error messages must be clear and useful. We’ve all seen plenty of error messages that are neither. Good error messages tell users what went wrong—and possibly why—provide one or more solutions for fixing the error, and offer a set of buttons that relate directly to the next action a user should take. Options like OK, Continue, and Cancel are not appropriate when an error message is a question. The possible responses to a question should be Yes and No. Too many options in an error message can confuse users, so they have no idea what will happen when they click a button. When reviewing error message text, your aim is to reduce confusion.
Tip—Ask the developers on your team for your application’s resource file, which contains all of the error messages and other UI text, so you don’t have to try to create every error condition to review the message text. Without a resource file, you’re likely to miss some error messages, because you may never create the error condition that displays them.
Reviewing Link Elements
There are links in all Web applications and in some desktop applications, but not all of them are blue underlined text. Links help users navigate—both within an application and to external locations.
Navigational links include menus of all types, breadcrumb trails, links to other pages, links to Help, and even email addresses. Often links in applications display something on the same page—such as a popup dialog box, an expandable panel, or user assistance—or clickable image maps with multiple hotspots display related information. When reviewing a user interface:
- Ensure it uses similar link elements consistently. For example, if an application has a page browser, do the link elements always look the same? Or are they different like those in Figure 6?
- Review the font, color, and style of active and visited links.
- Check the behavior when users hover over links.
- Make sure the text matches the link’s action.
- Verify that links take users where they would expect to go.
