Transcript
[ Background Conversations ]
>> I'm sure many of us here have
found ourselves in this
situation.
You're in the bathtub, and you
come up with an amazing idea for
your app.
Or perhaps a little bit less
relaxing, you get a text message
from someone very important in
your organization asking you to
come up with amazing ideas for a
new app.
Looks like we are going to be
looking at Timers today.
So in those situations, you
might tell yourself, "I don't
have time."
You might want to dive into X
code, start typing out some
Swift, but the problem with that
is that once you get committed
to code, you're really deep into
how your app is going to work,
and you don't get much leeway to
explore all the alternatives
that you could.
Or you might want to dive into
Sketch, and draw some really
detailed visuals.
But again, the problem with that
is that visuals are not
interactive.
We're building apps.
We want to try it as if it were
a real app.
So let me show you something I
may build after getting my CEO
asking for a Timer.
This is a very basic concept.
I tap to add five seconds to the
timer.
Let's make it 10.
I press Start, and it starts
counting down to zero.
Nothing fancy here, just an idea
I had about how the Timer app
might look.
Now, as you might have guessed,
from the title of this talk,
this is not a real app.
It's a prototype, and it only
took me 60 seconds to build.
That is less time than it took
you to brush your teeth this
morning...hopefully [laughter].
So why do we build prototypes?
We build prototypes to test
ideas.
Some things that seem really
great might turn out to be not
so great once you try it.
And some things that don't
appear very good at first might
actually have some very valuable
insights to them.
This is about saving time and
money by making sure that when
you commit to building something
by writing code, designing
assets, you're building the
right thing.
We also make prototypes to get
new ideas.
The act of making prototypes and
showing them to people will
bring new insights that will
help make your product even
better.
Designers love diagrams, so here
is a diagram of what the
prototyping process might look
like.
We make prototypes, we show them
to people, and we learn from the
feedback.
And we do this over and over and
over again, until we know we're
really making the right thing.
So let's start by making a
prototype.
Who can make prototypes?
Everyone. It is about using
tools that you already use every
day.
If you are a developer, you
might use X code in Swift, or
HTML, CSS, and JavaScript.
If you are a designer, you might
use Sketch or Illustrator.
But even if you don't code or
design, you can build
prototypes.
You can use keynotes, or your
favorite text processor.
It's about subverting your
tools.
Use tools that you use already
every day, and push them in new
ways.
If it can display images, and
respond to user interaction, you
can probably build prototypes
with it.
So let me show you how I built
the prototype we just saw
earlier, just using Keynotes, in
under 60 seconds.
Now, the video you're about to
see is a little fast, because I
like to use Keynote a lot for
that kind of stuff, but let me
get you through it.
So I start by making my document
the size of an iPhone.
And I'm going to draw the clock
face for my timer.
You'll notice I'm not using
really fancy design assets, I'm
just using basic Keynote shapes.
Let's do the same thing for the
button, the Start button.
Again, just using a basic
Keynote shape.
Let's make it green.
And let's make it say Start.
Now, I'm adding the hand for my
timer.
The trick I'm going to use is in
Keynote, when you rotate
objects, they rotate around
their center.
So here, you see I am
copy/pasting the hand, moving it
to the lower part, and making it
invisible.
Now, I can group them and I can
rotate it and it will look just
like a hand on the timer would.
So we make it rotate to the 5
second mark for the first tap,
no easing to make it look just
like a real clock, and we add
another animation for the 10
second mark.
And finally, the last animation,
which is the hand of the timer
rotating all the way back to the
0 second mark.
And as this animation starts, we
make the Start button disappear.
And that's it.
Just like that, we have a
prototype that we can load on an
iPhone, and have it look just
like a real app.
[ Applause ]
>> So now that we've made a
prototype, we show it to people.
As we show it to people, we ask
ourselves, how can we make it
better?
I have some theories about what
will work and what won't, and
look for evidence that supports
or contradicts those theories.
Don't argue, defend, or dismiss
the feedback you get.
It is also very important to
show your prototypes in context,
on the device they're meant for,
in a somewhat realistic
situation.
You can't test things in a
vacuum.
So, for example, here I ask my
co-worker to test the pH of a
little bit of water, using the
timer.
So we add the pH reagent, press
the Start button, and start
shaking the test tube for 10
seconds.
So in this case, it seems to
work pretty well, right?
Like, it is not a very
complicated use case.
Maybe it would be nice to have
the Timer flash, or play a sound
at the end, but it seems to work
pretty well.
Now, my friend David used to be
really good at solving the
Rubik's Cube in high school, so
I asked him to see if he could
still solve a Rubik's Cube in
under 10 seconds.
All right.
Looks like he's still got it,
with time to spare, too
[applause].
Now, as David was using this,
there are a number of things
that he was telling me.
He found that the Start button
was a little small, and hard to
tap.
He also thought it would be nice
if there was a countdown when
you press Start, so he could
really position himself on the
Rubik's Cube, and he really
wanted to see the actual precise
time, so he could tell if he
beat his record or not.
You see that this opens up a lot
of interesting design questions
around what we're building, and
what it should be like.
Once we've shown our prototypes,
we take a moment to step back
and learn from the feedback that
we have gathered.
What is working?
What is not working?
Do we refine what we have?
Or do we try something else
altogether?
Perhaps do some brainstorming to
come up with the next steps?
For example, here are some of
the questions that we got as we
showed our prototype.
Do we display the time left on
the timer, or the time elapsed?
How do you pause or stop the
timer?
Should we show the time in
digital form or analog form, or
maybe both?
And are we building a generic
timer, or one for a very
specific purpose, like solving
Rubik's Cubes?
And many, many other questions.
Now, the goal isn't to answer
all of those questions, but
rather to know what you don't
know, so you can then
strategically choose what to
pursue next.
Here is how I might improve this
prototype after showing it.
So, David told me that the Start
button was small, and the Clock
was hard to see, so I agree with
him.
I'm going to make it a nice,
bold red, and let's make the
hand white, just so that it
really stands out.
Start button is too small, so
let's do away with it
altogether, and maybe we make
the entire lower portion of
this, creating a tap region.
And let's make it say Start in
nice, bold letters.
Same color as the clock to keep
it consistent.
And I'm going to add a finish
screen for my timer, so we know
the timer is done counting down.
So I just add a new slide that
we navigate to automatically and
have it say Timer Done.
And just like that, we have a
new iteration of our prototype,
that we can build on, and show
to people.
Making things fast lets you
quickly explore a very wide
range of ideas and directions.
Here are some more prototypes
that I built in Keynote around
the concept of the Timer.
Now, some of them, as you see,
are aesthetic explorations
around what a Timer might look
like, or how you might interact
with it, while others are more
specific use cases.
Timers for developing film or
cooking a steak.
That is also where having a very
diverse team helps your process
a lot.
It will let you stumble upon
things you never would have on
your own.
For example, my co-worker made
this Timer to help their child
brush their teeth.
So we make quick interactive
prototypes.
We show them to people.
And we learn from the feedback.
And we do this over, and over,
and over again, until we know
we're doing the right thing.
If you start by making one
thing, you'll be inspired to
make a few others.
Some of these things will work
really well, and the ideas will
make it mostly unchanged
throughout your prototyping
process, and on to your final
product.
Most things will have some
aspects that work, and others
that don't work as well.
You will be able to take those
and modify them and recombine
them in new prototypes that you
can show and explore.
And finally, a few things won't
work at all, and it is great
when that happens.
You've just learned something
very valuable about your app,
and you're not going to be
spending designing time or
programming time building things
that would not have worked out.
The goal is to take ideas from
your head into the real world,
on device, in context, in front
of people, as fast as possible.
As you are leaving WWDC later
today, here are a few things you
can do.
If you don't make prototypes
already, the next time you have
an idea for an app, or future
for your app, make prototypes.
Show them to your colleagues.
If you already make prototypes,
amazing!
Wonderful!
Find co-workers who don't, and
show them how you do it.
And if you manage a team, make
sure that you're building the
right thing, by making time for
prototyping as part of your
process and culture.
Imagine how wonderful it would
be if the next time you get a
text message like this from your
CEO, you can reply just 60
seconds later with a prototype
like this.
Thank you.
[ Applause ]