IBM Design Thinking

Field Guide
We all think.
IBM Design Thinking is how we come up with the
answers to our toughest problems. It’s a way for us
all to think together—to work as one and make a
difference in the life of a user.

THIS IS HOW WE THINK TOGETHER.

IBM Design Thinking guides the journey we take together
as a team to get to an iconic outcome. This journey can
take many forms but there are some key bits that we
have found are essential to finding great answers to
tough questions. Welcome to the field.

What’s inside?
Divided into two sections, this field guide provides a high-level
overview of IBM Design Thinking:

LEARNING IT
A summary of the fundamental concepts of IBM Design Thinking

LEADING IT
A quick reference for facilitating essential IBM Design Thinking
activities on your team
 LEARNING IT

Hills Sponsor Users

Explore Evaluate

User-centered design Understand Prototype

Design as a professional discipline has undergone a tremendous

evolution in the last generation from a practice focused mainly on
aesthetic style to one with a clear and explicit focus on the “user”
(aka: person or group of people who use a product or service) and Playbacks
their hopes, desires, challenges, and needs.

By establishing empathy with the user, designers are able to work

toward outcomes that meet those needs more successfully. IBM Design Thinking
This user-centered approach known as “design thinking” enables
designers and others to address a wide range of complex business At IBM we are practicing design thinking at a global scale and at
and social issues. a level of complexity that has never been done before. With teams
dispersed across the globe, collaboration and alignment among key
project stakeholders in our organizations can be extremely challenging.
Likewise, the deep legacy of many of our products and businesses
makes it particularly challenging to implement change.

“Designers don’t try With IBM Design Thinking, we have added three scaling practices
to search for a solution until they to the conventional design thinking approach—Hills, Playbacks,
have determined the real problem, and even and Sponsor Users—to help extend design thinking to the complex
then, instead of solving that problem, they stop to problems and teams a global organization like IBM has. These
consider a wide range of potential solutions. Only practices enable our teams to gain focus and alignment and ultimately
then will they finally converge upon their proposal. to develop truly great product outcomes.
This process is called design thinking.”

—Don Norman,
author, The Design of Everyday Things

Learn more

IBMers can watch an introduction to IBM Design

Thinking webcast: [Link]/ibmdesignline_intro
2
 LEARNING IT

Hills are user-centric statements that define the mission and scope
of a release and focus the work on desired market outcomes. At any
given time, you should be working on no more than three major project
objectives—Hills—plus a technical foundation. Each individual Hill
articulates a clear and containable scope defined to be achieved in
one release or in a finite set of releases.

Hills TAKE-BACK TIPS

Who, What, Wow! Hills are composed of a “Who” (a specific user

Hills are about you and your team or group of users), a “What” (a specific action or enablement), and
a “Wow” (a measurable, market differentiator).
coming together around the things you
Three and only three. It’s often challenging for teams to focus on
know are most important for the user. three (and only three) Hills because this might mean that very valid
ideas are not being included. It’s important to realize that additional
Hills can be addressed in future releases. Consider building them into
a product roadmap.

It’s a real world out there. We know there’s a backlog to groom

A SAMPLE HILL
and technical debt to pay down. Your investment in necessary items
like these—the “technical foundation”—should be made explicit
WHO A sales leader
up front while defining your Hills.
team
WHAT can assemble an agile response
on
from across her entire corporati
WOW in 24 hours, without management
Learn more
involvement.
IBMers can watch the deep-dive
Designline episode on Hills:
[Link]/ibmdesignline_hills
4
 LEARNING IT

Playbacks are both project milestones and informal delivery check-ins

that align teams, stakeholders, and clients around scenarios that show
the value of your offering. Playbacks serve many purposes: to capture
feedback and ideas from stakeholders, to check your progress against
original goals, to review designs, and to communicate the current state
of your work.

Playbacks TAKE-BACK TIPS

No surprises! Leading up to milestone Playbacks, hold meetings and

Playbacks are a time to show what working sessions with all necessary stakeholders to gain consensus
and share work-in-progress along the way.
you’re doing and get everyone
Show before you tell. Playback decks should have a strongly visual
on the same page. emphasis based on the work—not contrived synopses or feel-good
scenarios.

Make us care. A real, human story should be at the core of every

COMMON TYPES OF MILESTON Playback. Show how your tool or concept solves a problem in
E PLAYBACKS
your user’s real world workflow.
MARKET PLAYBACK establishe
s HILLS PLAYBACK commits
an outside-in market point of view
your team to the mission for the
and preliminary business case
release(s) through a draft version
as the basis for moving forward.
and the underlying personas.

PLAYBACK ZERO aligns your team

DELIVERY PLAYBACKS of code
around a finalized version of the d
stories keep your to-be scenarios
Hills and the user experience to in
focus as implementation advances Learn more
achieve them. .

IBMers can watch the comprehensive

Designline episode on Playbacks:
[Link]/ibmdesignline_playbacks
6
 LEARNING IT

Sponsor Users help you to surface many aspects of the problems

that you’re trying to solve in a Hill. Since Sponsor Users represent the
problems, they are also critical in validating the solutions that you are
envisioning, designing, and implementing. Sponsor Users help identify
edge use cases that cannot be identified by personas alone.

Sponsor Users TAKE-BACK TIPS

Design for real target users rather than imagined needs. Sponsor
Users should be real people, not personas or “types.” They participate
Sponsor Users are real people with with your team during the entire development process under NDA.

real opinions. They’re actual users Sponsor Users should attend Playbacks. Ideally, a Sponsor User
can actually present the product demo during your Playback Zero.
you can build your product with.
Involve your whole team. Finding Sponsor Users is not the
responsibility of a single person or discipline—everyone on your team
should be contributing ideas for Sponsor Users.

POTENTIAL SPONSOR USERS

ARE ALL AROUND US

Social media
IBM Customer Councils
Learn more
Your IBM sales organization
LinkedIn
IBMers can find out much more about Co-working spaces
Your own experiences
Sponsor Users in this Designline episode: Meet-ups
[Link]/ibmdesignline_sponsorusers Friends and family
Fellow IBM colleagues
Conferences
Craigslist ads
…and others!

8
 LEARNING IT

Six universal experiences

The six universal experiences are a means to focus your work for
a release or planning period on a user’s distinct interactions within
the overall arc of their experience with an IBM product.

TAKE-BACK TIPS

Be choosy. For any particular release, focus your work on one or two
of the six experiences.

It ain’t a checklist. Rather, use the six experiences as a lens to DISCOVER, TRY, AND BUY
ensure that your team is holistically considering all of your user’s How do I get it?
product experiences.

GET STARTED
User, user, user. The six experiences can help organize dispersed
How do I get value?
teams (including sales, support, and marketing) around user-focused
outcomes.
EVERYDAY USE
How do I get my job done?

MANAGE AND UPGRADE

Learn more How do I keep it running?

There’s lots more about the six universal

LEVERAGE AND EXTEND
experiences on the IBM Design Language
website: [Link]/design/language
How do I build on it?

SUPPORT
How do I get unstuck?
10
 LEARNING IT

IBM Design Language

The IBM Design Language is a living vocabulary for communicating
our brand promise through a product’s experiences. It’s comprised
of guidelines, resources, and inspiration that help designers and
developers create software that speaks to our users.

Like the style and structure of a spoken language, the IBM Design
Language is crafted with similar units of expression to create different
products that work together. We invite you to use our language and
join the conversation at IBM Design.

TAKE-BACK TIPS

Speak the language. Learn the principles of the IBM Design

Language and apply them to your user’s context.

Define your personality. Align on a personality for your offering by

describing how it looks, feels, sounds, and interacts.

Design for everyone. Explore issues like flashing animations or color

contrast to ensure users from all walks of life can get value and delight
from your product.

Put the resources to work. From creating a type scale to leveraging

the icon library, use the tools to develop a design guide for your product.

Learn more

Check out the IBM Design Language at

[Link]/design/language
12
 LEARNING IT

Radical collaboration

Radical collaboration
“Radical collaboration” means that all key stakeholders are part of
co-creating great user experiences from the beginning. For your team
to take full advantage of IBM Design Thinking, you need to commit to a USER EXPERIENCE TECHNOLOGY

cross-discipline way of working throughout the entirety of a release.

Design Engineering
Organization Organization
One key to radical collaboration is to break up decision making into
small enough “chunks” that there is a constant flow of interaction
between disciplines. Of course, such a continuous flow of interaction
means that your tooling must enable real-time sharing of information
and decision making—see page 20.

TAKE-BACK TIPS
BUSINESS
Good collaboration needs good tools. Create a “tool chain” of
integrated collaboration tools that enable stakeholders from each Offering Management
Organization
discipline to share their work-in-progress with other disciplines
while working day-to-day in the tools that fit their discipline best.

Don’t slip back into the waterfall. If you start to find your team
simply reviewing artifacts after-the-fact with stakeholders from other
disciplines: STOP AND START OVER with broad, up-front, and active
participation in their creation.

N-in-a-box. Whenever possible, go beyond “3-in-box” (design,

engineering, and offering management) to include other disciplines
such as content design, sales, marketing, and support in design
thinking activities, key decisions, workshops, and milestone Playbacks.
14
 LEARNING IT

IBM Offering Management Strategic

Planning
IBM Offering Management is IBM’s point-of-view on markets, users, and Portfolio
products, and services. Offering managers decide in which markets Management
Market Opportunity
IBM will play and how we will differentiate in those markets via and Approach
unique functionality, great user experiences, digital engagement,
and ecosystem partnering.

Offering managers are empowered to act as entrepreneurs to explore Define and

Prove
new markets of users with new user experiences. They are responsible
for leading the co-creation of “whole” offerings that deliver value
across all of the six universal experiences.
Measure and
Evaluate

TAKE-BACK TIPS

Get outside. Great offering managers “get out of the building” to Build and
Deliver
discover real user experiences to improve upon. User, market, and
competitive research provide the fact base for all offering decisions.

Look across offerings. Given IBM’s comprehensive portfolios,

offering managers should look at how individual offerings work together
to address users in a market. Most of our offerings will be part of larger
solutions.

Lead your offering. Offering managers are being empowered to

lead their offerings, but no one is going to clear the path for you. It’s up
to each offering manager to act as an internal entrepreneur for their
Ch-ch-changes. At IBM, the practice of Product Management is
offering—their key “superpower” will be persuasion, not command.
evolving into Offering Management to ensure that IBM wins in markets
with iconic user experiences and an integrated point-of-view that is
differentiated from competitors.
16
 LEARNING IT

Learn more

IBMers can learn more

at Agile Academy:
[Link]/AgileAcademy

Agile and
IBM Design Thinking Individuals
and interactions
There’s a great deal of shared “DNA” between Agile and IBM
Design Thinking: individuals and interactions over processes and
tools, working prototypes over comprehensive artifacts, customer
collaboration over contract negotiation, and pivoting for change Agile principles Responding
over sticking to the original plan. IBM Design Thinking incrementally to change
delivers great user experiences, while Agile incrementally delivers Radical
great enabling software. What links them most closely is the collaboration
continuous cycle of experience maps and Playbacks.
Working
deliverables
TAKE-BACK TIPS Continuous
delivery and
learning
Everyone grooms the backlog. After Playback Zero, all disciplines
collaborate on a release backlog. Throughout the release cycle, leaders Customer
from each discipline meet to groom the backlog, updating the priority collaboration
as necessary and ensuring that the top of the backlog represents Focus on
outcomes IBM Design Thinking
current priorities and stays true to the “minimum delightful experience.” for users principles

Double-vision. When developers, designers, and offering managers

all see the backlog through the dual lenses of functionality and
experience, then Agile and IBM Design Thinking are truly one.

Hypothesis-driven design and development. Create measurable

hypotheses describing what you think success looks like and then
investigate and possibly pivot when reality doesn’t meet your
expectation—positively or negatively. Together forever. The principles of Agile and IBM Design Thinking
are very closely aligned. Together, they offer an opportunity to solve
complex problems for our users with creativity and empirical adaptation.
18
 LEARNING IT

WHITEWATER TOOLS

Each of these tools is undergoing inspection to

make sure you can use them in an IBM Confidential
environment. Until then, follow secure practices.

The best tools for the

best practices GitHub Enterprise: A web-based Git repository hosting
service offering distributed revision control, source code
management, and access control in support of a social and
Whitewater is IBM’s solution to shipping better products faster by highly collaborative development workflow.

giving teams modern tooling that supports whole-team practices.

By giving you access to tools that you love using, your team can [Link]: A web-based virtual whiteboard that lets you
more easily and successfully practice Agile and IBM Design Thinking capture plans and ideas with your team.
in a collaborative and user-centered way—whether your team is
co-located or distributed around the world.

Currently, each tool in the program is undergoing close inspection Slack: A messaging app for teams offering a wide range
of integrations with other tools and services along with
to make sure you can use them in an IBM Confidential environment.
powerful search.
IBM teams that have access to the fully-secure environments can
begin exchanging confidential information in these tools right away.

Release Blueprints: A wiki serving as the single place for

your team’s release plans to guide stakeholder alignment.
TAKE-BACK TIPS

Choose wisely. When choosing tools for your whole team to use,
consider the entire makeup of your team and decide if everyone
Bluemix Dedicated: A Platform as a Service that enables
would benefit from using the industry standard tools that Whitewater developers to quickly and easily create, deploy, and manage
is offering. Project teams in the IBM Design Hallmark program can applications on the cloud.
onboard to the Whitewater program and then pick-and-choose only
those tools that are “right” for their team.

Top secret? Not all of the tools that IBM product teams want will be
immediately ready for IBM Confidential information. When using a tool’s
free trial, be sure to check the Whitewater website to find out when or if Learn more
it is expected to be “IBM Confidential Approved.”
IBMers can follow the evolution of Whitewater, check tool
status, and leave feedback at [Link]
20
 LEADING IT

IBM Design Thinking

Mantras activities
of the
This section of the field guide contains activities for your team to use
Master Facilitator every day to you help practice radical collaboration and put the user
at the center of your project. Each activity can be used in isolation
or as part of a broader set of activities with your team and Sponsor
Users. Think of each activity as a tool that helps you establish the IBM
LESS TALKING, MORE WRITING Design Thinking framework, understand your user’s problems and
Everyone should capture lots of ideas onto sticky notes motivations, explore new concepts, prototype designs, and evaluate
and post them on the wall before discussing them. with stakeholders.

LESS WRITING, MORE DRAWING Remember, this is not a cookbook or a set of recipes. Nor is it a
Different words mean different things to different people. Instead, process or methodology. It’s a set of recommended practices that will
try making a quick or crude sketch to communicate your idea. help you think orthogonally and move beyond feature-centric delivery.

QUANTITY OVER QUALITY

Ideas with big potential can be killed easily by negative attitudes, so TAKE-BACK TIPS
first get lots of ideas posted to the wall and then discuss and distill.

Space and supplies. Prepare your workspace with pads of sticky

MAKE EVERY VOICE HEARD notes of various colors, some Sharpie® markers, and a drawing
Everyone has a Sharpie®. Everyone has a pad of sticky notes. surface—a whiteboard or large pad will do. These tools encourage
Everyone contributes ideas. Everyone’s ideas are valid. every team member to engage in the thinking behind the design. If your
team is distributed, there are plenty of virtual substitutes—see page 20.
WHOLE-TEAM APPROACH
Don’t make decisions without involving people that Conversations and collective decisions. The activities contained
will act on them. Everyone pitches in to fill the gaps!
here are intended to encourage focused and productive conversations
between multiple disciplines on your team. The value isn’t in having a
YES, AND… completed artifact—it’s in doing the activities together so that you can
It’s easy to play the devil’s advocate. Instead, push yourself to build agree on the right course of action together.
on your teammates’ ideas by saying, “Yes, and…” while iterating.

If you’re sitting down, you’re having a meeting. Get everyone up and

BE HONEST ABOUT WHAT YOU (DON’T) KNOW active—it’s difficult to include many voices when one person is standing
Sometimes you won’t have all of the answers—that’s
at the front of the room. If you have lots of participants, break them up
okay! Actively work to admit and resolve uncertainty,
especially on topics that put your project most at risk.
into working groups of 5–8 people and frequently playback to each other.
 LEADING IT

Design thinking facilitation

Design thinking facilitators initiate and lead design thinking activities FACILITATION IS AN EVERY DAY PRACTICE.
on their team to reach great outcomes for their users. With time and
practice, anyone can become an effective and credible facilitator. Do you find yourself doing these things on a regular
basis? If so, you’re a natural facilitator!
Whether facilitating an ad hoc activity to help your team work through
an immediate decision or planning a lengthier and more formal
workshop, use what works for you. IBM Design Thinking is designed
GREAT FACILITATORS…
as a framework for you and your team to use bits and pieces of as it
makes sense.
Plan, communicate, and lead design thinking
activities, whether formal or informal.
As a design thinking facilitator, you help ensure that conversations
and activities are centered on the user, how they work, and what
market they occupy. And you can serve as the driving force for Have a passion and enthusiasm for getting the
inclusion and collaboration so the voices of people from all areas whole team involved.
of your business are heard and understood.

Guide coworkers in understanding and productively

TAKE-BACK TIPS engaging in design thinking activities.

Practice makes perfect. Much like practicing IBM Design Thinking

in general, we find that the best facilitators learn to be better facilitators Drive the process and guide to the goal, but don’t
define the details of the end result.
by doing facilitation. Continued weekly practice over time, matched with
coaching or apprenticeship, will prepare you to lead more advanced
design thinking engagements like workshops.
Ensure shared understanding and have everyone’s
voice heard.
Use what works for you. Concentrate your facilitation efforts on
initiating design thinking activities that make sense for the work your
team is doing right now and guiding those teammates who aren’t Know what their limits are and can say, “That’s
familiar with design thinking by actively engaging them in the practices. a great question! I don’t know the answer but
I know someone who does.”

24
 LEADING IT

Hopes and Fears

WHEN YOU MIGHT USE THIS TIME

If you’re starting a project, kicking-off a workshop, 15–30

or bringing in new team members, this activity helps minutes
you get to know each other, expose aspirations and
concerns, and prepare everyone to start.

INSTRUCTIONS

1. Label one area for Hopes and another for Fears.

2. Ask team members, “What about this project are you really excited
about? What has potential? And what are you concerned about?
What do you think won’t work?”

3. Diverge, with each team member writing one “hope” or “fear” per
sticky note and applying it to the appropriate area on the map.

4. Playback, discuss, and synthesize. What themes emerge?

TAKE-BACK TIPS

Warm up and take the temperature. This activity is an effective way

to gauge participants’ attitudes about a workshop. “Hopes” usually
reveal their expectations about what can be accomplished and “fears”
may reveal their doubts about making an investment to work together.

Let it persist. Keep the artifact posted where team members can see
it and refer back frequently to track progress. Place stars on “hopes”
notes that become realized and remove “fears” notes that melt away.
“Fears” that persist should be directly addressed.

26
 LEADING IT

Stakeholder Map
WHEN YOU MIGHT USE THIS TIME

If you’re integrating new team members, starting a 30–60

new project, exploring a new market, or expanding minutes
an offering, this activity helps you identify project
stakeholders, their expectations, and relationships.

INSTRUCTIONS

1. Diverge on identifying stakeholders, one per sticky note.

“Stakeholders” can include teams, team roles, project leads,
executives, partners, customers, and end users.

2. For each stakeholder, add a second sticky note with a quote

expressing their thoughts, opinions, or expectations.

3. In parallel, cluster stakeholders and label the groups.

4. Draw and label lines among groups representing relationships

such as influence, process, or dependencies.

TAKE-BACK TIPS

Don’t delay. Take an inventory of a project’s stakeholders as soon as

possible in the development cycle. It’s difficult to circle back with those
who have been forgotten, so it’s better to get a jump start than to play
catch-up.

Assumptions aren’t always bad. Assume that everyone is involved

or impacted until proven otherwise. This might seem hard to do, but
it’s actually easier than trying to guess who’s impacted and risking an
accidental oversight.

28
 LEADING IT

Empathy Map
WHEN YOU MIGHT USE THIS TIME

Empathy Maps help to rapidly put your team in the 30–60

user’s shoes and align on pains and gains—whether minutes
at the beginning of a project or mid-stream when you
need to re-focus on your user.

INSTRUCTIONS

1. Draw the map and its four quadrants: Says, Does, Thinks, and Feels.

2. Sketch your user in the center and give them a name and a bit of
description about who they are or what they do.

3. Diverge, with each team member writing one observation per sticky
note and applying it to the appropriate quadrant of the map.

4. Annotate unknowns (assumptions and questions) for later inquiry

or validation.

5. Discuss observations and fill in gaps collaboratively.

TAKE-BACK TIPS

Don’t go it alone. Empathy for users arises from sharing in the

collaborative making of the Empathy Map. Everyone knows something
about your user, so use the activity as a means to gather, socialize,
and synthesize that information together.

Involve your users. Share your Empathy Maps with your Sponsor
Users to validate or invalidate your observations and assumptions.
Better yet, invite them to co-create the artifact with your team.

Go beyond the job title. Rather than focusing on your user’s “job
title,” consider their actual tasks, motivations, goals, and obstacles.

30
 LEADING IT

Scenario Map (As-is / To-be)

WHEN YOU MIGHT USE THIS TIME

As-is Scenario Maps help to document collective 60–90

understanding of user workflows and are best minutes
used as precursors to exploring new ideas. To-be
Scenario Maps tell the story of a better experience
for your user.

INSTRUCTIONS

1. Draw four rows and label each: Phases, Doing, Thinking, and Feeling.

2. Fill in the phases, one per sticky note. Don’t worry about what the
“next phase” is; iterate through the scenario at increasing resolution
until you are comfortable with the level of detail.

3. In parallel, team members should begin annotating each column

with what the user is doing, thinking, and feeling.

4. Label unknowns (assumptions and questions) for later inquiry or

validation.

TAKE-BACK TIPS

It’s not about the interface. Rather than focusing on the user’s
pathway through a product’s user interface, pay close attention to the
job tasks they actually perform in order to accomplish their goals.

Warts and all. When creating the As-is Scenario Map, it’s important to
articulate your user’s actual current experience—don’t neglect tasks or
qualities that are not ideal or positive. Be honest and thorough.

Check your math. The solutions presented in a To-be Scenario Map

should ideally be correlated to the “pain points” identified in the As-is.

32
 LEADING IT

Big Idea Vignettes

WHEN YOU MIGHT USE THIS TIME

Once your team has a clear and validated 30–60

understanding of your user’s problems and minutes
challenges, this activity is a great way for many people
to rapidly brainstorm a breadth of possible ideas.

INSTRUCTIONS

1. On one sticky note, write a brief overview of an idea or solution. Try

labeling it with a one- or two-word headline.

2. On a second sticky note, sketch a visual depiction. Think of this as

a single frame of a storyboard—for example, a rough prototype of a
user interface or depiction of a user.

3. Diverge on many of these pairs of sticky notes (called “vignettes”)

and quickly share them with your teammates.

4. Cluster similar ideas and converge on a set that you would like to
take deeper using Scenario Maps or Storyboarding.

TAKE-BACK TIPS

Say yes to the mess. Avoid evaluating or dismissing ideas while you’re
generating them—dedicate a period of time to get everyone’s thoughts
onto the wall and only then begin to discuss what’s been shared.

Everyone has ideas. Don’t make the mistake of leaving idea generation
only to the designers, the engineers, the offering managers, or the
executives. Everyone has a unique perspective on the user and the
problem, so everyone should contribute ideas for solutions!

Stay out of the weeds. Evaluate which ideas are important and
feasible (using a Prioritization Grid) before deep-diving into the details.

34
 LEADING IT

Prioritization Grid
WHEN YOU MIGHT USE THIS TIME
When many items (such as ideas, Hills, scenarios, or 30–90
user stories) are being considered, this activity helps minutes
your team evaluate and prioritize them by focusing
discussions on importance and feasibility.

INSTRUCTIONS
1. Draw two axes: Importance to the user (low to high) and Feasibility
for us (difficult to easy).

2. Evaluate each item quickly and on your own—roughly plot them on

the grid where they make most sense.

3. Once many items are on the grid, begin to discuss with your
teammates and reposition them in relation to each other—do
certain ideas seem more important or less feasible than others?

4. Avoid spending too much time discussing items that fall into the
“unwise” zone unless you believe they have been mis-categorized.

TAKE-BACK TIPS

Importance is important. Avoid considering only what is feasible,

rather than what is feasible and what will have an important and
market-differentiating impact for the user.

Feasibility is more than the tech. In addition to the technical

perspective, feasibility also includes elements such as your
go-to-market strategy and your head-count capacity to deliver.

No-brainers are everywhere. Your competitors will also be focused

on the things that are highly important and feasible. (Why wouldn’t they?
They’re impactful and easy.) Instead, focus your discussion on making
“utilities” more impactful and on making “big bets” more feasible.

36
 LEADING IT

Needs Statements
WHEN YOU MIGHT USE THIS TIME

This is a very effective activity to use with your team 30–60

when you feel that you’re drifting away from the minutes
actual needs, desires, and goals of your user. It helps
reorient or reframe the work around your user.

INSTRUCTIONS

1. Write the statement: The user needs a way to do something that

addresses their need so that they benefit directly .

2. Focus on your user’s pain points—this helps get at what the

underlying problems are. More than one Needs Statement can
come from a single pain point.

3. Stay away from listing individual features. Instead, ask yourself,

“What does my user really seek? What does she really want?”

4. Cluster similar ideas and discuss.

TAKE-BACK TIPS

Über Needs Statements. After clustering several ideas together, try

writing one big (“über”) Needs Statement that represents the entire
group. Use the same “need/benefit” format.

People aren’t machines. If an idea is expressed in terms of the

machine (“dashboard,” “click,” “log in,” “export,” and so on), that’s a
clue it’s actually a feature. Re-cast the idea in human terms of what the
technology allows your user to accomplish.

38
 LEADING IT

Storyboarding
WHEN YOU MIGHT USE THIS TIME

Storyboarding is a way to iterate and communicate 20–60

ideas and scenarios visually by telling user-centric minutes
stories. If you’re having a difficult time just talking
about an idea, try some Storyboards.

INSTRUCTIONS

1. Imagine your scenario as a story with characters, a plot, conflict,

and resolution.

2. Place six sticky notes (“frames”) on a piece of paper. For each

frame, draw a quick sketch and annotate with a brief caption.

3. Make the story seamless with a beginning, middle, and end.

4. Share your stories and get feedback.

5. To converge, choose the best parts of each teammate’s story and

weave them into one refined “master” story that’s representative of
the entire team’s thinking.

TAKE-BACK TIPS

Comics aren’t just for kids. Try thinking of your storyboard like a
comic strip. Combine quick sketches with speech and thought bubbles,
action bursts, captions, and narration.

This isn’t wire-framing. Avoid drawing too many screens. Instead,

create a narrative that focuses on people and their actions, thoughts,
goals, emotions, and relationships.

Use Sharpies®. Using a pen or a sharp pencil makes it too easy to

include unnecessary high-fidelity details. Stay out of the weeds!

40
 LEADING IT

Assumptions and Questions

WHEN YOU MIGHT USE THIS TIME

Any time you feel that your team’s work needs a 30–90
“reality check,” use this activity to identify and minutes
prioritize what assumptions are being made, what
you’ve been guessing about, and what your team
still doesn’t know.

INSTRUCTIONS

1. Draw a two-by-two grid with High-risk on the top, Low-risk on the

bottom, Certain on the left, and Uncertain on the right.

2. Diverge, with each team member writing one assumption or

question per sticky note.

3. Evaluate each item quickly and on your own—roughly plot them on

the grid where they make most sense.

4. Once many items are on the grid, begin to discuss and reposition
them in relation to each other—how certain are you in knowing the
correct answer to the question, and how risky is it if you’re wrong?

5. Focus the discussion on the items in the upper-right quadrant.

These are the assumptions and questions that most urgently need
further validation and inquiry.

TAKE-BACK TIPS

Do this early and often. Risk will never disappear, but the sooner you
recognize and evaluate your team’s assumptions and questions, the
more quickly you can act to reduce the risk they pose.

Don’t hold back. Be honest about the questions you have and the
assumptions you’re making—even if you’re afraid of appearing naïve.
An unasked question will forever go unanswered.

42
 LEADING IT

Feedback Grid
WHEN YOU MIGHT USE THIS TIME

This activity helps to gather and organize any sort of 30–60

feedback and to then unpack questions and ideas— minutes
either in real time or after-the-fact—as an efficient
means of determining next steps.

INSTRUCTIONS

1. Draw the grid and its four quadrants: Things that worked, Things
to change, New ideas to try, and Questions we still have.

2. Fill in each quadrant with sticky notes. Be specific and give

constructive criticism.

3. Cluster similar ideas and discuss. Search for patterns and themes.

TAKE-BACK TIPS

The sooner, the better. Use the Feedback Grid to capture ideas in
real-time during a meeting or workshop. Or do the activity immediately
following a Playback or a cognitive walk-through with a user.

Take the next step. Once you’ve developed and discussed a

Feedback Grid, it’s time to take action: Use the “Questions we
still have” from the Feedback Grid to inform an Assumptions and
Questions activity. Use the “New ideas to try” to begin Storyboarding.
Or use the “Things to change” as the basis for a to-do list of action
items for different team members.

44
46
48
50
52
© 2015 IBM CORPORATION v3.1 0910
 Get the latest version

This field guide is updated frequently.

IBMers can download the latest version,
share with others, and leave feedback at
[Link]/idt_fieldguide

Field Guide Editor: Seth Johnson

Cover Illustration: Stephanie Hagadorn

© 2015 IBM CORPORATION v3.1 0910