CS 321: Human-Computer Interaction Design Lesson Two Understanding Interaction Goal-Directed Design Contextual Design Chapters 1, 6 Chapter 2

Goal-Directed Design The Evolution of the Software Development Process PROGRAMMERS Originally, programmers did it all… Design, code, test, and ship Ship Code/Test MANAGERS PROGRAMMERS Managers brought order… Understanding the market and the competition Initiate Code/Test Ship Testing and design became separate steps… Testing in case the code needed fixing; GUI design after coding was done MANAGERS PROGRAMMERS QUALITY ASSURANCE DESIGNERS Initiate Code Ship Test GUI Design Design begins to precede the programming process… Formally defining the user and the user’s goals drives the entire development effort MANAGERS DESIGNERS PROGRAMMERS QUALITY ASSURANCE Code Bug Test Initiate Ship Design User Test USABILITY PRACTITIONERS CS 321 Lesson Two Understanding Interaction Page 17

Building Successful Software Balancing Desirability, Viability, and Technology Common Error #3 Emphasize Viability & Ignore Desirability (e.g., Microsoft) What do people desire? Of the things people desire that will sustain a business, what can we build? OBJECTIVE: A PRODUCT THAT IS DESIRABLE, VIABLE, AND BUILDABLE Common Error #1 Emphasize Technology & Ignore Desirability (e.g., Silicon Graphics) Of the things people desire, what will sustain a business? Common Error #2 Emphasize Desirability & Ignore Viability (e.g., Napster) CS 321 Lesson Two Understanding Interaction Page 18

Bridging The Research/Design Gap The Traditional Model RESEARCH Performed by market analysts and ethnographers (immersive cultural observers) DESIGN Performed by graphical interface and industrial designers The Goal-Directed Design Model RESEARCH Interview the user and observe the domain MODELING Analyze the field research, looking for patterns REQUIREMENTS Define and prioritize the needs of the user and the business FRAMEWORK Use design patterns and principles to conceptualize design REFINEMENT Clarify, revisit, validate, and, finally, document the design CS 321 Lesson Two Understanding Interaction Page 19

Contextual Design Contextual Design is a customer-centered approach to designing software within the context of how the customer works. Talk to Customers while they work Provides reliable knowledge about what customers actually do and care about Interpret the Data in a cross-functional team Creates a perspective of the data that is shared by developers and customers Consolidate Data across multiple customers Creates a single statement of work practice for your entire customer population Invent Solutions grounded in user work practices Provides a way to imagine and develop better ways to work Structure the System to support the new work practice Represents the system for planning, marketing, UI design, and specification Iterate with Customer through paper mockups Provides early verification of design before any ideas are committed to code Design the Code Structure for implementation Defines the implementation architecture and ensures support of work structure CS 321 Lesson Two Understanding Interaction Page 20

Contextual Inquiry Field Interviews Team Interpretation Sessions Uncover who the customers are and how they work on a daily basis. Field Interviews Design team members talk individually with customers in order to discover motivations and strategies. Through discussion, the interviewer and the customer develop a shared interpretation of the work. Team Interpretation Sessions The design team meets to discuss the interviews and to gain insights relevant to their design problem. By collating their different perspectives on the customers’ needs, the team members can develop a shared view. CS 321 Lesson Two Understanding Interaction Page 21

Detailed steps to accomplish tasks. Work Modeling Before designing the new software, attempt to represent the current versions of the pertinent customer tasks in diagrams. Flow Model Communication & coordination issues. Cultural Model The customer’s culture & policies. Sequence Model Detailed steps to accomplish tasks. CS 321 Lesson Two Understanding Interaction Page 22

Work Modeling: Flow Model The flow model represents the coordination, communication, interaction, roles, and responsibilities of the people involved in the work practice. By clearly identifying who is involved in the relevant tasks and how they interact, it is hoped that the development team will be able to comprehend what practices are working (and need to be preserved in the software being developed) and what practices are not working (and need to be improved or replaced). CS 321 Lesson Two Understanding Interaction Page 23

Work Modeling: Cultural Model The cultural model represents the norms, influences, and pressures that are present in the work environment. The development team needs to become familiar with the rules, procedures, traditions, customs, and attitudes that affect the work being done, in order to ensure that the new software being developed will accommodate the needs of the potential users. CS 321 Lesson Two Understanding Interaction Page 24

Work Modeling: Sequence Model The sequence model represents the steps that users currently go through to accomplish a specific task. By dissecting the step-by-step procedure currently used to perform a task, the development team tries to identify those steps that must be preserved in the new software being developed, as well as the problematic steps that need to be avoided or replaced. CS 321 Lesson Two Understanding Interaction Page 25

Consolidation Collate info from many customers to discern patterns. SUBMISSIONS CONSISTENCY SECURITY USABILITY NOTIFICATIONS Consolidated Work Models Merge the work models to reveal common strategies and individual differences. It’s sometimes unclear whether assignments have been successfully posted to student drop-boxes. Instructors are not consistent about assignment deadlines, with some permitting late assignments and some forbidding them. Having assignment grades posted on the system as soon as they’re ready is convenient, as long as it’s secure. Many icons are provided, but they’re small, often obscure, and have long delays before tool-tips appear. Instructors may input settings so graders are notified when students submit assignments. The size limit for submitted assignments sometimes makes it difficult to submit program files using databases or images. Some instructors post assignments on the system, but most still provide hard copies in class. Separate logins are not required when students shift from one course’s drop-box to another’s. Grade screens use extremely small font, allowing display of large classes without much scrolling, but damaging readability. Student may access schedule of all events (including due dates) occurring in the next two weeks for all of student’s classes. Team assignments are now permitted, but it’s confusing whether team members can overwrite each other’s submissions. Calendar arrangement of due dates is confusing, allowing instructor to list assignments above their due dates. System automatically logs out students and instructors after fifteen minutes of inactivity. Most pages include help documents explaining the purpose and usage of the fields on those pages. Instructor may post announcements to individual students, project teams, and entire classes. Student profiles list first and most recent access times, but do not log all uploads and downloads. Instructor may toggle descriptions on (making interface crowded) and off (hiding info from users). Users may post profiles that include a photo, a list of interests, and contact information. Students report increased levels of interrupted service when uploading assignment files from off campus. Calendar of upcoming assignments may be displayed for one class or for all classes. Students may use drop-box to submit early assignments, but must notify instructor by e-mail of having done so. Instructors may retrieve logs of every participant’s access to their account for a particular class. Affinity Diagram Chart a hierarchical diagram (often wall-sized) to reveal the scope of the problem across all customers. CS 321 Lesson Two Understanding Interaction Page 26

Work Redesign Example: Mozilla’s Firefox Envision how customers will perform their tasks with new software. Example: Mozilla’s Firefox Addressing common complaints about Web browsers, Firefox has designed several new features. Download Manager Enables downloads to be paused and resumed Live Bookmarks Provide dynamic news updates Awesome Bar Bases searches on “frecency”, a mixture of frequent and how recent the search was CS 321 Lesson Two Understanding Interaction Page 27

User Environment Design Establish a “blueprint” for the user interface design. Itemize each design component, its purpose and functionality, and how it will fit into the overall navigation of the system. Explicitly state how each design component may be rolled out over a series of releases. Articulate a coherent design structure that will enable the design team to counterbalance later “incoherent” forces, like ease of implementation and delivery schedule. CS 321 Lesson Two Understanding Interaction Page 28

Low-Fidelity Prototyping Develop a dynamic “wireframe” prototype for the interface. Working dynamically with the user to determine what might and might not work, the design team can quickly eliminate most of the remaining misconceptions that the team has about the tasks that the software system will handle. CS 321 Lesson Two Understanding Interaction Page 29

Prioritization & Design Modularize the design by breaking it into coherent delivery units, and decide which units may be implemented in parallel and which must be implemented in sequence. This is often the point at which “high fidelity” prototypes are implemented, with all major screen components and test case scenarios that demonstrate actual user interactions. CS 321 Lesson Two Understanding Interaction Page 30