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

17. 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

18. 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

19. 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

20. 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

21. 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

22. 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

23. 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

24. 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

25. 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

26. 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 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

27. 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

28. 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

29. 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

30. 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