Usability Institue Logo- A bolt that can be fastened with any of 4 tools
PicoSearch
Usability Consulting, Specializing in Schools and Non-Profits
Reducing Training to Its Sensible Minimum: Zero
Home Page- List of All Content Home Page- All content, in date order Resources: page describing tools you can use Morsels: just our short articles and blurbs Just our Before&After Articles About: details on who I am and what I do Address, phone, number,  and so on
 
 
Check out these items that can help you conquer unfriendly software:
arrow Function Tree
Destined to be an industry classic, a consolidated hierarchy of all generic software function.
arrow Results Tree
I'm not settled on the name yet, but the content is incontrovertable: afford these results or vanish.
arrow GenericUI
Style sheet and hundreds of design elements for serious data applications in a browser
arrow Website Survival Checklist
33 vital signs for every website's health
arrow Computer User's
Bill of Rights

8 rules of the of user-in-yourface common sense
arrow Winning the Business Softwar
Our 46-page book, absotively free
arrow Free Usability Criteria for RFPs
Put this text right in your Requests for Proposals, no strings attached.
  Full list of resources...

Created circa 1999

User-Friendly Interface Requirements for RFPs
Free Text to Use in Your Request for Proposals (RFPs)

  What
  • Copy all of this page to use in your own requests for proposals or even design documents. The copyright on this page content is waived. You have unlimited permission to reprint this material.
  • Several items in this list were inspired by "Avoiding 'We can't change THAT!': Software Architecture & Usability," by Bonnie E. John, et al. The paper is at http://www.sei.cmu.edu/publications/documents/01.reports/01tr005/01tr005chap02.html
  Why
  • So that usability requirement don't start from a blank page and build upward on every project, which inevitably leads to forgotten items.
  • To finally deliver quality, usability, and usefulness.
  How
  • Copy it into your specs.
  • Delete the irrelevant.
  • Add the unique.
  • Consider crediting www.usabilityInstitute.com at your option. We make no stipulations whatsoever on how you must use this material or acknowledge us as its source, but if you are so inclined, we hope that by mentioning us you will speed the adoption of these rules elsewhere.
  Who
  How Much?
  • Free
  Updated
  • 2008-Jan: Minor updates
  • 2006-Jan-21 Credit noted, above in "What" section
  • 2005-Nov-7 Broke into cateogories
  • 1999 Created

Part 1, Lofty Goals

  1. Minimal Reading

    If possible, the software should be usable without reading a printed guide. If the complexity of the tasks being automated cannot feasibly be embedded into the software interface, reading a printed guide may be unavoidable. In this case, the most that any individual user should have to read for a particular role is 50 pages...short enough to read in one sitting.
    1. The system should utilize step-through (wizard) dialogs for multi-step procedures.
    2. Functionality provided by the steps in the wizards should also be directly accessible (without using the wizard).
  2. Browsability

    The interface should enable all interaction techniques and input to be discoverable and chosen from a browse-able, heirarchical structure, arranged in order of the functions the user needs to perform.

    Prior to the advent of the Web, this simply meant supplying an exhaustive menu or menu-like outline of choices, supported by dialogs with options and click-able choices. More recently, this requirement is being satisfied by multiple graphical choices, in the form of icons and segmented, click-able graphics known by various names, such as imagemaps. In either case, what this requirement specifically precludes is reliance solely on any of the following techniques: command line syntax; parameter (INI) file options not built into the interface; techniques supported only by combination keystrokes, mouse techniques, or combinations thereof; techniques requiring knowledge of special, manually entered values.
  3. Fewest Actions

    Users should be able to accomplish every task and entry with the fewest possible keystrokes. For instance, dates should not necessitate typing four digits for the year unless the context of the given field leaves considerable doubt as to which millennium might be intended. In many cases, keying in any characters at all for the year may be an unnecessary expense of the users' time.
  4. Any Order of Action

    The software should enable users to do things out of order without being penalized.
  5. Self-Evidency

    The interface and messages should make it clear why the program does what it does.
  6. Error Tolerance

    The software should enable users to make outright mistakes without losing progress or data entered to the point at which the mistake occurred. Support multiple levels of undo or cancel. An absolutely marvelous standard is set by Macromedia Fireworks which enables the user to drag a slider control back and forth over a hisory list of edits.
  7. Power Tolerance

    Most of the users' work should be retained after power interruptions.

Part 2, Facility

Facility is basically efficiency, but also encompasses all of the different things you can do, not just how fast. It corresponds to item 3, "Fewest Actions," in the Lofty Goals section above.

  1. Direct Manipulation
    1. Wherever feasible, objects can be acted upon directly rather than through independent dialogs.
    2. Drag and drop is supported for movement and copying.
  2. Multiple Invocations
  3. Provide multiple methods where applicable to invoke a given function (menu, right-click, keyboard, mouse, docked palette).
  4. Text-Based Editing

    Where applicable, in addition to the graphical (mouse, menu, dialog) interaction with the data, systems should enable text-wise (ASCII) maniuplation of the data so that macro (single-action) techniques can invoke changes across a broad set of data.
  5. All Sort Orders

    Provide access to information and objects via all common orders that could conceivably structure the objects, including but not limited to:
      1. Categorical (hierarchical by function, affinity, or conceptual/learning order)
      2. Alphabetical (by inherent identifiers or assigned keywords)
      3. Numerical
      4. Date (history)
      5. Alphabetical by every word (full-text search)
      6. Popularity
      7. Other orders include geographical, color and so on
  6. Quick Search
    1. Where applicable, a search feature should be available throughout all main windows and pages.
    2. The search function should search through all popular indexes.
    3. The search results should redisplay the search invocation features.
  7. Object Scope
    1. Objects should be able to be edited at all levels of system scope, such as system-wide, template level, document or project level.
    2. Object properties should be able to be inherited dynamically, if explicitly opted for.
    3. Object properties should be able to be inherited on demand, when chosen by the user.
    4. Object properties should be able to be copied among objects at all levels of system scope.
  8. Docking (Dialog-less) Invocation

    Repeatedly-accessed functions should be able to be clicked or invoked without repeatedly opening dialogs, such as from docked tool palettes or hotkeys.
  9. Group (Mass) Operations

    Functions and property changes should be able to be applied to multiple objects, not just one at a time.
  10. Tables
    1. All table columns should be sortable.
    2. The order of sorted columns should be indicated.
    3. Tables of more than 7 rows and more than 50% of the width of the screen should be provided with row highlighting when the mouse is rolled over the row. See http://www.alistapart.com/d/tableruler/tableruler.html for the effect.
  11. Pick List

    Recent files should be able to be re-opened by a "pick-list," that is, in a single action.
  12. Provide Features Expected of "MS Windows" Controls

    The input, display, and interaction controls should provide the convenience features typical of Windows systems:
    1. Seeking: Typing the first letter or letters in a list advances to the matching item.
    2. Field Selection: Tabbing into a field preselects the entire contents of a simple text box.
    3. Option Selection: Check boxes and radio (option) buttons should be able to be selected by clicking not just the button but also anywhere in the text labels. See Google.com>Preferences for example code.
  13. Hotkeys
    1. Where feasible, common functions should be supported by standard Windows/MS Office hotkeys:
      1. F1 for help.
      2. F5 to refresh.
      3. Control-S to save.
      4. Control-P to print.
      5. Control-X, C, V to cut, copy, paste.
      6. Control-A to select all.
      7. Control-click to extend selection/multi-select contiguous
    2. Hotkeys are described on the pertinent menus where the functions appear.

Part 3. Interaction

  1. Save by Default

    The system should save all of what the users type, by default, meaning without extra steps.
  2. Don't Overwrite

    Users should be forewarned when any work is over-written, undone, or erased.
  3. Undo
  4. Allow the user to undo their actions.

  5. Cancel
  6. Allow the user to confirm actions prior to committing to them.

  7. Resizeable Text

    Text sizes should be resizeable by the user.
  8. Error Messages
    1. Errors should be trapped at every spot where errors could occur. In other words, errors should not be grouped together, such that the message does not sufficiently narrow the cause and resolution.
    2. Error messages should describe the problem and solution in terms the user can take action on.
    3. Error message text should be selectable, to copy.

Part 4, Support

  1. Introductory Explanations
    1. Functions that are neither trivial nor obvious should display introductory explanation panels.
    2. The introductory panels should provide a check box labeled "Do not show this message again."
    3. The check box should default to unchecked.
    4. A preferences function should enable introductory messages to be reactivated individually or all at once.
  2. Embedded Information

    For infrequent tasks that require explanation, put the information right into the interface.

  3. Error Messages
    1. Errors should be trapped at every spot where errors could occur. In other words, errors should not be grouped together, such that the message does not sufficiently narrow the cause and resolution.
    2. Error messages should describe the problem and solution in terms the user can take action on.
    3. Error message text should be selectable, to copy.
  4. Sandbox

    A test database or environment should be provided to encourage user experimentation.
  5. Online Help
    1. Expert systems should provide online help...
    2. The online help should be context-sensitive to the page, window, or dialog.
    3. The online help should be in HTML pages or a help viewer application.
    4. The online help should respond to the F1 key if feasible.
    5. The online help should provide full text searching.
    6. The online help should provide a docked table of contents.

"My interest in usability arose from the pain and tears of patching the wounds of suffering interface designs with the inadequate bandages of help files and user guides." — Daniel Cohen

© 2002, UsabilityInstitute.com   All Rights Reserved    jackbellis@hotmail.com
Any and all content may be reused without prior consent if you simply acknowledge the source, UsabilityInstitute.com