Homework answers / question archive / 4 A USER-CENTERED FRAMEWORK FOR DERIVING A CONCEPTUAL DESIGN FROM USER EXPERIENCES: LEVERAGING PERSONAS AND PATTERNS TO CREATE USABLE DESIGNS Homa Javahery, Alexander Deichman, Ahmed Se?ah, and Mohamed Taleb Human-Centered Software Engineering (HCSE) Group, Department of Computer Science and Software Engineering, Concordia University, 1455 Maisonneuve Boulevard West, Montreal, Quebec, Canada H3G 1M8, Website: http://hci

4 A USER-CENTERED FRAMEWORK FOR DERIVING A CONCEPTUAL DESIGN FROM USER EXPERIENCES: LEVERAGING PERSONAS AND PATTERNS TO CREATE USABLE DESIGNS Homa Javahery, Alexander Deichman, Ahmed Se?ah, and Mohamed Taleb Human-Centered Software Engineering (HCSE) Group, Department of Computer Science and Software Engineering, Concordia University, 1455 Maisonneuve Boulevard West, Montreal, Quebec, Canada H3G 1M8, Website: http://hci

Computer Science

Share With

---

4 A USER-CENTERED FRAMEWORK FOR DERIVING A CONCEPTUAL DESIGN FROM USER EXPERIENCES: LEVERAGING PERSONAS AND PATTERNS TO CREATE USABLE DESIGNS Homa Javahery, Alexander Deichman, Ahmed Se?ah, and Mohamed Taleb Human-Centered Software Engineering (HCSE) Group, Department of Computer Science and Software Engineering, Concordia University, 1455 Maisonneuve Boulevard West, Montreal, Quebec, Canada H3G 1M8, Website: http://hci.cs.concordia.ca/www Abstract . Patterns are a design tool to capture best practices, tackling problems that occur in different contexts. A user interface (UI) design pattern spans several levels of design abstraction ranging from high-level navigation to low-level idioms detailing a screen layout. One challenge is to combine a set of patterns to create a conceptual design that re?ects user experiences. In this chapter, we detail a user-centered design (UCD) framework that exploits the novel idea of using personas and patterns together.

Personas are used initially to collect and model user experiences. UI patterns are se- lected based on personas peci?cations; these patterns are then used as building blocks for constructing conceptual designs. Through the use of a case study, we illustrate 53 54 HUMAN-CENTERED SOFTWARE ENGINEERING, VOLUME II how personas and patterns can act as complementary techniques in narrowing the gap between two major steps in UCD: capturing users and their experiences, and build- ing an early design based on that information. As a result of lessons learned from the study and by re?ning our framework, we de?ne a more systematic process called UX-P (User Experiences to Pattern), with a supporting tool. The process introduces intermediate analytical steps and supports designers in creating usable designs.

4.1 INTRODUCTION User-Centered Design (UCD) has been proposed in the literature to provide design- ers with a general approach for interactive system design, by making end-users and their experiences a focal point of the design process. Based on UCD principles, dif- ferent design methods have been developed. These include Scenario-based design (Carroll, 2000), Goal-directed design (Cooper, 1999), Contextual design, (Beyer and Holtzblatt, 1998) and Participatory design (Ehn, 1998). These methods introduce tech- niques for evolving and documenting the design at various steps of the process. If a designer would like to model user experiences, tasks, and the context of use—relevant techniques include personas, task analysis, scenarios, work?ow modeling, and con- text analysis. Furthermore, if a designer would like to build a prototype, conceptual design, or detailed design—relevant techniques include design guidelines, principles, style sheets, and patterns. Although these methods share a common user-focused tenet, there exists a signif- icant gap between current user analysis and modeling techniques, and the process of deriving a UI conceptual design. Ethnographic and empirical techniques are generally used to collect relevant user data to describe user experiences. These experiences are then captured in narrative form, but the derivation of a conceptual design from them is ambiguous and based on guided principles rather than a reproducible systematic method. Even if some techniques like storyboarding try to “walk” designers through relevant user tasks, they only address a subset of user experiences. There is little re- producibility of solutions and traceability to user experiences. Often, the ?nal design is only the result of the designer’s background and knowledge rather than the result of following a well-established and standardized method (Preece et al., 2002). In Seffah et al. (2005), the need to build a tighter ?t between user experiences and design concepts is described as one of the main challenges in human-centered software engineering. To advance the state-of-the-art and narrow this existing gap, we require processes that support designers in deriving conceptual designs from user experience descriptions. Such a process should be systematic, traceable, and practical, but should also leave room for design creativity when appropriate. Figure 4.1 highlights the cur- rent lack of such a process. In this chapter, we propose a design framework and associated process to tackle this problem. We investigate personas and patterns as two complementary artifacts which can be correlated for the purpose of narrowing this gap. More precisely, our research is tailored towards the de?nition of a systematic process that derives a pattern-oriented design from persona descriptions, through a set of intermediate steps. The research questions we have addressed are as follows: How can we systematically generate a conceptual design from the model we have of the user experiences? How much DERIVING A CONCEPTUAL DESIGN FROM USER EXPERIENCES 55 Figure 4.1 Current problem of deriving a design from user experiences of this process can be automated or computer-supported? What are the major steps in this process? By de?ning such a process and with tool support, it is possible to empower UI designers with concrete design solutions that can be traced back to the user experiences. This is of great help in empirical or formal validations, as well as when design trade-offs are to be made. In what follows, we will present the core UCD concepts applied relative to our framework, and illustrate it using a case study.

4.2 A FIRST LOOK AT THE PROPOSED FRAMEWORK We have proposed and de?ned a framework to help narrow the gap between user ex- periences and conceptual design. The framework, illustrated in Figure 4.2, exploits two key UCD artifacts. Its starting point is an understanding of user behaviors and experiences, their tasks, and the context of their work. Personas are the ?rst key UCD artifact used. They are created iteratively to model user experiences. Initially, the personas help to identify actual users for predesign usability evaluation of the target application. Evaluation results from psychometric and heuristic assessment are used to categorize potential users into a set of personas, as well as to further enhance them—giving a clearer picture of user behaviors and experiences, their tasks, and the context of use. Other inputs, such as task analysis and scenario generation, are used to re?ne the persona set. Personas are represented by a set of persona elements (examples are age and computer experience) and textual descriptions (examples are general pro?le and interaction behavior). Patterns , the second key UCD artifact used, are then selected based on personas. In HCI, design patterns and their associated languages are used to capture essential details of design knowledge. The presented information is organized within a set of prede?ned attributes, allowing designers, for example, to search rapidly through different design solutions while assessing the relevance of each pattern to their design.

Every pattern has three necessary elements, usually presented as separate attributes, which are: a context, a problem, and a solution. Other attributes that may be included are design rationale, speci?c examples, and related patterns. Furthermore, our patterns include speci?c information about the user needs and usability criteria addressed. The selected patterns are then used as “building blocks” and composed into a pattern-oriented design. By using personas, we are able to have a precise under- standing of the user and context of use. During pattern composition, speci?c steps are followed which add structure to the design activity. This includes the use of a User Experiences UI Conceptual Design ? traceability 56 HUMAN-CENTERED SOFTWARE ENGINEERING, VOLUME II Figure 4.2 The proposed framework pattern-oriented design model which addresses the logical organization of the entire application, as well as the use of pattern relationships. The latter exploits the genera- tive nature of patterns, resulting in a network of patterns which can be combined in a design. As an example, certain patterns are subordinate to others, meaning that they can be composed within their super-ordinate pattern. Further details will be discussed later in this chapter.

4.3 MODELING USER EXPERIENCES WITH PERSONAS Understanding user experiences is the starting crucial step in user-centered design.

Several techniques have been proposed within the HCI community to understand users and to model their needs. This includes user pro?les, stereotypes, and personas. In our UCD-based framework, we extend the concept of personas (Cooper, 1999) to model user experiences. Alan Cooper, the father of Visual Basic, ?rst proposed the use of personas in soft- ware design. His original work in 1999 brought the concept of personas from market- DERIVING A CONCEPTUAL DESIGN FROM USER EXPERIENCES 57 ing to UCD; so as to redirect the focus of the development process towards end-users and their needs. His work emphasizes personas as being ?ctitious characters, based on composite archetypes, and encapsulating “behavioral data” gathered from ethnog- raphy and empirical analysis of actual users. Archetypes have been used in marketing research both as an alternative and as an extension of traditional market segmentation and user pro?ling. Instead of modeling only “average” users, personas also take into account boundary cases. The idea used is that all consumers are a mixture of certain types of users. Each persona should have a name, an occupation, and personal characteristics such as likes, dislikes, needs, and desires. In addition, each persona should outline speci?c goals related to the application or project in question. These goals can be personal (e.g., having fun), work-related (e.g., hiring staff), or practical (e.g., avoiding meet- ings) (Tahir, 1997). Personas are intended to help developers better understand both the users and context of use for a planned tool or interactive system. Cooper (1999) ar- gues that designing for any one external person is better than trying to design vaguely for everyone. He also believes that for each project, a different set of personas should be constructed. This is because each project targets different users in different contexts of use. An example of the kind of information contained in personas is illustrated in Table 14.1. According to (Cooper, 1999), persona’s imaginary, though realistic, representation of users’ goals and skills is bene?cial to designers, programmers, and managers at ending “feature debates.” Personas eliminate the construct of “the user” and guide functional speci?cations. On the other hand, there are some pitfalls to avoid when using personas as an interaction design tool. The major risk, reported by both Pruit and Grudin (2003) and Mikkelson and Lee (2000) is the challenge to get the right persona or set of personas without stereotyping. Persona creation implies choices and biases that could overgeneralize or exclude users. Cooper would reply to this argument saying that it is better to design for any one person instead of ineffectively designing for the “masses.” Figure 4.3, adapted from Whitney Queensberry’s company website (Cognetics, 2005), illustrates an example of a persona. Similar to Pruitt and Grudin (2003), we believe that personas should be based on empirical evidence and studies. Their approach encourages a more “global” use of personas. This includes attempts to integrate personas in the software development process by establishing relationships with other data sets through the use of artifacts such as feature–persona matrices, foundation documents, and task descriptions. A focus on ongoing qualitative and quantitative analysis is a central theme of their work.

In our framework, we use empirical evidence to create our personas and extend their descriptions to include interaction details and scenarios. This will be illustrated in our case study.

4.4 CREATING A CONCEPTUAL DESIGN USING PATTERNS A conceptual design is an early design of the system that abstracts away from presen- tation details. In this section, we will discuss how UI design patterns can be used as design “blocks” to build a conceptual design. To elaborate, UI design patterns have been introduced as a medium to capture, disseminate and reuse proven design knowl- 58 HUMAN-CENTERED SOFTWARE ENGINEERING, VOLUME II Table 4.1 Persona elements Persona Elements Description Identity Include a ?rst and last name, age and other demographic information. Status Whether the user is a primary, secondary, tertiary, or anti- user of the application. Typically, only primary and in some cases, secondary users are included. Goals Besides goals related to the application, it includes personal and professional goals as well. Knowledge and Experience Knowledge and experience including education, training, and specialized skills. This should not be limited only to the application. Tasks Frequency, importance, and duration of most important tasks related to the application. Relationships Include information about user associates, since this could give insight on other stakeholders. Psychological pro?le and Needs Include information about cognitive and learning styles, as well as needs such as guidance and validation of decisions. Attitude and Motiva- tion Include information about the user’s attitude to information technology and level of motivation to use the system. Expectations Information about how the user perceives the system works, and how the user organizes information related to his/her task, domain, or job. Disabilities Any disabilities, such as color blindness, related to mobility, eyesight (wears contacts), etc. Photograph Include a photograph that ?ts with the persona’s identity. edge, and to facilitate the design of more usable systems. As a result, they are a key artifact for user-centered design, with interesting rami?cations for designing across a variety of contexts. Patterns are toolkit-independent, presented in a speci?c format with de?ned attributes, and applicable at different levels of abstraction. These lev- els include the user-task model, navigation model, or the concrete presentation of the user interface (UI). They are a great source of interest not necessarily because they provide novel ideas to the software designer community, but because of the way that they package already-available design knowledge. This way of presenting information to designers promotes reusability of best design practices, and avoids reinventing the wheel each time we develop a design. Based on the original work of Christopher Alexander (1979), some HCI practition- ers have proposed to connect individual patterns to create pattern languages. Exam- ples are patterns for Web page layout design (Welie, 2003), for navigation in large DERIVING A CONCEPTUAL DESIGN FROM USER EXPERIENCES 59 Favorite Quote: “A designer knows he has achieved perfection not when there is nothing left to add, but when there is nothing left to take away,”– St-Exupery Company: Cognetics Corporation Name: Linda Title: Interaction Designer Age: mid-30’s Membership: SIGCHI, UPA and a local usability discussion group Favorite Tool: The whiteboard—or anything that lets me iterate the design quickly. Education: M.S. in HCI Specialties: Web, Intranet, Database Searching Duties: Interview Users, De?ne Requirements, Produce Visual Designs, Produce Speci?cations, Coordinate Usability Testing, and Pro- duce UI Style Guide Summary: After initially graduating with a Computer Science degree, Linda spent several years as a Web administrator and programmer for two software companies. She then returned to school to complete an HCI degree and joined Cognetics upon completion of her de- gree. With the vision in place, she works with users to analyze their needs and requirements. She uses that data to produce a draft of a UI and manages an iterative design process, combining expert review with usability testing. She starts the design process in Visio, but she prefers to construct low-?delity HTML proto- types as soon as possible for both review and testing. Once the design is stable, Linda typically delivers annotated specs for the full interface and the user interface style guide used to construct the prototype. Constraints: Linda is one of the few women who are red-green colorblind.

Access to users for user analysis is not always feasible, so Linda must sometimes gather user data in more creative ways (tech sup- port logs, surveys, remote interviews, etc.).

Figure 4.3 Example of persona (Cognetics, 2005) information architectures (Engelberg and Seffah, 2002), as well as for visualizing and presenting information (Wilkins, 2003). Different pattern collections have been pub- lished including The Design of Sites (Duyne et alt., 2002) and Designing Interfaces (Tidwell, 2005). In addition, speci?c languages such as emphUser Interface Design Patterns (Laakso, 1993) and the UPADE Web Language (Javahery and Seffah, 2002) have been proposed. However, to support pattern use as part of the design process, speci?c frameworks or methods are needed. To this end, Thomas Erickson (Erickson, 2000) proposed using pattern languages as a lingua franca for the design of interactive systems, with 60 HUMAN-CENTERED SOFTWARE ENGINEERING, VOLUME II Figure 4.4 A Site Map page implemented using Tree Hyperbolic, a sophisticated visual- ization pattern the purpose of disseminating the HCI body of knowledge. Such an approach assumes that several types of relationships exist between patterns. Pattern-Supported Approach (PSA) (Lafreni ` ere and Granlund, 1999) links patterns with the purpose of supporting early system de?nition and the derivation of a conceptual design. In this direction, the set of design patterns that forms a language are also linked to the task model. As a consequence, during system de?nition and task analysis, appropriate design patterns are chosen for the design phase. However, none of the above languages, frameworks or methods effectively lever- ages relationships between patterns. Relationships between patterns are key notions in the understanding of patterns and their use. In Taleb et al. (2006), we have de?ned ?ve types of relationships between Web patterns. Pattern-Oriented Design (POD) (Javah- ery and Seffah, 2002) aims to exploit explicitly these relationships, as well as associate patterns and their languages to the design process. POD consists of understanding when a pattern is applicable during the design process, how it can be used, as well as how and why it can or cannot be combined with other related patterns. Moreover, to be effective in a user-centered design setting, patterns need to be bet- ter associated with user experiences. Our framework tackles this problem by linking personas with patterns, allowing us to narrow the gap between user experiences and conceptual design. Patterns are chosen based on persona speci?cations, and then com- bined to create a pattern-oriented design. In essence, pattern-based designs are consid- ered as design blocks that apply in particular situations, based on a description of the user experiences. Figures 4.4 and 4.5 portray examples of pattern-oriented designs. DERIVING A CONCEPTUAL DESIGN FROM USER EXPERIENCES 61 Figure 4.5 A Home Page Design combining several patterns 4.5 AN ILLUSTRATIVE CASE STUDY We applied the proposed framework to a design project with a popular Web appli- cation, aimed at a speci?c user community—the National Center for Biotechnology Information (NCBI) site (NCBI, 2005). The goals of the study were to (1) evaluate whether the framework results in a more usable system, (2) evaluate the validity of correlating personas and patterns for designers, and (3) understand the limitations of the framework. It would lead us to conclude that we could either develop a more re- ?ned process leading from personas to patterns, or that our framework needs to be reworked. The NCBI site is a well-established Bioinformatics website, with a large number of users and a vast amount of information. Some of the NCBI’s speci?c aims include the creation of automated systems for storing and analyzing biological information, the facilitation of user access to databases and software, and the coordination of efforts to gather biotechnology information worldwide (Attwood and Parry-Smith, 1999). High user access and a great deal of content can often cause usability problems. Further- more, the site acts as an information portal which aims to be a unique access point to diverse and specialized bioinformatics tools. Users accessing and interacting with the site and its tools have different behaviors ranging from simple information gather- ing, such as article searching, to more advanced molecular biology tool usage, such as 62 HUMAN-CENTERED SOFTWARE ENGINEERING, VOLUME II sequence alignment and molecular visualization tools. It is these interaction and task- based behaviors, in addition to typical user characteristics such as age and application experience, that should be considered by designers as part of their user experience modeling. They should be correlated to different steps in the entire UCD process, and most importantly, to the creation of an early design. Personas were created iteratively. Our ?rst set contained three personas, which we believed covered the most representative users. As a starting point, we used do- main analysis and ethnographic interview results to postulate representative users of the NCBI site, including information about their experiences. A biomedical expert ad- vised us on domain-speci?c information. The main user attributes that were taken into consideration in differentiating our personas were age, work environment, and appli- cation experience. Our initial ?eld observations indicated that these attributes would strongly in?uence user behavior. First, we observed a relatively wide age range in our end-users (from young to older adults). Older users were less comfortable with site navigation. They indicated issues with cognitive and memory load, and dif?culty remembering various sequences (of actions) which they had performed earlier. Furthermore, compared with other groups, older users seemed uncertain about their actions; they were more cautious about using newer technology, and required more guidance. Second, we had users from industry, academic, and clinical (medical practitioner) settings. Based on our ?eld observations, we expected variations in behavior among users depending on their work environment.

For example, users from industry were driven by deadlines and time limits. They demonstrated less patience, and were looking for task ef?ciency and more control over the system. Thirdly, application experience seemed to in?uence both the needs and satisfaction levels with the website. Basic users, who had just started to use the site within the past year, were dissatis?ed. They demonstrated a sense of confusion about site structure and navigation, expressed information overload, and indicated that they needed more support. Intermediate users were more satis?ed, but indicated that some of the tools they needed could “work better.” Expert users were also quite satis?ed, but indicated that the website was slow at times and they wanted to perform their tasks in a more ef?cient manner. As highlighted previously, if constructed effectively, a persona should be suf?- ciently informative and engaging so that it redirects the focus of the development process towards end-users and their needs. However, constructing such an effective persona is not easy. Therefore, as a means to increase their effectiveness, a persona should be supported by user and empirical data (Pruitt and Grudin, 2003). To enhance and render our personas more informative, we decided to gather more speci?c user and behavioral information from usability evaluations with end-users and UI experts. We had 39 participants in our study: 16 users for creating personas and predesign evaluation, and 23 users for post-design evaluation. Predesign evaluation consisted of psychometric and heuristic techniques to construct personas and identify usability is- sues with the current design. We then used these personas, as well as accrued usability results, to construct a UI design based on patterns. Post-design evaluation consisted of a comparative study between the new and current designs. This was to determine DERIVING A CONCEPTUAL DESIGN FROM USER EXPERIENCES 63 whether our framework added value to the design process, and helped with the overall usability of the application.

4.5.1 Psychometric Evaluation to Quantify User Experiences Psychometric evaluation enables us to quantify user experiences with certain proper- ties of an application or site. In our study, we dedicated part of the questionnaire with our NCBI users to collect this information; the other part was used to gather user char- acteristics such as demographic details. Similar to McKenzie (2000), heuristics were used to describe different facets or properties of the site, although the questionnaire was used for psychometric-based evaluation. In other words, each set of questions was correlated with a particular heuristic. Using a list of nine heuristics adapted from Nielsen (1994) and Nielsen et al. (2001), we were able to cover the most important aspects of usability by asking speci?c questions. For example, if we are to take the ?rst heuristic, Visibility and Navigation, the following tailored questions were asked to assess user experiences with relation to the visibility and navigation of the site: Do you ?nd it easy to navigate on the NCBI website, especially when perform- ing a new task?

Is it visually clear what is a link or a button?

Do you receive feedback and requested information promptly, such as when you perform a BLAST search?

Is it easy to get lost when looking for information? When we analyzed the results of the administered questionnaire, results differed for users with varying application experience. Speci?cally, with relation to a number of properties of the site: (1) Visibility and Navigation, (2) Consistency and Standards, and (3) Help; two groups emerged (we have called them Novice and Expert users).

The results can be found in Figure 4.6. The only property of the site that both user groups seemed to be satis?ed with was Language and Communication. Other at- tributes which we had initially thought to also affect user experiences with the site did not demonstrate any signi?cant differences.

4.5.2 Heuristic Evaluation We carried out a second type of test with UI experts, who were asked to directly com- ment on a set of accepted principles, similar to the heuristics described above. How- ever, in contrast to the psychometric evaluation, heuristic evaluation is an inspection method where UI experts evaluate a program’s user interface against the heuristics.

Nielsen introduced heuristic evaluation as a relatively low-cost method for identifying usability problems in an existing program (Nielsen, 1994). To reduce testing costs, Nielsen came up with a list of 10 heuristics that cover what he considered the most important aspects of usability. We used a small number of UI experts (three) for heuristic evaluation. The number was small due to resource limitations of this project rather than to go with Nielsen’s 64 HUMAN-CENTERED SOFTWARE ENGINEERING, VOLUME II Figure 4.6 Questionnaire results of Novice and Expert users claim that “3 to 5” evaluators is suf?cient (Nielsen, 2001). One evaluator was a senior usability expert, whereas the other two were junior usability experts, with at least 2 years of experience in the ?eld. The UI experts were asked to comment on the NCBI site with relation to nine heuristics (we found two to be redundant for our purposes, and therefore combined them), as well as to give comments and suggestions for im- provement of navigation structure, home page, site map, and search tools. In addition, they were given space to write any other comments they deemed relevant that were not covered in the heuristics or speci?c items asked. A concise version of results is as follows: all heuristics, except for Language and Communication, were found to be problematic. Major problems found by UI experts were: (1) easy to get lost because path or current position is unclear, (2) dif?cult to get out of undesired or error states, (3) inconsistency amongst sites, such as with different menu structures, (4) informa- tion overload, (5) not enough help and guidance for novice users, (6) lack of ef?cient options for expert users, such as shortcuts. These results were similar to our earlier ethnographic interviews with users. In addition, UI experts were asked to comment on the following speci?c items of the site: (a) navigation structure, (b) home page, (c) site map, and (d) search tools.

The navigation structure was found to be big and fairly complex, so it is easy for users to lose their orientation on the site. The home page was found to be overloaded with links, low in visibility, and no guidance for ?rst time users. 2 out of 3 UI experts sug- gested that it might be interesting to consider a different home page for different users, based on their experience with the site (i.e., Novice vs. Expert users). In practice, a site map is designed to give users who know what they are looking for, fast access to a certain subsite; and for new users, additional help in locating a page or topic. The site map for the NCBI site was found to be complicated and dif?cult to use for either of these groups of users. Search tools on the NCBI site were found to be relevant for DERIVING A CONCEPTUAL DESIGN FROM USER EXPERIENCES 65 more experienced users, but more explanation and control should be given to newer users.

4.5.3 Pattern Selection and Composition We started off with three personas for NCBI site users. However, after re?ning the personas based on empirical results from our predesign evaluation, two predominant personas emerged. To stimulate the imagination of the designers, we de?ned them based primarily on application experience with the NCBI site and associated tools:

(1) the Novice tool user, with less than 1 year experience, and (2) the Expert tool user, with more than 1 year experience. Furthermore, based on the different empirical tests described, our personas were enhanced with information about user behavior and experiences. Each persona was characterized by (a) personal characteristics, (b) computer and bioinformatics skills, (c) interaction behavior with the site, including tasks performed, and (d) scenario descriptions. By using this newly gathered information, we applied pattern-oriented design to close the gap between actual user experiences and the features offered by such com- plex applications. We associated patterns with each type of desired task and user be- havior, and combined them to design a more usable UI. The patterns used were from Web pattern languages—UPADE (Javahery and Seffah, 2002) and Welie’s collection (Welie, 2003). As illustrated in Table 4.2, we selected applicable patterns based on information contained within our personas. After pattern selection, we combined patterns into a comprehensive design. Pattern-oriented design may be used to create Web applications that customize the solution of common problems for different personas. Alternatively, they can guide designers in ?nding compromise solutions based on design trade-offs. One ideal design strategy in this case would be the implementation of separate home pages for novice and expert users. The two different home pages would actually be the result of using different types of patterns for each group of users. Although this strategy may be ideal for the user community, our context information revealed that its practicality and maintenance would be limited for such a large website, with a site architecture that is so multifaceted. It therefore made more sense to settle for a compromise, making the site usable for both types of users. Taking into account earlier evaluation results, the two personas and the original NCBI site, one example of a design decision is as follows: The left navigation menu on the home page has important site links, however a textual description of the link is provided under each name; this is only useful for novice users who don’t know what kind of information they can ?nd from the links. This convenience for the novice user is a hindrance for an expert user as it contributes to more scrolling. A solution would be implementation as rollovers (on-?y description pattern) to help new users. Using the selected patterns, we built a new design for a subset of the NCBI site—this included the portal home page, the main navigation elements, the site map, search tool, and some content pages. Selected pattern compositions are illustrated in Figure 4.7 (as a pattern skeleton) and in Figure 4.8 (the prototype). 66 HUMAN-CENTERED SOFTWARE ENGINEERING, VOLUME II 4.5.4 Testing the Prototype After applying the Persona to Pattern framework to the NCBI site, the resulting con- ceptual designs were used as a blueprint to build a test prototype. We evaluated the prototype in terms of usability, using principles of software usability measurement Table 4.2 Pattern Selection based on persona Persona 1 Persona 2 Donna Smith (The Novice User) 24 years old; Master’s student in Biochemistry; works daily in a lab Needs: Guidance, Simple Navigation Xin Li (The Expert User) 37 years old; Molecular Biologist; researcher in a pharmaceutical com- pany Needs: Control, Task Ef?ciency Attribute/behavior Patterns Attribute/behavior Patterns She recently started doing bioinformatics- based research, and has only been access- ing the NCBI site for 6 months Novice user patterns He has been access- ing the NCBI site for 2 years now, and is very familiar with tools re- lated to his research Expert user patterns She is unfamiliar with all the menu options and functions and of- ten needs guidance On-Fly Description English is his second language, and he is not always comfort- able with spelling Index Browsing Alphabetical Sitemap She is still learning about the NCBI site, and wants general in- formation about the site Executive Summary He uses the NCBI site for speci?c tasks, such as secondary structure prediction and wants to save results Shortcut MySpace (customized) She uses the site mainly for liter- ature and article searches, information- gathering, and has only started to do sequence alignment searches Index Browsing Simple Search Likes to limit his searches to speci?c species and does not have patience to go through a long list of possibilities Advanced Search She gets lost looking for information after advancing more than 3 layers, and needs to go back to a safe place Convenient Toolbar Dynamic Path Likes to know about recent discoveries and advances in the ?eld Teaser Menu Executive Summary DERIVING A CONCEPTUAL DESIGN FROM USER EXPERIENCES 67 based on ISO standards, and as indicated in (Msheik et al., 2004). We conducted a comparative study with the current NCBI site, which according to (NCBI, 2005), has been designed following “usability and user-friendly design guidelines.” Our participants this time included 23 users; 19 users who ?t our novice persona and 4 users who ?t our expert persona. The set of participants were selected initially based on a phone interview to assess whether they ?t our study. Furthermore, these 23 users were different from the original set of users who participated in our predesign heuristic and psychometric evaluations. We primarily differentiated based on applica- tion experience, where novice users had limited or basic experience, and expert users had intermediate or advanced experience. For novice users, we used a between-subjects (randomized) design, where each participant was assigned to a different condition (Dix et al., 1993): (1) the prototype built using our framework and (2) the current site. On one hand, by using a between- subjects protocol, we were able to control any learning effects which would have oc- curred if each user tested both conditions. On the other hand, this type of protocol required a greater number of participants and a careful matching of participants be- tween the two conditions; the reason being that individual differences between users can bias the results. Task duration, failure rates, and satisfaction ratings were collected and analyzed as usability indicators. Users were given four common tasks to perform on the website, with the purpose of calculating task duration and failure rates. A questionnaire was employed to rank their satisfaction. We used ANOVA (Analysis of Variance) tests to assess if the mean values were signi?cantly different between the two conditions. We also computed effect size, eta-squared ( η2), which is a measure (of the magnitude) Figure 4.7 Pattern Skeleton of NCBI home page Convenient toolbar Shortcut pattern Index browsing pattern Executive summary pattern Executive summary Teaser menu Executive summary pattern Search pattern On-Fly description 68 HUMAN-CENTERED SOFTWARE ENGINEERING, VOLUME II Figure 4.8 Pattern-Oriented Design of NCBI home page of the effect of a difference, independent of sample size. In HCI, due to commonly small sizes of studies, effect size has been found to be appropriate (Landauer, 1997).

In general the greater the value of η2is, the greater the effect. Some HCI practitioners (McGrenere, 2004; McGrenere et al., 2002) use the following metrics for interpreting eta-squared: 0.01 is a small effect; 0.06 is medium; and 0.14 is large. The results were all statistically signi?cant: Task duration: Overall improvement of 55% for prototype; F (1, 14) = 6.4, p <0.05, η2=0.67 Failure rates: Overall improvement of 100% for prototype; F (1, 16) = 6.4, p <0.05, η2=0.29 Satisfaction ratings: Overall improvement of 82% for prototype; F (1, 16) = 11.53, p < 0.05, η2=0.42 Since expert users already had extensive experience with the NCBI site, we per- formed only qualitative evaluations with them using both structured and open-ended interviews. They were given time to explore both the prototype and current site, and were asked a set of questions based on their experience. They were asked to give DERIVING A CONCEPTUAL DESIGN FROM USER EXPERIENCES 69 ?rst impressions about both sites (likes/dislikes and any noticeable differences), as well as answer speci?c questions about individual Web pages (such as the portal home page), the overall site, and ease of navigation. Results varied in response. Two out of four users preferred the prototype, and noted that it was more “simplistic” and “lightweight.” Other comments included that the prototype introduced less informa- tion overload and increased clarity. They also found it easier in terms of navigation, although they commented that they would need to get used to the new design. The other two users did not have an overall preference, but preferred different aspects of the two designs. Overall, the qualitative results with experts were what we expected.

Expert users have been using the site for an extended amount of time; they are used to speci?c visual representations, habituated in performing tasks in a certain manner, and are comfortable with the current navigation path.

4.5.5 Lessons Learned The results from the NCBI study were encouraging, and they led us to conclude that a more concrete process leading from personas to patterns was substantiated. First, we found that applying the framework facilitated our design activities, al- lowed us to incorporate sound UCD principles into our design, and afforded guidance to an often ad-hoc process. The focus of the design activity was directed to the users early on. Since, personas are a relatively lightweight user model, we did not require a user or cognitive modeling specialist for their creation. By developing personas iter- atively using empirical evidence, we were able to determine more precise interaction behavior and usability problems with the application; these points were essential in se- lecting HCI patterns. In this vein, the framework follows the reuse paradigm through the use of these patterns, enabling us to make design decisions based on best practices.

Notably, in current practice, there exists no commonly agreed upon UI design process that employs patterns and their languages as ?rst class tools. It was our intention to further develop the framework to overcome this problem. Second, after applying the Persona to Pattern framework to the NCBI site, we car- ried out comparative usability studies with the current site and our prototype. We wanted to evaluate if the framework resulted in more usable systems. The results were positive for both quantitative and qualitative measures. In particular, our prototype indicated a statistically signi?cant decrease in task duration and an increase in satis- faction with novice users. For total task time, we noted an overall improvement of more than 55%. Moreover, when we considered average satisfaction ratings of both designs, we found that users were almost two times more satis?ed with our prototype as compared to the original design. As expected, our qualitative results with expert users were also positive but more mixed, since they have extensive experience with the current site. Thirdly, there were some limitations we needed to address. The framework was a ?rst step in using the techniques of personas and patterns together. We noted that links made between user experiences and design solutions were based on narrative and qualitative data, assessed manually where the “best” pattern within a speci?c context was selected. Any further development of our framework should include identi?- able and discrete steps, and not be subject to extensive interpretation by the designer. 70 HUMAN-CENTERED SOFTWARE ENGINEERING, VOLUME II This would require some formalization of the information contained in both personas and patterns. We also realized early on that we would refer back to the personas for additional information both during the selection of appropriate patterns, and for pattern-oriented design. At times, the amount of additional information contained within personas was lacking. Therefore, an enhancement of persona descriptions with interaction behaviors, scenarios, and goals is an added value in guiding designers dur- ing design decisions.

4.6 A DETAILED DESCRIPTION OF UX-PROCESS Based on the initial knowledge extracted from the NCBI study and re?ned by informa- tion collected from focus groups and interviews, we constructed a process following a natural ?ow as currently applied by design experts. The process is called UX-P, or User Experiences to Patterns. In this section, we will describe each phase of the process, its inputs, outputs, and artifacts produced. Figure 4.9 illustrates the process diagram, by depicting the ?ow of activities involved. The activities, which correspond also to the process steps, are grouped into three distinct phases: Persona Creation, Pattern Selection, and Pattern Composition. Persona Creation takes user data as input and is expected to produce a set of representative personas. Pattern Selection takes the personas and a pattern library as input, and produces an ordered set (based on im- portance and relevancy) of candidate patterns for design. Based on these candidate patterns, the Pattern Composition phase results in a conceptual design. It is important to note that context information serves as input during all phases of the design.

4.6.1 Persona Creation Persona Creation consists of three steps and a decision point: clustering users, veri- fying that the clusters ?t the context, modifying clustering parameters if needed and re?ning personas. In essence, clustering consists of grouping users based on their similarities and by analyzing a set of parameters. Once the users are grouped, it is important to ensure that the results produced ?t the context of the current design. If the veri?cation proves the clustering to be inadequate, the designer must modify the parameters used and repeat the clustering. In fact, clustering should be repeated as many times as required until the results are satisfactory. Once clusters are appropriate, each resulting cluster can be represented by a skeleton persona. Finally, these skele- ton personas can be re?ned by completing the description based on real data from representative users. Overall, the clustering step consists of grouping users based on their commonal- ities. Therefore, this step is a good candidate for automation allowing user involve- ment. In fact, k-means clustering or other statistical analysis techniques, when pro- vided grouping parameters and a set of data, are capable of performing this task. Thus, the major dif?culty is in presenting data in computer-readable format and producing ?exible results. The proposed solution is to describe a user by a set of variables grouped into cate- gories. In order to assist the specialist, a ?nite amount of the categories and variables must be de?ned. Moreover, each variable must have a ?nite amount of values. There- DERIVING A CONCEPTUAL DESIGN FROM USER EXPERIENCES 71 Figure 4.9 The UX-P Design Process 72 HUMAN-CENTERED SOFTWARE ENGINEERING, VOLUME II fore, it is proposed to have a set of basic categories that may evolve with time or change based on the domain. Each category contains up to 10 variables with 5 pos- sible values. For example, a category Knowledge and Experience contains a variable Input Skills that can vary from none to expert. We propose to have a small amount of categories and variables in order to provide a concise and complete description of the user. Once the users are described in computer-readable format, it is possible to interact with the clustering algorithm. More precisely, a specialist can use one or more avail- able automated grouping techniques in order to favor some aspects of the similarities between analyzed users. That is, it might be more important to group users based on their cognitive style than on their computer experience, or identify strong correlations without ignoring boundary cases. In any case, this step is part of a creative process and cannot be fully automated.

4.6.2 Pattern Selection The pattern selection phase is composed of three steps and one decision point. This phase resides at the core of our process. The steps are selecting patterns based on personas, modifying the selection parameters, and ?ltering the pattern set. For select- ing patterns based on personas, the personas created in the previous step are taken as input. For each persona, patterns are suggested and prioritized, based on a set of rules.

The designer has a decision point at this step; if she/he is not satis?ed with the pattern set, the selection parameters can be modi?ed. These two steps are repeated until the pattern set is satisfactory. Finally, the designer can ?lter the pattern set based on the envisioned design model. In essence, mapping consists of logically linking a set of patterns to the personas. It is expected that this step can be automated or at least computer supported. As a result, a library of patterns should be presented in a format that will allow automation and, at the same time, that can be interpreted by specialists. As a solution, we propose to reuse the idea of user variables, presented above, and describe patterns as a set of characteristics grouped into categories—which we call pattern variables . In fact, we propose to separate human-readable and computer speci?c variables in different cate- gories. More precisely, we have added a set of pattern variables to the standard textual description of a pattern: usability-design criteria affected by a given pattern (such as minimalist design or logical organization ) and a special need criterion allowing us to relate a pattern to a particular user group like color blind users. In this way, we can link these criteria to personas based on their usability and special needs.

4.6.3 Pattern Composition This phase consists of one step: composing patterns. This is purely a design activity where selected patterns from the previous phase are used to create a design. Recall that a valuable advantage of patterns and their associated languages is their generative nature, meaning that they can essentially be combined together as building blocks.

However, design is an activity dependent on each designer’s creativity, background, and expertise. Our goal is to simply provide some structure to the design activity, DERIVING A CONCEPTUAL DESIGN FROM USER EXPERIENCES 73 Figure 4.10 Website structure using three basic information patterns by presenting designers with: (1) a Pattern-Oriented Design (POD) model, and (2) a means to exploit pattern relationships. Artifacts such as task and interaction models may be used during this step, although they are external to our process. The designer iterates through various compositions until a satisfactory pattern-oriented design is attained. First, designers should follow a POD model. We have published literature on this model previously (Javahery et al., 2006). POD de?nes the overall design composition of a particular type of application, including a breakdown of this composition into dif- ferent UI facets. The model acts as a guide for designers in making stepwise design decisions. To illustrate, for website design, we have de?ned four steps that design- ers should follow: (1) de?ning the architecture of the site with architectural patterns, where an example is illustrated in Figure 4.10, (2) establishing the overall structure of each page with page manager patterns, (3) identifying content-related elements for each page with information container patterns, and (4) organizing the interaction with navigation support patterns. Landay and Myers (2001) and Welie (2003) also propose to organize their Web pattern languages according to both the design process and UI structuring elements (such as navigation ,page layout and basic dialog style ). Second, designers should exploit relationships between patterns. We have de- scribed ?ve types of relationships between the UPADE patterns, published in (Taleb et al., 2006): Superordinate, subordinate, similar, competitor, and neighboring. The same relationships can easily be applied to other pattern libraries. This multicriterion classi?cation is based on the original set of relationships used to classify the patterns 74 HUMAN-CENTERED SOFTWARE ENGINEERING, VOLUME II Table 4.3 UX-P Process steps and tool support No. Steps Tool Input Output Persona Creation 1 Clustering users Y* user data user clusters 1b Modifying clustering pa- rameters Y user clus- ters modi?ed parameters 2 Re?nement of persona set Y user clus- ters personas Pattern Selection 3 Selecting patterns based on personas Y* personas pattern set 3b Modifying selection pa- rameters Y pattern set modi?ed parameters 4 Filtering pattern set Y pattern set ?ltered pattern set Pattern Composition 5 Composing patterns N ?ltered pattern set pattern-oriented design * – automated.

proposed by (Gamma et al, 1995). The relationships are used to compose a UI design, allowing designers to make suppositions such as: For some problem P, if we apply Pattern X, then Patterns Y and Z apply as subor- dinates, but pattern S cannot apply since it is a competitor. 4.7 FURTHER INVESTIGATION: THE P2P MAPPER TOOL As an attempt to better assist designers in using our process, we developed a support- ing tool called the Persona to Pattern (P2P) Mapper. The proposed process involves a set of repetitive, tedious, and time-consuming tasks. In addition, some of the steps and artifacts described in the process have been constructed in a format which allows for automation. The general steps comprising our process are illustrated in Table 4.3. The persona creation and pattern selection phases were amenable for partial automation.

In particular, we automated the following steps: clustering users (step 1) and selecting patterns based on personas (step 3). Moreover, we provided features for users to carry out the remainder of the persona creation and pattern selection phases. The P2P Mapper provides the designer with three major features: (1) the data entry system, (2) the clustering utility, and (3) the pattern selection utility. The data entry system provides the user with an interface to enter, view, and modify user information.

In particular, the designer provides a set of discrete user variables; optionally he/she may also include narrative text illustrating popular user scenarios and other textual descriptions. DERIVING A CONCEPTUAL DESIGN FROM USER EXPERIENCES 75 Figure 4.11 Clustering in P2P Mapper Once the data is entered, the tool provides the designer with automatic and inter- active clustering capabilities (see Figure 4.11) to derive quanti?ed persona speci?ca- tions. Clustering is performed based on the discrete user variables provided during the data entry phase. The tool provides the user with the choice between two clus- tering techniques, namely, k-means clustering and interactive clustering. The former technique is performed fully automatically but requires, apriori, an indication of the desired number of clusters. The latter technique is performed in an interactive man- ner, where the designer selects a subset of the user variables, on which the clustering should be based. The tool then returns a number of clusters, which can be iteratively re?ned and reduced by further constraining the allowed range of values of the selected user variables. Automatic clustering is more suitable for novice designers as it can be used as a black box technique where the required designer intervention is minimal. It leaves, however, the designer with very little control to in?uence the outcome of the clusters.

Iterative clustering is an interactive clustering method, which mimics the designer’s strategy of manually building personas. Hence it provides the user with more in?u- ence on the outcome but requires advanced knowledge of the user variables and the domain on which the clustering will be based. If none of the previously described methods (automatic or interactive clustering) result in the desired set of clusters, the 76 HUMAN-CENTERED SOFTWARE ENGINEERING, VOLUME II tool provides the designer with the option to manually manipulate and enter the various clusters. Once the designer is satis?ed with the set of clusters, a “quanti?ed” persona set is created (see Figure 4.12). Note that these personas are described by user vari- ables and associated values. They should be extended manually by the designer with textual descriptions such as interaction details and scenarios, based on information gathered from representative users. Based on these personas, the designer can use the mapping module in order to create a set of patterns. This step is performed automatically based on the set of per- sonas generated during the previous step. The mapping module selects patterns using a scoring system; where, based on a set of rules, the various patterns are associated with scores. These rules leverage the dependencies between user variables and pattern variables, and simplify the task of a designer who would manually match usability and special needs to particular personas. For example, if our persona is colorblind and has a need for ef?ciency of use , the following patterns apply: (1) the pattern redundant encoding indicates in its context that it is applicable for users with visual de?cien- cies such as color blindness (Wilkins, 2003), and (2) ef?ciency of use is a usability need and one physical design implication would be to apply accelerators. One pattern which is an accelerator is called macros (Tidwell, 2002). After gathering the above information, designers can build a mental model under- standing the potential pattern, its relationship with other patterns, and its applicability in a given context of use. Supplemented by their design experience, they select a subset of these patterns which they compose into a comprehensive design. Figure 4.12 overviews the infrastructure of the P2P Mapper Tool. In its current version, the tool supports the ?rst two phases of the UX-P process, namely, Persona Creation and Pattern Selection. We also note that our tool comes with a prepopulated library containing the formalization of 83 patterns from the following pattern libraries:

GUI (Tidwell, 2005), Web (Javahery and Seffah, 2002; Welie, 2003), visualization (Wilkins, 2003), and our own “special needs” patterns.

4.8 CONCLUSION In current practice, the derivation of a conceptual design from user experiences is based on loosely de?ned guidelines, giving rise to a signi?cant “gap” between user re- quirements and design outcomes. Typically, the outcome is reliant almost completely on the designer’s intuition. This is especially problematic for novice designers who lack the background and training required to make trade-offs, judgments, and interpre- tations towards a usable design. In this chapter we propose a UI design framework to support designers in deriving a conceptual design from user experiences. Its starting point is an understanding of user behaviors and experiences, their tasks, and the con- text of their work. Using different usability methods, empirical studies on all aspects of the user’s interaction with the target application are conducted. Only then can we perform a task analysis and scenario generation; followed by low-?delity prototyping and rough usability studies; resulting in a high-?delity product for more rigorous user testing. The framework exploits two key UCD artifacts. Personas are created iteratively to model user experiences, giving a clearer picture of the user behaviors and experiences, DERIVING A CONCEPTUAL DESIGN FROM USER EXPERIENCES 77 Figure 4.12 Overview of P2P Mapper Tool 78 HUMAN-CENTERED SOFTWARE ENGINEERING, VOLUME II their tasks and the context of use. Other inputs, such as task analysis and scenario generation, are used to re?ne the persona set. Information contained in personas is then used to select appropriate patterns—the second key UCD artifact used. In HCI and empirical software engineering, user-oriented studies are required both to motivate the research as well as to assess the validation and accuracy of the proposals. We therefore applied our framework in a proof-of-concept with a popular Bioinformatics website, which biologists use as a portal to access different analytical tools. The new design was compared to the current design, and resulted in signi?cant improvements in terms of usability. The result was a positive increase in usability measures for the resulting design prototype, including a signi?cant improvement in task times and user satisfaction. Based on the results and lessons learned from our study, we re?ned our framework into a more concrete process, called UX-P (User Experiences to Patterns). The pro- cess consists of three phases, namel, Persona Creation, Pattern Selection and Pattern Composition. Personas and patterns are used as the primary design directives. Fur- thermore, UX-P is based on a set of key UCD principles which we have enriched with “engineering-like” concepts such as reuse and traceability. The process rigorously de?nes a set of steps from persona creation to the composition of a comprehensive design. It incorporates a clustering step as part of persona creation, and a set of rules to select patterns from persona speci?cations. Furthermore, we propose more formal representations for personas and patterns amenable for tool support. We have imple- mented a prototypical tool to provide support for our design process. The P2P Mapper provides the designer with tool support for the persona creation and pattern selection phases, and automates two of the substeps. An interactive environment is provided for the designer where she/he can enter user data, as well as view and modify both personas and candidate patterns. The UX-P process de?nes a methodical link between personas and patterns. The process is traceable since any given conceptual design is composed of patterns, and for any given pattern, a set of user needs can be identi?ed. By systematically mod- eling users with our enhanced personas, the combination of both formal and infor- mal descriptions guides designers during the design process, in decision making, and trade-offs to be made. The formal descriptions as user variables are amenable for au- tomatic analysis by the P2P Mapper. Furthermore, we extend pattern descriptions to include knowledge about usability design principles and user groups which have spe- ci?c needs, such as novice users or those that are colorblind. Pattern selection is based on a set of rules, inferred from dependencies between user variables, pattern variables, and usability principles. The rules were implemented within a scoring system which takes user variables as input and outputs a list of patterns, ordered by their relevance. Our research resulted in an initial design process to derive conceptual designs from user experiences; however, it led to additional research questions that can be avenues for further research. First, we described two types of associations between users and patterns, through their needs: a direct association with special needs, and an indirect association with usability needs. These associations allow designers to select a set of patterns appropriate to their design. An interesting possibility for investigation would be to further ?lter patterns based on task type. Recall that pattern descriptions make DERIVING A CONCEPTUAL DESIGN FROM USER EXPERIENCES 79 reference to typical tasks of the user-task model. Some patterns are only applicable for a particular task type (i.e., Advanced Search Pattern and tasks of type search ). These task types could act as further input into pattern selection, rather than being manually assessed by designers. Second, both our persona and pattern descriptions are a good starting point in stan- dardizing the representation of personas and patterns, respectively. In current practice, personas are constructed based on general narrative guidelines and contain information which allows them to be little more than a communicative tool. Furthermore, pattern writers have few guidelines in constructing patterns. This results in little consistency in the structuring and de?nition of pattern descriptions for pattern libraries. It would be interesting to explore the use of both our descriptions as a standard representation of these two artifacts in HCI. Thirdly, the associations discovered between user variables and pattern variables were based on knowledge elicited from HCI experts. It would be valuable to test each one of these through experimentation with end-users, to determine their precise im- pact. In this vein, we note that our scoring system is based on the heuristics elicited during expert consultation. Our knowledge elicitation activities concentrated on es- tablishing associations between user experiences and design solutions attempting to satisfy user needs. A further improvement of our scoring system can be its enhance- ment with learning capabilities. Hence, the current implementation of the rules can be understood as an initial con?guration of a future expert system or a neural network, which may be further adjusted and ?ne tuned based on the assessment of the quality of the results. One of the major problems we found is that mastering and applying large col- lections as well as different types of patterns requires in-depth knowledge of both the problems and forces at play. As such, it is inconceivable that the mapping rules and ensuing pattern composition will evolve strictly from theoretical considerations.

Practical research and industry feedback are crucial in determining how successful a pattern-oriented design framework is at solving design problems. It is therefore es- sential to build an “academia–industry bridge” by establishing formal communication channels between industrial specialists in UI design patterns, as well as pattern re- searchers. It is hoped that such collaboration will lead to a common POD framework that is essential in making the large diversity of patterns accessible to common UI de- signers. At this time, the POD approach including the list of patterns and relationships has been de?ned and illustrated for websites and Web applications. We can extend these ideas to other types of applications as well. In addition, further investigation is required to explore the scalability of the approach for multiple pattern-oriented designs and platforms; as well as strategies for providing heuristics and computer-support to designers during the pattern composition phase.

References Alexander, C. (1979). A Timeless Way of Building . New York: Oxford University Press. Attwood, T. and Parry-Smith, D. (1999). Introduction to Bioinformatics . Addison Wesley Longman Higher Education, Essex. 80 HUMAN-CENTERED SOFTWARE ENGINEERING, VOLUME II Holtzblatt, K. and Beyer, H. (1998). Contextual Design: De?ning Customer-Centered Systems . San Francisco, CA: Morgan Kaufmann. Carroll, J. M. (2000). Making use: Scenario-based design of human-computer inter- actions . Cambridge MA: MIT Press. Cooper, A. (1999). The Inmates Are Running the Asylum: Why High Tech Products Drive Us Crazy and How to Restore the Sanity . Indianapolis, IN: Sams. Corporation, C. (2005). Persona of a cognetics design specialist. http://www.cognetics.com/about/team/people4.html. Dix, A., Findlay, J., Abowd, G., and Beale, R. (1993). Human Computer Interaction . Prentice Hall: New York. Duyne, D. K. V., Landay, J., and Hong, J. I. (2002). The Design of Sites: Patterns, Prin- ciples, and Processes for Crafting a Customer-Centered Web Experience . Addison- Wesley, Reading: MA. Ehn, P. (1998). Work-Oriented Design of Computer Artifacts . Ph.D. thesis. Stockholm: Arbetslivscentrum. Engelberg, D. and Seffah, A. (2002). Design patterns for the navigation of large in- formation architectures. In 11th Annual Usability Professional Association Confer- ence , Orlando, FL. Erickson, T. (2000). Lingua francas for design: sacred places and pattern languages. In Proceedings of DIS’00: Designing Interactive Systems: Processes, Practices, Methods, & Techniques , Pattern Languages, pages 357–368. Gamma, E., Helm, R., Johnson, R., and Vlissides, J. (1995). Design Patterns: Elements of Reusable Object-Oriented Software . Addison Wesley Professional Computing Series. http://www.aw.com. Javahery, H. and Seffah, A. (2002). A model for usability pattern-oriented design. In Pribeanu, C. and Vanderdonckt, J., editors, Task Models and Diagrams for User Interface Design: Proceedings of the First International Workshop on Task Mod- els and Diagrams for User Interface Design - TAMODIA 2002, 18-19 July 2002, Bucharest, Romania , pages 104–110. INFOREC Publishing House Bucharest. Javahery, H., Sinnig, D., Seffah, A., Forbrig, P., and Radhakrishnan, T. (2006). Pattern- based UI design: adding rigor with user and context variables. In Proceedings of TaMoDia 2006 , Hasselt. Laakso, S. (1993). Collection of user interface design patterns. University of Helsinki, (September 16, 2003); http://www.cs.helsinki.?/u/salaakso/patterns/. Lafreni ` ere, D. and Granlund, A. (1999). A pattern-supported approach to user interface design. UPA 99 Workshop Report ; http://www.gespro.com/lafrenid/Workshop_Report.pdf . Landauer, T. K. (1997). Behavioral research methods in human-computer interaction. In Handbook of Human-Computer Interaction . Amsterdam: North-Holland, 2nd edition. Landay, J. A. and Myers, B. A. (2001). Sketching interfaces: toward more human interface design. IEEE Computer , 34(3). McGrenere, J. (2004). Iterative design and evaluation of multiple interfaces for a com- plex commercial word processor. In Seffah, A. and Javahery, H., editors, Multiple DERIVING A CONCEPTUAL DESIGN FROM USER EXPERIENCES 81 User Interfaces: Cross-Platform Applications and Context-Aware Interfaces .New York: Wiley. McGrenere, J., Baecker, R. M., and Booth, K. S. (2002). An evaluation of a multiple interface design solution for bloated software. In Proc. of SIGCHI, CHI’02 , pages 164–170. ACM Press. McKenzie, K. (2000). 10 usability heuristics. http://www.studiowhiz.com/ _publications/10heuristics.php . Mikkelson, N. and Lee, W. (2000). Incorporating user archetypes into scenario-based design. In UPA Workshop . Msheik, H., Abran, A., and Lefebvre, E. (2004). Compositional structured component model: Handling selective functional composition. In EUROMICRO , pages 74–81. IEEE Computer Society. NCBI (2005). National Center for Biotechnology Information. http://www.ncbi.nlm.nih.gov/. Nielsen, J. (1994). Heuristic evaluation. In Nielsen, J. and Mack, R. L., editors, Us- ability Inspection Methods . New York: Wiley. Nielsen, J. (2001). How to conduct a heuristic evaluation. (November 2001); http://www.useit.com/papers/heuristic/heuristic evaluation.html. Preece, J., Rogers, Y., and Sharp, H. (2002). Interaction Design: Beyond Human- Computer Interaction . New York: Wiley. OCLC 48265540. Pruitt, J. and Grudin, J. (2003). Personas: practice and theory. In Proceedings of DUX’03: Designing for User Experiences , number 6 in Informing DUX, pages 1–15, New York. ACM Press. Seffah, A., Gulliksen, J., and Desmarais, M. C., editors (2005). Human-Centered Software Engineering: Integrating Usability in the Development Process . Wiley, Boston. Tahir, M. (1997). Who’s on the other side of your software: creating user pro?les through contextual inquiry. In Proceedings of Usability Professionals Association Conference UPA ’97 , Monterey. Taleb, M., Javahery, H., and Seffah, A. (2006). Pattern-oriented design composition and mapping for cross-platform Web applications. In Proceedings of DSV-IS 2006 , Dublin. Tidwell, J. (2002). Ui patterns and techniques. http://timetripper.com/ uipatterns/index.php . Tidwell, J. (2005). Designing interfaces : Patterns for Effective Interaction Design . Cambridge, MA: O’Reilly. Welie, M. (2003). Interaction Design Patterns. http://www.welie.com/.

Wilkins, B. (2003). MELD: A Pattern Supported Methodology for Visualization De- sign . Ph.D. thesis, submitted to The University of Birmingham, School of Com- puter Science.