THE $1 PROTOTYPE

A Modern Approach to
Mobile UX Design
and Rapid Innovation
for Material Design,
iOS8,
and RWD

By Greg Nudelman
DesignCaffeine Publications
San Francisco, California
Copyright 2014 by
Greg Nudelman
Kindle Version 1.1

Table of Contents
Beginning
1. What is the $1 Prototype Mobile Design Methodology?
Case Study: Be a Hero!
2. How is the material in this book organized?
3. What do I need to get started with $1 Prototype methodology?
PART 1 ~ ENVISION
4. What do I need to draw in my storyboard?
5. How do I craft my storyboard? What tips do you have for making it interesting and effective?
6. Im stuck. Where do I start?
7. You encourage us to just storyboard our assumptions. Isnt it better to do some research first?
8. Why do you insist on using small square sticky notes for storyboards?
9. I got my storyboard. Now what?
Case Study: Mood Ring to MyStuff
PART 2 ~ PROTOTYPE
10. What should I strive for when designing my mobile experience?
11. Where do I start my mobile design?
Side Panel: List of Links Pattern
12. Are we really able to model a mobile experience effectively with a pack of sticky notes?
Case Study: Commute Assist
13. Can you give an example of an app re-design done using sticky note wireframes?
14. How do I design for Android Material Design?
Side Panel: Do I need a FAB (Floating Action Button)?
15. How do I design for iOS8?
16. How do I use $1 Prototype to design Responsive Websites?
PART 3 ~ TEST
17. Are you saying dont do any usability testing?
18. When and where should I do my usability testing?
Case Study: Go Fetch!
19. What are the best practices for testing using sticky note wireframes?
20. How do I ask non-leading questions?
21. How do I test Google Material Design Transitions?
22. What if I already have a product implemented? Can I still use sticky note prototypes for testing?
PART 4 ~ COLLABORATE
23. We use Agile development process. Do we still need the $1 Prototype methodology?
24. What do you mean replace the kick-off meeting with a kick-off design workshop? Is this just a
fancy name?
25. Are you saying everyone should be a designer? I dont like that. Sounds like chaos.
26. What makes storyboards so special for mobile? What about using Personas instead?
27. I still dont understand why we need storyboards. I think the list of requirements ought to be

enough for anyone.

28. My team cant agree on our first design.
29. Whats the best way to integrate $1 Prototype methodology into Agile Scrum?
30. What kind of graphics software do you use in your design work?
31. My developers are demanding only high-definition wireframes and refuse to look at my sticky
notes. What do I do?
One Last Thing

Greg Nudelman is a Mobile and Tablet Experience Strategist, Fortune 500 Advisor, Author/Speaker
and CEO of DesignCaffeine, Inc. For over 15 years he has helped his clients, Intuit, Oracle, Cisco,
eBay, USAA, Wells Fargo, Safeway, Associated Press, Groupon (and many others), get multiple
featured apps and amass millions of satisfied customers. Internationally acclaimed design workshop
leader and accredited graduate course instructor, Greg has taught at over 50 workshops, events, and
university classes in 10 countries, and authored four books on mobile UX design. Greg lives in the
San Francisco Bay Area.
Also by Greg Nudelman:
Android Design Patterns: Interaction Design Solutions for Developers (Wiley 2013)
Padres de Projeto para o Android Solues de Projetos de Interao para Desenvolvedores
(Novatec, 2013)
The Mobile Book (Smashing Media AG, 2013)
Designing Search: UX Strategies for eCommerce Success (Wiley, 2011)
Author Online!
For 50+ design articles, free design courses, updates, and more visit: www.DesignCaffeine.com

Copy Editor: Jim Driggers http://writingjim.com

Technical Editor: Cesar Brod http://brodtec.com
Video Producer: Lawrence Hannigan http://bit.ly/1dplarry
Art Consultant: Will Krause http://willkrause.com

Beginning
Your work should empower and inspire. Thats how important it is.
Sketching is the life-blood of any design process. I did a lot of visual thinking in my Moleskine
notebook and when I started doing mobile design, my approach was much the same. Proudly, I
labored behind closed doors, producing many sketches like these, which made me feel very
designery:

One day, I had to rush out the door to a client meeting and left my Moleskine behind. At the
meeting, I needed to quickly think with my pen to design a mobile screen, so I grabbed the first
available piece of paper lying on the table: a pack of sticky notes. I was trying to be as quick as I
can, so I drew the bare minimumjust the page layout and controls. Imagine my astonishment, when
the companys CEO (normally a reserved and dignified personconsummate professional, whom I
greatly respect) suddenly jumped up and, seizing my pack of sticky notes in his hand, started
vigorously gesticulating and tapping my hand-drawn buttons with his thumb, saying See! This is
EXACTLY what I mean!:

Eureka!
I never imagined that an $800 iPhone, the pinnacle of human achievement, the technological miracle
of the 21st century . . . could be exceedingly well approximated by a $1 pack of sticky notes coupled
with an active imagination!
Since that memorable meeting, I had the privilege to speak at length with Steve Krug, the author of
Dont Make Me Think (http://bit.ly/1dpdmmt3), who was very receptive to my ideas and encouraged
me to explore the concept further. Mr. Krugs interest in the early versions of my sticky note
prototypes and his encouragement five years ago eventually led to the book you hold in your hands.
For the last five years Ive had the privilege to present and teach at more than 50 events,
workshops, and university courses in 10 countries. Throughout this time, my initial lightweight mobile
design technique has been challenged and improved through many enthusiastic experiments and
insightful questions from the participants, as well as some intensive client work, which resulted in
multiple featured apps in both Apple App Store and Android Play Store. This book is the result of
those workshops and design sessions, so I want to thank the thousands of people that came to my
eventsIve learned as much, if not more, from those sessions as those that have attended them. In
particular, I want to thank the students of my San Francisco State University Agile Mobile UX Design
Certificate Course, who graciously consented to have their work featured as part of this book:
Will Krause
Adam Beu
Anastasia Walia

 Talya Carrie
Frances Liddell
Valerie Lord
Ken Bousquet
Kate Chadd
Darrin Jones
Leslie Keats
Patricia Larsen
Jacob Madsen
Deepti Mande
Katherine Sawyer
Monica Zendig
Theyre the best collaborators anyone can hope to have, and Im proud of what they accomplished
in just three short weeks of class!
I also want to thank my sponsors who pre-ordered the book on Publishizer:
Vitaly Polekhin
Guy Vincent
Aaron Vargas
Bob Royce
Louis Rouffineau
Tom Belunis
Andrew Lawton
Anastasia Walia
Andrew Sandler
Anthony Hand
Chris Noessel
Dan Keldsen
David Hunkins
Eric Henderson
Their generous financial support improved everything that is good about the quality of the book:
editing, art and video production, and indeed made this book possible. Any and all mistakes are my
own.

My three previous books were more concerned with the What of design, such as design patterns and
pitfalls:

In contrast, the book you hold in your hands is much more about the How. Instead of providing
design patterns, this book combines the best of modern mobile usability techniques with Agile
development lifecycle and Lean business practices. This combined methodology creates a practical,
no-nonsense lightweight UX design methodology I call The $1 Prototype.
This methodology can be used to quickly envision and design any mobile or tablet product or
service: from native and hybrid mobile and tablet apps to responsive and mobile-optimized websites.
CEOs, mCommerce Directors and Product Managers as well as UX Professionals of all kinds should
find the book both useful and practical.
Another essential difference from my previous work, is how this book is organized. I decided to
use the Question and Answer format throughout the book to create the feel of doing the design process
as a workshop as well as to keep the book concise and practical. My goal is to enable you to finish
this book on the flight from SFO to JFK and get off the plane full of new strategic ideas and
techniques you can put to work even before jet lag wears off. The Q&A format should also help you
easily revisit any topics you need at a later time.
Rather than try to convince you that UX design is valuable, I simply assume you already know this.
And if at times I speak forcefully, it is to cut through layers of accumulated misunderstandings around
UX and to help you get back to the core of whats really important: empowering and inspiring your
customers, while making a good living for you (and profit for your companys shareholders.)
If youre currently a UX practitioner, this book will give you modern techniques to apply UX
principles with renewed vigor, efficiency and confidence. If youre new to UX design, this book will
give you complete, practical, mobile design processes that will immediately benefit you and your
team. This book does not aim to present anything particularly Earth-shattering. Instead its a restating
of the original UX principles for our modern, mobile agea rapid, lightweight, and resilient
application of simple but profound techniques that really work in the real world.

For updates to this book, design patterns, articles and free design courses, please visit my companys
website at
www.DesignCaffeine.com
While there, be sure to sign up for my newsletter, Mobile and Tablet Design Secrets, so youll
know when I have anything new, including UX strategy articles, design patterns and revisions of this
book (http://bit.ly/1dpsecrets). At DesignCaffeine, Inc., were a full-service boutique design and
mobile consulting company, providing everything from private training workshops for your team to

UX design and mobile development that will help you get featured in the Apple App Store and
Android Play Store. So if you need additional training, or any help implementing the ideas in this
book, dont hesitate to drop us a line.

One last thing: beyond techniques and methodology, design is a highly spiritual discipline. In my own
practice, Ive found Zen Buddhist awareness techniques to be very helpful in everything from product
visioning to usability testing. These techniques have helped me recognize the spark of divinity in
everyone, keep my focus on awareness of other peoples needs, and off my own ego gratification. So
in some tiny measure, this book is also a spiritual guide to experience design. I hope it will help you
adopt the right attitude from the start: do your best, and then let go. Otherwise, mobile design will just
make you crazy. Take it from one who has learned the hard way.

1. What is the $1 Prototype Mobile Design Methodology?

The $1 (One Dollar) Prototype methodology is a lean, lightweight mobile design methodology that
can be successfully plugged into any existing software development and design process, from
Waterfall to Agile. The $1 Prototype methodology consists of four activities: Envision, Prototype,
Test, and Collaborate working together as a continuous iterative loop. The name One Dollar comes
from the low cost of materials requiredthe basic process uses just two packs of sticky notes, at the
cost of you guessed itabout $1.
The name One Dollar also refers to brutally efficient use of time. I once had a four-hour
workshop at a large enterprise client, where we used the $1 Prototype methodology to kick-off the
digital strategy for Responsive Web Design (RWD) of their marketing site of over 50,000 pages. At
the workshop, the client team ran through one full cycle of the $1 Prototype methodology with several
user stories, creating a solid foundation for success of the project. This workshop proved that using
the $1 Prototype approach could leverage even a few hours of your teams dedicated time to improve
the design and digital strategy and provide incredibly high ROI.
If the $1 Prototype methodology were simply about cutting costs, I would consider it a failure.
Instead, cost cutting is but a fringe benefit of this methodology. The primary benefit is its laser-focus
on the customer, with rapid investigation and modeling of the goals, activities, and tasks. Instead of
being focused on deliverables (that is on producing expensive, time-consuming and flashy wireframes
and prototypes) the product team is focused on most efficient ways of finding the opportunity to help
potential customers, producing a working prototype solution and validating this solution with real
people.
The central philosophy of the $1 Prototype methodology is that the state of completion of the
system must be reflected in the state of the prototype. An expensive high-definition prototype isnt
built for most mobile projects, because the level of uncertainty is too high to make such a major
commitment. The benefits of building such a prototype are low compared to the costs in time and
money required to build it. Instead, lean, low-fidelity sticky note prototypes are used to explore
several design solutions quickly, so the Agile team can move forward rapidly and innovate with
confidence. By sticking to this methodology, we do the exact thing we need to move the project
forward and avoid doing and maintaining unnecessary expensive work. To quote Milton Glasers
seminal essay, Ten Things I Have Learned, Just enough is more. (http://bit.ly/1dpmilton).
State of your prototype must reflect the state of completion of your system. This simple
guideline is also very profound. The degree of certainty in your design should be reflected in the level
of completion of your prototype. The project starts with a rough storyboard which is highly uncertain
and full of assumptions: no one knows if the audience will find the product useful, if they will pay for
it, or even if the product can (or should) be built. As the design and development progress, the
prototype becomes the pack of sticky notes with specific workflows, layouts and on-screen controls.
As the confidence in the design grows still further and more questions are answered, the product
coding begins. Both Alpha and Beta releases become the prototype until finally the confidence level
reaches a local maximum and the product is released. At this point the cycle of improvement starts
again.
In essence, the $1 Prototype is about institutionalizing failurein its cheapest and most expedient
form. The faster the product team fails, the faster it gets back on track and addresses solving the
customers challenge with realistic, functional solutions. The sooner we get to the experimental stage,

the more innovative and functional the solution will be, and the less any team or management egos
will be able to influence the product direction. The $1 Prototype approach will help you escape
endless arguments and three-hour meetings in favor of rapid, inexpensive, open-air experimentation
focused on solving real problemsthe perfect marriage of mobile UX design and Lean Startup
methodology (http://bit.ly/1dpleans). The following case study of Be a Hero! app demonstrates the
$1 Prototype process in action.

Be a Hero!
Be a Hero! is an app designed by students in my Advanced Mobile UX course at San Francisco State
University using the $1 Prototype methodology. The app allows people (Heroes) to help victims of a
disaster (Survivors) anywhere in the world by quickly donating funds, blankets, medical supplies,
etc.
The design process began by identifying a typical use case of a Hero with a collaborative
storyboarding exercise. The team envisioned the following scenario: A Hero wants to help the
typhoon relief effort by sending funds to the charity of their choice. Here is the final version of the
teams storyboard:

After the team approved the storyboard, they converted it into sticky note wireframes. This is the

final version of the sticky notes prototype:

Sticky note wireframes serve a dual purpose: they help document various design approaches, and

they serve as a ready prototype that can be immediately tested with real people to find out which
design approaches work best. Because wireframes are sketched in pencil, they can be changed
quickly and easily right in the field if the team discovers any issues during the testing. This method is
known as Rapid Iterative Testing and Evaluation (RITE).
Before the team arrived at the final design above, they tested multiple versions of the homepage.
For example, this early version of the map design pattern showed too much information and obscured
the map. Also, seeing more than one open pin confused the participants because the items in the list
looked like notifications, instead of multiple open pins:

Older versions of the homepage explored various other design directions: a carousel of calls to
action, a map carousel overlay, and a list of charities:

Prototyping design ideas with sticky notes allowed the team to explore various design approaches
and quickly iterate on the most promising design: the world map with pins, showing the detail of the
most recent disaster. Here it is again:

Finally, the team created the logo and visual assets using Photoshop and put together highdefinition wireframes (complete with colors and visual design) using Adobe Fireworks:

Through collaboration, the team completed the entire design process: vision, prototype, testing,

and final visual design in just three weeks.

2. How is the material in this book organized?

To help you get the most out of $1 Prototype methodology, the material in this book is organized along
the four main project activities:
1) Envision: in this part of the book I show you how to create and document your product vision
using comic storyboards drawn on a set of square 3x3 inch sticky notes. I explain how to draw
creative details and provide tips for effective storytelling.
2) Prototype: in this part I explain how to create your $1 mobile prototype using a pack of 3x5
sticky notes. I address the practical details of sketching paper wireframes to create Material Design,
iOS8 and RWD components such as wireframes, layers, menus, popup dialogs, keyboards, and other
moving parts.
3) Test: in this part I explain how to quickly and cheaply test your $1 Prototype using guerrilla
testing strategies in your local coffee shop. I also explain how to ask non-leading questions, so get the
most out of RITE methodology.
4) Collaborate: in this part I discuss how the $1 Prototype methodology can be used to
immediately enhance and complement the Lean Agile development process, and how to address
various organizational challenges. In this section I also handle the most common questions and help
you avoid critical pitfalls when working together.
Throughout the book, youll see the four parts of the $1 Prototype methodology referred to as a
journey through four sticky notes, like this:

Essential Case Studies

Throughout the text youll see case studies from my San Francisco State University course on mobile
UX design. These case studies demonstrate practical application of the material in the book and will
help you apply the $1 Prototype methodology in your own organization.
Live Action Video
Various hands-on aspects of the $1 Prototype methodology are shown in multiple live action videos.
These demonstrate in detail all essential aspects of the $1 Prototype methodology: storyboard
walkthrough, prototype review, usability testing and asking on-leading questions. All of the videos
are included in the $1 Prototype Play List on YouTube, accessible here: http://bit.ly/1dppl1.
Dont Skimp on your Vision
If youre like most people, you may be tempted to skip Envision (Part 1) altogetherdont! Although
vision storyboarding seems trivial, doing the activity has magic all its own. Just 30 minutes invested
into honing and documenting your vision will put you in the right frame of mind for your design
project to succeed. Even as I write this, I am at the end of a project where (at the request of the client)

we skipped the vision storyboarding step and as a result, ended up having to go back and implement
several rounds of expensive and time-consuming fixes. Time and again, when the team just jumps
straight into design without taking the time to storyboard the use cases first, I witness failed projects
and missed opportunities. Dont skimp on your visionthe success of your project depends on it!
A Working Process Reference
I laid out the book in a natural order of implementing $1 Prototype methodology, so I recommend you
give the entire book a quick scan (its short). I also took tremendous pains to make this book a
working reference, so that each question provides immediate benefit. If youre interested in a specific
topic, dive right in! Just be sure to go back and review the portions you skippedall four parts of the
$1 Prototype methodology have to work together to ensure success.

3. What do I need to get started with $1 Prototype methodology?

Getting started with the $1 Prototype methodology is easy. All youll need are two packs of sticky
notes, a pencil and a mobile device running the platform youre designing for.
1) Two Packs of Sticky Notes
To get going youll need only the most humble of supplies: 3x3 inch square sticky notes for your
vision storyboard and 3x5 inch rectangular sticky notes for the full-size mobile prototype. These
should be unlined and of the lightest possible color. If youre going to also model larger (or smaller)
touch devices youll need appropriately sized sticky notes to handle those device sizes.
Fortunately 3M, Highland, and other paper-supply firms make sticky notes in a great variety of
sizes. That makes it easy to accurately approximate anything from a smart watch to a full-size nine- or
ten-inch tablet, and you should have few problems ordering these other sizes from an office supplies
store or from Amazon.com. I tend to use Highland Self Stick Notes purchased in bulk in packs of 18
and 24 from Amazon.com (http://bit.ly/1dpstickies), but you can use any brand you like. Highland
stickies tend to be cheaper and lighter in color than the popular 3M Post It brand notes, so I prefer
them for this reason. I recommend starting with just two sizes: the 3x3 and the 3x5 inch stickies and
building up from there.
2) Pencil
Youll also need something to write with. In my books I tend to use archival pens, as shown below, to
ensure that the lines show up well when scanned as images in the book:

However using a pen typically represents too much commitment for most real-life work, so I find a
simple, fine-point mechanical pencil is usually more than adequate. I use a Pilot G-2 mechanical
pencils 0.5 and 0.7mm with soft HB graphite leads (second from the left) because theyre tough yet
comfortableI have yet to have one fail on me and I own ten of them (http://bit.ly/1dppencil). I also
like how this model of pencil allows me to see how many leads I have left and has the attached eraser
that is well mounted and of good quality. You can of course use any brand of pencil you prefer, as
long as you can get a bright fine line that you can erase easily (and arent tempted to chew it... thats
just gross). Graphite pencil allows quick fixes and changes on the fly between participants and makes
it easy to add detail to the prototype, as you gain more information about the problem (see sidebar).
The state of your prototype must reflect the state of completion of your system. If you

write something in a permanent pen, youre in essence committing to re-drawing the entire sticky note
wireframe screen if you are wrong. For most purposes, that is just way too much commitment,
especially given the benefit of using a pen vs. a pencil is normally very slight. (Rememberthe $1
Prototype methodology is about doing what works with minimum effort!) Yet there is another benefit
to using a sketchy prototype: it helps make regular people who evaluate your design more
comfortable in making comments and suggesting drastic changes. In essence, it makes your evaluators
co-owners of the product and your design a co-creative process, allowing you to iterate rapidly and
with a high degree of confidence.
3) Mobile Device
In addition to the two kinds of sticky notes and a pencil, youll also have to get on the right mobile
platform. To make rapid progress in mobile design, be it Android, iOS, Windows or something else,
things will go faster and easier if you have a personal device that runs the exact platform youre
designing for.

While this advice seems rather obvious, youll be surprised how many people ignore it. Dont be
one of these people! Even if youre on a tight budget, you can get an inexpensive new Nexus Android
tablet or a slightly less budget-minded iPad Mini. In a pinch, a mere $100 will get you a pre-owned
Android or iOS phone on eBay that you can use with only Wi-Fi if you want to avoid purchasing a
cellular plan. This device will do everything a regular phone does, except make phone calls, making
it more than adequate for most prototyping needs. Before you make an investment, however, be sure to
visit a mobile carrier store (Sprint, AT&T, Verizon in the U.S., Vivo, Claro, Telecom Italia in Brazil,
etc.). At the store you can play with various devices, as well as get up-to-date information on
compatibility of a particular device to the upcoming releases of the operating system of your choice.
Android will be particularly tricky, due to how many customizations leading manufacturers like
Samsung and HTC seem to put on their devices. Given the choice, when designing for Android, I
recommend getting the latest device that runs pure Androidthe un-adulterated version of the core
Android operating system. As of this writing, my choice for modeling Android is the Nexus 5 mobile
phone from LG (http://bit.ly/1dpnexus5) running Android L. Having a pure Android phone
endorsed by Google (as opposed to one made by Samsung or HTC, for example) will help you see
the design patterns in the native applications like Gmail, Contacts and Calendar, exactly as Google
intended them to appear. You will be able to make sense of the patterns faster and that will make it

easier for you to use them in your own wireframes. As the Android ecosystem evolves, what you use
as the reference phone will changeknow your options and make informed decisions driven by the
needs of your audience.

Part 1
Envision
Now that you got your supplies taken care of, lets dive into the meat of the bookthe four core
activities of the $1 Prototype methodology: Envision, Prototype, Test and Collaborate. Here in Part
1 we review how to create simple and effective storyboards on a set of square 3x3 inch sticky notes.
These storyboards document the requirements, create incredible team alignment and provide the
essential use cases for designing your mobile app or website.

4. What do I need to draw in my storyboard?

Most UX storyboards are pretty straightforward. They broadly involve four types of objects: things,
people, facial expressions and establishing shots (landscapes). In this section Ill show you how to
draw all of these step-by-step. If youre already familiar with drawing storyboards, this section
should provide a quick review and a warm-up exercise.
1) Drawing Things
Many people (myself included) can draw common objects like cell phones and laptops with ease, but
have a bit more trouble with drawing people. If thats the case with you, I have some good news:
accurate drawing of things is more important to creating story realism than accurate drawings of
people. To borrow a line from Scott McClouds Making Comics (http://bit.ly/1dpmakingcomics), its
more important to be able to tell your phone from your tablet than to tell your Mark Twain from your
Albert Einstein.
Objects help add realism and understanding to the simplest of stick-figure drawings. And
understanding and alignment within your team is your key objective. No matter how basic the
drawing, if your team is aligned around a common vision as a result of the storyboarding exercise,
you have achieved your goal. Fantastic!
To give you some inspiration, below are some common, everyday objects drawn using nothing but
basic shapes like ellipses and boxes:

Warm up your drawing skills by taking a stab at a few of these drawings on your own or with your
team. I know this looks super-easy. Thats the point! That is, the point is to drawto actually DO a
drawing yourselfnot to sit there and analyze my dorky drawings. As I often say in my workshops,
Im not much of an artist, but I enjoy drawing and tossing visual ideas around. In my experience, most
readers can produce drawings as good as or better than minewhich makes me the perfect person to
teach basic storyboarding. Rather than treating drawings in this section as something to aspire to,
use them as something to beat. And that is exactly the heart of my super-sneaky, design ninjitsuto
get you to draw stuff and storyboard your ideas. So before you go on reading this text, go ahead and
put your mechanical pencil to that 3x3 inch sticky note and draw something. Seriously. Im not even
kidding. Go ahead and draw, Ill wait.

Got your first drawing? Great. If not...

Lets get one thing straight: if the $1 Prototype technique is to work for you, you (and
everyone on your team) have to do the work yourself. There is not that much work actually, but there
is no way to outsource it, any more than outsourcing your morning coffee or your vacation to
Bahamas. The $1 Prototype methodology works (I have thousands of peoples success to rely on) but
it will only work for you if you actually do the work. Of course, if you truly decide not to draw or not
to do other activities I mention in the book, such as user testing, its totally your choice. We are
consenting adults, and I cant make you do anything, really. Just know, that if you choose to skip some
of the work, your mileage, as they say, may differ. Thats all. Ill get off my soapbox now and return
you to your scheduled drawing activity.
Note that when drawing devices in your storyboard, it is best to draw only a corner of the device,
and at most include only a button or two, not the full interface! I call this my three-button maximum
ruleit simply means that a given sticky note should show no more than three total user interface
elements (otherwise youre designing and not visioning). That is why I am so insistent that you use
3x3 inch sticky notes for storyboarding. The small square shape serves to gently discourage giving
too much detail to objects and drawing out full interfacesthis is another small but powerful Jedi
Mind Trick to maintain proper prototype hygiene: separation between the What and the How,
between Vision and Implementation.
If you simply must note down your UI design idea before its fantastic awesomeness gets away from
you, go ahead and take a minute to do so on a 3x5 inch sticky note, then set it aside. Now, return to
drawing your storyboard using 3x3 inch sticky notes. It bears repeating: separating your work into
two different sets of sticky note shapes helps you keep the vision and implementation separate,
thus freeing your mind to brainstorm unique and interesting UI implementations of your vision.
Remember, in phase one, were focused on telling the story and expressing the product visionthe
design and prototype phase will come after the vision is complete. (See Question #8: Why do you
insist on using small square sticky notes for storyboards?).
2) Drawing People
Now that you drew some inanimate objects, its time to try your hand at drawing a person. The good
news is that, although drawing people is a little harder than drawing things, you dont have to be
nearly as accurate. This is because human beings are hard-wired from birth to recognize faces and
humanoid shapes and assign them meaning pre-cognitively (that is before conscious rational thought).
For visual communicators, this is fantastic news: even a simple stick figure drawing will resemble a
human and communicate volumes to the viewers.
Our minds automatically look everywhere for patterns that resemble faces and people and try to
understand their moods and intentions. This pattern recognition is a useful survival trait, and
underscores the importance of cooperation among early humans in order to avoid predators and
obtain food. (More on pattern recognition and its effect on prehistoric human social behavior can be
found in one of my all-time favorite books, Sex at Dawn by Christopher Ryan, Ph.D., and Cacilda
Jeth, MD. You can get the book on Amazon.com at http://bit.ly/1dpsx or if you want a free version of
the book, just Google sex at dawn PDF.)
Were the only species in the universe (that we know of) that creates art drawings of ourselves. We
have a rich history of drawing figures that represent ourselves and our surrounding flora and fauna,

and todays stick figures arent really that different from those we drew hundreds of thousands of
years ago. I use three types of basic figure drawings: Stick, Box, and Star. While you may be familiar
with the first two from cave drawings (and kindergarten), the Star is a newer form of quick drawing
used by many sketchnoters. Star is meant to be easy to draw with large sweeping movements on a
full-size poster or whiteboard, but it works just as well on a small sticky note. Heres what these
three basic types look like:

As you can see, theyre all pretty straightforwardgo ahead and try them now (for extra credit,
instead of The Hustle, make the figure do all the YMCA dance moves, http://bit.ly/1dpdance). All
three drawings take about the same amount of time to draw, so which one you use is totally up to you.
Just pick the one youre most comfortable with and go from there. If you want to improve your
drawing technique to make your stick figures look more like real people, pick up a copy of See What
I Mean by Kevin Cheng (http://bit.ly/1dpsee) or Making Comics by Scott McCloud
(http://bit.ly/1dpmakingcomics).
3) Drawing Faces
You might have noticed that none of the drawings above have facesthis was necessary to break the
figure drawing down into two parts to make it easier for the reluctant artists among you (you know
who you are). This was another part of my super-secret ninjitsu mind control technique to get you to
put pencil to paper (I hope it worked). So if you are with me so far, the third aspect of creating the
storyboard is drawing facial expressions.
The facial expression recognition engine of most humans is, if anything, even more sophisticated
than figure recognition. Just drawing two dots and a line allows people to see a face with multiple
facial expressions, especially if it is put inside a circle (or feel free to arrange two dollops of sugarfree organic Greek yoghurt and a piece of free-range turkey bacon on your gluten-free pancake
instead). Add eyebrows, and were really cooking with gasoline! Here are a few expressions for you
to practice, from Kevin Chengs book See What I Mean (http://bit.ly/1dpsee):

While most humans are somewhat reserved with their emotions, comics, as an art form, has a rich
history of overemphasizing the emotional state of the person in the drawing. If the person is happy,
they are really happy and you can see that in their face as well as their posture. If your drawing skills
allow this, use the shape of the figure or body language to underscore and nuance facial
expressions. This will add realism to your drawings and help you tell the story in closer alignment
with the traditions of the comics medium.
4) Drawing Establishing Shots
The last piece of the puzzle is drawing what is known as the establishing shot. This is often easier

than it sounds because many of the mobile vision storyboards start in a city: on the street corner, on a
metro, inside an office building. Since youre dealing with inanimate objects, you can use some of the
same basic shapes and simple techniques we reviewed in Drawing Things section above.
Its important to remember to zoom far enough out to establish the opening shot of the story. Not
zooming out far enough to fully establish the sense of place is the number one mistake I see students at
my workshops. If you zoomed out your opening shot correctly, you should be able to omit people from
the picture entirely or represent them as simple sticks or dots. I explain this in detail in the next
section, but it bears repeating again: always start your storyboard with the question where are you?
The establishing shot, when set up correctly, should provide an obvious answer to that question.
When planning your establishing shot, think of the first few seconds of a blockbuster movie. Is the
camera filming high above the city from a fast moving helicopter, at mid-day, while the fast techno
music is playing? Chances are this will be high-tech, sci-fi thriller or a modern shoot-em-up. Do you
see tiny tables outside a small cafe in the evening, while your ears are assaulted by accordion music?
Romantic comedy. (Run away! Run away!) Does the opening shot show a dilapidated but clean
suburban kitchen? Then likely well be cooking ourselves up at least a little drama. (Drama is always
happening in the kitchen. There is a Zen truth in there. Somewhere.)
The more you can set up the atmosphere and provide the setting for the story in the establishing
shot, the less you have to work at it in the remainder of your storyboard. With the atmosphere and
setting fully established, you can concentrate on scene-to-scene and action-to-action transitions (more
on this in the next section). Naturally this means spending a bit more time on that establishing shot,
often providing little extra details like windows, doors, awnings, cars, stop signs, etc. Believe me,
the effort is worth it. Plus, rememberif you follow my advice and make each shot a 3x3 inch
sticky note, youll be able to reuse the opening scene many times over in different scenarios. Here are
some examples of simple establishing shots to get you started:

Note that in addition to adding a depth to some of the buildings, some drawings have multiple
layersthat is, the lines that are further away have a washed-out, hazy look. Together with the
depth, this helps your landscapes look more realistic and make it easier for the readers to lose
themselves in your story. So take your time!
Save your chicken scratches. As you work through the methodology in this book, youll be
making rapid progress. Dont worry if your first storyboards and wireframes are simplistic and
crude! Above all, dont get discouraged. The more you work through the exercises, the more youll
improve. To give yourself a measure of confidence and courage, save your early drawings and put
them aside to compare with the work youll produce just a few short weeks later. Apply the
techniques in this book, and I personally guarantee that your progress will be something youll be
proud of!

5. How do I craft my storyboard? What tips do you have for making it interesting and effective?
Storyboarding is easy (all you have to do is cast yourself back to 3rd-grade mindset and relax). The
pointers below should help you become effective quickly while avoiding most common pitfalls.
Based on the experience of thousands of people who took my classes and workshops, I can
confidently state that most people do not need any additional skills beyond what I cover in this book
to communicate their ideas effectively and derive immediate benefit from using this powerful UX
technique.
However (and this is as true with much of UX) while its easy to get started with storyboarding, it
takes a lifetime to master. If you want to continue growing your drawing skills beyond the 3rd grade
level and perform a more thorough study of the subject of UX storyboards, I recommend two excellent
books: of See What I Mean by Kevin Cheng (http://bit.ly/1dpsee) and Making Comics by Scott
McCloud (http://bit.ly/1dpmakingcomics) Note: small excerpts from both books are presented in the
side bars with permission of the author/publisher. Be sure to also review the various case studies in
this book carefullythey will help you understand the nuances of the storyboarding technique and
how it serves the next two steps: prototyping and testing.
Below is an excellent storyboard that demonstrates a common use case for the Square app from the
book See What I Mean by Kevin Cheng:

If youre not familiar with Square, its an app that allows anyone running a small business to
receive money using a major credit card. This particular storyboard features Lou Rosenfeld, the
President of Rosenfeld Media (and a good friend). Lou often attends UX conferences both as a
speaker and to help promote and sell over 30 exceptional UX books published by Rosenfeld Media.
Thanks to the Square app, Lou is able to take major credit cards as a payment for his books,
providing convenience for the buyers and a nice end-of-the-day report for Lou.
If you dont already have Square on your mobile device, I recommend you download it and
review the award-winning UI that purportedly resulted from the initial storyboard much like this one.
It makes for an excellent case study. NOTE: to use Square youll need a free card reader. Go to
squareup.com to get yours.
Using Kevins Square app storyboard as an example, lets review seven guidelines for creating
interesting and effective storyboards:
1) Establish a strong sense of place
As we can see in the opening panel, Kevins storyboard starts an establishing shot of a convention
center. We see an industrial-looking building and a sign in front. The opening panel is fairly detailed,
and helps us understand where the story takes place. Establishing a sense of place is essential to
transporting your readers into the story and creating a deep emotional connection with your subject.

Establishing a sense of place is also essential to modeling your understanding of the free range
customers. Putting your characters in their natural habitat allows them to behave in the
characteristic fashion and helps your story unfold smoothly and logically.
To illustrate the importance of the opening panel to the story, I removed it in the picture below.
Note how the story now lost its anchor and its taking your brain a bit longer to catch up to whats
going on:

To make the storyboarding process easier, remember to always start your drawing session with a
simple yet profound question: Where am I? This will put you in the ideal frame of mind to do
effective storyboarding. Whenever youre stuck, come back to the Where am I? question. Close
your eyes. Picture the scene in your mind in as much detail as you can to establish a strong sense of
place. See the electric light of the conference hall; hear the echo from the animated crowd at a
conference. You recognize some of the attendeessay hello! See the covers of world-class books on
the table that you yourself commissioned; smell fresh ink on crisp, glossy paper. How do you feel?
Now put your protagonist, Lou, into that scene and describe what happens next.
For the establishing shot to be effective, spend a bit of extra time and effort on your drawing to
ensure that it is believable. This will be time well spent, because it will put you in the right frame of
mind to continue with your storyboard. (For more information, see Drawing Establishing Shots
section in Question #4: What do I need to draw in my storyboard?)
2) Avoid captions, use dialogue and thought balloons
In storyboards, captions are considered bad form: its more effective and immersive to the reader to
tell the story with the characters own voices and thoughts, which generally represented in the
storyboard using speech and thought balloons. A great example of this technique can be seen in
classic graphic novels such as Alan Moores Watchmen (http://bit.ly/1dpwatchmen) which is on
Times 100 All-Time Best Novels list (http://bit.ly/1dptime) and the critically acclaimed V for
Vendetta (http://bit.ly/1dpvv).
Using a distracting Narrator Smurf voice yanks the reader out of the story. In contrast, Alan
Moore maintains his dark, brooding realism by introducing external events via TV announcers and
character dialogthe way we ourselves find out about news and happenings. Frank Millers
Batman: The Dark Knight Returns (http://bit.ly/1dpbat) particularly stands out in this regard: the
characters of the TV announcers are craftily woven into the story itself, and the tragic absurdity of the
western TV culture is driven home with the full strength of the black armored boot during the
dramatic meeting between the Joker and the TV personalities at the conclusion of season three (I
wont tell you what happens, so youll just have to pick up a copy and see for yourself!).
Kevin Cheng likewise skillfully avoids captions in his Square storyboard and moves the narrative

along using the dialog between Lou and his customer:

Imagine for the sake of the argument, that instead of the pleasure of discovering Lous worlddomination goals and his primal desire to be able to accept credit cards as payment for his books as
we normally would (that is through observing Lous conversation his customers) we are hit with the
following caption instead:
Meet Lou. Lou runs a small, traveling bookstore. Thanks to the Square mobile app, Lou is now
able to accept all major credit cards, so he can grow his sales.
OUCH! (Not my best writing, by far. Really. OK, you can stop laughing now.) I hope this painful
example demonstrates several salient points:
a) Its nearly impossible not to make a caption sound like a commercial.
b) The caption throws an immediate switch in the brain that removes any and all connection with
Lou.
c) I will now have to pay you to read the rest of this story.
So enough said! Captions are toxic, slimy, soul-sucking vampires. Avoid them like curse they are.
3) Pick appropriate transitions
In his brilliant book, Making Comics (http://bit.ly/1dpmakingcomics), Scott McCloud defines six
types of transitions: (reprinted below with permission of the author):

For most UX storyboards, youll primarily use Action-to-Action transitions with the occasional
Subject-to-Subject or Scene-to-Scene transition, when the story demands it. Rather than explaining
these key transitions in words, allow me to present the appropriate reprints from the brilliant Making
Comics.
A) Action-to-Action: the Action-to-Action transition is a UX workhorse. Its versatile, and keeps
the story moving forward at a good clip. Action-to-Action transitions are especially handy for mobile

storyboards because the story is often a series of quick actions that move in space as well as in time
and this transition is ideal for illustrating this. Here is the Action-to-Action transition... ahem... in
action:

B) Subject-to-Subject: this transition is very useful for showing a dialog between two people. It
is characterized loosely by a close up of the speaker or listener with the emphasis on their emotions
as can be glimpsed through their facial expressions. In UX storyboarding this transition is used as a
break from the Action-to-Action transitions during important dialogs:

C) Scene-to-Scene: If you read the awesome Game of Thrones series by George RR Martin
(http://bit.ly/1dpthrone), you should be very familiar with Scene-to-Scene transitions used as a
literary device, as the narrative jumps around constantly between endless Starks and Lannisters, often
leaving various heroes and villains (as well as the eager readers) literally hanging off a cliff. In UX
storyboarding, Scene-to-Scene transitions are a special case: they allow the viewer to jump across
time or space to keep the story moving or to show a parallel storyline between the two places. This
can be very handy for example if you need to show two parallel swim lanes that show two different
people using an asynchronous mobile service:

Kevin skillfully combines all three types of transitions in his Square app storyboard:

Note that although most panels look like action-to-action transitions, there is another factor in
play. In particular, note how the mobile devices interface is treated as a third person in the dialog
between Lou and the buyer. This is a unique feature of many UX storyboards (see sidebar below).
Danger, Will Robinson! The unique feature of many UX storyboards is that device
interfaces are often treated like another participant in the dialog (or at least as a well-meaning, but
clumsy robot). Because the device interface is so important (and is in fact, the entire raison dtre for
having a storyboard in the first place!) the device interface is elevated to the status of a full-fledged
story participant. In a way, simple action-to-action transitions in a typical storyboard become in fact
subject-to-subject transitions, where the view alternates between that of a computer and a person
interacting with it. This casting is especially easy to do with a mobile device because it is a selfcontained digital object that is aware of its environment and moves around from place to place.

Another important point is that Kevins storyboard includes a Scene-to-Scene transition indicated
by the caption LATER... on his last panel of the storyboard. Time-based transition is the only
generally accepted use of captions. Be sure to keep them short and to the point. In this case, the
LATER... caption shows that a longer time-period has elapsed between the last panel and the one
before it (that is, Lou looking at his sales figures sometime after the sale has been concluded). This
cleverly concludes the story and illustrates reporting as an additional benefit of using the Square app.
4) Stick to five to eight panels total
Storyboards that are between five and eight panels are generally effective and easy to follow without
being boring, which makes this a good range to aim for. Few people make their story shorter than five
stickies, because its hard to tell the complete story in four stickies or less. Issues with incomplete
stories are also generally easy to discover as soon as you show your storyboard to someone outside
your team. If you discover that your story doesnt come across quite as complete as you pictured,
dont panic! Provided you were (ahem...) sticking to using sticky notes to draw your storyboard, there
is a simple fix: add a few more panels that help explain the missing aspects of your story and
rearrange the stickies on the page to incorporate the new material. Problem solved!
A far more common issue is making the story too long. If you find your storyboard getting longer
than eight stickies, you may be falling too deeply in love with it. Rememberwhile the ideas
embedded in the storyboard may have taken years to mature, the storyboard itself is meant to be a
simple visioning exercise you can finish in 15-20 minutes, not a work of art! Chances are, your first
storyboard will need to be tweaked, often significantly. This will happen as you show your
storyboard to teammates and potential customers, get feedback and gain insight. Falling too deeply in
love with an early version of your vision will make you attached to it and prevent you from thinking
clearly when faced with new facts and having to make adjustments. Spend just enough time on your
storyboard to document your vision, and then stop.
What did you work on today? Did you just lay bricks, or were you building a cathedral? (if
you dont know what this means, Google it: http://bit.ly/1dpcathedral) Dont get confusedthe
artifacts we as designers produce (storyboards, wireframes, reports, etc.) are not the product. The
product (and more commonly the service) is the product! Drawing storyboards and wireframes is
like laying bricksits just a way to get us to the completed cathedral. Focus your efforts on team
alignment toward building working software, services, and ecosystems. Your design deliverables are
just a way to get you there.
Another reason the storyboard maybe getting too long is that you are adding too much interface
detail. Remember: too much interface detail is actively harmful at the Envision stage. You need the
discipline to maintain clear separation between your vision and your interface design at all times (see
Maintaining Good Prototype Hygiene section Question #8: Why do you insist on using small square
sticky notes for storyboards?)
The function of the storyboard is to record the goals and use cases and kick-start the thinking
process, while allowing space for multiple design interpretations. Remember this is the Envision
(storyboarding) stage: youre creating a vision, not designing the interface. Stick to the vision. Note
how Kevin ruthlessly abstracted unneeded interface details and optimized the story to make it lean yet
wonderfully expressive. Each panel moves the story forward by sticking to the point, with minimal

extra details. The entire complete use case is packed into just five panels!

5) Close with an (appropriate) bang

The final panel in your storyboard should show the benefit of using your mobile app. Spend a bit of
extra effort on this panel to ensure that your big bang theory is appropriate (http://bit.ly/1dpbbang).
Many people tend to overemphasize the benefit, which makes the final panel cheesy and hurts the
believability of the entire story.
Let me give you an example. At DesignCaffeine we do a lot of work with financial companies, and
they make fantastic clients. However, many teams (and in particular, some otherwise really awesome
middle-management folks) get a bit over-enthusiastic about the level of benefit a particular feature
would provide to the customer, often creating a final panel along the lines of Most AWESOMEST
Thing Ever! The customer just paid their bills on their mobile device! Jump for joy!
The reality is often just a bit more mundane: first off, the customer often has to wait 12-24 hours to
enable Bill Pay, and this cooling off period makes the whole exercise rather less exciting. And
then, even if the Bill Pay feature somehow automagically turns on without having to wait for legacy
back-end systems (as well as having to read and sign the 132-page EULA (http://bit.ly/1dpeula2),
take a retinal scan, send a urine sample along with some toenail shavings for analysis to Chinain
short, all the other things your financial institution wants you to do to prove to the NSA that youre not
a terrorist) all it tends to accomplish is that . . . Wait for it . . . the feature helps people give their
money away just a little bit faster.
True, most people who use the mobile Bill Pay service appreciate the convenience, but its hardly
the stuff of the best moments of life! Instead, the major benefit of mobile Bill Pay is the slack it
provides in bandwidth and time, which customers can spend throwing a Frisbee with their dog or
watching their kids play softball. (For more discussion of the importance of slack, see fantastic book
Scarcity: Why Having Too Little Means So Much by Sendhil Mullainathan and Eldar Shafir
(http://bit.ly/1dpscarce)this book should be essential reading to anyone designing and building
digital products). Bottom line: to stay believable, be real with your storyboards big pay off moment
make sure your final panel is appropriately enthusiastic and reflects the reality on the ground, not
the corporate Kool-Aid.
Controlled enthusiasm is the key. Enthusiasm is like gasoline. Properly employed, it
can do magnificent things. But if you spill it about carelessly, you run the risk of a catastrophe... You
must take care that your enthusiasm does not cloud your judgment.Napoleon Hill, Keys to
Success (http://bit.ly/1dpsuccess)
Kevin, as usual, delivers an excellent example of controlled enthusiasm. In his Square app
storyboard the final big bang panel is barely any bang at alljust another day in the office for Lou,

looking over his daily sales:

And note that, although Lou is smiling (we just see the corner of his mouth) the screen shows a bar
chart that reflects quite a bit of variation. In fact, the final bar on the chart (presumably showing how
many books Lou sold that day) is lower than all the others on the graph. Talk about realism!

6. Im stuck. Where do I start?

Invariably, when a scenario is written down or spoken aloud, it is happening somewhere. So when I
sit down to do a storyboard, I always begin with a simple question: Where am I? Am I observing
my customer as they board the Metro train? Is the train moving? Is it daytime or night? Hows the
light? How busy is it? Is the customer comfortably sitting down? Or standing, because he is on a jampacked train during the peak commute? What is the customer wearing? What kind of device are they
using? What else do they have with them? Where are they going? Why? What else is going on in their
life? .... And so forth.
Human minds are intricate organic story machineswe have incredible capacity to create very
detailed scenes in our minds based on just a few words and weave a story out of that setting. In fact,
most of the time this happens subconsciously even before were aware of it. It takes practice to
capture that image and put it down on paper, but I assure youanyone can do this.
I find it best to start, as the clich goes, at the beginning. Simply imagine and draw the opening
shot of your story (we already discussed this in the previous two questions). You do this by asking
that simple, but powerful question: Where am I?. If it helps you, imagine that you are the customer.
Alternatively, you can imagine that youre standing or floating nearby, quietly observing your freerange customer in their natural habitat. Then draw what you see.
Establishing shots have magic all their own, because drawing one transports you into the setting
and mindset you create with your drawing. And through that conduit flows empathy, the love and
connection we feel for our fellow humans. The love we can combine with our understanding of
technology and turn into a useful technical solution that empowers our fellow Earthlings. So before
you put the pencil to paper, close your eyes, and ask the magic question, Where am I? Then draw
the setting you see in your minds eye. Dont worry about the rest of the story while you do this. Just
draw that initial setting. Stay in the moment.
Take as much time as you need to do this properly and keep thinking about the scene and adding
little details. Your mind will then conjure up the next step in the story, then the next one after that, all
driving toward the outcome you selected in your subconscious intuitive mind. That is how your story
comes together.
With practice, youll learn to set up your establishing shots by zooming out far enough out to where
people are barely visible as lines or dots or can be omitted altogether. But the important thing now is
to draw what you see. And the more you practice, the easier this will get, so do this simple exercise
as often as you can. Im not sure how or why this works, but the power of this technique is
undeniable. Hundreds of my students who were completely stuck, got unstuck in less than two minutes
by simply asking, Where am I? and drawing the picture they saw in their minds eye. Go ahead and
try it now. Because if not now, when? (http://bit.ly/1dpnow)

7. You encourage us to just storyboard our assumptions. Isnt it better to do some research first?
Absolutelyhaving more research, especially up-front, is both wonderful and highly desirable. That
is, if you have the time and budget to do it! In our modern, fast-paced world we often don't have the
luxury of data gathered in years of ethnographic research many UXers enjoyed in a recent past. Many
big companies are slashing user research budgets, while at the same time insisting on doing things the
way theyve always been donethat is, having dedicated in-house user researchers provide all of the
data for the entire portfolio of projects and initiatives. In practice, that means that few (if any)
projects get to do any research at all!
Another challenge to long-term research is that mobile technology is just moving too quickly for
last years research to be relevant. Were using smart mobile devices very differently today than we
did just two or three years ago, without much of the early training wheels: global navigation,
skeuomorphism, tutorials, and the like.
Take skeuomorphism for example: until recently, lifelike buttons that popped off the page with
drop-shadows, bevels and rounded corners were all the rage for mobile apps (both iOS and Android)
and much of the user research supported the usefulness of skeuomorphism in communicating to the
customer which parts of the interface were in fact interactive controls.
Today, while there is nothing to directly contradict this early research, many mobile interfaces
follow the any gesture anywhere approacha clean and flat design language that is almost the
exact opposite of early skeuomorphism introduced by Apple iOS. (One can argue that the Android
Material Design is a kind of skeuomorphism, but this discussion is beyond the scope of this book
sign up for my newsletter to get see my upcoming article on this topic http://bit.ly/1dpadb2).
Collectively, the rapid pace of mobile innovation means that much of the research data obtained
last year will, at best, be no longer be applicable. At worst, this means that last years research
data be outright damaging to your design effort. Especially if youre trying to produce an app that
has even a remote chance of being featured in the Apple App Store/Google Play Store (take it from
me, we helped just one of our clients, Intuit, to get six featured apps for Android and iOS
http://bit.ly/1dp6case).
Heres another example. If youre building for the Android platform, you might have noticed some
pretty drastic changes from Android 2.x to Android 4.x to the new Google Material Design. In just
one year the entire platform went from global navigation accessed from the bottom right on the device
menu (2.x), to showing only local functionality on each screen (4.x). Now with Android Material
Design, new elements such as Floating Action Button (FAB), new transitions and the concept of
digital paper layers have been added to make things even more interesting (see Question #14:
How do I design for Android Material Design? in Part 2 of the book).
Lack of persistent, visible global navigation in favor of off-screen approaches like the Drawer is a
drastic reversal of the canonical design principles of the recent past, and is still the subject of
vigorous debate (Anthony Rose, April 8, 2014, UX designers: Side drawer navigation could be
costing you half your user engagement TNW, collected July 30, 2014, http://bit.ly/1dpdrawer).
Should you use the Drawer? Tabs? Drop-down title? Instead of trying to operate from the platform
of certainty, you can reduce risk by using a lightweight, inexpensive methodology that allows you to
test various approaches quickly to experience first-hand which pattern works best for your
customers. That is the function of the $1 Prototype methodology and the topic of this book.
If you follow the traditional model and spend years to carefully validate your findings, much of the
usefulness of what you discover could be lost, as other, more nimble companies swoop in, taking
advantage of emerging technologies and new habits, or as mobile technology itself simply moves on.

Thats not to say that long-term ethnography studies arent usefulat DesignCaffeine we also do
pure ethnographies yielding global generational trends and deep insights into consumer behavior
you just cant get any other way. Just dont expect traditional ethnography and heavyweight usability
techniques to easily fit into a modern, fast-paced agile mobile project and inform your tactical design
effort in a timely fashion!
In contrast to the certainty provided by rounds of dedicated research, storyboards excel at
providing the team with a lightweight, quick-and-dirty $1 Prototype approach to experience design.
By taking the time to document the key assumptions as a cohesive story early in the process, the team
can now take some artifacts into their field research for immediate evaluation. Thus, with a
storyboard, any field study becomes a Lean experiment. By documenting their early assumptions, the
entire team becomes tightly focused on creating the product and extremely sensitive to any parts of the
product story that ring false. A storyboard allows everyone on the team to operate semiindependently under a joint understanding and correct any issues and discrepancies quickly, as new
information comes in. Should it become necessary, the storyboards can also help the company to pivot
rapidly, preventing the consequences of bad assumptions from propagating into the product (see side
bar Fail Fast with Storyboarding: Mood Ring to MyStuff later in the book).
Doing lightweight storyboarding and showing a storyboard to a few potential customers at a coffee
shop (or even something as simple as validating the storyboard with a larger team) is much better
than doing no research at allwhich is what frequently happens at companies that insist on only
doing their research a certain way or with only a few dedicated user researchers. The $1 Prototype is
not some kind of a silver bullet techniqueits a restating of the basic UX truths and a way to get
some slack in a mobile, fast-moving world where time, money, and attention are scarce resources.

8. Why do you insist on using small square sticky notes for storyboards?
There are several reasons I prefer to use small square sticky notes (3x3 inches is about ideal) to draw
my storyboards:
1) Reuse. Reduce. Recycle.
If you read the previous sections you may have gathered that it takes extra time to draw the
establishing shot as well as the last Big Bang pay-off panel of the storyboard. Having these on
separate pieces of sticky paper allows you to reuse them over and over again in different scenarios. It
also gives you incredible freedom to add, subtract and re-arrange your storyboard as neededjust
remember to take photos of your storyboard with your mobile device as documentation. Remember,
the $1 Prototype methodology is about doing what works. Drawing is an enjoyable activity, but so are
hiking, sex, and relaxing on the beach. So consider: do you wish to spend two hours painstakingly
redrawing all your storyboards because you chose to put everything on the same piece of paper? Or
would you prefer to get those two hours back because you only had the foresight to use sticky notes?
Your choice.
2) Respond quickly to new information.
The storyboards are living documents, meant to reflect your current understanding of the problem
youre trying to solve. The easier it is to update your storyboards, the more likely youre to keep them
up-to-date. The $1 Prototype methodology is about quickly responding to new informationwhether
it comes in the shape of updated business and technical requirements or new research findings. If
several of your potential customers look at your storyboard and find one particular aspect confusing
or unrealistic, it is easy to fix the storyboard directly in the field. Just replace the confusing sticky
note with two others that help tell your story better, and youre good to go.
Remember, storyboards are a very playful medium, so have fun with this research methodology.
You can change the meaning significantly by changing a few simple aspects of your drawing or even
just by rearranging the order of key actions. Sticky notes make this creative process simple and easy.
Just be sure to take a picture of the whole thing before you make the change, so you can remember
your progress later (or share with your remote team). Store these images in Evernote
(https://www.evernote.com), Dropbox (https://www.dropbox.com) or just email them to yourself and
your team with notes outlining what you changed and why.
Co-Create your storyboard with Participatory Design. Instead of making the storyboard
the end in itself, use it as a tool to involve your potential customers in the design process directly.
Revise your storyboard based on their feedback while they watch. Explore, move things around,
follow your hunches. Most importantly, connect. Use your storyboard prototype as a conduit for a
human, spiritual connection with the person youre showing it to. Allow your empathy, respect,
humor, and humility to flow freely through your simple drawing and into the person youre trying to
serve. Drop your preconceived ideas and tune to the frequency of the person in front of you to receive
the simpler, deeper understanding behind their feedback. See the persons true needs: their craving for
empowerment, simplicity, achievement, belonging. Can you, in love, show them a story that delivers a
little of what they crave? Or simply makes their lives a little easier? Or are you just adding to their
problems, creating nothing but noise and confusion, while relieving them of their cash? Connect and
youll be energized and enriched by your connection, and your discoveries will blow away your
expectations.

3) Show and tell. Anywhere.

If you followed my recommendations thus far, your entire storyboard should comfortably fit on a
standard 8.5x11 or legal 8.5x14 paper (you may have to use both sides for standard paper). Having
your entire story on a single piece of paper allows you to take your storyboard anywhere with you
and to have it handy whenever you need to do a quick show and tell. Simply throw it in the folder and
stick it in your backpackthat, some spare stickies and a pencil, is all the equipment you need to do
some quality user research whenever youre around other people and have some free time.
4) Maintain good prototype hygiene.
Over the years of teaching my mobile design workshops, I found that people who ignore my advice,
and try to use the same large rectangular 3x5 inch sticky notes for both wireframing and storyboarding
always fall into a trap of drawing too much interface detail in their storyboard (it may be that the
format of the sticky resembles the form factor of the phone too much, or people are simply
uncomfortable with the extra left over space on a larger panel.) Avoid this mistake by maintaining
good prototype hygiene, by keeping different sizes of sticky notes reserved for separate design
activities. Drawing wireframes on 3x5 stickies, while using 3x3 stickies strictly for drawing
storyboards, will help you separate the use case from the implementation in your mind, before the
pencil even hits the paper.
For example, if the storyboard requires the customer to input directions into the mobile device,
it is up to you how this input is actually implemented in the wireframes (and therefore the final
product). Will you use voice input, search history, GPS locator, social feeds? Or, if the task actually
calls for keyboard text input, will you use one text field you parse, or several different text fields on
one or more screens? Or will you outsource your text entry to an overseas Mechanical Turk team
armed with advanced Optical Character Recognition (OCR) as CardMunch, Intuit and TaxBrain do?
Good prototype hygiene allows you to document your vision, while giving your team the flexibility
to think about the design problem creatively on multiple levels. So remember the three-button
maximum rule and keep the interface off your storyboard.
Separate the What from the How. Design is problem solving; the key to solving problems
is to first clearly define them. When we intertwine thinking about WHAT needs to get accomplished
with HOW it needs to get accomplished, we do a crap job of problem definition because the moment
we start talking about The How, we stop talking about The What. The designer must disentangle that
mess, first for herself, and then, as best as she can, for others. Let I need a button go uncontested
and youll soon be trapped in a room with a dozen other people arguing over what shade of blue to
use. Instead, pick apart the request before responding. Explore what the problem is for which a button
is the best solution to allow the more significant issues to emerge. Dan Willis, Five Things Every
UX Designer Should Do Well, UX Crank Blog, collected September 1, 2014 (http://bit.ly/1dpfive).
5) Refuse to allow any space for captions.
Small, 3x3 inch square stickies are just small enough to be un-intimidating to the beginner
practitioner, yet can carry enough detail to communicate complex concepts with ease, all without
leaving space for captions. (Which is a good thing: as we discussed earlier, captions are toxic to your
story.) What you ultimately use to draw your storyboard is of course completely up to you. I
recommend using five to eight square 3x3 inch sticky notes. This will help you take full advantage of

the $1 Prototype benefits, save time and effort, and help you avoid many potential problems.

9. I got my storyboard. Now what?

Finished your storyboard? Congratulations! Now comes the fun part: testing your assumptions against
the reality on the ground. Remember, the state of your prototype reflects the level of completion of the
product. Your storyboard is your first prototype. Its going to help you to decide if your vision is on
target with the needs of the market and correct as necessary.
The first step is to do a storyboard walk-through with your larger team. This need not take long
10-15 minutes is sufficient. Simply take a photo with your phone and project it as you would
PowerPoint slide on an overhead projector (In my workshops, I use a fancy IPEVO Point 2 camera
(http://bit.ly/1dpcam) to project sticky notes live on the screen. A hat tip to Barak Danin of UX Israel
for this idea).
Now talk through everything that happens in your story. Listen carefully to the feedbackwas
everything clear? How does the story compare with the experiences of members of your larger team?
Are the benefits clear and abundant? Are there any competing scenarios or things that just dont jive?
The $1 Prototype Play List (http://bit.ly/1dppl1) on YouTube has several live-action videos showing
real people doing storyboard walkthroughs for some of the use cases in the book.
If during walk-through you discover that your storyboard does not resonate with the target
audience, you should consider changing it. See Fail Fast with Storyboarding: Mood Ring to
MyStuff in the sidebar below.

Once you have completed a storyboard walk-through with your team and found it satisfactory, its
time to move on to creating your prototype using 3x5 sticky notesthe subject of Part 2 of the book.

Fail Fast with Storyboarding: Mood Ring to MyStuff

Every team from my San Francisco State University (SFSU) Mobile UX Design course had to design
a unique mobile app that solves a real problem. Naturally, the first exercise included storyboarding as
a proof-of-concept. One of the teams came up with a Mood Ring app: a cool concept, featuring a
mobile app that would make you feel better when youre stressed or depressed. Heres one of the
storyboards, starting at home:

And heres another version of the same vision, this app being used during the commute:

Additional storyboards from the team included tracking your mood over time, providing alerts
with affirmations, playing calming music, etc. Regardless of the specific aspect of the vision,
however, none of the storyboards the team came up with resonated with the rest of the class. Instead,
during the storyboard walk-through the class was overall very skeptical about the usefulness of such
an app.
The main issue (which is plain to see if you look at the storyboards above) was that, while the
problem was definitely there, none of the stories provided a clear, detailed vision for a solution and
a substantial payoff at the end. Most people already have a friend or two that they would call when
feeling overwhelmed and carry some calming music on their phone. Affirmation alerts were judged to
be too distracting and untimely, while any kind of tracking seemed to involve a great deal of data
entry and have no clear benefits, as most people already know where (and with whom) they feel most
stressed or irritated. Thanks to the storyboarding exercise, the Mood Ring app was quickly
abandoned in favor of designing an entirely different appMyStuff.
MyStuff is the app that keeps track of your stuff, including warranties and instruction manuals,
helps diagnose and repair common issues, and, when all else fails, helps find a repair shop near you:

As you can see, both the use case (literally, oh shit, my dryer is on fire!) and the pay-off (my
dryer was repaired quickly by a qualified local professional) are both very clear. Having a vision
with a tangible pay-off helped the team to move quickly to exploring interesting design solutions
through multiple iterations of the sticky note designs. Here are some early versions of the sticky notes
prototype, using the rooms in the house concept to track the stuff:

Other collage of stuff concepts:

Exploring the collage to segment the home screen to lay out the functions instead:

After testing various mosaic and collage concepts with real potential customers, the team
chose the calm grid of items as the homepage (printer, dryer, etc.), with clearly labeled functions
(scan item, sell, repair) in a custom overlay drawer. Heres the final round of sticky notes prototype:

Finally, here are medium-fidelity wireframes. These are normally not needed, as sticky notes are
enough for coding the app, but were required as part of this particular assignment. (See Question #30,
What kind of graphics software do you use in your design work? for more discussion on the topic
of using software):

Bottom line: When you feel a great idea coming on, spend just 15 minutes and draw a quick
storyboard. This will help sharpen your vision and test it for consistency and viability. The
storyboard is an excellent tool to help you judge whether the use case itself is reasonable and the
payoff is worth the trouble. Once your vision is complete, designing an excellent solution that
becomes a win with your customers becomes much easier.

Part 2
Prototype
While storyboarding is vitally important, the whole purpose behind the $1 Prototype methodology
is to give you the completed wireframes for your project. In Part 2 of the book, well cover the
fundamentals of mobile design and create prototypes of Android Material Design and iOS8 app
screens and mobile versions of the RWD pages.

10. What should I strive for when designing my mobile experience?

Our mobile devices remind us of upcoming appointments, tell us the best way to get there given the
traffic conditions, and find a parking space in a hurry. They notify us when our friends say something
funny or interesting, help us find enriching stuff to see and do, and allow us to share these experiences
with the world. Your mobile phone is what you can count on to get you out of a difficult situation (and
if all else fails, you can always use your phone to beat muggers over the head, especially if yours is
one of those rugged early Nokia models).
Mobile technology transforms the way we see ourselves and our environment. Mobile phones
were essential for organizing and overthrowing dictators during the Arab Spring
(http://bit.ly/1dparabspring) and are an important part of the essential arsenal for all of the Little
Brothers (http://bit.ly/1dplittlebro) everywhere. Mobile technology empowers us to make better,
smarter decisions and be more aware of our connection with each other and the world. Like wearing
an Iron Man suit of cybernetic armor, our mobile devices protect us from the worst aspects of
ourselves, make our jobs and our lives easier, and generally help us feel like everyday super-heroes.
When designing for mobile space, remember the Iron Man (http://bit.ly/1dpironman) movies and
comics: operating the Iron Man suit feels empowering and natural at the same time. Thats because
the Iron Man technology is highly sophisticated but not complicated. You dont have to navigate
complicated menus to create a repulsor blast. The interface is automagical (literally wired into
Tonys nervous system in some versions of the story). All you have to do is aim and think the action
and Jarvis, the on-board AI, executes it. (For more examples of sci-fi interfaces inspiring near-future
technology, see an excellent and highly inspirational book Make it So by Nathan Shedroff and
Christopher Noessel, published by Rosenfeld Media, http://bit.ly/1dpmakeitso).
The real power of mobile is not just simple and intuitive technology. Its technology that becomes
the integral part of youa perfect mind-meld between human and machine, each one supporting,
augmenting and empowering the other. Strive for the same feeling of freedom and empowerment in the
mobile experiences you design. After all, what are mobile devices if not our modern interpretations
of the superhero myth, our very own portable versions of the Iron Mans cybernetic exoskeleton?
Above all, use your mobile design effort as an opportunity to transform your workflows. That
means discarding the over-bloated marketing-laden mess that most websites have become, and
starting over, from the very core of the experience, targeting that feeling of empowerment, simplicity,
and sophistication (see Luke Wroblewskis brilliant book Mobile First, http://bit.ly/1dpmobile1st).

11. Where do I start my mobile design?

The best place to start your design is on the Home screen, using the List of Links design pattern.
While more powerful and more effective homepage patterns exist, List of Links is uniquely suited for
taking stock of the initial situation to begin your design, by helping you answer questions such as:
What do I have in this app? What can I do with this app? Etc.
The section below is an almost-verbatim excerpt on the List of Links design pattern from my book
Android Design Patterns: Interaction Design Solutions for Developers (http://bit.ly/1dpadp). The
book includes over 70 mobile design patterns including six design patterns just to help you design
your apps homescreen.

List of Links Pattern

Sometimes called Hub-and-Spoke (first documented by the UX expert Jennifer Tidwell in her
essential book Designing Interfaces (http://bit.ly/1dpdesint), List of Links is a popular and
venerable design pattern used all over the mobile world on all manner of platforms and applications.
Unfortunately, this pattern typically tells people about the story, rather than telling the story itself.
Heres how to spruce it up to improve its usefulness.
How It Works
The home screen acts as a hub that presents a bunch of links or icons of primary functions or popular
views that can be obtained with the app.
Example
You dont have to look hard to find an example of this pattern. Travelocity (see Figure 6.1) offers a
good one that also highlights the key issue with this pattern: telling customers about the story (instead
of the story itself).

Figure 6.1: The Travelocity app uses a typical List of Links pattern.
The screen makes it clear what information can be obtained within the app and what actions you
can take if you engage with the app as a customer. The icons are clear. However, despite the clarity of
the display, the screen leaves the customer feelinga little blue (or a little gray, if you are viewing

this screenshot in gray scale). There is absolutely no information that pertains to the customer:
Everyone gets the same set of links. How would you make this static page tell customers more of a
story?
One approach is to use notification badges somewhere on the page or on the individual icons or
links. One example of this is the early version of Google Plus (see Figure 6.2), where notifications
are featured prominently on the top of the screen (the 3 in the red box).

Figure 6.2: Google Plus List of Links tells more of the story.
A simple variation of this would be to put notifications as smaller badges on individual iconsfor
example, place a (1) on the Photos icon if someone shared a new photo and a (2) on the Circles icon
when two people have been added to your circles, and so on. The additional notifications would help
the List of Links provide a few more details of the story (rather than telling people about the story.)
When and Where to Use It
List of Links is the default pattern most people should consider as the first design for their
homescreen, because List of Links does a great job of cataloging various aspects of the apps
functionality. Even if you do not end up ultimately using this pattern for your homescreen, drawing a
List of Links for your app is a great exercise in organizing the apps information architecture and
cataloging possible use cases and those of your competitors.
Other patterns in this chapter (Updates, History, Browse, Map and so on) are better for certain
applications; however, List of Links is the basic default you should consider if your app covers a lot

of highly variable functionality. Consider that in the Travelocity example (refer to Figure 6.1 above)
the customer can book hotels, flights, or cars, read about new and exciting vacation destinations, and
even find gasthis is a great deal of useful functionality to pack into a mobile app!
Why Use It
The List of Links pattern is one of the easiest and most intuitive for a novice to navigate. Its easy to
design and build (provided you have a decent icon designer), and it launches instantly because it does
not require a server call to retrieve any information that is not already on the phone. Even if you do
decide to go the server to grab the badges, as shown in the Google Plus app refer to Figure 6.2, these
updates are typically single digits, which require minimal download time.
Other Uses
One popular variation from this basic pattern is the Grouped List of Links shown in the Southwest
Airlines app shown in Figure 6.3.

Figure 6.3: The Southwest Airlines app shows a grouped variation of the List of Links pattern.
This is a great variation for apps that have a lot of links because it enables a logical grouping that
helps reduce the cognitive load on the customer.
Pet Shop Application
List of Links enables designers to succeed with a wonderful variety of information architectures
(IAs). Imagine for example, that you are building a Pet Shop application. Figure 6.4 shows just two
List of Links pattern implementations: the IA on the left enables exploration by type of object (Dogs,

Cats, Birds, Fish, Reptilians, and Other) whereas the IA on the right is more centered on what you can
do (Find Pets, Care & Feeding, Local News, and Your Profile). Its a great exercise to pause here and
imagine a few other alternative IAs that fit the Pet Shop theme. Which one should you choose?
Obviously the one on the left emphasizes e-commerce application, whereas the one on the right is
more suited to social networking applications. The one you ultimately choose depends on what your
app is designed to do.

Figure 6.4: The List of Links pattern supports multiple IAs.

The badge update mechanism mentioned earlier is also included, so that some links (for example,
Local News in the right-hand design variation) show the new updates that have come in since the last
time that particular area of the app was visited.

In summary, the List of Links pattern is like a lobby of the hotel at 3 am in the morning. No matter
how opulent, the lobby is just not a place to be at that hour, and most travelers immediately move to
one of three destinations: the room, the restroom or the hotel bar (credit goes to Jared Spool for this
excellent analogy.) So while List of Links is a great place to start your design, most high-quality apps
quickly move on to other, more powerful patterns. But worry not: the work you did mapping out your
List of Links is far from wasted: you can immediately put it to use by putting these links into a
navigation drawer. Drawer typically peeks in on top of the more valuable homescreen content,
making it a perfect analogy to a hotel lobby you visit only for a few seconds as a convenient gateway
to access other parts of the hotel.
A great example of this design progression is Google Plus. When the app first launched, the
homescreen was implemented as a List of Links (on the left). However, subsequent redesigns quickly
moved the List of Links into the drawer element, implementing the homescreen as the Updates pattern
instead (on the right):

Most recently, with Android Material Design, Google modified the information architecture of the
homescreen still further to include a drop-down filter and show key areas as tabs, ostensibly to
improve discoverability of the rich content available on Google Plus:

While the success of this latest iteration of Google Plus remains to be determined, the point Im
trying to make here is that List of Links on the homescreen is a great place to start your mobile design.
Just dont stop there! Also sketch and test the design patterns that might work, borrowing freely from
other apps, then maybe even create some of your own design patterns.
If you need inspiration, check out over 70 design patterns in my book Android Design Patterns:
Interaction Design Solutions for Developers (http://bit.ly/1dpadp). Theresa Neils Mobile Design
Pattern Gallery (http://bit.ly/1dpmobpatterns) is another excellent resource.
Keep an eye on Google Plus. You may think it impossible to keep up with Android with its
many design iterations, fragmented devices and customizations. Mobile design space feels so

overwhelming, and new rumors and leaks are constantly trying to whip consumers into buying
frenzy. How do you know which way Android is really heading? Heres a tip: keep an eye on Google
Plus. Ever since the Google social network launched, the Google Plus team has been iterating rapidly,
doing quarterly releases and experimenting with large changes in layout, information architecture and
new design patterns. Android 4? Google Plus implemented it first. Material Design? Ditto. So if you
want to quickly check in on whats happening at Google, heres an unofficial tip: download and study
the latest release of Google Plus. It will give you more insight into whats new at Google than just
about anything else out there.

12. Are we really able to model mobile experience effectively with a pack of sticky notes?
Yes. Ive seen literally hundreds of mobile design projects over the years, and all of them with just a
few exceptions benefited from being prototyped with sticky notes. (I explain the limitations of the
sticky note wireframes in Question #30, What kind of graphics software do you use in your design
work? in Part 4 of the book.)
What makes this possible? Two things: meat pointers and distractions. Firstly, while our mobile
devices feature high-resolution retina displays, we commonly use our fat fingers (meat pointers) to
manipulate things on the screen. Which means that for a given mobile application or website, we can
only put a maximum of four to five controls across the screen. Thats itnothing more can fit because
the size of our fingertip is simply too large to reliably select a smaller target.
Secondly, by its nature, much of mobile use involves moving around and multi-tasking, which
apparently puts humans in a rather distracted state of mind. Engadget reported on a study in the UK
that found that as many as one in ten people actually managed to hurt themselves by walking into a
post while peering down at their mobile phone screen! These so called "walking and texting" injuries
have spurred the charity Living Streets to launch a pilot project of wrapping thick padding around the
lamp posts and similar obstacles to protect distracted mobile phone owners in the city of London
(http://bit.ly/1dpwalktext). On a related note, in the effort to curb mobile-related teen driving deaths,
much maligned teen heartthrob Justin Bieber made a well-publicized effort to promote the Dont
Text and Drive campaign. (http://bit.ly/1dptextdrive).
Although texting is the obvious culprit, any mobile use by its very nature is distracting. This
includes so called immersive experiences such as full-screen photo and video, mobile games, and
reading. In just a few years since the launch of the first iPhone in 2007, we went from treating
distraction as an aberration (and something altogether undesirable in our sedentary, focused, monitorkeyboard-mouse context) to treating distractions and multitasking as a simple reality of our mobile
world.
Meat pointers and distractions together dictate that our mobile experiences need to be capable, yet
simple and straightforward to operate, shifting the burden of mundane tasks to the device itself and
away from the customer. As Leonardo da Vinci so eloquently stated, Simplicity is the ultimate form
of sophistication (http://bit.ly/1dpsimplicity). But note that simple does not mean simple-minded
just the opposite!
... The operating moral premise of information design should be that our readers are alert
and caring; they may be busy, eager to get on with it, but they are not stupid. Clarity and simplicity are
completely opposite of simple-mindedness. Edward Tufte, Envisioning Information
(http://bit.ly/1dpenv)
As it turns out, a pack of sticky notes is a perfect conduit for modeling experiences that are simple
and straightforward, yet empowering, providing a convenient platform for documenting the designs
and prototyping them in the same, single step. A pack of 3x5 inch sticky notes provides a good
model for a full size mobile device and allows a fast but thorough study of layout, page flows,
information architecture, content, transitions and ergonomics. Using a sticky note prototype allows for
fairly realistic interface components (such as layers, keyboards, alert boxes, drop-downs, and much
more) that can be used to accurately communicate your intended experience to a potential customer.
Most importantly, sticky notes prototype allows your team to immediately put your designs in front
of free-range customers in the wild, where they typically operate their device, get immediate

primary research feedback and improve the design rapidly, without having to do any additional steps.
This combination of capabilities, speed of prototyping and immediate feedback, makes a $1 pack of
sticky notes the essential tool to design for simplicity and delight while guarding against simplemindedness.
Garbage in, garbage out: for optimal test results, your prototype must include all of the key
components, such as actual icons and actual text on the headers and buttons. This discipline is crucial.
Any text that runs off screen on a sticky note, is likewise will likely not fit on the mobile device.
Aufzeichnungen nehmen, Deutsch Sprachbenutzer! (German speakers, take note!) Thus, when creating
sticky note prototypes, I encourage my students and clients to guard against any and all instances of
lorem ipsum as religiously as they guard against dropping their phone in a toilet. To put it another
way, garbage in, garbage out. There are no shortcuts: to get real data, you need to add real content
and draw real interface components. Thats not to say youll get everything right the first timethe
Commute Assist case study in the sidebar below shows how the prototype evolved from conceptual
model to refinements and finally to Android 4.x wireframes. (Also see the $1 Prototype Play List on
YouTube for videos of real people doing a walk-through of their sticky note prototypes:
http://bit.ly/1dppl1.)

Commute Assist
Commute Assist is an app designed by students in my Advanced Mobile UX course at San Francisco
State University using the $1 Prototype methodology. As shown in the excellent storyboard below, the
app provides a value-add to standard Apple/Google Maps interface that allows commuters to
optimize their commute time: hear the news, get traffic conditions and alternate routes if needed, if
theyre running early, stop for a coffee, breakfast, etc.

While the storyboard identifies excellent opportunities to add value to the daily commute, it also
shows the primary challenge: Google Maps app has already delivered an excellent, industry-standard
maps experience Can the team extend and enhance it in unexpected, valuable ways? This is the first
conceptual sticky notes prototype, a perfect reflection of teams level of thinking about the problem at
that particular point time. I especially like the wheel-and-spoke selector on the homepage, screen #1
(using the List of Links design pattern mentioned above) as well as the split screen directions entry
(screen #2) and analog clock you have to spin using a multi-touch gesture (screen #6):

In testing, the team quickly proved that the value-add provided by the concept storyboard was real,
but the vertically spilt screen was not working well. This is the next version of a functional
conceptual prototype:

In testing this refined prototype, the team discovered that the spit direction screen (split either
vertically as in first prototype or horizontally in second prototype) as well as the analog clock were
really hard to figure out and use. Also, the team discovered that Google Maps was a very strong

influence for potential customer. So instead of trying to beat them it made sense to join them
instead. That is, the app was easier to understand and use if it followed the conceptual model laid
down by Google Maps and add all of the enhancements on top of that model. Below is the final
storyboard, optimized for the Android 4.x, that worked much better with the target market:

Finally, the team added visual design elements and created the final high-definition visual design
wireframes:

The final design is a unique combination of Google Maps, Yelp and Sirienvisioned, designed
and customer-tested in just 3 weeks. I dont know about you, but I can sure use an app like that!

13. Can you give an example of an app re-design done using sticky note wireframes?
My favorite classic example is TripAdvisors Android 4.x app. I dont know what forces guided the
designers at TripAdvisor to come up with this interface. My only point here is that if they had taken
the time to test some early sticky note wireframes before building their app, they would have found
some of the same issues we did. After all, As Jakob Nielsen so eloquently said, there are no secrets
of usability:
There are no secrets of usability any more than there are secrets of astronomy. If you point
your telescope at Saturn, you will see that it has rings (Banner Blindness: Old and New Findings,
Jakob Nielsen, Nielsen Norman Group, August 20, 2007, collected July 7, 2014,
http://bit.ly/1dpbanner)
So perhaps, if TripAdvisor would have known about the issues early, they would have had the
time in their development process to draw and test some alternative designs. Using the $1 Prototype
methodology, it took me less than 30 minutes to draw the Parallel Architecture pattern redesign at the
end of this section. Unfortunately, as far the current TripAdvisor design goes, the interface does not
perform as we as one would expect. Below are just a few of the issues we found in our testing.
We asked 6 participants to use the TripAdvisor app look for a hotel (this study was not
commissioned by TripAdvisor). At first glance, this should be pretty easy: the homescreen uses a
simple List of Links design pattern already listing a bunch of possible app areas you can access, and
the Hotels are an easy #1:

Unfortunately, the issues come up as early as the following screen. In our testing, we found that for
various mobile navigation and travel apps, the initial mental model is that the hotels youll find would
already be near you, unless specified otherwise. In contrast, in the TripAdvisors app, the primary
assumption is the reverse: unless you can figure out that you need to tap the Find hotels near me
now checkbox, youll be searching world-wide hotels instead. Even when the participants figured
out to look for it, the checkbox was hard to find: the label on the checkbox is unusually long and

buries the keywords near me in the middle of a long sentence. Including the checkbox label itself,
the phrase Find Hotels occurs three times on the same page, adding unnecessary noise and
confusion. All these are likely factors contributing to the key finding: in our usability testing, many
people missed the checkbox their first time through the flow. To add to the usability challenges, the
checkbox is a non-standard Android UI control: it is hard to tap and seems to be placed too close to
the search field.
When, despite these issues, our participants did figure out to tap the Find hotels near me now
checkbox and got to the next screen, they promptly encountered additional challenges. Note the three
tabs on top of the search results: Stay, Eat and See, which, as one participant put it, sound like dog
training commands. Second, these three tabs were confusing to many people because they already
selected Hotels link using the initial List of Links on the homescreen. Thus the tabs seemingly invite
them to Stay, Eat and See the hotels!
Of course most hotel buildings are not edible, with the possible exception of the Gingerbread
House from Hansel and Gretel (http://bit.ly/1dphansel). But it took most people a few moments to
realize that Stay directly maps to Hotels, Eat maps to Restaurants and See maps to Things
to do. This kind of additional mapping is actively harmful: it is confusing because it shows items
people have already selected and forced them to do the extra thinking to map the Information
Architecture due to multiple inconsistent labels for the same item. Finally, the three tabs needlessly
take up precious real screen estate on the results screen (more on this below).
Navigating from the homescreen is not the only way the TripAdvisor app can search for hotels.
Tapping the magnifying glass from the action bar on the homescreen launches the search screen
sequence shown below:

Assuming youre still looking for a hotel, it seems reasonable to type in the word hotel into the
search field (as an answer to the What are you looking for? question which comes up as the text
mask when the field is first displayed). And indeed, many of our participants did just that. When they
performed this search, they were in for quite a shock. Look at the screen carefully: the app certainly
did find some hotels, but where? The results are hotels scattered around the world, covering parts of

Spain, France, Washington DC and Austria. Now compare the structure of the search results you see
here with the previous search results obtained by tapping Hotels on the homescreen: do you see
anything missing? Thats right: prices, distance and the right caret. In fact, search and browse present
two completely different UIs for the same exact information.
This is a huge problem. Not only was this confusing to our test participants, it duplicated the effort
for the developers in having to create and maintain two sets of pages. And look at the filter link: in
addition to the three filters that match the previous three tabs (Hotels, Restaurants and Things to
do) the app adds the forth filter that occurs nowhere else: Locations. Also note that Things to do
sports a different icon (running man) in the filter than it does on the homescreen (binoculars).
Certainly the UI can be more consistent.
But there is yet a third way that TripAdvisor app can advise you (But that is not all. Oh, no. That
is not all... said the app, with apologies to Dr. Seusss Cat in the Hat (http://bit.ly/1dpcat). If you
look in the overflow menu, you can select Near Me Now:

Although our participants thought that this option looked most promising at the first glance, the app
did something very odd: selecting Near me now catapulted the participants into the Eat tab! Also
note that in this case, the app served up the first type of search results, the ones with the three tabs.
And as I already mentioned, these tabs make up the chrome that takes up a great deal of precious
vertical screen real estate: fully a third of the tiny mobile screen:

Obviously there are better ways to solve this very common design problem. One such approach
involves using a Parallel Architecture design pattern, one of over 70 patterns featured in my book
Android Design Patterns: Interaction Design Solutions for Developers (http://bit.ly/1dpadp). This
design pattern requires just 4 sticky notes. Below is a detailed step-by-step sequence of simple steps
required to create the Parallel Architecture TripAdvisor sticky notes prototype, following the original
design as closely as possible, while fixing many of the issues we discussed above:
1) Homescreen
Pretend the entire surface of the sticky note is your homescreen (you do not need to draw a box or any
extra chrome on your sticky note). Now draw the top action bar.
I am often asked if you get extra points for drawing everything by hand. I have not found
that to be the case. In fact, if youre at all like me, then drawing a straight line accurately by hand is a
serious challenge. Dont waste your timethe $1 Prototype methodology is about doing what
works, and this includes doing what works for you. So go ahead and cheat whenever you can, no one
will slap you with a splintered ruler (http://bit.ly/1dpalanis). And if you dont have a ruler handy,
another pack of sticky notes works well as a substitute.

Right below the action bar I added a Filter Strip. Filter Strip is another important search design
pattern from my Android Design Patterns: Interaction Design Solutions for Developers
(http://bit.ly/1dpadp). It is a thin label that sits on top of the screens interactive elements, usually
displaying the sort order, the text query or other information about the elements below it. (If you look
at the current TripAdvisor app designs shown above, you can see the example of Filter Strip in gray
with the text Sort: Distance). The new Filter Strip I am adding will say Browse Nearby, to
indicate the order of the expected search results:

Adding horizontal lines creates the rest of the structure for the homescreens menu:

Note: these prototypes are done using art pens, so you can see the details. Remember to
work in pencil when you are just starting out with a particular design, as pencil makes it easy to make
small fixes without having to discard the entire sticky note (which is what I had to do when I was
drawing these, as you can see below).

Although there are many much better patterns for the homescreen, I wanted to stick as close to the
original TripAdvisor design as possible. Thus the new homescreen design is also using the List of
Links pattern. Other than adding the filter strip, Ive also re-arranged the order of links, because I
think in the Browse Nearby use case, Restaurants and Things to Do are much more likely to be
frequently accessed on the mobile device than Hotels are. After all, when we travel, we tend to stay
at one place, but eat several times a day and visit multiple attractions:

2) Basic Search Results

If we tap on Hotels, as we did in the original TripAdvisor app above, the next screen well see
would be the search results for the query Hotels:

For many of the use cases we study in the mobile world, including this one, we only need to show
a singe result: after all it is possible (though unlikely) that there is only a single hotel in the vicinity of
the searcher. If you wish you can also spur the imagination of the potential customer and probe some
other questions about the result set by drawing more horizontal lines to indicate additional potential
search results (see more on this testing strategy in Part 3 of the book):

3) Advanced Search
If the searcher is not satisfied with this basic result set of nearby hotels, he can enter a more detailed
query by editing the current query or by searching from the homepage. To facilitate the search
process, the system presents a dedicated search screen with the recent search history:

Note that the keyboard is an additional layer on top of the screen, created using a somewhat timeconsuming technique of painstakingly drawing each of the tiny letters on another sticky note of a
different color. Note that there are multiple keyboards in every mobile OS (letter, email, phone
number, etc.) and youre likely to need more than one keyboard sticky note in the course of your
project. However, once you draw these paper keyboard mockups, you can reuse them multiple times
in many projects until the stickies wear out.
The alternative is to take keyboard screenshots, print them in such a way as to match the width of
the sticky notes pack, and mount them on the back of a sticky note with a glue stick or similar method.
Either way, keyboards are a bit of a pain to make, but in my experience the extra level of realism is
well worth the trouble.
Recall that the fidelity of your prototype should reflect the level of completion of your
project. Depending on your use case, Ive seen good results from just writing the word keyboard on
the smaller sticky note and using that instead, but its harder to get your test subjects to pretend to type
on that crude surrogate. Everything depends on the level of fidelity your particular design problem
demands. Most people are familiar with how keyboards function. However, you may wish to show a
realistic keyboard when testing some tricky forms, especially if you need to study the relationship
between Enter, Next and Done keys on the keyboard and the action bar navigation. You can
also find out whether the keyboard should submit the form, whether the Next button on the keyboard
should navigate to an optional field or dismiss the keyboard, as well as many other useful insights.
(See Chapter 11 in my Android Design Patterns: Interaction Design Solutions for Developers
(http://bit.ly/1dpadp). for detailed data entry design patterns.) Bottom line, detailed form interactions
can be difficult to test without showing what the actual keyboard looks like, so use the sticky note
keyboard prototype with the fidelity that is appropriate for your use case.

4) Advanced Search Results

Once the person types in the new hotel query on the keyboard, Hilton San Jose, they will get a new
set of search results, this time sorted by Best Match:

Once again, I only drew the minimal requirement: a single search result to show the structure,
implying additional results in horizontal lines on the sticky note.
Altogether, the 4-sticky note prototype looks like this:

Note that there are two parallel ways to get to the same type of search results: the basic browse
method (on the left) and the advanced search method (on the right). Hence the name of this pattern:
Parallel Architecture. You may have seen this similar approach used in other apps like Yelp,
ThirstyPocket, Booking.com and many others. It is a great approach to gracefully incorporating
nearby results obtained using on-board mobile GPS while making the entire inventory fully available.
In our testing, the Parallel Architecture sticky notes prototype provided a much better finding
experience than the current TripAdvisor Android app shown above. But dont take my word for it:
take 30 minutes to create your own sticky note prototype and test it for yourself. As Eckhart Tolle said
in the Power of Now: Try it, and you will be the evidence. (http://bit.ly/1dppnow).

14. How do I design for Android Material Design?

The $1 Prototype methodology is perfect for prototyping Android Material Designs. In fact, as you
can see below, according to Googles official video titled Google I/O 2014 - Material design:
Structure and components, Google designers came up with the Material Design principles using paper
prototyping methodology that at its core, is very similar to $1 Prototype (http://bit.ly/1dpmaterial):

We spent a lot of time actually cutting out pieces of paper, and layering them and moving
them, till we came up, within this [Material Design] system with views that made sense. I really got
to hone my scissors and glue skills working on this project. We even used little wooden disks to
track the floating action button Playing with paper is just a great practice for getting a sense of how
this design system works. It really gives you a feel of how the surfaces will interact with each other
shuffling the paper around physically helps you understand [various interactions] very quickly. Its
really fast, really cheap, and a kind of fun way of designing Rich Fulcher, Senior UI Designer at
Google.
Now in my own prototyping and user testing, I often find myself fresh-out of wooden disks, so
instead I tend to use pre-formed round stickers such as these Removable Color Coding Labels from
Avery (http://bit.ly/1dproundstickies) to simulate FAB (Floating Action Button), one of the signature
features of Material Design:

These round stickers usually work great, but if you have to move them around a lot, you may
find that some brands are a bit too sticky. This is usually easy to fix: just stick the disk to your shirt or
pants a few times until it picks up some lint. The resulting disk can now be moved around easily and
has a pleasant, raised appearance that helps add a natural drop shadow and enforce the Material
Designs mental model of FAB always being on top of the interface stack. (And as a bonus your
clothes are now a bit more lint-free! Hurray!)
Other than simulating the new FAB with a circular sticky note, there is little else you need to do
differently to create Material Design prototypes using the $1 Prototype methodology. Of course, if you
wish, you may create layers by cutting up colored sticky notes (as I did below to show you an
example of prototyping layers). In most of my design work, I rarely have to use separate layers,
unless I am specifically aiming to prototype and test the interaction between various layers (see
Question #21: How do I Test Material Design Transitions? in Part 3 of this book for more details
on how to test complex transitions).
Beware spending so much time creating your prototype that you fall in love with its design: the
prototype exists only to test one particular design direction, nothing more. Remember: the fidelity
of the prototype should reflect the level of completion of your design. If youre at the step that still
requires you to fix your Information Architecture and content, it may be too early to worry about
interface layer transitions. Spend your design time wisely to maximize brainstorming various design
directions and testing them with real customers. Minimize the documentationincluding needless
prototype beautification to avoid what Timothy Ferriss wisely calls W4W (Work for Works

sake) in his book Four Hour Work Week (http://bit.ly/1dp4hrww).

In my workshops, often the greatest challenge for designers is converting their existing Android
designs to the new Material Design approachmaking the interface both simpler and more visually
rich than their corresponding Android 4.x designs, as well as laying out the happy path for the
customers (using FAB as one of the tools). The following sticky note wireframes demonstrate my
quick take on converting the Android 4.x TripAdvisor app into Material Design. Be sure to compare
and contrast Material Design wireframes below with the Android 4.x redesign wireframes covered in
previous question.
1) Homescreen
In accordance with Googles Material Design principles, I designed the first screen to be much more
visually appealing. In particular, I replaced the List of Links pattern currently used by TripAdvisor
with the 2-D More Like This design pattern, which shows the pictures of nearby attractions,
restaurants, and hotels in several image carousels positioned as scrollable rows on the screen.
Netflix, Gowala, Amazon, and many other mobile apps and websites use the 2-D More Like This
design pattern to showcase visual content, because it helps the app to tell the story directly (instead of
telling searchers about the story with a List of Links, the way the current TripAdvisor app does). See
my Android Design Patterns: Interaction Design Solutions for Developers (http://bit.ly/1dpadp) for
descriptions of 2-D More Like This, and 70 more design patterns.

In addition to the new design pattern, note that the naming convention for the screen is drastically
simplified per Material Design guidelines, removing the filter strip element, launch icon, and any
explicit branding in favor of using Near Me as the screen title itself. This simplifies the interface
and navigation, allowing the content to shine.

Do I need a FAB?
You may have noticed that the homescreen did not include a FAB (Floating Action Button), a
signature new element of Material Design. Should you have included a FAB? Google guidelines say
that to include a FAB, the function it calls should reflect the zeitgeist of the app. For TripAdvisor,
which relies so heavily on customer reviews for their content, the spirit of the app could be
something like Write a Review function. The picture below shows what a homescreen with a
Write a Review FAB may look like when prototyped using sticky notes:

However, before we celebrate the FABulous cleverness of us (http://bit.ly/1dpclevernessofme),

it pays to think through what would happen if the customer were to tap the FAB buttonthat is, to
walk through the flow of creating a new review from the homescreen. If you do, you may realize that

its much more natural to create a review once you have found the object youll be writing about,
and that starting a review from the homescreen is not, in fact, even close to ideal. If you tap the Write
a Review FAB on the homepage, the first step of the workflow would be searchnot the most
satisfying scenario, and not likely what your customers would expect. Remember that while FAB is a
powerful new feature of Material Design, not every screen needs or deserves a FAB. In this case, I
would emphatically recommend not including a FAB on the homescreen.

The homescreen now serves two functions: first, it explains the IA structure of the app at a glance,
and second, it helpfully lists the nearby points of interest (restaurants, hotels and attractions, etc.).
This design basically all but eliminates the first tap, creating a convenient, visual Browse Nearby
screen. Of course, in a city like New York, you may be within walking distance of hundreds of hotels
and thousands of restaurants, so a 2-D More Like This carousel (that can comfortably show only
about 8-12 results on a full-size mobile device) would present a rather limited number of options. We
need to provide an additional way for people to access the bulk of the results, beyond 80-100 that can
be shown on the homescreen. Time to dig deeper with the category search results.
2) Category search results
The 2-D More Like This pattern makes it easy for your customers to transition from visual browse to
search results by tapping the See All placeholder at the end of the carousel. This link navigates to
the search results in a particular category. Alternatively, tapping the title of the row also navigates to
the same place:

The category search results screen could look something like the sticky notes prototype shown
below:

Note the filter overlay: it is rendered as a bright-colored teaser layer on top of the search results.
Many of the students in my workshops asked me whether this is something people can discover on
their own. Good question! Per Google Material Design guidelines (http://bit.ly/1dpmat), you do not
need any identifying icon on this layerthe z-depth of the layer and its color alone should be enough
of an indication to point it out to customers as an interactive element. So far that concept seems to
workI did not see any issues in our testing with sticky notes. However, it never hurts to launch the
filter overlay in an open position to draw attention to this element, at least the first one or two times
the searchers use the app.
As I already mentioned, the whole idea behind using the $1 Prototype methodology is to be able to
experiment rapidly with various design approaches. One alternative design worth trying might be to
surface the various sort options (Nearest, Best, Cheapest) and a map as tabs on a secondary toolbar.
This alternative design fits well with the Material Designs directive of exposing more happy path
functionality to the customer with additional toolbars:

Depending on the design, either the app bar or the additional toolbar (or both) can fold up and
disappear when the searcher scrolls the screen. Alternatively, one or both bars can remain glued to
the top of the screen. My recommended behavior in this case would be to hide both bars when the
customer starts to scroll the search results page down, and bring them back the moment the searcher
tries to scroll the screen upward. Early in the design process, this can be an excellent point to probe
with your potential customers to get their opinions on the subject (See Part 3: Test, for more on asking
non-leading questions).
Get real. Note the real icons I used in my tab bar. Although these icons are very crude, they
allow you to probe whether the meaning behind the icon conveys the intended information. For
example, should we use a different icon for a map? Is Near Me better as a compass needle icon?
Does the star clash with the circles we use for rating in the results page? Should we drop icons
altogether and use text instead? In your prototype, always use real content, including icons, whenever
you can. This will yield a great deal more information from your tests and maximize your
effectiveness.
Later in your design process, if you do decide to go with the tabs option and successfully nail
down the rest of the design on this page, you may wish to create a couple of different wireframes to
test various transition designs against actual customer behaviors. As we are using separate colored
strips of paper for the app bar and tabs, testing various transition behaviors is pretty straightforward.

(See Question #21: How do I Test Material Design Transitions? in Part 3 of this book for more
details on how to test the hide-away elements).
3) Keyword search
As I described in the previous question, another way to access search results would be from the
search icon on the app bar on the homescreen, which launches a dedicated keyword search screen.
Just as we did in the Android 4.x redesign, we can again launch this dedicated search query screen
showing recent search history and then add auto-suggest terms on another layer as soon as the
customer begins to type:

4) Putting it all together

In summary, here are the four screens of the Parallel Architecture design pattern. Note that you can
access the same Hotels search results by browsing a Hotels category from the homescreen or by
searching using the Hotels keyword query from the search screen:

Note that on the four sticky notes shown above I made some minor variations in the treatment of the

search box. This minor change could be a big dealit translates into treating search as a leaf-node
(with a back arrow, left side) vs. launching search as a modal window (with a close X button, right
side). While most customers might not notice this, some will, and you can always point out this
difference and ask questions to squeeze even more data out of your prototype.
We could have designed the app in many different ways, using over a dozen different design
patterns. For example, the content categories (along with an additional way to access search) could
have been located in the drawer, or tabs on the second screen could have been category filters
(instead of the sort order and map options) to name just a couple of possibilities. Using sticky notes,
you can rapidly design and test a variety of UI approaches and figure out what works best for your
customers before you make a substantial commitment to code and release your app. This is as true for
Google Material Design as it is for Apple iOS8 or any of the other mobile platformsthats what
makes the $1 Prototype methodology so powerful.

15. How do I design for iOS8?

While the signature feature of Android Material Design (described in the previous section) is layers
of digital paper, this concept is by no means a new one. Months before Google came out with
Material Design, Apples iOS7 already took advantage of various layers in their apps. In the case of
iOS however, the layers are opaque, so you can almost (but not quite) see the content in the layer
underneath. In the memorable words of Colette Crosby, Director of the App Stores Channel Team at
Intuit, Inc., its a bit like looking at a fresh Thai eggroll: you can almost see the shrimp and cilantro
inside the roll, but not quite.
In other words, opaque layers of iOS7/iOS8 do not add much in information from the layer under it
they only signal to the customer that he is looking at a screen with multiple layers. The good
news is that the opaque nature of the app and tab bars can be pretty much ignored when prototyping
iOS8 apps. The same general guidelines we discussed in Question #14: How do I design for
Android Material Design?, also apply to building effective iOS8 prototypes: various layers can be
ignored unless youre planning to test complex transitions.
Heres an example of the prototype of the Amazon app executed using iOS6 design principles, and
then the same Amazon app again updated for the iOS8. Note that in the iOS6 design its pretty
straightforward to identify the entry fields due to skeuomorphic elements: rounded corners on the text
fields, additional drop shadows and bevels that make various design elements pop off the page:

When creating the sticky note wireframes for iOS6 (which has a fair bit of skeuomorphism), you
can take full advantage of these graphical elements to bring life to your screen, and make it easy for
your customers to identify interactive elements such as text fields and buttons:

Now compare the iOS6 design with the iOS8 design show below. Note the general lack of
skeuomorphism in rendering the on-screen elements: text fields are now simple gray lines, not so very
different from lines that separate search results from each other. Now that a big part of the design
vocabulary has been removed, both the designer and the customer are forced to work harder to
identify various interactive elements to successfully connect human with the machine:

The same challenges of reliably communicating the interactive elements that are present in the
native iOS8 apps, are also present when designing and testing iOS8 prototypes created using sticky
notes. Note how little differentiation there is between interactive and informational on-screen
elements, especially on the homescreen:

Because of low differentiation, we sometimes have to use different color pens instead of pencil to
draw the iOS8 prototypes. As long as you keep this in mind, there is nothing particularly complicated
about using sticky note prototypes for iOS8the $1 Prototype methodology works pretty much the
same regardless of the quirks of the individual mobile OS. In fact, the way your iOS8 sticky note
prototypes behave in testing is highly indicative of the issues your customers are likely to have
when interacting with the finished native iOS8 app. For example, if some interactive element on the
screen requires extra differentiation when tested with sticky notes, be sure to also give it extra
differentiation in the finished product!

16. How do I use $1 Prototype to design responsive websites?

It should come as no surprise that, in my opinion, the best place to start your responsive web design
process is mobile first, that is using a version of the site that runs on a full-size mobile device. This
can be quickly and easily done with sticky notes using the $1 Prototype methodology. Once you figure
out what works, you can scale the design to larger form factors, like the 7-inch tablet and/or 9-10inch tablet, using the appropriately sized sticky notes, and build on the mobile design you perfected.
While the detailed discussion of RWD is beyond the scope of this book, you may want to check out
Luke Wroblewskis excellent book Mobile First (http://bit.ly/1dpmob1st) as well as Ethan
Marcottes seminal Responsive Web Design (http://bit.ly/1dprwd). Smashing Medias Mobile Book
(http://bit.ly/1dpmobsmash) is an excellent resource as wellits a compendium of the latest RWD
best practices from the best and brightest minds in the business of mobile design and development. Be
sure to get the complete book together with Smashing Addendum, which can be found here
(http://bit.ly/1dpmobsmasha)sometimes they go on sale together as a package (disclaimer: I cowrote the chapter on mobile UX strategy).
To briefly demonstrate a few simple RWD mobile design principles, Ill use the Kershaw website
(http://kershaw.kaiusaltd.com), which sells high-end knives and tools. Note that when rendered on the
full-size mobile device, the website uses a drawer element (on the left) to show the content categories
and provides a variety of excellent browse tools like sorting (on the right):

When it comes to rendering responsive websites using the sticky notes prototype, there are few
differences between that and designing a native app as I described in detail above. The devil is of
course in the details. For example, in my workshops, people often struggle with how to render the
drawer, unable to decide between these two options:
A) Pushover: the drawer is layer that pushes the screen content to the right.
B) Overlay: the drawer renders on top of the screen content as another layer (much like a
Material Design drawer).

Which drawer design is better? Actually, it doesnt seem to matter that much; in our testing the
difference between the two types of drawer designs was negligible. Thus I strongly recommend
going with the Material Design layer that renders on top of the screen (even though the original
Kershaw website renders a drawer that pushes the content over). Why? Because of the ease of
creating and testing the prototype, modular nature of the sticky notes components used in creating an
overlay drawer prototype, and overall speed and convenience of prototyping.
Heres how the sticky notes $1 Prototype for the Kershaw website might look when using an
overlay style drawer and sort popover. Note that the entire sequence below was drawn in less than
five minutes, because there is only a single content pane repeated three times. The rest of this
wireframe set is created by using simple overlays on top of that single content page:

This sticky notes prototype can be used to figure out the exact categories that need to go in the
drawer, content on the screen, information architecture, icons, transitions, and so forth. You can use
similar sticky note prototypes to test various alternative designs: for example exposing categories in a
drop-down or as tabs on top of the screen.
Once the basics have been nailed down, you can move on to modeling the same screen on a midsize seven inch tablet. The design of the page for vertical tablet orientation is much the same as that
of the mobile screen (so we will not provide it here). But when the tablet is rotated into horizontal
orientation, the screen rearranges nicely to replace the drawer element with an open horizontal menu.
Items are arranged in the grid and sort options are shown in a popover:

This is how this screen looks when prototyped using a slightly larger 6x4 inch sticky note
(available from Amazon.com , http://bit.ly/1dp7inch and many other office supply stores):

You can follow the same process for the larger, full size nine- or ten-inch tablets, using a paper
pad or an appropriately sized giant sticky note. Regardless of screen size, the $1 Prototype
methodology lets you perform quick and simple experiments with various content elements, sections
and dynamic layers, helping your responsive web designs succeed on any device and platform.

Now that weve created our prototypes, its time to test them with the potential customers. While
this is usually pretty straightforward, it takes a bit of practice. Part 3 of this book will help you get the
most out of your interaction with your participants and avoid potential pitfalls, enabling you to
connect with people easier and iterate your design faster and with more confidence.

Part 3
Testing
Now that you have your $1 Prototype, its time to put it in front of some test pilots. In this section,
we explain how to quickly and cheaply test your sticky notes prototype at your local coffee shop,
using effective guerrilla testing strategies. Youll also learn how to ask non-leading questions and
iterate in the field to get the most out of Rapid Iterative Testing and Evaluation (RITE) methodology.

17. Are you saying dont do any usability testing?

No. Quite the opposite! As Steve Krug said in his book Dont Make Me Think
(http://bit.ly/1dpdmmt3):
Most people think usability tests are expensive, time consuming, and hard to do. In fact... I
know from years of experience that valuable, effective usability tests can be done quickly and easily,
with little or no cost. And I believe strongly that everyone... canand shouldbe doing their own
testing.
Unfortunately, the reality is that for many large companies, usability testing has become a
formality, a checkmark on a list of project activities. And while usability tests are very useful (and
its always better late than never), high-definition usability tests late in the project do not fulfill the
original promise of UX design, nor represent the optimal use of teams resources, particularly for
mobile projects.
Instead, I find it more useful to think of usability testing as the platform on which your team runs
the entire project. In a sense, that means you no longer view usability testing as a separate activity or
task. In fact, you and your team always have the prototype of the experience in hand and are always
testing it with customers, acquaintances, and within the team. When viewed this way, satisfying
customer goals becomes the projects core, and continuous testing becomes one of the core activities
that continuously ensures that the team stays on the right track.
The $1 Prototype methodology makes usability testing accessible to anyone, at every company, no
matter the size. Whether you use Agile methods, are transitioning from Waterfall to Agile, or use some
other project methodology, you can use the $1 Prototype concepts to quickly prototype and test an
idea to add value at any point in the development process. Pretty much anyone who can draw a box,
can use a pack of sticky notes to create a basic workflow of three to four wireframes, then step
outside their office building at lunch to test it out with real people. All it takes is some basic drawing
skills, some empathy and about thirty minutes of your time. (You may also need a few licks from the
magical dish labeled Courage, but you have to get those in the Land of Oz (http://bit.ly/adpoz) at the
end of the Yellow Brick Road). The book youre holding in your hands is the ultimate end of all
excuses not to do usability testing for your product and to continue inflicting pain and suffering on
people that try to use your software. Its as simple as that!

18. When and where should I do my usability testing?

I always encourage my students and clients to find the exact representative of their target audience to
achieve the best results for their usability testing. Thats the ideal scenario, and for some
applications, such as doing brain surgery, you might want to find the person actually certified by the
American Association of Neurological Surgeons to drill into your skull. Those situations are quite
rare, however. The vast majority of almost two million apps in Apple App Store and Android Play
Store do not require prerequisite knowledge brain surgery to use and enjoy.
As Douglas Adams wrote in The Restaurant at the End of the Universe (http://bit.ly/1dpreofu)
we are now in the Sophistication stage of our Galactic Civilization, which means most of the
questions we ask our smart phones are akin to Where shall we have lunch? Thats not to say you
can afford be sloppy about the answerthe very nature of the questions we ask demands answers of
poise and elegance!
The History of every major Galactic Civilization tends to pass through three distinct and
recognizable phases, those of Survival, Inquiry and Sophistication, otherwise known as the How,
Why, and Where phases. For instance, the first phase is characterized by the question 'How can we
eat?' the second by the question 'Why do we eat?' and the third by the question 'Where shall we have
lunch? (Douglas Adams, The Restaurant at the End of the Universe, http://bit.ly/1dpreofu)
This increased sophistication is great news. It means that for your usability testing, you can use
anyone who is able, at some point in their life, to imagine asking their mobile device the questions
your product or service is designed to answer. Most apps dont require skills outside of the usual
80% of the mobile activities performed by a typical person living in any relatively wealthy country in
the 21st century. Activities similar to checking and responding to email, checking bank balance and
recent transactions, sending and receiving messages, checking social media updates, buying stuff
online, etc.
To put this in the Galactic perspective, most of our mobile activities involve messaging friends to
decide where to have lunch, booking a restaurant reservation, and helping everyone get there and find
parking (hopefully sometime before the Universe ends).
Bottom Line: while some mobile projects doubtless demand rigor and full compliance with
a predetermined set of selection criteria for their evaluators, the majority of the mobile design
projects youre likely to be involved with can be profitably tested by someone with a mobile phone
in line at a coffee shop.
Coffee shops during the morning rush make ideal places to test your mobile flows. Theyre full of
people who are bored, impatient, and have no better place to go. And people who are in their natural
decaffeinated statelow on patience, attention, good manners and tolerance for bad designmake
awesome testers. This means you better be prepared to get some very honest feedback. If something
doesnt work or doesnt make sense in your application, decaffeinated people will usually tell you the
whole truth and nothing but the truth (so help them God).
Lack of caffeine helps people cut through the bullshit front of politeness most people put up when
they dont like something. (In a way, during the morning coffee rush everyone is a bona-fide New
Yorker.) As an added bonus, there is a time constraint: if an average person is unable to complete
your flow by the time they reach the counter (four to seven minutes), your flow might be too long and

you might want to consider a different design (or at least find a more upscale coffee house with longer
lines).
Ultimately, if you have thick skin, this method of coffee shop testing considerably shortens the
process of getting honest feedback about your prototype, which allows you and your team to iterate
quickly and effectively. If you have a big ego, I simply cant recommend this method enoughit was
highly therapeutic for me in my own work and essential to my spiritual growth.
Most of the time, curious and bored people will look at your prototype for free, while their friends
and other people in line offer helpful and often instructive (and humorous) commentary. But if your
flow is longer than one to two minutes, you may want to offer to buy their morning coffee fix as a
token gesture of appreciation for their time and priceless attention.
All you have to do is approach some fortunate person in the back of the line and ask, can you test
my mobile app prototype? while thrusting the pack of sticky notes toward her and simultaneously
making your best Puss in Boots cute eyes impression (http://bit.ly/1dpcutei). Most people will be
naturally curious, having never seen anything quite like this object youre thrusting toward them, and
will be intrigued by the hand-made look of your prototype. Once they take it, simply say Just pretend
this is your phone... and youre off to the races. (Well discuss how to ask non-leading questions
later in the book). If they hesitate, you can offer a helpful Ill buy your coffee todayand youre not
doing much at the moment anyway. Sure, a few people will reject your attentionsthat is inevitable!
Be persistent, polite and patient. And dont forget those cute eyes!
I always try to tip before receiving a serviceit makes the service that much better. So I
sometimes show off my bribe by putting the $5 coffee card (or free coffee drink coupon) right on top
of the prototype while I walk around the shop. Most people are honest and will try their best to help
you if you pay them upfront. Ive never seen someone take the payment and not offer some useful
feedback.
Last but not leastdont forget to tip the students behind the counter! If you plan to do a lot of
testing in a strange coffee shop where no one knows you, be a mensch and give them a $10 tip when
you buy your coffee cards or free drink coupons. You dont have to tell them what youre up to, as the
employees might have a policy specifically prohibiting your behavior. But as long as youre not
bothering people unduly, and do your testing somewhat quietly and under the radar, most decent
coffee places will let you slide. After all, youre just talking to people!
Morning coffee line is my personal preferred method of testing mobile ideas quickly and cheaply.
If you get to the coffee shop early enough, you can easily put your prototype in front of 15-20 people
in a single morning, with plenty of breaks to fix your prototype, brainstorm other ideas with your
teammates, check your messages and enjoy a cup or two of expertly prepared caffeinated bliss. In a
space of a few hours (and for a price tag of about $20-40) youll accomplish the equivalent of months
of typical recruiting, prototyping, usability testing and design work!
Coffee shop is not the only place to test your prototype. As the Go Fetch! case study (in the sidebar
below) demonstrates, there are many excellent ways to escape the cubicle land and find free-range
customers with real connection to your app. All you have to do is use your imagination.

Go Fetch!
Go Fetch! is an app designed by students in my Advanced Mobile UX course at SFSU using the $1
Prototype methodology. The app allows dog people new to the area to find dog-friendly parks,
purchase essential supplies, and even make new friends:

The team decided early-on that part of the appeal was dog-themed graphics and a fun, social
element provided by app. This is reflected by the early versions of the homescreen, which uses the
List of Links pattern to model and test various navigation options with dog-loving potential
customers:

To find people who really cared about dogs and to model a realistic use case the team elected to
test the app in the neighborhood dog walking park (instead of the coffee shop). The $1 Prototype
methodology made this easy. The final set of wireframes further enhanced the fun, dog-themed
graphics, while also adding useful and secondary refinement options of particular interest to dog
walkers, such as a distance off leash filter, maps, and photo profiles:

Detail View shown below included interesting dog-themed interface elements such as a pawprint menu that allowed access to additional social features of the app, e.g., park reviews.
Surprisingly, this feature tested very well with mobile-friendly urban dog owners, who could figure

out to tap it, especially after it was shown open as a watermark/coachmark (see my Android Design
Patterns: Interaction Design Solutions for Developers (http://bit.ly/1dpadp) for descriptions of
Watermark and 70 more design patterns):

19. What are the best practices for testing using sticky note wireframes?
There is no right or wrong way to test sticky note prototypes, simply techniques that work or dont
work for your particular project. The tips below should be enough to get you started.
1) Use the Adding method
There are really two basic ways to do sticky notes testing:
A) Removing: Stack all the stickies in the order you expect the evaluator to go through the flow,
and when she taps a button, peel off the top sticky note to expose the next one underneath.
B) Adding: Hand the evaluator only the homescreen (on top of a thick empty stack of stickies),
and add all the next screens on top of the homescreen when she taps the appropriate button.
The second method is vastly superior, because it allows you to gracefully take the evaluator to
her goal using a variety of potential paths (referred to as prototype branching) together with testing
interface transitions.
2) Branch your Prototype
Branching refers to your prototypes ability to handle multiple paths to the same goal. For example, if
the goal of the test is to buy a book, the evaluator can alternatively search for the book or browse for
it. If youre using the adding method of testing, your prototype can gracefully support any number of
paths. Observe what the evaluator does naturally, then give her the appropriate sticky after she choses
some action. Did she click on the search button? Great, heres the search screen. Did she open the
drawer and select a Books category? Great, slide the drawer sticky on top of the prototype, observe
her tap Books, then remove the drawer sticky (you might need it later) and give her the wireframe
for the Books category landing page.
What if the evaluator happens to tap a button that wasnt part of your planned flow? No problem
simply ask her what she expected to see. If you have time, you can even do a brief sketch of the
missing screen in direct collaboration with the evaluator. Once you have the wireframe for this new
screen, you can add it to your library. Now youre ready to use it should the next evaluator decide
to go down that same path!
This ability to grow your prototype organically in the field in direct response to evaluator
feedback is one of the chief benefits of using the $1 Prototype methodology. Its the reason I
encourage all my students and clients to spend as little time as possible in the office and get out
there as soon as you finish just three or four sticky note wireframes. What youll be able to find and
build in the field as a team, with direct consumer feedback and strong coffee, will be vastly
superior to anything you can produce during three-hour shouting matches in the isolation of the
cubicle land.
3) Show and Test Transitions
Testing using the Adding method gives you a great variety of options when it comes to transitions.
You can demonstrate almost any transition mode by using the appropriate motion when adding the next
sticky note to the pack that the evaluator holds in her hand. For example, while going deeper into
the information architecture of the app, the next screen typically slides in from right to left.
To test this transition, simply say something along the following lines of: When you do X, the next
screen slides in from the right side like so... while simultaneously demonstrating the motion by
taking the next sticky note wireframe and sliding it in from the right to affix it on top of the stack of

sticky notes already in the evaluators hand. The physicality of the paper prototype makes it easy to
compare several transitions. Right after you show the first transition, say, or instead the next screen
can [come up from the bottom/flip over/bend in half, etc.] like so... which one would you prefer?
You may have to demonstrate each motion several times.
4) Organize your wireframe library with care
With the Adding method Im recommending, your prototype can potentially support near-infinite
number of workflows, and a prototype consisting of 20-30 screens is not entirely out of the question.
How do you manage that big of a sticky notes library? One solution that works well for us is to put the
stickies into a three-ring binder you can bring along with you into the field. Binders in larger sizes
such as legal (8.5x14 inches) or larger art portfolio binders work well.
Stickies corresponding to each of the flows can be affixed to the separate pages in the binder and
various versions of the flows can be kept under different tabs. The binder will keep the stickies clean,
neat and straight in your field bag, thereby preserving the all-important adhesive strip.
Its best to have a helpera separate person who can hold and manage the sticky notes library
binder, while you interview the participant. The helper should be ready to hand you the appropriate
sticky note from the library the instant the participant taps the button, while youre still busy asking
follow up questions and otherwise interacting with the participant. Obviously, to be effective, the
helper needs to be well versed in the design youre testing. Its a great job for people like product
managers, engineers, QA testers, and anyone else who has not been out in the field as much and is not
as familiar with the prototype, as it will force this person to learn the design quickly. After testing
two or three participants, the helper is likely to know the design better than everyone else on the
team!

Regardless of how prepared you think you feel, realize there is simply no substitute for jumping in
and doing the work yourself. Remember, you cant outsource user testing any more than you can
outsource a Parrilla dinner with a few bottles of Mendoza wine split among friends
(http://bit.ly/1dpparr). You have to play the game to realize the benefit. See the $1 Prototype Play List
on YouTube for lots of video examples of real people testing their sticky note prototypes:
http://bit.ly/1dppl1.

20. How do I ask non-leading questions?

Observing and interviewing people who use your prototype is a huge part of the $1 Prototype
methodology and good grasp of the basic user-testing principles is essential. I recommend starting
with the highly accessible Rocket Surgery Made Easy by the incomparable Steve Krug
(http://bit.ly/1dprocket), as well as studying the classic text Observing the User Experience by
Elizabeth Goodman and Mike Kuniavsky (http://bit.ly/1dpobserve), especially if youre planning to
become a serious UXer. While youre waiting for those books to arrive, here are a few guidelines to
help get you started in the right direction.
1) Focus on human connection
Interviewing is a lot like Aikidoit only looks easy if youve never tried it. There is a reason why
professional interviewers like Oprah Winfrey and Barbara Walters are some of the best-known and
respected people on television. Interviewing is serious work that requires homework, dedication,
and lots of practice.
While interviewing is simple, it is by no means easy. Give yourself plenty of space to fail, again
and again. And again. Remember, the important thing is your rapport with the participantyour
human connection and your empathy. When I tried to interview people at the start of my UX career 15
years ago, I looked like the Incredible Hulk practicing Ikebana. But I persisted, and I got better, to the
point that I now feel comfortable enough to write a book about it! Anyone can acquire the skill of
participant interviewing and everyone without exception can get better with practice.
And another thing: there is no magic in your prototype or in your questions. They are just tools
for human connection. As the old shaman from the movie Medicine Man (starting Sean Connery,
Hollywood Pictures, 1992) says No ju-ju in sky flower... only house for bugs.
(http://bit.ly/1dpmed). The user testing activity is just a conduit to help pass the knowledge between
you and this other human being in order to facilitate their use of your technology to help them solve
their problem, grow, and achieve their full potential in the world.
You are communicating (being in communion) in order to understand (under-stand literally
stand below), to connect to and to serve the spark of divinity in another person. Once you learn to
approach user testing as human connection first and everything else second, the entire process falls
into place. The rest is just mechanics that will get better with practice.
2) Have an ice tea on the sunny porch
One of the hardest skills to acquire is simply letting your participants fail, be confused and helplessly
flail about. I call this having an ice tea on the sunny porch. Even when your product is perfect, some
people may not get it. And if were talking about one of your early designs, moments of confusion and
frustration are virtually guaranteed. In fact, moments of confusion and frustration are exactly what
we are looking for when we conduct user testingtheyre the shimmering splendid magic pots of
gold that help us make our product better!
For normal human beings, however, these moments of pain and friction can be difficult to
experience calmly. We tend to empathize with peoples pain because we, the researchers, put them in
this painful situation in the first place. Most peoples first reflex is to ease this pain quickly by
explaining to the participants what the screen means and pointing out what to push next. Dont do this!
While this desire is understandable and even laudable (it means, basically, that youre not a
sociopath) its also unfortunate, because by not letting your participants struggle, youre not really
learning what they do when interacting with the interface when youre not there. In other words, you

are wasting everyones time, including theirs.

Do your job: explain the task to the participants in as few words as possible, then sit back on that
sunny porch and sip your ice tea. Let them figure out how to do the task on their own using your
interface. Just relax and watch carefully. Dont give participants any hints unless they become
completely stuck, and even then give as little information as possible. Remember, youre not there to
help that particular participant, but to transform the base metal of their suffering into a pure gold elixir
of a technical solution to a larger design challenge in order to better the world at large. So shut up and
sip that tea!
3) Answer questions with questions
Participant interviews get particularly challenging when participants express their confusion in the
form of the question, for example, What do I do next? or What is this thing here? Again, many
beginning user researchers get caught in the trap of politeness, and actually answer the question,
thereby leading the participant.
Its impolite and socially awkward to ignore other peoples questions, so you must be ready to
answer every question from a participant with a question of your own. For example, a question like
What do I do next? can be answered with a standard response: What do you think? An even more
effective response is to refocus the participant on the task at hand by emphasizing action and
doing with an answer such as: What would you do if I wasnt here? Note the subtle emphasis on
the word doits part of the interviewers verbal ninjitsu that helps guide the participant in the
desired direction. Because what people actually do is much more valuable than what they say or
think.
4) Watch what they do first, then ask valuable questions
If I got a dollar for every time I heard I dont like this gray color Id be... just a little richer. In fact
this fixation on irrelevant details (such as color) of early versions of digital prototypes is what led me
to create the $1 Prototype methodology. If you follow the guidelines I lay down in this book, the level
of completion of your prototype will accurately reflect the level of completion of your project. In
other words youre less likely to get comments about color while youre still trying to nail your IA.
Regardless of the project phase, what your participants do during the test will always be much
more valuable than what they say. Thats because behavioral data is highly consistent. In other
words, different people tend to behave in similar ways when faced with the same set of inputs. If one
participant is confused about the screen, chances are that thousands of other people of the similar age,
gender, experience and education will likewise be confused about the same screen. This is the feature
that makes usability testing worthwhile.
On the other hand, what participants say is often a matter of opinion. And as the clich goes,
opinions are like cell phoneseverybody has one. Fortunately, there are subtle ways to guide the
discussion to more valuable questions. For example, a statement such as I like this app is great for
boosting your ego, but carries almost no weight, because its pure speculation. We dont know if the
person will want to download the app, pay for it, or use it if they do download it. So instead, ask
questions focused on potentially significant actions that will help reveal crucial behavioral
information. Here is a typical process:
Moderator: How was your experience?
Participant: It was easy. I liked it.

Moderator: Thats great. Do you see yourself using this app?

Participant: Yes.
Moderator: In what situation?
Participant: When I want to get a great price for something.
Moderator: Like what exactly?
Participant: An iPod.
Moderator: Did you have that happen recently? If so, when?
Participant: Not yet, Im shopping now.
Moderator: Oh yeah? What have you done so far?
Participant: I looked at prices on Amazon.com
Moderator: Great. And if you were to use this app...?
Participant: Id use it to check prices after I check Amazon
Moderator: Have you ever checked prices anywhere else after checking Amazon? If so, when was
the last time? What were you shopping for?
Participant: Last time was a month ago, I was buying a car.
Moderator: Imagine that you had this app a month ago. Would you have done anything different?
Participant: Im not sure. Probably not. I dont see this app being useful for car shopping.
Moderator: Could you elaborate?
Participant: The search in the app was just too general. I thought it was only for new items, like
electronics... maybe a camera.
Moderator: Great. Thank you for that feedback. One more question: if this app was in the App
Store/Play Store, would you pay for it? If so, how much?
Participant: Id never pay for it. I might download it if its free.
Moderator: How often would you estimate youd use it?
Participant: Maybe once... Id probably just do my research and then delete it.
As you can see in this typical exchange, the moderator guided the participant into answering some
pretty valuable behavioral questions that revealed serious weakness with the design and business
models. If more than one of my participants had a similar response, I would consider creating
additional search tools and custom experiences for certain categories (car shopping, for example, if
that was important to my client). Id also seriously consider implementing this functionality as a
mobile-friendly website rather than a native app to avoid forcing people to download it.
Particularly valuable mobile user research tool is the magic question, How much would you pay
for this app? Price is a sensitive issue and asking this question often reveals all kinds of useful
details that are hard to get to otherwise. The price question helps you gauge the level of affinity for
your product, and test your business model from a single morning at a coffee shop for about $20
worth of coffee and $1 worth of sticky notes and before writing a single line of code. Thats the true
power of $1 Prototype methodology.
5) Learn to ask non-leading questions
Note how, in the script above, the moderator started out asking fairly general questions, but slowly
ended up with more and more detailed questions, all the while staying just shy of asking any questions
that truly lead a participant. As an interviewer, asking non-leading questions first is a critical skill to
develop and practice. Its also one of the hardest skills to master. Fortunately the concept is fairly
easy to graspall you need is patience and practice to master it.

Leading can be imagined as a scale. Here are some typical questions interviewers might ask,
ranging from a typical format to less leading alternatives:
1) Most leading: Why did you like this app?
2) Leading: Did you like our app?
3) Less leading: Did you like or dislike our app?
4) Best: How was your experience?, How was your experience doing task X?, So what do
you think?, How was it?, Which parts of the experience stood out to you?, etc.
Lets review these questions one at a time:
1) Why did you like this app? There is nothing inherently wrong with this question, unless it is
the very first question you ask at the end of the test. The reason being is that by asking why?
question first, youre already assuming that the participant liked the app. People are then
automatically forced to look for reasons why they liked the app, even though they generally disliked
it. However, if the participant already stated that they liked the app, this is an OK follow up question
(a better version would be Which parts of the experience stood out for you?). Keep the focus away
from opinion like/dislike and on behaviors and actions, e.g. What happened that made you say
that? When? and Which parts of the experience stood out? Thats a clean question. No judgment
there.
2) Did you like our app? This is another brand of leading question; it frankly conveys your
preference to hearing the positive aspects of the experience. Remember ice tea on the porch
youre just testing one particular solution, and arent attached to the outcome in any way.
3) Did you like or dislike our app? These kinds of paired opposites questions became
popular in UX research in recent years, particularly for surveys. Personally, I find this phrasing and
similar paired questions (easy/difficult, short/long, simple/complicated) awkward in the
extreme. In addition, the phrasing and intonation with which the question is asked, can subtly convey
the desire of the interviewer to hear the good news instead of bad. A subtle emphasis on like or a
flatter pronunciation of the opposite word dislike is all the hinting the participant needs to
unconsciously gravitate to the positive aspects of the experience. Coupled with the awkward
phrasing, this makes these questions my tool of last resort.
4) How was your experience? This is an optimal, non-leading way to ask about the overall
experience. Not only are questions of this type non-leading in any way (by avoiding any open
emphasis on the positive or negative) these questions are behavioraltheyre focused on what
happened during the test, not opinions. Best of all, these kinds of questions are holistic and openended. Most people like a thing or two about the experience, while also disliking a few aspects at the
same time. Open-ended questions of the type How was your experience? and What do you think?
easily accommodate both good and bad aspects. Its up to the participant to select salient points to
discuss.
6) Dont be afraid to lead, but know when to move on
When interviewing, clean, non-leading, open-ended questions are optimal. However, sometimes these
questions lead to very generic, useless answers. This can be especially frustrating later in the testing
cycle, when youve heard the same generic answers several times. After interviewing a few
participants and getting the general feel of things, you may wish to push some participants for
specifics.

The important thing is to start with general questions to give the participant a chance to answer on
their own, before leading them to the questions you need answered. Dont start with leading
questions, but if youre not getting what you want, dont be afraid to lead. Heres a typical script that
may play out with participant number five or six:
Moderator: How was your experience?
Participant: It was OK.
Moderator: Care to elaborate?
Participant: Well, I generally liked it.
Moderator: Which parts did you like and for what reason?
Participant: I liked the search.
Moderator: What in particular about the search?
Participant: It was easy.
[OK were clearly not getting what we want here. Time to push a bit...]
Moderator: When you were searching for an iPhone on this screen, I noticed you stopped right here.
What happened?
Participant: Oh, I thought I was supposed to select something.
Moderator: You mean you thought you had to pick a category from this thing here?
Participant: Yes.
Moderator: For what reason did you think you had to pick a category?
Participant: I thought it was going to give me a bunch of unrelated stuff like cases, accessories, that
sort of thing
Moderator: Thank you. Thats super helpful. Anything else?
As you can see, slowly pushing the participant for specifics revealed some useful information.
However, in most cases with such general answers I would give the poor guy his free coffee and send
him on his way, for two reasons:
1) Poor information yield. While the confirmation of behavioral information may have been
valuable, it was already pretty obvious to the attentive moderator that this participant was confused
looking at the category drop-down during his search. Observation alone was enough. The grueling
interview work we did afterwards did not reveal any additional helpful information.
2) Lots of cheap participants available. Walking away is an option we do not often have with
traditional usability testing, because each session represents so much investment into a limited
resource. Each participant travels 30 minutes or more to the usability lab, is scheduled in advance for
two hours, and paid $75 or more for their time. By golly, we better make sure we squeeze everything
we can out for him for the full two hours, and damn the torpedoes!
In contrast, if youre using the $1 Prototype methodology, you can find free-range participants
almost everywhere, and your entire investment is a mere $2-3 for a cup of coffee. In other words, you
have the freedom to let the duds go away in peace, while you find more enthusiastic participants
who will give you useful information. By letting useless participants leave early, youll preserve
your sanity, and your work will be altogether much more enjoyable (not to mention more productive).
The $1 Prototype methodology is about getting the most out of the least amount of work. Know
when and how to lead, if necessary, but realize that leading is hard work. Dont fall into a trap of
thinking you have to keep squeezing a hard, dry lime until your thumbs bleed. Not all relationships are
meant to work out, and letting go is sometimes a more productive alternative to pulling teeth from the

crocodile (which is hard for you and painful for the crocodile).
7) Ask For what reason? instead of Why?
In many schools of usability thought, were taught to ask The Five Whys; that is, to ask why? five
times to get to the bottom of the persons mental model. Unfortunately, when asking the reason for
something, a direct question like why? can sometimes be perceived as confrontational, especially
coming from a male moderator. Even if you ask the question in the most gentle of tones, why?
sometimes has the effect of sounding like How could you do this? You are so stupid! As a result the
evaluator feels like they have to justify themselves or make up a fictional story.
A slighter better version of the why? question is to ask for what reason? While a bit more
awkward, this phrasing ensures that the question comes across as intended: as a non-confrontational
query that shows you really want to know the deeper underlying reason someone did something. In
other words, the evaluator is much more likely to answer with an actual reason, so you will not have
to ask the same question five times.
8) Use only general control names when testing
While reading the previous section, you may have noticed that the moderator fastidiously avoided
using the word drop-down and asked instead You mean you thought you had to pick a category
from this thing here? This is intentional. Most people who work with digital goods and services
carry the Curse of Knowledge (http://bit.ly/1dpcurse).
The good news is that the Curse of Knowledge wont necessarily turn you into a Tech Zombie
(especially now that youre using the $1 Prototype methodology to get out of your cubicle and talk to
some real people.) The bad news is this curse means you now know too much, which means you
cannot relate to what its like to view your product objectively, that is without the benefit of all the
knowledge you already have in your head. (Brains! Brains!)
Normally, we call UI controls by their proper names, such as drop-down, button, checkbox,
text input, SERP, detail page and so forth. While this is helpful for us techie folks to
communicate with each other, proper control names can be intimidating to non-technical people. Even
worse, the proper names frequently convey too much information about the prototype and the tasks
you want the evaluator to accomplish on the particular screen. Thus proper control names are often a
first step on a slippery slope to leading the participant into doing what you want them to do, not what
they would normally do. As a result, I generally advise my students and my clients to completely
avoid calling any and all application elements by their proper, technical names. Instead get used to
using vague terms like this thing here, this element, this part of the screen, and so forth. As a
last resort, you can go literal, calling out this drawing/box/line/circle/triangle, etc.
The same goes for transitions (see Question #19, What are the best practices for testing using
sticky note wireframes?) Instead of using the word transition when explaining things to the
participant, choose to rely on the motion of the stickies and accompany your show-and-tell with vague
non-descriptive words like when you tap here, this happens or the screen moves this way, the
next screen comes sliding in like this, etc. Using non-technical terms like these takes conscious effort
and practice, but along with asking non-leading questions, it is one of the most important ingredients
for successfully identifying issues with your design.

One last point: if you accidentally let your knowledge slip through and call something by its proper
name, dont worry, just keep going like this: While filling out this form you happen to notice this

drop-down here? ergh... I mean while you were on this screen, did you happen to notice this thing
here [point to the drop-down]? What did you think it was? Remember, its the human connection that
matters. If you catch yourself this time, the next time you will not make the same mistake. So Dont
sweat the practice... And its all practice (http://bit.ly/1dpchick). See the $1 Prototype Play List on
YouTube for lots of video examples of real people testing their sticky note prototypes:
http://bit.ly/1dppl1.

21. How do I test Google Material Design Transitions?

While there are a great many useful and interesting Material Design transitions, the three transitions
below (Drawer, FAB to Action Panel and Hide-Away Elements) should be representative of the
typical techniques of testing mobile transitions and should give you a good idea on how to test similar
elements should your project require it.
1) Drawer
Drawer is a basic building block of Android and holds an important place in the Google Material
Design. Fortunately, the Drawer transition is a very easy one in Material Design, because mobile
drawer typically sits on top of the primary on-screen content:

This makes it easy to add a drawer to your prototype: simply cut a 3x5 sticky note to about 80%
width and write whatever menu items are needed in this drawer. Be sure to add realistic icons if
you plan to use them. When the evaluator taps the menu button, say something like: when you do this,
this new panel slides in from the left side... like so, while you simultaneously slip in the drawer
sticky note on top of the stack of wireframes in evaluators hand from the left side. That is all there is
to it.
Once the evaluator looks over the drawer, he can decide to navigate to another area or dismiss the
drawer. In either case, be sure to remove the drawer before proceeding with the next step in the flow
you might need to use your drawer again in a different area of the app, so you want to keep it handy,
not leave it buried under all the other sticky notes.
2) FAB to Action Panel

Heres an example of a fairly straightforward way to test what is arguably the most complex
transition of the Material Design: the FAB conversion to the action panel. I unofficially nicknamed
this transition The Octopus Burst. You can think of the FAB as a kind of cephalopod mollusk that
moves around the screen, sometimes holding onto various layers of the screen, sometimes
swimming independently with or against the scroll or the current on the page.
In this particular transition, tapping this FAB Octopus releases the ink inside it, spilling it onto
the page in the same way a real-life octopus releases a cloud of ink before escaping into the hole in
the rock. This is how the this transition looks step-by-step as shown in the Googles Material design
promotional video on YouTube (http://bit.ly/1dpmatyt):

This transition is quite complex when broken down into component elements (for example, you can
see the FAB moving down before the panel bursts into color). Fortunately, this transition happens
quickly, so the human eye sees mostly that the round button smoothly expands into a panel (in the same
way, from the point of view of a baffled barracuda, the octopus disappears into a cloud of ink).
Turns out that once you understand the purpose of a transition, its fairly easy to simulate it using
the sticky notes prototype. Simply walk the evaluators through the process of the transition explaining
what happens. You can say something like when you tap this button, it expands into this new
element. You can accompany your words by using your other hand to make the bursting motion with
your fingers and paste the new panel on top of the FAB. (Its helpful if your panel is the same color as
the FAB sticky.)
You may have to do this a few times to help the evaluator understand what happens. In this way its
actually pretty easy to do a show-and-tell walk-through of almost any transition. Focus on how the
motion brings about the end state of the transition. You can safely ignore most of the complexity in
the middle. (See the $1 Prototype Play List on YouTube for lots of video examples of testing with
sticky notes: http://bit.ly/1dppl1).
3) Hide-Away Elements
Heres another example: scrolling transitions for hide-away elements. As we saw in Part 2 (see
Question #14, How do I design for Android Material Design?) Material Design offers many new
options for hide-away elements such as search query app bar panel and the tab tool bar when
scrolling long lists. Both of the elements can stay glued to the top of the screen; alternatively, one or
both panels can retract:

How do you know what transition works best for your app? Testing this will require at least two
different screens used to simulate the scrolling, plus a way to create various options. In the example
in Question #14, How do I design for Android Material Design? we used contrasting panels cut
from 3x3 sticky notes to make our job easier. To test this transition, ask the evaluator the following:
imagine that you look at this page and do not see what you are looking for. Whats next?
Note the non-leading nature of the questionideally you want the customers themselves to figure
out that they want to scroll. If theyre stumped, you can push them in the right direction by saying
something like: You get a feeling looking at this page that the desired item is lower on the list.
Finally, if theyre still stumped, simply tell them to go ahead and try scrolling the page to see if you
can find what you want. (Note: this last request is quite leading, so save it as a last resort.)
Regardless, you have now observed the person scrolling the sticky notes prototype. At this point,
working from the bottom of the sticky notes pack screen, slide the new page up and onto the stack of
notes, saying something like when you scroll... this is what happens. Depending on the transition
you are testing, your new page will have two, one or no action bars. Now give the evaluator a second
to absorb the changes and ask: Now how was this experience for you?. Listen carefully to the
response.
To test the hidden panel behavior, you can say something along the lines of: OK youre still not
seeing what youre looking for... is there a way to [go back/change the query/filter/sort/etc.]? In the
case of transition that involves hide-away panels, the evaluator has to figure out how to get the panels
back (usually by scrolling the screen in the opposite direction). When you observe the right gesture,
you can slip just the small function panel sticky note on the stack of notes from the top, simultaneously
saying: when you do that gesture you just did, this element pops down from the top... What do you
think? How was that experience for you? At this point you can do the whole thing again with one,
two or no panels and ask the evaluator to compare and contrast the three versions, state their
preference and comment on the reasons for it by asking for what reason? (See Question #20, How

do I ask non-leading questions? above for more details).

22. What if I already have a product implemented? Can I still use sticky note prototypes for testing?
Absolutely. The process is pretty much the same as testing two versions of the sticky note prototypes
(see previous sections). The main challenge is to ensure that you do a proper A/B test; in other
words, alternate which version you start with to combat the recency bias (tendency to prefer the
product you saw firstsee Thinking, Fast and Slow by Daniel Kahneman, http://bit.ly/1dpfastslow).
To get the best results from your testing, half of your participants should start the test with the
existing live product on a mobile device, followed by evaluating your sticky notes prototype. The
other half of the participants should start with the proposed sticky-notes prototype, followed by the
existing live product. Its best to alternate the two versions constantly throughout the day, so you get a
well-rounded set of insights as both your test technique and your prototype tends to evolve throughout
the day.

Now that weve tested our prototype, its time to integrate the insights from the testing and sell the
new design (and the new $1 Prototype design methodology) to the rest of the team. We learn how to
do that in Collaborate: Part 4 of the book, coming up next.

Part 4
Collaborate
In this section we discuss how the $1 Prototype methodology can be used to immediately enhance
and complement the Agile development process and how to address various organizational
challenges. This section also handles the most common questions and helps you avoid critical pitfalls
when working together, so you and your team get the most out of $1 Prototype methodology.

23. We use Agile development process. Do we still need the $1 Prototype methodology?
Agile methodologies, such as Scrum, are first and foremost software development methodologies.
That means Agile is focused on the most efficient way of producing quality code quickly and has little
built-in room for UX research and design. While many people in the Agile software movement have
made great strides integrating UX into their process (using mind mapping, product canvas and paper
prototyping, and other techniques to capture the needs of the audience), there is no perfect solution,
and many Agile teams still think that the software product itself should be the one and only
deliverable.
Similar to not taking the time to build a solid foundation for the house, it appears that dropping UX
design initially speeds up the project. However, ultimately, lack of UX efforts hurts the final product,
increasing the chance of catastrophic failure. Cracks begin to appear in the walls mid-way through the
project and developers are forced to patch constantly, instead of building the right design from the
get-go.
We need to think about problem solving in terms of efficiency vs. effectiveness: The $1 Prototype
is a perfect match for Agile, combining its very efficient process with the effective UX guidance. The
$1 Prototype process offers the best of both worlds: it takes very little up-front time to get up and
running, and delivers high-quality UX insights very quickly and with minimum extra effort. The short
story below describes a situation that might be familiar to some readers and shows how the $1
Prototype methodology can be used to immediately benefit Agile projects.
The Agile Story
Unless your development team is a team of unicornsdevelopers that are already skilled in UX
design (and such individuals are as rare as... well, unicorns), just jumping into Agile may present the
risk of leaving the UX design out of the loop entirely. As the teams switch from Waterfall to Agile,
designers (with their traditional, heavy, high-definition deliverables) often get squeezed in the middle
between business and development, struggling to meet the ever-increasing expectations.
Observe a Typical Product Team, made up of the Business Person, Designer and Developer:

As our Typical Team works together in a Waterfall development process, the Business Person
gives the Designer some requirements. From these requirements, the Designer creates beautiful
wireframes, which the Developer then codes just right into a well-functioning productin this case, a
truly spectacular game of Tic-Tac-Toe:

In other words, our process is all Rainbows and Pink Unicorns. Now, Ill be the first to admit that
I cant draw Pink Unicorns, so I pulled the Antoine de Saint-Exupry and drew you box containing
some Pink Unicorns below. So, like the Little Prince (http://bit.ly/1dplittleprince), you, the reader, get
to just imagine the Pink Unicorns inside. The holes in the box are so the Unicorns will not suffocate
while you take your time:

That is, our Typical Product Teams Waterfall process is going along swimmingly, until suddenly,
someone at our company comes across an article by an Agile guru like Ken Schwaber
(http://bit.ly/1dpkenschwaber), Fred Brooks (http://bit.ly/1dpfredbrooks), or Robert Martin
(http://bit.ly/1dprobertmartin), who, in a voice like thunder, says: Thou Shall Be Agile!

So as our Typical Product Team is rapidly transformed into a Lean, Mean, Agile Machine
(http://bit.ly/1dpagile). The expectations suddenly change, as the management expects to see software
products delivered in a slightly more aggressive time frame:

Creating perhaps just a wee bit of friction within the team:

The new Agile process sounds great in theory. In practice, our Developer is frequently confused
about what she is building, expecting the design to come from on high from the Designer, just as it
did before.
Designer is now the bottleneck: no matter how many prototypes he churns out, he is forever

behind even before the project starts! Design deliverables are simply taking too long, and Developer
is always asking where are my wireframes?! Finally she gives up and starts making her own design
decisions, making Designers output irrelevant. For Designer, this feels as though he is being slowly
swallowed alive by the Agile Guppy:

Enter $1 Prototype
Has the Agile Story in the previous section ever happened to you or anyone you know? If so, there
is good news: you dont have to do it this way anymore (and even better newsyou dont have to do
it alone!) The $1 Prototype methodology was developed specifically for Agile teams and is a perfect
fit for people busy developing code for mobile and tablet devices. The $1 Prototype methodology
takes next to no time, produces lightweight deliverables, and is able to contribute immediately and
transparently by helping your team build a shared vision and make clear design decisions. So your
entire team can reap the benefits of Agile development methodology without sacrificing the benefits
of UX design and research. Using $1 Prototype methodology, your management can realistically say:

All it takes is adopting three simple techniques described in this book:

1) Enhancing a standard kick-off meeting by including a kick-off design workshop within it, where
you work as a team to define key use cases with vision storyboards.
2) Dropping time-consuming high-definition design deliverables and expensive digital prototypes,
in favor of sticky note prototypes that serve a dual purpose: documenting the designs and providing
ready prototypes for user testing.
3) Replacing standard usability testing with RITE studies using your sticky notes prototype.
Techniques 2 and 3 are described in detail in Part 2 and Part 3 of the book, respectively. The kickoff design workshop is described in detail in the next section.

24. What do you mean replace the kick-off meeting with a kick-off design workshop? Is this just a
fancy name?
No, design workshop is not just a fancy name. Heres how its different from the typical
PowerPoint pitch/Slide Show kick-off meeting.
A) Typical PowerPoint Pitch Kick-off
As Edward Tufte famously quipped in Pitching Out Corrupts Within: Power corrupts, but
PowerPoint corrupts absolutely (http://bit.ly/1dpppt). In a typical kick-off meeting (pictured below)
the team is not particularly engaged. As the Business Person stands in front of the project team
delivering her PowerPoint pitch, the rest of the meeting participants are occupied in various multitasking activities behind their numerous electronic devices:

Most people do not take any notes, relying the deck that will be sent out later by the Business
Person (you can see the person on the left wrote down exactly two lines of notes).
The trouble sets in when the Business Person, in accordance with the Agile workflow,
immediately asks for estimates of work based on the meager few screens of bullet-points that spell
out the requirements. At this point, the Designer is feeling dizzy and the Developer is not particularly
happy to give the estimates either (yes, those things I drew are meant to be steam coming out of her
ears, not flying broccoli!):

The problem? Nobody on the team sufficiently understands the business use case to make any
kind of reasonable estimate. To make things worse, the Business Person is often convinced he did his
part correctly, and the fault lies squarely with the rest of the team: the Developer and the Designer
who are refusing to get with the Agile program!
Kick-Off Design Workshop
Ready to fix this? Then put aside the electronics in favor of a little collaborative sketching at the
kick-off design workshop:

Even at first glance, its clear something very different is going on herenote the level of
engagement of the participants, the style of work, and the deliverables produced during the design
workshop. When compared with the usual PowerPoint pitch meeting, putting on the design workshop

is different in five crucial ways:

1) Use a round table: as in the fabled time of the knights of King Arthurs Round Table
(http://bit.ly/1dproundtable), no one is pitching and no one is in the audience, passively
absorbing information. Everyone on the team sketches together developing user stories (even if your
table is actually a rectangle).
2) Put away the electronics: thats a cardinal ruleput away your e-waste and be present in the
moment. Every participant has to be involved in sketching the use cases. If you dont pay, you dont
get to play.
3) Make a mess: the table is messy with work artifacts, and we like it that way! This is the
generative, brainstorming stage of the meeting. You want a bunch of different ideas and directions
cleanup will come later.
4) Sketch, dont type: this is not a requirements review, but a collaborative storytelling, where
pictures and words are used together to tell collaborative user stories.
5) Deliver stories on paper: instead of electronic notes collected during a typical meeting, the
design workshop artifacts are mostly paper (and sometimes photos of whiteboard sketches). Instead
of simply writing down notes about the pitch, everyone is involved in sketching user stories in a
comic book format.
The ultimate result of the design workshop is the collaborative understanding of the key use
cases, documented using storyboards that comprise key aspects of the product vision. To put it
another way, storyboards are the initial expression of teams joint understanding of the problem.
Conveniently, storyboards also allow for simple usability experiments that will help confirm and
further refine your vision (we will discuss those later in the book). All other UX activities
(prototyping, testing, etc.) stem from these storyboards and provide more experimentation
opportunities that enhance understanding and help the team arrive at a complete solution. Fred Brooks
Jr. called this Conceptual Integrity in his famous book The Mythical Man-Month
(http://bit.ly/1dpmanmonth). This cohesion of vision is the key to creating usable software that solves
real-world problems. Storyboards are also a powerful method to help everyone separate the What
from the How (see Question #8, Why do you insist on using small square sticky notes for
storyboards? for more discussion on why this is important).

25. Are you saying everyone should be a designer? I dont like that. Sounds like chaos.
The important consequence to centering your design process on a lightweight research approach like
the $1 Prototype is the democratization of the design and research process. The $1 Prototype process
can feel a bit chaotic at first, especially for teams where people with rigidly assigned roles like
researcher, designer and engineer are encouraged to stay within their box and take special
care not to step on each others toes. In the $1 Prototype process, youll still have a leader doing each
of the activities, but likely there will be much more cross-over of the various roles, as overall the
team is focused away from producing and consuming pretty, expensive deliverables and reports and
on working together around the core of continuous iterative prototype evaluation to create a
working product or service.
Democracy is about empowering your team to make assumptions, fail fast, innovate rapidly and
make key decisions quickly. But democracy is a two-edge sword: while it empowers all individual
team members to do research and design, democracy also imparts ultimate individual responsibility
for product quality, usability and profitability. That is why the $1 Prototype process is one the best
antidotes to the usual three-hour shouting matches and all sorts of team drama.
If a team member disagrees with the storyboard accepted by the rest of the team, instead of saying
something like I disagree or I personally would never he or she can sketch an alternative
storyboard of their own devising and walk through it with the teama process that should only take
about 10-15 minutes. Following this, if the team still cant commit to a single use case and a
corresponding set of assumptions, both storyboards are collected and tested with potential customers.
At this point, a clear winner usually emerges, or more common still, it becomes clear that a better
solution is a combination of the two initial storyboards. Sometimes the team even discovers an
entirely different direction during this quick research phase as a result of customer feedback.

26. What makes storyboards so special for mobile? What about using Personas instead?
Persona was the primary UX technique for designing software for keyboard-mouse-monitor systems,
because Context changed so little from one task to the next. In contrast, todays mobile use cases are
best described through Context, which includes the Persona concept. Storyboards are exceptionally
good at expressing the rollup of Persona in the Context of the mobile activity.
Age of Persona
In the good old days, the Age of Persona, most of the work was done with a keyboard and mouse,
while sitting in front of the computer. Persona was the Queen of UX, because everyones system
looked quite similar. Very little about the early storyboards had to do with context: we rarely saw
people moving about and interacting with their environment as part of their task. As a result, most of
the early storyboards looked rather like the one pictured below and were unsurprisingly, of somewhat
limited utility. If you look closely, you might be able to see a person staring at a monitor doing
something... and the same person staring at the same monitor doing something else... and (surprise!)
the same person still staring at the same monitor again, now doing some other thing, and so on, ad
nauseam:

Monitor, keyboard, and mousethats all the users context ever was (even when using a laptop
computer). This made the Persona incredibly important for UX work, both as a concept and as a
deliverable, because it gave us some very specific clues about what a given archetype of person
might be likely to do with that mouse and keyboard in front of that monitor.
Instead of building the system that everyone will love, using Personas, allowed us to focus on a
specific set of requirements that fit specific archetype of user and design software strictly to those
requirements. Instead of Mike the Engineering Manager making the ultimate decision whether to
include a certain feature based on what he had that day for lunch, Persona allowed the team to ask
much more objective and enlightened questions, such as, Does this feature make sense for our

Persona, Mary?, In what way would this feature helps Mary meet her goals?, Would Mary know
how to use this? and so on. Persona allowed us to build a functional feedback loop that helped
evaluate whether our monitor-keyboard-mouse system would actually work for a bunch of specific
people who were a lot like Mary in real life. That was the beginning of truly useful usability testing.
In one sense, in the Age of Persona, the concept of Context was rolled into the concept of
Persona: Mary is stressed, she has to pick up her kids, but first she has to finish this task in front of
this monitor with this keyboard and mousethat was the users context. But the Persona still
remained Mary, married mother of two, who drives a minivan and works as a pediatric nurse. It
was primarily the Persona that drove the design, because the context of the task changed so little.
Age of Context
Enter the mobile Age of Context: in contrast to sedentary, focused-use monitor-keyboard-mouse
systems, mobile devices with their ubiquitous and frequently interrupted patterns of use involve
people perpetually moving around and frequently interacting with their environment using the onboard sensors. For that reason, when designing mobile applications, its often more important to
know the Context of the task, than which Persona is doing the task.
Consider that, while looking for parking on a busy city street, Lucy (a young, single lawyer driving
her late-model BMW on her way to an important client meeting) will exhibit many of the same
behaviors as Mary (a middle-aged pediatric nurse) shuttling her kids to a dentist in her minivan. Note
that Lucys BMW might need a slightly smaller parking spot than Marys minivan, which may be more
important to your mobile app than the rest of the background information behind both of these
Personas. This is because, while looking for a parking spot on their mobile device, both of these very
different Personas will likely exhibit similar behaviors. In other words, the Context often includes
the Persona (and not the other way around)a common situation in mobile design.
For our purposes, this is a crucial distinction, because it just so happens, that storyboards excel at
presenting the context in which goals are accomplished and actions take place. Storyboards can also
be made to include much of the Persona information in context, which makes storyboards the ideal
tool for conceptual mobile UX design.

27. I still dont understand why we need storyboards. I think the list of requirements ought to be
enough for anyone.
The storyboards created in the workshop represent something that a list of requirements would never
be able to do: the first pass at the system prototype. Storyboards encapsulate the vision and allow
people unfamiliar with the project (such as potential customers) to understand what youre building.
They provide a taste of the entire experience before you even start designing.
Storyboards are not a new concept. In Agile methodology its common to talk about stories and
epics. Stories are typically written in the form of: As a [type of user] I [want/can/need to/etc.] so
that [some goal]. Epics are simply larger stories. They have similar structure, but are larger in scope
and more detailed. Usually epics cannot be implemented directly but must be broken down into
smaller chunks, but there is no specific threshold for when a story becomes an epic.
If youre already using Agile stories and epics to document your requirements, youll find that
storyboarding is simply an extension of (and an improvement on) stories and epics. The storyboards
you create during the kick-off design workshop become the stories of the Agile process. Yet
storyboards also provide many additional benefits without adding a great deal of overhead.
Storyboards are very good at helping readers focus on a particular area of the interface together
with customers emotional reaction, giving a good feel for the entire experience. Heres just one
example: Kevin Cheng successfully used comic storyboards at Yahoo! as early prototypes for testing
since 2006. When showing his storyboards to evaluators, Kevin and his team encouraged the
evaluators to use colored markers to indicate parts of the storyboard that people particularly
resonated with, the parts they thought were easy, difficult, confusing, etc. and anything else they
thought was worth discussing. In his book, See What I Mean (http://bit.ly/1dpsee10), Kevin Cheng
explains how he and his team did storyboarding with their customers and clients, how this technique
allowed everyone to feel free to make comments, and helped understand the complete holistic
experience designers wanted to create.
One of the most valuable benefits of storyboards, is how they allow everyone on the team to view
each others basic assumptions. Where is the experience taking place? (On the beach? In the mall? In
the car? Who is driving?) Who is participating? (A young lawyer? A nurse? A busy mother of two? A
wealthy couple?). What is the reward? (Money? Time? Fame? Mastery? Attention?)
It is not enough to simply list these things. By putting them in the story, you get to try it on and
see if all of the teams assumptions hang together. That is, does a young, affluent lawyer really care
about saving a few cents on parking near the beach? Is that a valid use case? Even if youre fresh out
of young, beach-going lawyers to interview, you can use these basic tools of the story: role-playing,
empathy and imagination together with the diverse experience found within the team to see if the story
hangs together. Be honest with yourself, but dont worry if these things are just assumptions or
extrapolations. As long as you can get something in front of potential customers you are ahead of
80% of your competition!
Sketch with others. Sketch the conversations inside your head, share your sketches with
others and encourage them to create their own (and to revise yours.) Visual communication is all
about our bald ape brains. When we sketch with others, it changes how we think in three powerful
ways:
1) Talking and drawing stimulates more areas of the brain than talking alone and a more active
brain can surprise you with the connections it makes.
2) Pictures spark emotional responses and we retain concepts better when theyre bonded with

emotion.
3) Even when we dont pick up the pen ourselves, we feel like co-creators as the ink spreads out
before us on a dry erase board, flip chart or cocktail napkin. Dan Willis, Five Things Every UX
Designer Should Do Well (http://bit.ly/1dpcarnk), UX Crank Blog.
When testing storyboards with potential customers, the devil is in the details. Although people can
relate to your characters, it doesnt mean theyre likely to pay for the service or even find the service
useful to begin with. When interviewing evaluators ask specifically, Has this situation ever
happened to you? When? Where? What did you do? Wait for a response like a cat waiting for the
mouse beside the mouse-hole. If the answers are evasive, vague, or imply that I wouldnt use the
product, but my neighbor Joe... Now he would really think its awesome, you may be solving the
wrong problem.
Well-executed storyboards have the magic power to help people visualize the entire product as a
coherent story, because storytelling is literally in our genes. The power of storytelling is how our
ancestors gained our increased level of consciousness and raised themselves up from the great apes,
creating the civilization we enjoy today. Before we had a language and could write things down, we
drew pictures in the caves and passed along important information down to our children using stories.
Stories are easier to remember than a list of requirements because theyre easier to relate to. Theyre
coherent and maintain a great deal of Context (where are you?) and Persona information (who is
performing actions in the story?).
In contrast, a naked list of requirements just does not have the same power to magically come
alive in our mindits just a bunch of technical words on the screen. Even the most dedicated
Product Managers have trouble relating to that! Stories resonate, they create emotion and empathy in
the listener, something a list of requirements will never be able to do. This makes storyboards an
excellent vehicle for investigating use cases.
Stories also allow teams to fail fast and quickly discard any use cases customers have trouble
relating to. For example, in my early days of working for a large ecommerce client, we were asked to
investigate the possibility of a specific product for the clients top sellers. During the one-day
workshop to help envision the product, I put together two simple storyboards using 3x3 square sticky
notes (exactly as I show in Part 1 of the book). These two storyboards and the discussion they
sparked (more than anything else at that workshop) convinced the broader team that the product as
envisioned would be difficult to use and understand and would not provide the benefit the company
was trying to create for its key customers. The new process would also make the clients selling
system much more complex to use and even more confusing for everyone else.
As a result, the project was quickly droppedtwo simple storyboards allowed everyone involved
to fail quickly before a large corporate commitment was made, saving millions of dollars and months
of work, while instilling confidence in the teams ability to make key decisions quickly.
I observed a similar case in my SFSU course where a team was able to quickly evaluate and reject
the Mood Ring app idea. Mood Ring idea looked fantastic on the surface, but as soon as it was
put into the storyboard format, it was clear that the app would be difficult to use and will not provide
significant benefit (see Fail Fast with Storyboarding: Mood Ring to MyStuff side bar in Part 1 of
the book).

28. My team cant agree on our first design.

So, your team is made up of dynamic, creative minds that think differently. Congratulations!
Unfortunately, inside most corporate offices, disagreement is often viewed as a problem, resulting in
three-hour shouting matches to determine whose design your team should build, with the prize going
to the one who shouts the loudest. Worst of all, by the time the shouting is done, both parties are so
attached to their entrenched positions, theyre completely blind to the third, fourth, or fifth
possible designs that build on the best features of both ideas and introduce true industry innovation!
In contrast to the business as usual, the $1 Prototype methodology helps you capitalize on your
disagreement. If your team cant agree on one design, celebrate by creating both sets of sticky note
wireframes! You now have not one, but two wonderful starting ideas for your design iterations. Test
them both and see what other ideas develop. Simply focus on the working product and end all threehour shouting matches and drama through quick prototyping and testing.
This is exactly what happened at one of my Fortune 500 enterprise clients. By the time I arrived on
the scene, the Product Manager and the Lead Designer were already circling each other like
werewolf and vampire in a Twilight saga movie! (http://bit.ly/1dptwilight) Instead of enduring yet
another epic three-hour design shouting match, I persuaded the embattled combatants to focus the
teams energy on creating prototypes and doing some quick hallway usability testing. During the
lunch hour later that day, we tested the two competing designs at the company cafeteria, interviewing
people that worked at the company, but werent familiar with the product (it was necessary to test
inside the company because of the complicated NDA requirements). The better design emerged
quickly, and by that afternoon, a working design direction was abundantly clear to everyone involved.
Who knew that Werewolf and Vampire really could get along, as long as they... Ahem... have some
prototypes to stick their teeth into!

29. Whats the best way to integrate $1 Prototype methodology into Agile Scrum?
An explanation of Agile Scrum methodology is outside the scope of this book, but there are countless
resources (http://bit.ly/1dpagilescrum) that cover the specifics of this software development
methodology. Here well focus on how to get the most out of the $1 Prototype methodology if your
Agile team is using Scrum, but concepts discussed in this section will also apply to other Agile
software development methods.
The $1 Prototype methodology truly shines in Agile Scrum mobile projects. It allows team
members a rapid, effective way to document their assumptions then test them out in the real world,
with real customers, before theyre implemented as code. The $1 Prototype methodology was
developed specifically to add value to Agile Scrum development teams. Its optimized with a ruthless
focus on helping the team deliver a working product that solves a real need in the shortest amount of
time. The $1 Prototype activities are selected for speed of delivery, maximum customer contact, and
value of insights (as opposed to traditional focus on deliverables: their quality, volume, or certainty).
The following seven tips will help you get the most out of the $1 Prototype methodology.
1) Support both current and next Sprints
To use the $1 Prototype effectively (as a Product Manager, Designer or someone in your team who is
wearing a Designers hat at the moment), you have to proactively create some space in front of the
development process in which to make strategic UX decisions. The key is being aware of supporting
multiple cycles of work at the same time. While developers are entirely focused on the current Sprint
(which is their primary responsibility), I recommend that designers and PMs (sometimes called
Product Owners) only spend about 40% of their time supporting the current iteration, spending the
remaining 60% of the time looking ahead at the next Sprint. This is the only sure way Ive found to
stay ahead of the Agile Guppy.
The idea of thinking about the next Sprint is called the Product Backlog Grooming where
team thinks ahead" about future Sprints, makes design decisions and adjusts priorities in a systematic
fashion. Many seasoned teams do this activity together, and do not separate the designers or product
managers from the team, generally avoiding even naming peoples specialties. The $1 Prototype
provides these teams with a ready way to access primary research data and try out design ideas to
support this product backlog grooming activity.
2) Use the Sprint Planning/Kick-off Meeting to draw storyboards
If you want to be effective in the shortest amount of time, you have to get in front of the very first
Scrum iteration. That means using a part of the kick-off meeting as a design workshop to map out and
document at least a few basic use cases and teams assumptions. Use vision storyboards, as discussed
earlier in Part 1 of the book. Sprint Planning meetings tend to be fairly long, so its usually safe to
hijack the early portion of the meeting for drawing storyboards.
Many development teams struggle with understanding the vision behind the functional and business
requirements. If you communicate with your team early to let them know theyll better understand the
business goals and get good Agile stories out of this exercise, most will welcome the hijacking for
the benefit your storyboarding work delivers (particularly if it doesnt take a great deal of extra time).
However, occasionally, the kick-off tends to be solely about technology matters and completely
ignores the UX aspects of the application. For those teams you may need to set up your kick-off
design workshop as a separate meeting.

3) Give developers something juicy to sink their teeth into

Once the use case storyboards are complete, you can work with the developers to identify aspects of
the application that will likely be required for your MVP and are complex or difficult to build. For
example, one project I led used a database of US Zip Codes that had to be mapped to GPS
coordinates in a special way. The feature was central to the product, so we knew ahead of time that
the team had to build this complex functionality. This was the perfect feature to use for the first Sprint,
because its necessary, complex, well defined, and had no UI components.
Tackling complex technical issues first, allows developers to get busy right away, while Designers
and Product Managers get together to figure out the rest of the UX strategy. In other words, giving
Developers something to sink their teeth into keeps them from sinking their teeth into you, asking for
UI wireframes! Often, building application stacks, such as standing up an instance of Solr, Oracle,
Android development environment, etc., can serve the same function in the initial Sprint. Anything
necessary to get the project going and at the same time technically demanding will work. Help your
development partners to become productive quickly, and they will give you the space you need to
figure out what needs to happen from the UX perspective.
4) Prototype and test next Sprints designs
While the developers are busy working on the tasks for the current Sprint, you (or anyone in a role of
a Designer, Product Manager, or more generally Product Owner) can get busy with sketching
prototypes for the wireframes of the next Product Backlog Items and testing them with the potential
customers. Dont wait two weeks for great ideas to come to youthey wont! Look at your
storyboards and draw the first UI that comes to mind. As soon as you have three to four initial
screens for a particular workflow done using sticky notes, get out there and get them in front of
your potential customers. By doing this, you will keep the Product Backlog well groomed and avoid
unnecessary development.
Invite anyone else on your team who wants to come along to brainstorm potential solutions before
and after you testyou are much stronger when working together! (Hint: If youre testing during the
morning coffee break or during lunch, more people can tag along with you for 15-20 minutes on your
little excursions.) Whatever you do, make sure that by the end of the two-week Sprint you have the
next Sprints worth of designs done and validated on your sticky notes. Be sure to also update your
use case storyboards to match the new findings you obtained during the prototype testing. Some of the
teams initial assumptions may not have been correct. (Shocking, really, but it happens. Every. Single.
Time.)
5) Stick with paper as the only deliverable (for as long as possible)
If youve done your job correctly, various members of your Scrum team have already come along
with you one or more times. Which means that they are familiar with the new designs, and have seen
first-hand what works and what doesnt. Your team members are also mostly bought into the design
and understand why certain decisions were made. Which means they already understand what they
need to build next and are itching to get started.
This is ideal, because now you can simply take a photo of the final versions of the sticky note
wireframes and storyboards with your mobile device and email it to the developers and they will
accept is as the only documentation. Low-fi prototype documentation works during the bulk of the
project. In the final Sprint or two youll also need to supply a visual design guide and some visual

assets, such as icons and gradients to supplement the sticky notes. (See Question #30: What kind of
graphics software do you use in your design work?, coming up next.)
There will always be questions, of course, but now you can spend the bulk of your time on
designing the next piece and not on re-drawing detailed sticky note wireframes using some kind of
software package. Creating even mid-fidelity wireframes in OmniGraffle takes time, effort, and
concentration. Time you cant afford to spend on this low-value task. Instead, you need to concentrate
on doing the design and research needed to groom the product backlog for the next Sprints design.
And with the $1 Prototype methodology, you dont have to spend that time, because your storyboards
and sticky notes prototype are your design documentation.
Set the expectations early, and get the team buy-in. The more low-fi you train your teammates to
be, the more productive youll be as a team. This is not an us vs. them scenarioits about
managing expectations and getting the entire team completely involved in the design process. Realize
that you are in this together, working on the same product. The teams first-hand understanding of what
they are building, enthusiasm and empathy are more instrumental to the success of your project than
any amount of pretty digital wireframes. Focus on creating the product, not on your design
deliverables. This is the heart and soul of the $1 Prototype methodology.
6) Support the current Sprint, while focusing on the next one
Once the initial wireframes are done, you can present your findings at the next Sprint Planning
meeting. Having these initial wireframes as sticky notes makes everyones job of figuring out what to
build next much easier. Now the developers can implement the wireframes you worked so hard on for
the last two weeks, while you work on the next batch of functionality, guided by the storyboards
updated with feedback from SMEs and your business partners.
Check in with your developers at least every other day, preferably at the daily standup meeting,
especially during the first week of the Sprint. This is essential, because supporting your developers
current Sprint is your top priority. Be prepared to face specific questions such as does this line need
to be two or three pixels? as well as fundamental questions regarding information architecture,
interaction design, transitions, etc. You dont need to answer those kinds of questions during the 15minute standup meeting itselfschedule a separate meeting! Youre attending the standup meeting
to find out about impediments, not to solve them. If youre not sure about an answer to a question
posed by developers, update your current Sprint prototype quickly and test it during that days lunch
hour and/or that same afternoon. You can often answer your developers questions on the very same
day!
Quick check-ins during the morning standup meetings will enable you to fully support development
activities during the current two week Sprint, while you focus on rapidly designing and testing the
next Sprints worth of screens and functionality. As an alternative, you can also hold special office
hours one or two times per week, when developers can drop-in with their questions. Be sure to
check-in frequently and make yourself available for quick answers as well, otherwise developers
will be making their own design decisions.
If you cant answer a question in a single afternoon, let your development partners know, and ask
them if the app can be built in such a way as to allow easier changes later, should they become
necessary. Most developers will appreciate this heads up, as it will often save a great deal of time
later in the project.
7) Rinse. Repeat. Document.

Continue supporting the Agile Scrum process until the work on this phase of the project is complete.
Be sure to document initial wireframes and storyboards as well as any subsequent changes with
simple photos taken with your mobile device. Evernote (https://evernote.com/) is a great tool where
you can save these mobile photos right in the field and tag them with dates, changes youve made, and
any UX insights, helping you to stay organized even during fast-paced projects and helping your team
to stay connected and up to date with your field activities.
The most effective way to show off the projects progress is by creating your report using several
11x17 pages: one for multiple iterations of the storyboard, and one or more pages for all iterations of
each sticky note prototype that supports a particular storyboard. (Note: we tend to use OmniGraffle
for this purpose and set the page size to 22x34 inches, which can be viewed on the screen as PDF or
printed on 11x17 paper. See Question #30, What kind of graphics software do you use in your design
work?)
In your report, be sure to also include any screenshots from the current state of the actual product
as the development team is implementing it. Annotate images with 10-15 small blurbs of text (no
more than one to three sentences each) briefly explaining the key aspects of what you changed and
why. This creates a highly effective, visible, self-explanatory deliverable that is easy to put together
and easy to consume. Documenting the process you went through showcases the value of the service
you (and your $1 Prototypes) delivered to the organization and helps your team to feel ownership of
the design process. Heres an example of this kind of deliverable produced by Be a Hero! team:

See Be a Hero! case study mentioned in the beginning of the book.

While the exact sequence of steps above is optimized for Agile Scrum, with some changes, the $1
Prototype methodology can be to effectively support most development processes and practices. No
matter what methodology youre using, the $1 Prototype will help you add value to the development

process while reducing risk, removing impediments to innovation, and keeping your development
team as productive as possible.

30. What kind of graphics software do you use in your design work?
Designing actually involves two separate tasks: designing and documenting. It is important to
be clear about the difference between these two. Become keenly aware of the purpose of each design
activity youre engaging in and the reasons for the deliverables youre creating. Optimize for
effectiveness: avoid over-documenting your designs because tradition and custom dictate it!
In the $1 Prototype methodology, we stay with the sticky notes for as long as possible through the
design phase. Why? Because using sticky notes makes the design phase more efficient and productive.
Sticky notes allow us to design freely. In addition to documenting the designs, sticky notes forms an
effective, flexible prototype. We can brainstorm different design approaches, sketch them quickly, and
jump immediately into testing and design iterations. In this way, we can rapidly test information
architecture, interaction design, data entry, content, icons, buttons, transitions, etc.
Final sticky notes designs are documented by taking clear photos with a mobile phone or highresolution scans using an office scanner. Any conditional logic and transitions between the screens
can be documented as videos recorded with your mobile device.
While sticky notes will take you farther than you ever thought possible, in most projects, there
comes a point when you need to provide higher fidelity design documentation. Weve identified the
following three distinct use cases:
1) Visual design and branding (Photoshop or GIMP http://bit.ly/1dpgimp).
2) Custom controls and minor variations (Fireworks or Karbon http://bit.ly/1dpkarbon with
InVision http://bit.ly/1dpinv).
3) Complex workflows and templates (OmniGraffle, Dia http://bit.ly/1dpdia or yEd
http://bit.ly/1dpyed).
Below is an explanation of the various software packages and how we use them in conjunction
with the sticky notes in the $1 Prototype methodology.
1) Visual Design and Branding
At DesignCaffeine, we normally switch to a competent, industrial-strength graphics program such as
Adobe Photoshop to create a high-definition visual design guide. We also typically skin a few key
pages into pixel-perfect examples of how color and branding can be added to the sticky note
wireframes.
The bulk of the wireframes, however, remains in the sticky notes format. Skinning every sticky
note is not necessary, because were diligent in our collaboration with development and business
partners throughout the project. This means that most teams have no trouble using our visual design
guide together with the stickies to produce the final product. We also typically stay on the project as
consultants during the implementation phase to ensure smooth and accurate execution as well as to
answer any development questions that inevitably come up.
2) Custom controls and minor variations
Shunned by its stepmother, Adobe, but beloved by many designers, Fireworks (http://bit.ly/1dpfir) is
the Cinderella of the design world. It combines the best features of Photoshop with simple and rapid
workflows, allowing for up to 100% pixel-perfect fidelity in about one-third the time it would take to
do the same work in Photoshop. At DesignCaffeine, we use Fireworks whenever the project calls for
custom controls and testing minor variations in the designs that are difficult to capture using sticky

notes.
Most often, we load completed Fireworks wireframes into the InVision (http://bit.ly/1dpinv) tapthrough linked-page prototype. This allows us to test the resulting high-resolution designs. For linkedpage prototypes, we tried InVision, POP and Fluid. Of the three tools, InVision provides the best
combination of functionality and ease of use and is able to handle larger projects.
For example, a financial company we worked with wanted a unique mobile wallet design that
introduced a bunch of custom controls. We did the preliminary work in sticky notes, but found that the
main design element needed to be mocked up with higher fidelity to be understandable to potential
customers. So we switched to high-fidelity wireframes created using Fireworks. Then, for testing, we
linked the resulting wireframes together using a tap-through InVision prototype that was hosted on a
server and viewed on the mobile device.
In another example, a large B2C client wanted us to explore a bunch of non-standard font sizes and
styles in the Android action bar to convey a total amount in a merchant point of sale app. Using
Fireworks to create a high-definition linked-page prototype allowed us to test and compare several
designs that were extremely close together in late-stage usability testing.
3) Complex workflows and templates
OmniGraffle is my personal go to tool for rapid documentation of complex workflows on a Mac.
Its similar to Visio for Windows and performs the same function: the glue between various
disparate deliverables. We use it often when we have to communicate complex system workflows to
people outside the core product team. OmniGraffle makes it easy to add arrows, decision points, and
annotations to sticky note wireframe scans, combine them with high-definition branding elements and
fully skinned pages, and finally put everything on a single larger poster. Depending on the project, our
final deliverables are often ten to twenty-five OmniGraffle pages. We tend to use the page size of
22x34 inches, which can be viewed on the screen as a PDF or printed on 11x17 paper.
Another reason to use OmniGraffle is to take advantage of the repeating elements and templates.
Some projects involve tremendous amounts of documentation needed to satisfy regulatory
requirements. As much as we try to avoid those projects, sometimes there is little choice but to play
by the rules, especially if those rules are set by government agencies. OmniGraffle is a lifesaver for
those cases, because it has an exceptionally efficient stencil feature. Key elements of the application
can be saved as stencils and then dragged onto the canvas, copied, and edited easily to rapidly
document even the most complex designs.

It is important to note that templates are used for documentation purposes only, not for design! Our
tools strongly shape our thinking; using templates for design is dangerous, because it tends to limit the
kind of strategic thinking youll be able to do.
The bulk of the design happens while you sketch on sticky notes or on the whiteboard. In
contrast, graphic software exists with the express purpose to help you document your designs. If you
want to be efficient and productive, its essential to understand the differences between design and
documentation and allocate the appropriate amount of time to each one, as demanded by your
project. Avoid the temptation to put a pretty finished deliverable in front of someone important if this
does not help the project! No matter how tempting or seemingly innocuous, this desire to please is
pure poison.
Creating high-definition wireframes too early in the design process shifts the focus from the final

product to the quality of your deliverables. This is what gets you eaten by the Agile Guppy! Once
people see a single high-definition screen, they tend to expect them forever after and refuse to even
look at your drawings, even though they carry more than enough information. Dont get caught in the
documentation trap: educate your team about the strength and effectiveness of your process early on
and then prove the value by spending the bulk of your time trying out various designs and testing them
with potential customers. Always be designer first and documenter second.

31. My developers are demanding only high-definition wireframes and refuse to look at my sticky
notes. What do I do?
If your team is having trouble with sticky notes, it could be a matter of managing expectations. People
fear change, and if theyre used to working off of high-definition wireframes, sticky notes can take
some getting used to. The following five tips should help you make the process smoother.
1) Assure them the wireframes are coming
When faced with recalcitrant team members, I first assure them that the high-definition wireframes
theyre used to are coming soon, but only during the final visual design phase. In the meantime, I
explain the need to be flexible and work as a team to explore various design directions quickly. Then
I ask the entire team: what exactly is missing or not clear here? Maybe your stickies arent as
complete as you thought. Or maybe its just a matter of explaining the new process and managing
expectations.
2) When in doubt, draw!
If your stickies are of good quality, but the objections keep coming, show how committed you are to
your methodology by saying, here, let me draw another sticky note screen for you. Heres the action
bar, heres text field, heres the button, etc. Now, what was the question again? If the disagreement is
isolated to one or two difficult individuals, it helps to enlist the help of management and buy-in from
as many team members as possible prior to the meeting. I suggest giving everyone a copy of this book
so you all have a shared organization platform on which to base your communication.
3) Whatever you do, do not give in
If you do, your team will just expect high-definition wireframes every single time and youll be right
back at spending the bulk of your time behind the screen documenting instead of out there designing.
Use the mobile workflows as an opportunity to take the focus away from creating pretty deliverables
and onto creating excellent designs.
4) Get buy-in early
Remember for the $1 Prototype methodology to succeed, you need to get your entire team involved
in the new process from the beginning. If the first time your developers see your sticky notes is when
theyre sitting down to code them, its simply too late. Provided your team was involved during the
storyboarding stage (even if you were the one to draw the storyboard) youve already created early
team alignment around a common vision, and this will help you during the remainder of the project. If
people were directly involved in storyboarding, they will understand how the sticky note wireframes
are derived from these use cases, and it will in turn help them accept this strange new deliverable as
a way to quickly jump into coding the final product.
5) Remember to make the new process fun
I cannot over-emphasize this point. To the extent that you can do it, being able to laugh at your own
goofy drawings will help you immensely! Getting everyone involved early on will create trust and
give you time and bandwidth to explore, user-test, fail, and perform the necessary design iterations,
while youre working together to deliver the project faster than ever.

One Last Thing

I sincerely hope you found this book useful! My team and I worked hard to combine the best of
modern mobile usability techniques with Agile development lifecycle and Lean business approaches
to give you a practical, no-nonsense lightweight UX design methodology you can put to work today.
But the $1 Prototype methodology is also something more: full permission to play and experiment.
To turn your world into a giant laboratory to figure out how technology can connect people by taking
care of all the minutia of tedious details. To simplify, empower, and inspire. So you can use your
design talent to help people find their purpose, grow, and reach their full potential.
Like Iron Man, were all modern cyborgs, surrounded by technology that makes our heroic lives
powerful and exciting. But while technology is a shiny, fascinating toy, at the core of each successful
design lies our humanity. Inside the cybernetic exoskeleton, Iron Man is still just a man. If you
approach your design by seeing the bright spark of divinity in another human being, both the
methodology and your design solution will fall into place.
So dont wait another minute. Get out there! Escape the cubicle land, three-hour shouting matches,
and over-documentation. Open the door to imagination, creativity, empathy, and love. Our mobile
future is up to you.
Namaste,
Greg

P.S. If you did find this book useful, please let others know via an Amazon.com review
(http://bit.ly/1dollarp). And if you hated it, keep it to yourself. OK, OK, Im kidding! Id love to read
your review on Amazon.comhow else would I get better? So heres that URL again:
http://bit.ly/1dollarp Thank you for reading!