patterns. We will define a pattern-based design framework, which helps designers derive an early UI prototype, or conceptual
design, from specified variables. These variables abstract important properties from the user and context of use. The
resulting UI prototype is then used for stakeholder evaluations and early usability testing. Design flaws are detected at a very
early stage within UI development and can be recovered with little effort. Finally the prototype serves as a basis for the actual
implementation of the UI.
2. Pattern-Based User Interface Development
Interactive application development typically commences with the elicitation of user requirements by investigating the
characteristics of the target user group, performing a detailed task analysis, and determining relevant platform constraints. In current
practice, user requirements are often captured in narrative form with no standard representation. To make matters worse, there is
no mature process which supports the systematic transformation of user requirements and context information into concrete design
solutions. Typically, the design is reliant almost completely on the designer’s previous experience.
Our intention is to narrow the current gap between user requirements and conceptual design. To be able to effectively
design user interfaces, it is important to capture and represent user requirements and context information in a rigorous manner. This
entails representing the user model in a more formal form, facilitating automated analysis and processing. Within our
approach, we represent each user description, or persona [14], in the form of variables with discrete domains. Each representative
user is characterized by the set of variable assignments. Additionally we establish qualified links between the personas
and selected tasks of the user task model. These links are used to further tailor tasks of the user-task model to specific user groups.
Examples of the qualifications used are: Task preference, task frequency
and preferred device. For the design phase, in order to foster the reuse of proven and
valid design solutions, we employ Pattern-Oriented Design POD as our foremost design directive. Therefore, based on the
collection of user and context variables, a set of applicable patterns is selected and Pattern-Oriented Design POD is carried
out. 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. An example outlining its use is presented in Section 2.3.
Figure 1 depicts our pattern-based UI development process. The process commences after requirements elicitation and hence
assumes the existence of a task model and information about user characteristics. It comprises the following three major phases:
User and Context Abstraction: Relevant information about
representative users and context of use information are captured as discrete variables into a requirements matrix.
Pattern Selection: The mapping module is rule-based, and maps
the variables of the requirements matrix with pattern variables in order to extract a set of applicable patterns.
Pattern-Oriented Design:
The designer further filters the pattern set by choosing appropriate patterns. At this stage, the creativity
and experience of the designer plays an important role. The patterns are then used within a pattern-oriented design process to
derive the conceptual design of the user interface.
In what follows, we will discuss each of the three phases in greater detail.
Fig. 1. The Pattern-Based UI Design Process.
2.1 User and Context Abstraction
The first step of our pattern-based UI design process consists of abstracting important user properties from our persona
descriptions [14]. In order to increase persona effectiveness as a technique, we develop our personas iteratively using ethnography,
domain analysis and empirical evidence; we also extend them to include information about interaction behavior, user tasks and
goals [15]. In current practice, user information is often captured in narrative form, with no standard representation. In order to
make these requirements amenable for tool support and automated analysis, we represent them by a set of variables grouped into
categories. In its current stage, our user variables are grouped into five basic categories; each of them containing about six variables,
with one of five possible values. For example, the category Knowledge and Experience
contains a variable ‘System Experience’ that can vary from novice to expert on a five-point
scale. Another example is the category Psychological Profile and Needs
which contains variables such as ‘Initiative Taking’
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 andor a fee.
Conference’04
, Month 1–2, 2004, City, State, Country. Copyright 2004 ACM 1-58113-000-0000004…5.00.
proactivereactive user and ‘Control’ amount of control a user needs while interacting with a system.
In addition, each persona is linked to a set of context variables. Selected higher-level user tasks, which are domain-dependent,
and platform preferences, become important factors for later pattern selection. Examples of tasks relevant to our case study on
a web-based application see Section 3 are: ‘Search database’, ‘Browse list’, and ‘Open Tool’, with examples of their user-
dependent properties being Frequency of use, Importance and Duration
. Furthermore, platform preferences such as Preferred Device
are included as context variables. An important characteristic of our process is that task and device
requirements are not universally valid across all categories of users. For example, for a novice user the search task may be less
important than the browse task, since heshe may not be familiar with the search criteria. The advanced user however, may rate the
search task as more important. In a similar manner the preferred device may vary between user groups. Currently we distinguish
between three types of platforms: web, GUI, and mobile applications. We adopted this classification from [12] who uses a
similar classification for his interaction design patterns.
The requirements matrix is a nested table, whose cells contain tuples as entries. Each row of the table represents a different
persona. The persona properties are categorized into user and context variables. Variables and categories of variables can be
ranked according to importance and impact, as determined by the designer. It is also important to note the task entries contain
references to the corresponding node in the task model. These references will help the designer in the later stages of the process
to select and apply the patterns appropriately. From a process- point of view, these references help in tracing task-related entries
back to their origins in the task model.
The selected variables from personas are used as input for the next step of our process, which consists of selecting a set of
applicable patterns. After the requirements matrix has been completed, the mapping module analyzes the information in order
to select appropriate patterns. This step will be described in the next section.
2.2 Pattern Selection
