Design Principles and Guidelines

1. Design Principles and Guidelines Hints for good design

2. Attributes of Good UIs • Invisible • They don’t get in your way • Minimal training • Easy to learn • Good manual (perhaps online) emphasizing how users can meet their goals • Training transfers easily to practice • Error savvy • Predictable: NO SURPRISES! • Prevent the user from making errors • Easy to recover from errors • Avoid information overload

3. Attributes of Good UIs (2) • Allow people to perform their tasks well • the good UI promotes efficiency! • Flexible • Seem “intelligent” • “do the right thing” without asking; remember user patterns • People have to like it! • “It is easy to make things hard. It is hard to make things easy.” -- A. Chapanis, ‘82

4. Design Guidelines • There are helpful UI design guidelines • Design guidelines are: • a set of design rules to follow • at multiple levels of design (e.g., early & late) • obvious to users of poorly designed interfaces • easy to ignore when deadlines approach • not complete • hopefully built on psychological underpinnings and an understanding of users

5. Guidelines for Building Good UIs • Follow graphic design principles • Use standard language conventions • Minimize load on short-term memory • Design for consistency • Provide clear feedback • Prevent errors & provide error correction • Use sensible conceptual models • Let’s discuss some of these…

6. From IBM’s RealCD application Graphic Design & Color Choice • A good UI will appropriately direct the user’s attention. How? • One way: use color and layout - black button on black background is bad colour choice - shouldn’t need label to tell you this is a button

7. Use white space (vital in WWW design) Use only a few fonts & colors (5-7 colors max) Remember colour deficiency (5% of males are colour blind) A Toolbar from MS Word Graphic Design & Color Choice (2) • Keep related objects together • Appropriate alignment & spacing (readability) • Decorations can provide extra information.

8. Bad? Speak the User’s Language • Use common words, not “techno-jargon” • Use the vocabulary of the user • Refer to the user’s objects when giving feedback, e.g., “your document…”, “your graph…” • Allow full-length names in forms • Avoid spatial-linguistic conversions, which can be extremely confusing for users • pick one or the other; examples…

9. Spatial - Linguistic Examples • Placing objects on a canvas • by specifying (X, Y) coordinates • linguistic, use keyboard to enter X, Y • by relative positions to other items • spatial, use cursor/mouse • Selecting a quantity • specify a known value • linguistic, use keyboard to enter value • relative (more, less) • spatial, use dial

10. Problem? Less is More • The KISS Principle: “Keep it simple, stupid!” • Use concise language; avoid verbiage • Avoid extraneous pictures & information • fewer options and menu choices • reduce planning time • reduce manual size, etc. • avoid information overload!

11. Minimize User Memory Load • Short-term memory of people. • capacity of 7 +/- 2 items, with decay of 30 seconds to 2 minutes • Recognition is easier for us than recollection! • Use menus rather than keyed input • Prompts should provide formats for required data • Don’t require retyping of remembered info • Use pervasive, generic rules for common interactions, e.g., cut, copy, paste

12. Memory Examples • CAD example • poor: delete template 5 • better: delete resistor template. • best: delete <select resistor icon> • Error recovery message example • poor: message telling user what to type in vanishes when typing starts • better: message maintained on display. • best: automatic error recovery

13. Be Consistent • Size, color, wording, location, ordering of objects • Same command should always have same effect in different contexts. • Following convention helps • e.g., Cut/Copy/Paste • Seems easy but it’s often not followed • Useful since it allows user to generalize from their own experience

14. Inconsistency • CMS - XEDIT Editor • in one context, D10 means “down 10 lines” • in another context it means “delete 10 lines” • Current selection (CS) in graphics editor • create a new object, it becomes CS • duplicate an object, the original remains CS • Macintosh dragging file operations? • folder on same disk vs. folder on different disk • file to trashcan vs. disk to trashcan

15. Inconsistency - Example • Moving icon to file cabinet, mailbox, or trash causes icon to disappear (Xerox Star) • What to do when dragging a file icon to the printer icon? • delete the file icon (and thus the file) • the file icon disappears “into” the printer icon, from where it can be retrieved (printer icon is also a folder?) • return icon to original location

16. Lexical Consistency • Make use of “words” consistent with common (real-world) usage • Examples: • red = bad/stop, green = good/go • left arrow = less, right arrow = more • Use consistent abbreviation/capitalization rules • CONTROL, CTRL, Ctrl, Control  which is it? • Use mnemonic names rather than codes • Use devices in the same way in all states • e.g., character delete key is always the same

17. Syntactic Consistency • Error messages at same (logical) location in all situations • Give command first -- or last (e.g., after arguments to the command) • Don’t change ordering based on context! • The user will have more to remember • Menu items at same location in menu • Muscle memory helps the user here

18. Semantic Consistency • Global commands should always be available: • Help • Cancel • Undo • Operations should always be valid on all reasonable objects • if object of class “X” can be deleted, so can object of class “Y” • if it can’t be deleted, the user will want to know why.

19. Providing Feedback • Lexical • feedback on ‘words’ that are used, (the definition of a word) • Syntactic • feedback on grammar, i.e., the order in which ‘words’ are used (subject, action and object of a sentence are determined) • Semantic • feedback on the meaning of operations (the meaning of a sentence) • It is vital to provide clear, consistent, meaningful feedback to users based on their inputs • More…

20. Lexical Feedback • Legal input in the input “language” • may be keyboard-based, mouse-based, voice-based, etc. • Using the right tokens, gestures, clicks, etc. • Feedback given using • Cursor movement (e.g., valid keypresses only generate cursor movement) • Cursor image (example… ) • Keyboard echo (e.g., don’t echo illegal words) • Selection highlighting, e.g., for cut & paste or changing text style

21. Syntactic Feedback • Ensure that the sequence of “words” entered is grammatically valid • Feedback provided when the sequence is illegal • Examples… • Wrong number of arguments provided • Menu item under cursor in reverse video indicates it will execute if you release mouse button (absence of this means it will not execute)

22. Semantic Feedback • Command is understood: • it may be helpful to restate the command, e.g., by echo or by highlighting the icon in some way • Command is underway: • provide a count-down or progress bar • makes the processing appear faster (placebo)

23. Semantic Feedback (2) • Command is completed: • provide its results • prompt for next command • All three forms of semantic feedback are not always necessary • select one or more depending on the task of interest • Examples: • Progress bars not needed for short computations • Incomplete data might not be displayed

24. Feedback Placement • Put feedback where the eyes are! • Examples… • Insertion point for text • Where the screen cursor is located. • Audio output can also provide useful feedback. • sounds on error, failure, success • voice, for more detailed responses • environmental conditions may not permit audio feedback

25. Error Prevention • Preventing errors should take priority over correcting for them. Why? • Avoids “fear of failure” on the part of the user • Allows the user to work faster • Things to consider • Key placement (e.g., Apple Reset key vs Microsoft Windows key) • “distance” between commands • menu items or typed names • Suppress unavailable commands where appropriate • Confirm dangerous actions, e.g., delete files

26. Error Correction • Lexical • typing mistakes (automatic in MS Word) • Syntactic • re-specify just the parameter in error, or • restart at beginning of command (may be necessary if dependent words are used) • Semantic • cancel the operation underway • undo previous command(s)

27. Mismatch Between Designer & User Conceptual Models • Result in errors on the part of the user • Slow the user down • Result in a great deal of frustration on the part of the user • Coming up with good design models that mesh well with commonly held conceptual models is very difficult • Have to know a lot about the users requirements and typical characteristics

28. Conceptual Models DO NOT ENTER Which way would you drive?

29. Why are Design Guidelines Insufficient? • Too specific and/or too general • there may be a huge number of guidelines that are not specifically focused enough to provide useful help • A standard design might not address all the issues • Macintosh standard UI could be all dialog boxes and menus. Who is to say that this will be sufficient for the users?

30. Usability Slogans • Beware of Slogans • Always catchy, rarely useful! • Examples… • Your best guess is not good enough! • The user is always right! • The user is not always right! • Users are not designers! • Designers are not users! • Less is more! • Details matter!

31. Summary • UIs are hard to design - obviously! • Slogans do not really help • Guidelines can give us general principles to follow • Guidelines fail in that they can be hard to apply • too specific or too general • especially true for style guides

32. Thank you!