A look into the world

The essay goes on to describe in detail the different strategies for answering these questions, and shows how each of these questions requires a different sort of help interface in order for the user to be able to adequately phrase the question to the application.

• 
  Set up the observation. Design realistic tasks for the users, and then recruit end-users that have the same experience level as users of your product (Avoid recruiting users who are familiar with your product however).
  
• 
  Describe to the user the purpose of the observation. Let them know that you're testing the product, not them, and that they can quit at any time. Make sure that they understand if anything bad happens, it's not their fault, and that it's helping you to find problems.
  
• 
  Talk about and demonstrate the equipment in the room.
  
• 
  Explain how to "think aloud". Ask them to verbalize what they are thinking about as they use the product, and let them know you'll remind them to do so if they forget.
  
• 
  Explain that you will not provide help.
  
• 
  Describe the tasks and introduce the product.
  
• 
  Ask if there are any questions before you start; then begin the observation.
  
• 
  Conclude the observation. Tell them what you found out and answer any of their questions.
  
• 
  Use the results.
  

User testing can occur at any time during the project, however, it's often more efficient to build a mock-up or prototype of the application and test that before building the real program. It's much easier to deal with a design defect before it's implemented than after. Tognazzini suggests that you need no more than three people per design iteration -- any more than that and you are just confirming problems already found.

One must be true to one's vision. A product built entirely from customer feedback is doomed to mediocrity, because what users want most are the features that they cannot anticipate.

Some things designers should keep in mind about their users:

• 
  certain aspects of an interface should behave in consistent ways at all times for all screens
  
• 
  terminology should be consistent between screens
  
• 
  icons should be consistent between screens
  
• 
  colors should be consistent between screens of similar function
  

• 
  break complex tasks into simpler tasks
  
• 
  break long sequences into separate steps
  
• 
  keep tasks easy by using icons, words etc.
  
• 
  use icons/objects that are familiar to the user
  

• 
  organize information into a small number of "chunks"
  
• 
  try to create short linear sequences of tasks
  
• 
  don't flash important information onto the screen for brief time periods
  
• 
  organize data fields to match user expectations, or to organize user input (e.g. auto formatting phone numbers)
  
• 
  provide cues/navigation aids for the user to know where they are in the software or at what stage they are in an operation
  
• 
  provide reminders, or warnings as appropriate
  
• 
  provide ongoing feedback on what is and/or just has happened
  
• 
  let users recognize rather than recall information
  
• 
  minimize working memory loads by limiting the length of sequences and quantity of information - avoid icon mania!
  

• 
  minimize mental transformations of information (e.g. using 'control+shift+esc+8' to indent a paragraph)
  
• 
  use meaningful icons/letters
  
• 
  use appropriate visual cues, such as direction arrows
  
• 
  use 'real-world' metaphors whenever possible (e.g. desktop metaphor, folder metaphor, trash can metaphor etc.)
  

• 
  provide informative feedback at the appropriate points
  
• 
  provide appropriate articulatory feedback - feedback that confirms the physical operation you just did (e.g. typed 'help' and 'help' appear on the screen). This includes all forms of feedback, such as auditory feedback (e.g. system beeps, mouse click, key clicks etc.)
  
• 
  provide appropriate semantic feedback - feedback that confirms the intention of an action (e.g. highlighting an item being chosen from a list)
  
• 
  provide appropriate status indicators to show the user the progress with a lengthy operation (e.g. the copy bar when copying files, an hour glass icon when a process is being executed etc.)
  

• 
  provide user-centered wording in messages (e.g. "there was a problem in copying the file to your disk" rather than "execution error 159")
  
• 
  avoid ambiguous messages (e.g. hit 'any' key to continue - there is no 'any' key and there's no need to hit a key, reword to say 'press the return key to continue)
  
• 
  avoid using threatening or alarming messages (e.g. fatal error, run aborted, kill job, catastrophic error)
  
• 
  use specific, constructive words in error messages (e.g. avoid general messages such as 'invalid entry' and use specifics such as 'please enter your name')
  
• 
  make the system 'take the blame' for errors (e.g. "illegal command" versus "unrecognized command")
  

• 
  don't anthropomorphize (i.e. don't attribute human characteristics to objects) - avoid the "Have a nice day" messages from your computer
  

• 
  use modes cautiously - a mode is an interface state where what the user does has different actions than in other states (e.g. changing the shape of the cursor can indicate whether the user is in an editing mode or a browsing mode)
  
• 
  minimize preemptive modes, especially irreversible preemptive modes - a preemptive mode is one where the user must complete one task before proceeding to the next. In a preemptive mode other software functions are inaccessible (e.g. file save dialog boxes)
  
• 
  make user actions easily reversible - use 'undo' commands, but use these sparingly
  
• 
  allow escape routes from operations
  

• 
  use attention grabbing techniques cautiously (e.g. avoid overusing 'blinks' on web pages, flashing messages, 'you have mail', bold colors etc.)
  
• 
  don't use more than 4 different font sizes per screen
  
• 
  use serif or sans serif fonts appropriately as the visual task situation demands
  
• 
  don't use all uppercase letters - use and uppercase/lowercase mix
  
• 
  don't overuse audio or video
  
• 
  use colors appropriately and make use of expectations (e.g. don't have an OK button colored red! use green for OK, yellow for 'caution, and red for 'danger' or 'stop')
  
• 
  don't use more than 4 different colors on a screen
  
• 
  don't use blue for text (hard to read), blue is a good background color
  
• 
  don't put red text on a blue background
  
• 
  use high contrast color combinations
  
• 
  use colors consistently
  
• 
  use only 2 levels of intensity on a single screen
  
• 
  Use underlining, bold, inverse video or other markers sparingly
  
• 
  on text screens don't use more than 3 fonts on a single screen
  

• 
  maintain display inertia - make sure the screen changes little from one screen to the next within a functional task situation
  
• 
  organize screen complexity
  
• 
  eliminate unnecessary information
  
• 
  use concise, unambiguous wording for instructions and messages
  
• 
  use easy to recognize icons
  
• 
  use a balanced screen layout - don't put too much information at the top of the screen - try to balance information in each screen quadrant
  
• 
  use plenty of 'white space' around text blocks - use at least 50% white space for text screens
  
• 
  group information logically
  
• 
  structure the information rather than just presenting a narrative format (comprehension can be 40% faster for a structured format)
  

• 
  accommodate individual differences in user experience (from the novice to the computer literate)
  
• 
  accommodate user preferences by allowing some degree of customization of screen layout, appearance, icons etc.
  
• 
  allow alternative forms for commands (e.g. key combinations through menu selections)
  

Web page design

Download speed is a critical aspect of web page design. Remember that when you check your pages locally in your browser you aren't experiencing normal web delays! Regardless of your modem speed, pages will only download at the fastest rate of the slowest link in the 'chain' from a server to the browser. The following tips will help to speed downloads and aid comprehension of your web page materials:

• 
  avoid using 'blinks' unless these are absolutely necessary - blinks are distracting, use fonts, sizes, colors to attract attention
  
• 
  keep backgrounds simple and muted
  
• 
  minimize audio and video use, this really slows download time
  
• 
  use animated files (e.g. animated .GIFs) sparingly
  
• 
  use thumbnail .GIFs linked to larger .GIFs
  
• 
  specify .GIF size (HEIGHT, WIDTH) - this speeds download times
  
• 
  use 'ALTs' for .GIFs where only the .GIF provides the link - this provides linked text information to those only browsing in text mode
  
• 
  use image maps sparingly - they are slow and can be annoying - using an invisible table can often give similar results with much faster downloads
  
• 
  use frames sparingly and consistently - use absolute widths for frames, scroll bars, avoid menus for small numbers of items, also check that users don't get stuck in a frame
  
• 
  avoid 'construction signs' - web pages are meant to be dynamic and therefore should be changed/updated regularly - they are always under construction - try to tell users when content was last changed and what changes were made
  
• 
  minimize use of Java, Javascript, Applets (e.g. ticker tape status bars) - they are cute but often provide little useful information content and slow downloads
  
• 
  remember that 50% of users have monitors 15" or less and at 640 x 480 resolution, so use a maximum window width of 620 pixels or flexible window widths and test your pages in your browser at low screen resolutions and limited colors (256 or less)
  
• 
  provide contact information at the home page location in your site
  

General principles to follow when designing any programme.