60-Second Prototyping

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 .

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. 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 . 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 ]