A Conceptual Model For HCI Design Cases

A Conceptual Model for HCI Design Cases
Bruno Santana da Silva, Simone Diniz Junqueira Barbosa
Departamento de Informática, PUC-Rio
R. Marquês de São Vicente, 225
Gávea, Rio de Janeiro, RJ, Brasil, 22451-900
{brunosantana, simone}@inf.puc-rio.br
ABSTRACT
Designers often use previous knowledge during design
activities. Case-Based Reasoning (CBR) systems have been
used to help designers deal with a large repertoire of past
design cases in many domains, like architecture and
software. However, we still have little work that addresses
Human-Computer Interaction (HCI) design in CBR
systems. In general, they focus on specific HCI design
artifacts, considering just a few aspects of HCI solutions. In
this paper, we review related works to propose an enlarged
conceptual model for HCI design cases in CBR systems.
The model is flexible and extensible to accommodate
different design artifacts, supporting different design
processes and cultures. We have evaluated our conceptual
model with a qualitative research, in which participants
were asked to index and retrieve cases during an HCI
design activity, referring to characteristics of context of use,
domain, user, user goal, interaction, user interface, and
system. The results indicate that CBR systems for HCI
design should consider a wide view of the HCI problem and
solution spaces, and the proposed conceptual model has
great potential to support designers in dealing with a large
repertoire of HCI design cases in CBR systems.
Categories and Subject Descriptors
H.5.2 [Information interfaces and presentation]: User
Interfaces – Theory and methods.
Keywords
case-based reasoning, user interface design, human-
computer interaction
INTRODUCTION
Case-Based Reasoning (CBR) has been explored to support
designers’ skills and activities during design processes [14].
CBR systems can aid designers in the maintenance and use
of a large repertoire of design cases, working both as a
personal and a collective memory for designers [18]. CBR
systems record and index design cases in a way that makes
it easy and quick to retrieve past cases that are relevant to
the current one. Designers may be responsible for
evaluating retrieved cases and for deciding what to do with
them: to discard or to adapt previous knowledge to the
current problem. Therefore, “the system does what tends to
be more difficult for people – retrieving and presenting
cases; and people do what tends to be more difficult for
machines – adapting cases to fit new situations and
comparing and contrasting cases to interpret new situations”
[15]. CBR systems can also automatically adapt retrieved
cases, but such adaptation is out of the scope of this work.
Several CBR systems have been developed in different
domains, such as architecture, engineering and software
design [17][29]. Nevertheless, Human-Computer
Interaction (HCI) design has so far received little attention
from the CBR community. Griffith et al. [10] explores ways
to jointly access user interface examples and guidelines.
Lee et al. [16] represent design cases as web pages. Kim
and Yoon [13] integrate a task model, a dialog model and
user interface prototypes into a design case. Their work
focuses on only a few aspects of the HCI problem and
solution spaces. For example, the reported HCI design
cases do not contain explicit information about context of
use or user characteristics in their problem descriptions, and
they usually do not refer to the interaction process or
input/output devices in their solution descriptions.
Moreover, the reported CBR systems generally support
only specific HCI design artifacts. Both limitations hinder
their adoption in a diversity of HCI design cultures and
processes [9].
In this work, we review the HCI problem and solution
spaces to propose a conceptual model for HCI design cases
in CBR systems. This conceptual model is flexible and
extensible to accommodate and to support several design
processes and cultures, using diverse models and
representations. Therefore, the designer may index and
retrieve HCI cases according to different dimensions as
needed at each moment. We evaluated our conceptual
model with a qualitative research study. During an HCI
design activity, participants were asked to retrieve and to
index design cases organized according to our conceptual
model. They examined and updated a base of HCI design
cases taking into account characteristics of context of use,
domain, user, user goal, interaction, user interface, and
system. These results point out the importance of a wide
view of the HCI problem and solution spaces in CBR
systems, and indicate that the proposed conceptual model
209
Permission to make digital or hard copies of all or part of this work for
personal or classroom use is granted without fee provided that copies
are not made or distributed for profit or commercial advantage and that
copies bear this notice and the full citation on the first page. To copy
otherwise, or republish, to post on servers or to redistribute to lists,
requires prior specific permission and/or a fee.
IHC'12, Brazilian Symposium on Human Factors in Computing
Systems. November 5-9, 2012, Cuiabá, MT, Brazil. Copyright 2012
SBC. ISSN 2316-5138 (pendrive). ISBN 978-85-7669-262-1 (online).
IHC 2012 Proceedings • Full Paper November 5-9, 2012 • Cuiabá, MT, Brazil

may help designers maintain and use a large repertoire of
HCI design cases.
This paper is organized as follows. The next section
presents the HCI design space as defined by related work.
The third section presents the proposed conceptual model
for HCI design cases, in which the case content, structure
and indexing mechanisms are described. Next, we present
how cases can be retrieved. In the fifth section, we describe
a qualitative study conducted to evaluate our proposal.
Finally, we present some concluding remarks and directions
for future work.
HCI DESIGN SPACE
Our HCI design space review is based on an interpretation
of a typical situation of use [24]. The use of a system [20]
occurs when a user [11] is engaged in an interaction
process [19][5] with a user interface [24], to achieve some
goal [19][28][3] in a domain [27] within a context of use
[6][22]. These seven elements of the HCI design space are
strongly interrelated. They play an important role during
system use and, therefore, during HCI design. We organize
them in problem and solution spaces of HCI design.
The HCI problem space includes elements that had existed
before the system was designed: the context of use, domain,
user and user goals. The HCI solution space involves all
elements that result from the design activity (or designer’s
decisions): the interaction process, user interface, system,
and user goals. User goals cross the boundary of the
problem and solution spaces, because they are identified
during the analysis of the current situation (problem), but
the designer helps to decide which user goals will be
supported by the system (solution).
The designer can use a particular set of representations and
models to register an HCI design case, depending on his
design approach, culture, preferences and available
resources. We will illustrate the HCI problem and solution
spaces in line with two theoretical approaches of HCI:
cognitive engineering [19] and semiotic engineering [5]. In
line with cognitive engineering, the Figure 1 shows an HCI
design problem represented with personas [3] and problem
scenarios [21]; and an HCI design solution registered in
task models [7] and sketches [2], for example. When the
designer works in line with semiotic engineering, an HCI
design problem may be represented by personas [3], the
content part of sign schemas, scenarios and goal maps [1];
and an HCI design solution may be elaborated using
interaction models, the expression part of sign schemas [1],
and sketches [2], as illustrated in Figure 2.
It is important to note that these are only examples of
representations in line with cognitive and semiotic
engineering approaches to HCI design. The designer may
choose to work with other artifacts, when considered
necessary or more adequate. Based on this definition of the
problem and solution spaces, we propose a conceptual
model for HCI design cases.
problem
scenarios
task models sketches
personas
user goals interaction interface system
problem space solution space
domain
context
user
Figure 1. Example of representations in line with
cognitive engineering.
goal map
interaction
model
sketches
signs
(expression)
scenarios
signs
(content)
personas
user goals interaction interface system
problem space solution space
domain
context
user
Figure 2. Example of representations in line with
semiotic engineering.
A CONCEPTUAL MODEL FOR HCI DESIGN CASES
Kolodner and Leake [15] argue that design cases should
have content (problem + solution + outcome), to register
the learned lessons, and indices, to describe the context in
which these lessons can be taught. Therefore, an HCI
design case (Figure 3) should have:
 a problem description, with information about
context of use, user and domain;
 a solution description, with information about user
goal, interaction, user interface, system and about
the design process (e.g. author, client and date);
 an evaluation description, with information about
evaluations of the solution quality of use;
In addition, an HCI design case should have indices:
descriptors, with information that describes the HCI design
case, considering all elements of HCI design space.
As many HCI design artifacts are represented in digital
media or can be easily turned into digital media (e.g.
scanning or taking a picture), we propose to use the artifacts
produced during the design activity to describe the content
of their corresponding design case. This helps the storage of
design cases, because the designer tends to employ less
effort to register his design cases, avoiding the translation
210

of the produced artifacts to other specific artifacts expected
by CBR system.
For example, the design problem and solution could be
described by artifacts, as those in Figure 1 or in Figure 2. In
both circumstances, the evaluation part of case content will
be typically associated to reports of formative or summative
HCI evaluations [24].
The designer may choose which kind of artifacts will be
associated to HCI design cases, according to his
preferences, approach or design culture. There is no
restriction on kinds of artifacts in the proposed conceptual
model. However, we assume that a design case will be in
line with a certain HCI design approach, i.e., artifacts and
their descriptors are consistent and coherent with the design
stance the designer adopted.
A metamodel may define the elements and constraints of
some of the artifacts. For example, there are specific
metamodels for HTA, CTT and GOMS task models [7].
The relation between artifact and metamodel is analogous
to the relation between instance and class. A metamodel
may support the computational processing of HCI design
artifacts in (semi)automatically retrieving and indexing
design cases.
How much information can we put into an HCI design
case? An HCI design case may range from a whole system
up to a very small part of one, such as describing a single
widget. These are two extremes, and probably the most
frequent use will fall somewhere in the middle. We
recommend defining an HCI design case for each main user
goal, i.e., each design case should describe the necessary
portion of HCI solution for the user to achieve one of his
main goals. Main goals are those that lead users to use the
system. Achieving main goals may require achieving other
instrumental goals. For example, one of the main
motivations to use an e-commerce system is to “buy
products”. However, before buy something, the user should
find the desired products among all the available ones. In
this way, we may consider the goal “search products” as
instrumental to the goal “buy products”. If the user needs to
achieve instrumental goals to complete a main goal, the
instrumental goals (“search products”) should be included
in the design case of the respective main goal (“buy
products”), or at least linked to it. Therefore, we can define
an HCI design case as: a set of related artifacts produced
during an HCI design activity that describes a problem,
solution and an evaluation of the solution; usually within
the scope of a main user goal.
Indexing HCI Design Cases
CBR systems must index design cases to retrieve them later
to support the designer’s needs. According to Kolodner and
Leake [15], indices are important descriptors of a case,
allowing designers to distinguish one case from others.
They are used to indicate which cases the designer wants to
retrieve at each moment. In our conceptual model (Figure
3), we represent indices as descriptors associated to HCI
design cases. A descriptor has a name, type, domain, and
comment. Simple type descriptors are text, number and
date. Composite type descriptors are tuples composed of
other descriptors.
How could we index design cases registered in different
kinds of artifacts? When a design artifact has a metamodel,
we can automatically process and index it through the
descriptors defined in the metamodel. Automatic indexing
approaches require very little work of the designer, but are
difficult to scale for some of the artifacts, which have no
associated metamodels. In these cases, we have to manually
index the design cases. Although manual indexing requires
effort from the designer, he may choose which artifacts will
compose a design case and which descriptors will describe
Figure 3. A conceptual model of HCI design cases.
211

it. In this way, the designer can maintain a case base that
accommodates diverse kinds of artifacts related to the same
concept of the HCI design space. For example, an HCI case
base may have an interaction scenario, a task model and an
interaction model (artifacts) to represent the user-system
interaction (concept). Moreover, manual indexing allows
the designer to easily modify and extend the set of
descriptors according to his preferences and needs. For
instance, the designer can index a case with user
characteristics that have not yet been considered.
Conjugating automatic and manual indexing is a promising
approach to CBR systems, because we can profit from the
advantages of both. Independent of the indexing approach,
the indices should highlight characteristics, aspects and
dimensions that can be used to compare different kinds of
artifacts. Based on the HCI design space discussed
previously, we have proposed an initial set of descriptors to
index design cases. This set can be extended when the
designer deems necessary.
Indexing HCI Problems. An HCI design problem can be
described in terms of context of use, user and domain.
Context of use descriptors refer to the physical (e.g. place,
attention level, luminosity level, noise level) and
sociocultural environment (e.g. language, power structure,
interaction among people, social pressure, sociocultural
group). User descriptors involve personal characteristics
(e.g. age, profession, and role), domain and task
knowledge, experience with technology, physical,
perceptive and cognitive skills, and user preferences.
Domain descriptors indicate concepts and their relations.
Indexing HCI Solutions. An HCI design solution can be
described in terms of user goal, interaction, user interface,
system and project. User goal descriptors refer to user
motivations to use the system (user goals) and relations
between them. User-system interaction descriptors involve
the sequence of user and systems steps (task, action, dialog
or utterance, depending on the design approach has been
used) during the interaction process, and kinds of
interaction support (e.g. wizard, foster exploration, and
overview first and details on demand). User interface
descriptors highlight widgets, interaction styles, user
interface patterns and the mappings of interaction onto user
interface elements. System descriptors refer to
characteristics that may directly affect the interaction, such
as platform (core hardware and operating system), input
and output devices and available infrastructure (e.g.
network connection, bandwidth, storage space, and battery
level). Project descriptors include project name, authors,
client and date.
Indexing HCI Evaluations. An HCI evaluation can be
described in terms of its results. Evaluation descriptors
highlight results from inspection (e.g. favored and impaired
design principles, favored and impaired quality criteria, and
severity of issues) and user evaluation of the proposed
solution (e.g. percentage of users who achieved the goal,
average time or number of errors to achieve the goal, and
error severity).
Appendix 1 presents an example of an HCI design case in
the supermarket domain. It just illustrates the user interface
artifact and some descriptors, due to space restrictions. [25]
presents more examples of descriptors and their use.
RETRIEVING HCI DESIGN CASES
Computers are usually better than people in dealing with
systematic and repetitive tasks. One such task is to scan a
large set looking for something of interest at the moment.
What could be the retrieval mechanisms for CBR systems
to return similar HCI design cases? In the CBR system
proposed by Lee and colleagues [16], the designer begins
by interacting with a web site gallery. At any time, he can
see details of a website or seek similar sites, according to a
similarity dimension. For example, the designer can retrieve
websites with similar background color or with similar
number of columns. Here, the similarity is calculated by
websites metadata. This retrieval approach is adequate and
useful to our proposal for HCI design cases.
In this work, we propose to recover HCI design cases with
similar descriptors. The designer’s basic question should be
“What cases have similar descriptors?” The designer can
begin with a current case at hand to search for other cases
with similar descriptors, or he can choose a set of
descriptors directly from our conceptual model without
having a current case at hand. When the designer retrieves a
case, he may access its artifacts and descriptors to analyze
them. In the supermarket domain, for example, the designer
may look for HCI design cases using the questions:
 Which cases have the domain concepts of product,
order or payment? – descriptors domain.concept
with product, order or payment
 Which cases have the user goals of buying or
selling something? – descriptors user goal in the
form <buy, _, _, _, _> or <sell, _, _, _, _>
 Which cases have interaction steps involving a
shopping cart? – descriptors interaction in the form
<_, O(cart), _> or <_, _, O(cart)>
 Which cases have a command button in a web
platform? – descriptors user interface.widget with
command button or system.platform with web
As a result, he may obtain design cases of other websites
for supermarket, websites that sell specific products such as
electronics or flowers, and even websites that sell products
that supermarkets do not sell, such as airline tickets, for
instance.
EVALUATION
We evaluated the use of cases during HCI design activities,
according to our conceptual model. Before getting involved
with development concerns of a CBR system, we decided to
evaluate the manual use of cases, with printed material,
paper, and pencil. Therefore, we avoided that problems in
212

CBR systems might affect the evaluation of our conceptual
model.
Objectives
The general goal of our qualitative research was to
investigate how previous cases affect the HCI design
activities [25]. In this work, we detail this general research
goal in the following specific questions:
How do people use the descriptors for retrieving HCI design
cases?
Different from other proposals of CBR systems to support
HCI design, our conceptual model proposes to index cases
with a wide range of descriptors, involving different
elements of a typical situation of use. Moreover, previous
work [13][16] does not evaluate the use of descriptors in
retrieval activities with the participation of HCI designers.
It is important to evaluate whether or not our descriptors
may be useful for the retrieval of adequate design cases.
Which descriptors are referred to by participants while they
search for HCI design cases? It is also important to
investigate whether or not the participants can associate the
desired information with the given descriptors. This is
relevant, for example, to verify whether we can develop a
CBR system that makes the descriptors explicit as in a
form, or whether we should explore other ways to express
the characteristics of the desired cases.
How do people use the descriptors for indexing HCI design
cases?
It is important to investigate whether participants can index
their own cases using the proposed descriptors and how
they do this, so that they can update the case base in a CBR
system.
Methodology
Our conceptual model was evaluated in a qualitative
research study [4] with eight participants. We collected data
following a participant observation method [4] during one
session of an HCI design activity. Each participant worked
individually in his design process without interacting with
others. The researcher’s participation consisted in
explaining the activities that should be executed, simulating
the behavior of a CBR system in the retrieval of the design
case and clarifying any doubts about the design process, the
design decisions and the resulting HCI solution. The
participants were asked to express aloud their reflections,
doubts and decisions during the design process, in line with
the think-aloud technique [8]. The observation sessions
were recorded in audio and video, and all produced
materials (e.g. sketches and notes) was gathered. We took
care of ethical concerns [24], such as asking for free and
informed consent and ensuring the participants’ anonymity.
The proposed HCI design problem guided the participants
to focus on a single user goal: to buy movie tickets using a
smartphone with internet access. To familiarize them with
the design problem, all participants received the following
interaction scenario:
Paula decided to watch a movie that is not very
famous. She used her smartphone to verify the
available sessions in the site for buying movie tickets.
The website allows her to search for sessions by
movie, city, and theatre. As the movie was probably
playing in only a few theatres, she considered more
efficient to search by movie. After she informed the
movie name, she received a list of theatres that were
exhibiting the movie and the schedule of the available
sessions. She analyzed the sessions, chose one nearby
her home, informed the number of tickets and chose
the delivery mode. Afterward, she checked the order,
indicated a payment mode and confirmed the
purchase. Finally, she received a confirmation
message.
We used a purposive sample [23] of participants with a
background in Computer Science (CS) who had some
experience in HCI design. The background in CS is useful
because it provides strong incentives to reuse and it is
typically constrained by short time to market demands.
From the eight participants of the study, two were CS
undergraduate students and six were CS graduate students
at our university. They had participated in at least one
introductory HCI class. The genre division was balanced:
four man and four women. According to the pre-test
questionnaire, their experience included academic and
professional work. Five participants declared having had
designed up to five user interfaces; one having had
designed from six up to ten user interfaces; and two having
had designed more than ten user interfaces. All of them
reported to have an above average domain knowledge.
We separated the eight participants in two groups: group A,
with six participants to examine previous cases during the
design, and group B, with two participants to design
without using cases. All participants received the same
input and performed the same HCI design activity.
Table 1 presents the activities performed by the two groups
of participants. These activities were part of a larger study
about the use of cases during HCI design activities [25]. In
this work, we will focus on the activities related to retrieval
(2-5 activities) and indexing (8-9 activities) of HCI design
cases.
Group A retrieved HCI design cases. They read a list of
descriptor examples. The researcher presented the basic
instructions of the indexing activity, illustrated with indexed
examples of scenario, persona and domain model similar to
those in Figure 2. Then, participants wrote retrieval
questions for the desired HCI design cases, taking into
account the proposed design problem in the scenario. First,
they wrote the questions in natural language and later they
defined the descriptors that referred to each proposed
question. The researcher simulated the retrieval in a CBR
system with the descriptors defined by participants, and
presented the retrieved HCI design cases (design artifacts
and respective descriptors) to them. The participants had
213

the opportunity to make other retrieval questions or to
modify those initially proposed, when they deemed
necessary. This retrieval simulation was similar to paper
prototyping [26]. The available HCI case base had four e-
commerce Web systems: two in the domain of supermarkets
and two in the domain of theater tickets.
Table 1. Activities performed by participants.
Activities
participants
who examined
cases (group A)
participants
who did not
examine cases
(group B)
1. answer pre-test questionnaire  
2. read descriptors 
3. read instructions to retrieve
cases

4. write questions to retrieve cases 
5. analyze retrieved cases 
6. design interaction and user
interface
 
7. compare proposed solution and
retrieved cases

8. read descriptors 
9. index the proposed solution 
10. answer post-test interview  
Participants in the group B indexed their HCI design cases.
They began reading the scenario to propose an interaction
and user interface solution. They made their solutions
without examining any HCI design cases. Then, they read
the list of descriptors (presented in “Indexing HCI Design
Cases” Section) to index their HCI design problem and
solution.
Results
In this qualitative evaluation of our conceptual model, we
found interesting issues regarding the case retrieval and
indexing mechanisms.
How did participants use descriptors to retrieve HCI design
cases?
Aware of the proposed design problem, group A posed
questions to retrieve HCI design cases. They wrote
questions in natural language and, later, they defined them
in terms of the proposed descriptors. Only one participant
had difficulty to formulate case retrieval questions in
natural language, although he had cited many characteristics
of similar systems (cases) he wanted to examine. The six
participants initially proposed at least three questions.
When the retrieval simulation returned empty or
unsatisfactory results, three participants wrote three or four
additional questions.
We classified the questions in natural language in terms of
the descriptor type to which they referred: context of use,
domain, user, user goal, interaction, user interface, system,
project and evaluation. Table 2 presents the number of
questions that referred to each kind of descriptors,
classified by participant. Only project and evaluation
descriptors were not referred to by any question. Context of
use and user descriptors were referred to by just one
participant. User goal descriptors were the only kind of
descriptors referred to by all six participants, although two
of them referred to user goals only in the second group of
retrieval questions (after having received an empty or
inadequate response from the researcher simulating the
CBR system). In the following, we examine the use of
descriptors in detail.
Table 2. Number of questions by
categories of descriptors and by participants.
category P1 P2 P3 P4 P5 P6
total by
category
context of use 2 2
domain 1 1 2 4
user 1 1
user goal 1 3 4 2 3 1 14
interaction 1 1 2 4
interface 1 2 4
system 2 2 1 1 6
project
evaluation
total by participant 8 6 7 4 3 6 34
Context of use. Only Participant 1 referred to the context
of use when retrieving HCI design cases. Thinking about a
system executed in a smartphone, he was interested in
systems that had been used in public places and in transit.
He adequately mapped natural language questions to
context descriptors.
Domain. Participants 3, 4 and 6 referred to the domain in
their retrieval questions. They looked for cases involving
ticket, movie theatre, bookstore and airfare. Participants 3
and 6 adequately used the descriptors. Participant 4 did not
map his questions to descriptors, but he gave examples of
websites he knew and would examine during the proposed
design activity. He commented: “I always saw eBay and
Amazon, which are two references to me.” He could easily
cite concrete examples of systems that he would like to
examine, instead of system characteristics that he was
interested at that moment. This kind of retrieval strategy
may be explored in CBR systems. The designer could
examine similar systems to one already found in the base,
without explicitly defining descriptor values.
User. Only Participant 1 referred to the user in his retrieval
questions. He was interested in cases that consider the user
experience with smartphones (“users that often use
smartphone?”). He defined the descriptors correctly to
214

express his search intention (“experience with technology =
often uses smartphone”).
User Goal. All six participants referred to user goals in
their retrieval questions. In general, they were interested in
goals of buying, selling, searching and identifying user (login).
However, some of them had difficulty in mapping the
natural language questions to user goal descriptors. Part of
this difficulty is intrinsic to HCI and part of it may be
personal. Some participants referred to user goals at
different levels of abstraction. Participant 6, for example,
mapped the buying goal to an interaction descriptor
involving payment. Participant 2 made a still more distant
mapping, relating the buying goal to a descriptor of a user
interface widget. These distant mappings reflect the
difficulty recognized by Diaper and Stanton [7] to
distinguish user goals from their respective interaction steps
(or task steps). The different levels of abstraction from what
is in the user’s mind down to corresponding actions at the
user interface still do not have a clear and widely accepted
distinction in HCI. These are difficulties inherent to the
area. Some participants also present difficulty in dealing
with abstractions. For example, Participant 2 systematically
jumped to defining user interface descriptors to refer to
abstract concepts, as user goals and interaction. Here, again
Participant 4 was not able to propose retrieval questions
about buying, nor to use its respective descriptors. He just
cited examples of websites that he knew and would like to
examine.
Interaction. Participants 1, 2 and 6 referred to the
interaction in their retrieval questions, citing interaction
support, choice of seats, authentication and confirmation.
Participant 1 considered useful to consult design cases with
interaction support “overview first and detail on demand”.
He was looking for ideas to present an overview of seats in
the movie theatre and present more information on demand.
Participants 1 and 6 adequately mapped natural language
questions to descriptors. Participant 2 mapped abstract
concepts, which were more appropriate to the interaction,
directly to user interface widgets.
Interface. Participants 1 and 2 were interested in cases with
certain user interface characteristics. The first one was
interested on a specific interaction style, and the second one
in widgets and their properties. Here, the natural language
questions were adequately mapped onto descriptors.
System. Participants 1, 3, 4 and 5 hoped to find design
cases with certain system characteristics, such as
smartphone, cellphone or PDA platform, touchscreen input
and wireless connection. Participants 1, 3 and 5 adequately
mapped natural language questions onto system descriptors.
Participant 4 did not write a retrieval question, however he
orally expressed his interest in examining design cases for
the PDA platform.
As expected, descriptors were initially unfamiliar to all
participants. The most difficult point was to understand the
tuple structure of some descriptors, as in the user goal
descriptor: <verb, [slots], [precondition], [post condition],
[frequency]>. This difficulty was well illustrated by
Participant 4 when he said “It is difficult to absorb this”
when he read the descriptors list with tuples. They also had
doubts about which descriptor should contain the desired
retrieval criteria. Mapping questions in natural language
onto descriptors was not considered trivial, as illustrated by
Participant 5: “I was thinking about how to go from this
(questions in natural languages) to the descriptor. This is…
(laborious, complicated, difficult…)”. This was evident
when some participants made inappropriate mappings from
natural language questions onto descriptors. These results
point out the need to indicate the content without explicitly
indicating to which descriptor this content refers. In other
words, people would write what they wanted without
having to think about how that content would be searched.
In spite of the initial difficulty with tuples and the necessary
work to define the desired descriptors, some participants
showed a keen understanding of the proposed mechanism
for cases retrieval. It became evident when they began to
compose more complex questions that allowed them to
retrieve more relevant cases. Participants 1, 3 and 5 made
interesting comments about this:
“I think I’m beginning to understand the problem (of
how to retrieve design cases). This here (a question)
will give me any kind of user interface, I have to
combine this (question) with smartphone. In fact, I
should check if there is an intersection between these
(responses of a question) and those (responses of
another question). (How should a question be
combined in natural language?) It should be a search
tool (user goal) for a smartphone (system).” –
Participant 5
“I want one (recovered solution) that had all these
questions answered” – Participant 3
“If I have this goal map here or this interaction
diagram here with this information, with these
descriptors; if I realize that the context considered in
this goal map is the same that I was looking for now
for what I’m doing, so I would probably use this
solution or part of this solution in what I’m doing
now.” – Participant 1
“I would not have... (something in the recovered
cases)” – Participant 5
How did participants use descriptors to index HCI design
cases?
The two participants of the group B indexed their HCI
design case (both problem and solution) according to our
conceptual model. Evaluation descriptors were not used,
and only one participant used project descriptors. These
participants were engaged in understanding the descriptors
and tried to follow the proposed format. We did not identify
conceptual errors in their use of descriptors, although they
215

made some syntax mistakes considering the proposed
descriptors format. They made a comprehensive indexing of
their HCI design cases, involving different kinds of
descriptors. They highlighted important points of their case,
which may make the case retrieval easier.
Both participants of the group B said that the indexing of
cases offers an opportunity for the designer to verify what
was considered during HCI design or not. They
commented:
“the descriptors help to identify what concerns had
been addressed by designer.” - Participant B1
“they (the descriptors) call your attention to things
you have not thought yet. Eventually you may be
forgetting some detail.” - Participant B2
Moreover, Participant B2 also highlights the need to add
other descriptors according to the particularities of case. He
said:
“It is important give space for you to put specific
things of domain. (...) (The CBR system should ask:)
‘What else (is important to your particular case)?’
(The CBR system should) remind the designer that
he should consider more things.” - Participant B2
In [25], we provide more details about this qualitative
evaluation of our conceptual model of HCI design cases.
CONCLUSIONS
In this work, we proposed a conceptual model for CBR
systems to support HCI design. Different from previous
works which consider only a few characteristics of user
interface, interaction and user goals; our conceptual model
accommodates a broader view of the HCI design space. We
argued that an HCI design case should contain information
about context of use, domain, user goal, interaction, user
interface, user, system, project and evaluation. HCI design
cases may be recorded in any artifact produced during the
design process that may be digitalized in a computer file,
like XML and image files. Furthermore, HCI design cases
should be indexed (automatically, manually or both) by
descriptors that refer to the HCI design space to facilitate
their later retrieval.
Our conceptual model was proposed to be flexible and
extensible. The flexibility comes from the opportunity to
use various design representations indexed by different
descriptors of the HCI design case. The extensibility comes
from the opportunity to add new design representations and
new descriptors besides the ones proposed in this work. In
this way, HCI designers may maintain a case base
according to their particular design culture, using their
preferred representations and dealing with the
particularities of each case base using a different set of
descriptors. This represents an improvement on previous
works.
The qualitative research study presented promising results
for our conceptual model. The participants referred to all
kinds of proposed descriptors to retrieve previous design
cases, except evaluation and project descriptors. These
empirical results point out the need to index and to retrieve
HCI design cases with more information about both
problem and solution. Previous works [13][16] had not
investigated this possibility, and considered little
information on the HCI design space. In addition, manual
indexing may motivate designers to review what they have
learned about the design problem and to evaluate whether
the solution is adequate.
As future work, we will investigate how to develop a CBR
system according to the proposed conceptual model. We
need to investigate ways to process some HCI design
artifacts (e.g. task and interaction models) to
(semi)automatically index them, and to investigate how to
integrate the indexing to verification activities during the
design process. We also must investigate candidate retrieval
mechanisms, such as natural language, keyword and form
search and a faceted navigation. A good starting point is to
review the user interface of CBR systems, like [12].
Moreover, we need to conduct more qualitative and
quantitative research to evaluate our conceptual model with
other design problems and case bases, exploring other
domains, platforms, and with designers with different
experiences and backgrounds. In particular, we should
investigate whether the project and evaluation descriptions
can be useful to maintain and recover HCI design cases.
ACKNOWLEDGEMENT
The authors thank to CNPq and FAPERJ for his financial
support to their work. They thank to the participants for
their valuable opinions.
REFERENCES
[1] Barbosa, S.D.J. and Paula, M.G. (2003) “Designing
and Evaluating Interaction as Conversation: a
Modeling Language based on Semiotic Engineering” In
Proceedings of DSV-IS 2003, Lecture Notes in
Computer Science, Vol. 2844, pp. 16–33.
[2] Buxton, B. (2007) Sketching User Experiences: getting
the design right and the right design. San Francisco,
CA: Morgan Kaufmann.
[3] Cooper, A., Reimann, R. and Cronin, D. (2007) About
Face 3: The Essentials of Interaction Design. New
York, NY: John Wiley & Sons.
[4] Creswell, J.W. (2003) Research Design: Qualitative,
Quantitative, and Mixed Methods Approaches. 2nd
Edition. SAGE Publications.
[5] De Souza, C.S. The Semiotic Engineering of Human-
Computer Interaction. MIT Press, 2005.
[6] Dey, A.K. (2001) Understanding and Using Context.
Personal and Ubiquitous Computing, Vol. 5, pp. 4–7.
216

[7] Diaper, D. and Stanton, N. (2003) The Handbook of
Task Analysis for Human-Computer Interaction.
Mahwah, NJ: Lawrence Erlbaum Associates.
[8] Ericsson, K.A. and Simon, H.A. (1993) Protocol
Analysis: Verbal Reports as Data. Cambridge, MA:
The MIT Press.
[9] Goldschmidt, G. (1998) Creative architectural design:
reference versus precedence. Journal of Architectural
and Planning Research, Vol. 15, Issue 3, pp. 258-270.
[10] Griffith, A.L., Simpson, R., and Blatt, L.A. (1994).
Interface lab: A case-based interface design assistant.
In Proceedings of the tenth conference on artificial
intelligence for applications, pp. 469-470.
[11] Hackos, J.T. and Redish, J.C. (1998) User and task
analysis for interface design. New York, NY, John
Wiley & Sons.
[12] He, W.; Wang, F.K.; Means T. and Xu, L. D. (2009)
Insight into interface design of web-based case-based
reasoning retrieval systems. Expert Systems with
Applications, Volume 36, Issue 3, Part 2, April, pp.
7280-7287.
[13] Kim, H. and Yoon, W.C. (2005) Supporting the
cognitive process of user interface design with reusable
design cases. International Journal Human-Computer
Studies, Vol. 62, pp. 457–486.
[14] Kolodner, J.L. (1991) Improving Human Decision
Making Through Case-based Decision Aiding. AI
magazine. Vol. 12, Issue 2, pp. 52-68.
[15] Kolodner, J.L. and Leake, D. (1996) “A Tuturial
Introduction to Case-Based Reasoning”. In: Leake, D.
(Ed.) Case-based reasoning: Experiences, lessons, and
future directions. Menlo Park, CA: AAAI Press. pp.
32-65.
[16] Lee, B., Srivastava, S., Kumar, R., Brafman, R. and
Klemmer, S.R. (2010) Designing with Interactive
Example Galleries. In Proceedings of the 28th
international conference on Human factors in
computing systems: CHI 2010, pp. 2257-2266.
[17] Maher, M.L. and Garza, A.G.S. (1997). Case-based
Reasoning in Design. IEEE Expert, Vol. 12, Issue 2,
pp. 34-41.
[18] May, D. and Taylor, P. (2003) Knowledge
management with patterns. Communications of the
ACM, Vol. 46, Issue 7, pp. 94-99.
[19] Norman, D.A. (1986) “Cognitive Engineering”. In:
Norman, D.A. and Draper, S.W. (Eds.) User Centered
System Design. Hillsdale, NJ: Lawrence Erlbaum
Associates, pp. 17–38.
[20] Paternò, F. and Santoro, C. (2003) A Unified Method
for Designing Interactive Systems Adaptable to Mobile
and Stationary Platforms. Interacting With Computers,
Vol. 15, Issue 3, pp. 349-366.
[21] Rosson, M.B. and Carroll, J.M. (2002) Scenario-Based
Development of Human-Computer Interaction. San
Francisco, CA: Morgan Kaufmann Publishers.
[22] Schilit, B., Adams, N. and Want, R. (1994) Context-
aware computing applications. In: Proceedings of the
IEEE Workshop on Mobile Computing Systems and
Applications, IEEE Press, pp. 85-90.
[23] Seidman, I. (1998) Interviewing as Qualitative
Research: a guide for researchers in Education and the
Social Sciences. New York, Teachers College Press.
[24] Sharp, H., Rogers, Y. and Preece, J. (2007) Interaction
Design: Beyond Human-computer Interaction. Second
Edition. New York, NY: John Wiley & Sons.
[25] Silva, B.S. O Uso de Casos na Reflexão em Ação em
Atividades de Design de IHC. PhD Thesis.
Departamento de Informática. PUC-Rio, 2010.
[26] Snyder, C. (2003) Paper Prototyping: the fast and easy
way to design and refine user interfaces. San Francisco,
CA: Morgan Kaufmann.
[27] Sowa, J.F. (2000) Knowledge Representation: Logical,
Philosophical, and Computational Foundations, Brooks
Cole Publishing Co.
[28] Suchman, L.A. (1987) Plans and Situated Actions: The
problem of human–machine communication. New
York, NY: Cambridge University Press.
[29] Watson, I. and Perera, S. (1997). Case-based design: A
review and analysis of building design applications.
Artificial Intelligence for Engineering, Design,
Analysis and Manufacturing, Vol. 11, pp 59-87.
217

APPENDIX 1: AN HCI DESIGN CASE EXAMPLE
user interface
descriptors
context of use
local home or work
level of attention high or middle
user
age adult
task knowledge <high knowledge, search products>, <average knowledge, buy products>
experience with technology <frequent use of internet for e-mail and internet bank>
preferences delivery at home
domain concept: <name [: attributes]>, relation: <concept 1, relation, concept 2>
concept <client>, <order: total price, items>, <item: quantity, unit price >
<product: name, brand, quantity, information, price>
<delivery: scheduled date, scheduled time, date, time, shipping rate>
relation <client, make, order>, <order, has, payment>, <order, has, delivery>
<product, is_part_of, item>,<item, is_part_of, order>
user goal tuple: <verb, [objects], [precondition], [post condition], [frequency]>
user goal <sign in, [client], unidentified user, identified user, few times per month>
<search, [product], , , many times per month>
<buy, [product], identified user, , some times per month>
interaction tuple: < agent, verb, [objects] >
step <d, show, [number of items, total price]>, <u, define, [delivery]>
sequence of steps < <u, finalize, [order, cart]>, sequential, <d, show, [number of items, total price]> ,
sequential, <u, define, [delivery]> , sequential, <u, define, [payment mode]> >
user interface
mapping interaction to user interface each interaction step in a dialog
widget link, menu, text box, label, image, command button
interaction style menus and forms
system project
platform web, desktop project
input device keyboard, mouse author
output device screen, print client
evaluation
favored design principles organization and visual structure, contrast
favored quality criteria efficiency, remember user’s address
218

A Conceptual Model For HCI Design Cases

More Related Content

Similar to A Conceptual Model For HCI Design Cases

More from Brittany Allen

Recently uploaded

A Conceptual Model For HCI Design Cases