Using a versatile design research technique, this presentation calls designers to give themselves permission to be flexible in their design practice by being the master of their techniques and get creative with the design process as much as they get creative with the experiences they design!

1. Bridging Reality
and Future
Vision with
Reality Maps
Malini Rao
Design leader & strategist
Acquia
Acquia

2. Are you ready to set your design practice free?
Image source: anxietybegone.com

3. Use your tools…

4. …creatively to serve your purpose!
Image source: Pinterest

5. It’s not about the tool!
• It is about stimulating
thinking
• It is about taking
inspiration
• It is about bending rules
• It’s about getting the job
done!
Image source: Wikipedia

6. Journey Maps - Main Differences
Phases in customer/user journey
Touchpoints
?
!
! ! !
Steps in a task to achieve a goal
Journey Map Reality Map
Communication Tool
Bird’s eye view of customer
path to identify broad design
opportunities
Collaboration Tool
Closer look at customer task
flows to tease out rich detail
and identify design
opportunities
?
?

7. Reality Mapping
Technique to help understand
and communicate how people
achieve their goals currently in
a step by step manner
Artifact constructed together
with a representative user
*Tamara Adlin and Holly Jameson Carr describe this technique in detail in
Chapter 10 of The Persona Lifecycle, Pruitt and Adlin, Morgan Kaufman, 2006
Current flow >

8. Reality Mapping
Uses different colored
stickies to separate task
steps from comments,
questions, and design ideas
*Tamara Adlin and Holly Jameson Carr describe this technique in detail in
Chapter 10 of The Persona Lifecycle, Pruitt and Adlin, Morgan Kaufman, 2006
!
! ! !
Current flow >
? ?
?

9. Artifacts that help you
understand and
communicate information
about the ways people could
achieve their goals
?
?
?
!
! ! !
Proposed flow >
Design Mapping
Steps in the
proposed flow
Questions about the
proposed flow
Comments from
stakeholders/team
Design ideas

10. Design process is iterative
…and continuous
Image source: uxcellence.com

11. Toolsets used in each phase of
the design process are siloed
Image source: anthropologizing.com; blog.centersource.com

12. Mix and match tools from
related or unrelated
phases in your process
or even disciplines
Image source: goanywherez.com

13. Case Study 1
Ready. Steady. Discover!
Image source: magic4walls.com

14. Taking a closer look!
• Product/ Tool: Metadata Repository Builder
• Main issue: Low adoption rate of product due to
difficulty in setup
Image source: careebear.com
Highly technical IT
administrator
persona

15. Taking a closer look!
? !
? !
Adapted method of constructing reality map due to lack of time to
construct it together with representative user
1. Interview
User
2. Break down into
Reality map on our own
3. Follow up questions and ideas
with user and Product team

16. Taking a closer look!
Create
Repository
Import
Metadata
Add
Users
Create
Projects
Setup process
in the tool
The setup process looked easy…
But it was not… as we discovered when we broke it down into a
reality map!

17. “This process is
really hard…
easier if you have
a repository
already”
Creating a Repository for development by group of developers
Assumptions: No existing repository; multiple developers
Treat metadata
objects separately
and store in DB
instead of an RPD
file
Group divides work
among developers
Divide by ERP
Apps – 1 project
per app – HR,
financials etc.
Some people work
on common
dimensions only
Are certain users
more ‘qualified’/
senior? What projs
(horiz/vertical) do
they usually work
on?
If the fact/bus.area
the unit that people
want?
Are there other
criteria to divide up
projs besides
common dimensions
and content fact
tables?
This is a non-trivial
task
Do the common
dimension developers
divide up which
dimensions they are
responsible for?
Group establishes
rules/conventions/
culture for working
together
Before using MUD,
people worked on
a time-share basis
Of DDS process
Provide Object
level permissions
Do people have
access to objects
they are not
supposed to
touch?
Clear ownership of
objects to minimize
confusion…
ownership on
paper
Create repository
Who builds rpd
before splitting up?
How much gets
done before
splitting into projs
on tool?
Create skeleton
physical layer
Who creates this
skeleton layer?
Import all content
into physical layer
and then sort?
Need for dummy
fact table
Usually imported
from source DBs
Create dummy fact
table
(bus.mod.layer)
Need dummy fact
table so that proj
can be defined and
people can check it
out
Does this dummy
project stay around
or get deleted?
Create dummy
project
Need something
that people can
check out… can't
create a proj
without a fact
Everyone checks
out the same proj
to add facts
Allows multiple
users to do initial
repos./buss. model
development
No way to create
something outside
of an existing proj
and then add it to
the repos. (like
clearcase)
Does anyone work
as an uber-admin
and work on the
repository without
checking out a
project?
Group members
check out dummy
project and add
real facts
Requires merge,
check-in
Do the common
people have to
create dimensions
first?
If I add fact to dummy
project, is that fact
automatically added
to project or user has
to remember to make
the association?
Does everything in
a repository have
to be in a project?
Does the tool
enforce?
People create
project subsets
because big
repository is slow
to work with
Create real
projects – get into
master repository
in MUD folder
somehow
Who creates the
real projects?
Does the tool
require uber-admin
responsibility/
access?
Done at “master”
level or locally of
checked out?
Progressively
added as some
facts are created
or all at once?
If I checkout
dummy project and
then create a new
project, do I check
in two then?
Feels like projects
should be made at
the uber admin
level
Who manages
access to the
projects?
Run scripts to
check in MUD
folder Repos into
Clearcase
Create MUD
Folder on a
network drive
Is this where the
MUD folder is
defined or
elsewhere in the
process?
When in the
process does this
happen?
Automatic nightly
process
Developers local
repositories are not
checked in
Log files checked
in automatically
nightly
Log file logs
everyone’s activity
-Who logged in
-Which machine
change initiated from
-Developer comments
Developer
comments are
mandatory but the
tool doesn’t
enforce it.
Run auto
regressio
suite nig
Bunch of 200
collected o
years to ma
the check-in
day are
Looks at
set… no
physical
2 repositories
compared – list of
changes emailed
to developers by
automated script
Lists all the objects
that have changed
-
Added, Modified,
deleted
Doesn’t tell which
fact table was
changed
No impact analysis
as part of this
script
This report is a few
hundred rows
Does it say which
table? Or only
columns?
Is this sent out as
an Excel sheet?
Developers have
to check to see
what the real
change is
Most conflict
resolution happens
outside the admin
tool
Email? Meeting?
How?
Automated scripts
refresh test
environment
Once per day
typically
Every 3 hours in
crunch time
Not the offi
environme
developme
Compares
a static
What is th
Production
saved resu
Start with a list of
Reqs from end -
user to report with
interested metrics
Create Functional
spec – translate
business metrics to
data sources, data
flow, table names –
info for data modeler
This feeds the blue
print for the
physical data
model
This may be done
as part of the
repository building
or as part of an
ETL process
Physical model blue
print - Identify and
optimize the source
systems for business
modeling and
reporting
Use OLTP/Excel
sources directly or
decide to build a
data mart first
Create Business
model blue print
Kimbal metric –
facts along column
and dimensions
across
Build a simplistic
logical star on
paper
IT responsibility –
Either by the same
person who created
the physical blue print
or a BI data modeler
but within IT
Used as a tool for
validation and
planning projects,
allocating work etc.
A project may be a
subset of a bus.
model or extend a
bus. Model (by
adding facts) or
contain more than
one business model
Data warehousing
model is forced in this
tool -forces star
schema – so fact is
the unit around which
everything is defined
Discoverer users –
not fact driven
For MUD, usually,
a proj = bus.model
You may split the
work but will get the
same objects – tool
allows ways to
resolve conflicts and
merge
This blue print is
essentially the
physical diagram
on paper
Is this a mandatory
step? If not, how
does project
definition get
planned??
Steps in the flow
( external)
Questions
Comments
Design ideas
Steps in the flow ( in
product)

18. Live artifact evolves over time - Greens and yellows transform into
pinks as you move into the design phase
Group
establishes rules/
conventions/
culture for
working together
“This process is
really hard…Easier
if you have a
repository already”
Clear ownership of
objects is recorded
on paper to clear
any confusion
Do people have
access to objects
they are not
supposed to touch?
Provide object level
permissions
Sample stickies
on the reality map

19. Case Study 2
Image source:dreamstime.com

20. Piecing a story together
• Product: Personalization tool
• Company: Acquia
• Main issue: Where should we
start to redesign the product
experience meaningfully?

21. Challenge Too many projects kicked off without enough info about users and how
they use the product and in what context
Image source:www1.aps.anl.gov

22. Challenge Too many projects kicked off without enough info about users and how
they use the product and in what context
Learning about the context of use can be a way to identify
meaningful feature expansions
Feature expansion Current product and customer experience Feature expansion
Improve
Goals for our meetup

23. Challenge Too many projects kicked off without enough info about users and how
they use the product and in what context
No time for contextual enquiry? Then, piece together
knowledge that is fragmented in secondary sources/
stakeholders
Individual experience Customer experience (second hand) Individual experience

24. Challenge Keeping user’s needs and behaviors as an overarching influencer of the
project is always a challenge
Focusing on the big picture and still grasping details is hard!

25. Challenge Keeping user’s needs and behaviors as an overarching influencer of the
project is always a challenge
Anchor insights about the user at a contextual level with
Reality mapping
• Tag comments as
pain points to serve
as reference for
usability test scripts
• Identify gaps to
pursue in your
research

26. Challenge Keeping user’s needs and behaviors as an overarching influencer of the
project is always a challenge
Mapping personas to tasks identifies who to design for
and where collaboration and hand offs occur

27. Challenge Collecting data is hard but analyzing it is harder… and very time
consuming
Image source:www.normalight.com

28. Challenge Collecting data is hard but analyzing it is harder… and very time
consuming
Reality Mapping is an efficient, collaborative technique that
surfaces big picture insights via visual analysis
Feature expansion Current product and customer experience Feature expansion
Improve
Great way to collaborative on hard
& interesting design problems -
individual ideas in a cluster can
bubble to be a design
breakthrough

29. Challenge Collecting data is hard but analyzing it is harder… and very time
consuming
Feature expansion Current product and customer experience Feature expansion
Improve
In this state of the reality map, we had clearly spent more time
thinking about feature expansion than product improvement
Collaborate on design problems but also assess the state of
your analysis

30. Challenge Collecting data is hard but analyzing it is harder… and very time
consuming
With the entire workflow visible, it is easier to identify
phases and flows to break down a complex process

31. Image source:www.fmsi.com
UX can drive & influence product road-
mapping & strategy

32. Collaborative reality mapping allows teams to identify themes
across the workflow that can translate as initiatives and
stories in a product road map
Current Reality
Bridging Reality and Future Vision with
Reality Maps
Future Vision
Robust preview
Goals Funnel

33. What we learned…
A collaborative research and
analysis technique you can use
right away
? !

34. An effective way to distill research
and reach consensus
What we learned…
A collaborative research and analysis technique you can
use right away

35. To be flexible in adapting the
technique to get the job done
An effective way to distill research and reach consensus
What we learned…
A collaborative research and analysis technique you can
use right away

36. Get Creative!
malini.rao@acquia.com
twitter: @malinitweets
#ias15 #realitymap
Rate my talk: http://spkr8.com/t/53861
Be the master of your techniques!