1. User interface design
Designing effective interfaces for software systems

2. Objectives
To suggest some general design principles for user interface design
To explain different interaction styles
To introduce styles of information presentation
To describe the user support which should be built-in to user interfaces
To introduce usability attributes and system approaches to system evaluation
<SKIP>

3. Topics covered 15.1 User interface design principles
15.2 User interaction
15.3 Information presentation
15.4 User support
15.5 Interface evaluation
<SKIP>

4. The user interface
System users often judge a system by its interface rather than its functionality
A poorly designed interface can cause a user to make catastrophic errors
Poor user interface design is the reason why so many software systems are never used
Software engineers generally must do interface design
… in some big organizations, human factors experts may help. In smaller organizations, they are not available

5. Importance of User Interface
“Most important part of any computer system”
“Interface is the system for most users”
Increasingly important
GUIs a big improvement over previous approaches
Platforms (e.g. Mac/ Microsoft) have style guides
50% of code devoted to interface
Interface should “disappear” – users can focus on their task, not the interface
Biggest enemy of good interface design is time
… what people interact with – issue directions and see results (other code hidden)
… if users can focus on their job, they can do a better job – worth $$$$
poor design can cost $$$ - employee mistakes, turnover
… “Designing an object to be simple and clear takes at least twice as long as the usual way. It requires concentration at the outset on how a clear and simple system would work, followed by the steps required to make it come out that way – steps that are often much harder and more complex than the ordinary ones. …” – T.H. Nelson 1977
These are words that are not very welcome in today’s “compressed development cycles”, but words that should be heard, especially by people such as yourself who plan to manage these development cycles. Fortunately, some technological things that have happened since the quote (1977) help to speed parts of the process (e.g. rapid prototyping)
Galitz

6. Benefits of Good Design
Small improvements can be worth big $$$
Book e.g. if users work 1 sec slower on each of 4.8 million screens per year, need almost an extra person
Book e.g.s Redesigns have improved productivity 20%, 25%, 40%, 50% …
IBM - $1 invested in usability returns $10-$100
Interface problems are treated as bugs
Pressman - $1 fix during design, $10 fix during development, $100 fix after release
Big Improvements can establish new products, companies, markets …
the browser was a UI idea – before it, search using gopher etc was tedious.
AOL was successful because it was more user friendly than early leader CompuServe.
(I don’t know the base number of users)
… led to the creation of Netscape company. Likewise, the search engine created vast efficiencies – and produced multiple companies.
… In WWW era, was an alternative philosophy, instead of making search easy, produce content to avoid search
Galitz

7. Graphical user interfaces
Most users of business systems interact with these systems through graphical interfaces although, in some cases, legacy text-based interfaces are still used

8. GUI characteristics Windows Icons Menus Pointing Graphics
What makes an interface a GUI? …
Windows – multiple windows allow different info to be displayed simultaneously on the users screen
Icons – represent different types of info - can represent files, or can represent processes
Menus – actions/ commands are selected from a menu (list of choices on screen) rather than typed in a command language
Pointing - A pointing device such as a mouse is used for selecting choices from a menu or indicating items of interest in a window
Graphics - Graphical elements can be mixed with text on the same display.

9. GUI advantages They are easy to learn and use.
The user may switch quickly from one task to another and can interact with several different applications.
Fast, full-screen interaction is possible with immediate access to anywhere on the screen
Users now expect GUIs
They are easy to learn and use.
Users without experience can learn to use the system quickly.
The user may switch quickly from one task to another and can interact with several different applications.
Information remains visible in its own window when attention is switched.
Fast, full-screen interaction is possible with immediate access to anywhere on the screen

10. User-centred design
The aim of this chapter is to sensitise software engineers to key issues underlying the design rather than the implementation of user interfaces
User-centred design is an approach to UI design where the needs of the user are paramount and where the user is involved in the design process
UI design always involves the development of prototype interfaces
hard to give feedback without seeing it. May start with Paper mockup and move to prototype

11. User interface design process
Start with analysis – watch users work (ethnography), interview them, analyze the tasks that they do (task analysis)

12. 15.1 UI design principles
UI design must take account of the needs, experience and capabilities of the system users
Designers should be aware of people’s physical and mental limitations (e.g. limited short-term memory) and should recognise that people make mistakes
UI design principles underlie interface designs although not all principles are applicable to all designs

13. User interface design principles
Description
User Familiarity
Interface should use terms familiar to users
Consistency
Comparable operations should be started the same way
Minimal Surprise
Users should never be surprised
Recoverability
Users should be able to recover from their errors
User Guidance
Meaningful feedback, context-sensitive help
User Diversity
Should provide for different types of user
User Familiarity - Interface should use terms and concepts familiar to users – taken from the experience of the people who will make most use of the system. The interface should be based on user-oriented terms and concepts rather than computer concepts. For example, an office system should use concepts such as letters, documents, folders etc. rather than directories, file identifiers, etc.
Consistency – … Commands and menus should have the same format throughout the system, command punctuation should be similar, etc. Key short cuts should be consistent across the system
Minimal surprise –
Recoverability – There should be ways for user to recover from their mistakes (such as undo) Also, seek confirmation of actions that are potentially destructive
User Guidance –
User Diversity – different interaction facilities for different types of system user – casual vs power users; disabilities – visual, hearing

14. Design principles User familiarity Consistency Minimal surprise
The interface should be based on user-oriented terms and concepts rather than computer concepts. For example, an office system should use concepts such as letters, documents, folders etc. rather than directories, file identifiers, etc.
Consistency
The system should display an appropriate level of consistency. Commands and menus should have the same format, command punctuation should be similar, etc.
Minimal surprise
If a command operates in a known way, the user should be able to predict the operation of comparable commands
<SKIP>

15. Design principles Recoverability User guidance User diversity
The system should provide some resilience to user errors and allow the user to recover from errors. This might include an undo facility, confirmation of destructive actions, 'soft' deletes, etc.
User guidance
Some user guidance such as help systems, on-line manuals, etc. should be supplied
User diversity
Interaction facilities for different types of user should be supported. For example, some users have seeing difficulties and so larger text should be available
<SKIP>

16. Nielsen’s Ten Usability Heuristics
Visibility of system status
Match between system and the real world
User control and freedom
Consistency and standards
Error prevention
Recognition rather than recall
Flexibility and efficiency of use
Aesthetic and minimalist design
Help users recognize, diagnose, and recover from errors
Help and documentation
<Below – direct quote from Nielsen’s WWW page>
Ten Usability Heuristics
Visibility of system status
The system should always keep users informed about what is going on, through appropriate feedback within reasonable time.
Match between system and the real world
The system should speak the users' 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.
User control and freedom
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 dialogue. Support undo and redo.
Consistency and standards
Users should not have to wonder whether different words, situations, or actions mean the same thing. Follow platform conventions.
Error prevention
Even better than good error messages is a careful design which prevents a problem from occurring in the first place.
Recognition rather than recall
Make objects, actions, and options visible. The user should not have to remember information from one part of the dialogue to another. Instructions for use of the system should be visible or easily retrievable whenever appropriate.
Flexibility and efficiency of use
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.
Aesthetic and minimalist design
Dialogues should not contain information which is irrelevant or rarely needed. Every extra unit of information in a dialogue competes with the relevant units of information and diminishes their relative visibility.
Help users recognize, diagnose, and recover from errors
Error messages should be expressed in plain language (no codes), precisely indicate the problem, and constructively suggest a solution.
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.
Could use Shneidermans guidelines and principles – don’t want something with 1000 items
Nielsen

17. Galitz’s Heuristics (Table 14.2)
Automate unwanted workload
Reduce uncertainty
Fuse data
Present new info with meaningful aid to interpretation
Use names that are conceptually related to functions
Group data in consistently meaningful ways to reduce search time
Limit data-driven tasks
Include in displays only info needed by user at a given time
Provide multiple coding of data where appropriate
Practice judicious redundancy
From Gerhardt-Powals (1996)
… free cognitive resources for higher level tasks. Eliminate mental calculations, estimations, comparisons, and unnecessary thinking (have computer do anything computers are better at)
… display data in a way that is clear and obvious
… reduce cognitive load by bringing together lower level data into higher level summation <same as #1?>
… use a familiar framework, making it easier to absorb. Use everyday terms, metaphors, etc
… context dependent, attempt to improve recall and recognition …
… reduce the time needed to assimilate raw data. Make appropriate use of color and graphics
… allow users to remain focused on critical data. Exclude extraneous info that is not relevant to current tasks
… to resolve conflicts between #6 and #8
Galitz

18. Galitz’s WWW Heuristics
Speak the user’s language
Be consistent
Minimize the user’s memory load
Build flexible and efficient systems
Design aesthetic and minimalist systems
Use chunking
Provide progressive levels of detail
Give navigational feedback
Don’t lie to the user
From Levi and Conrad (1996) – i think this is more “operational” than the previous
… use familiar words, phrases and concepts. Present info in a logical and natural order
… indicate similar concepts thru identical terminology and graphics. Adhere to uniform conventions for layout, formatting, typeface, labeling etc
… take advantage of recognition rather than recall. Do not force users to remember key info across documents
… accommodate a range of user sophistication and diverse user goals. Provide instructions where useful. Lay out screens so that frequently accessed info is easily found.
… create visually pleasing displays. Eliminate info that is irrelevant or distracting
… write materials so that documents are short and contain only one topic. Do not force the user to access multiple documents to complete a single thought <this is chunking???>
… organize information hierarchically, with more general info appearing before more specific detail. Encourage user to delve as deeply as needed, but to stop whenever sufficient info has been obtained
… facilitate jumping between related topics. Allow the user to determine his/her current position in the document structure. Make it easy to return to an initial state.
… eliminate erroneous or misleading links. Do not refer to missing info.
Galitz

19. 15.2 User-system interaction
Two problems must be addressed in interactive systems design
How should information from the user be provided to the computer system?
How should information from the computer system be presented to the user?
User interaction and information presentation may be integrated through a coherent framework such as a user interface metaphor

20. Interaction styles Direct manipulation Menu selection Form fill-in
Command language
Natural language
Direct manipulation – user interacts directly with objects on the screen – e.g. dragging a file to the trashcan
Menu selection -
Form fill-in – user fills in fields of a form
Command language – user types in a command in specialized syntax (as in DOS)
Natural language – user issues command in human language – such as English
Each has advantages and disadvantages, situations where they are useful and those where they are not.
Frequently they are mixed together in one system

21. Direct manipulation advantages
Users feel in control of the computer and are less likely to be intimidated by it
Fast and intuitive interaction
User learning time is relatively short
Users get immediate feedback on their actions so mistakes can be quickly detected and corrected

22. Direct manipulation problems
The creation of an appropriate information space model (metaphor) for real world tasks and objects can be very difficult
Given that users have a large information space, what facilities for navigating around that space should be provided?
Direct manipulation interfaces can be complex to program and make heavy demands on the computer system

23. Direct Manipulation Applications
Games
CAD systems
Files and Folders

24. Control panel interface
<SKIP>

25. Menu systems
Users make a selection from a list of possibilities presented to them by the system
The selection may be made by pointing and clicking with a mouse, using cursor keys or by typing the name of the selection
May make use of simple-to-use terminals such as touchscreens

26. Advantages of menu systems
Users need not remember command names as they are always presented with a list of valid commands
Typing effort is minimal
User errors are trapped by the interface
Context-dependent help can be provided. The user’s context is indicated by the current menu selection

27. Problems with menu systems
Actions which involve logical conjunction (and) or disjunction (or) are awkward to represent
Menu systems are best suited to presenting a small number of choices. If there are many choices, some menu structuring facility must be used
Experienced users find menus slower than command language

28. Menu System Applications
Most general purpose systems

29. Form-based interface

30. Forms-based Systems Advantages
Simple data entry
Easy to learn

31. Forms-based Systems Disadvantages
Takes up a lot of screen space

32. Forms-based Systems Applications
Most systems involving significant data entry

33. Command interfaces
User types commands to give instructions to the system e.g. UNIX, DOS
Advantages:
Powerful and flexible – good for experts
Easy to process using compiler techniques
Commands of arbitrary complexity can be created by command combination
Concise interfaces requiring minimal typing can be created

34. Problems with command interfaces
Users have to learn and remember a command language. Command interfaces are therefore unsuitable for occasional users
Users make errors in command. An error detection and recovery system is required
System interaction is through a keyboard so typing ability is required

35. Command languages
Often preferred by experienced users because they allow for faster interaction with the system
Not suitable for casual or inexperienced users
May be provided as an alternative to menu commands (keyboard shortcuts). In some cases, a command language interface and a menu-based interface are supported at the same time

36. Natural language interfaces
The user types a command in a natural language. Generally, the vocabulary is limited and these systems are confined to specific application domains (e.g. timetable enquiries)
NL processing technology is now good enough to make these interfaces effective for casual users but experienced users find that they require too much typing

37. Multiple user interfaces
<SKIP>

38. 15.3 Information presentation
Information presentation is concerned with presenting system information to system users
The information may be presented directly (e.g. text in a word processor) or may be transformed in some way for presentation (e.g. in some graphical form)
The Model-View-Controller approach is a way of supporting multiple presentations of data
… data is in the model. Presentation is provided via a view (there may be multiple views). Controller handles user input and device interaction

39. Information presentation
Keeping software responsible for presenting info separate from rest of system allows the presentation to the user to be changed without impacting the main processing system
Also aids in supporting multiple presentations of the same data

40. Model-view-controller
<SKIP – not much here>

41. Information presentation
Static information
Initialised at the beginning of a session. It does not change during the session
May be either numeric or textual
Dynamic information
Changes during a session and the changes must be communicated to the system user

42. Information display factors
Is the user interested in precise information or data relationships?
How quickly do information values change? Must the change be indicated immediately?
Must the user take some action in response to a change?
Does the user need to interact with the displayed info via a direct manipulation interface?
Is the information textual or numeric? Are relative values important?
What info to display how must be decided based on info needs of users, their background, and the way they use the system. Some issues …
textual presentation takes up less space, and is more precise, but takes longer to process (especially looking for trends, or relative to other data)
changing values should be highlighted if they are important and must be reacted to

43. Alternative information presentations
Graphs good for detecting trends and/or abnormalities

44. Analogue vs. digital presentation
Compact - takes up little screen space
Precise values can be communicated
Analogue presentation
Easier to get an 'at a glance' impression of a value
Possible to show relative values
Easier to see exceptional data values

45. Dynamic information display

46. Displaying relative values
Here we see some context – where the values stand in terms of their min and max values

47. Textual highlighting
GUI capabilities can be used to draw attention to info that is purely textual in nature
(you guys knew that)

48. Data visualisation
Concerned with techniques for displaying large amounts of information
Visualisation can reveal relationships between entities and trends in the data
Possible data visualisations are:
Weather information collected from a number of sources
The state of a telephone network as a linked set of nodes
Chemical plant visualised by showing pressures and temperatures in a linked set of tanks and pipes
A model of a molecule displayed in 3 dimensions
Web pages displayed as a hyperbolic tree

49. Colour displays
Colour adds an extra dimension to an interface and can help the user understand complex information structures
Can be used to highlight exceptional events
Common mistakes in the use of colour in interface design include over-use of colour in the display

50. Colour use guidelines Don't use too many colours
Use colour coding to support user tasks
Allow users to control colour coding
Design for monochrome then add colour
Use colour coding consistently
Avoid colour pairings which clash
Use colour change to show status change
Be aware that colour displays are usually lower resolution
be conservative – no more than 4 or 5 colors in one screen, no more than 7 in entire interface. Use it selectively
… e.g. in Visual Studio, colors distinguish key words, comments – supports avoiding misspelling of keywords, avoiding using keywords as variable, avoiding mis-begun or mis-ended comments. Another e.g. – if managers will be looking for anomalous instances, highlight those with a different color
… allow them to change coding
… don’t vary meanings of color from screen to screen, users will get confused. (if RED means error msg, red should ALWAYS mean error msg). Some user groups will have expectations about color meaning e.g. – for finance – show losses in Red.
e.g. red and blue together not that good for visibility. White on blue is good
… color changes can attract attention – use them to attract attention – when something significant has happened (e.g. temperature too high in a chemical processing plant – change to RED). (Don’t use color changes when don’t need user attention – because you will get it)

51. 15.4 User support
User guidance covers all system facilities to support users including on-line help, error messages, manuals etc.
The user guidance system should be integrated with the user interface to help users when they need information about the system or when they make some kind of error
The help and message system should, if possible, be integrated

52. Help and message system
<SKIP>

53. Error messages
Error message design is critically important. Poor error messages can mean that a user rejects rather than accepts a system
Messages should be polite, concise, consistent and constructive
The background and experience of users should be the determining factor in message design

54. Design factors in message wording
<SKIP>

55. Design factors in message wording
Context
Experience
Skill Level
Style
Culture
Here messages include error messages and help
Context – the user guidance system should be aware of what the user is doing and should adjust the output message to the current context.
Experience – beginners have trouble with terse statements of problem. But more advanced users don’t want to spend the time to read long messages – give option of verbosity of msgs
Skill Level – express in ways familiar to user (Visual C++ messages designed for people who know the whole language)
Style – be positive. Use active, not passive. Don’t be insulting or funny
Culture – be aware of culture where system is to be used re: msgs

56. Nurse input of a patient’s name
<SKIP>

57. System and user-oriented error messages
System-oriented error message ?
Err
or #27 In v
alid patient id entered OK
Cancel
Bad msg - negative, doesn’t tie in to users experience, users system-specific terms (rather than user-oriented) does not give advice on what to do

58. user-oriented error messagesP
atient J .
Bates is not registered
Clic
k on P
atients f
or a list of registered patients
Clic
k on Retr
y to re-input a patient name
Clic
k on Help f
or more inf or
mation P
atients
Help
Retr y
Cancel
Good Message – more positive (not blaming), uses nurse’s terms, suggests how to handle (unreadable here – click on Patients for list of registered patients, click on retry to re-input name, click on help for more info), makes help available. “is not registered” comes from taking into account the context

59. Help system design Help? means ‘help I want information”
Help! means “HELP. I'm in trouble”
Both of these requirements have to be taken into account in help system design
Different facilities in the help system may be required

60. Help information Should not simply be an on-line manual
Screens or windows don't map well onto paper pages.
The dynamic characteristics of the display can improve information presentation.
People are not as good at reading screen as they are paper text.
Content should be prepared with help of application specialists
Content should not be too large – don’t overwhelm user
… people read paper and screens in different ways
… people who know the application so can refer to things using users’ vocabulary

61. Help system use
Multiple entry points should be provided so that the user can get into the help system from different places.
Some indication of where the user is positioned in the help system is valuable.
Facilities should be provided to allow the user to navigate and traverse the help system.
Index, TOC, and Search should be provided
e.g. back button, possibly a way to go directly back to any help already visited, button to get to index of topics, perhaps to go to next topic

62. Entry points to a help system
(help info is usually organized into some form of hierarchy with cross-links – may enter at top on general entry – but at different points if asked for help concerning an error message or part of the system (context sensitive help)

63. Help system windows Useful to show where user is within help,
to have buttons for navigation, to to be able to go directly to previous topics

64. Help on WWW Easy to implement Easy for users to use
Difficult to link to applications themselves
users may need to make extra effort to get to help
Help doesn’t know context where you needed help – cannot provide context sensitive help

65. 5.4.3 User documentation
As well as on-line information, paper documentation should be supplied with a system
Documentation should be designed for a range of users from inexperienced to experienced
As well as manuals, other easy-to-use documentation such as a quick reference card may be provided
documentation may include more detailed info

66. User document types At Least 5 important kinds of documentation
Functional description
Brief description of what the system can do
Introductory manual
Presents an informal introduction to the system, describing normal usage. How to get started, how system can be used , how to recover from mistakes. Lots of examples.
System reference manual
Describes all system facilities in detail – and error messages (and what to do)
System installation manual
Describes how to install the system, and system requirements (how much disk space needed etc)
System administrator’s manual
Describes how to manage the system when it is in use

67. Document types Functional description Introductory manual
Brief description of what the system can do
Introductory manual
Presents an informal introduction to the system
System reference manual
Describes all system facilities in detail
System installation manual
Describes how to install the system
System administrator’s manual
Describes how to manage the system when it is in use
<SKIP>

68. 15.5 User interface evaluation
Some evaluation of a user interface design should be carried out to assess its suitability
Full scale evaluation is very expensive and impractical for most systems
Ideally, an interface should be evaluated against a usability specification. However, it is rare for such specifications to be produced
… involving cognitive scientists and graphic designers, experiments with groups of users

69. Usability attributes
Also – how easy is it to use after it has been learned? Preferable if use quantitative metrics – but sometimes that is hard

70. Things to Test Galitz Conformance with a requirement
Conformance with guidelines for good design
Identification of design problems
Ease of system learning
Retention of learning over time
Speed of task completion
Speed of need fulfillment
Error rates
Subjective user satisfaction
Tests are usually formal – with measurable criteria
Galitz

71. …System - User Interface Design Goals
5 human factors central to community evaluation:
Time to learn
Speed of performance
Rate of errors by users
Retention over time
Subjective satisfaction
Trade-offs sometimes necessary
Test all design alternatives using mock-ups
5 human factors central to community evaluation:
Time to learn How long does it take for typical members of the community to learn relevant task?
Speed of performance How long does it take to perform relevant benchmarks? (distinct from #1 and sometimes forgotten)
Rate of errors by users How many and what kinds of errors are commonly made during typical applications?
Retention over time How well do users retain their knowledge of how to use the product over short or long periods of time? Frequency of use and ease of learning help make for better user retention
Subjective satisfaction How did users like using the system? (subjective) Allow for user feedback via interviews, free-form comments and satisfaction scales.
Trade-offs sometimes necessary e.g. learning time vs performance time, complex several-key shortcuts can be slow to learn but can speed performance over going through several menus. Managers and developers should be aware of trade-offs being made and make them explicitly and document them
Test all design alternatives using a wide range of mock-ups – paper (can do many), interactive (can do a few)
Galitz

72. Objective Measures of Usability
Effectiveness
Speed of performance, # errors (against some standard)
Tasks completeable by required pct of target users
Learnable
Time to learn, amount of training and tech support needed (against some standard)
Relearning time for intermittent users
Flexible
Subjective satisfaction
Tiredness, discomfort, frustration, effort required, willingness/eagerness to use system
Important for these to be measurable – and to have a target standard to compare to, otherwise you will not know if you have succeeded
… allow some variation in tasks beyond that first specified <????> p59
Galitz

73. Simple evaluation techniques
Questionnaires for user feedback
Video recording of system use and subsequent tape evaluation.
Observation of users at work with system and “thinking aloud” about how they are trying to use system
Instrumentation of code to collect information about facility use and user errors.
The provision of a gripe button for on-line user feedback.
More feasible to do than full-scale usability evaluation
… questionnaires should ask focused, specific questions – at least some should be close-ended. Some questions should get at background and experience – to tell if particular groups of users have problems
… expensive to do well (cameras on screen and on user), but can get at things such as whether users had to move eyes around too much or move hands from keyboard to mouse and vice versa too frequently
… what are the most common operations? Where are errors most commonly made?

74. Kinds of Tests Galitz Guidelines review
Heuristic evaluation (will be covered last due to extensive coverage)
Cognitive walkthrough
Think aloud evaluations
Usability test
Classic experiments
Focus groups
… review against organization’s standards and design guidelines
… detailed evaluation of system by interface design specialists to identify problems
… reviews of the interface in the context of tasks users perform
… users perform specific tasks while thinking aloud
… users perform specific tasks under real-world or controlled conditions. Measures of performance are taken
… an objective comparison of two or more prototypes identical in all aspects except for one design issue
… a discussion with users about interface design prototypes or tasks
Galitz

75. Elements of Discount Usability Engineering
Scenarios
Simplified Thinking Aloud
Heuristic Evaluation
… each basically already discussed – task scenarios, simplified talking aloud while doing tasks on paper prototypes
Nielsen

76. Scenarios
Take prototyping to extreme – reduce functionality AND number of features
Small, can afford to change frequently
Get quick and frequent feedback from users
Compatible with interface design methods
… can even be paper mock-ups (as discussed earlier) …
… scenarios may have been developed as part of design process, so don’t represent additional effort required for testing
Nielsen

77. Simplified Thinking Aloud
Bring in some users, give them tasks, have them think out loud
Fewer users in user testing
… w/o videotape, detailed protocol analysis (analysis of subjects statements down to a detailed level), psychologists, labs. Nielsen says that CS people can be trained to apply thinking aloud observation to get useful results
… learn the most from the first few users – 3-5
Nielsen

78. Heuristic Evaluation Nielsen Context – part of iterative design
Goal – find usability problems
Who – small set of evaluators
How – study interface in detail, compare to small set of principles
… preferably knowledgeable about usability.
… the principles are the heuristics – rules of thumb
Nielsen

79. How to Conduct a Heuristic Evaluation
More than one evaluator to be effective.
Each evaluator inspects the interface by themselves
General heuristics may be supplemented
Results can be oral or written
Evaluator spends 1-2 hours with interface
Evaluator goes through interface > 1 time
Evaluators may follow typical usage scenarios
Interface can be paper
… Different evaluators will find different usability problems. By having 3-5 evaluators, should get good coverage, without too much expense and without getting a lot of repetition of the same problems (see next slide).
… only after all evaluators have done their work can evaluators talk to other evaluators or see what they came up with – to ensure independence and avoid bias – so new problems will be found by new evaluators
… w/ specific heuristics for the kind of product that it is (its domain)
… oral – have observer writing down the evaluator’s comments – then coalescing after all evaluators. Advantage – results may be available sooner. Written – evaluator must write their own report, then somebody has to create coalesced summary
… break into multiple sessions if big complex system requiring more time
Different experts tend to find different problems in an interface, so 3-5 expert reviewers can be highly productive, as can complementary usability testing.
… first get an overall feel for interface and scope of system. Second evaluate each interface element w/r/t heuristics
… going through steps user would follow to accomplish different tasks – drawn from task analysis – and chosen as important/common tasks
… Does not have to be a working prototype – this makes it possible to evaluate very early
Nielsen

80. Key points
Interface design should be user-centred. An interface should be logical and consistent and help users recover from errors
Interaction styles include direct manipulation, menu systems form fill-in, command languages and natural language
Graphical displays should be used to present trends and approximate values. Digital displays when precision is required
Colour should be used sparingly and consistently
<SKIP>

81. Key points
Systems should provide on-line help. This should include “help, I’m in trouble” and “help, I want information”
Error messages should be positive rather than negative.
A range of different types of user documents should be provided
Ideally, a user interface should be evaluated against a usability specification
<SKIP>

82. Norman’s Four Principles of Good Design
State and the action alternatives should be visible
Should be a good conceptual model with a consistent system image
Interface should include good mappings that reveal the relationships between stages
User should receive continuous feedback
Norman’s Four principles of good design
(system) State and the action alternatives should be visible
Should be a good conceptual model with a consistent system image (recognizable metaphor for the world)
Interface should include good mappings that reveal the relationships between stages (???)
User should receive continuous feedback

83. Galitz’s Principles of User Interface Design
To follow … alphabetically (following book)

84. Aesthetically Pleasing
Meaningful contrast between screen elements
Create groupings
Align screen elements and groups
Provide 3 dimensional representation
Use color and graphics effectively and simply
Visual appeal increases user satisfaction, and makes users more productive
… meaningful – differences should reflect differences, otherwise users will be looking for differences (if I made each of these bullets a different color, most of you would spend at least a few seconds figuring out if the color differences meant anything)

85. Clarity Visual elements Functions Metaphors Words and text
… identifiable, recognizable
… must be understandable to users and realistic, simple. Must be consistently reflected in the design
… simple, unambiguous, in users language (not techies). Same word should mean same thing. Same function should be described with same word (e.g. not Save one place, Store another)

86. Compatible With the user With the task and job
With the product (past systems)
.. Adopt the users perspective (“Know the user”). Start by understanding the user and their needs. Recognize the diversity of users – experience with computers, with the system, frequency of use, cultural background, age, gender, education, physical abilities, training, motivation, goals, personality
… understand the tasks that will be done, so you can make them easy (so the interface “disappears”) – make natural flow match natural way of performing job tasks
When not necessary to change something, compatibility with past eases the learning curve, speeds acceptance of the system (e.g. keep terminology if it is not a problem)

87. Comprehensibility User should easily be able to determine:
What to look at
What to do
When to do it
Where to do it
Why to do it
How to do it

88. Configurability Users should be able to set preferences
Good Default Settings should be provided for non-tinkerers
… gives users a sense of control, makes them more effective, helps deal with different experience/skill levels, increases user satisfaction

89. Consistency One of Shneiderman’s 8 golden rules for interface design
Similar components should
Have similar look
Operate similarly
Same action should always produce the same result
Function of elements should not change
Position of standard elements should not change
Same terminology used for same thing throughout
Standards and Guidelines increase the odds of consistency
… “most frequently violated golden rule”. Probably because it requires developers to be organized and systematic, both as individuals and as a group. Meaningless differences lead users to look for the meaning of the difference. Galitz – consistency speeds learning because what is learned one place can be transferred.
“One study found that user thinking time nearly doubled when position of screen elements was varied on a series of menus” – NOTE to Microsoft and learning menus in Windows
… color, layout, capitalization, fonts
… Apple had them. Microsoft has them. IBM, Sun, X-windows (motif). W3C has them for WWW

90. Control User should control the interaction
Actions initiated by user
Actions performed quickly
Actions can be interrupted or stopped, and reversed
Context maintained is from the user’s perspective
More than one way to do things
Avoid modes
Configurable
… #7 on Shneiderman’s 8 golden rules. Ties to other principles. “Simple, predictable, consistent, flexible, customizable, and passive interfaces provide control”
… as opposed to non-event-driven systems of old in which the system was in control and asked users for responses as the program needed them. But, also, not having the system all of sudden popping up with its own agenda … why the paper clip bugs a lot of people (but auto-correction of spelling is ok!!)
… lack of response makes user feel not in control
… reversability is another of Shneiderman’s 8 golden rules
… e.g. menus, toolbar, function key, keyboard shortcut in many Microsoft products – “The means to achieve goals should be flexible and compatible with the user’s skills, experiences, habits, and preferences”
… e.g. insert / overwrite mode. They restrict the actions available to a user at a given time – give them less control (can be confusing too)

91. Directness Provide Direct Manipulation
user selects an object, then directly performs an action on it
The effect of action on an object should be immediately visible
Available alternatives reduces memory load
(reducing memory load is another of Shneideman’s 8 golden rules)

92. Efficiency Minimize eye and hand movements
Make user actions flow from one to another
Don’t switch users frequently from keyboard to mouse
Anticipate users wants and needs whenever possible
… any movements take time. Any wasted movements (movements that could have been avoided with better design) slow the user. Accumulated over many users over many times adds up to big $$$
… e.g. let people happy on the keyboard stay on the keyboard …
… don’t make them search for what they need. Provide it in a logical order

93. Familiarity Use language and concepts familiar to the user
Keep the interface natural
Use real world metaphors
… their language, not yours
… interface should mimic users thought process (silly e.g. you wouldn’t ask for address in an unnatural order (city, zip, address, state)
… as already discussed

94. Flexibility
compatible with the user’s “skills, experience, habits, and preferences, and current conditions”
Danger: more flexibility increases complexity of system
Flexibility is related to control – as discussed – more than one way to do things, configurable
… affecting learning curve and costs of development. Can be good to hide flexibility from novices (“Progressive disclosure”). NOTE: Transitionality

95. Forgiveness Prevent errors from occurring when possible
Tolerate and forgive common and unavoidable human errors
When an error occurs, provide constructive error messages
Protect against catastrophic errors
… validation … or not even let the error happen in the first place (e.g. drop down list, with direct manipulation, sometimes can’t do invalid things). One of Shneiderman’s golden rules
… Permit easy reversal of actions (a golden rule) … allows users to learn by experimenting without fear
… tell what went wrong (without blaming), how to recover, how to avoid in the future
… ask user before allowing potentially disastrous actions (“Do you want to Save before quitting?”). Plus things like DB backup and recovery

96. Predictability User should be able to anticipate the flow of the task
Expectations should be fulfilled
… e.g. in a wizard, show what step of total # steps you are on
… actions should do what the user expects them to do.”Provide cues to the result of the action to be performed”. (van der Linden’s “Principle of Least Astonishment”). Aided by consistency.

97. Recovery System should permit: Users should never lose work due to:
Commands or actions to be abolished or reversed
Immediate return to a certain point if difficulties arise
Users should never lose work due to:
An error on their part
Hardware, software, or communication problems
… as discussed previously
… e.g. reset settings to defaults; BACK on wizards
… at least make it hard for them to do (do you really want to delete *.* ?)
… any program should have recovery procedures

98. Responsiveness Respond rapidly to user requests
Provide acknowledgement of user actions
Beginners need more / more informative feedback than experts do
… if process will take some time, give progress indicator (otherwise user may believe system has crashed)
… oops – Unix, dos command line – no comment means it went ok – messed up beginners. … Acknowledgement could be visual/graphical (cursor change), text, or sound (careful for accessibility)
… Shneiderman golden Rule #3 “Offer Informative feedback”

99. Simplicity Provide as simple an interface as possible
Progressive disclosure
Defaults
Minimize screen alignment points
Make common actions simple
Provide consistency
… not complex …
… hide things until they are needed. Common and necessary functions presented first, made more prominent. Hide more sophisticated, less frequently used functions. “Training Wheels”
… allows novices to do simple, common things without making any choices
… reduces “visual complexity” – easier to read/ skim / scan
… less common actions can be more complex because they are needed less often by fewer people
…consistent interfaces are simpler

100. Transparency Allow user to focus on the task, not the interface
Basic principle of direct manipulation
Use user’s task vocabulary
Design interface based on task analysis
… never force the user to think about what is happening in the computer /software

101. Trade-offs Final Design will always represent a series of trade-offs
People’s requirements always take precedence over technical requirements
… one principle against another. One requirement against another. A principle or requirement against time or cost. Cannot create a perfect system.
… easier for developers shouldn’t win out of better for the users if you want the program to be used