Methods and Standards for User Centered Design AND User Support and Online Information/Documentation ======================================================== ON INTERFACES Issues/Problems: "There may be no best interface, and by assuming it is possible to choose the absolute best interface among alternatives, we are forcing choices instead of supporting diversity." (Whiteside et al, 1987). PROBLEMS WITH USERS USERS: - Don't care about the elegance, sophistication, or complexity of the design -- only what it can (or can't) do for them. - will do the unexpected - will fail to observe even prominently displayed information - quickly develop habits that are hard to change - can be "suspicious" of the system - sometimes fear that they will "break" the system PROBLEMS WITH DEVELOPERS DEVELOPERS: - they assume too much about users - they tend to focus on system criteria - they get attached to systems - many will never use the systems they design - they are suspicious of "soft" sciences like psychology (and sometimes with good reason) ========================== GENERAL PRINCIPLES OF USABILITY - Know your user's job - task analysis - Maximize user control - provide user profiles - provide defaults but let user adjust - Maintain consistency of the user interface - Consistency of data display - Reduce users reliance on memory - provide defaults for options - provide user help facilities - Minimize memory load - rely on recognition memory search and select commands menus - use words or mnemonics not numbers or random letters for commands - Minimize user processing time - provide instant feedback - minimize opportunity for error - apriori set acceptable computer response times - provide an escape or undo function - provide flexibility for user control of data display ========================= INTERFACE DESIGN STEPS - task analysis, with users - build a storyboard/scenario - usability test scenario, before designing - prototype interface and iterate to gradually work more interactively - build in appropriate data hooks for subjective and objective data collection - user test: naive -- experts in video protocols - analyze users' subjective feedback and objective data - redesign prototype interface to meet users' requirements and needs - iterate interface redesign more than 3 times - observe interface performance in real world - use findings to apply to another system build ========================= DESIGN STRATEGIES Iterative Design assumes that design is art and must be evaluated Formative Design incremental development with evaluation Contextual/Participative/Situated Design close interaction with users in a realistic environment ============================ COMMON MYTHS ABOUT USER INTERFACE DESIGN (Mayhew, 1994) The quality of the user interface really doesn't matter As long as designers are familiar with interface guidelines and principles, good user interfaces will be designed User interface design tasks don't arise until the detailed design phase of a software project Usability is subjective, and cannot be measured or engineered User interface design can be done right the first time, in the design phase User interface design is an implicit part of software design and development, and need not be explicitly planned and budgeted for ======================== ON USER INVOLVEMENT (Mayhew, 1994) In ALL phases of the project Both managers and end users As steering committee As design team members For structured walkthroughs As design review/sign off committee As test subjects during prototyping ====================== "Business goals for such improvements as computer systems or work systems are heavily influenced by the underlying assumptions about how people work and how organizations function." Patricia Sachs, CACM, September 1995 ================= PARTICIPATORY DESIGN Schuler and Namioka, 1993 "...represents a new approach towards computer systems design in which the people destined to use the system play a critical role in designing it." PD versus Traditional Design: It rejects the assumption that the goal of computerization is to automate the skills of human workers, instead seeing it as an attempt to give workers better tools for doing their jobs. It assumes that workers themselves are in the best position to determine how to improve their work and their work life. Viewing users as the experts and designers only as technical consultants. It views the users' perceptions of technology as being at least as important to success as fact, and their feelings about technology as at least as important as what they can do with it. It views computers and computer-based applications not in isolation, but rather in the context of a workplace; as processes rather than as products. ======================= Obstacles to User Involvement in Participatory Design Grudin in Schuler and Namioka, 1993 CHALLENGES: Motivating Developers Requires a huge commitment of members of the development team because: prototyping and testing require software support management must make the investment in resources help may be needed to initiate contacts with users the results have to be valued Identifying Appropriate Users Developers may have a market in mind, but actual users are not known until the product is bought. Difficult to reverse the desire to appeal to a broad range of people. Even with the advantage of beginning with relatively constrained user populations, within one industry or even one organization, selecting representative users could be a major challenge. User interface specialists rarely have the "big picture". Competitive importance in terms of sales and marketing may take the lead in terms of identifying potential users. Marketing and sales people consider themselves to be internal advocates for the customers. The system is modified substantially after shipment, but before the users see it. =========================== Grudin on Challenges, continued Obtaining Access to Users Making contact Getting past IS representatives and to the end users. Changing the philosophy -- move from generic improvements to individual use. There is a reluctancy from sales that developers should meet with customers. Motivating Potential Users Time away from jobs of end users The degree that end users are stakeholders -- future users of the product End users need to see personal benefit End users may feel threatened by the potential efficiency of the system Obtaining Feedback From Existing Users Can be done informally or through bug reports and design change requests. The little information that is relevant rarely gets back to developers. What is the pain of the user? Typical tradeoffs = decisions need to be made Find the Design Team With what group do users work with? Different development teams/different agendas. ============= REQUIREMENTS ANALYSIS Finding out what a user/client wants from a software system. Concerned with understanding needs. The result of requirments analysis process is: a representation of the problems of the current system a representation of the requirements of the new system functional -- specify what the system must do data requirements: specify the structure of the system and the data that must be available for processing to be successful usability requirements: specify the acceptable level of user performance and satisfaction with the system The user/client perspective is difficult to capture. How do we do this? Ethnographic field methods Contextual inquiry Understand how to make representations work Scenario-based design Task analysis Prototyping ========================= ETHNOGRAPHIC FIELD METHODS Blomberg, Giacomi, Mosher, and Swenton-Hall, 1993 Get the "natives' point-of-view" in natural and holistic settings. The ethnographer is interested in understanding human behavior. The designer is interested in designing artifacts that support human behavior. Natural settings -- everyday settings holism -- the everyday context in which things occur description -- what happens versus what ought to happen Ethnographic Study Methods: The focus is on the work, not the technology observation: how behavior is manifested. Must be unobstrusive. focus of observation: what, when, where to observe note taking video taped records as notes observations coupled with interviews: contextual inquiry interviewing: relevance/non-relevance Traditional Methods: The focus is on the technology, not the work Customer surveys usability testing focus groups field trips =================== CONTEXTUAL INQUIRY Work-of-the-work: the way people think, talk about, and structure their work. Work-of-the-tool: the way people interact with the computer system. Principles: context people speak about their work in abstractions do users know what they want? capture the on-going experience partnership the user is the expert focus managing the conversation with the user Structure of a Contextual Interview introduction ongoing work inquiry the wrap-up Taking notes: what users do what users say our interpretations disruptions that occur to the users' work aspects of tool use that support the users' work ================== Contextual inquiry, continued Interpreting the Information: work structure or work flow problems accomplishing the work problems in system use disruptions caused by the system transparency of the system aspects of work process and system use that support work ===================== MAKING REPRESENTATIONS WORK Morten Kyng, Communications of ACM, September 1995 The design process needs to be based on experience with both the work to be supported and the technical possibilities and limitations. This includes cooperation between designers and end users. The experience of end users cannot be effectively mediated by representations of systems analysts or ethnographers. End users are there to create new understandings of the work. Representations of the System and of Work: the system: representations via paper mock ups or prototypes of work: descriptions via use scenarios use scenarios: based on work situations and the emerging design ====================== Problems with Computer-based Prototypes: which aspects of the prototype are actually aspects of the computer system being designed end users have difficulties in understanding the space of possibilities and limitations for changing the system being designed, including difficulties in distinguishing the simple, the complex, and the impossible end users have similar difficulties in understanding the opportunities and limitations for changing the representation when the representation is computer-based. =============== THREE CHALLENGES OF EVALUATING REPRESENTATIONS IN PARTICIPATORY DESIGN: better understanding of moving back and forth between prototypes and the "real thing" there is a tendency to stick to the interface -- taking the mock-ups beyond the interface requires more work designers have a hard time trying the cooperative techniques of simulated future work based on use scenarios. How do use scenarios differ from other descriptions? ============== SCENARIO-BASED DESIGN John Carroll, 1995, p. 5. Contrasting The Scenario Perspective The Establishment View ============================================== concrete descriptions abstract descriptions focus on particular instances focus on generic types work driven technology driven open-ended, fragmentary complete, exhaustive informal, rough formal, rigorous envisioned outcomes specified outcomes ============== SCENARIO PERSPECTIVE ON SYSTEM DEVELOPMENT Some Roles of Scenarios Requirements Analysis: People using current technology can be directly observed to build a scenario description of the state-of-the-art and to ground a scenario analysis of what subsequent technology might be appropriate: The requirements scenarios embody the needs apparent in current work practice. User-Designer Communication The intended users of a system can contribute scenarios illustrating design issues that are important to them, specific problems or strengths in the current technology, or the kinds of situations they think they would like to experience or avoid. Design Rationale Scenarios can be a unit of analysis for developing a design rationale. Envisionment Scenarios can be a medium for working out what a system being designed should look like and do. They can be detailed via storyboards or video-based simulations or be early prototypes of the actual system. Software Design A set of user scenarios can be analyzed to identify the central problem domain objects that would required to implement those scenarios. Implementation The problem domain objects identified and defined in software design can be implemented and run as scenarios. Documentation and Training There is an unavoidable gap between the system as an artifact presented to users, and the tasks that users want to accomplish using it. This gap is bridged when documentation and training is presented within the framework of scenarios of interaction that are meaningful to users. Evaluation A system must be evaluated against the specific user tasks it is intended to support. ================ TASK ANALYSIS Gordon, 1994: A job is broken down into its subtasks and then evaluation is made on each of the subtasks at a detailed level. Sample task list of riding a mountain bike: 1. Adjust the seat height 2. Adjust the handlebar height 3. Adjust the placement of the brakes 4. Check the inflation of the tires 5. Check chain tension 6. Check break cable tension 7. Check for frame fractures 8. Inflate tires to proper degree 9. Change flat tire 10. Get on bike 11. Ride the bike on the pavement 12. Ride the bike on a dirt trail 13. Ride the bike over obstacles 14. Shift between 18 gears 15. Use breaks 16. Ride safely ========================== TYPES OF INFORMATION OBTAINED FOR TASK ANALYSIS (Gordon, 1994) CONTEXT Initiating circumstances or cues (when you do the task) Equipment, tools, or materials involved with the task Controls, and critical values Displays, and critical values Coordination, communication with others Effects or results of performing the task RELATION TO JOB Importance of the task to attainment of job goals or requirements (e.g., is task essential or optional) Frequency of task performance Average time spent performing the task Concurrent tasks Severity of consequence if task not performed correctly PSYCHOLOGICAL FACTORS Attitude toward the task (positive or negative) Importance of the task (to the worker) Difficulty of performing the task Difficulty of learning the task ===================== TAXONOMY OF GENERAL AND SPECIFIC TASK ANALYSIS METHODS (Gordon, 1994) GENERAL METHODS FOR DATA COLLECTION document and equipment analysis unstructured interviews group interviews sorting and rating questionnaires verbal protocol analysis observation task simulation with questions GENERAL METHODS FOR DATA REPRESENTATION list and outline matrix (cross-tab table) structural network hiearchical network flow chart timeline chart SPECIFIC TASK ANALYSIS METHODS/TECHNIQUES Methods Position Analysis Questionnaire (PAQ) Delphi and Focus groups controls and displays analysis hierarchical task analysis Extended Task Analysis Procedure (ETAP) The GOMS model Critical Incident Technique Functional Analysis System Technique (FAST) Activity sampling Functional flow diagrams ==================== SUMMARY OF TASK ANALYSIS STEPS Preliminary: identify the types of knowledge relevant to the job or task being analyzed. Tasks that are time-critical with multiple task-sharing will need a representation that captures the time characteristics. Develop a priority list of the types of knowledge representation most useful. Normally a task hierarchy in either list/outline or network format. This would include subtasks, their initiating conditions, and the consequences. Determine the appropriate representational formats -- flow charts for sequential information, etc. Collect data beginning with document and equipment analysis. Continue collecting data using appropriate methods -- interviews, observation, video analysis, etc. Represent data as it is collected if possible. Allows you to identify gaps and also determine the completeness of analysis. ================== LEARNING ABOUT USERS AND THEIR TASKS (SAA CUA Guidelines) Categories: Experience How much experience do they have doing their job? How much experience do they have using computers? How much experience do they have using similar user interfaces? Capabilities With what styles do they approach their work? How do they learn new systems? Motivations How will the new product affect their work routine? How will the new product affect their productivity? Desires How would they like to use the product? What kinds of features would they like to see in the product? ======================== SAMPLE INTERVIEW QUESTIONS Why? How? When? How often? What do you call that? What errors typically occur? How do you discover and correct errors? Describe exceptions to normal procedures Describe notable successes and failures What kind of problems do you face? What are your ideas for improvement? What things would like most changed? Least changed? About Interviews: Exploratory Few subjects, in depth study Subjective reports Structured or unstructured About Surveys and Questionnaires You get feedback Many subjects, broad sampling Subjective reports Highly structured About Usage Studies You get feedback Few to many subjects Objective measures Complete or selected features ========================= ===================== DESIGN BY PROTOTYPING A Prototype is a Mock-Up of a System exploratory, evolutionary, throwaway Limited capability Low-reliability Inefficient performance Prototype Design Tools produce vaporware (no real capabilities) Paper and Pencil Interactive type Design/Implementation Tools bridge the gap between design and implementation Apple HyperCard (Mac) Asymetrix Toolbook (PC Windows) NeXT Interface Builder Asymetrix Compel Some authoring systems (IBM Linkway Live) ================ Goals of Prototyping Check technical feasibility evaluate risky areas Explore new ideas clarify/communicate requirements, experimental programming Evaluate alternatives the key word is EVALUATE Limited investment contain effort, time, cost ====================== PROTOTYPING METHODS AND TOOLS Rapid prototyping Aims to collect information on requirements and the adequacy of possible designs. Emphasis is on evaluating the prototype before discarding it in favor of some other implementation Evolutionary prototyping Compromise between production and prototyping. The system can change during and after development. Helps overcome the traditional gap between specification and implementation. Incremental prototyping The system is built incrementally, one section at a time. Based on one overall design. ============================= How to Evaluate Prototypes Decide what decisions are to be made Devise measures to allow valid decisions Generate prototypes Collect evaluation data Summarize and interpret data Make design decisions ==================== USER INTERFACE TOOLKITS Unix Workstation GUIs SunView/SunTools HP New Wave OSF/Motif (Open Software Foundation) SUN/AT&T Open Look NeXTStep & Interface Builder X Windows & Xt, Xlib Macintosh Apple HyperCard Application Prototyping DOS Systems MS Windows Software Development Kit Borland C++ with libraries Asymetrix Toolbook application prototyping Visual BASIC ========================= SHORTCOMINGS OF USER INTERFACE TOOLS (Hix and Hartson, 1993) Difficult to learn and use Limited functionality Lack of portability ADVANTAGES OF USER INTERFACE TOOLS Toolkits offer libraries of code modules Usable/reusable widgets UIMSs provide runtime support mechanisms Attempts to relieve as much as the programming burden as possible Attempts to support all activities in the interface development life cycle =================== IMPORTANT QUESTIONS FOR SCREEN DESIGN - Why present this information? WHAT IS THE PURPOSE OF THE MENU OR INTERACTION STYLE? - What actions can the user take? - How can the information displayed on the screen be made compatible with the user's knowledge and skill? - Must the user rely on memory for prior information? - How often will the user do this task? SCREEN DESIGN GOALS Consistency of data display Efficient information assimilation by the user Minimal memory load on user Compatibility of data display with data entry Flexibility for user control of data display (Smith and Mosier, 1986) SCREEN DESIGN STEPS Review screen design documentation and services Identify system inputs and outputs Identify unique user requirements Describe data elements Develop transactions Develop final paper screens Define computer screens Test screens Implement screens Evaluate screens ================================= ONLINE INSTRUCTIONAL FACILITIES Advantages - Information is available whenever the computer is, no need to hunt for the right manual - No additional workspace is necessary - Electronic dissemination and updating is feasible - Rapid searching can be accomplished - Active involvement of the learner, animation and sound are possible Disadvantages - Screens are not as readable as printed materials - Screens show less than paper, smaller display and lower display rate - Requires user to learn new menus or command language - Requires use of valuable screen "real estate" and may lead to loss of work context, while increasing the burden on short-term memory ONLINE INSTRUCTION DESIGN Keep in mind the distinctions between: - Assistance with errors by experts (typos, syntax slips) - Local reminders for intermittent users (local syntax, computer and task semantics) - Online tutorial for novices (sequenced computer and task semantics) - Online demo disk (marketing tool, introduction) - Online reference manual (detailed system oriented review) Beware of confusion for novice users Prune text to make it relevant (context-sensitive) - Show users text to match their situation Quality of writing is more important factor than system design =================== USER MANUALS Product User's learning process shapes sequencing Semantics precede syntax Keep writing style clean and simple Show numerous examples and sample sessions Menu maps, transition diagrams, data structures Try advance organizers and summaries Table of contents, index, and glossary Credits, objectives, prerequisites, references Process Seek professional writers and/or copy editors Prepare user manuals before implementation Review drafts thoroughly Conduct early field and lab usability evaluations Provide a feedback mechanism Revise to reflect changes ================== ================== USER SUPPORT AND ONLINE INFORMATION (Preece, 1994) Reduce the problems, but provide functional help. minimalist instruction: (Carroll, 1992): reduce the amount of information that a learner needs to read in order to learn to use a wordprocessor. Encourages users to try things out Two Tasks of Help: primary task: what led you to use the tool secondary task: mastering enough of the tool to accomplish the primary task Contemporary Online Help Features: help messages generated by selecting a desired object (Shift + F1 key or balloon help) context sensitive help built into application system states or dialogue boxes generic help text, usually limited in length (OS/2 Master Help Index Icon) extended help screens, integration of hypertext extensive written documentation available online WHAT DO WE KNOW ABOUT HELP? (Preece, 1994) Typical users's questions focus on: goal exploration: What can I do with this program? definition and description: What is this? What is it for? task achievement: How do I do this? diagnostic: How did that happen? state identification: Where am I? Dorazio (Horton, 1990) On Help: "The goal of the HELP System should not be to teach users about a system's capabilities and functions, but rather to provide quick and immediate access to information about a specific task, command, or message. In other words, HELP should refresh or remind the memory of what it already knows." Hypertext: Englebart (1968) presented the first optional hypertext system How can we use hypertext and hypermedia to improve navigation of contextual help? ================ IMPORTANT REMINDERS IN DESIGNING SUCCESSFUL INTERFACES Mountford, 1990 Users will never do what you think they will. Watch out for the stunning demo: try it out yourself Never underestimate the power of visualization to facilitate the interface design process Never underestimate the use of early testing Do not hesitate to use informal testing methods There is no such thing as a "stupid" user There is no such thing as a "typical" user You can never iterate interface designs too much What seems obvious is often the hardest to anticipate in design Simple and elegant interface designs always take the longest time to design ===============