Design Concept Guide V2
User Manual:
Open the PDF directly: View PDF 
.
Page Count: 30
HUMAN
CENTERED
DESIGN HCD
DESIGN STAGE
CONCEPT GUIDE
2 3
Human-Centered Design: Design Phase Concept Guide
Purpose of This Guide
The purpose of this Design Guide and its sister Design
Phase Operations Guide (available Fall 2019) is not to
make an exhaustive list of design processes. There are
many other works can do that for you, some of which
we cite throughout this work. The purpose of this
guide is to provide context and some select methods
for designing products, services, and systems that
will help solve the problems highlighted from your
Discovery phase. While the Operations Guide will
focus on the How of the making process, this Concept
Guide helps you understand the Why behind the How.
After learning the Why, you will be able to cross-apply
the contents of these Guides to other situations and
expanding your understanding of how to grapple with
complex problems. Eventually, you may nd yourself
able to contribute back to this work with original
methods of your own making. That, in fact, would
be the author’s and sponsors’ greatest measure of
success: for you to take what you have learned here
and create original work from your learnings.
4 5
Human-Centered Design: Design Phase Concept Guide
Participants, Not Users
Throughout this Guide, we will refer to the people for
whom we’re designing as participants. This is because
the people for whom we’re designing are participating
in the use of the products, services, and systems we
design. They might participate by using our products,
services, and systems in dierent ways than we
intended, adapting them to their own needs, or they
might use them for a while and abandon them. In this
way, the participants have an active role in the life
cycle of our work. This approach is sometimes called
Participatory Design; you can learn about and practice
it in detail in Participatory Design, one of the Lab’s
open enrollment classes.
In contrast, thinking of participants as “users” or
“customers” sidelines them into simply receiving
products, services, and systems. This creates either a
supplicant (i.e., please give me the thing or service) or
an entitled (e.g., I deserve the thing or service without
reservation and in the exact way I want it) orientation.
This orientation separates and creates a power imbal-
ance between the leadership stakeholders sponsoring
the work, the design teams researching and creating
the work, and participants contributing their knowl-
edge and voices to the work’s development.
In Human-Centered Design, both the designers and
the people for whom the designed products, services,
and systems are made participate in the design, use,
and evaluation processes. Participants are equal to the
design team and the leadership stakeholders, and the
project as a whole is driven primarily by participants’
input. While the designers create the prototypes or
models for solutions to participant needs, they can
only create and rene these products, services, and
systems through continued collaboration with the
participants throughout the design process.
Team Structure
The Design Phase team should include the team
members from the Discovery Phase. This team’s
in-depth understanding of the research as well as
their practice in working together will help to ensure
a successful Design phase that results in a useful,
positive Delivery and Measure phase experience for
the participants and stakeholders.
If someone from the Discovery Phase isn’t available
to join the Design Phase, review the team structure
you built based on the guidance on pages 22-31 in the
Discovery Phase Operations Guide and evaluate which
piece you might be missing. More in-depth guidance
on team roles for the Design Phase will be provided
in the upcoming Design Phase Operations Guide
(available Fall 2019).
If your Design phase will almost certainly require
technical expertise that your Discovery team does
not have, such as engineering, social work, or graphic
design skills, identify and recruit an available and
sympathetic expert in that area as soon as possible.
By including this person in your core team before you
start the design work itself, the team will benet from
their input, and they will be able to invest more deeply
in the project than if they were brought in simply to
realize your product, service, or system vision.
6 7
Human-Centered Design: Design Phase Concept Guide
Table of Contents
Purpose of this Guide ........................... 3
Participants, Not Users ......................... 4
Team Structure ................................ 5
Human-Centered Design....................... 8-9
HCD Process Cycle .........................10-11
Design Phase Principles ....................12-27
Designed Things............................28-35
Communicating Ideas Through Design ......36-49
Design & Implementation ...................50-51
What’s Next...................................52
Thanks........................................53
Glossary ...................................54-55
Notes .........................................56
Template Consent Form .......................57
8 9
Human-Centered Design: Design Phase Concept Guide
What is HCD?
Human-Centered Design (HCD) is a problem-solving, design-based
discipline that quickly moves ideas for products, services, and systems
from concept to prototype so that it can be tested with participants to
see if it meets their needs. These prototypes are developed with the
people who will ultimately use the product or service, and reect their
values and needs.
It requires rigorous qualitative research, directing that research
towards the goal of deeply understanding the needs, insights, and
emotions of customers. By using Human-Centered Design, we can
focus our time, resources, and energy on solutions and innovations
that make service delivery eective, easy, and in tune with the emo-
tions of our participants.
HCD involves four phases of sequential work: discovery, design, de-
livery, and measurement. HCD is also cyclical. Once a design solution
is launched, we measure its eectiveness against initial and intended
aims, and then we continually tweak it, thus improving the solution
over time. HCD recognizes that people and their needs are dynamic
and changing and so our solutions must be dynamic and changing.
HCD allows us to understand the types of experiences participants
want from a system, product or service. We refer to their experience
as the “front stage” of the design eort. HCD also helps us craft the
interactions of the people, processes, and technology that create those
desired experiences. We refer to this behind-the-scenes work as “the
back stage” of the design eort. By tending to the front stage and the
back stage, HCD allows us to put the customer at the center of our
design development.
DISCOVER DESIGN DELIVER MEASURE
Human-Centered Design
DESIRABILITY LENS
The Desirability Lens from the design
consultancy IDEO illustrates that
Human-Centered Design should focus
at the intersection of what customers
want (DESIRABLE), what is possible with
current means (FEASIBLE), and what can
work within constraints (VIABLE).
Introduction / HCD
HCD in Practice
The HCD approach has already created immense value in advancing public sector missions. For example,
redesigning USAJOBS, the hub for federal hiring where nearly 1 billion job searches are done annually
by over 180 million people, has resulted in a 30% reduction in help desk tickets after the rst round of
improvements. Not only does this reect an easier experience for those involved in the hiring process,
this change also creates savings in support costs.
HCD and LEAN
HCD and LEAN complement each other. HCD is
based heavily on qualitative research, while LEAN
is quantitative. LEAN enacts the rst two Es of
customer experience: Ease and Eectiveness, very
well. HCD also enacts Ease and Eectiveness,
but adds the third E, Emotion, into the process,
through an understanding of human needs, and
identication of the desired experience.
The two methods complement each other. HCD
helps to dene the desired customer experience
front-stage, and then LEAN can be used to architect
the backstage to deliver on that desired experience.
Human-Centered Design and other qualitative
research methodologies investigate and help sort
out the root causes of conicts like the one above
by Dr. Margaret Mead.
LEAN and other quantitative methodologies allow
for the understanding of current system states and
the rational correction of mechanical and nonhu-
man ineciencies in systems.
EASE
LEAN HCD
EFFECTIVENESS
EMOTION
“What people say, and what people do, and
what people say they do are entirely dierent
things.”
-Dr. Margaret Mead, Anthropologist
10 11
Human-Centered Design: Design Phase Concept Guide
The HCD Process Cycle
Introduction / HCD
HCD Phases: A Breakdown
This Design Guide series began with the Discovery
phase. Both Concept (why) and Operations (how)
guides are available for this research-focused
phase. To review, in the Discovery phase, teams
participate in research to gather participants’ and
stakeholders’ perspectives and experiences in that
frame, synthesize the results of that gathering, and
dene possible parameters for the Design phase.
After prototyping and testing, public sector design
teams typically work with implementation teams
and other stakeholders to create a small pilot and
test the logistical needs around the launch of the
product, system, or service the team has designed.
The teams should build into the delivery process
mechanisms to gather feedback on the product,
service, or system once it has been in the hands
of participants for stipulated amounts of time.
Creating these mechanisms will feed into the
success of the next phase, Measure.
With your insights gathered and opportunities
dened, teams enter the Design phase. This phase
is characterized by working through design ideas
and building models, also called prototypes, of
design solutions. Instead of trying to make the rst
version of a design perfect, the team will prior-
itize iteration, testing, and making incremental
renements. Build, test and repeat. As the team
and stakeholders converge around a best product or
service solution, renements can be made to start
moving towards a product, system, or service that
will be the team’s nal deliverable.
In the Measure phase, the design team should be
part of gathering quantitative and qualitative data
to learn if the goals and expectations of your work
are being met. When applied, this data will help
improve your design.
Discovery Deliver
Design
Measure
HCD Process
HCD is a cyclical process with dierent phases,
with each phase moving between divergent and
convergent modes of thinking. In Discovery, a team
diverges through desk research, then converges on
a problem frame, and diverges again when listening
to the points of view of the participants.
The Design phase’s ideation, or idea generation,
requires divergent thinking, then convergence
around a few viable options to prototype and test.
This prototyping and testing also requires that the
team start considering the potential measurement
points for the designed product or solution.
These measurement points include a spectrum
of measuremnets built on both quantitative and
qualitative data points. This will allow the design
team and stakeholders to gain a robust evaluation
the product or service, once it has been deployed.
Delivery includes divergence around modes of
delivery and collaboration with implementation
teams, then convergence around an workable
model. The creation of measurement points also
exist in this phase. Since the delivery of and access
to a product or service is an integral part of that
product’s or service’s success, the team should
build qualitative and quantitative measurement
points into this phase as well.
Finally, the Measurement requires that the team
and stakeholders not only converge around the col-
lection the data from the measurement points built
in the previous sections, but also think divergently
in their parsing of that data. Divergent thinking
in this phase is also known as interpreting the
data, or creating understanding or meaning from
the data. The data itself will not give the team and
stakeholders insights and direction on where to go
next; the interpretation of data provides those.
At each stage, the team is aware that a return to
a previous stage might be necessary. The HCD
process is not strictly linear, progressing from
one stage to another; it is subject to informed and
intentional revision at all points, which gives it its
cyclical nature. The balance between when to move
forward and when to revise is sometimes a tough
one to strike, but through practice and mentorship
through this process, practitioners can rene their
instincts for when this balance point is struck, and
when it feels like a project might need to re-cycle
through a phase again.
12 13
Human-Centered Design: Discovery Stage Field Guide
Design Phase Principles
1. Getting to Simple is Hard
2. No Solitary Geniuses
3. In Their Shoes
4. Consider Potential Change
5. Value New Participants
6. Plan For Long Term Use
8. Wait for the Right Opportunity
7. Serve Everyone and Define Your Audience
9. Designs Have a Life Cycle
Design teams frequently create a set of guiding principles for their projects’ Design Phases. These principles
help teams maintain alignment with the key learnings from the Discovery Phase. Below, nd a set of global
design principles. These principles, alongside those that you might create for your specic project, will help
ensure that the designed product, service, or solution that your team develops embodies the perspectives
and needs of your current and potential participants.
Discovery Stage Research Cycle / Before / Brief and Frame
The government does not have a product or product
suite that it sells, and it does not package a variety
of services or systems to sell at a prot, as private
companies do. For this reason, you might be asking
yourself, “Well, what designs does the public
sector actually need? Why do we need design in the
government, anyway?”. In fact, the public sector
constantly designs products, services, and systems.
Just because they’re not oered for sale does not
mean that they don’t exist or aren’t, in fact “real”
products and services. They just function for public
service instead of for commercial oerings.
Traditionally, public sector products, services, and
systems were designed largely from a policy angle.
Policy makers and subject matter experts would
look at data and create the items they believed
were needed. More recently, however, government
entities have realized that harnessing the power of
design-specic methodologies like Human-Cen-
tered Design and specialized design practitioners
can result in more eective and more sustainable
product and service solutions.
So what are some public sector designs? Examples
of public service product design include drivers’
licenses, building permit applications, and in-
terstate signage, while examples of public sector
service design include the system of free school
lunch distribution, the Medicare system, and the
National Park System. Each of these examples has
roots in laws, policies, and initiatives from legisla-
tures, agencies, and other government bodies, but
growing the ideas from their roots into functional
What are the things we design in
the government?
products, services, or systems require a design
process — and that process is more impactful when
it is conscious, careful, and intentional, or not.
Products, services, and systems are not mutually
exclusive entities. While products are most often
single entities (often with multiple manifestations,
such as military uniforms), they are also often
integral parts of designed services and systems.
Products may be stand-alone items, but services
and systems are more complicated designed things
because they always include more facets.
As an example, consider the National Parks System.
First, its name includes “system”, but “system” as
used in its name indicates that it is a group of parks
that form a network of protected geographical
areas and historical monuments. As a designed
thing, the National Park System is a system
including an over-arching, large-scale service of
maintaining parkland that is supported by many
dierent component parts. The single entity
called the National Parks System includes multiple
products, services, and systems within itself, as
do most services and systems. One may think of
the National Parks System as just a bunch of open
air maintained by the Department of Interior, but
the system’s component services include wilder-
ness preservation services, scientic research
opportunities, natural resource maintenance, and
historical preservation. Some of its component
products include signage, websites, apps, uniforms,
housing, and many others. We discuss this further
in the Products & Services section.
14 15
Human-Centered Design: Design Phase Concept Guide
Design Phase Principles
PURPOSE
These explanations of the design princi-
ples outlined previously should help you
contextualize why the authors of this
Guide have selected these principles
as items to keep top-of-mind during
your design phase. This section should
also act as a reference throughout your
design process.
INTRODUCTION
The Global Design Phase principles are a
high-level, project-type-agnostic means
of defining Design-phase work. They
allow us as designers and design teams
to constantly align our designs to the
needs and desires of our audience and
are applicable across the fields for
which we design in the Public Sector.
As teams create and iterate during the
Design phase, they run the risk of losing
touch with the urgency of the needs and
values expressed by participants during
the Discovery phase. Having a set of
guiding principles gives design teams
the parameters they need to constantly
reference participants’ needs and per-
spectives as the design phase proceeds.
REFERENCES
Additional Research Methods
Other resources for design principles
can be found from the following groups
and resources:
• 18F Methods
• NYC Civic Service Design Group:
Tools & Tactics
• UK Design Group Case Studies
• The Book Apart Series, specifically
Design for Real Life by Eric Meyer &
Sara Wachter-Boettcher
1. Getting to Simple is Hard
“How long will this take?” has to be one of the most terrifying ques-
tions any designer will be asked when embarking on the design phase.
The simple answer: one can’t know — but rational time constraints
can be useful. What we do know, from years of experience and many,
many design case studies, is that getting to a simple, easy-to-under-
stand, and useful solution to any design problem is the result of many
rounds of iteration, problem-solving, and testing. Leadership and
clients should not expect a design solution to be completely nished in
a month, especially if the team is working on multiple projects either
together or apart, but dening the term of the design phase rationally
can help the phase move along.
Making Decisions
A successful design phase requires the team to make a lot of decisions.
Some of these include: what to design, how to make a model or proto-
type of it, who to test with, how to test it, how to get on those peoples’
calendars, how long to wait before nding other people to test with,
how to integrate their feedback, and how to move through iterations
on that feedback.
This process can be anxiety-inducing, as it means the design won’t
meet all the needs of all the participants. This decision-making is,
however, necessary. What a design team is trying to do is to make a
precisely useful solution for a precise problem, not to make a large,
unwieldy solution that tries (and fails) to solve all the problems
encountered by the participants.
Simple is Hard Case In Point
The Semester Model as a Rational Time
Constraint
We will go further into the details of scheduling
a design phase in the Design Phase Operations
Guide, but for now, one useful rule of thumb is
based on a very familiar time unit, the aca-
demic semester. The Semester Model can also
be compared to “Epics” in the Agile process*.
These timelines generally consists of twelve
to fteen weeks of continuous work. Graduate
thesis-level design projects typically an entire
semester with students primarily working on
their own or with a tight team and focusing on
nothing else. If your team meets the criteria of
tightly working together and narrowly focusing
on the immediate task of product, service, or
system development, then a semester (12 - 15
weeks) might be a good timeline for producing
design work that has been developed through
an iterative process and tested with either one
or two rounds of partcipants, depending on
how easy it is to schedule time with them. At
12 weeks, you can reasonably be able to oer
your leadership and stakeholders a (hopefully
brief) report on your design phase, including
iterations and testing, and plan to move into
secondary testing and piloting. More on this
process in the Feedback section.
2. In Their Shoes
If you’ve heard the old saying “it takes all kinds
to make the world go ‘round,” then you know what
this principle is about. Designing for those unlike
yourselves depends on the practices of empathy.
Practicing empathy means creating designs that
will work for the participants.
The word “empathy” is often used in the design
circles to describe an ideal emotional state between
designers and participants in which the designers
have so deeply learned about the participants’
experience with a product, service, system, or
lack thereof, that they can, as nearly as possible,
stand the shoes of the participants themselves.
Practicing this emotional intelligence during the
Design phase allows designers to create solutions
for people whose experiences they may never have,
but with whom they can empathize successfully
codesign new or evolved products, services, and
systems that improve participants’ future experi-
ences.
The team has practiced empathy throughout the
Discovery phase during Interviews (Discovery
Phase Concept Guide, pages 16 - 21). As you move
deeper into design, remember that deep empathy
or sympathy you developed. Lean on that while
iterating in order to design for your participants,
even if they are widely dierent from yourselves.
Team
16 17
Human-Centered Design: Design Phase Concept Guide
Case In Point
NASA’s Mars Rover
When the NASA undertook to land research
robots called rovers on planet Mars, no one per-
son accomplished the task. Not even one leader
can take credit. Instead, to land and operate a
rover successfully on Mars, NASA assembled
multiple teams of ight and mechanical engi-
neers, physicists, rocket scientists, designers,
project managers, nance specialists, and
others to take on the task.
During the development process, those
teams engaged with the geologists, weather
scientists, chemists, and others who needed
their instruments sent to Mars to perform the
ground-breaking research. When the rst rover
landed and started collecting that information,
everyone knew they had contributed to making
that happen. This culture of interdisciplinary
collaboration at NASA has characterized their
workow since they were established in 1958.
This is not to say that collaboration is always
easy or seamless, but that the value that those
interdisciplinary teams bring to the larger
mission is understood and highly valued. This
same logic holds throughout agencies and
missions in the public space; working in teams
allows us to be more eective and have lon-
ger-term, positive impact on our core missions
than working in single-discipline silos.
Case In Point
VEO and Transitioning Veterans
The VA Welcome Kit is one example of using empathy to design
better experiences. Through hundreds of interviews with
veterans, administrators, and service providers, the Veterans
Experience Oce has been able to organize these varied oerings,
opportunities, and earned benets into a single, well-designed
informational package. Through intensive research with veterans
and a value and practice of co-design during the Design phase,
the Welcome Kit improves veterans’ understanding of available
services and benets in the large VA system. Using plain language,
the Kit strives to bring together the myriad phone numbers,
registrations, and options a veteran has upon entering VA into a
consistent, readable, and modern layout. To design it, VEO spent
a year speaking and co-designing with veterans to understand
and empathize with their confusion regarding benets and
services during transition. Building this empathy meant VEO sent
employees and designers to all parts of the United States to talk to
veterans about that experience. What this research found was that
veterans bring a range of readinness for civilian life to their period
of transition from the military, but that VA could do a lot better to
smooth that path with consistent, consumable direction regarding
the VA organization.
Using this information, the team designed the VA Welcome Kit,
now in use across VA. The Welcome Kit research and design teams
used empathy to engage with veterans about their experiences.
The teams came to understand at a minute level veterans’ feelings
of confusion and frustration with VA. The teams synthesize those
learnings into the VA Welcome Kit and tested the product exten-
sively with veterans across the country to ensure its utility. In this
way, VEO stepped into the shoes of their product participants in
order to improve their earliest experiences of VA. VA’s Welcome Kit
teams engaged empathetically with, not designed authoritatively
for, veterans across the VA system.
WHY HAVE DESIGN PHASE
PRINCIPLES?
Global Principles
Principles help teams maintain focus
on their main objective while through-
out a multi-parted, challenging design
process. For this reason, design teams
frequently create a set of guiding prin-
ciples for their projects at the start of
their design phase. These principles can
be derived from the Opportunity spaces
identified at the end of the Discov-
ery phase. They encompass the main
learnings from the participants in the
Discovery phase; they are not tactical
rules and guidance for the team.
Project Level Principles
In addition to these global design princi-
ples, individual teams team might con-
sider creating a set of guiding principles
tailored to the specific project on which
they’re working. For example, if the
design idea is to create a knowledge
sharing repository for a department, a
principle of the design phase could be
to center the design of the repository’s
submission structure on how the depart-
ment members want to submit articles
and notes, not how it would be easiest to
build from a technical standpoint.
3. No Solitary Geniuses
The myth of a solitary genius solving a huge
problem no one else could solve is largely just that
— a myth. Although CEOs, sports team leaders,
and award-winners tend to get public credit, none
of those people achieve their goals without the
consistent, robust support and help of a variety of
other people.
The same holds true in design. Although design
clusters around a few big names, like Frank Gehry,
an architect, Jonathon Ive, an industrial designer
at Apple, Inc, and Miuccia Prada, a fashion de-
signer, all of these people have teams with which
they work, and no of them designs in a vacuum.
Working in teams allows organizations to utilize
the unique backgrounds, training, and natural
talents of a variety of people. In the same way that
design teams go out and talk to participants during
Discovery, they also work as teams that espouse
multiple disciplines. This allows design teams to
hear multiple points during the making phase, in
the same way they heard multiple points of view
during the Discovery phase.
18 19
Human-Centered Design: Design Phase Concept Guide
4. Consider potential change
In stakeholders
The design process strives to include all possible participants and
stakeholders* in the Discovery phase. The thinking is that, if teams
talk to all the people who work with a product, service, or system as
participants as well as all those who administer, approve, or oversee it
as leadership stakeholders and design with them, then the end result
of the work serve the needs of all those people.
As we know, the ideal is to codesign solutions with everyone involved.
Through having open conversations in safe spaces, design teams hope
to hear the aws in designs and revise the product(s), service(s), or
solution(s) before they go to implementation. In reality, sometimes
those open conversations don’t happen often enough, or anxieties
about potential aws go unsaid. Design teams must champion the
need for access and time with participants throughout the design
phase as well as continue their empathetic listening from the Discov-
ery phase during those conversations to hear anxieties or concerns
that might be hesitantly oered.
Participants
In workow
As they move through the design phase, teams need to evaluate how
the proposed solution might change the workow or unduly increase
the workload for any of these groups. Teams can do this through
talking with these impacted groups as the process goes on, testing
with them, and listening to anxieties about being expected to do more
with no more time allowances or, conversely, with being cut out of
access or workows they may see as key to their work. Finding these
participants might seem dicult, but talk to your primary partici-
pants to nd out who they think might be touched by these changes,
contact those groups, and set up testing with them.
DEFINING TERMS
In this Guide series’ usage, we define
participants and stakeholders in the
following ways:
participants are people who work with a
product, service, or system in the course
of their normal public usage or work-
flows, such as entering information on
a website page or pages or processing
that information inside the organization.
stakeholders are people who may not
use the product, service, or system
directly but are responsible for admin-
istering those who do use it, approving
funding for its development and main-
tenance, and understanding the greater
organization in which it functions.
Case In Point
US Postal Service Package Delivery
A well-designed product or service continues to
be useful even as circumstances around it may
dramatically change. Back in 1775, the creators
of the US Postal Service could not foresee that
delivery planes, trains, and trucks would one day
replace wagons and horses as the way of getting
packages from here to there. Technology has
radically changed, but the core service oered by
the US Post Oce remains relevant today, espe-
cially as the number of packages sent continues
to increase.
In fact, much of the boom in online retail could
not have occurred without a reliable, low cost
shipping infrastructure already in place. From
small, single-person shops to industry giants like
Amazon, the US Postal Services’ package delivery
has allowed businesses of all sizes to engage in
digital interactions that result in three dimen-
sional goods showing up at customers’ doors. This
increase in scale, however, has not been without
its challenges.
However, the new services that characterize
current package services, like at rate boxes and
weekend delivery, cause a need for the consid-
eration and design for other changes within the
USPS itself. For example, in the age of Sunday de-
livery, how is personnel distributed and yet labor
contracts still honored? How might an unexpect-
ed glut of packages coming from one USPS site
be absorbed into the delivery system quickly and
eciently? Whenever a public-facing feature is
added, all these questions and many more have to
be designed for inside the organization. These are
the types of changes that teams must consider
when creating new products, services, or systems
in the context of large-scale organizations. One
change is rarely one change; in an organization
of any size, considering the potential changes
to workow, personnel, et cetera, that will have
to occur to support a new or evolved system is a
crucial task of the design team.
5. Value new participants
And design for the newest-newbies
Your design does not exist in a vacuum. It will
be integrated into an ecosystem of processes,
all of which have their primary participants and
stakeholders. For this reason, it is important to
understand and anticipate the role of new partici-
pants in the your proposed designs.
New participants are people who are entirely fresh
to the process, either from the public or from inside
the organization. When the team is creating an
entirely new product to oer to veterans, or a new
system for school administrators to talk to one
another, then everyone will be a new participant.
Keep in mind, however, that new participants
also come from inside the organization. Whoever
will distribute or administer that new product is
a new participant. Introductions, training, and a
consideration of their current workload will all
need to be addressed.
20 21
Human Centered Design: Discovery Stage Field Guide
Case In Point
USAJOBS
The USA Jobs website is well-known to many
federal employees. Through this jobs applica-
tion portal, one can nd a position that ts with
a desired career path, background, employment
preference, and General Services level. In
the past, this site has been run by the federal
government as well as by private entities, but
it has never gotten good reviews, either from
new or experienced participants, in terms of
experience or usability.
Navigating the site required participants to
understand multiple points about their em-
ployment opportunities that they might only
know if they had already had experience with
federal employment. Even if applicants did have
previous understanding of the federal hiring
system, the site’s structure made it almost
impossible to understand if they had success-
fully applied for a job or not. Applicants had no
visibility into where their application was in
the hiring process. In addition, unless someone
explicitly reached out to them, they had no way
of knowing whether their application was still
moving through the system or if they had been
dropped from consideration.
These pain points were considered during the
massive redesign of the site from 2015-2018.
Although still reective of a maddeningly
byzantine hiring path, both applicants and
hiring managers are now able to interact
through a more modern, transparent system.
This improvement was made possible by
constant testing both with new and experienced
participants as alternations to the site design
were proposed and built. No feature of this site
appeared to the public without hearing from
participants about their experience with it.
This sort of large-scale change is possible only
through a long-term commitment to change
that is paired with a constant return to focus on
the participants themselves.
Public Sector Design
6. Plan for Long Term Use
Dierences in Need
Design in the Public Sector can seem a slower, more
complicated aair than its Private Sector coun-
terpart. However, each sector has its own unique
values and pressures, terms to fulll, and spaces
to explore. While the Private Sector is pressured
by a constant need for increasing prot and the
short-term thinking that such a challenge requires,
the Public Sector must respond to and support the
public through the long life spans we now enjoy,
which means nurturing ideas that support plan-
ning ahead for decades of growth and change.
Case In Point
Building Resilient Buildings: The New Orleans
VA Medical Center
In talking about New Orleans, one cannot avoid
talking about Hurricane Katrina in 2005. The
citizens of that famous city speak of “before
the storm” and “after the storm” as markers
of time and radical change. Katrina ooded
the 50-year-old VA Medical Center (VAMC) in
New Orleans, ultimately shutting it down and
causing suering to some of the city’s most
vulnerable residents.
In 2016, the city reopened its VA Medical Center.
In building this new facility, VA and its partners
chose to plan for more storms like Katrina, in-
stead of chalking it up on a once-in-a-century
event. In order to plan for other violent storms
and ooding even, the building features bed
capacity for housing people through electrical
outages and has a boat landing on the second
oor. The planners anticipated that the build-
ing might be in use for another 50 years, and
that those 50 years are full of unknowns. The
result is a facility that works not only for the
current healthcare of the approximately 70,000
veterans in the Gulf Coast region, but also the
community surrounding the facility itself and
that community’s potential, critical needs.
22 23
Human-Centered Design: Design Phase Concept Guide
7. Serve Everyone; Dene Your Audience
Public Sector Design means planning for all groups aected by the
products, services, and systems we design. It is also inherent to
our work that we make sure that groups of diering abilities, back-
grounds, worldviews, ages, and practices are all able to access what
Public Sector designers create. This means that the groups needed for
research and testing are massive, but that need must be addressed if
we want to be sure that tour designs are useful and usable.
Precision; not Exclusion
Due to this massive potential audience, design in the public sector can
be intimidating. To get it right, to include everyone, to consider all
the angles, are all pressures design teams feel throughout the design
process. How, then, can a team eectively design for such a massive
number of people as the entire public? To be successful, teams must
proactively and explicitly dene the audiences for their work. An
important distinction here is precision in the audience denition
the product, service, or system being designed, not exclusion of
audiences to design. Design teams in the public sector have to be fair
and inclusive of all people, but if a design tries to solve problems for
multiple, overlapping groups, it runs the risk of not functioning well
for anyone. This means making designs that address precise problems
for precise audiences, so teams solve problems well and thoroughly.
During the Discovery phase, design teams dene their audiences
through the problem-framing process. In the Design phase, teams
may need to redene their audience to a more precise scope, as the
team ideates product, service, and system solutions based on the
opportunities they identied in the Synthesis portion of Discovery.
This means acknowledging a diverse audience set, but designing for
a precise group within that audience so that the product, service, or
system solution functions well and, ideally, will clear the path for
other design solutions to be made for the adjacent audience groups.
Case In Point
VA’s Patient Advocacy Tracking System (PATS)
The Patient Advocacy Tracking System (PATS)
is not a glamorous software product. At its
core, it is a data-entry system used by Patient
Advocates, who are non-clinical service pro-
viders in VA Medical Centers. But its function is
incredibly important: to record complaints and
compliments veterans have while navigating
VA Medical Centers (VAMCs) and to track the
paths to their resolutions and the paths of
compliments through to their dissemination.
The numbers generated by the PATS system
are vital to the medical centers as a dataset,
but those numbers, congured in various
ways, return dierent results according to the
audience’s values, assumptions and biases.
For example, administrators use PATS to track
performance; medical professionals use PATS to
gather insights into how veterans and caregiv-
ers perceive their care, and Patient Advocates
themselves, who are charged with keeping all
the numbers on the reactions of veterans to
their care. Given this diverse group, should the
software attempt to answer all their questions
and needs, or should it focus on working best
for one set of participants? And, if for one set,
whose values should be most supported in a
redesign?
In preparing for just such a redesign, the
Veterans Experience Oce and The Lab part-
nered to parse the data and dene the audience.
While part of the redesign eort was supposed
to include an expansion of the resolution
process to the dierent medical departments,
also known as Service Lines, within a VA
hospital, the research undertaken by VEO and
The Lab showed that those service lines would
not necessarily be able to take on this task
in addition to their normal medical work. In
response to this research, the team decided to
design the system for the needs of the Patient
Advocates themselves, because they touch the
system most often and would, according to the
research, would continue to manage the reso-
lution process, and were willing to work more
closely with the medical lines to enact the new
procedures as needed in the future.
For this reason, the software interface The Lab
designed focuses on the needs of the Patient
Advocates in their daily work: a large, open
text box for notes; search by name and last
four digits of social security numbers, and
the ability to have multiple cases open at the
same time. While the system will still allow
healthcare providers to access complaints
and compliments and be part of the process,
and it will still allow administrators to pull
performance numbers, it answers the needs
of the audience that interacts with it most
often - the Patient Advocates. Because of this,
the design team chose the Patient Advocates as
the primary design audience for this work. The
system would allow other audiences to get what
they need from the system, but the system is
designed primarily around Patient Advocates’
needs, as the primary participants in it. In
this way, the PATS redesign is an example of
supporting multiple participants, but highly
dening one’s primary audience.
24 25
Human Centered Design: Discovery Stage Field Guide
The Design phase requires much energy and eort
in order to reach the goal of usable products,
services, and systems. It sometimes seems as
though teams must make all the right decisions or
get everything perfect before launch is possible.
It’s important to remember that no design is
permanent; everything will need to change, will
have to ex, and will ultimately be succeeded by
something that is hopefully more useful and more
delightful than the thing originally designed. To
prepare for this and to build in space for exibility
and change, many design teams work as though
they are always in an interactive loop: constantly
designing, testing, delivering, and measuring
designs they know aren’t perfect but are getting
closer and closer to a perceived ideal. This state can
last months or even years, and setting up designs
to undergo it is an important part of the design
phase process.
8. Wait for the Right Opportunity
As was said before, the design phase is about mak-
ing decisions. Almost always you will nd yourself
having to leave behind what you and the team are
certain are desirable, feasible design ideas in order
to pursue one of those ideas that is more desire-
able or feasible. This can feel dicult. You might
even feel as if you are not fullling the needs of
your participants, and therefore not fullling your
project mandate, because you are not meeting all
their needs.
Good ideas, based in strong research, however,
have a long shelf life. Better than trying to execute
on all the ideas your team has come up with, focus
in on the one that you can do well and thoroughly,
and wait for the right opportunity to execute on one
or some of the others. Note all your design ideas in
your project documentation, outlining their con-
nection to your research. If possible, share them
with other teams who might be able to design for
them. But avoid taking on the development of more
than one design idea at a time. Your project has a
greater potential for success if you allow the team
to focus on developing designs for a single idea.
Once the initial design phase is complete, the team
can always go back to the additional ideas. If the
research was done thoroughly and with excellent
documentation, those ideas will almost certainly
still be pertinent. You might even be able to update
them, given the work you have done in your rst
design phase. And in the meantime, circumstances
might have developed that create opportunities for
design ideas that might have previously not been
feasible to now be more realistic. In this way, for
the good of your design phase, focus on the design
ideas you can most reasonably execute immedi-
ately, never leaving behind your other ideas, but
putting them on the back burner until you either
have time, resources, or a better opportunity to
address them.
Design for Change Case In Point
Veteran Suicide Prevention
In 2017, the Veterans Experience Oce
undertook a focused project in rural, upstate
New York to try to understand and address the
issue of suicide among rural veterans. A team
of four VEO people and a Lab team member
worked for months to connect with private and
VA healthcare providers and Veteran Service
Organizations in addition to local, county, and
state organizations in order to understand
the nature of veteran suicide in the area and
what was being done to prevent it. In August of
2017, the team presented its ndings to both
the VA’s Oce of Suicide Prevention as well as
to leaders in the Veterans Integrated Service
Network (VISN) 2, which covers New York and
New Jersey.
The team provided multiple design ideas that
could be pursued to forward the work already
being done in VISN 2 and to scale the best
practices from the area to other rural areas
experiencing similar veteran suicide crises. The
solutions were divided into two groups, Imme-
diately Actionables and Need More Research,
to give VEO leadership an idea of how the team
might proceed immediately and in the medium
term. Disappointingly, the team did not get the
go-ahead to pursue their Immediately Action-
ables, and the design phase seemed to whither.
In the face of the VEO reorganization, the team
was broken up into dierent areas of specialty,
and the discovery research seemed destined to
gather dust.
The research, however, was rigorous and sound.
A calendar year later, the Centers for Disease
Control (CDC) approached The Lab with an
audacious idea: apply Human-Centered Design
to the problem of suicide among veterans who
do not access Veterans Health Admininstration
(VHA) healthcare. Suddenly, the research from
that New York State project had new life. It
became part of the literature review for the
CDC’s project. The Immediately Actionables
shed light on the needs of healthcare providers
in rural areas specically, while the Needs More
Research ideas fed into the direction of the CDC
Discovery Phase.
Although not a perfect one-to-one use of the
New York State project’s ndings, the CDC
project built upon the previous work in a
meaningful way. Currently, the CDC project is
itself entering the design phase, and, with one
design solution already funded, the team has
hopes for the funding of others. So, although
a Design Phase opportunity for the New York
State research did not present itself, because it
was rigorously done and well articulated, it was
immediately useful when opportunities for its
use arose in another forum.
26 27
Human-Centered Design: Design Phase Concept Guide
9. Designs Have a Life Cycle
Creating new work and sharing it with the world is exciting (and
frightening); that is doubtless. Through the long, hard Discovery
Phase, through all the meetings where the team had to “sell” their
vision, through all the emails ying back and forth between the
Design and Implementation teams, a lot of work goes into realizing a
new product, service, or system. There is a pride, a irrecoverable cost,
and an emotional association inherent to a designed thing, but that
doesn’t mean the thing has to continue to be owned or exercised by
the original team or department that created it.
Products, services, and systems have life cycles, both natural and
imposed, usually relative to the amount of time that it takes to build
a thing. This idea might feel odd or painful. After all, why go through
all the work getting your work into the world if you’re already thinking
of how it might exit it? We are not taught how to do this; as organiza-
tions, we largely do not talk about letting go or taking apart. Instead,
when designed products, systems, or services become dysfunctional,
we often blame the people who administer them, or we argue that the
dysfunction is simply how things are. However, these are not usually
accurate reasons; they are ways to avoid the potential pain of change.
Humans ght change; it feels dangerous. Not changing, however,
holds us back. For this reason, rather than ght natural life cycles,
organizations should strive to acknowledge them and move with them.
Case In Point
Consumer Financial Protection Agency: Policy
Sunsets
As a new agency, the Consumer Financial
Protection Agency (CFPB, established 2011) took
on the massive task of regulating various types
of nancial entities in the United States. As they
scaled quickly, the leadership of CFPB’s Human
Capital (Human Resources) oce understood
that, in the rush of bringing on personnel to
address such a broad mission, human capital
policies ran the risk of being put into place but
never implemented. This might not be because
the policies themselves were not good ideas,
but, instead, because their intended purpose
could have been either subsumed by another,
adjacent policy, because the policy did not, in
fact, mesh with related policies, or because
supportive policies were not pursued.
For this reason, the Human Capital leadership
instituted a “sunset” rule: any policy that had
not been implemented within two years of its
articulation would be sunset, or dropped, from
the agency’s policy books. The assumption was
that any policy that had not gained traction
in that time was clearly pretty unnecessary to
some people. In this way, CFPB’s Human Capital
oce understood that not all their policy
design ideas would necessarily take root, and, in
response, built in an automatic means by which
to set those policies aside.
This is clear thinking, although it might seem
a bit sad. However, if a solution does not take
root, becomes outdated, or is superceded by an-
other solution, that doesn’t mean that the eort
going into creating that solution was necessarily
wasted. Rather, it means that something has
been learned about why things change, about
what might cause an idea to not take root, about
how and when ideas become outdated, as well
as about the natural progression and nature of
change, and when and how to allow one idea to
supercede another. Instead of keeping design
solutions around indenitely, a better practice
is to build in an automatic cycle of re-evaluation
for them, so they can be updated if they can
and need to be, or they can be sunset, with the
reasons why they no longer function becoming
part of the knowledge base for new designs.
28 29
Human-Centered Design: Design Phase Concept Guide
Purpose
It’s easy to believe that the thing a design team makes is, in fact, the
“design”. However, the thing that the team makes is simply a physical
expression of the nuanced, well-informed, and carefully constructed
design ideas that the team has formed through the process of Dis-
covery and Design. In other words, it’s exciting to create new things
from the research you have enacted, and to test that thing with
participants, and launch it into the world, but that thing must adhere
to needs found in Discovery and be constrained by the Opportunities
found during Synthesis.
Whatever the Opportunities your team identied, in the public sector,
you will most likely design a product, service, system, or a pantheon
of those items. This product, service, or system is the expression of
your design ideas. Drawing from your design ideas, dening what the
item you will design, or what items to design in what order, is a crucial
decision. To help you parse your options, this section provides a broad
outline of the ways in which products, services, and systems dier.
It also highlights a few of the points at which products and services
specically are dependent upon each other and where and how the two
might intertwine.
As you read through this section, consider your Opportunities through
the lens of product versus service versus system. Do some of them
denitely speak to being expressed as one of these designed things?
Might some of their possible designed outcomes be a combination? Is
it still unclear for some?
Designed Things
Products are dened by economists as made, or
manufactured, objects, typically created in a factory
setting. They tend to be single-instance interac-
tions between buyer and seller. If you go to a coee
shop and buy a coee every day, each purchase of
that coee is a new event; the coee is the product,
and the product is new every time you buy it.
Discovery Stage Research Cycle / Before / Recruitment
Products
REFERENCES
National Archives on Services
“One way to think of [products and ser-
vices] is from the clients’ point of view.
When a client asks “what can you make
for me?” they are asking about products;
when a client asks “what can you do for
me?” they are asking about services.
While a product is something that can be
measured and counted, a service is less
concrete and is the result of the appli-
cation of skills and expertise towards an
identified need.”
- National Archives
More broadly than the National Archives’ denition
highlighted in the previous section, economists as
a group dene products quite literally as something
you “can drop on your foot”, and they’re not joking.
This denition, while appropriate, does not address
some of the most important current products we
interact with every day: digital products.
Sun Mon Tue Wed Thu Fri Sat Sun
P
P
P
P
P
P
P
P
30 31
Human Centered Design: Discovery Stage Field Guide
Products & Services Work Together
In order to be able to determine whether a product,
service, or a combination of the two might be
necessary for the project at hand, it’s important to
be able to recognize and categorize some of these
interactions. In parsing dierent product—service
interactions in the public sector, the authors of this
Guide have come up with three categories: products
that set constraints around categories, products
that give access to services, and products that
augment services. Find a brief description of each
of them with private and public sector examples
below.
Products that set constraints around services
Products like these are used to box in a service so
that consumers can use it in pieces or at certain
scales. In the private sector, they include items
like insurance, which box in insurance services
to include a certain package of services on oer
at a certain price point. In the public sector, they
include things like drivers’ licenses classications.
The service of licensing drivers is the umbrella
oering; the classications allow people to use that
service at dierent levels. For example, CDL drivers
are the licensed to pilot a vehicles over a certain
number of axles or a certain weight, while a class C
license limits the driver to smaller vehicles.
Products-Service Spectrum
Like the coee and coee shop example above,
many products and services coexist and serve each
other as dierent parts of systems. Before further
exploring the relationship between these two
concepts, we can further break products into two
broad categories: tangible or traditional products,
and digital products.
Digital Products
Tangible Products
Tangible products are the traditional playing eld
of design and are what most people think of when
they think of design in general. Tangible products
require manufacturing in some way, and can be
used in three dimensional space. In the private
sector, they include daily items like phones or
bottles, while in the public sector they can be items
like driver’s licenses and passports.
Digital product design has emerged as more and
more parts of life are carried out on computerized
platforms. Digital products include items you may
use everyday like word processing programs, photo
sharing applications, or database applications like
your contacts lists. Government examples include
the digital ling system from the US Patent Oce,
the USAJobs website, and the Library of Congress’
digital archives.
Products that give access to services
Products like these are necessary to access services.
Private sector examples include video streaming
interfaces: without the interface, the video stream-
ing service might exist, but no one would be able to
access it. A good public sector example is New York
City’s 311 service, which exists as a call center that
routes calls as well as a mobile app. Without the
product of the phone line or the app, New York City
might oer services for non-emergencies, but New
Yorkers would not be able to access them.
Products that augment a service
Products that augment a service are not necessarily
needed to constrain or access the service, but they
do make using the service more delightful or easy.
A private sector example is a to-go coee cup:
while coee can always be served in multiple-use
cups, to-go cups, whether multiple or single use,
create a dierent way to use a coee service. A
public sector example includes the Welcome Kit
from the Department of Veterans Aairs, men-
tioned in the Principles of Team section previously.
While the Welcome Kit is not strictly necessary
for accessing all of VA’s services and benets, it
certainly makes those services and benets easier,
more delightful, and is shaping up to show higher
rates of navigation success for veterans entering
the VA system.
P
PP
P
P P
P P
P
32 33
Human Centered Design: Discovery Stage Field Guide
Services Case Study: Human-Centered
Design Capacity Building
While the public sector provides many pub-
lic-facing services, it also provides services to
itself in many forms. One of those forms is that of
education and capacity building for the workforce.
An example of this type of service is The Lab at
OPM and the Veterans Experience Oce’s (VEO’s)
Human-Centered Design (HCD) Capacity Building
program, established in 2018.
This program was a match between The Lab’s mis-
sion to provide education and training to all levels
of government as well as private sector profession-
als and VEO’s increasing need for human-centered
design capabilities.
Since its establishment in 2015, VEO has relied
almost exclusively on a combination of designs
from The Lab at OPM and HCD contract resources to
source expertise in applying HCD to solve complex
problems. As the designated CX organization in VA,
VEO seeks to increase its HCD capacity through this
program to deepen VEO’s understanding of Veteran
needs and develop innovative tools and solutions
to meet those needs. This program also an oppor-
tunity for VEO and The Lab at OPM to build an HCD
capacity building program that could be leveraged
by other Agencies in support of the President’s
Discovery Stage Research Cycle / Before / Plan
According to economists, services are items that
are not manufactured and are typically delivered
on-demand. They tend to be ongoing, or things you
return to again and again, unlike the single-in-
stance events that characterize products.
The touchpoints of the transaction, the culture and
community of the coee shop, are components of
the shop’s service, which is ongoing and intangible.
Going back to our coee shop example, while the
coee you drink is a new product every day, the
coee shop provides the ongoing service of stock-
ing, making, and selling coee.
As readers of this Guide probably already know, the
public sector is, in fact, primarily a service provid-
er. The services of governance, civil and criminal
protections, environmental and food safety regula-
tions, and so many others, are the primary reasons
for the public sector's existence.
Management Agenda (PMA), Cross-Agency Priority
(CAP) Goal of Improving Customer Experience
with Federal Services. This program is designed to
increase VEO’s capacity to provide HCD support to
VA and provide a framework for other Agencies to
use as well.
In this way, the HCD Capacity Building program
is an example of a service that one agency (OPM)
provides to another agency (VA). The exchange is
comprised of knowledge and practice, and return
on investment is long-term and strategic. Its
evolution is ongoing, as there is no one-stop-shop
for learning a complex practice like design. In order
to support the participants’ development, however,
The Lab has articulated a path to “launch”, ie,
welcome into the public sector design community,
that includes a variety of formal, class-based
requirements as well as project-based evaluations.
34 35
Human-Centered Design: Design Phase Concept Guide
Systems
Economists divide economies into the two previous categories of
activity: manufacturing products, and executing services. This parsing
is not quite precise enough for the challenges of design, however.
In the design process, we have a third possible category of designed
thing: systems.
As was said at the introduction to this section, the public sector is pri-
marily a service provider. Those services are upheld, augmented, and
accessed through products. But, especially internally, the public sector
also launches and maintains systems that, while not exactly services
themselves, are also not exactly products. Systems dier from ser-
vices in that they, too, uphold services, or even launch the products,
but they are neither. One example of this is the hiring system through
which the public can enter the government workforce. The website
USAJobs.gov is a product that creates access to the hiring system. The
action of hiring itself is a service, while the process of getting hired
is, in fact a system supporting that service. In this way, the hiring
managers, people who write position descriptions, review resumes,
conduct background checks, et cetera, are parts of the hiring system,
which, as a whole is the service to the American public of hiring.
Consent form Pens/Pencils
Case Study: Systems in
Government
USAJOBS Mission Critical Hiring Paths Diagram
Teams rebuilding the outdated USAJobs site studied
the interactions of USAJobs.gov product and the
system of hiring closely. Instead of simply over-
hauling the site from technical, administrative,
public-, or organizational- facing perspectives, the
design team brought all these groups to the table
during the design process. Each group has a unique
value and requirements set for the functioning
of the site, and, in organizing that functionality,
those values and needs must be balanced. For
example, if the designers prioritize technology
needs, they might ignore the needs of the people
who process the information coming in. If they
prioritize administrators’ needs, they might not
reect the needs of the public. Even though each
of these groups is working towards the same goal,
the successful functioning of the USAJobs site, the
denition of success diers slightly across each
group.
For this reason, throughout their project’s devel-
opment, the designers mapped how the system
of hiring worked, where it bogged down, and how
Discovery Stage Research Cycle / Before / Plan
it might be reconstructed. They recognized that
the hiring system drives every aspect of the sites’
functionality, no matter which group a participant
or stakeholder might come from. In this way, the
eort to improve the USAJobs site became an eort
to improve hiring itself, thusly demonstrating the
utility of nding and working from the root cause
of an issue, instead of solving for discreet, surface
issues. A simple glance can show a reader that the
system of hiring is complex and involves multiple
groups and stakeholders. In building this diagram,
the USA Jobs team created an illustration of the
hiring path components: people, stages, and touch-
points. Through this diagram, the team was able to
not come up with a single solution for hiring, but
instead to explore the system, for that exploration
to result in understanding it, to clarify nuances in
the system to viewers, and to communicate ideas
for the systems’ many possible throughlines and
values in a concise and yet thorough manner. This
understanding then informed the development of
the USAJobs site product in terms of the various
stakeholders’ positions and needs in the system.
USING DIAGRAMS
Diagrams like this one are a common ap-
plication of drawing and visual communi-
cation in organizations. They can be used
to give form to systems, and that can be
useful. Because systems typically don’t
have physical, tangible forms, such as
this Hiring Paths process or the organi-
zational chart of an office, they can be
hard to understand holistically, which in
turn limits designers’ ability to intervene
at the most effective places.
In addition to allowing teams to under-
stand the system in order to intervene
in it, diagrams, like references, also
help teams get feedback on proposed
changes to the system in a concise yet
multi-layered way. Diagrams can show
loops, forks, simultaneous actions,
divergences, convergences, and
dependencies so that stakeholders can
understand their position in the system,
and design teams can identify how and
where to best intervene with new or
improved products and / or supporting
systems.
36 37
Human-Centered Design: Design Phase Concept Guide
Communicating Abstract Concepts
When design teams need to talk about abstract concepts or convey a
feeling, they often use any of those alternate forms of communication
to do so. These photos, drawings, recordings, et cetera, are called
“references” because you should “reference” them when reading the
text or listening to the presentation that accompanies them. They
function the same way that metaphors and similes do in written and
verbal language. Instead of saying “happy” and expecting everyone
to know what we mean, we often say things like “happy, like a sunny
day”. In design, we bring our metaphors into visual, audio, and tactile
forms so that we can communicate meaning, form, and emotion all in
one place.
Using References is Just Show And Tell
In grade school, many students in the United States play an in-class-
room game called “Show and Tell”. In this exercise, students bring in
an object they think is interesting, show it to the class, and then tell
the class a story for which that object is starting point or an integral
part.
One of the purposes of this exercise is to teach students about how
tangible objects can represent abstract concepts or events that have
already occurred. For example, although a student cannot bring to
class the hike in the woods they took over the weekend, they can
bring the cool rock they picked up on that hike as a representation
of what they did. By connecting the tangible rocks with the intangible
hike, students are able to make generalizable connections about the
elements of a hike, where to nd rocks, and what future hikes or rocks
might be like.
As adults, images and objects function in the same way: an object
or visualization allows us to give shapes to ideas. From that starting
point, we can then talk about a desired experience, substance, process,
etc. that cannot be present. For this reason, the old game of show and
tell as useful in meetings as it was in your grade school’s class.
PURPOSE
The Design phase is all about creation.
To aid idea expression and development,
designers use non-verbal and non-text-
based communication to show their
ideas and thoughts in addition to talking
and/or writing about them. We use these
because it can be difficult to express
the fullness of ideas verbally or in text,
especially collaboratively, when the idea
is still emerging, vague, or unfinished.
That being said, alternatives to verbal
and text-based communication chan-
nels, like drawing, collaging, or mod-
el-making, aren’t better than verbal- and
text-based communications; they’re all
different from one another and can be
used in unison.
Each communication method answers a
specific set of needs, according to the
strength of that method. If talking about
the changes you’re thinking of making
to an existing system is confusing, why
not draw it? If you can’t really describe
a better visual-impairment melody for a
system to play when people log in, why
not hum two or three options, record it
on your phone, and email that instead?
You might feel silly at the time you’re
making the drawing or recordings, but
your team will understand what you’re
thinking faster, and you’ll be able to more
forward on the project rapidly. In this
way, drawing, building, collaging, and/or
recording our ideas is faster, more clear,
and more actionable than just talking or
writing about them.
Communicating Ideas Through Design
Envisioning Ideas
Discovery Stage Research Cycle / Before / Plan
Using References: Communicating Happiness
In this example, a team member would like to
describe a product or service that should have a
happy, sunny feeling. To do this, the team member
has collected images to help them communicate
what they mean when they talk about a happy,
sunny feeling. As you can see, none of the images
in this section are actually images of “happy”.
One is a line drawing of two people talking to each
other with stars around them. One is a logo that
uses a sun-like form that seems like it might be
quite happy and optimistic. The third is actually
the words “I’m walking on sunshine”, but in a font
that looks happy and fat, sort of like it’s written
in toothpaste. And the fourth is a photo of a beach
on a sunny day, which many people associate with
happiness.
So none of these images are actually images
of happiness, and none of them is particularly
sophisticated. In fact, they look homemade or
pulled o the internet. And that’s part of the point:
references shouldn’t be polished; they’re a quick
way to communicate your thoughts, not your nal
presentation. But what is a picture of happiness,
and how could your nal idea be just “happiness”?
First, there isn’t one picture of happiness, because
it’s dierent for all of us, and secondly, this is not
the time to have a nal idea; you’re still envision-
ing and communicating your rst draft ideas. This
is why using references is so useful when talking
about abstract concepts like happiness and when
working at the early stages of your design phase.
38 39
Human-Centered Design: Design Phase Concept Guide
Using Collections of References for Ideation
As design teams begin to ideate, they start to create collections of
references, often called Reference Decks, to help show their ideas. By
accompanying these collections of references with words, whether
written or verbal, the team can more easily understand what it collec-
tively is thinking or what an individual teammate is thinking, keep a
record of that thinking, and edit the idea.
Because design teams evolve or create new products, services, or
systems, there’s no exact photo or sketch or recording of it that exists.
For this reason, it’s essential to develop a collection of references that
are like the product, service, or system you’re envisioning in order to
express all your thoughts on how a design might look, feel, and func-
tion. The purpose of using references, whether drawn, photographed,
recorded, et cetera, is to meet four primary goals:
• To explore nuances in a proposal, system, or idea.
• To understand those nuances.
• To clarify those nuances, especially if they act within a complex
system.
• To communicate the steps above to others who may or may not be
present in design meetings.
When to Use References
Design team members can use references to aid in communication
with their teammates at any point in the design process. However,
since references inform the direction of an idea’s designed form, and
not the details of that form itself, they are most frequently used early
in the process of making a prototype design solution. If the team
nds itself still leaning on references as they approach a low-delity
prototype that’s testable in the eld, that can be a marker of a team
that is not coalescing around a design direction, and thusly the team
needs to back up and start the design process from the idea again.
Specic practice on the form and cadence of using references will be
provided in the upcoming Design Phase Operations Guide.
REFERENCES
The Lab Education Courses
Visual Eloquence
Visual Communications
https://lab.opm.gov/class-sign-up/
To read more about the interaction of
words and pictures, please see Scott
Mccloud’s excellent graphic work.
Scott Mccloud
“Understanding Comics”
http://scottmccloud.com/2-print/1-uc/
IMPORTANT TO NOTE
Understand that different cultures
assign different meanings to shapes,
colors, gestural forms, and groupings,
the same way different parts of the
US assign different meanings to words
(try ordering a pop in a restaurant in the
South. No one will know what you’re
talking about.) For this reason, if the de-
sign work is to be shared across languag-
es or cultures, some research is required
to ensure that the work retains the
intended impact across all audiences.
Building Out Ideas
Discovery Stage Research Cycle / Before / Plan
Exploring Happiness
Returning to the references for “happiness”, as seen
in the Envisioning Design section, how might they
each inform an overall idea of a product or service?
This line drawing shows two people talking. They
seem to be facing each other, and their little,
line-drawing eyes communicate pleasure. This
seems to indicate that the idea of happiness in
this product, service, or system has to do with
human connection and communication as a form or
components of happiness.
The ag in this graphic seems to indicate that the
product, service, or system will be related to the
United States of America, while the graphic sun
conveys optimism and hope. This item also intro-
duces the ideas that the expression of happiness in
this product, service, or system is modern, clean,
and minimal.
This bouncy text not only communicates the idea of
movement and joy, but also, like the logo, informs
the form of the idea through the use of a distinct
typeface.
The image of the beach conveys ideas of happiness
associated with being outside in the natural world,
serenity, and peace.
40 41
Human Centered Design: Discovery Stage Field Guide
Conclusions
If these four images were a teammate’s reference
deck, what might be a few ideas to take from it?
One might be that the product, service, or system
that the teammate envisions has to do with hap-
piness as a social connection, away from work, in
a light-hearted environment such as community
engagement or outdoor exercise opportunities for
veterans or school children. Because this is only
an example, one might take away many ideas from
it. For a more precise understanding of the idea,
the reference deck would need to be built out more
fully, preferably accompanied by verbal or written
cues as well.
Discovery Stage Research Cycle / Before / Plan
Example Reference Deck
Telehealth Toolkit
The Telehealth Toolkit is a prototype knowl-
edge-sharing repository designed for the Oce of
Telehealth in the Veterans Health Administration.
This reference deck uses examples from several
well-known, well-organized sites that share
knowledge in dierent ways. Multiple ideas for the
Toolkit are described by the aspects of each site
that is highlighted.
This deck is from the very beginning of the design
team’s design phase for this digital product. At the
beginning of the design process, the deck refers
to the product as the “Genius Bar”; however, the
nal name is the Telehealth Toolkit. This change is
typical of reference decks. Because they’re begun
so early in the design process, they’re often called
by dierent names from the nal name iteration,
since the information and references that decks
contain are simply the starting point for the
iterated design process.
One of the members of the design team made this
deck so that they could communicate their ideas for
the toolkit (or Genius Bar) to other team members.
Making this deck has nothing to do with a knowl-
edge of user experience coding or layouts; it has to
do with understanding the synthesis of research
that the team had performed during the Discovery
Phase. The design team member searched the
internet for examples of what they thought should
be built to solve for the participants' needs, then
compiled those examples into this deck.
42 43
Human-Centered Design: Design Phase Concept Guide
Everyone Iterates
Iteration refers to making a series of design versions. This is a classic
design practice; its purpose is to push designers past the rst expres-
sion of ideas in order to build them out, identify their advantages and
drawbacks, and revise ideas before prototyping begins.
Iteration
Discovery Stage Research Cycle / Before / Plan
Turning Insights & Opportunities
into Design Iterations
Designs must emerge from Discovery. Below is the
process diagram from the HCD Discovery Phase
Guides and the Designed Things section of this
Guide. Here, the diagram is further developed by
the use of puzzles called tangrams to show how
each opportunity can be developed into multiple
iterations.
Most people, in any profession, iterate constantly: they just dene the
iterations they’re making in terms of their immediate outputs, wheth-
er those are emails or processes or methods, instead of their strategic
goals. In design iteration, teams use iterations as a way to approach
the strategic goals of the project as well as fulll the immediate goals
of it.
To understand iteration at the immediate, daily level, think about
emails. Any email that requires a bit of thought, whether it’s for work
or a personal matter, requires iteration. When we write thoughtful
emails, we think about what to say. We try out wording, delete words,
and move things around until we think we have expressed in the best
way what we want to say. Then we send it. All those dierent email
versions were iterations of the email. They weren’t the email’s nal
form; they weren’t even the second or the third. They were how ever
many versions that had to be made in order to reach a version that
seemed to be the most clear, best way to say what needed to be said.
The tangrams in the Fields of Opportunity are
stand-ins for an iterative design process. Why tan-
grams? Because a tangram puzzle is a useful way to
talk about the cycle of ideation and iteration during
the design phase. Every tangram is comprised of
the same seven shapes, called tans.
To solve a tangram puzzle, a player looks at an
outline of a tangram shape and re-creates the
shape using all seven tans, with no alterations
and no overlaps permitted. (Find out more about
the history of tangram puzzles.) Each dierent
tangram is representative of a new iteration
within a eld of opportunity cone. And, like design
iterations, each tangram takes on similar, though
not identical, shapes. Similarly, the design team is
putting together pieces identied in the Discovery
Phase, pieces that, through ideation and iteration,
become a new product, service, or system.
Coming up with only one design option will almost
never produce the best solution. That’s akin to
walking into a supermarket and buying the rst
apple you see because it’s an apple and you need
an apple. You don’t do that. You examine several
apples, considering their size, sweetness, and
defects in the light of what you need before making
the nal decision. It is the same with design
solutions. You work with many possible solutions to
arrive at a selection that is best suited to the needs
of your participants.
All your iterations are related to each other, but
none is identical. Instead, they build on one an-
other, just as all tangrams are built from the same
seven shapes into an innite variety of nished
creations.
Additionally, like the constraining rules of the
tangram puzzle game—only the seven tans, no
alterations, and no overlaps—there are many times
your solutions will need to address or operate
inside some strict constraints dictated by factors
like time, costs, and climate.
In your work, the team has a need to create
something new based on research, insights, and
opportunities identied in the Discovery Phase.
Sometimes, this process can seem daunting or even
pointless, but, as in the Synthesis portion of the
Discovery phrase, you will nd that the more you
and your team work with the ideas for design, the
more possibilities you will see.
44 45
Human-Centered Design: Design Phase Concept Guide
Your work Only Gets Better
Feedback is an integral part of the design process and should be
sought out when designing anything, be it product, service, or system.
In design, feedback is a multi-step phase during which the design
gradually reaches farther and farther outward from the core team in
order to gather feedback from an increasingly large pool of feedback
providers.
It’s preferable to gather feedback on several of the team’s design itera-
tions. Through feedback, the team is able to understand which design
ideas might hold up best in real-world conditions and which ones
resonate most with participants. Feedback also allows the team to
improve and rene the design iterations, using the feedback reviews
to gradually phase out the design iterations that are less successful
while rening and focusing the more successful ones.
In this section, see the cycle of feedback and revision for a single
design solution. Two steps make up a feedback phase: (1) receiving the
feedback from an individual or group and (2) making revisions to the
product, service, or system based on that feedback. In each feedback
step, the circle of people the team reaches out to for feedback moves
farther away from the core team and farther into the eld of potential
participants.
These feedback sessions can take the form of codesign workshops,
prototype testing, or other formats depending on the product, service,
or system being tested. Guidance on dierent feedback formats will
appear in the Design Phase Operations Guide. For the second step,
design revision, the team revises the design internally in order to
integrate the feedback from the people that have been asked. Revision
activities generally take the shape of tiny synthesis sessions; you will
nd guidance on those in the Operation Guide as well.
Feedback
Discovery Stage Research Cycle / Before / Plan
Feedback and Revision
Process Map
This Feedback and Revision Process is a basic
framework for how to seek out and integrate feed-
back into a product or service you have designed.
Before jumping into the feedback loops, the team
needs to review the primary Design Phase Princi-
ples as well as the principles you developed during
Problem Framing. After an intense iteration phase,
in which the team gets deeply involved in details, a
refocus onto the participants and the strategic level
goals of the project will prove useful.
There are two parts to the feedback process:
(1) Finding out the people to talk to
(2) Making changes to your design based on their
feedback.
Strategies for Feedback
Creating a strategy for feedback allows the team
to collect feedback logically and methodically. The
team should test with people who are all current
participants or future participants in the product,
service, or system that is being created, but those
particpants can and should be from dierent areas
of the design object's use. For example, if you test
with a front-line participant at one stage of testing,
you should try to balance that by testing with a
leadership level participant at another. Of course,
it's not always possible to perfectly construct feed-
back testing rounds; the purpose of this guidance
is not to create an impossible goal of perfection for
testing, but to give guiderails on the best way the
team can go about this process.
If testing narrows in on a single participant group
for reasons of access or timeline, that's okay, but it
will result a not-as-thoroughly testing prototype.
For this reason, the designed product, service, or
system's potential for success is lessened. While
this is sometimes acceptable, it is not desirable.
Work with your leadership to nd a way to either
extend your team's timeline or to gain access to the
participants you need.
46 47
Human Centered Design: Discovery Stage Field Guide
Who to Talk To: An Expanding
Galaxy
In testing rounds, the design team needs to
get feedback from people who have increasing
amounts of distance from the project. This is for
two reasons:
1. Starting with participants previously involved
in or aware of the project allows the team to
test low delity prototypes with people who
have context on the project itself. This will
provide actionable feedback to increase the
renement of that prototype quickly.
2. Moving outward to people who have no rela-
tionship to or awareness of the project includes
the perspective of absolutely new participants.
This allows the design team to learn about
and correct for the issues new users will have
without having to nd out those issues during
a pilot.
This group will also encounter a clos-
er-to-launch-delty prototype, which prepares
them for interacting with the new product,
service, or system during the pilot phase.
Note: All participants outlined below should be
current or future users of the product, service, or
system that the team is currently designing. The
dierences between these people are their close-
ness to the research and design process of the new
product, system, or service.
Discovery Stage Research Cycle / Before / Plan
Round 1
An ideal person for round 1 feedback is someone
who has previously been involved in the project and
is familiar with the research or design of phases
of it. This can be one of your primarily research or
design partners.
Round 2
A good type of person for round 2 feedback is
someone who is close to but not directly involved in
the research or design of it. This can be the team-
mate of one of the Round 1 feedback people who
you simply haven't talked to directly before.
Round 3
It's useful for round 3 feedback to talk to someone
who is aware of the project, but not previously
involved in the research or design. This can be an-
other teammate of people in Rounds 1 or 2 but, for
whatever reasons, has been somewhat distanced
from the project development.
Round 4
A strong candidate for round 4 feedback is a person
who has not previously been in touch with the
team or the other participants about this project at
all. This person's fresh eyes will help head o any
quirks or stumbling blocks that, due to familiarity,
the previous testers might have taken for granted.
48 49
Human Centered Design: Discovery Stage Field Guide
What to Do with Feedback:
Make Changes!
Each time the team gathers feedback on the
designed product, service, or system, document,
meet, and discuss that feedback. Think of this
process as a smaller, more concentrated version of
the Problem Framing process the team underwent
during the early parts of your Discovery Phase.
In that process, as new information about the
large problem frame was uncovered through desk
research and the identication of constraints, the
team narrowed in on the specic problem frame in
which you were going to operate. Similarly, in this
process, as the team tests with participants, you
will make changes to your prototype to narrow in
on a more useful and resonant product, service, or
system for your participants.
You'll work with the resources you have, within the
constraints of the product, service, or system you
rst designed based on your research, to better t
the needs of the ultimate participants in your work.
This means tweaks, not systematic changes.
If, at this point, you nd the need for large scale,
thematic or systematic changes, it means the
design that you’ve forwarded does not accurately
reect the opportunities identied in the Discovery
phase, so the team will need to start again on the
design process. This outcome is not failure; indeed,
it simply means you know more about what your
participants need. And, if you’ve designed in quick,
fast iterations, you’ll easily be able to go back and
change your direction without adding a great deal
of cost or time to your project.
Below, nd another visualization of making small
changes based on feedback. As you can see, the
tangram shape stays roughly the same shape
through all the revisions. They all, vaguely, look
like a person standing up in dierent poses. Those
dierent poses are created by moving around
some of the pieces that make up the puzzle. These
changes are analogous to the changes the design
team should be making in the feedback cycle: ones
that change details to the overall design, but not
the core idea of the design itself.
Bringing It All Together
Through the feedback cycle, the team will talk
to a variety of people to gather feedback on the
product, service, or system the team is designing.
Those people will have dierent positions to and
awarenesses of the project and its history. As you
gather feedback from these people, the team will
make changes to its design in response to that
input. If the feedback points the team to an entirely
dierent design, that’s okay, but the team must
throw out its design and start the design process
itself again. In this case, the team might want to
review their Opportunities from their Discovery
Phase and identify a new direction in which to go
for their new design.
A Note on Using Feedback:
It is important to know that not every piece of
feedback from each participant can should be
integrated. Be aware of the primary principles of
the design phase (and review them if you need
to) as well as the principles from your problem
framing phase.
If your design resonates deeply, people will be
excited about its potential, have great ideas for
improvements, and really want to see those
improvements. Ensure that you compare those
suggestions to your original project scope and
technical ability. If you cannot integrate an
improvement into this stage, that’s okay. Com-
municate to the participant that their feedback is
well-placed and important, and that you will note it
for integration into a future version or as an idea for
a related product or service.
50 51
Human Centered Design: Discovery Stage Field Guide
No “hand os”; no “waterfall”
When the web was young, the “waterfall” process
of development organically developed as a way
content-makers and designers could push content
to the engineering teams to be put up on the web.
The waterfall process of content development is
linear: one team completes their tasks and passes
to another team who completes their tasks and
then pushes to another team, and so on, until the
nal product is realized.
Broadly, this process was an adaptation of the
traditional, factory-like print media workow from
newspapers and magazines. In this process, the
Editorial team would write and edit text content,
push it to a Design team to lay the text out on a
page and work in the illustrations and photographs,
and then the Design team would push the layouts
to the Printers, who would implement the design by
setting the printing presses to churn out the nal
product.
That was the ideal. In reality, however, these
three groups almost always work together in a
less-than-linear, collaborative workow. This
was because the rigid nature of the ideal process
assumes that no group will ever have questions
for the previous or following groups. This assumes
that each group understands all the needs and
constraints of the other groups in the process and
will not produce something that is impossible or
dicult or even creates questions in a future stage
of the product development.
Design & Implementation
This, however, is impossible. Even in a completely
controlled environment where there will never
be any changes or revision to content, each group
doesn’t know every constraint and need of next
group, so they will of course sometimes produce
work that causes problems or questions for future
groups in the process.
Plus, that perfect environment is a fantasy; it does
not exist. Changes and revisions happen all the
time. In newspapers, this meant that if something
happened to change the headlines in the early
morning edition, Editorial would rush to write new
headlines and article text; Design would freak out
a little to source a photo and set the text, and the
Printers would have to scramble to reframe the
entire front page to include this new article. But
what happens to the original content? Where does
it go? The Printers need to know, and they also have
ideas — after all, they understand the mechanics of
the page better than anyone. They need to be able
to talk to Design and Editorial quickly in order to
make content decisions. The three groups abso-
lutely had to work together to get changes made in
a way that worked for the newspapers’ readers. And
they had to do it fast.
So, in traditional print media, the groups had to
overlapping work; they had to talk to each other.
This is the same in the current design process.
Design teams can’t just “hand o” designs to the
people who will implemenent them. Whether your
team is developing print media, a digital product
like a website, a real-life object like a kiosk, or a
service like a benets advisory board, working with
the people who will implement is crucial to the
success of your project. No matter how clear you
think you’ve been, no matter how top-notch your
implementation team is, there will be questions
that you need to work out together.
The Design & Implementation phase is analogous
to the Communications phase from the HCD
Discovery Process: until the Discovery Team
eectively communicated their ndings to their
leadership and partners, the Discovery stage could
not be considered complete. Until the Design team
has eectively worked with the Implementation
team to create nal testing through a small pilot
and to help that team create an implementation
plan, their Design work is not done, because the
team has not set the design(s) they crafted up for
success: the designs have simply been carefully,
painstakingly crafted and then shoved out into the
world without support or thought of sustainability.
So never plan to just “hando” your design work
and roll o a project; stay in it through the rst
pilot and help you implementation team develop
and test a implementation strategy. Only then
will you have set your carefully designed solution
up for success.
52 53
Human-Centered Design: Design Phase Concept Guide
What’s Next
You’ve drawn on your Discovery phase work and created prototypes
from it. You’ve tested those prototypes with participants. You’ve kept
your leadership informed. You’ve worked with the implementation
team to make sure the work will see lift-o.
The team is set up for success. Next, with the Implementation team,
move into the Deliver Phase and see your work enter the world at
scale!
Deliver Phase
Contact Information
Please send questions or comments.
GSA Customer Experience: customerexperience@GSA.gov
The Lab at OPM: LAB@opm.gov
Thanks and Acknowledgment
Numerous people, across agencies, contributed to this guide. We are grateful to
all of them.
Veterans Experience Oce at VA
GSA Oce of Customer Experience
The Lab at OPM
We would also like acknowledge other leaders in the eld of Human-Centered
Design which inspired and informed this guide: The VA Innovators Network,
18F, USDS (United States Digital Service), Deloitte & Doblin, Helsinki Design Lab,
Luma Institute, Ideo and Ideo.org, Frog Design, IBM Design, and The d.School at
Stanford University.
Thank You!
Discovery Stage Research Cycle / After / Next
54 55
Human Centered Design: Discovery Stage Field Guide
Glossary
3 Es
Effectiveness, Ease, and Emotion are the 3 core qualities that VE
measures across the enterprise. These are based on a Forrester
Research Inc. pyramid model of customer experience.
5 Whys, aka, Laddering
A method by which an interviewer derives additional detail and
undercurrents from an interviewee. Typically characterized by the
interviewer asking “why” in regards to a qualified or abstract word or
phrase used during the an answer to questions. A common metric is
for the interviewer to do this five times in a line of question.
Accessibility
The extent to which content is available, understandable, and
usable by all audiences, regardless of sensory, physical, cognitive,
intellectual, or situational disabilities or impairments.
Best Practice
Procedures or approaches that are accepted or prescribed as being
correct or most effective.
Clustering
A research analysis method characterized by the grouping of words
or phrases that have a single or set of commonalities. In Design
Research, this is often enacted physically by the assembly of words
or phrases written on single pieces of paper into a, proximate group.
Concept/Context mapping
An ethnographic research technique, concept/context mapping is
a process that tries to understand the environment in which the
behavior under study takes place.
Customer Experience (CX)
Customer experience (CX) is the product of an interaction between
an organization and a customer. This interaction includes a custom-
er’s attraction, awareness, discovery, cultivation, advocacy and
purchase and use of a service. It is measured by the individual’s
experience against the individual’s expectations.
Decode
To understand. To analyze in order to find meaning.
Empathy
The action of understanding, being aware of, being sensitive to, and
vicariously experiencing the feelings, thoughts, and experience of
another through a shared experience.
Ethnographic research
Ethnographic research tries to understand how people live their
lives. Unlike traditional research, who ask specific, highly practical
questions, ethnographers may visit homes or offices to observe
and listen in a non-directed way. While this observational method
may appear inefficient, it enlightens us about the context in which
customers see their own environment.
‘Fail early, fail fast, fail small’
A Design Research principle expressing the ethos that, through
quickly making and testing small, unsuccessful solutions to big
problems in quick succession, drawing lessons in terms of what
works and does not work from those tests and revising the next
solution accordingly, more effective and successful end solutions
can be reached than if a single large solution was launched once and
without testing.
Front Stage / Back Stage
Parts of services that are visible to the service user are called front
stage. Part of services not visible to the service user but are inter-
acted with by the service provider are called back stage.
Guided Tour
A research methodology during which a participant shows re-
searcher(s) their physical space, collections, or other assets so that
the researcher(s) understand the participant’s context and reality
through the participant’s point of view.
How Might We Question
A “How Might We” (HMW) question serves two purposes. First, it
is the frame of inquiry, or the area of research. And second, a HMW
question should spur and inspire the research team. A good HMW
research question will focus but also leave room for exploration.
Human-Centered Design
Human-centered design (HCD) is a design and management frame-
work that develops solutions to problems by involving the human
perspective in all steps of the problem-solving process. Human
involvement typically takes place in observing the problem within
context, brainstorming, conceptualizing, developing, and imple-
menting the solution.
Ideate
To form an idea of; imagine or conceive. In Design Thinking, this
refers to imagining or conceiving of multiple ideas for solutions to
problems, usually in succession and building off each idea.
Innovation
A new idea, method, or device. In Design Thinking, usually charac-
terized by a break from traditional or institutionalized methods,
production methods, or products .
Intercepts
Intercepts (intercept interviews) are conducted on site with Veter-
ans while they are interacting with services at the research site.
Internal bias
A universal situation in which humans feel or show inclination or
prejudice for or against someone or something. In Design Thinking,
the inherency of internal bias is accepted, and we correct for these
biases is through awareness and acknowledgment of them.
LEAN (process)
An approach that focuses on people, process and purpose and the
alignment between the three.
‘No wrong ideas’
In Design Thinking, the principle that, in order to forward innovative
thinking, the group or individual performing the thinking session
must accept and consider all ideas as possible solutions.
Pain Points
In experience design, pain points are real or perceived problems
experienced by customers within a system.
Problem frames
The area of research in regards to a particular problem.
Qualitative research
Primarily exploratory research. It is used to gain an understanding of
underlying reasons, opinions, and motivations. It provides insights
into the problem or helps to develop ideas or hypotheses for poten-
tial quantitative research.
ROI
Acronym for: Return on Investment.
Root cause
The fundamental reason for the occurrence of a problem.
Shadowing
A research methodology during which the researcher follows the
participant through the participant’s activities. These activities
show the researcher the participant’s physical context as well as
their interaction within that context.
Sensemaking
To make sense of; to understand.
Snapshots
A representative sample of research. In design-oriented presen-
tations, this refers to a collection of photographs, quotations,
and synthesized research that is formatted to tell the story of the
research endeavor.
Stakeholders
Persons, groups or organizations that have direct or indirect stake in
an organization because it can affect or be affected by the organiza-
tion’s actions, objectives and policies.
Sympathy
The action of understanding, being aware of, being sensitive to, and
vicariously experiencing the feelings, thoughts, and experience
of thorough emotional and intellectual understanding of another’s
experience. Contrasts with empathy in that it does not include a
shared experience.
Synthesis/synthesizing
To combine (a number of things) into a coherent whole. In De-
sign Thinking, this refers to the collection and integration of the
substance of the research instances into a logical and meaningful
collection.
Touchpoints
Any point of contact between a customer and a service or service
provider. This could be the design of a receipt, the comfort of a
waiting room or the usability of a web page.
Yes, And
In Design Thinking, the logical opposition to the statement, “No,
But...” Meant to set up acceptance and integration, this form of reply
to statements can allow for expansive conversation instead of a
negation of opinions and options.
Appendix / Glossary
56 Human-Centered Design: Discovery Stage Field Guide
Notes
Unique ID:
Project:
Quotes, Photography and Video Consent Form
Thank you for your willingness to participate in this research study.
Use of Quotes
When we write reports or presentations on what we learn from the interviews, wesometimes use specific
quotes from study participants. Quotes bring to life what we learn and are an important part of sharing
your experience with others. If you give us permission to use your quotes, we will not include your name
or a photograph of your face next to the quote.This protects your identity and makes the quote
anonymous. If you approve of your quotes being used in future publications or presentations of our work,
please include your name and signature in the section below.
Name ____________________________________________________
Signature _________________________________________________
Date _____________________________________________________
Photography and Video
The project team may take pictures or video during the interview. Photographs and Videos bring to life
what we learn and are an important part of sharing your experience with others. If you give us permission
to use photographs or videos of you, we will not include your name or a quote as part of the photograph
or video description. This protects your identity. If you approve of photographs or video being used in
future publications or presentations of our work, please include your name and signature in the section
below.
Name ____________________________________________________
Signature _________________________________________________
Date _____________________________________________________
Please keep a copy of this document in case you want to read it again.
Photocopy this
Consent Form for
use in the eld.
59 58 Human-Centered Design: Discovery Stage Field Guide
