Engineering and design students are often required to evaluate their products against user requirements, but frequently, these requirements are abstracted from the user or context of use rather than coming from actual user and context data. Abstraction of user requirements makes it difficult for students to empathize with the eventual user of the product or system they are designing. In previous research, Design Heuristics have been shown to encourage exploration of design solutions spaces at the initial stages of design processes. This study combines use of Design Heuristics in an engineering classroom context with a method designed to connect students with an understanding the context of the user, product use setting, and sociocultural milieu. We adapted an existing method, the cognitive walkthrough, for use in an engineering education context, renaming it the empathic walkthrough. In this study, this method was revised and extended to maximize empathy with the end user and context, using these insights to promote a more situated form of idea development using the Design Heuristics cards. We present several case studies of students using this method to expand their notion of situated use, demonstrating how this method may have utility for importation into engineering contexts. Our early testing has indicated that this method stimulates empathy on the part of the student for the design context within which they are working, resulting in a richer narrative that foregrounds problems that a user might encounter.
Intze Overhead Water Tank Design by Working Stress - IS Method.pdf
Idea Generation Through Empathy: Reimagining the "Cognitive Walkthrough"
1. COLIN M. GRAY
1
, SEDA YILMAZ
1
, SHANNA R. DALY
2
,
COLLEEN M. SEIFERT
2
, & RICHARD GONZALEZ
2
1 Iowa State University; 2 University of Michigan
IDEA
GENERATION
THROUGH
EMPATHY
REIMAGINING THE “COGNITIVE WALKTHROUGH”
3. HUMAN-CENTERED
COMPETENCIES
[Zowghi & Paryani, 2003; Mohedas et al., 2014; Lande &
Leifer, 2010; Walther et al., 2012; Strobel et al., 2013]
limited examples of methods to
systematically encourage the
development of empathy
5. the cognitive knowing of what
another person is feeling
the emotional feeling what another
individual is feeling
the act of responding to another’s
experience with compassion
[Levenson and Ruef, 1992; Walther et al. 2012]
EMPATHY
6. COGNITIVE WALKTHROUGH
CHI 2000 • 1-6 APRIL 2000 Papers
1. Define inputs to the walkthrough
a. Identification of users
b. Sample tasks for evaluation
c. Action sequences for completing the tasks
d. Description or implementation of interface
2. Convene the walkthrough
a. Describe the goals of the walkthrough
b. Describe what will be done during the CW
c. Describe what will not be done during the
walkthrough
d. Explicitly defuse defensiveness
e. Post ground rules in a visible place
f. Assign roles
g. Appeal for submission to leadership
3. Walkthrough the action sequences for each task
a. Tell a credible story for these two questions:
- Will the user know what to do at this step?
- If the user does the right thing, will they know
that they did the right thing, and are making progress
towards their goal?
b. Maintain control of the CW, enforce the ground
rules
4. Record critical information
a. Possible learnability problems
b. Design ideas
c. Design gaps
d. Problems in the Task Analysis
5. Revise the interface to fix the problems
DETAILED DESCRIPTION OF THE STREAMLINED
WALKTHROUGH PROCEDURE
1. Define inputs to walkthrough
Before the CW session, the usability professional is
responsible for defining the important user task scenario or
scenarios and producing a task analysis of those scenarios
by explicating the action sequences necessary for
accomplishing the tasks in the scenarios. Wharton et al.
should be used as a resource for determining how to decide
on the scenarios and how to describe the task sequence.
2. Convene the walkthrough
The first step is to describe the goals of performing the
walkthrough. Namely, the walkthrough is an opportunity to
evaluate the user interface in terms of learnability. This is
the first opportunity to address SC 3 - Design
defensiveness, by defusing defensiveness on the part of any
team members. It is important that the usability professional
points out that learnability is only one aspect of usability,
and that the team recognizes that learnability may have
been traded off for other aspects of usability. Nonetheless,
there is inherent value in knowing when users may
encounter problems learning an interface as the issue could
be explicitly addressed elsewhere, for example, though
marketing or the help system.
A CW session is analytical in nature, and therefore lacks the
definitiveness of an empirical usability tests. In light of the
CW method's tentative nature, specification owners may
resent absolute proclamations that "this is a problem". The
usability specialist should, therefore, take care to use softer
language, like "this is a potential problem, we need to think
about it". Constant reference to the tentative nature of the
finding should help defuse defensiveness.
The usability professional then points out for the first time
that the CW is an evaluation session, not a design session,
and goes on to describe the process of walking through the
task sequence and answering the two questions for each
step (See table 4). The usability professional then gives an
example of an action sequence from software not currently
under consideration and that has plausible answers to the
two questions, and the team is encouraged to produce those
answers. Then the usability professional gives another
example, one without plausible answers, and the team is
prompted to try to provide answers. For each example, the
usability professional should model the format that the data
is captured in before proceeding with preparing the team for
the CW.
Table 4
2 questions from the streamlined CW
1. Will the user know what to do at this step?
2. If the user does the right thing, will they know that they
did the right thing, and are making progress towards their
goal?
After describing what the team will do during the
walkthrough, describe what the team will not do during the
walkthrough. This is the first opportunity to directly address
SC 2 - Lengthy design discussions, and indirectly address
SC 3 - Design defensiveness. In particular, the usability
professional explains that if the team finds a step with
possible learnability issues, they will note the possible
problem and move on to the next step, but they won't
redesign the interface. Furthermore, the usability
professional should explain that if the team encounters a
gap in the design (for example when it is not clear from the
specification what action sequence the user is supposed to
perform), the team will note the gap and move on, but they
won't stop and design the missing actions. Also, if a design
idea is suggested, the team may briefly discuss the design
idea, note it, and then move on, but the team will not flesh it
out. Lastly, if the task analysis appears to be faulty, or only
describes one of multiple possible paths towards achieving
355
[Spencer, 2000 from Wharton et al., 1994]
7. COGNITIVE WALKTHROUGH
CHI 2000 • 1-6 APRIL 2000 Papers
1. Define inputs to the walkthrough
a. Identification of users
b. Sample tasks for evaluation
c. Action sequences for completing the tasks
d. Description or implementation of interface
2. Convene the walkthrough
a. Describe the goals of the walkthrough
b. Describe what will be done during the CW
c. Describe what will not be done during the
walkthrough
d. Explicitly defuse defensiveness
e. Post ground rules in a visible place
f. Assign roles
g. Appeal for submission to leadership
3. Walkthrough the action sequences for each task
a. Tell a credible story for these two questions:
- Will the user know what to do at this step?
- If the user does the right thing, will they know
that they did the right thing, and are making progress
towards their goal?
b. Maintain control of the CW, enforce the ground
rules
4. Record critical information
a. Possible learnability problems
b. Design ideas
c. Design gaps
d. Problems in the Task Analysis
5. Revise the interface to fix the problems
DETAILED DESCRIPTION OF THE STREAMLINED
WALKTHROUGH PROCEDURE
1. Define inputs to walkthrough
Before the CW session, the usability professional is
responsible for defining the important user task scenario or
scenarios and producing a task analysis of those scenarios
by explicating the action sequences necessary for
accomplishing the tasks in the scenarios. Wharton et al.
should be used as a resource for determining how to decide
on the scenarios and how to describe the task sequence.
2. Convene the walkthrough
The first step is to describe the goals of performing the
walkthrough. Namely, the walkthrough is an opportunity to
evaluate the user interface in terms of learnability. This is
the first opportunity to address SC 3 - Design
defensiveness, by defusing defensiveness on the part of any
team members. It is important that the usability professional
points out that learnability is only one aspect of usability,
and that the team recognizes that learnability may have
been traded off for other aspects of usability. Nonetheless,
there is inherent value in knowing when users may
encounter problems learning an interface as the issue could
be explicitly addressed elsewhere, for example, though
marketing or the help system.
A CW session is analytical in nature, and therefore lacks the
definitiveness of an empirical usability tests. In light of the
CW method's tentative nature, specification owners may
resent absolute proclamations that "this is a problem". The
usability specialist should, therefore, take care to use softer
language, like "this is a potential problem, we need to think
about it". Constant reference to the tentative nature of the
finding should help defuse defensiveness.
The usability professional then points out for the first time
that the CW is an evaluation session, not a design session,
and goes on to describe the process of walking through the
task sequence and answering the two questions for each
step (See table 4). The usability professional then gives an
example of an action sequence from software not currently
under consideration and that has plausible answers to the
two questions, and the team is encouraged to produce those
answers. Then the usability professional gives another
example, one without plausible answers, and the team is
prompted to try to provide answers. For each example, the
usability professional should model the format that the data
is captured in before proceeding with preparing the team for
the CW.
Table 4
2 questions from the streamlined CW
1. Will the user know what to do at this step?
2. If the user does the right thing, will they know that they
did the right thing, and are making progress towards their
goal?
After describing what the team will do during the
walkthrough, describe what the team will not do during the
walkthrough. This is the first opportunity to directly address
SC 2 - Lengthy design discussions, and indirectly address
SC 3 - Design defensiveness. In particular, the usability
professional explains that if the team finds a step with
possible learnability issues, they will note the possible
problem and move on to the next step, but they won't
redesign the interface. Furthermore, the usability
professional should explain that if the team encounters a
gap in the design (for example when it is not clear from the
specification what action sequence the user is supposed to
perform), the team will note the gap and move on, but they
won't stop and design the missing actions. Also, if a design
idea is suggested, the team may briefly discuss the design
idea, note it, and then move on, but the team will not flesh it
out. Lastly, if the task analysis appears to be faulty, or only
describes one of multiple possible paths towards achieving
355
[Spencer, 2000 from Wharton et al., 1994]
1. Define inputs to the
walkthrough
2. Convene the walkthrough
3. Walkthrough the action
sequences for each task
4. Record critical information
5. Revise the interface to fix the
problems
9. DESIGN HEURISTICS
• Provide prompts to help designers generate alternatives that vary in
nature, discouraging fixation and encouraging divergent patterns of
thinking [Yilmaz, Daly, Seifert, & Gonzalez, 2011; Yilmaz, Seifert, & Gonzalez, 2010]
• Derived from empirical evidence of industrial and engineering
designs [Daly et al., 2012; Yilmaz, Christian, Daly, Seifert, & Gonzalez, 2012; Yilmaz & Seifert, 2010]
• Validated through a range of product analysis, case studies, and
protocol analyses, in both educational and professional contexts
[e.g., Yilmaz & Seifert, 2009; Yilmaz et al., 2011; Yilmaz et al., 2010; Yilmaz et al., 2013; Yilmaz, Daly,
Christian, Seifert, & Gonzalez, 2014]
10. Property Definition Design Heuristics cards
Form Form of the product
#32: Expand or collapse
#38: Impose hierarchy on functions
#55: Repurpose packaging
Function Functions embedded in the product
#5: Adjust function through movement
#16: Bend
#50: Provide sensory feedback
Temporal
Use/function of the product over time
Relation to sociocultural environment
#13: Apply existing mechanism in new way
#21: Change product lifetime
#46: Mimic natural mechanisms
Use/User
Situated use of the product
User interactions with the product
#9: Allow user to customize
#10: Allow user to rearrange
#40: Incorporate user input
System
Context in which the product is used
Systems/services the product relies on
#24: Contextualize
#28: Create service
#29: Create system
HEURISTICS BY CATEGORY
12. EMPATHIC
WALKTHROUGH
1
Define inputs to the
walkthrough
Identification of users, problem definition, and
concept sketch
2
Convene the
walkthrough
Paired students
3
Walkthrough the
action sequences
for each task
Role-play or “talk through” each other’s concept
with a user story
4
Record critical
information
Record parts of the design that are confusing or
strange, that don’t appear to work correctly, or
otherwise seem inappropriate for the user
5
Revise the interface
to fix the problems
Generate alternatives or additional concepts that
address user concerns
25. DISCUSSION
• Even without prompting or explicit training, all participants were
able to tell a credible user story
• Students were generally not able to exhaust their ideas in the
10-15 minute period provided
• Design Heuristics were primarily used when the students got
“stuck” on a piece of critical information
• Categorization of critical information was generative, promoting
conversation about concerns or issues
26. SO WHAT ABOUT EMPATHY?
• Our goal was to foster an empathic connection between the
designer, their solution, and ultimately the end user
• The empathic walkthrough pointed out areas where their
knowledge of the user or use context was deficient
• Empathy displayed was most often cognitive knowledge about
what the user was feeling, with occasion articulations of the
emotional feeling itself
• No instances of participants responding with compassion
(i.e., product-centric, not user-centric)
28. COLINGRAY.ME
DESIGNHEURISTICS.COM
THANK YOU
This research is funded by the National Science Foundation,
Division of Undergraduate Education, Transforming Undergraduate
Education in Science, Technology, Engineering and Mathematics
(TUES Type II) Grants # 1323251 and #1322552.