Presentation is loading. Please wait.

Presentation is loading. Please wait.

User interface design Designing effective interfaces for software systems.

Similar presentations

Presentation on theme: "User interface design Designing effective interfaces for software systems."— Presentation transcript:

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

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

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

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

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

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 messages
P 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

Download ppt "User interface design Designing effective interfaces for software systems."

Similar presentations

Ads by Google