DESIGN, PROTOTYPING, AND

CONSTRUCTION

SRI RAHAYU 20160310015

When is the design
activity done?
 Design Activities

Design activities begin once some requirements

have been established. The design emerges
iteratively , through repeated design– evaluation–
redesign cycles involving users.
 Concerned with developing
a conceptual model that
Conceptual captures what the product
will do and how it will
behave
Two Types Of
Design Concerned with details of
the design such as menu
Concrete structures, haptic feedback,
physical widgets, and
graphics
What Is a Prototype?
 Prototype

A prototype is one manifestation of a design that allows stakeholders to interact

with it and to explore its suitability; it is limited in that a prototype will usually
emphasize one set of product characteristics and de-emphasize others. When
you hear the term prototype, you may imagine a scale model of a building or a
bridge, or a piece of software that crashes every few minutes. A prototype can
also be a paper-based outline of a display , a collection of wires and ready-made
components, an electronic picture, a video simulation, a complex piece of
software and hardware, or a three-dimensional mockup of a workstation.
This is an example of a very simple (some might even say
bizarre) prototype
  Prototypes are useful when discussing or
evaluating ideas with stakeholders; they
are a communication device among team
members, and an effective way for
designers to explore design ideas

 Prototypes answer questions and support

designers in choosing between
Why Prototype? alternatives. Hence, they serve a variety of
purposes: for example, to test out the
technical feasibility of an idea, to clarify
some vague requirements, to do some user
testing and evaluation, or to check that a
certain design direction is compatible with
the rest of product development. The
purpose of your prototype will influence the
kind of prototype you build.
Example of a paper-based
prototype of a handheld device
to support an autistic child
  A low-fidelity prototype does not look very much like the
final product and does not provide the same
functionality . For example, it may use very different
materials, such as paper and cardboard rather than
electronic screens and metal, it may perform only a
limited set of functions, or it may only represent the
functions and not perform any of them. The lump of
wood used to prototype the PalmPilot described above
Low-Fidelity Prototyping
is a low-fidelity prototype.

 Low-fidelity prototypes are useful because they tend to

be simple, cheap, and quick to produce. This also
means that they are simple,cheap, and quick to modify
so they support the exploration of alternative designs
and ideas. This is particularly important in early stages
of development, during conceptual design for example,
because prototypes that are used for exploring ideas
should be flexible and encourage exploration and
modification. Low-fidelity prototypes are not meant to be
kept and integrated into the final product.
 Storyboarding is one example of
low-fidelity prototyping that is often
used in conjunction with scenarios.
A storyboard consists of a series of
sketches showing how a user
might progress through a task
using the product under
development. It can be a series of
a. Storyboarding
screen sketches or a series of
scenes showing how a user can
perform a task using an interactive
device. When used in conjunction
with a scenario, the storyboard
provides more detail and offers
stakeholders a chance to role-play
with a prototype, interacting with it
by stepping through the scenario.
An example storyboard for a mobile
device to explore ancient sites such
as The Acropolis Sketching.
 Low-fidelity prototyping often relies on hand-
drawn sketches, and many people find it difficult
to engage in this activity because they are
inhibited about the quality of their drawing, but as
Greenberg et al (2012) put it, “Sketching is not
about drawing. Rather, it is about design” (p. 7).
b. Sketching You can get over any inhibition by devising your
own symbols and icons and practicing them –
referred to by Greenberg et al as a ‘sketching
vocabulary’ (p. 85). They don't have to be
anything more than simple boxes, stick figures,
and stars. Elements you might require in a
storyboard sketch, for example, include digital
devices, people, emotions, tables, books, etc.,
and actions such as give, find, transfer, and write.
If you are sketching an interface design, then you
might need to draw various icons, dialog boxes,
and so on
Example of some simple
sketches for low-fidelity
prototyping
 Using index cards (small pieces
of cardboard about 3 × 5 inches)
is a successful and simple way to
prototype an interaction, and is
used often when developing
c. Prototyping with index cards websites. Each card represents a
screen or one element of the
interaction. In user evaluations,
the user can step through the
cards, pretending to perform the
task while interacting with the
cards.
Example of A storyboard
depicting how to fill a car with
gas
 Another low-fidelity prototyping method called Wizard
of Oz assumes that you have a software-based
prototype. In this technique, the user interacts with
the software as though interacting with the product.
In fact, however, a human operator simulates the
software's response to the user. The method takes its
name from the classic story of the little girl who is
d. Wizard of Oz swept away in a storm and finds herself in the Land
of Oz (Baum and Denslow, 1900). The Wizard of Oz
is a small shy man who operates a large artificial
image of himself from behind a screen where no one
can see him. The Wizard of Oz style of prototyping
has been used successfully for various applications,
including PinTrace, a robotic system that helps
surgeons to position orthopedic pins accurately
during the surgery of hip fractures (Molin, 2004), and
to identify gestures for full body interaction with digital
games (Norton et al, 2010).
  A high-fidelity prototype looks like the final product
and/or provides more functionality than a low-fidelity
prototype. For example, a prototype of a software
system developed in Visual Basic is higher fidelity
than a paper-based mockup; a molded piece of
plastic with a dummy keyboard is a higher-fidelity
prototype of the PalmPilot than the lump of wood.

High-Fidelity Prototyping  High-fidelity prototyping is useful for selling ideas to

people and for testing out technical issues. High-
fidelity prototypes can be developed by modifying
and integrating existing components – both hardware
and software. In robotics this approach has been
called tinkering (Hendriks-Jansen, 1996) while in
software development it has been referred to as
Opportunistic System Development (Ncube et al,
2008). Banzi (2009) comments that: “Reusing
existing technology is one of the best ways of
tinkering.
 By their very nature, prototypes involve
compromises: the intention is to produce something
quickly to test an aspect of the product. Lim et al
(2008) suggest an anatomy of prototyping that
structures the different aspects of a prototype and
what it aims to achieve. The kind of questions that
any one prototype can answer is limited, and the
prototype must be built with the key issues in mind.
Compromises in Prototyping In low-fidelity prototyping, it is fairly clear that
compromises have been made. For example, with a
paper-based prototype an obvious compromise is
that the device doesn't actually work! For software-
based prototyping, some of the compromises will
still be fairly clear; for example, the response speed
may be slow, or the look and feel may not be
finalised, or only a limited amount of functionality
may be available.
Example variables of each filtering dimension

The definition and variables of each manifestation dimension

 Conceptual Design

Conceptual design is concerned with transforming requirements into a conceptual model. Designing the
conceptual model is fundamental to interaction design, yet the idea of a conceptual model can be
difficult to grasp. One of the reasons for this is that conceptual models take many different forms and it
is not possible to provide a definitive detailed characterization of one. Instead, conceptual design is best
understood by exploring and experiencing different approaches to it, and the purpose of this section is
to provide you with some concrete suggestions about how to go about doing this.

A conceptual model is an outline of what people can do with a product and what concepts are needed
to understand how to interact with it. The former will emerge from the current functional requirements;
possibly it will be a subset of them, possibly all of them, and possibly an extended version of them. The
concepts needed to understand how to interact with the product depend on a variety of issues related to
who the user will be, what kind of interaction will be used, what kind of interface will be used,
terminology , metaphors, application domain, and so on.
An example mood board
Key guiding principles of conceptual design are:

 Keep an open mind but never forget the users and

their context
 Discuss ideas with other stakeholders as much as
possible
 Use prototyping to get rapid feedback
 Iterate, iterate, and iterate
 Some elements of a conceptual model will
derive from the requirements for the product.
For example, the requirements activity will
have provided information about the concepts
involved in a task and their relationships, e.g.
Developing an Initial through task descriptions and analysis.
Conceptual Model Immersion in the data and attempting to
empathize with the users as described above
will, together with the requirements, provide
information about the product's user
experience goals, and give you a good
understanding of what the product should be
like. In this section we discuss approaches
which help in pulling together an initial
conceptual model.
 Interface metaphors combine familiar
knowledge with new knowledge in a way that
will help the user understand the product.
Choosing suitable metaphors and combining
new and familiar concepts requires a careful
balance between utility and fun, and is based
a. Interface metaphors on a sound understanding of the users and
their context. For example, consider an
educational system to teach 6-year-olds
mathematics. One possible metaphor is a
classroom with a teacher standing at the
blackboard. But if you consider the users of
the system and what is likely to engage them,
a metaphor that reminds the children of
something they enjoy would be more
suitable, such as a ball game, the circus, a
playroom, and so on.
 To evaluate this metaphor, apply the five questions listed above.

1. Does it supply structure? Yes, it supplies structure based on the familiar paper-based brochure. This is a
book and therefore has pages, a cover, some kind of binding to hold the pages together, an index, and table
of contents.
2. How much of the metaphor is relevant? Having details of the accommodation, facilities available, map of the
area, and supporting illustrations is relevant for the travel organizer, so the content of the brochure is
relevant.
3. Is the metaphor easy to represent? Yes. The vacation information could be a set of brochure-like pages. Note
that this is not the same as saying that the navigation through the pages will be limited to page-turning.
4. Will your audience understand the metaphor? Yes.
5. How extensible is the metaphor? The functionality of a paper-based brochure is fairly limited. However, it is
also a book, and we could borrow facilities from ebooks (which are also familiar objects to most of our
audience), so yes, it can be extended.
b. Interaction types c. Interface types

Introduced four different types of interaction: Considering different interfaces at this stage may
instructing, conversing, manipulating, and seem premature, but it has both a design and a
exploring. Which is best suited to the current practical purpose. When thinking about the
design depends on the application domain and conceptual model for a product, it is important not to
the kind of product being developed. For be unduly influenced by a predetermined interface
example, a computer game is most likely to suit type. Different interface types prompt and support
a manipulating style, while a drawing package different perspectives on the product under
has aspects of instructing and conversing. development and suggest different possible
behaviors.
Most conceptual models will include a
combination of interaction types, and it is Therefore considering the effect of different interfaces
necessary to associate different parts of the on the product at this stage is one way to prompt
interaction with different types. For example, in alternatives. Before the product can be prototyped,
the travel organizer, one of the user tasks is to some candidate alternative interfaces will need to
find out the visa regulations for a particular have been chosen. For example, input and output
destination. devices will be influenced particularly by user and
environmental requirements.
 Considering the issues in the previous section
helps the designer to produce a set of initial
conceptual model ideas. These ideas
must be thought through in more detail and
expanded before being prototyped or tested with
users. For example, concrete suggestions
Expanding the Initial Conceptual of the concepts to be communicated between the
Model user and the product and how they are to be
structured, related, and presented are
needed.
This means deciding which functions the product
will perform (and which the user will perform),
how those functions are
related, and what information is required to
support them. These decisions will be made
initially only tentatively and may change after
prototyping and evaluation.
 Understanding the tasks the product will
support is a fundamental aspect of developing
the conceptual model, but it is also important
to consider which elements of the task will be
the responsibility of the user and which will be
carried out by the product.

a. What functions will the For example, the travel organizer may suggest
specific vacation options for a given set of
product perform?
people, but is that as much as it should do?
Should it automatically reserve the booking, or
wait until it is told that this travel arrangement is
suitable? Developing scenarios, essential use
cases, and use cases will help clarify
the answers to these questions. Deciding what
the system will do and the user will do is
sometimes called task allocation.
 Functions may be related temporally, e.g.
one must be performed before another, or
two can be performed in parallel. They may
also be related through any number of
possible categorizations, e.g. all functions
b. How are the functions related relating to privacy on a smartphone, or all
options for viewing photographs in a social
to each other?
networking site. The relationships between
tasks may constrain use or may indicate
suitable task structures within the product.

For example, if one task depends on

another, the order in which tasks can be
completed may need to be restricted.
 Data is one of the categories of
requirements identified and captured through the
requirements activity. During conceptual design,
these requirements are considered
to ensure that the model provides the information
necessary to perform the task. Detailed issues of
structure and display, such as
whether to use an analog display or a digital
c. What information is display, will more likely be dealt with during the
needed? concrete design activity, but implications
arising from the type of data to be displayed may
impact conceptual design issues.

For example, identifying potential vacations for a

set of people using the travel organizer requires
the following information: what kind of
vacation is required; available budget; preferred
destinations (if any); preferred dates and duration
(if any).
 Concrete Design

Conceptual design and concrete design are closely related. The difference between them is rather a
matter of changing emphasis: during design, conceptual issues will sometimes be highlighted and at
other times, concrete detail will be stressed. Producing a prototype inevitably means making some
concrete decisions, albeit tentatively, and since interaction design is iterative, some detailed issues will
come up during conceptual design, and vice versa.

Designers need to balance the range of environmental, user, data, usability, and user experience
requirements with functional requirements. These are sometimes in conflict. For example, the
functionality of a wearable interactive product will be restricted by the activities the user wishes to
perform while wearing it; a computer game may need to be learnable but also challenging. Concrete
design also deals with issues related to user characteristics and context, and two aspects that have
drawn particular attention for concrete design are accessibility and national culture. n designed for
(Rogers and Marsden, 2013).
 Using Scenarios

Scenarios are informal stories about user tasks and activities. Scenarios can be
used to model existing work situations, but they are
more commonly used for expressing proposed or imagined situations to help in
conceptual design. Often, stakeholders are actively
involved in producing and checking through scenarios for a product.

Bødker suggests four roles (Bødker, 2000, p. 63):

1. As a basis for the overall design.
2. For technical implementation.
3. As a means of cooperation within design teams.
4. As a means of cooperation across professional boundaries, i.e. as a basis of
communication in a multidisciplinary team.
 Generating Prototypes

Astoryboard represents a sequence of actions or

events that the user and the product go through to
achieve a task. Ascenario is one
story about how a product may be used to
achieve the task. It is therefore possible to
Generating Storyboards from Scenarios generate a storyboard from a scenario by
breaking the scenario into a series of steps which
focus on interaction, and creating one scene in
the storyboard for each step. The
purpose for doing this is two-fold: first, to produce
a storyboard that can be used to get feedback
from users and colleagues; second, to
prompt the design team to consider the scenario
and the product's use in more detail.
Five main steps

1. The Thomson family gather around the

organizer and enter a set of initial
requirements
2. The system's initial suggestion is that
they consider a flotilla trip but Sky and
Eamonn aren't happy
3. The travel organizer shows them some
descriptions of the flotillas written by
young people
4. Will confirms this recommendation and
asks for details
5. The travel organizer emails the details.
The storyboard for the travel organizer focusing on environmental issues
 The value of a card-based prototype lies in the fact
that the screens or interaction elements can be
manipulated and moved around in order to
simulate interaction with a user or to explore the
user‘s end-to-end experience. Where a
storyboard focusing on the screens has been
developed, this can be translated into a card-
based prototype and used in this way. Another
way to produce a card-based prototype is to
Generating Card-Based generate one from a use case output from the
Prototypes from Use Cases requirements activity.

For example, consider the use case generated for

the travel organizer in Section 10.6.2. This
focused on the visa requirements part of the
system. For each step in the use case, the travel
organizer will need to have an interaction
component to deal with it, e.g. a button or menu
option, or a display.
Example of cards one to three of a card-
based prototype for the travel organizer
Example of card four of a card-based prototype for the travel organizer
 Construction

What is Construction?
Construction

As prototyping and building alternatives progresses, development

will focus more on putting together components and developing the
final product. This may take the form of a physical product, such as
a set of alarms, sensors and lights, or a piece of software, or both.

Whatever the final form, it is very unlikely that you will develop
anything from scratch as there are many useful (in some cases
essential) resources to support development. Here we introduce
two kinds of resource: physical computing kits and software
development kits (SDKs).
 Physical computing is concerned with how to build and
code prototypes and devices using electronics. Specifically,
it is the activity of “creating physical artifacts and giving
them behaviors through a combination of building with
physical materials, computer programming and circuit
building”(Gubbels and Froehlich, 2014). Typically, it
involves designing things, using a printed circuit board
Physical Computing (PCB), sensors (e.g. accelerometers, infrared, temperature)
to detect states, and actuators (e.g. motors, valves) that
cause some effect.

An example is a ‘friend or foe’ cat detector that senses,

via an accelerometer, any cat (or anything else for that
matter) that tries to push through a family's catflap. A
number of physical computing toolkits have been developed
for educational and prototyping purposes. One of the
earliest is Arduino (see Banzi, 2009).
Example of the Arduino board
 Asoftware development kit (SDK) is a package of
programming tools and components that supports
the development of applications for a specific
platform, e.g. for iOS on iPad, iPhone, and iPod
touch, for the Kinect device, and for the Windows
phone. Typically an SDK includes an IDE
(integrated development environment),
documentation, drivers, and sample programming
code to illustrate how to use the SDK components.
SDKs: Software Development Kits Some also include icons and buttons that can
easily be incorporated into the design. While it is
possible to develop applications without using an
SDK, it is so much easier using such a powerful
resource, and so much more can be achieved.

For example, the availability of Microsoft's Kinect

SDK makes the device's powerful gesture
recognition and body motion tracking capabilities
accessible.