UsabilityGuidelines

Intended as a helpful guideline for the design of graphical user interface applications, here is a brief collection of frequently emphasised design rules and good practice methods derived from user-testing experiences and human-perception analysis:

Arrangement of Input and Output Fields

  • Fields should be logically grouped.
  • Input fields should be arranged in the order they are to be processed in.
  • Fields should be separated by extra spacing (e.g. for table columns).
  • Field lists should be aligned to emphasise enumeration character.
  • Input fields should be clearly visually different from output fields.
  • Labels should be positioned left to input fields or form a caption in case of tables.
  • Fields should include dimension units where appropriate.
  • Fields not suitable for input should block input attempts.
  • Input fields should use pre-filling with default values or last-recently-used values.
  • Inactive field elements should be blocked from user input and use visual indication of their blocked state.

Tables

  • Columns and rows in tables should be properly separated, e.g. contrasted by vertical and horizontal lines.
  • Column and row titles in table should be clearly distinguishable from table cells.
  • Table row and column titles should be kept visible throughout table navigation (scrolling).

Presentation of Text

  • Text should be structured into paragraphs of approximately 4-6 lines.
  • Blocks of text should be separated by empty lines.
  • The amount of characters per line should be roughly limited to 50-60.
  • Texts presented to the user should be orthographically correct.
  • Messages adressing the user should be worded politely, users react better to politely worded phrases than to neutral ones.
  • Word spacing should be homogeneous. That is, left-aligned text is to be preferred over block-aligned text.
  • Important items should be emphasised.
  • Graphics should be placed next to the relevant text portions.
  • Markup should be used consistently across an application.

Colors, Composition and Arrangements

  • The human eye can only focus one wavelength at a time.
  • For two objects, one red and one blue, at the same distance of the eye, only one can be seen sharply at a time.
  • Blue objects apear to be farther away than red objects (for similar objects).
  • Pristine blue should not be used for text, thin lines and small objects.
  • Adjoint colors should differ in more wavelengths than just blue (e.g. cyan and green are a bad choice for adjoint colors).
  • Older people need higher brightness to tell colors apart.
  • Red and green should be avoided in the border area of large graphics (due to the arrangement of uvulas in the eye).
  • For colorblind people, two different colors should differ in more than one base color.
  • Too many color and font changes can overstress perception capacity (people can tell roughly 5-7 objects apart at first sight).
  • Logical object groupings should be reflected by similar background colors.
  • Similar colors should signal similar semantics.
  • Luminance and saturation are good means to attract attention.
  • Cold colors (short wavelength: violet, blue, cyan) are most suited for status information.
  • Warm colors (long wavelength: red, orange, yellow) are most suited for alerts and prompts.
  • Colors should be sorted by temperature or wavelength (red, orange, yellow, green, cyan, blue, indigo, violett).

Names and Abbreviations

  • Labelling constraints (e.g. for naming objects or files) should be reduced to a minimum. System imposed constraints should be circumvented by applications.
  • Abbreviations should be avoided if at all possible, to spare users the extra mental step of expanding them. If used however, abbreviation rules should be consistent, and an index of abbreviations used should be provided. Good practice to generate abbreviations includes:
    • use of natural abbreviations of the language (e.g. Mr., Ms.),
    • omit vowels (action -> actn, control -> cntrl),
    • abbreviate to leading syllables (information -> info, documentation -> docu).

Preventing and Handling of User Errors

Provisions should be taken, to avoid erroneous activation of user interface elements:

  • Critical elements should be surrounded by safety margins.
  • User interface elements should labelled unmistakably.
  • Provide memorable signals, audible or visual in emergency situations. However, such signals should not be overused, as users tend to ignore them if they get flooded by signals.
  • Erroneous inputs should be detected and signalled as early as possible.
  • Erroneous places should be marked and reported. Enough context should to be provided, so that only the erroneous parts have to be edited/reentered.

Menus

  • Menus shouldn't be deeper than 2-3 levels.
  • Flat menu structures should be preferred over deep ones.
  • For novice users, no more than 7 different items should be presented.
  • Advanced users usually can handle around 15-20 items per menu.
  • To support memorisation, menus should be consistently structured where possible, for example conceptually, by activation frequency or alphabetically.
  • Because people learn by spatial location, menus should not be restructured (hiding or moving menu items) in applications.
  • Unselectable menu items should be blocked from user input and use visual indication of their blocked state.
  • Menu items should support mnemonics to allow faster activation.
  • Frequency controlled split menu techniques can accelerate navigation (see article about the pros and cons of Adaptive Menu Design).

Dialogs

  • Allow undocking (split up into separate windows) of packed up dialogs (e.g. notebook pages) to allow simultaneous view and control of multiple objects.
  • Different dialog types should be visually distinct but use consistent identification.
  • Multi stage input actions should allow abortion at every stage, e.g.:
    1. Select action.
    2. Provide parameters.
    3. Confirm action or abort.
  • Dialogs relating to interface elements (help/tips/errors) should not cover up the interface element they relate to.
  • All dialogs should be resizable for the benefit of visually impaired people, in particular if they contain (partially) covered text portions or scrollable areas.

Files and Documents

  • Documents should be automatically saved to minimise impact of data loss due to application errors or user input.
  • File or document display should indicate access restrictions (e.g. the inability to read or delete a file).
  • Saving documents/files should allow the user to specify access restrictions (may (not) be read by others).

Providing Feedback

  • Feedback should be provided to the user about active program operations. Examples for feedback are:
    • icon animations - these are easy to understand to indicate progress,
    • progress-bars - using progress-bars providing an estimate about completion time is recommendable.
  • Window and text cursors should be adapted according to application modes.
  • Despite progress indication, operations with long durations should not block the user interface or other parts of the application if possible.
  • Messages of a program, presented to the user should avoid colorization

Colorization should generally be avoided. Users may be color blind or using hardware which displays items of different colors in non-intended ways. Also, different colors maybe interpreted differently by individuals so colors don't convey clear and unambiguous information. It is preferable to restructure content representation than to try to encode information by colorization.

Configuration and Adaption

As users get used to an application and gain experience, they develop desires to automate specific actions and to optimise familiar tasks. This involves input (such as activating the same set of operations from a menu repeatedly) and output operations (such as reading texts, and looking up information). As a consequence, both classes of usage are subject to individualisation/adaption demands.

  • Applications should offer configuration abilities for users to adjust colors, text markup and positioning of elements.
  • Enable configurability of key strokes, mouse buttons and other input device settings.
  • Provide input alternatives where possible (e.g. allow activation via keyboard and mouse).
  • Text constants like field labels should be adaptable to user needs in a special adaption mode.
  • Focus indication should be configurable to enable user-specific adaptions (colorization, intrusiveness).
  • Decimal number displays, currency, unit and time displays should be adaptable.
  • Input field pre-filling behaviour (last-recently-used vs. default values) should be configurable.
  • Menus should be adaptable according to user experience, i.e. allow items to be relabeled, inserted, reordered or removed.
  • Tooltip display should be configurable (on/off/timeout).
  • Time intervals of auto-save functionality should be configurable and eventually include purging/backup options.
  • All configuration options of an application should be available from one central place, to allow comprehensive control over the configuration state (application behaviour).

Miscellaneous

  • Output layout should match across devices (adhere to the WYSIWYG principle).
  • Facilities should be provided to save complete sessions, including opened documents, cursor positions, field pre-fills etc.
  • All operations should be undo-able (preferably with unlimited history), including undo (redo).
  • Focus display should be clearly noticeable, but non-disturbing (avoid too intensive colors or intensive blinking).
  • Input elements should be accompanied by descriptive tooltips.
  • Context help for all interface elements should be available.

Optimizing code for GUI events

While UI responsibility is in general important to maintain, it is not an excuse for over optimization of GUI code. In general there is plenty of time available for computers to handle GUI events, most modern computers can execute more than a million instructions per millisecond, and GUI events need to be handled much less frequently, e.g. consider:

  • The human eye/brain combination can not distinguish more than 16 different images per second, that translates into a good 60 msecs processing time per frame (WikiPedia:Movie_projector).
  • The speed of sound is about 344 m/s, that means ca. 1.5 msecs for a mouse click sound to reach the ear.

Usability Checklist (taken from the Usability Toolkit)

  1. Visibility of System Status:
    The system should always keep the user informed about what is going on, through appropriate feedback within reasonable time.
  2. Match Between System and the Real World:
    The system should speak the user's language, with words, phrases and concepts familiar to the user, rather than system-oriented terms. Follow real-world conventions, making information appear in a natural and logical order.
  3. User Control and Freedom:
    Users should be free to select and sequence tasks (when appropriate), rather than having the system do this for them. Users often choose system functions by mistake and will need a clearly marked "emergency exit" to leave the unwanted state without having to go through an extended dialog. Users should make their own decisions (with clear information) regarding the costs of exiting current work. The system should support undo and redo.
  4. Consistency and Standards:
    Users should not have to wonder whether different words, situations, or actions mean the same thing. Follow platform conventions.
  5. Help Users Recognize, Diagnose, and Recover From Errors:
    Error messages should be expressed in plain language (NO CODES).
  6. Error Prevention:
    Even better than good error messages is a careful design which prevents a problem from occurring in the first place.
  7. Fexibility and Minimalist Design:
    Accelerators-unseen by the novice user-may often speed up the interaction for the expert user such that the system can cater to both inexperienced and experienced users. Allow users to tailor frequent actions. Provide alternative means of access and operation for users who differ from the "average" user (e.g., physical or cognitive ability, culture, language, etc.)
  8. Aesthetic and Minimalist Design:
    Dialogs should not contain information which is irrelevant or rarely needed. Every extra unit of information in a dialog competes with the relevant units of information and diminishes their relative visibility.
  9. Help and Documentation:
    Even though it is better if the system can be used without documentation, it may be necessary to provide help and documentation. Any such information should be easy to search, focused on the user's task, list concrete steps to be carried out, and not be too large.
  10. Skills (and anticipation of user action):
    The system should support, extend, supplement, or enhance the user's skills, background knowledge, and expertise ----not replace them.
  11. Pleasurable and Respectful Interaction with the User:
    The user's interactions with the system should enhance the quality of her or his work-life. The user should be treated with respect. The design should be aesthetically pleasing- with artistic as well as functional value.

References to related or originating materials:


BackLinks · PageInfo · Pages like this · last changed on Wed Aug 15 05:28:33 2007