If you're an HTML/web designer working on big websites or cloud apps, modern CSS, Javascript, and Javascript libraries make projects much simpler now than they were in the 1990s - usability standards are now defaults and you can focus on building and testing the things that differentiate and inform. But maybe these checklists will inspire some new ideas, or at least entertain.
 
Portions © 1989, Apple Computer

In This Page

• Interface Checklists
• | General Considerations | Scrolling Standards |
  | Dialog-Box Standards | Alert Standards | Menu Standards |
  | Mouse Standards | Keyboard Commands | Documentation |
• Programming Strategies
• Critical Features of Great Media

 

General Considerations

• Does the application have the 'look' of the Windows Interface (including, but not limited to, desktop, windows, and menus)?
• Does the application have the 'feel' of the Windows Interface (including, but not limited to, pointing, selecting, and keyboard input)?
• If a metaphor is being used, is it suitable for the application? Does the metaphor have a 'real' visual and behavioral representation, as with the desktop, so that the users do not have to carry a 'map' in their head?
• Does the application always provide some indication that an activity is being carried out in response to a command?
• Does the user always have the option of finding an object or action on the screen? (v. memorize locations of hidden options, or keyboard shortcuts)
• Are the operations consistent with the standard elements of the interface - if a user is familiar with popular applications, will the application seem like familiar territory?
• Does a print operation send a replica of what the user sees on the screen, or is it optimized for printing?
• Is feedback provided during long task processing? Is the duration of the task indicated? Is the completion of a processing task indicated somehow?
• Is an explanation offered if a particular action cannot be carried out? Are alternatives offered?
• Are there warnings about risky actions? Are there different warnings for different levels of risky actions? (Are there enough warnings without being too many? Are users allowed to back away gracefully from risky territory?)
• Is there a feeling of stability?
• Are there enough landmarks to remind the user what area of the application he or she is in?
• Can an operation be interrupted? (Can Escape be used to cancel an operation that has a Cancel button?)

Graphic Design

• Are the graphics appropriate and believable?
• Does the screen look clean and free from clutter?
• Does the user have control over the design of the workspace, allowing him or her to individualize it?

Scrolling Standards

• Does clicking on a scroll arrow cause the document to move a distance of one unit in the chosen direction? Is it appropriate to the application?
• Is the function of the arrow keys different from the function of the scroll bar?

Dialog-Box Standards

Modal dialog boxes (a popup dialog the user must explicitly dismiss before doing anything outside it) create friction and should be used sparingly. Modeless dialog boxes let the user perform other operations without dismissing the box first.

• Is the question posed in a straightforward and positive way? (For example, 'Do you want to erase everything on this disk?' rather than 'Do you not want to alter the contents of this disk?')
• When appropriate, do buttons have descriptive labels? ('Destroy Power Supply' rather than 'OK')
• Does the default button (if any) have consistent styling? (A bold outline or color, location, etc.)
• Does pressing Escape indicate Cancel in a dialog box? (In an ideal world pressing Escape would never cause the user to lose information.)
• When a command key equivalent is used, does the button highlight?
• Do modal dialog boxes not lead to other modal dialog boxes?
• Has room been left to allow the dialog box to grow during localization? Most languages require more characters than English to convey equivalent messages.

Alert Standards

• Do the alert icon and message fit the situation?
• Is a beep alert accompanied by a flash (rapid inverting) of the menu bar so that people who can't hear don't miss the message?
• Does the alert message not only tell the user what is wrong but offer suggestions as to what to do to correct it?
• Is an alert necessary? (Could they be prevented from making the error? Example: if the application cannot handle an 80 character file name, don't offer them an 80 character field in which to enter it.)

Menu Standards

• Does the menu bar contain only menu titles?
• Are the standard menus - File, and Edit - present, with at least the standard items?
• Is there enough room for the expansion when translated into other languages?
• Do the unique menus of the application have names that are appropriate? (Are the names sufficiently different from the standard menu names? Can the user understand and remember their meaning?)
• Are frequently used menu items available at the top level rather than in a hierarchical menu or a dialog box? If not, can the user move them up with customization?
• When an item in a menu is currently or temporarily disabled, is it dimmed in the menu rather than missing from it?
• If all the items in a menu are currently disabled, is the menu title also dimmed? Can the user still pull down the menu and see the dimmed options?
• Are the names of menu items appropriate? Can the user understand and remember their meaning?
• Are menu titles and items in caps/lowercase unless there is a compelling reason to have a different style? (such as 'ALL CAPS' in a Style menu)
• Do menu items have an ellipsis (…) if more information will be required from the user?
• Do hierarchical titles in a menu have a right-pointing triangle? Are hierarchical menus used only for lists of related items?
• Can the user see all the commands, items, and hierarchical titles in a menu without scrolling? (Scrolling should be necessary only for menus that users have added to, or for menus that spill over because the user has selected a large view font)
• Is the indication of a pop-up menu a drop-shadowed box around the current value? While the menu is showing, is its title inverted and is the current value checked? If the menu must be scrolled, is this indicated? (for example, by up- or down-pointing triangles)

Mouse Standards

• If the user initiates an action by clicking the mouse or trackpad, does the action take place only when the button is released?
• Are there ways other than clicking to perform a given action? (power keys, key combinations)

Keyboard Commands

• Do keyboard equivalents appear where appropriate? Are the keyboard equivalents case-independent? (This second rule does not apply if the product uses both cases in the keyboard equivalents and enables the user to predict which case to use.)
• Does the application support Undo, Cut, Copy, and Paste?

Documentation

• Does the manual include a glossary of potentially confusing terms that relate to the application or to the application's topic?
• If the manual refers the user to another document, is the reference more appropriate than having the information in the manual itself?

• Is there a clear visual indication of the current mode? Does the visual indication of the mode appear near the object most affected by the mode? (For example, a pencil in draw mode and to a paint brush in paint mode)
• Is each mode absolutely necessary? Do the modes within the application properly track the user's own modes? Do users consistently avoid the kind of errors caused by the program being in a mode other than what the user wants or expects? (Making a mode visually apparent is no guarantee that the user will track it - test the application on users and find out what sorts of mistakes they are making. If the errors are modal, eliminate the modes.)
• Can the user save a document or quit an application at any time, unless he or she is in a modal dialog box?
• Are the widest possible range of user activities available at any time? (The user should spend most of his or her time in the event loop)
• Will a user unable to distinguish colors be able to use the application? Will someone without a color monitor, or with vision issues be able to use it? (The information conveyed by color coding should also be presented in another form, such as text, position, highlighting, gray-scale variations, or pattern)
• Will a user with a hearing disability be able to use the application? (Audible messages should be supplemented with visual cues or should allow the user to choose visible instead of audible messages, video subtitles can be provided)

• Present a Useful Idea
• Use High Quality Images and Video
  (start with best possible images, you can always throw information away with compression later)
• Pay attention to lighting and shadows
  (our eyes are fantastic at adjusting to lighting changes, much better than most cameras)
• Use close-ups rather than long shots
  (on most devices online media is small)
• When panning or tilting, slow down changes of content
• Provide Clear Navigation
  (dividers for sections more than 10 seconds, will support 'scrubbing' through a video... also links in descriptions with timestamps)
• If text is used, use large characters
  (small text will not be legible after compression for conference calls, better to avoid text in the image and superimpose graphics during playback)
• Great Sound Matters
  (Good sound can make up for poor video)

Keep in mind that you probably have no control over the systems used to present your work - Bad or small monitors, glare from open window coverings, ambient noise, remote presentations via Zoom. But you can accomodate bad conditions with bigger fonts, more contrast, and keeping big ideas in the middle of the frame.