itijij IijIIi ii.

i
3 1155 06067687 6

SHNEIDERMAN • PLAISANT • COHEN • JACOBS • ELMQVIST

SIXTH EDITION

DESIGNING THE USER INTERFACE

STRATEGIES FOR EFFECTIVE
inift/iAM rnr/iDHTCD INTERACTION
 • COHEN • JACOBS • ELMQVIST

SIXTH EDITION
CCD
I INTERFACE
( trl-tl TIVF
INTERACTION

NOTE: This material may be protected by copyright law (Title 17 U.S. code\
This copy is being furnished for private research use only.

PEARSON
Boston Columbus Indianapolis New York San Francisco Hoboken
Amsterdam Cape Town Dubai London Madrid Milan Munich Paris Montreal Toronto
Delhi Mexico City Sao Paulo Sydney Hong Kong Seoul Singapore Taipei Tokyo
IM reseat; ■ Gaining
I

11
 CHAPTER

Just as we can assert that no product has ever been created in a

single moment of inspiration . . . nobody has ever produced a set
of requirements for any product in a similarly miraculous manner.
These requirements may well begin with an inspirational moment
but, almost certainly, the emergent bright idea will be developed
by iterative processes of evaluation until it is thought to be worth
starting to put pencil to paper. Especially when the product is
entirely new, the development of a set of requirements may well
depend upon testing initial ideas in some depth. 99
W. H. Mayall
Principles in Design, 1979
60 The p|an is the generator. Without a plan, you have lack of order

and willfulness. The Plan holds in itself the essence of sensation. 99

Le Corbusier
Towards a New Architecture, 1931

CHAPTER OUTLINE
4.1 Introduction 4.5 Design Methods

4.2 Organizational Support for Design 4.6 Design Tools, Practices, and Patterns

4.3 The Design Process 4.7 Social Impact Analysis

4.4 Design Frameworks 4.8 Legal Issues

99
 100 Chapter 4 Design

4.1 Introduction
1
Design can be loosely defined as the outcome or the process of creating
specifications for synthetic artifacts, such as products, services, and processes.
All manufactured objects in the world—objects that were made by people and
are not found in nature—are the result of some form of design piocess, whether
a deliberate one or otherwise. User interfaces, which are very much synthetic
and decidedly do not occur in nature, are no exception. Howe' er, while early
computer manufacturers were quick to enlist industrial designers to shape the
physical form factors of the first computers, they were much less agile in recog­
nizing the need for interaction design (Moggridge, 2007): the design of the digital
interface itself. Now an established design discipline in its own right, interaction
design is defined as making plans and specifications for digital objects, which
include devices, interfaces, services, and information.
Every time designers create a new digital artifact, they make decisions—
unconscious or not—on how the artifact will look, feel, and function. If they
carefully consider how digital products and services are created, they can make
appealing products and services that respond to human needs with user inter­
faces that are easy to leant, comprehensible, and efficient to use. Early computer
applications were designed by programmers to be highly functional for the pro­
grammers themselves and their peers, but this approach quickly failed when the
audience for computers grew to non-technical fields. Bill Moggridge (2007) calls
this phenomenon being "kind to chips but cruel to people," and it was an early
failing of interaction design.
The current generation of users for smartphones, social media, and e-
commerce have vastly different backgrounds from programmers and engineers.
They have no interest in obscure interfaces but are more oriented toward
their professional or recreational needs and are less dedicated to the technol­
ogy itself. Therefore, effective interaction design takes the intended user as its
starting point and focuses on facilitating the function of the artifact. As a
result, professional interaction designers carefully observe their users, itera­
tively refine their prototypes based on thoughtful analysis, and systemati­
cally validate their interfaces through early usability and acceptance tests.
However, as for any design discipline, function is not the only important
aspect of a digital object. Form is another aspect, and it sometimes comes in
conflict with function. While on the one hand it can be argued that good form
will facilitate function (since an aesthetically appealing artifact can invite
use), it is also true that a highly convoluted form may inhibit it. Consider a
kitchen cabinet door with no handles: slick and appealing according to
contemporary design sense but lacking visual indications of how and where
to open the door. In fact, it may not even be immediately obvious that a door
 4.1 Introduction 101

with no handles is in fact a door, let alone that it can be opened! The same
is true for interfaces: It often makes sense to let form follow function
(Sullivan, 1896). Tradeoffs between form and function are discussed in
Chapter 12.
If there are several similarities between interaction design and other design
disciplines, what is particularly unique about interaction design? One of the
key characteristics of digital media is that they are freely reproducible without
consuming the original copy or costing additional resources. They also have
few of the physical requirements that real materials must obey, such as cost,
ease of manufacturing, or physical robustness. In essence, information tech­
nology is thus a "material without qualities" (Lowgren and Stolterman, 2004).
For software engineering, this fact has led to the global open source move­
ment, where programmers, even professional ones, are willing to give away
the results of their hard work for free. In the context of interfaces and interac­
tions, digital media mean that designers work under few physical constraints
compared to tangible artifacts. A digital button can be arbitrarily large or
small, or it can be entirely gold- or diamond-plated, with no added or reduced
cost to the overall project. In fact, the designer can freely experiment with any
number of alternate designs during the process without incurring any other
cost than time. However, this added freedom is a double-edged sword in that
constraints can often be helpful in reducing the space of potential designs (also
known as the design space) and even boosting the creativity of the designer;
after all, necessity is said to be the mother of invention. With no such helpful
constraints to reduce the design space for digital interfaces and objects, inter­
action designers are often left with a much more daunting problem than
industrial designers working in the real world.
The key to good design starts in the organization itself. The primary reason
for this is that design is unpredictable, which requires an agile organizational
structure as well as a comprehensive business strategy oriented around diverse
design processes. In fact, some companies, such as Apple, Pepsi, Philips, and
Kia Motors, have hired chief design officers (CDOs) in recognition of this
unpredictability. Section 4.2 offers examples of such structures and strategies
that managers can adapt to suit their organizations, projects, schedules, and
budgets.
This unpredictable and dynamic nature requires a robust and flexible
design process. Section 4.3 describes a four-phase iterative design process
consisting of requirements analysis (Phase 1), preliminary and detailed
design (Phase 2), build and implementation (Phase 3), and finally evaluation
(Phase 4, described in Chapter 5). This cycle is repeated until the outcome
from the evaluation phase is acceptable given the requirements. The design
cycle itself is part of a larger cycle that incorporates the entire life cycle of a
product, including deployment, maintenance, and new updates to the
system.
102 Chapter 4 Design

Design frameworks are discussed in Section 4.4 and permeate the entire
design philosophy and design methods used in the process. Three specific
frameworks are of particular interest to interaction designers: agile and rapid
prototyping, user-centered design, and participatory design. The exact choice of
which design framework to use depends on the organization, the project team,
and the product being designed.
If frameworks provide the high-level structure, then the design methods are
the building blocks that are used to populate the structure. Section 4.5 reviews
popular interaction design methods for each phase of the design process, includ­
ing ethnographic observation and sketching (Phase 1), storyboarding and sce­
nario development (Phase 2), and paper mockups and protot ping (Phase 3).
Evaluation methods for Phase 4 are described separately in Chapter 5.
Design is a challenging activity and is difficult to learn in a purely theoretical
setting, particularly for newcomers but also for seasoned designers entering a
new domain. Section 4.6 offers several practical, hands-on best practices to facil­
itate the design process, including UX prototyping tools, UX guidelines docu­
ments, and the notion of design patterns for interaction design and UX. Originally
derived for as disparate areas as urban planning (Alexander, 1977) and software
engineering (Freeman et al., 2004), design patterns are concrete and reusable
solutions to commonly occurring problems. The section shows how such design
patterns can be applied to interaction design.
This chapter concludes with Section 4.7, which describes legal concerns that
should be addressed in the design process, including topics such as privacy,
safety, intellectual property, standardization, and certification.

See also:
Chapter 5, Evaluation and the User Experience
Chapter 12, Advancing the User Experience

4.2 Organizational Support for Design

Most companies may not yet have chief usability officers (CUOs) or vice
presidents for usability, but some companies are beginning to employ chief
design officers (CDOs), which may help to promote usability and design think­
ing at every level. A case in point is Apple Inc., which was one of the first com­
panies with a CDO and which accordingly has been praised for its innovative,
 4.2 Organizational Support for Design 103

well-designed, and usable products. Even if a company has no CDO, organiza­

tional awareness can be stimulated by presentations, internal seminars, news­
letters, and awards. However, resistance to new techniques and changing roles
for software engineers can become a problem in traditional organizations.
Organizational change is difficult, but creative leaders blend inspiration and
provocation. The high road is to appeal to the desire for quality that most profes­
sionals share. When they are shown data on shortened learning times, faster per­
formance, or lower error rates on well-designed interfaces, managers are likely to
be more sympathetic to applying usability-engineering methods. Even more
compelling for e-commerce managers is evidence of higher rates of conversion,
enlarged market share, and increased customer retention. For managers of con­
sumer products, the goals include fewer returns/complaints, increased brand
loyalty, and more referrals. The low road is to point out the frustration, confu­
sion, and high error rates caused by current complex designs while citing the
successes of competitors who apply usability-engineering methods.
Collecting momentum for organizational change can come from different
sources. Major corporations almost always question the return on investment
(ROI) for usability engineering and interaction design. However, the business
case for focusing on usability has been made powerfully and repeatedly (Karat,
1994; Marcus, 2002; Bias and Mayhew, 2005; Nielsen, 2008). Claire-Marie Kar­
at's (1994) business-like reports within IBM became influential documents
when they were published externally. She reported up to $100 payoffs for each
dollar spent on usability, with identifiable benefits in reduced program-devel­
opment costs, reduced maintenance costs, increased revenue due to higher cus­
tomer satisfaction, and improved user efficiency and productivity. Other
economic analyses showed fundamental changes in organizational productiv­
ity (with improvements of as much as 720%) when designers kept usability in
mind from the beginning of development projects (Landauer, 1995).
The necessary pressure for change may also come from the customers them­
selves. Corporate marketing and customer-assistance departments are becom­
ing more aware of the importance of usability and are a source of constructive
encouragement. When competing products provide similar functionality,
usability engineering is vital for product acceptance. Today's customers are dis­
cerning and expect high quality, and their overall brand loyalty is steadily
diminishing. Retaining as well as increasing its customer base can provide a
powerful incentive for an organization to improve its focus on interaction design
and usability engineering.
Finally, usability engineering is required for certification and standardization
in some industries. For example, the aerospace industry has Human Systems Inte­
gration (HSI) requirements that deal with a combination of human factors, usabil­
ity, display design, navigation, and so forth (National Research Council, 2007).
As a result, most large and many small organizations now maintain a
centralized human factors group or usability/UX laboratory as a source of
 104 Chapter 4 Design

expertise in design and testing techniques. In fact, many organizations have

created dedicated usability laboratories to provide expert reviews and to con­
duct usability tests of products during development in carefully supervised
conditions (Rubin and Chisnell, 2008). Beyond internal usability teams, outside
experts can sometimes provide fresh and unbiased insights on difficult design
and usability decisions. These and other evaluation strategies are covered in

11 Chapter 5.
Organizational support for usability testing is not sufficient, however, but
should also include the creative parts of the design process. Each, project should
have its own user-interface architect who develops the necessary skills, man­
ages the work of other people, prepares budgets and schedules, and coordinates
£ with internal and external human-factors professionals when further expertise,
references to the literature, or usability tests are required. Organizations with a
strong design ethos understand this, and their example can be used in enacting
change in more traditional corporations.
There are interaction design activities where the ROl for usability analysis
during the development cycle is not immediately apparent but true usability of
the delivered system is crucial for success. One familiar example is voting
machines. An end result of confused, misinterpreted voting results would be
catastrophic and counter to the best interests of the voting population, but the
usability analysis and associated development costs should be manageable by
the government contractor building the electronic voting system.
As the field of interaction design has matured, projects have grown in com­
plexity, size, and importance. Role specialization is emerging, as it has in fields
such as architecture, aerospace, and book design. Interaction design takes on
new perspectives when writing web, mobile, or desktop applications, with an
emerging discipline in translating the same information across each of these
media. Eventually, individuals will become highly skilled in specific problem
areas, such as user-interface-building tools, graphic display strategies, voice
and audio design, shortcuts, navigation, and online tutorial writing.
Consultation with graphic artists, book designers, advertising copywriters, text­
book authors, game designers, or animators is expected. Perceptive system
developers recognize the need to employ psychologists for conducting experi­
I mental tests, sociologists for evaluating organizational impact, educational psy­
chologists for refining training procedures, and social workers for guiding
customer-sendee personnel.
Usability engineers and user-interface architects, sometimes called the user
experience (UX) team, are gaining experience in managing organizational
change. As attention shifts away from software engineering or management­
information systems, battles for control and power manifest themselves in
budget and personnel allocations. Well-prepared managers who have a concrete
organizational plan, defensible cost/benefit analyses, and practical develop­
ment methodologies are most likely to be winners.

I
 4.3 The Design Process 105

4.3 The Design Process

Design is inherently creative and unpredictable, regardless of discipline. In the

context of interactive systems, successful designers blend a thorough knowl­
edge of technical feasibility with an uncanny aesthetic sense of what attracts and
satisfies users. One way to define design is by its operational characteristics
(Rosson and Carroll, 2002):
«» Design is a process; it is not a state, and it cannot be adequately represented
statically.
o The design process is nonhierarchical; it is neither strictly bottom-up nor
strictly top-down.
o The process is radically transformational; it involves the development of partial
and interim solutions that may ultimately play no role in the final design.
o Design intrinsically involves the discovery of new goals.
These characterizations of design convey the dynamic nature of the process. An
iterative design process based on this operational definition would consist of
four distinct phases (Fig. 3.1): requirements analysis (Phase 1), preliminary and
detailed design (Phase 2), build and implementation (Phase 3), and evaluation
(Phase 4). This is a bare-bones process that describes its overall structure; indi­
vidual applications of this process in specific design teams and for specific
design artifacts will differ in terms of the frameworks, methods, and tools used.
The primary feature of this process is that it is iterative and cyclical; unlike linear

Project start
Phase 1: Phase 2
Requirements Preliminary Cr
analysis detailed design
INCEPTION
pro
?

DEPLOYMENT
Phase 4: Phase 3:
Evaluation Implementation
Project end

FIGURE 4.1
An iterative design process for interaction design.
106 Chapter 4 Design

waterfall models where one phase of a pipeline feeds the next, our design pro­
cess repeats each phase over and over until the final product is of acceptable
quality. Second, there are several cross-cutting factors that contribute to each
phase of the cycle, including academic and user research, guidelines and
standards, and tools and patterns. Each of these is described below.
Our focus here is purely on the human and social aspects of an interactive
system or product, but the overall design process encompasses also technical
aspects. Many technical design processes, such as in software engineering, fol­
low a similar four-phase cycle, allowing interaction design and engineering to
be integrated with them easily.

4.3.1 Phase 1: Requirements analysis

This phase collects all of the necessary requirements for an interactive system or
device and yields a requirements specification or document as its outcome. In
general, soliciting, capturing, and specifying user requirements arc major keys
to success in any development activity7 (Selby, 2007). Methods to elicit and reach
agreement upon interaction requirements differ across organizations and indus­
tries, but the end result is the same: a clear specification of the user community
and the tasks the users perform.
Collecting interaction design requirements is part of the overall requirements
analysis and management phase and often has a direct impact on the engineer­
ing aspects of the design; for example, a finger painting app requires a multi­
touch display with low touch latency. Thus, even requirements documents
written specifically for user experience and interaction design aspects are often
specified in terms of three components (see Box 4.1 for specific examples):
• Functional requirements define specific behavior that the system should sup­
port (often captured in so-called use cases, see below);
• Non-functional requirements specify overall criteria governing the operation
of the interactive system without being tied to a specific action or behavior
(hardware, software, system performance, reliability, etc.); and
• User experience requirements explicitly specify7 non-functional requirements for
the user interaction and user interface of the interactive system (navigation,
input, colors, etc.).
Requirements documents provide a shared understanding between the
members of the product team. The success or failure of software projects often
depends on the precision and completeness of this understanding between all
the designers, developers, and users. What happens without adequate require­
ments definition? You are not sure what problem you are solving, and you do
not know when you are done.
Box 4.1 gives an example of interaction design requirements for an
e-commerce website, an ATM, and a mobile messaging app. Be careful not to
 4.3 The Design Process 107

BOX 4.1
Examples of requirements regarding system behavior for three distinct types of
interactive systems: an e-commerce website, an ATM, and a mobile messaging app.

Functional requirements:
o Website: The website shall allow users to purchase items and shall pro­
vide other, related merchandise based on past visits and purchases.
c ATM: The system shall let users enter a PIN code as identification and
shall ensure that the code matches the one on file.
• Mobile app: The app shall be able to send messages at all times, even when
out of the service area (in which case they are saved for later sending).

IMon-functional requirements:
° Website: The website shall give users the ability to access their user
account at all times, allowing them to view and modify name, mail
address, e-mail address, phone, etc.
ATM: The system shall permit the ATM customer 15 seconds to make a
selection. The customer shall be warned that the session will be ended if
no selection is made.
• Mobile app: Messages should send within 2 seconds, returning the user
to the new message window (continuing in the background if necessary).

User experience requirements:

• Website: The website shall always have a visible navigation menu in the
same position on the screen.
• ATM: On-screen prompts and instructions shall be clear and accessible.
The ATM should return the user's commands within half a second.
• Mobile app: The mobile app shall support customization such as color
schemes, skins, and sounds.

impose human operator actions (requirements) onto the interaction design

requirements. For example, it is best not to specify a requirement like this: “The
user shall decide how much to withdraw from the ATM within 15 seconds."
Rather, allocate that same requirement to the computer system: “The ATM shall
permit a user 15 seconds to select a withdrawal amount... before prompting for
a response."
While it is possible to write functional requirements as simply an informal list
of actions (as in Box 4.1), the concept of a use case from software engineering can
come in handy here because of its direct connection to users and interaction. Put
simply, a use case is a formalized scenario that captures an operation between
an actor and the system (in general software engineering, the actor could be
108 Chapter 4 Design

another system, but the focus is on human users here) in a step-by-step manner.
The rule is that a system should simply be a sum of its use cases: No functional­
ity should be implemented that does not explicitly support at least one use case.
This also gives a straightforward recipe for evaluating the system (in Phase 4); if
all use cases can be completed successfully, the system is correct and valid.
Several methods exist for actually collecting and analyzing interaction design
requirements, including ethnographic observation, focus groups, and user inter­
views. Common among all of these is that they are intended to monitor the con­
text and environment of real users, either in action or in their own words. Section
4.5 describes these methods in detail. Tradeoffs between what functions are
done best by computers versus humans in human-computer interaction (Section
3.3.6) should also be discussed at this point in the development process.

4.3.2 Phase 2: Preliminary and detailed design

The core of the design process is realizing the requirements from the previous
phase. The design phase in turn consists of two stages: a preliminary stage,
where the high-level design or architecture of the interactive system is derived,
and a detailed stage, where the specifics of each interaction are planned out. The
outcome from the design phase is a detailed design document.
The preliminary design is also known as architectural design, and in engineer­
ing settings this stage often entails deriving the architecture of the system. For
user experience and interaction design, preliminary design consists of mapping
out the high-level concepts such as the user, controls, interface displays, naviga­
tion mechanisms, and overall workflow. Preliminary design can also be called
conceptual design, particularly in software engineering, because it is sometimes
useful to organize the high-level concepts into a conceptual map with their rela­
tions. Overall, this activity is about developing the mental model that users
should have about the interactive system when using it. Is your system focused
on a central view, such as a map or a table, or is it a sequence of forms or a set of
linked displays? Is it an app that integrates with other apps to pop up on
demand, or is it intended for focused, sustained use? These are questions to
answer and refine during this stage.
The high-level concepts and their relations provide a starting point for the
detailed design. This stage entails planning out all of the operations that take
place between user and interactive system to a level where only implementation
and technical details remain. Regardless whether you are using the use case
concept discussed in the previous section, this can be done by creating and refin­
ing a step-by-step list for the exchanges between the user and the system.
One difficulty in designing interactive systems is that customers and users
may not have a clear idea of what the system will look like when it is done.
Since interactive systems are novel in many situations, users may not realize
the implications of design decisions. Unfortunately, it is difficult, costly, and
 4.3 The Design Process 109

time-consuming to make major changes to systems once those systems have

been implemented. Although this problem has no complete solution, some of
the more serious difficulties can be avoided if, at an early stage, the customers
and users can be given a realistic impression of what the final system will look
like. Suitable methods for the design phase should thus go beyond eliciting the
needs of the users and instead find ways to fulfill these needs.
Examples of suitable design methods include sketching, paper mockups, and
high-fidelity prototypes. Furthermore, all methods can be informed through the
use of tools, patterns, and best practices. For example, guidelines documents
give direction on specific design choices, such as menu design, display layout,
and navigation techniques. Patterns suggest effective ways to design an inter­
face, such as single-page applications for websites or multi-document interfaces
for desktop tools. Dedicated wireframing tools allow for rapidly creating mock­
ups of a design. Section 4.6 discusses these tools and patterns in depth.

4.3.3 Phase 3: Build and implementation

The implementation phase is where all of the careful (or not very careful at all,
depending on your design approach; see the agile development framework in
Section 4.4.1) planning gets turned into actual, running code. The outcome from
this phase is a working system, albeit not necessarily the final one. The actual
software and hardware engineering needed to achieve this are outside the scope
of this book. It is worth, however, briefly mentioning some suitable software
development platforms for interactive applications based on your computing
platform:
• Mobile: Building mobile apps typically requires using the SDK (software
development kit) and development environment provided by the manu­
facturer of the operating system: the Android SDK in Java, the Apple iOS
SDK in Objective-C, and the Windows Phone/Mobile SDKs. Most of these
SDKs require registering as a developer to have access to the app exchange
for making your app available to general users. Since mobile app develop­
ment typically is cross-platform—the development is actually conducted on a
personal computer—all of these SDKs include emulators for testing the app
on a virtual phone residing on the personal computer itself.
• Web: The browser has become a ubiquitous information access platform,
and modern web technologies are both pervasive and full-featured to the
point that they can emulate or replace traditional computer software. Web
applications and services typically consist of both client and server software:
Client-side software runs in the user's browser and is accordingly built in
JavaScript—the programming language of the browser—whereas server-side
software runs on the web server or connected hosts and is often implemented
in languages such as PHP, Ruby, Java, or even JavaScript (using [Link]).
110 Chapter 4 Design

A recent change in web development has been to build mobile apps using
web technologies; the resulting app runs in a dedicated browser instance and
is almost indistinguishable from a normal app built using the native SDK
yet has the benefit of being cross-platform across different mobile operating
systems.
• Personal Computers: Developing dedicated applications for a personal
computer typically requires using the native SDKs for the specific operating
system. Development environments such as Microsoft's Visual Basic/C++ are
easy to get started with yet have an excellent set of features. C and the .NET
Framework are other good candidates for your project. For cross-platform
software development that works regardless of operating s\ Siam, Oracle's
Java™ is a popular choice. People who want to write their o\\ n Java programs
can use the Java Development Kit™ 0DK).
Regardless of platform, make sure to evaluate tool capabilities, ease of use,
ease to learn, cost, and performance. Tailor your tool choices for the size of the
job. Building a software architecture that supports your user-interface project is
just as important as it is for any other (particularly large-scale) software devel­
opment activity.

4.3.4 Phase 4: Evaluation

In the final phase of the design cycle, developers test and validate the system
implementation to ensure that it conforms to the requirements and design set
out earlier in the process. The outcome of the validation process is a validation
report specifying test performance. As discussed above, a straightforward
approach to validate a system specified using use cases is simply to check that
each use case can be completed successfully. Since an interactive system is the
sum of all of its conceivable user operations, such a test covers all of the system
functionality. Depending on this outcome, the design team can decide to pro­
ceed with production and deployment of the system or to continue another
cycle through the design process.
Validation is a vital part of the design process. Theatrical producers know
that extensive rehearsals and previews for critics are necessary to ensure a suc­
cessful opening night. Early rehearsals may involve only the key performers
wearing street clothes, but as opening night approaches, dress rehearsals with
the full cast, props, and lighting are required. Aircraft designers carry out wind­
tunnel tests, build plywood mockups of the cabin layout, construct complete
simulations of the cockpit, and thoroughly flight-test the first prototype.
Similarly, website designers know that they must carry out many small and
some large pilot tests of components before release to customers (Rubin and
Chisnell, 2008). In addition to a variety of expert review methods, tests with the
intended users, surveys, and automated analysis tools are proving to be
 4.4 Design Frameworks 111

valuable. Procedures vary greatly depending on the goals of the usability study,
the number of expected users, the danger of errors, and the level of investment.
Chapter 5 covers a range of suitable evaluation methods for this phase in depth.

4 A Design Frameworks

While the design process discussed above generally should remain the same for
all your projects, the approach to performing it may vary. The concept of design
frameworks captures this idea: the specific flavor and approach the design takes to
conducting the design process. More specifically, interaction design practice over
the past few decades has unearthed several unique approaches to conducting the
design process. This section reviews the concepts of user-centered design (UCD),
participatory design (PD), and the nascent idea of agile interaction design.

4.4.1 User-centered design

Many software development projects fail to achieve their goals; some estimates
of the failure rate put it as high as 50% (Jones, 2005). Much of this problem can
be traced to poor communication between developers and their business clients
or between developers and their users. The result is often systems and interfaces
that force the users to adapt and change their behavior to fit the interface rather
than an interface that is customized to the needs of the users.
User-centered design (UCD) is a counterpoint to this fallacy and prescribes a
design process that primarily takes the needs, wants, and limitations of the actual
end users into account during each phase of the design process (Lowdermilk,
2013). Directly involving the intended users in the process constantly challenges
the assumptions of the design team about user behavior in the real world and
gives designers a much-needed understanding of what their users actually
need. In particular, careful attention to user-centered design issues during the
early stages of software development dramatically reduces both development
time and cost. UCD leads to systems that generate fewer problems during devel­
opment and have lower maintenance costs over their lifetimes. They are easier
to learn, result in faster performance, reduce user errors substantially, and
encourage users to explore features that go beyond the minimum required to
get by. Most importantly, UCD reduces the risk of designers building the
"wrong system": a system that the end users neither need nor asked for. In addi­
tion, user-centered design practices help organizations align system functional­
ity with their business needs and priorities.
While the main premise of UCD—user involvement—is straightforward, it is
also its most significant challenge. For example, finding users may be difficult
112 Chapter 4 Design

because of the need to select a manageable number of representative users,

because the users may be unable or unwilling to participate, and because the
users often lack the technical expertise needed to communicate effectively with
the designers. Even when these challenges have been overcome, many users
may not have a clear understanding of what they need in the new system or
product. Successful developers work carefully to understand the business's
needs and refine their skills in eliciting accurate requirements from non­
technical business managers. In addition, since business manage; > may lack the
technical knowledge to understand proposals made by the developers, dialogue
is necessary to reduce confusion about the organizational implications of design
decisions.

4.4.2 Participatory design

Going beyond user-centered design, participatory design (PD) (also known as
cooperative design in Scandinavia) is the direct involvement of people in the col­
laborative design of the things and technologies they use. The arguments in
favor suggest that more user involvement brings more accurate information
about tasks and an opportunity for users to influence design decisions. The
sense of participation that builds users' ego investment in successful implemen­
tation may be the biggest influence on increased user acceptance of the final
system (Kujala, 2003; Muller and Druin, 2012). On the other hand, extensive user
involvement may be costly and may lengthen the implementation period. It
may also generate antagonism from people who are not involved or whose
suggestions are rejected and potentially force designers to compromise their
designs to satisfy incompetent participants.
Participator}' design experiences are usually positive, however, and advo­
cates can point to many important contributions that would have been missed
without user participation. Many variations of participatory design have been
proposed that engage participants to create dramatic performances, photogra­
phy exhibits, games, or merely sketches and written scenarios. For example,
users can be asked to sketch interfaces and use slips of paper, pieces of plastic,
and tape to create low-fidelity early prototypes. A scenario walkthrough can be
recorded on video for presentation to managers, users, or other designers.
High-fidelity prototypes and simulations can also be key in eliciting user
requirements.
Careful selection of users helps to build a successful participatory design
experience. A competitive selection increases participants' sense of importance
and emphasizes the seriousness of the project. Participants may be asked to
commit to repeated meetings and should be told what to expect about their roles
and their influence. They may have to learn about the technology and business
plans of the organization and be asked to act as a communication channel to the
larger group of users that they represent.
 4.4 Design Frameworks 113

The social and political environment surrounding the implementation of

complex interfaces is not amenable to study by rigidly defined methods or con­
trolled experimentation. Social and industrial psychologists are interested in
these issues, but dependable research and implementation strategies may never
emerge. The sensitive project leader must judge each case on its merits and must
decide on the correct level of user involvement. The personalities of the partici­
patory design team members are such critical determinants that experts in
group dynamics and social psychology may be useful as consultants. Many
questions remain to be studied, such as whether homogeneous or diverse
groups are more successful, how to tailor processes for small and large groups,
and how to balance decision-making control between typical users and profes­
sional designers.
The experienced interaction designer knows that organizational politics and
the preferences of individuals may be more important than technical issues in
governing the success of an interactive system. For example, warehouse manag­
ers who see their positions threatened by an interactive system that provides
senior managers with up-to-date information through digital displays may try
to ensure that the system fails by delaying data entry or by being less than dili­
gent in guaranteeing data accuracy. The interaction designer should take into
account the system's effect on users and should solicit their participation to
ensure that all concerns are made explicit early enough to avoid counterproduc­
tive efforts and resistance to change. Novelty is threatening to many people, so
clear statements about what to expect can be helpful in reducing anxiety.
Ideas about participatory design are being refined with diverse users, rang­
ing from children to older adults. Arranging for participation is difficult for
some users, such as those with cognitive disabilities or those whose time is lim­
ited (for example, surgeons). The levels of participation are becoming clearer;
one taxonomy describes the roles of children in developing interfaces for chil­
dren, older adults in developing interfaces whose typical users will be other
older adults, and so on, with roles varying from testers to informants to partners
(Druin, 2002; Fig. 4.2). Testers arc merely observed as they try out novel designs,
while informants comment to designers through interviews and focus groups.
The key characteristic of participatory design is that the design partners are
active, first-class members of the product design team.

4.4.3 Agile interaction design

Traditional design processes can be described as heavyweight in that they
require significant investments in time, manpower, and resources to be success­
ful. In particular, such processes are often not sufficiently reactive to today's
fast-moving markets and dynamic user audiences. Originally hailing from
software engineering, agile development is a family of development methods for
self-organizing, dynamic teams that facilitate flexible, adaptive, and rapid
114 Chapter 4 Design

Intergenerational and interdisciplinary design team from the University of

Maryland's KidsTeam working on new human-computer interaction technologies
using paper prototypes ([Link]

development that is robust to changing requirements and needs. These methods

are based on evolutionary development, where software is built incrementally and
in rapid release cycles. Similarly, rapid prototyping comes from manufacturing
disciplines and describes a family of techniques for quickly fabricating physical
parts or assemblies using computer-aided design (CAD). Both methods counter
traditional heavyweight processes that have plagued design and facilitate a
more flexible and, indeed, agile approach to design. Taken together, the meth­
ods can also be applied to interaction design to enable the rapid creation of
interactive systems to meet user needs. In fact, taking users and usability into
account during agile development may help to address a common weakness of
agile development methods: Constant interface changes due to continuous iter­
ative design may lead to inconsistent and confusing user experience poorly
matched to the user.
Thus, agile interaction design uses lightweight design processes that facilitate
the incremental and iterative nature of agile software developments. Instead of
 4.5 Design Methods 115

Professor Jon Froehlich and his students working in the HCIL Hackerspace at University of
Maryland, College Park.

costly and time-consuming documentation, high-fidelity prototypes, and usabil­

ity evaluation and workshops that are common to heavyweight design processes,
agile interaction design will use sketches, low-fidelity mockups, and fast usabil­
ity inspections (Gundelsweiler et al., 2004). This enables practical and pragmatic
design, short development cycles, and dynamic designs that are responsive to
changing needs. Good resources for more information on agile interaction design
and extreme usability (XU) can be found in Ambler (2002, 2008).
The contemporary "maker culture" movement on technology-based tinkering
and manufacturing is a prime example of agile methods in action, where the
focus is heavily on rapid and informal experimentation and prototyping by
like-minded individuals gathering in so-called makerspaces, hackerspaces, or
fablabs. Fig. 4.3 shows the Hackerspace at University of Maryland, College Park.
For more information on maker culture, see Anderson (2014).

4.5 Design Methods

Design methods are the practical building blocks that form the actual day-to-
day activities in the design process. There are dozens of design methods in the
literature, but designers may want to focus on the most common ones (discussed
116 Chapter 4 Design

below). See Holtzblatt and Beyer (2014) and Jacko (2012) for more details on
specific methods or additional methods beyond these.
What is the relation between design frameworks and design methods? It is
certainly true that specific design frameworks have an affinity to specific design
methods; for example, participatory and user-centered design tends to incorpo­
rate a lot of ethnographic observation, whereas rapid and agile development
employs sketching to a high degree. However, the design frameworks also
provide a flavor for the overall process and each of the design methods: An agile
approach to sketching will focus on collecting quick ideas from ::. • esign team,
whereas a user-centered or participatory approach will let the ■ ended users
themselves be part of the sketching process. The description .v discusses
such variations and affinities.

4.5.1 Ideation and creativity

One way to think about design is as an incremental fixation of the solution
space, where the range of possible solutions is gradually whittled down until
only a single solution exists. This is the final product or service that then goes on
to ship and be deployed. Gradually reducing the solution space in this manner
is called convergence or convergent thinking, particularly for teams of designers

Divergence Convergence Divergence Convergence

/

Initial
specification
I | Potential solutions considered

CO /
S’
s
Pinal product

Time

Iteration #1 Iteration #2 Iteration #3

Project start

FIGURE 4.4
Illustration of how the solutions considered during a design process will grow
(diverge) and shrink (converge) iteratively until they eventually fixate on a single
point, the finished product. This particular design process involves three iterations,
but real processes may have more or fewer iterations.
 4.5 Design Methods 117

who each bring their own expertise and visions to the table. However, employ­
ing convergent thinking alone runs the risk of imposing conformance and
uniformity too early in the process, yielding an end result that is a local rather
than a global optimum. To avoid such local optima, there is a need to introduce
divergence or divergent thinking into the design process as well (Lowgren, 2004).
Fig. 4.4 demonstrates how interleaving divergent and convergent thinking
iteratively can lead to a well-rounded and balanced design process that consid­
ers a large portion of the potential solution space.
Ideation (or idea generation) and creativity techniques are methods for such
divergent thinking in that they require designers to test their limits, abandon
their assumptions, and reframe their problems. Many creativity techniques exist
in the literature, including lateral thinking, brainstorming and brainwriting,
improvisation and role playing, and aleatoricism (incorporation of chance) and
bootlegging (Holmquist, 2008). Common among many of these techniques is
that they incorporate visual aids, sketching (Buxton, 2007), and physical artifacts.
For example, brainstorming often results in mind maps that show the main con­
cepts as bubbles with links describing relations between the concepts. The mere
process of creating hastily drawn visual depictions of ideas and concepts—
sketching (Buxton, 2007)—has been shown to facilitate both divergence and
convergence by inviting both common ground and consensus as well as
deviation and diversity. Fig. 4.5 shows two concept sketches of personal
hovercrafts drawn by two different designers.

Fans

Hjn-fleban

Handlebars Stsnairg
platform
/

□
A. xFoot pegs
4 O' A^
pro»J*

FIGURE 4.5
Concept sketches of personal hovercraft drawn by two different designers
(divergence). In a follow-up step, the designers may work together to combine ideas
from each separate sketch (convergence).
 118 Chapter 4 Design

An in-depth discussion of ideation and creativity techniques is beyond the

scope of this book. Many excellent resources on creativity exist; see, for example,
the book by Buxton (2007).

s 4.5.2 Surveys, interviews, and focus groups

The most straightforward way to elicit requirements and desires from users is
simply to ask them. Surveys—online or paper-based—are the simplest and
cheapest approach and simply entail distributing a questionnaire to represen­
tative users. Online surveys can have significant reach but often yield a low
response rate. Furthermore, the feedback received is often superficial in
nature.
In-person interviews are more labor-intensive than surveys but will yield
more accurate and high-quality responses. Interviews can take place either in
one-on-one settings between designer and user or in focus group discussions
with multiple users and designers. Again, the choice between individual or
group interviews depends largely on cost; a group session requires less time
investment but may not be able to collect in-depth feedback from all partici­
pants. On the other hand, sometimes group dynamics yield synergistic effects
where one participant's response may trigger additional feedback from other
participants. Thus, group interviews are often used in UCD and PD design
frameworks.
Depending on the goal of the interview, the designer will take a structured or
unstructured approach. Structured interviews are essentially verbal surveys, but
the method often lets the designer follow up with additional questions based on
the answer. Unstructured interviews have no specific questions to ask the user,
only a general discussion topic. Successful designers often combine both strate­
gies in the same session: Some questions are fixed, whereas some are more
open-ended. This allows for collecting unsolicited feedback as well as getting
answers to specific questions that the designer did not know to ask but that are
important to the user.
A common problem with soliciting feedback directly from users is that they
often don't really know what they want, either because they are too accus­
tomed to the current way of doing things or because they don't know what is
technologically possible (as well as impossible) to do. For this reason, the
interaction designer often has to take the role of a therapist, trying to tease out
deeper meaning and underlying motivation from the things that participants
say. Furthermore, successful designers are often creative in interpreting par­
ticipant responses and use them as a springboard for future ideas. For exam­
ple, if several users mention that they tend to think of their job duties as a list
of tasks to be crossed out one by one once completed, the designer may use the
idea of a dynamic timeline of tasks as a central metaphor in future sketches
and prototypes.
 4.5 Design Methods 119

4.5.3 Ethnographic observation

The early stages of most methodologies include observation of users. Since
interface users form a unique culture, ethnographic methods for observing
them in the workplace are becoming increasingly important (Fig. 4.2). Ethnog­
raphers join work or home environments to listen and observe carefully, some­
times stepping forward to ask questions and participate in activities (Fetterman,
2009; Dourish and Bell, 2011; Bazeley, 2013). As ethnographers, interaction
designers gain insight into individual behavior and the organizational context.
However, they differ from traditional ethnographers in that, in addition to
seeking understanding of their subjects, interaction designers focus on inter­
faces for the purpose of changing and improving those interfaces. Also, whereas
traditional ethnographers immerse themselves in cultures for weeks or months,
interaction designers usually need to limit this process to a period of days or
even hours to obtain the relevant data needed to influence a redesign (Crabtree
et al., 2012).
The goal of ethnographic observation for interaction design is to obtain the
necessary data to influence interface redesign. Unfortunately, it is easy to misin­
terpret observations, to disrupt normal practice, and to overlook important
information. Following a validated ethnographic process reduces the likelihood
of these problems. Examples of ethnographic observation research include
(1) how cultural probes have been adopted and adapted by the HCI community
(Boehner et al., 2007), (2) development of an interactive location-based service
for supporting distributed mobile collaboration for home healthcare
(Christensen et al., 2007), and (3) social dynamics influencing technological solu­
tions in developing regions (Ramachandran et al., 2007). Box 4.2 provides some
guidelines for how to prepare for the evaluation, perform the field study, ana­
lyze the data, and report the findings.
These notions seem obvious when stated, but they require interpretation
and attention in each situation. For example, understanding the differing per­
ceptions that managers and users have about the efficacy of the current inter­
face will alert you to the varying frustrations of each group. Managers may
complain about the unwillingness of staff to update information promptly, but
staff may be resistant to using the interface because the login process is tedious
and time-consuming. Respecting the rules of the workplace is important for
building rapport: In preparing for one observation, we appreciated that the
manager called to warn us that graduate students should not wear jeans
because the users were prohibited from doing so. Learning the technical lan­
guage of the users is also vital for establishing rapport. It is useful to prepare a
long list of questions that you can then filter down by focusing on the proposed
goals. Awareness of the differences between user communities, such as those
mentioned in Chapter 2, will help to make the observation and interview pro­
cess more effective.
 120 Chapter 4 Design

Guidelines for conducting ethnographic studies for interaction design.

I Preparation
• Understand policies in the target environment (work, home, public
space, etc.).
• Familiarize yourself with the existing interface and its historv
• Set initial goals and prepare questions.
• Gain access and permission to observe or interview.
»
Field study
• Establish a rapport with all users.
• Observe or interview users in their setting, and collect subjective and
objective quantitative and qualitative data.
• Follow any leads that emerge from the visits.
• Record your visits.

Analysis
• Compile the collected data in numerical, textual, and multimedia
databases.
• Quantify data and compile statistics.
• Reduce and interpret the data.
• Refine the goals and the process used.

Reporting
• Consider multiple audiences and goals.
• Prepare a report and present the findings.

Data collection can include a wide range of subjective impressions that are
qualitative or of subjective reactions that are quantitative, such as rating scales
or rankings. Objective data can consist of qualitative anecdotes or critical inci­
dents that capture user experiences or can be quantitative reports about, for
example, the number of errors that occur during a one-hour observation of six
users. Deciding in advance what to capture is highly beneficial, but remaining
alert to unexpected happenings is also valuable. Written report summaries have
proved to be valuable far beyond expectations; in most cases, raw transcripts of
every conversation are too voluminous to be useful.
Making the process explicit and planning carefully may seem awkward to
many people whose training stems from computing and information technol-
°&y- However, a thoughtfully applied ethnographic process has proved to
 4.5 Design Methods 121

have many benefits. It can increase trustworthiness and credibility, since

designers learn about the complexities of the intended environment by visits
to the workplace, school, home, or other environment where the eventual
system will be deployed. Personal presence allows designers to develop
working relationships with several end users to discuss ideas, and, most
importantly, the users may consent to be active participants in the design of
their new interface.

4.5.4 Scenario development and storyboarding

Scenario development builds on the use case concept and allows for develop­
ing specific scenarios when a user engages the interactive system to solve a
particular task. Storyboarding is the use of graphical sketches and illustra­
tions to convey important steps in a scenario (Fig. 4.6). Several additional
methods for scenario development are useful. Often, a flowchart or transition
diagram helps designers to record and convey the sequences of possible
actions; the thickness of the connecting lines indicates the frequency of the
transitions. An easy way to describe a novel system is to write scenarios of
usage and then, if possible, to act them out as a form of theater. This technique
can be especially effective when multiple users must cooperate (for example,
in control rooms, cockpits, or financial trading rooms) or multiple physical
devices are used (for example, at customer-service desks, medical laborato­
ries, or hotel check-in areas). Scenarios can represent common or emergency
situations with both novice and expert users. Personas can also be included in
scenario generation.
Some scenario writers take a further step and produce videos to convey
their intentions. In 2011, Corning Incorporated released a futuristic video
named "A Day Made of Glass" that showed a vision for how interactive sur­
faces can become increasingly incorporated into both our professional and

phone
USER #1 FINDS DATA DATA IS SYNCHRONIZED USER #2 IS NOTIFIED USERS CAN ANALYZE
TOGETHER

Hand-drawn storyboard for collaborative software that allows multiple people to

view a common dataset using their personal smartphones and tablets.
 122 Chapter 4 Design

everyday lives in the near future. Similarly, in 2013, "Future Vision 2020"
showed a similar vision of the future with integrated displays everywhere.
Finally, in 2015, Microsoft released the video "Microsoft: Productivity Future
Vision," which followed several individuals across the globe as they went
2
through their day five to ten years in the future collecting, analyzing, and
2 summarizing their data in mostly professional settings. All three videos fea­
ture large, transparent, and touch-sensitive displays as well as many personal,
small, thin, and even flexible displays that are all seamlessly connected and
integrated with each other. Taken together, these videos all point to an increas­
ingly augmented digital future where computing continues to become part of
the fabric of everyday life.

4.5.5 Prototyping
Prototypes, or physical sketches as Buxton (2007) calls them, arc particularly
powerful design tools because they allow users and designers alike to see and
hold (for physical prototypes) representations of the intended interface. They
also allow the design team to play out specific scenarios and tests using the
prototype. For example, a printed version of the proposed displays can be used
for pilot tests, whereas an interactive display with an active keyboard and
mouse can be used for more realistic tests. Fig. 4.7 shows a hand-drawn sketch
for a mouse equipped with a touch display, and Fig. 4.8 represents the corre­
sponding physical prototype that has been constructed simply by attaching a
smartphone to an off-the-shelf mouse.
Increasing realism, or fidelity, for a prototype governs the time investment
in creating it. Obviously, low-fidelity prototypes are more suitable for early
ideation and creativity because they are easily generated and as easily

smartphone

Lens Mouse
concept

£
optical mouse

FIGURE 4.7
Hand-drawn concept sketch for a so-called LensMouse: a mouse that incorporates
a touch display. The sketch suggests constructing the mouse by simply attaching a
smartphone to a traditional optical mouse.
 4.6 DesignTools, Practices, and Patterns 123

Soft Buttons Soft Scroll Wheel

(left+nght click)

Touch Display

LensBar

Tilted base for

better viewing
angle

Prototype of the LensMouse. This high-fidelity prototype was created by simply

attaching a smartphone on top of a standard wireless optical mouse (Yang et al.,
2010).

discarded; in fact, the very vagueness of a "quick and dirty" sketch

communicates the uncertainty of the ideation process and invites improve­
ments or rejection. Here are some examples of prototypes at different levels
of fidelity:
• Low-fidelity prototypes are generally created by sketching, using sticky
notes, or cutting and gluing pieces of paper together (paper mockups);
• Medium-fidelity prototypes are often called wireframes, provide some
standardized elements (such as buttons, menus, and text fields), even if
potentially drawn in a sketchy fashion, and have some basic navigation
functionality; and
• High-fidelity prototypes look almost like the final product and may have
some rudimentary computational capabilities; however, the prototype is
typically not complete and may not be fully functional.

4.6 Design Tools, Practices, and Patterns

Beyond the theoretical frameworks and methods discussed above, design

activities today are supported by current design practice: tools that have arisen
to support many design methods, guidelines and standards to inform working
designers, and patterns that provide reusable solutions to commonly occurring
problems encountered by interaction designers.
 124 Chapter 4 Design

4.6.1 Design tools

Creating prototypes beyond paper mockups requires using computer programs
to prototype a specific interface or app. The simplest approach is to use general-
2: purpose drawing and drafting applications for this purpose. For example, pro­
totypes have been developed with simple drawing or word-processing tools or
even Microsoft PowerPoint® presentations of screen drawings manipulated
with PowerPoint slideshows and other animation. Other design tools that can
be used are Adobe InDesign®, Photoshop ■, or Illustrator .
Dedicated prototyping design tools are specifically designed for the purpose
of creating interface mockups rapidly and effortlessly. Since the visual design
language varies across different platforms, different tools exist for desktop,
mobile, and web. Many design tools use the actual buttons, dropdown menus,
and scrollbars used in the interfaces on the specific platform. However, this has
the danger of looking "too polished" and suggesting to the user that the inter­
face mockup is final and cannot be changed. To avoid this, design tools such as
Balsamiq Mockups (Fig. 6.4 shows Balsamiq being used in a case study by
Volvo) use a sketchy, hand-drawn look for the interface elements. Similar to a
hastily sketched design on the back of a napkin, the purpose of the hand-drawn
look is to convey to the viewer that a design mockup is still a sketch, that it does
not represent the final version of the interface, and that it can still be changed
with little cost or time investment.
Finally, dedicated design tools—so-called graphical user-interface builders—
also exist for the final implementation phase when the development team is
realizing the planned interface. Many of these builders use a drag-and-drop
graphical editor where the interaction designer can construct the final interface
by assembling existing interface elements from a library of elements. Builders
often automatically generate the necessary source code from the graphical spec­
ification, requiring the developer only to write his or her own source code to
manage the events resulting from the user in teraction.

4.6.2 Design guidelines and standards

Early in the design process, the interaction design team should generate a set
of working guidelines. Two people might work for one week to produce a
10-page document, or a dozen people might work for two years to produce a
300-page document. One component of Apple's success with the original
Macintosh was the machine's early and readable guidelines document, which
provided a clear set of principles for the many application developers to follow
and thus ensured harmony in design across products. Microsoft's Windows
User Experience Guidelines, which have been refined over the years, also provide
a good starting point and an educational experience for many programmers.
 4.6 DesignTools, Practices, and Patterns 125

These and other guidelines documents are referenced and described briefly in
the general reference section at the end of Chapter 1. The Eight Golden Rules
of interface design in Section 3.3.4 are also applicable to most interactive
systems.
Guidelines documents are a powerful tool for interaction design because
they
° Provide a social process for developers;
° Record decisions for all parties to see;
° Promote consistency and completeness;
° Facilitate automation of design;
° Allow multiple levels:
° Rigid standards
° Accepted practices
° Flexible guidelines
° Industry-specific guidelines
° Announce policies for:
° Education: How to get it?
° Enforcement: Who reviews?
• Exemption: Who decides?
• Enhancement: Flow often?
Guidelines creation (Box 4.3) is often a social process within an organization in
order to help gain visibility and build support for the guidelines. Controversial
guidelines (for example, on when to use voice alerts) can be reviewed by col­
leagues or tested empirically. Procedures should be established to distribute the
guidelines, to ensure enforcement, to allow exemptions, and to permit enhance­
ments. Effective guidelines documents are living texts that are adapted to chang­
ing needs and refined through experience. Acceptance may be increased by a
three-level approach of rigid standards, accepted practices, and flexible guide­
lines. This approach clarifies which items are firmer and which items are sus­
ceptible to change.
The creation of a guidelines document at the beginning of an implementation
project focuses attention on the interface design and provides an opportunity
for discussion of controversial issues. When the development team adopts the
guidelines, the implementation proceeds quickly and with few design changes.
For large organizations, there may be two or more levels of guidelines to pro­
vide organizational identity while allowing projects to have distinctive styles
and local control of terminology. Some organizations develop "style guides" to
capture this (see, for example, Microsoft, 2014).

I
 126 Chapter 4 Design

BOX 4.3
Suggested content in user experience guidelines documents.

"7'
Words, icons, and graphics
• Terminology (objects and actions), abbreviations, and capitalization
• Character set, fonts, font sizes, and styles (bold, italic, unde line)
• Icons, buttons, graphics, and line thickness
• Use of color, backgrounds, highlighting, and blinking

Display layout issues

• Menu selection, form fill-in, and dialog-box formats
• Wording of prompts, feedback, and error messages
• Justification, white space, and margins
• Data entry and display formats for items and lists
• Use and contents of headers and footers
• Strategies for adapting to very small and very large displays

Input and output devices

• Keyboard, display, cursor control, and pointing devices
• Sound, voice feedback, speech I/O, touch input, etc.
• Response times for a variety of tasks
• Alternatives for users with disabilities

Action sequences
• Direct-manipulation clicking, dragging, dropping, and gestures
• Command syntax, semantics, and sequences
• Shortcuts and programmed function keys
• Touch input for devices such as smartphones, tablets, and large touch displays
• Error handling and recovery procedures

Training
• Online help, tutorials, and support groups
• Training and reference materials

The four Es provide a basis for creating a living document and a lively process:
• Education. Users need training and a chance to discuss the guidelines.
Developers must be trained in the resultant guidelines.
• Enforcement. A timely and clear process is necessary to verify that an interface
adheres to the guidelines.
 4.6 DesignTools, Practices, and Patterns 127

® Exemption. When creative ideas or new technologies are used, a rapid process
for gaining exemption is needed.
° Enhancement. A predictable process for review, possibly annually, will help
keep the guidelines up-to-date.
While creating and using guidelines documents help ensure success—to the
point that we propose our own Eight Golden Rules (Section 3.3.4)—we also
want to reiterate our argument from Chapter 3 that the discipline of human­
computer interaction needs to transcend specific guidelines and derive basic
theories underlying these phenomena. Our discussion in Section 3.4 presents
several both micro-level and macro-level HCI theories to which most practical
guidelines can be traced back. While a list of guidelines can be highly useful
precisely because they are practical and pragmatic, successful designers remain
aware of the underlying theories from where they stem.

4.6.3 interaction design patterns

Design patterns, originally proposed for urban planning (Alexander, 1977) and
later software engineering (Freeman et al., 2004), are best-practice solutions to
commonly occurring problems specified in such a way that they can be reused
and applied to slightly different variations of a problem over and over again.
Regardless of discipline, patterns help address a common problem for novice
designers: They have very little experience of past work to draw upon when
tackling a new problem. In this way, design patterns constitute valuable experi-
ence-in-a-can, ready to be used when needed.
While software engineering design patterns are quite technical in nature, they
are particularly useful for the interaction designer with a software engineering
bent; see, for example, Freeman et al. (2004) for details. In fact, user-interface
toolkits were one of the original inspirations for software engineering design
patterns, and, accordingly, many of the original 23 design patterns deal directly
with user interfaces, such as Decorator, Composite, and Command. As a result,
several of these patterns are manifested in modern user-interface toolkits.
The fact that patterns were originally used to solve problems in urban
planning demonstrates that the pattern concept transcends specific disciplines,
and the idea has further been applied to areas such as pedagogy, game design,
communication policy, visualization, and even chess strategy. Analogously, a
pattern approach to interaction design would suggest reusable solutions to com­
monly occurring problems in user-interface and interaction design. While an
exhaustive discussion of this topic would likely require an entire book of its own
(Tidwell, 2005), here is a list of a few useful interaction design patterns along
these lines:
• Model-View-Controller (MVC). A so-called architectural pattern for
implementing user interfaces, MVC governs how information should flow
128 Chapter 4 Design

between three specific components in the interface: models that represent

the state (e.g., a string for an input field or a number for a dial), views
that render the state on the display (e.g., the text box or the spinner), and
controllers that change the models (e.g., editing the string or increasing/
decreasing the number) as well as the views (e.g., scrolling through a long
document).
• Document interface. Many applications, particularly those designed for
personal computers, allow opening more than one document at the same
time. Document interface patterns capture different ways of managing
multiple documents for an application:
• Single document interface (SD1). The simplest document interface pattern,
each document opens a new instance of the application. Mobile apps and
web applications tend to be built using this pattern.
• Multiple document interface (MD1). Here each document opens an internal
window in the main frame, allowing for a single application window
even for multiple open documents. Common in personal computer
applications.
• Tabbed document interface (TDD. A compromise between SDI and MDI, the
tabbed document interface pattern places multiple open documents in tabs
in a single instance of the application. Most web browsers use TDI.
• Web application page architecture. Designing a web application is subtly differ­
ent than designing an application for a personal computer or a mobile device.
The page architecture is one of the most important interaction design aspects
here:
• Multi-page application (MPA). The traditional way of building a web
application is to use multiple pages, one for each specific function in the
application. This mimics dialog boxes in desktop applications and is easy
to implement by the very nature of HTML and the web, which is orga­
nized into separate pages but requires reloading for each page and may
thus cause disruption in the user experience.
• Single-page application (SPA). These applications fit on a single webpage,
thus mimicking a desktop application, and require no reloading or mode
changes, thereby making the user experience fluid and uninterrupted.
Instead of page loads, the application state changes dynamically through
communication with the web server using modern web technologies such
as JavaScript, HTML, and CSS.
Further discussion of interaction design patterns is beyond the scope of this
book. The reader may want to refer to Tidwell (2005) for more on this topic. Also
of interest is Schell and O'Brien's review (2015) of 13 so-called anti-patterns—
straightforward or seemingly good ideas that ultimately do not tend to work
out—in the context of user experience.
 4.7 Social Impact Analysis 129

4.7 Social Impact Analysis

Interactive systems often have a dramatic impact on large numbers of users. To

minimize risks, a thoughtful statement of anticipated impacts circulated among
stakeholders can be a useful process for eliciting productive suggestions early in
the development when changes are easiest.
Governments, utilities, and publicly regulated industries increasingly require
information systems to provide services. However, some critics have strong
negative attitudes toward modern technologies and see only a hopeless techno­
logical determinism: "Technopoly eliminates alternatives to itself. It consists in
the deification of technology, which means that the culture seeks its authoriza­
tion in technology, finds its satisfactions in technology, and takes its orders from
technology" (Postman, 1993).
Postman's endless fears do not help us to shape more effective technology or
to prevent damage from technology failures. However, constructive criticism
and guidelines for design could be helpful in reversing the long history of incor­
rect credit histories, dislocation through de-skilling or layoffs, and deaths from
flawed medical instruments. Current concerns focus on privacy invasion from
surveillance systems, government attempts to restrict access to information, and
voting fraud because of poor security. While guarantees of perfection are not
possible, policies and processes can be developed that will more often than not
lead to satisfying outcomes.
A social impact statement, similar to an environmental impact statement, might
help to promote high-quality systems in government-related applications
(reviews for private-sector corporate projects would be optional and self­
administered). Early and widespread discussion can uncover concerns and
enable stakeholders to state their positions openly. Of course, there is the danger
that these discussions will elevate fears or force designers to make unreasonable
compromises, but these risks seem reasonable in a well-managed project. An
outline for a social impact statement might include these sections (Shneiderman
and Rose, 1996):
• Describe the new system and its benefits.
• Convey the high-level goals of the new system.
• Identify the stakeholders.
• Identify specific benefits.
• Address concerns and potential barriers.
• Anticipate changes in job functions and potential layoffs.
• Address security and privacy issues.
• Discuss accountability and responsibility for system misuse and failure.
 130 Chapter 4 Design

• Avoid potential biases.

• Weigh individual rights versus societal benefits.
• Assess tradeoffs between centralization and decentralization.
5
f • Preserve democratic principles.
• Ensure diverse access.
• Promote simplicity and preserve what works.
• Outline the development process.
• Present an estimated project schedule.
• Propose a process for making decisions.
• Discuss expectations of how stakeholders will be involved.
• Recognize needs for more staff, training, and hardware.
• Propose a plan for backups of data and equipment.
• Outline a plan for migrating to the new system.
• Describe a plan for measuring the success of the new system.
A social impact statement should be produced early enough in the devel­
opment process to influence the project schedule, system requirements, and
budget. It can be developed by the system design team, which might include
end users, managers, internal or external software developers, and possibly
clients. Even for large systems, the social impact statement should be of
a size and complexity that make it accessible to users with relevant
backgrounds.
After the social impact statement is written, it should be evaluated by the
appropriate review panel as well as by managers, other designers, end users,
and anyone else who will be affected by the proposed system. Potential review
panels include federal government units (for example, the General Accounting
Organization or Office of Personnel Management), state legislatures, regula­
tory agencies (for example, the Securities and Exchange Commission or the
Federal Aviation Administration), professional societies, and labor unions. The
review panel will receive the written report, hold public hearings, and request
modifications. Citizen groups also should be given the opportunity to present
their concerns and to suggest alternatives.
Once the social impact statement is adopted, it must be enforced. A social
impact statement documents the intentions for the new system, and the stake­
holders need to see that those intentions are backed up by actions. Typically, the
review panel is the proper authority for enforcement.
The effort, cost, and time involved should be appropriate to the project, while
facilitating a thoughtful review. The process can offer large improvements by
preventing problems that could be expensive to repair, improving privacy pro­
tection, minimizing legal challenges, and creating more satisfying work
 4.8 Legal Issues 131

environments. Information-system designers take no Hippocratic Oath, but

pledging themselves to strive for the noble goal of excellence in design can win
respect and inspire others.

4,B Legal Issues

As user interfaces have become more prominent in society, serious legal issues
have emerged. Every developer of software and information should review
legal issues that may affect design, implementation, deployment, marketing,
and use. This section merely touches upon the most important such concerns.
For more information, Baase (2013) gives an in-depth overview of such social,
legal, philosophical, ethical, political, constitutional, and economic implications
of computing.
Privacy and security are always a concern whenever computers are used to
store data or to monitor activity. Medical, legal, financial, and other data often
have to be protected to prevent unapproved access, illegal tampering, inadver­
tent loss, or malicious mischief. Recently implemented privacy assurance laws
such as those imposed on the medical and financial communities can lead to
complicated, hard-to-understand policies and procedures. Physical security
measures to prohibit access are fundamental; in addition, privacy protection can
involve user-interface mechanisms for controlling password access, identity
checking, and data verification. Effective protection provides a high degree of
privacy with a minimum of confusion and intrusion into work. Website devel­
opers should provide easily accessible and understandable privacy and security
policies.
A second concern encompasses safety and reliability. User interfaces for air­
craft, automobiles, medical equipment, military systems, utility control rooms,
and the like can affect life-or-death decisions. If air traffic controllers are con­
fused by the situation display, they can make fatal errors. If the user interface for
such a system is demonstrated to be difficult to understand, it could leave the
designer, developer, and operator open to a lawsuit alleging improper design.
Designers should strive to make high-quality and well-tested interfaces that
adhere to state-of-the-art design guidelines and requirements. Accurate records
documenting testing and usage will protect designers in case problems arise.
A third issue is copyright or patent protection for software (Lessig, 2006;
Samuelson and Schultz, 2007; Mcjohn, 2015). Software developers who have
spent time and money developing a package are understandably frustrated
when potential users make illegal copies of the package rather than buying it.
Technical schemes have been tried to prevent copying, but clever hackers can
usually circumvent the barriers. It is unusual for a company to sue an individual
132 Chapter 4 Design

for copying a program, but cases have been brought against corporations and
universities. There is also a vocal community of developers, led by the League
for Programming Freedom, that opposes software copyright and patents, believ­
ing that broad dissemination is the best policy. An innovative legal approach,
Creative Commons™, enables authors to specify more liberal terms for others to
use their works. The open source software movement has enlivened these con­
troversies. The Open Source Initiative describes the movement as follows:
"When programmers can read, redistribute, and modify the source code for a
piece of software, the software evolves. People improve it, people adapt it, peo­
ple fix bugs. And this can happen at a speed that, if one is used L the slow pace
of conventional software development, seems astonishing." Some open source
products, such as the Linux® operating system and the Apachi web server,
have become successful enough to capture a substantial portion of the market
share.
A fourth concern is with copyright protection for online information, images,
or music. If customers access an online resource, do they have the right to store
the information electronically for later use? Can the customer send an elec­
tronic copy to a colleague or friend? Who owns the "friends" list and other
shared data in social networking sites? Do individuals, their employers, or net­
work operators own the information contained in e-mail messages? The expan­
sion of the web, with its vast digital libraries, has raised the temperature and
pace of copyright discussions. Publishers seek to protect their intellectual
assets, while librarians are torn between their desire to serve patrons and their
obligations to publishers. If copyrighted works are disseminated freely, what
incentives will there be for publishers and authors? If it is illegal to transmit
any copyrighted work without permission or payment, science, education, and
other fields will suffer. The fair use doctrine of limited copying for personal
and educational purposes helped cope with the questions raised by photocopy­
ing technologies. However, the perfect rapid copying and broad dissemination
permitted by the Internet demand a thoughtful update (Samuelson, 2003;
Lessig, 2006).
A fifth issue is freedom of speech in electronic environments. Do users have a
right to make controversial or potentially offensive statements through e-mail
or social media? Are such statements protected by freedom of speech laws, such
as the U.S. First Amendment? Are networks similar to street corners, where
freedom of speech is guaranteed, or are networks similar to television broad­
casting, where community standards must be protected? Should network oper­
ators be responsible for or prohibited from eliminating offensive or obscene
jokes, stories, or images? Controversy has raged over whether Internet service
providers have a right to prohibit e-mail messages that are used to organize con­
sumer rebellions against themselves. Another controversy emerged over
whether a network operator has a duty to suppress racist e-mail remarks or
postings to a social media platform. For example, Twitter has been commonly

b
 Practitioner's Summary 133

used by racists, bullies, and terrorist organizations. If libelous statements are

transmitted, can a person sue the network operator as well as the source? Should
designers build systems where the default is to "opt out" of lists and users have
to explicitly "opt in" by making a selection from a dialog box?
Other legal concerns include adherence to laws requiring equal access for
users with disabilities and attention to changing laws in countries around the
world. Do Yahoo! and eBay have to enforce the laws of every country in which
they have customers? These and other issues mean that developers of online
services must be sure to consider all the legal implications of their design
decisions.
The Internet Association ([Link] the spiritual suc­
cessor to the venerable NetCoalition, is a collective political lobbying organiza­
tion in Washington, DC, that monitors many of the legal issues raised here.
Founded by Amazon, eBay, Facebook, and Google, its website is an excellent
source for information about privacy legislation and related issues. For the
international level, the Electronic Frontier Foundation ([Link]
founded in 1990, is a non-profit digital rights group providing support to indi­
viduals fighting corporations and governments against baseless or misdirected
legal threats. There are also many other legal issues to be aware of today, includ­
ing anti-terrorism, counterfeiting, spam, spyware, liability, Internet taxation,
and others. These issues certainly require your attention, and legislation may
eventually be needed.

Practitioner's Summary

Interaction design is maturing rapidly, with once-novel ideas becoming

standard practices. Design has increasingly taken center stage in organiza­
tional and product planning. Development frameworks such as user-centered,
participatory, and agile design help by offering validated processes with
predictable schedules and meaningful deliverables. Specific design methods
such as surveys, focus groups, and ethnographic observation can provide
information to guide requirements analysis. Usage logs provide valuable data
about task frequencies and sequences. Scenario writing helps to bring com­
mon understanding of design goals, is useful for managerial and customer
presentations, and helps to plan usability tests. For interfaces developed by
governments, public utilities, and regulated industries, an early social impact
statement can elicit public discussion that is likely to identify problems and
produce interfaces that have high overall societal benefits. Designers and
managers should obtain legal advice to ensure adherence to laws and protec­
tion of intellectual property.
134 Chapter 4 Design

Researcher's Agenda

Human-computer interaction guidelines are often based on best-guess judg­

ments rather than on empirical data. More research could lead to refined stan­
dards that are more complete and dependable and to more precise knowledge
of how much improvement can be expected from a design change. Deriving
the underlying micro-HCI and macro-HCI theories from which practical guide­
lines are drawn would have far-reaching consequences for interaction design.
In particular, because technology is continually changing, we will never have a
stable and complete set of guidelines, but such scientific theories will allow us
to retain reliability and quality of interface design. It would also enable evolv­
ing design processes, ethnographic methods, participatory design activities,
scenario writing, and social impact statements to address emergent issues such
as international diversity, special populations such as children or older adults,
and long-term studies of actual usage. Thoughtful case studies of design pro­
cesses would lead to their refinement and promote more widespread applica­
tion. Creative processes are notoriously difficult to study, but well-documented
examples of success stories will inform and inspire.

References

Alexander, Christopher, A Pattern Language: Towns, Buildings, Construction, Oxford

University Press, USA (1977).
Ambler, Scott W., Agile Modeling, John Wiley and Sons (2002).
Ambler, Scott W.z Tailoring usability into Agile Software Development projects, in
Maturing Usability, Human-Computer Interaction Series, Springer Verlag (2008), 75-95.
Anderson, Chris, Makers: The New Industrial Revolution, Crown Business (2014).
Baase, Sara, A Gift of Fire: Social, Legal, and Ethical Issues for Computing Technology, 4th
Edition, Pearson Education (2013).
Bazeley, Patricia, Qualitative Data Analysis: Practical Strategies, SAGE Publications (2013).
Bias, Randolph, and Mayhew, Deborah, Cost-Justifying Usability: An Update for the
Internet Age, 2nd Edition, Morgan Kaufmann, San Francisco, CA (2005).
Boehner, Kirsten, Vertesi, Janet, Sengers, Phoebe, and Dourish, Paul, How HCI inter­
prets the probes. In Proceedings of the ACM Conference on Human Factors in Computing
Systems, ACM Press, New York (2007), 1077-1086.
Buxton, Bill, Sketching User Experiences: Getting the Design Right and the Right Design,
Morgan Kaufmann, San Francisco, CA (2007).
 References 135

Christensen, Claus M., Kjeldskov, Jesper, and Rasmussen, Klaus K., GeoHealth:
A location-based service for nomadic home healthcare workers, In Proceedings
of the ACM Conference of the Computer-Human Interaction Special Interest Group
(OZCHI) of Australia on Computer-Human Interaction, ACM Press, New York
(2007), 273-281.
Crabtree, Andrew, Rouncefield, Mark, and Tolmie, Peter, Doing Design Ethnography,
Human-Computer Interaction Series, Springer Verlag (2012).
Dourish, Paul, and Bell, Genevieve, Divining a Digital Future: Mess and Mythology in
Ubiquitous Computing, MIT Press, Cambridge, MA (2011).
Druin, Allison, The role of children in the design of new technology. Behaviour &
Information Technology 21,1 (2002), 1-25.
Fetterman, David M., Ethnography: Step by Step, 3rd Edition, SAGE Publications,
Thousand Oaks, CA (2009).
Freeman, Eric, Robson, Elisabeth, Sierra, Kathy, and Bates, Bert, Head First Design
Patterns, O'Reilly Media (2004).
Gundelsweiler, Fredrik, Memmel, Thomas, and Reiterer, Harald, Agile Usability
Engineering. In Keil-Slawik, Reinhard, Selke, Harald, and Szwillus, Gerd (Editors),
Mensch & Computer: Allgegenwartige Interaktion (2004), 33-42.
Holmquist, Lars Erik, Bootlegging: Multidisciplinary brainstorming with cut-ups. In
Proceedings of the Conference on Participatory Design (2008) 158-161.
Holtzblatt, Karen, and Beyer, Hugh, Contextual Design: Evolved, Synthesis Lectures on
Human-Centered Informatics, Morgan & Claypool, San Rafael, CA (2014).
Jacko, Julie (Editor), The Human-Computer Interaction Handbook, CRC Press, Boca Raton,
FL (2012).
Jones, Capers, A CAI State of the Practice Interview, Computer Aid, Inc. (July 2005).
Available at [Link]
Secure/Refs/capersjonesinterview1 .pdf.
Karat, Claire-Marie, A business case approach to usability, In Bias, Randolph, and
Mayhew, Deborah (Editors), Cost-Justifying Usability, Academic Press, New York
(1994), 45-70.
Kujala, Sari, User involvement: A review of the benefits and challenges. Behaviour &
Information Technology 22,1 (2003), 1-16.
Landauer, Thomas K., The Trouble with Computers: Usefulness, Usability, and Productivity,
MIT Press, Cambridge, MA (1995).
Lessig, Lawrence, Code and Other Laws of Cyberspace, Version 2.0, Basic Books, New York
(2006).
Lowdermilk, Travis, User-Centered Design: A Developer's Guide to Building User-Friendly
Applications, O'Reilly Media (2013).
Lowgren, Jonas, and Stolterman, Erik, Thoughtful Interaction Design: A Design Perspective
on Information Technology, MIT Press (2004).
Marcus, Aaron. Return on investment for usable user-interface design: Examples and
statistics (2002). Available at [Link]
ROIWhitePaper_28Feb02.pdf
136 Chapter 4 Design

Mcjohn, Stephen M., Examples & Explanations: Intellectual Property, 5th Edition, Wolters
Kluwer, New York, NY (2015).
Microsoft, Inc., Microsoft Windows S Design and Coding Guidelines (2014). Available at
[Link]
Moggridge, Bill, Designing Interactions. MIT Press, Cambridge, MA (2007).
Muller, Michael J., and Druin, Allison, Participatory design: The third space in human­
computer interaction. In Jacko, Julie (Editor), The Human-Computer Interaction
Handbook, CRC Press, Boca Raton, FL (2012), 1125-1154.
National Research Council, Committee on Human Factors, Committee on 1 luman-
System Design Support for Changing Technology, Pew, Richard \\ . and Mavor,
Anne S. (Editors), Human-System Integration in the System Development Process: A New
Look, National Academies Press, Washington, DC (2007).
Nielsen, Jakob, Usability RO1 declining, but still strong (2008). Available at http://
[Link]/alertbox/[Link].
Postman, Neil, Technopoly: The Surrender of Culture to Technology, Vintage Books,
New York (1993).
Ramachandran, Divya, Kam, Matthew, Chiu, Jane, Canny, John, and Frankel, James
F., Social dynamics of early stage co-design in developing regions. In Proceedings of
the ACM Conference on Human Factors in Computing Systems, ACM Press, New York
(2007), 1087-1096.
Rosson, Mary Beth, and Carroll, John M., Usability Engineering: Scenario-Based
Development of Human Computer Interaction, Morgan Kaufmann, San Francisco,
CA (2002).
Rubin, Jeffrey, and Chisnell, Dana, Handbook of Usability Testing: How to Plan, Design, and
Conduct Effective Tests, 2nd Edition, John Wiley & Sons, New York (2008).
Samuelson, Pamela, Digital rights management {and, or, vs.} the law, Communications of
the ACM 46, 4 (April 2003), 41-45.
Samuelson, Pamela, and Schultz, Jason, Should copyright owners have to give notice
about their use of technical protection measures? Journal of Telecommunications &
High Technology Law 6 (2007), 41-76.
Selby, Richard W. (Editor), Software Engineering: Barry W. Boehm's Lifetime Contributions
to Software Development, Management, and Research, John Wiley & Sons, New York, NY
(2007), 663-685.
Schell, Martina, and O'Brien, James, Communicating the UX Vision: 13 Anti-Patterns That
Block Good Ideas, Morgan Kaufmann (2015).
Shneiderman, Ben, and Rose, Anne, Social impact statements: Engaging public
participation in information technolog}' design, In Proceedings of the ACM SIGCAS
Symposium on Computers and the Quality of Life, ACM Press, New York (1996), 90-96.
 References 137

Sullivan, Louis H., The tall office building artistically considered, Lippincott's Magazine,
403-409 (March 1896).
Tidwell, Jenifer, Designing Interfaces: Patterns for Effective Interaction Design, O'Reilly
Media, Sebastopol, CA (2005).
Yang, Xing-Dong, Mak, Edward, McCallum, David, Irani, Pourang, and Izadi, Shahram,
LensMouse: Augmenting the mouse with an interactive touch display. In Proceedings
of the ACM Conference on Human Factors in Computing Systems, ACM Press, New York
(2010), 2431-2440.