Technical ReportPDF Available

HumanFIT: Multi-Stakeholder Mappings & Mock-Up Definitions

Authors:

Abstract

The goal of the HumanFit project is to develop an IoT Lab that supports companies in testing and developing new ideas for public health in Denmark. The IoT Lab is framed by four areas (user, organization, market, technology) and three maturity levels (low, medium, high). To determine the maturity level in each of the areas and how to move towards the next level for a company, methods and tools are necessary. This chapter outlines relevant methods and tools in relation to the four areas, maturity levels and in relation to technology and societal readiness levels
University of Southern Denmark
HumanFIT: Multi-Stakeholder Mappings & Mock-Up Definitions
Worm, Katrine Løck; Buur, Jacob; Mitchell, Robb
Publication date:
2019
Document version:
Final published version
Citation for pulished version (APA):
Worm, K. L., Buur, J., & Mitchell, R. (2019).
HumanFIT: Multi-Stakeholder Mappings & Mock-Up Definitions
.
Syddansk Universitet.
Go to publication entry in University of Southern Denmark's Research Portal
Terms of use
This work is brought to you by the University of Southern Denmark.
Unless otherwise specified it has been shared according to the terms for self-archiving.
If no other license is stated, these terms apply:
• You may download this work for personal use only.
• You may not further distribute the material or use it for any profit-making activity or commercial gain
• You may freely distribute the URL identifying this open access version
If you believe that this document breaches copyright please contact us providing details and we will investigate your claim.
Please direct all enquiries to puresupport@bib.sdu.dk
Download date: 08. Feb. 2022
IoT Lab Human FIT is a collaboration project between Public Intelligence,
Welfare Tech, SDU, MobilePeople, Life Partners, and AlertoCare.
AUGUST 2018 -8TH OF MAY 2019
HUMANFIT
MULTI-STAKEHOLDER
MAPPINGS
MOCK-UP
DEFINITIONS
AUTHORS:
KATRINE LØCK WORM
JACOB BUUR
ROBB MITCHELL
DEPT OF DESIGN AND COMMUNICATION
UNIVERSITY OF SOUTHERN DENMARK
MULTI STAKEHOLDER
STUDY
MOCK-UP TRIALS
1
15
33
PAGE 2: MAPPING THE ECOSYSTEM
PAGE 4: FLOW BETWEEN STAKEHOLDERS
PAGE 12: RISKS AND VALUES
PAGE 16: MOCK-UPS
PAGE 18: PROTOTYPES
PAGE 20: SIMULATIONS
PAGE 22: RELATION TO PROTOTYPES & MOCK-UPS
PAGE 28: DESIGN SPRINT
TABLE OF
CONTENT
REFERENCES
1
MULTI
STAKE-
HOLDER
STUDY
2
MAPPING THE ECOSYSTEM
The goal of the HumanFit project is to develop an IoT Lab that supports companies in testing and developing new
ideas for public health in Denmark. This first chapter of the report provides an overview of Who are the stakeholders?
Stakeholder mapping is a valuable process for gaining an overview of the project, and a prerequisite for understanding
resources, values and risks in the project.
WHAT IS IT AND WHY DO IT?
Stakeholder mapping is the process of uncovering those
involved in a project and those that may have an influ-
ence on a project. Stakeholders range from the users we
design for and with, to the sub-supplier we depend on, to
the legislators who’s rules we must follow. It can be done
in various ways, for instance by using Figurines. Using
the tools for establishing a stakeholder map requires
conversations with various project members. Geing an
overview of the stakeholders in a project is vital in doing
further mapping, analysis and examination of those
involved in the project. Stakeholder mapping can further
aid in resource overview, motivational drivers and clari-
fication of who we are designing for, who is going to use
our product, who do we need, etc.
FIGURINES USED FOR STAKEHOLDER MAPPING
3
FINDINGS
We created an overview of the stakeholders involved in
the HumanFIT project through conversations, Figurines
and Electronic Stakeholder Mapping.
Four stakeholder mapping sessions were conducted. The
first using Figurines, the remaining utilizing Electronic
Stakeholder Mapping:
Session 1: Angelina, project manager at Public Intelli-
gence
Session 2: Bri and Peter, project leaders at Public Intelli-
gence
Session 3: Peter S., project leader at SDU
Session 4: Rasmus, head of methodology at Public Intel-
ligence
OVERVIEW OF THE STAKEHOLDERS INVOLVED IN THE HUMANFIT PROJECT
Each stakeholder mapping session took its starting point
in the map created in the previous session to establish the
overview seen below. The stakeholders involved in this
project are Public Intelligence, AlertoCare, Life-Partners,
SDU, WelfareTech, IoT Platform Provider, Citizens, Care
Home, Home Care, Municipality and Hospital.
The stakeholder map serves as a starting point for the
Electronic Stakeholder Mapping as well as providing a
clear overview of who are involved in the project. In the
following, the stakeholder map will be used to explore
what each stakeholder brings to the project, how they
are connected and what they receive in return for their
contributions.
Public Intelligence
Citizens
Municipality
Hospital
HomeCare
CareHome
Life-Partners
AlertoCare
SDU
WelfareTech
IoT Platform Provider
4
FLOW BETWEEN STAKEHOLDERS
Now that we know who is involved, What are the relations between the stakeholders? What do they give to the project
and expect in return? We used Electronic Stakeholder Mapping to investigate how stakeholders might influence the
project and other stakeholders, and what flows between whom.
WHAT IS IT AND WHY DO IT?
Taking its starting point in the stakeholder mappings
described above, Electronic Stakeholder Mapping is a
dynamic way of discussing the relations between stake-
holders including the importance and influence of each
stakeholder. The Electronic Stakeholder Mapping served
as a ‘translation’ of, for instance, the Figurines into a
dynamic map of those involved. When using Electronic
Stakeholder Mapping, the role of a stakeholder, how they
are connected to the project, who works with whom and
who feeds what into the project, are some of the topics
which can be brought up. Regarding the role of a stake-
holder, the Electronic Stakeholder Mapping can be used
as a tool to discuss who are indispensable and who are
not, as well as discuss how it might affect the project,
should a stakeholder withdraw from the project. The
Electronic Stakeholder Mapping has the strong advantage
that it allows us to instantly see what happens, should a
specific stakeholder withdraw. The dynamic nature of the
Electronic Stakeholder Mapping means that if a stake-
holder shuts off an input, the rest of the system reacts
immediately.
Based on the Electronic Stakeholder Mapping, we have
drawn two graphical representations: An overview of the
actual LileBits map, and a generalized flow overview.
The LileBits map shows the dependencies amongst the
stakeholders, while the flow overview indicates what is
being exchanged between stakeholders.
We have mapped three cases – the HumanFIT project
as such, and the two case companies AlertoCare and
Life-Partners. The HumanFIT mapping is different from
the company mappings, as HumanFIT is a non-com-
mercial project, while the mappings for AlertoCare and
Life-Partners focus on their businesses. The mappings for
AlertoCare and Life-Partners are based on case studies
provided by Public Intelligence, sessions with project
members and a workshop session with representatives
from each company.
ANGELINA TRYING OUT THE LITTLEBITS DURING SESSION ONE
BRITT USING THE LITTLEBITS TO SHOW HOW PUBLIC INTELLIGENCE SHINES
A LIGHT ON TECHNOLOGY
PETER TESTING HOW ALTERING THE SYSTEM HAS AFFECTED THE PROJECT
5
LITTLEBITS IN ACTION
6
PUBLIC INTELLIGENCE & HUMANFIT
The HumanFIT LileBits map and flow map show a
clear division between the ‘paid’ side (WelfareTech, SDU,
AlertoCare, Life-Partners, IoT Platform Provider) and the
‘public’ side (municipality, home care, care home, hospi-
tal), with Public Intelligence being the place that connects
them. In this project, Public Intelligence is the medium
through which all stakeholders must go, with one excep-
tion being that WelfareTech pays SDU, AlertoCare and
Life-Partners without going through Public Intelligence.
The inputs that flow into Public Intelligence from the
‘public’ side are intangible, while Public Intelligence pro-
vides both knowledge and products to test. It is a some-
thing-for-something exchange, while at the ‘paid’ side
the inputs flowing into SDU, AlertoCare and Life-Partners
mainly come from WelfareTech in the form of funding.
The inputs flowing into Public Intelligence from the ‘paid’
side are knowledge and products, while Public Intelli-
gence does not necessarily give something in return. This
relationship is balanced, because WelfareTech is funding
the project partners.
Based on the LileBits map and the discussions in the
sessions, the indispensable stakeholders (without whom
the project would fail) are WelfareTech, AlertoCare,
Life-Partners, Public Intelligence, SDU, IoT Platform
Provider and the citizens. These are also the stakeholders
being paid for their participation in the project, except
citizens. The less critical stakeholders are the municipal-
ity, hospital, home care and care home. This is not to say
that these stakeholders can be excluded from the project,
but should one of them decide to no longer participate,
it would be less crucial than if, for instance, WelfareTech
pulled the funding.
Power Toggle
Fork
Slide Dimmer RGB LED
RGB LED
LED
LED
Sound
Trigger
Motion
Sensor
Bargraph
Bargraph
Servo
Fan
Bend
Sensor
Pressure
Sensor
Double
AND
Double
AND
Double
AND
Double
AND
Double
OR
Double
OR
Slide
Switch
Dimmer
Temp.
Sensor
Light
Sensor
Long
LED
Power
Fork
WELFARETECH
IOT PLATFORM PROVIDER
SDU
ALERTOCARE
LIFE-PARTNERS
IOT LAB
’PUBLIC’
PUBLIC INTELLIGENCE
PETER’S LITTLEBITS MAP REPRESENTING THE STAKEHOLDER MAP AND RELATIONS
7
ALERTOCARE
WELFARETECH
SDU
PUBLIC
INTELLIGENCE
LIFE-PARTNERS
IOT PLATFORM
PROVIDER CITIZENS
HOME CARE
HOSPITAL
CARE HOME
MONEY
KNOWLEDGE
KNOWLEDGE
KNOWLEDGE
PRODUCTS
PRODUCTS
USERS
PRODUCTS
SOFTWARE
KNOWLEDGE
MUNICIPALITIES
KNOWLEDGE
MONEY
MONEY
MONEY
KNOWLEDGE
KNOWLEDGE
KNOWLEDGE
KNOWLEDGE
USERS
KNOWLEDGE
PRODUCTS
KNOWLEDGE
KNOWLEDGE
USERS
PRODUCTS
KNOWLEDGE
USERS
KNOWLEDGE
KNOWLEDGE
PRODUCTS
FLOW MAP FOR THE HUMANFIT PROJECT
8
ALERTOCARE
For AlertoCare, there are three types of stakeholders.
Firstly, the collaborators such as sales partner and OEM.
Secondly, development/research partners such as SDU,
Public Intelligence and WelfareTech. Thirdly, users and
essential stakeholders for the service of AlertoCare to
work, such as relatives, neighbors and home care servic-
es. These last stakeholders are interesting, as they offer
their help in the event of a fall but are not paid by Alerto-
Care to do it. One could argue that the gain for the rela-
tives, neighbors etc. is the sense of security or assurance
of their family member or friend being safe. But then,
what motivates the home care service to help? This is a
question that arises from the flow mapping. The mapping
also makes it clear how dependent AlertoCare is on the
aid that their users receive from family, neighbors, home
care services and emergency centers. Without this, their
service could not function as it does today. The mappings
also highlight the possibility of knowledge sharing and
collaboration between AlertoCare and its users and their
relatives.
Based on the mappings, AlertoCare is highly depending
on the elderly (user), OEM, Soware, Public Intelligence,
Sales Partner and Manufacturer, while less critical stake-
holders are neighbors, relatives, emergency central and
home care service. This is not to say that these stakehold-
ers are not important, as disregarding them all would be
dire, but should one of the stakeholders withdraw, Aler-
toCare would be less impacted than if for instance their
OEM partner would stop the collaboration.
Power
Fork
Bright
LED
Fan
Double
AND
Double
AND
Double
AND
Double
OR
Double
OR
Slide
Switch
Power
Fork
EMERGENCY CENTRAL
HOME CARE SERVICE
RELATIVES
NEIGHBOURS
Slide Dimmer RGB LED
MANUFACTURER
Pressure
Sensor
Servo
Sound
Trigger Pressure
Sensor
LED
Motion
Sensor
ALERTOCARE
Bargraph
Bright
LED
Bright
LED
Slide
Switch
Slide
Switch
RGB LED Dimmer
SALES PARTNER
PI/IOT LAB
OEM
SOFTWARE
ELDERLY
ALERTOCARE’S LITTLEBITS MAP
9
ALERTOCARE
WELFARETECH MUNICIPALITY
SDU PUBLIC
INTELLIGENCE
SOFTWARE
OEM
SALES PARTNER RELATIVES NEIGHBOURS
HOME CARE
SERVICE
EMERGENCY
CENTER
ALARM
CENTRAL
MONEY
MONEY
PRODUCT
SOFTWARE
MONEY
HARDWARE
MONEY
KNOWLEDGE
KNOWLEDGE
KNOWLEDGE
DEV. OPP.
PRODUCTS
NEED/KNOWLEDGE
MONEY
SERVICE/HELP
HELP/AID/CARE
HELP/AID/CARE
HELP/AID/CARE
HELP/AID/CARE
PRODUCT
MONEY
PRODUCT
USER
PRODUCTS
SALES PLACE
% OF SALE
THE FLOW MAP OF ALERTOCARE
10
LIFE-PARTNERS
Clear from the maps is that Life-Partners keeps
everything in-house. It is possible to unpack both
Life-Partners, municipality, citizens and HCPs, because
each term covers more specific stakeholders depending
on where their product is used. For instance, municipality
covers both care homes, home care and nursing homes,
while citizens include elderly, nursing home residents,
relatives, disabled citizens and psychiatric citizens.
Even though we expand the stakeholders, it is still clear
that Life-Partners are very different in their stakeholder
dependencies than AlertoCare. AlertoCare relies heavily
on their suppliers and the network of relatives, neighbors
and support around the elderly for their product to work.
Life-Partners on the other hand has a straight forward
transaction with the municipality. The municipality is the
buyer of the product, while the citizens and HCPs are the
users. Unlike AlertoCare, Life-Partners relies on tangible
exchanges (money for product) and not on the cooper-
ation from outside help. The mappings also highlight
the possibility of knowledge sharing and collaboration
between Life-Partners, citizens (elderly) and HCPs, which
is not apparent at the moment.
The indispensable stakeholders for Life-Partners are
the municipality and the elderly. Because Life-Partners
keeps everything in-house and due to the nature of their
products, there are fewer stakeholders upon which they
depend. The municipality and the elderly are critical,
because they are their users and buyers. The less critical
stakeholders are neighbors, relatives and sales places,
as they oen sell directly to the municipality and, at the
moment, their solution is a tool for the elderly and the
health care professionals.
Power
Fork
Slide Dimmer RGB LED
Bright
LED
LED
Servo
Fan
Pressure
Sensor
Double
AND
Double
AND
Double
AND
Double
AND
Double
OR
Double
OR
Slide
Switch
Dimmer
Power
Fork
MANUFACTURER
SALES PLACE
LIFE-PARTNERS
PI/IOT LAB
Motion
Sensor
Pressure
Sensor
Sound
Trigger
SOFTWARE PROVIDER
MUNICIPALITY
ELDERLY Bright
LED
Bright
LED
Slide
Switch
Slide
Switch
NEIGHBOURS
RELATIVES
LIFE-PARTNERS’ LITTLEBITS MAP
11
LIFE-PARTNERS
WELFARETECH
SDU PUBLIC
INTELLIGENCE
SALES PLACE
CITIZENS
HCPs
SALES PLACE
MONEY
KNOWLEDGE
KNOWLEDGE
DEV. OPP.
PRODUCTS
MONEY
PRODUCT
PRODUCT
MONEY
PRODUCT
MUNICIPALITY
KNOWLEDGE
HCPs include:
- Nursing home employees
- Health care professionals
Municipality include:
- Care home
- Home care
- Nursing home
Life-Partners include:
- R&D development
- Software development
Citizens include:
- Elderly
- Nursing home residents
- Relatives
- Disabled citizens
- Psychiatric citizens
THE FLOW MAP FOR LIFE-PARTNERS
12
RISKS & VALUES
The stakeholders enter the HumanFIT project for different reasons and with different expectations. Mapping the risks
and values for each stakeholder can help understand what makes the project a success for all. So, what are the risks
and values for each stakeholder?
WHAT IS IT AND WHY DO IT?
To create an overview of the values and risks involved
for the different stakeholders, we gathered information
in the stakeholder mapping sessions, as well as in con-
versation with Rasmus, Head of Methodology at Public
Intelligence. The mapping sessions were useful, because
to create the maps, you inevitably need to talk about
what the different stakeholders get out of the project, in
order to place them on the map in relation to one anoth-
er. Geing an overview of the possible values and risks
for each stakeholder gives insights into why a stakeholder
might withdraw, explicitly states what they hope to get
out of the project and what to be aware of when running
the project.
13
FINDINGS
TABLE OF VALUES AND RISKS FOR STAKEHOLDERS INVOLVED IN THE HUMANFIT PROJECT. THE STAKEHOLDERS SHARING THE SAME RISKS AND VALUES
WITH BEING INVOLVED IN THE PROJECT ARE CLUSTERED.
STAKEHOLDERS VALUES RISKS
CITIZENS Life improvement
Beer service
‘Forced’ to use technology
MUNICIPALITY
CARE HOME
HOME CARE
HOSPITAL
PSYCHIATRIC DEPT.
Resource savings
Overview
Early detection
Beer, cheaper welfare
Beer and more effective day-to-
day work
Less stressfull work environment
Employees with fewer sick days
Monitoring (in relation to IoT)
Product failure
ALERTOCARE
LIFE-PARTNERS
Boost sale
Beer/improved products/services
Easier road to market
Use of excess data in new ways
(early detection)
Transforming ideas into
commercial value
Further commercialization and
IoT-fying of products
When we share our knowledge,
can others steal it?
Wasting resources
Wasting time
Municipalities are unwilling to
innovate
Not geing close-to-reality
solutions
Aligning needs with reality
IOT PLATFORM PROVIDER Sales Compatibility
WELFARETECH Advertisement for IoT Lab
Profiling/advertisement in relation
to members
Money (investment)
IOT LAB
PUBLIC INTELLIGENCE
Create beer life for humans
tomorrow
So aractive a process that PI
becomes leading
How do we handle the data-part?
Close-to-reality solutions vs
moving business forward
Right ambition level
How to prepare for the future?
How does the research-based
inputs fit into the lab?
SDU (New) knowledge Wasting time
Wasting resources
14
15
MOCK-UP
TRIALS
16
MODELS
A recurring question in the project has been What is the difference between models, mock-ups, prototypes and simula-
tions? Mastering representations of products will be crucial in the IoT Lab, as HumanFIT is about testing new tech-
nologies not seen before. Representations of systems come in different forms and with different labels. To confuse the
maer, terms are used interchangeably. In this second chapter of the report, we first look at models, then subsequently
mock-ups, prototypes and simulations, and how these representation forms relate to each other.
WHAT ARE MODELS?
According to Quek [2] “a model of a system, artefact or
environment is a simplified representation that captures
its essential characteristics for a specific purpose”. White
[3] similarly claims that “a model is an entity that is used
to represent some other entity for defined purpose”.
Maria [4] seconds the notion that models are representa-
tions, “a model is a representation of the construction
and working of some system of interest” and that “a
model is similar to, but simpler, than the system it repre-
sents”.
Within engineering, a model “is a ’miniature representa-
tion of something’ or a ‘paern of something’ or ‘an
example for imitation or emulation’” [1]. White [3] sim-
ilarly argues that “models are simplified abstractions,
which embrace only the scope and level of detail needed
to satisfy specific study objectives”.
The characteristics of models, according to Dym et al.
[1] are that “models are usually smaller and made of
different materials than are the original artefacts they
represent, and they are typically tested in a laboratory or
in some other controlled environment to validate their
expected behavior”. Additionally, “models are intention-
ally tested in controlled environments that allow the
model builder to understand the particular behavior or
phenomenon that is being modelled” [1].
WHAT CAN THEY BE USED FOR?
And what are models used for? Within engineering, we
“use models to represent some devices or processes” [1] as
well as “use them to illustrate certain behavior or phe-
nomenon as we try to verify the validity of an underlying
(predictive) theory” [1]. Models are also used for simula-
tions and evaluations. “Virtual computer models allow us
to visualize the product, see how parts fit together, cal-
culate the weight and carry out performance simulations
along the way” [5]. “A model-based evaluation is needed
to provide insights into usability before testing with end
users” [2]. Furthermore, models are built “to serve the
prototyping users” [5].
Models are also used to “study systems that exist only in
concept” [3] and they “enable the analyst to predict the
effect of changes to the system” [4].
Within architecture, Hull & Wille [6] argue that “physi-
cal models immediately reveal the relationships between
multiple dimensions of a structure, relationships that
are oen not obvious in blueprints or static views.” They
furthermore claim that physical models inherently have
three advantages, “invite tactile exploration, facilitate col-
laboration, and evoke a sense of delight in the miniature”.
Specifically, for architectural models, they “reflect real or
imagined geometries that could be manifest in the phys-
ical world.” Hull & Wille [6] also praise physical models
for their accessibility for large groups in collaboration.
Hull & Wille [6] go on to divide models into five catego-
ries with different functions and purposes. The categories
are: sketch, concept, working, context and presentation.
17
SKETCH, CONCEPT, WORKING, CONTEXT &
PRESENTATION
The following model classifications are according to Hull
& Wille [6].
Sketch models are the first iteration of models, and they
help “define and explore the space of high-level design
options and ideas.” These models are made with inexpen-
sive materials such as cardboard, foam blocks and paper.
Sketch models are a way to “quickly materialize an idea in
a playful and experimental flow of ideas.”
Concept models focus on the most fundamental form and
material relationships. They “distill the core idea of the
project”. Concept models are “physical manifestations of
an artistic ideal”. A concept model “represents the essen-
tial idea that is taken into material relationships, spatial
relationships, across all scales.”
Working models are used to refine and compare varia-
tions of the current design and are used to focus a discus-
sion with members outside the design team, like engi-
neers and investors. For each model made, the concept
becomes more refined and questions are answered.
Context models are used to “study the relationship be-
tween a design and the surrounding landscape or urban
conditions”.
Presentations models are used for showcasing the final
design to an audience, primarily of non-designers, for
instance investors. These models are more refined, oen
use high quality materials and have a nice finish.
This suggestion aligns with recent work by Stusak et al.
[32] which indicates that physicality can improve the
memorability of data representations.
DISCUSSION
While architects use a number of distinct genres of physical
models as part of their craft, each of these types can still
serve multiple and sometimes overlapping functions (see
Table 2). These common, low-level functions underscore
the specific points during the process of conceptualizing
and designing a structure where physical models are
particularly valuable. Moreover, each of the shared
functions highlights material properties, manipulation
strategies, and use cases that we believe can prove useful
for data physicalizations more generally.
Building on the models and applications discussed in the
previous section, we outline a set of four specific functions
of physical models that can serve as inspiration for the
design and development of future physicalization systems.
1. Exploring Spatial Relationships and Characteristics
Early stage sketch and concept models provide architects
with a physical means of testing, exploring, and iteratively
modifying the physical characteristics of a design, often via
manual construction and manipulation. Architects often use
these kinds of models early in their design process because
they provide a quick and adaptable way of creating and
comparing design alternatives.
This need to rapidly create and assess possible design
alternatives is analogous in many ways to the challenges
faced by visualization designers and analysts early in the
data analysis process, as they seek to understand and craft
appropriate representations for new datasets. While both
visualization experts and novices often use “data sketching”
[38] as a way to make sense of data on paper or in 2D tools,
few mechanisms exist for supporting this kind of rapid,
iterative data exploration in the physical world.
Recent work on “constructive visualization" in which
authors manually assemble representations of data using
discrete physical tokens or building blocks [15] – provides
one potential model for facilitating this kind of exploration.
Like many approaches to sketch modeling in architecture,
constructive visualization can be playful, accessible, and
supports dynamic refinement of representations. However,
this line of research has tended to emphasize the
pedagogical, rather than practical, benefits of construction –
in part because the process of additively assembling
physicalizations token-by-token can be an arduous affair.
Architectural sketch modeling, by contrast, often employs
non-additive and non-discrete construction methods like
subtractive construction using foam and other easily-
manipulable materials. Purely manual subtractive
techniques may be less valuable when creating data
physicalizations, where the resulting physical
representations generally need to reflect a precise encoding
of the underlying data. However, computer-assisted tools
for handheld subtractive fabrication like Zoran and
Paradiso’s FreeD [46] suggest that simple data-driven tools
could easily enable these kinds of physical data sketching
or “data excavation.”
Similarly, early-stage model-making in architecture often
leverages assembly techniques like bricolage in which
models are created by piecing together existing objects and
physical components. This practice, sometimes called “junk
prototyping,” is also common in product design and
interaction design [10]. Bricolage is valuable because it
provides a fast, accessible, and social mechanism for
exploring new ideas, while building on the existing
complexity and texture of the component objects (rather
than simpler primitives like tokens). We believe that
bricolage-style techniques may also have value for data
physicalization, particularly in social settings where their
tangibility and composability can help ground discussions.
For example, a collection of simple physical time series
could serve as composable building blocks for examining
and comparing possible forecast models or concretely
illustrating and discussing imaginary policy scenarios. In
contrast to the simple tokens used in constructive
visualization, these components might include more
realistic variability, trends, and other data features (peaks,
outliers, etc.) that could be readily assembled to create
plausible time series and facilitate deeper conversations.
2. Supporting Comparison and History
Physical models serve as forms of external memory for
architects throughout the design process, and their physical
nature often permits rearrangement and reconfiguration to
support various design tasks. For example, architects may
place sets of working models alongside one another to
support direct comparison between several design choices
or possible building materials. In a studio setting, architects
may also position or distribute models on shelves and
tables, creating a physical record of the design process that
can prompt continued awareness of past experiments and
possible alternatives.
Work in information visualization has long recognized the
importance of visual representations as forms of external
memory [3]. To this end, both visualization and visual
Table 2. Types of Models and Related Functions. The color scheme
is the same as the one used in Figure 2.
Visual Perception based Decisions
CHI 2017, May 6–11, 2017, Denver, CO, USA
HULL & WILLETT‘S [6] OVERVIEW OF THE FIVE TYPES OF MODELS AND
WHAT THEY ARE USED FOR
18
MOCK-UPS
What are mock-ups? There are three main sources with comprehensive definitions of mock-ups. There is an overlap,
but since some sources deal with some aspects of mock-ups while other sources handle other facets, distinctions are
made.
THINGS-TO-THINK-WITH
Eva Brandt, Professor at the Royal Danish Academy of
Fine Arts, Schools of Architecture, Design and Conserva-
tion [1, 2]
Brandt defines mock-ups as “two or three-dimensional
artifacts that illustrate parts of a design” and “a mock-up
is an experimental model showing appearance (part of)
proposed book, ship, etc.”. She argues that mock-ups are
‘things-to-think with’.
Brandt claims that “the possibility to physically interact
with the mock-ups seems therefore to be one of their
major advantages”. Brandt argues that mock-ups can
be made with few or many details, be fast and cheap
or expensive and time consuming. They can be two-or
three-dimensional, computer aided or spatial. She argues
for different levels of detail prompts different discussions
and different levels of discussion.
She further argues that the purpose of using mock-ups
is “to facilitate design” and pleads the importance of
intention with the mock-up and project, when choosing a
mock-up design.
VERY EARLY PROTOTYPES
Interaction Design Foundation, Danish non-profit com-
munity for interaction design [3]
The Interaction Design Foundation (IDF) defines mock-
ups as “‘very early prototypes’ made of cardboard or oth-
erwise low-fidelity materials” with a “focus on content
and functionality, not graphical design”.
The characteristics of mock-ups, according to IDF, are
that “mock-ups incite criticism” due to low cost and low
fidelity as well as “incite and legalize experimentation”.
IDF claims that the purpose of mock-ups is its function as
a discussion medium between designer/user and design-
er/designer, as well as discussion facilitator. Furthermore,
they argue that mock-ups are used in early usability
testing.
19
DESIGN GAME
Pelle Ehn, Professor, School of Arts and Communication,
Malmö University & Morten Kyng, Professor, Department
of Computer Science, Aarhus University [4]
Ehn and Kyng defines mock-ups as something with zero
functionality. “Still, it works very well in the design game
of envisioning the future work… it is a suggestion to the
participating users.”
The characteristic for mock-ups is that they encourage
hands-on experience. Early mock-ups are oen created
with inexpensive materials. “Mock-ups lend themselves
to collaborative modifications” therefore, “everybody has
the competence to modify them”. Ehn and Kyng further
argue that mock-ups are built with familiar materials and
tools. They encourage active user involvement. Mock-ups
are cheap, so you can do many experiments. “There is
no confusion between the simulation [mock-up] and the
‘real thing’”. Relating to their definition, mock-ups lack
functionality, hence a characteristic is that we have to im-
agine. Ehn and Kyng sums up the characteristics of mock-
ups as “cheap, understandable and allow for hands-on
experience working and pleasurable engagement”.
The purpose of mock-ups is to help users and designers
imagine the impossible. Mock-ups encourage active user
involvement, both in the design process and for testing/
evaluating. “The purpose is design and the mock-ups are
used to evaluate design, to get ideas for modifications or
maybe even radical new designs, and to have a medium
for collaborative changes”.
20
PROTOTYPES
EXPLICIT REPRESENTATIONS
Beaudouin-Lafon, Computer Scientist at Université
Paris-Sud & Mackay, Research Director at INRIA,
Université Sud-Paris [5]
According to Beaudouin-Lafon & Mackay, “prototypes
are explicit representations that help designers, engi-
neers and users reason about the system being built.”
They characterize prototypes as something that force
the designer to “show the interaction”. Additionally, they
argue that the purpose of prototypes is “generating con-
crete representations of new ideas and clarifying specific
design directions”.
What are prototypes? To understand what mock-ups are, it is beneficial to compare it with the term prototypes, which
are oen used interchangeably. Like with mock-ups, we will describe definitions of mock-ups according to who de-
fined it.
LOOKS LIKE, BEHAVES LIKE, WORKS LIKE
Buchenau & Suri, IDEO [6]
Buchenau & Suri define prototypes as “representations
of a design made before final artefacts exist”. They argue
that prototypes “range from sketches and different kind
of models at various levels – ‘looks like’, ‘behaves like’,
‘works like’”. The purpose of prototypes, according
to Buchenau & Suri is “to explore and communicate
propositions about the design and its context”.
THEORY CONFRONTATION
Sanders, Associate Professor, Design Department, Ohio
State University & Stappers, Professor of Design
Techniques, TU Del [7]
Sanders & Stappers focus on what prototypes do, and
argue that “prototypes evoke a focused discussion in a
team, because the phenomenon is on the table” and that
“prototypes confront the world, because the theory is not
hidden in abstractions”. Furthermore, they address the
purpose of prototypes and argue that “prototypes allow
testing of a hypothesis” and “confront theories”. The pur-
pose is “to give form to an idea, and to explore technical
and social feasibility”. Prototypes can be used for “usa-
bility testing of an incrementally improved redesign” as
well as “usability/field testing of a radical new product”.
For research purposes, prototypes can be part of research
through design approaches. For designers, prototypes are
a design tool, while for end-users prototypes may be used
during evaluative research events.
21
ANY DESIGN IDEA REPRESENTATION?
Houde & Hill, Apple Computer, Inc. [8]
Houde & Hill has a more open definition of prototypes,
since they argue that prototypes are “any representation
of a design idea, regardless of the medium”. A key part
of successful prototyping is “clarifying what aspects of a
prototype correspond to the eventual artefact – and what
don’t”. They further argue that the significance of pro-
totypes is not the media or tool to create them, but “how
they are used by a designer to explore or demonstrate
some aspect of the future artefact”.
QUESTION ANSWERERS
Hallgrimsson, Associate Professor at School of Design,
Carleton University [9]
Like Sanders & Stappers, Hallgrimsson focuses on the
characteristics of prototypes. He argues that it can be
useful to distinguish between looks-like and works-like
prototypes. It is the difference between exploring form
and exploring function. He claims that “a prototype is
not a final product”, and that prototypes are iterative and
progress from low – to high-fidelity. He emphasizes that
“the iterative aspect of prototyping is key”. A key charac-
teristic of physical prototypes is that they “can be placed
into real environments and have tangible qualities, such
as weight, size and texture, that can be experienced at
first hand.” Furthermore, he argues that “simple proto-
types will expose obvious problems or show that an idea
is viable”. According to Hallgrimsson, the purpose of a
prototype is to “answer questions that are hard or impos-
sible to address on the computer alone. These questions
usually have to do with the qualitative human aspect”.
“Functional configurations can also be simulated very
quickly with simple prototypes”. He then lists the many
things prototypes are used for, including: explorative idea
generation, user testing, communication, design verifica-
tion, technical performance testing and safety standards
testing.
6
to evolve into an integrated prototype which could
be described by a position at the center of our
model. A version of the user interface developed
in Example 2 was implemented in the prototype in
Example 3. Results of other prototypes were also
integrated. This enabled a more complete user test
of features and user interface to take place.
This set of three prototypes from the same project
shows how a design problem can be simultaneously
approached from multiple points of view. Design
questions of role, look and feel, and implementa-
tion were explored concurrently by the team with
the three separate prototypes. The purpose of the
model is to make it easier to develop and subse-
quently communicate about this kind prototyping
strategy.
4. FURTHER EXAMPLES
In this section we present twelve more examples of
prototypes taken from real projects, and discuss
them in terms of the model. Examples are divided
into four categories which correspond to the four
main regions of the model, as indicated in Figure
3. The first three categories correspond to proto-
types with a strong bias toward one of the three
corners: role, look and feel, and implementation
prototypes, respectively. Integration prototypes
occupy the middle of the model: they explore a
balance of questions in all three dimensions.
4.1 Role prototypes
Role prototypes are those which are built prima-
rily to investigate questions of what an artifact
could do for a user. They describe the functional-
ity that a user might benefit from, with little atten-
tion to how the artifact would look and feel, or
how it could be made to actually work. Designers
find such prototypes useful to show their design
teams what the target role of the artifact might be;
to communicate that role to their supporting orga-
nization; and to evaluate the role in user studies.
A portable notebook computer
The paper storyboard shown in Example 4 was an
early prototype of a portable notebook computer
for students which would accept both pen and fin-
ger input. The scenario shows a student making
notes, annotating a paper, and marking pages for
later review in a computer notebook. The designer
presented the storyboard to her design team to fo-
cus discussion on the issues of what functionality
the notebook should provide and how it might be
controlled through pen and finger interaction. In
terms of the model, this prototype primarily ex-
plored the role of the notebook by presenting a
rough task scenario for it. A secondary consider-
ation was a rough approximation of the user inter-
face. Its marker, shown in Figure 4, is therefore
positioned near the role corner of the model and a
little toward look and feel.
Storyboards like this one are considered to be ef-
fective design tools by many designers because they
help focus design discussion on the role of an arti-
fact very early on. However, giving them status as
prototypes is not common because the medium is
paper and thus seems very far from the medium of
Look and feel
Integration
Implementation
Role
Figure 3. Four principal categories of prototypes on
the model.
Example 4. Storyboard for a portable notebook
computer [E4 Vertelney 1990].
HOUDE & HILL’S [8] MODEL OF WHAT PROTOTYPES PROTOYPE. THE THREE
DIMENSIONS CORRESPOND TO IMPORTANT ASPECTS WHEN DESIGNING
INTERACTIVE ARTIFACTS. ONE CAN CHOOSE TO FOCUS ON ONE ASPECT OR
ALL THREE AND THUS INTEGRATE THEM.
22
SIMULATIONS
IMITATING APPEARANCE?
Quek, School of Computing Science, University of Glasgow
[10]
Quek argues that “a simulation is the operation of the
model, where the intention is to draw conclusions, quali-
tative or quantitative, about the behavior or properties of
the system”. “A simulation is a model, or simplification, of
a real system, it is naturally never an exact representation
of a real system”. She furthermore states that “to simulate
is to ‘imitate the appearance or character of’ an object”.
According to Quek, simulations are “used in a wide range
of contexts where it is either more expensive, impossible
or impractical to investigate or test a real system” and
that simulation techniques “can be used to predict and
optimize performance of a system, and to check for safety
and correctness”.
What are simulations? Simulation is a term oen used in soware and computer science. Within design, rather than
simulation, experts will use terms like test, trialing and usability testing. In the following, we will use the same aen-
tion points as was used regarding mock-ups and prototypes to define what simulations are.
MODEL EXPERIMENTATION
White, Department of Systems and Information Engineer-
ing, University of Virginia [11]
According to White, “simulation is a particular approach
to studying models, which is fundamentally experiential
or experimental”. To be able to do simulations, one must
create a model, which “imitates the behaviors of interest;
experimenting with the model to generate observations
of these behaviors; and aempting to understand, sum-
marize, and/or generalize these behaviors.” He compares
simulations to field tests, arguing that “simulation is
much like running field tests, except that the system of
interest is replaced by a physical or computational mod-
el”. White argues for two types of simulations – either
“man-in-the-loop simulations used for training and/or
entertainment” or “analysis and design of artefacts and
process”. Finally, he claims that “simulation also involves
testing and comparing alternative designs and validat-
ing, explaining and supporting simulation outcomes and
study recommendations”.
23
SIMULATING A PROCESS WITH ANOTHER
Stephan Hartmann, Professor of Philosophy, LMU Munich
[15]
Hartmann discuss simulations in relation to science –
mainly natural and social sciences. He argues that “the
most significant feature of a simulation is that it allows
scientists to imitate one process by another process”. He
offers these words of caution, “a simulation is no beer
than the assumptions build into it”. Hartmann cites five
main motives for running simulations; firstly, to “inves-
tigate the detailed dynamics of a system”, secondly, to
“develop hypotheses, models and theories”, thirdly, to
“perform numerical experiments”, fourthly, to “support
experiments” and fihly, to “gain understanding of a
process”.
24
RELATION BETWEEN MODELS, MOCK-UPS,
PROTOTYPES AND SIMULATIONS
Above, we have tried to outline the different definitions of mock-ups, prototypes and simulations, but how do they
relate to one another?
HOW ARE REPRESENTATIONS RELATED?
What became evident when gathering the different defi-
nitions of mock-ups, prototypes and simulations were
that there is not one definitive definition for each of the
terms. Definitions and use vary from field to field and
sometimes even within fields. Furthermore, the terms are
oen used interchangeably and sometimes without much
reflection about whether someone is doing mock-ups
rather than prototypes. In the following section, we have
aempted to sum up the common aspects from the defi-
nitions given above. Boiling it down to essentials - these
are the overarching aspects, across definitions.
1. Models are simplified representations, that serve a spe-
cific purpose. Models are oen similar, but simpler and
sometimes smaller, than the real artefact or system.
2. Mock-ups have low or no functionality and can be seen
as ‘very early prototypes’. They are oen used in the early
stages of the design process, possibly as a collaboration
tool. The mock-up is not confusable with the real arte-
fact.
3. Prototypes are explicit/concrete representations. The
range and use of prototypes are extensive.
4. Simulations are not artefacts, like models, mock-ups
and prototypes are, but rather an approach to testing. To
be able to do simulations, a form of input, for instance in
the form of models or prototypes, is necessary.
In our aempt to beer understand the many nuances
of the various representation types and definitions, we
have taken the different terms used in the literature and
mapped them according to different criteria. The fol-
lowing list of terms is by no means complete, but is our
synthesis, where the placement of the various terms is
contingent upon the definitions from published papers
and the degree of detail provided in the different papers.
The terms have been looked at according to:
1. Overlaps and different term use from different authors
and whether they are purpose-based or medium-based
(is this type of prototype named in relation to the pur-
pose for which it is used or the medium with which it is
made?)
2. Models, mock-ups, prototypes and simulations in rela-
tion to field, mindset and approach.
TERMS & OVERLAPS
Different authors use terms in different ways and with
different meaning. Some authors argue that one type of
prototype is actually the same as another type. Other au-
thors claim that mock-ups are physical prototypes. In the
following, we have put together the different words and
terms used for models/prototypes/mock-ups/simulations
to show where and how authors use them differently.
If we look at the figure to the right, four overall categories
define the first division – model, mock-up, prototype
and simulation. Within each of the four categories more
narrow and specific terms have been divided, each with
the reference to the paper it comes from. Finally, dis-
crepancies between the authors’ definitions and use of a
specific term is shown with arrows containing references
and statements about the discrepancy. This allow us to
get an overview of the different terms used and see how
they correspond with each other.
From the map seen on the right, it is clear that it is not
just the narrow terms which are not agreed upon, but also
the overall terms such as mock-up. The many overlaps in
definitions might be because many of the terms are oen
used interchangeably, thus creating uncertainty about
the individual term.
Purpose-based or medium-based
Now, we look at the terms according to whether they are
purpose-based or medium-based, which is also shown in
the mapping to the right. Purpose-based terms indicate
that a prototype/mock-up/model/simulation is used for a
specific purpose – these include experience prototyping
and exploratory prototyping. Medium-based terms are
terms which include, in some way or another, the medi-
um through which or material with which it is created –
these include cardboard mock-up and video prototyping.
25
MODEL
Physical models
Hull & Willett, 2017 [6]
Sketch
model
Hull & Willett,
2017 [6]
Concept
model
Hull & Willett,
2017 [6]
Working
model
Hull & Willett,
2017 [6]
Context
model
Hull & Willett,
2017 [6]
Presentation
model
Hull & Willett,
2017 [6]
Cardboard model
Hornecker, 2007 [19]
Molded-foam model
Houde & Hill, 1997 [14]
Virtual models
Peavey, Zoss & Watkins, 2012 [21]
Computer model
Hull & Willett, 2017 [6]
MOCK-UP
SIMULATION
PROTOTYPE
Physical mock-up
Peavey, Zoss & Watkins, 2012 [21]
Tangible mock-up
Rosenqvist & Heimdal, 2011 [22]
Paper-and-cardboard mock-up
Ehn & Kyng, 1992 [10]
Digital mock-up
Wang, 2002 [24]
3D mock-up
Sanders, Brandt & Binder, 2010 [23]
Live mock-up
Peavey, Zoss & Watkins, 2012 [21]
Computer-based mock-up
Ehn & Kyng, 1992 [10]
Computer-based storyboard mock-up
Ehn & Kyng, 1992 [10]
Functional prototype
Hornecker, 2007 [19]
Digital prototype
Wang, 2002[24]
Virtual prototype
Peavey, Zoss & Watkins, 2012 [21]
Online prototype
Beaudoin-Lafon & Mackay, 2003 [11]
Software prototype
Beaudoin-Lafon & Mackay, 2003 [11]
Video prototype
Beaudoin-Lafon & Mackay, 2003 [11]
Look-and-feel
prototype
Houde & Hill, 1997 [14]
Role prototype
Houde & Hill, 1997 [14]
Implementation
prototype
Houde & Hill, 1997 [14]
Integrated prototype
Houde & Hill, 1997 [14]
Hi-fi prototype
Brandt, 2007 [7]
WOZ
Beaudoin-Lafon & Mackay, 2003 [11]
Physical prototype
Peavey, Zoss & Watkins, 2012 [21]
Offline prototype
Beaudoin-Lafon & Mackay, 2003 [11]
Finished-looking
prototype
Houde & Hill, 1997 [14]
Test programme
Houde & Hill, 1997 [14]
Exploratory prototype
Kyng, 1995 [20]
Experience prototype
Buchenau & Suri, 2000 [12]
Paper-prototypes
Beaudoin-Lafon & Mackay, 2003 [11]
Lo-fi prototype
Brandt, 2007 [7]
Storyboard
Houde & Hill, 1997 [14]
Storyboard prototypes
Ehn & Kyng, 1992 [10]
Offline simulation
Quek, 2013 [2]
Online simulation
Quek, 2013 [2]
Experiental simulation
Peavey, Zoss & Watkins, 2012 [21]
Man-in-the-loop simulation
White & Ingalls, 2009 [3]
Computer-based simulation
Peavey, Zoss & Watkins, 2012 [21]
Simulation of on-screen
appearance and behaviour
Houde & Hill, 1997 [14]
Experienced-based
simulation
Peavey, Zoss & Watkings, 2012 [21]
Rapid prototyping
Beaudoin-Lafon & Mackay, 2003 [11]
Rapid prototype
Beaudoin-Lafon & Mackay, 2003 [11]
Iterative prototype
Beaudoin-Lafon & Mackay, 2003 [11]
Evolutionary prototype
Beaudoin-Lafon & Mackay, 2003 [11]
Fixed prototype
Beaudoin-Lafon & Mackay, 2003 [11]
Fixed-path prototype
Beaudoin-Lafon & Mackay, 2003 [11]
Open prototype
Beaudoin-Lafon & Mackay, 2003 [11]
Horizontal prototype
Beaudoin-Lafon & Mackay, 2003 [11]
Vertical prototype
Beaudoin-Lafon & Mackay, 2003 [11]
Task-oriented prototype
Beaudoin-Lafon & Mackay, 2003 [11]
Scenario-based prototype
Beaudoin-Lafon & Mackay, 2003 [11]
Purpose-based terms Medium-based terms Overall terms Process rather than tool/method
Quek, 2013 [2]
Simulations are models...
Peavey, Zoss & Watkins, 2012 [21]
”hysical models are often referred to as...
Peavey, Zoss & Watkins, 2012 [21]
Virtual models are often referred to as....
Peavey, Zoss & Watkins, 2012 [21]
”mock-up falls under the term...”
Houde & Hill, 1997 [14]
molded foam models are...
Wang, 2002 [24]
Used interchangeably...
Peavey, Zoss & Watkins, 2012 [21]
mock-ups are often...
Beaudoin-Lafon & Mackay, 2003 [11]
mock-ups are...
Brandt, 2007 [7]
mock-ups are...
Beaudoin-Lafon & Mackay, 2003 [11]
also called...
Beaudoin-Lafon & Mackay, 2003 [11]
also called...
Wang, 2002 [24]
”virtual prototyping is essentially a simulation process...”
Quek, 2013 [2]
WOZ is...
Quek, 2013 [2]
Prototypes are...
Houde & Hill, 1997 [14]
is...
Houde & Hill, 1997 [14]
is...
[11]
Quek, 2013 [2]
Video prototype is...
OVERVIEW OF THE DIFFERENT TERMS, HOW THEY ARE CLUSTERED AND HOW THEY INTERLINK
26
FIELD, APPROACH & MINDSET
The different ways of creating representations come
from and are used in different fields. In the figure to the
right, the four general terms are distributed according to
whether they are used for scientific validation or practice
validation and whether they are created with an expert
mindset or participatory mindset. With expert mindset
we mean that the representations are created by experts
- that is people within the company whose job it is to
create representations. With participatory mindset, the
representations can be created by those whose job it is to
create such representations, but they can also be created
by or with users, or other people within the organization
who does not ordinarily work within this field.
From the figure, we see that several of the representation
methods are created with an expert mindset, stretch-
ing across the different representation types. The only
method which truly utilizes a participatory mindset is
mock-ups.
Simulation stretches from expert mindset and scientif-
ic validation towards the middle of the matrix. This is
because the term simulation contains both simulations
which need no external people to participate and are
purely scientific (i.e. can be done in a lab), for instance,
wind simulation around new buildings. The simula-
tions, which are closer to the center of the matrix, are
simulations which are conducted with external people,
for instance, users. These simulations are oen used to
validate practices.
Models inhabit the le top corner of the matrix, because
they are oen created by experts, for instance the design-
ers working on the project, and then later presented to
others and are most oen used for scientific validation.
Models can also be a premise for conducting simulations.
Prototypes are the broadest of the representation meth-
ods and start crossing the line towards a more participa-
tory mindset. Prototypes are oen created by experts, but
for instance low fidelity prototypes can be co-changed
with users. Because prototypes is a very diverse category,
it stretches from practice validation halfway to scientific
validation and crosses the line towards the participatory
mindset.
Mock-ups belong to the participatory mindset, because
mock-ups are not just used to co-create with users but
can also be created by users. The participatory aspect of
mock-ups also make them well-suited for practice valida-
tion, more so than for scientific validation.
This mapping along with the previous mapping allow us
to look at the terms from different angles – which terms
are there, how are they linked and how are they used.
Furthermore, we can argue that it is not enough to only
look at prototypes/mock-ups etc. one way, because the
relations and use change depending on how you look at
it. One could speculate that the reason the different terms
overlap is because they are on ‘different levels’ (some very
general terms, some very specific) and because one term
is not necessarily agreed upon to only belong within one
category – again, depending on how we look at it.
The mappings created for this section are not the only
mappings that could be made, there are many other
parameters through which one could look at representa-
tions. Another mapping that could be made is the pur-
pose of the representation, but that would be a daunting
task, because many of the representations can serve sev-
eral purposes. The purposes could for instance be; early
concept testing, usability testing, presentation, collabo-
rative modifications, evaluating, field testing, research,
user testing, technical performance testing and product
validation, just to name a few. Depending on the time,
cost, resources and intended purpose of the representa-
tion, each term can oen shi between purposes, making
categorizing them a futile process without the context for
which the representation is intended.
What we have discovered through these mappings is
supported by Dym et al [1] when they argue that “the
distinctions between prototypes and models may have
more to do with the intent behind their making and the
environments in which they are tested than with any
clear dictionary-type differences.” And that does not only
apply to prototypes and models, but also mock-ups and
simulations.
27
Scientific Validation
Practice Validation
Expert
Mindset
Participatory
Mindset
Simulations
Models
Prototypes
Mock-Ups
MAP OF THE FOUR GENERAL TERMS IN RELATION TO MINDSET AND VALIDATION
28
DESIGN SPRINT
TWO APPROACHES
Google Venture
Google Venture [12] suggests a framework for a design
sprint for businesses to answer critical business ques-
tions, which oen last around 5 days. They specify five
steps, each corresponding to a day in the sprint: Map,
Sketch, Decide, Prototype and Test. Day one will consist
of mapping activities with the goal for the day being the
creation of a sprint question to be answered. The theme
is understanding your problem and choosing your target.
The goal for day two is to have a range of solution pos-
sibilities, with the main focus of the day being ideation.
Day three is narrowing down from many ideas to one,
ending the day with a concept to build on day four. Day
four is all about building a prototype and preparing for a
testing session on the last day. On day five, potential users
are invited in to test the concept and prototype. The goal
for the final day is user data from the test as well as next
step decisions, so the knowledge from the sprint does not
disappear.
The Charree
The Charree [13] has its roots in urban planning and
takes a multi stakeholder approach to sprints. Similar to
Google Venture, the Charree involves five phases one
must go through: Organization, Engagement & Vision,
Alternative Concepts Development, Preferred Plan Syn-
thesis, Plan Development and Production & Presentation.
The first phase consists of gaining an overview of the
project, understanding who we are designing for/with
and establishing the goal/vision for the sprint. This phase
oen includes a startup meeting, a field trip and a stake-
holder meeting. The second phase focuses on concept
development and gaining feedback from the public. The
next two phases are iterations focusing on refinement of
the solution and public feedback. Finally, the last phase
aends to prototyping of the proposed solution, final
feedback from stakeholders, wrapping up and deciding
next steps. The Charree method further proposes a
follow up meeting/final review 4-6 weeks aer the sprint
has ended.
The main difference between Google Venture’s approach
and the Charree approach is that the Charree focuses
In the HumanFIT project, we are looking for ways to boost the collaborations with potential IoT Lab customers. A
design sprint is typically organized to bring the team together to work out ideas with users and stakeholders within a
short period of time, oen 2 to 9 days, with a setup and follow-up phase as well. Here we present two different schools
of design sprint – Google Venture and the Charree. Additionally, we will convey five aention points from IDEO’s
work.
5 TIPS
To keep others from falling into the same pitfalls as pre-
vious sprint organizers, IDEO [14] propose five points to
keep in mind, when conducting a design sprint.
1. Anchor your sprint in a big question”. If you are taking
days out of your own and your colleagues’ calendars,
make sure that the problem or question you are tack-
ling is worth the time spent.
2. “Bridge the say-do-gap”. Do not just keep the conver-
sation hypothetical but create realistic solutions and
build it.
3. “Focus your features”. Design for the smallest set of
features that will solve the users’ problems.
4. “Be scrappy: build just enough to learn”. Because
design sprints are limited in time and resources, do not
aim for the high-fidelity prototype, but rather focus on
what is important to learn from the testing day.
5. “Keep the team energized”. Make sure that there is
enough food, breaks and drinks to keep the team going
for the entirety of the sprint.
on constant stakeholder involvement and feedback, with
a minimum of three feedback loops. They additionally
suggest starting the sprint with a field visit, to get a sense
of where, who and what we are designing for.
29
A TEST OF THE DESIGN SPRINT FORMAT CONFIRMED THAT THE TRL/SRL CONCEPT IS VIABLE. STUDENTS FROM THE UNIVERSITY OF SOUTHERN DENMARK
30
DESIGN SPRINT IN THE IOT LAB
We have discussed, if a 36-hour sprint is viable to kick of
the IoT Lab process for companies. This suggestion com-
bines the best of the Google Venture and Charree plans.
The time frame is shorter than both the Charree and
Google Venture propose, but the sprint tries to maintain
the reality checks of field visits and stakeholder involve-
ment.
Aer an introduction to the companies and employees
involved, and the IoT Lab, the first activity is mapping the
company according to societal readiness level (SRL) and
technology readiness level (TRL). This mapping will serve
as a baseline for both the sprint and the IoT Lab process.
Once the SRL and TRL levels have been mapped, the
companies are invited to ‘date’. This is a facilitated Object
Theatre exercise, where the participants use a variety
of objects to represent products/ ideas. The objects will
meet, marry and have ‘children’ – potential combinations
of technologies.
Aer the ‘dating’ companies are ready to move on to
working with the four dimensions user, organization,
market and data. Here, the SRL/TRL mapping indicates
which activities are useful for which companies, depend-
ing on where they are in their process. When the compa-
nies have worked their way through all four dimensions,
a stakeholder meeting is held, to check the findings with
stakeholders of the project, providing a reality check.
Then the companies can go back and reiterate based on
the new inputs. Day two starts with a field visit, to keep
the sprint grounded in reality. The final step of the sprint
is to plan and agree upon the next steps in the process.
The outcome of the sprint should be an understanding
of where the companies are now, where they want to go
and how we take the first steps in geing the companies
there.
31
SIX COMPANIES
MEET
IOT LAB
INTRODUCTION
USER
Toy train + Pains & Gains
ORGANIZATION
Figurines + Arrows
MARKET
Business Canvas + Pinball
DATA
Data Charts
SRL
TRL
COMPANY
DATING
MARRIAGE AND
DIVORCE
OBJECT THEATRE
REITERATE
BASED ON
STAKEHOLDER
MEETING
INTRODUCING MAPPING CONNECTING WORKING I STAKEHOLDER
MEETING
WORKING II
DAY 1
CHECKING THE FIELD
PLANNING NEXT
STEPS
FIELDVISIT PLANNING
DAY 2
DESIGN SPRINT SUGGESTION FOR THE IOT LAB
32
33
REFER-
ENCES
34
REFERENCES
1. Dym, C.L., P. Lile, and E.J. Orwin, Engineering Design:
A Project-Based Introduction. 4th ed, ed. D. Sayre. 2014,
USA: Wiley.
2. Quek, M., The role of simulation in developing and
designing applications for 2-class motor imagery
brain-computer interfaces. 2013, University of Glas-
gow.
3. White, K.P. and R.G. Ingalls. Introduction to simulation.
in Proceedings of the 2009 Winter Simulation Confer-
ence (WSC). 2009.
4. Maria, A. Introduction to Modeling and Simulation. in
Proceedings of the 1997 Winter Simulation Conference.
1997.
5. Hallgrimsson, B., Prototyping and modelmaking for
product design. 2012: Laurence King.
6. Hull, C. and W. Wille, Building with Data: Architec-
tural Models as Inspiration for Data Physicalization,
in Proceedings of the 2017 CHI Conference on Human
Factors in Computing Systems. 2017, ACM: Denver,
Colorado, USA. p. 1217-1264.
7. Brandt, E., How Tangible Mock-Ups Support Design
Collaboration. Knowledge, Technology & Policy, 2007.
20(3): p. 179-192.
8. Brandt, E., Event-Driven Product Development: Collabo-
ration and Learning. 2001.
9. Foundation, I.D. The Glossary of Human Computer
Interaction, Mock-Ups. 2018 [cited 2019 15/01/2019];
Available from: hps://www.interaction-design.org/
literature/book/the-glossary-of-human-computer-in-
teraction/mock-ups.
10. Ehn, P. and M. Kyng. Cardboard Computers: Mocking-
it-up or Hands-on the Future. in Design at work. 1992.
L. Erlbaum Associates Inc.
11. Beaudouin-Lafon, M. and W. Mackay, Prototyping tools
and techniques. Human Computer Interaction-Devel-
opment Process, 2003: p. 122-142.
12. Buchenau, M. and J.F. Suri. Experience prototyping. in
Proceedings of the 3rd conference on Designing interac-
tive systems: processes, practices, methods, and tech-
niques. 2000. ACM.
13. Sanders, E.B.-N. and P.J. Stappers, Probes, toolkits and
prototypes: three approaches to making in codesigning.
CoDesign, 2014. 10(1): p. 5-14.
14. Houde, S. and C. Hill, What do prototypes prototype?,
in Handbook of Human-Computer Interaction (Second
Edition). 1997, Elsevier. p. 367-381.
15. Hartmann, S., The World as a Process: Simulations
i the Natural and Social Sciences, in Modelling and
simulation in the social sciences from the philosophy of
science point of view. 1996, Springer. p. 77-100.
16. Venture, G. The Design Sprint. 2016 [cited 2019 15/01];
Available from: hps://www.gv.com/sprint/.
17. Lennertz, B., et al., The Charree Handbook: The Es-
sential Guide to Design-Based Public Involvement. 2014:
American Planning Association.
18. Hartley, A. and C. Fudge. 5 Tips for Running a Success-
ful Design Sprint. 2018 [cited 2019 15/01]; Available
from: hps://www.ideo.com/blog/5-tips-for-running-
a-successful-design-sprint.
19. Hornecker, E. Sketches, Drawings, Diagrams, Physical
Models, Prototypes, and Gesture as Representational
Forms. in Physicality 2007. 2007. Lancaster, UK.
20. Kyng, M., Making Representations Work. Communica-
tions of the ACM, 1995. 38(9): p. 46-55.
21. Peavey, E.K., J. Zoss, and N. Watkins, Simulation and
mock-up research methods to enhance design decision
making. Health Environments Research & Design Jour-
nal, 2012. 5(3): p. 133-143.
22. Rosenqvist, T. and E. Heimdal, The Making of a Mock-
Up: A Story About How Ideas Are Framed Using Reality
as Scaffold, in Participatory Innovation Conference
2011. 2011.
23. Sanders, E.B.-N., E. Brandt, and T. Binder, A Frame-
work for Organizing the Tools and Techniques of
Participatory Design, in PDC’10. 2010, ACM: Sydney,
Australia.
24. Wang, G.G., Definiton and Review of Virtual Prototyp-
ing. Journal of Computing and Information Science in
Engineering, 2002. 2(September): p. 232-236.
35
IoT Lab Human FIT is a collaboration project between Public Intelligence,
Welfare Tech, SDU, Microsoft, Life Partners, and Alerto.
ResearchGate has not been able to resolve any citations for this publication.
Article
Full-text available
The aim of this column is to provide an intro- duction to simulation and mock-up research methods that can be used to inform and optimize building design. Every simulation is based on an underlying model and represents an activation of that model over space and time. A model is a representation of a real-world system; it is a simplified abstraction of a system with a set of input assumptions. For example, a mock-up of a patient room is a type of simulation model that can be used to run simulations and thereby draw conclusions about the real system of a patient room. In
Article
Full-text available
The role of making in the design process has been growing, taking on new forms and involving new players over the past 10 years. Where we once primarily saw designers using making to give shape to the future, today we can see designers and non-designers working together, using making as a way to make sense of the future. In this paper, we describe the landscape of design research and practice at the end of 2013 with special attention to the role of making across these perspectives: approach (cultural probes, generative toolkits and design prototypes), mindset (designing for people and designing with people), focus in time (the world as it is, the near future and the speculative future) as well as variations in design intent (provoking, engaging and serving).
Conference Paper
Full-text available
Simulation is experimentation with a model. The behavior of the model imitates some salient aspect of the behavior of the system under study and the user experiments with the model to infer this behavior. This general framework has proven a powerful adjunct to learning, problem solving, and design. In this tutorial, we focus principally on discrete-event simulation-its underlying concepts, structure, and application.
Article
What is the role of physicality when interacting with different representations? Representational forms differ in type of representation (e.g. sketch, diagram, 3D model) and in the way they are materialized. These variations influence the properties of a representation and suggest or enable different usages, interaction styles and variations in meaning, even if they represent the same object, idea or concept. Here we present a literature survey summarizing knowledge about the properties of representational forms such as sketches, drawings, diagrams, physical models, and also of gesture.
Article
Prototypes are widely recognized to be a core means of exploring and expressing designs for interactive computer artifacts. Choosing the right kind of more focused prototype to build is an art in itself, and communicating its limited purposes to its various audiences is a critical aspect of its use. Current terminology for describing prototypes centers on attributes of prototypes themselves that can be distracting. Tools can be used in many different ways, and detail is not a sure indicator of completion. This chapter proposes a change in the language used to talk about prototypes, to focus more on fundamental questions about the interactive system being designed. The goal of this chapter is to establish a model that describes any prototype in terms of the artifact being designed rather than the prototype's incidental attributes. By focusing on the purpose of the prototype—that is, what it prototypes—better decisions can be made about the kinds of prototypes to build. With a clear purpose for each prototype, prototypes can be better used to think and communicate about design. This chapter begins by describing current difficulties in communicating about prototypes: the complexity of interactive systems; issues of multi-disciplinary teamwork; and the audiences of prototypes. The chapter introduces the model and illustrates it with some initial examples of prototypes from real projects. The chapter concludes with a summary of the main implications of the model for prototyping practice.
Article
This paper is a contribution to a more conscious use of tangible mock-ups in collaborative design processes. It describes a design team’s use of mock-ups in a series of workshops involving potential customers and users. Focus is primarily on the use of three-dimensional design mock-ups and how differences in these affected the dialogue. Reflective conversations were established by using tangible mock-ups as “things-to-think with.” They served as boundary objects that spanned the gap between the different competencies and interests of participants in design. The design mock-ups evoked different things for different participants, whereas the challenge for the design team was to find boundaries upon which everybody could agree. The level of details represented in a mock-up affected the communication so that a mock-up with few details evoked different issues, whereas a very detailed mock-up evoked a smaller variation of issues resulting in a more focused communication.
Conference Paper
This introductory tutorial is an overview of simulation modeling and analysis. Many critical questions are answered in the paper. What is modeling? What is simulation? What is simulation modeling and analysis? What types of problems are suitable for simulation? How to select simulation software? What are the benefits and pitfalls in modeling and simulation? The intended audience is those unfamiliar with the area of discrete event simulation as well as beginners looking for an overview of the area. This includes anyone who is involved in system design and modification - system analysts, management personnel, engineers, military planners, economists, banking analysts, and computer scientists. Familiarity with probability and statistics is assumed.