A conceptual model for HCI design cases

IHC 2012 Proceedings • Full Paper November 5-9, 2012 • Cuiabá, MT, Brazil 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 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. 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. 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]. Categories and Subject Descriptors H.5.2 [Information interfaces and presentation]: User Interfaces – Theory and methods. Keywords case-based reasoning, user interface design, humancomputer interaction 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 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 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). 209 may help designers maintain and use a large repertoire of HCI design cases. problem space solution space user goals 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. interaction interface system problem scenarios context domain task models sketches personas user HCI DESIGN SPACE Figure 1. Example of representations in line with cognitive engineering. 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. problem space solution space user goals interface system goal map scenarios context 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). interaction interaction model sketches domain signs (content) user signs (expression) personas 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: 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.    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 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. 210 Figure 3. A conceptual model of HCI design cases. 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. 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. 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. 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 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 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. 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. 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. 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:  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.    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 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, 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. 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. 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. 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. 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. 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. 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. 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 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: 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 ecommerce Web systems: two in the domain of supermarkets and two in the domain of theater tickets. 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 1. Activities performed by participants. Activities participants who examined cases (group A) 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  participants who did not examine cases (group B)  Table 2. Number of questions by categories of descriptors and by participants. category context of use   9. index the proposed solution   P2  P3 P4 P5 P6 2 total by category 2 domain 8. read descriptors 10. answer post-test interview P1 1 user 1 user goal 1 3 interaction 1 1 interface 1 2 system 2 1 2 4 1 4 2 3 1 14 2 4 4 2 1 7 4 1 6 6 34 project evaluation 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. total by participant 8 6 3 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. Results In this qualitative evaluation of our conceptual model, we found interesting issues regarding the case retrieval and indexing mechanisms. 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. 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. 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 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, 214 express his search intention (“experience with technology = often uses smartphone”). 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. 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. 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 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. “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 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. “I would not have... (something in the recovered cases)” – Participant 5 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. 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 As expected, descriptors were initially unfamiliar to all participants. The most difficult point was to understand the 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. 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. 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 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. “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. 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. 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. [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. The qualitative research study presented promising results for our conceptual model. The participants referred to all 216 [7] Diaper, D. and Stanton, N. (2003) The Handbook of [18] May, D. and Taylor, P. (2003) Knowledge Task Analysis for Human-Computer Interaction. Mahwah, NJ: Lawrence Erlbaum Associates. management with patterns. Communications of the ACM, Vol. 46, Issue 7, pp. 94-99. [8] Ericsson, K.A. and Simon, H.A. (1993) Protocol [19] Norman, D.A. (1986) “Cognitive Engineering”. In: Analysis: Verbal Reports as Data. Cambridge, MA: The MIT Press. Norman, D.A. and Draper, S.W. (Eds.) User Centered System Design. Hillsdale, NJ: Lawrence Erlbaum Associates, pp. 17–38. [9] Goldschmidt, G. (1998) Creative architectural design: reference versus precedence. Journal of Architectural and Planning Research, Vol. 15, Issue 3, pp. 258-270. [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. [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. [21] Rosson, M.B. and Carroll, J.M. (2002) Scenario-Based Development of Human-Computer Interaction. San Francisco, CA: Morgan Kaufmann Publishers. [11] Hackos, J.T. and Redish, J.C. (1998) User and task analysis for interface design. New York, NY, John Wiley & Sons. [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. [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. [23] Seidman, I. (1998) Interviewing as Qualitative Research: a guide for researchers in Education and the Social Sciences. New York, Teachers College Press. [13] Kim, H. and Yoon, W.C. (2005) Supporting the [24] Sharp, H., Rogers, Y. and Preece, J. (2007) Interaction cognitive process of user interface design with reusable design cases. International Journal Human-Computer Studies, Vol. 62, pp. 457–486. 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 [14] Kolodner, J.L. (1991) Improving Human Decision Atividades de Design de IHC. PhD Thesis. Departamento de Informática. PUC-Rio, 2010. Making Through Case-based Decision Aiding. AI magazine. Vol. 12, Issue 2, pp. 52-68. [26] Snyder, C. (2003) Paper Prototyping: the fast and easy [15] Kolodner, J.L. and Leake, D. (1996) “A Tuturial way to design and refine user interfaces. San Francisco, CA: Morgan Kaufmann. 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. [27] Sowa, J.F. (2000) Knowledge Representation: Logical, Philosophical, and Computational Foundations, Brooks Cole Publishing Co. [16] Lee, B., Srivastava, S., Kumar, R., Brafman, R. and [28] Suchman, L.A. (1987) Plans and Situated Actions: The 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. 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. [17] Maher, M.L. and Garza, A.G.S. (1997). Case-based Reasoning in Design. IEEE Expert, Vol. 12, Issue 2, pp. 34-41. 217 APPENDIX 1: AN HCI DESIGN CASE EXAMPLE user interface descriptors context of use local level of attention home or work high or middle user age task knowledge experience with technology preferences adult <high knowledge, search products>, <average knowledge, buy products> <frequent use of internet for e-mail and internet bank> 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> <client, make, order>, <order, has, payment>, <order, has, delivery> <product, is_part_of, item>,<item, is_part_of, order> relation 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 sequence of steps <d, show, [number of items, total price]>, <u, define, [delivery]> < <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 widget interaction style system platform input device output device each interaction step in a dialog link, menu, text box, label, image, command button menus and forms project web, desktop keyboard, mouse screen, print evaluation favored design principles favored quality criteria project author client organization and visual structure, contrast efficiency, remember user’s address 218