How long does it take to go from idea to prototype that you can test with users? A month? A week? Few days? How about 30 minutes?

What if you can prototype your next idea quickly and cheaply without using any special wireframing or design tools?

What if you can send your prototype to friends to play with and give you feedback, without having to worry about uploading it to a server or making sure they have the right platform?

What if you can embed that interactive prototype within your product presentation, and click through it to show your audience how it works, rather than overloading their imagination with bullet points?

And what if you can do all this without writing a single line of code?

The challenge with existing prototyping tools is that they require you to become a designer in order to create a good looking, interactive prototype. By taking design out prototyping, you can focus on simply placing components on a page, editing their text, and create links between components and other pages. And contrary to popular beliefs, a prototype doesn’t need to look ugly or rough, especially if you’re presenting it to a prospective client or investor.

The video below shows a sample prototype created using Apple Keynote and Keynotopia’s iPad prototyping elements, without using additional graphics or tools. You can also see how I am testing the SAME prototype on an iPad, tapping my way through different screens and dialog.

Here are some screenshots of the graphics used in that presentation, which were all created in Apple Keynote.

So how can you create a similar prototype in 30 minutes or less?

First, you will need to  get the Keynote Prototyping template , and install the file “iPad Prototype.kth” into <UserName> -> Library -> Application Support -> iWork -> Keynote -> Themes. Alternatively, you can double click the file to open it in Keynote, and choose file -> Save Theme. This will create a theme in Keynote that you can reuse to create new presentations, as shown below.

When you create a new presentation based on the iPad Prototype theme, you will see a single black slide. To access the assets, you need to go to the toolbar and click View -> Show master slides.

This will reveal the master slides panel above the slides panel, allowing you to click on a specific master slide and copy/paste assets into your slides.

Step 1: Drawing a blueprint

To create your prototype, start by defining the different app screens that you will need and how the user will transition between them. I typically do this as a state diagram as shown below (Created on the iPad using Adobe Ideas).

It’s important that you get this diagram right because it will save you time doing modifications to your prototype later on.

Step 2: Putting together application screens

Next, you create a new slide for each screen, and copy/past components from the masters into each slide (Select a master slide > Select an object > Select target slide > paste object). Since all objects were created in Apple Keynote, they are fully editable (resize, change labels, change colors, add/remote elements, etc…). Each object is a group of building blocks that are grouped together. You can either double click on an object to select each sub-object, or ungroup using the Ungroup button on the toolbar, edit sub-objects, then group again. Grouping makes it easier to select and move objects.

Hint: After you’ve created each screen, you may find it at times easier to move the static components of that screen into its own master slide. That will save you time in making modifications in each slide if you decide to change something later.

After creating each screen, you duplicate (CMD+D) slides and add additional elements to them (pop-ups, fill text, …).

Step 3: Adding interactivity

Finally, it’s time to create transitions between screens. You do this by going through your state diagram, and for each slide, select the element that would transition it to another slide. For instance, clicking a picture shows the profile pop-up, so you’d select the profile picture (you can select all pictures in the slide), and in the Inspector -> Hyperlink select the target slide. Do this for every transition that you have in your state diagram. Keynote will add a blue indicator on each hyperlinked element in your slides.

Hint: Keynote is smart enough to know when you rearrange your slide, and will keep track of the right slide you link to even if you change its sequence order.

Test your presentation frequently to double check that you’re hyperlinking the correct slides.

That’s it! You now have an interactive prorotype within your presentation.

Test it on an iPad !

If you’d like to test this prototype with users and see how they’d use it, you need to export it as QuickTime as shown below (This will prevent screens from automatically advancing if the user clicks a spot that’s not hyperlinked. You then open the prototype in QuickTime Player 7, and interact with it.

If you’d like to test the prototype on the iPad, you need to export the prototype as PDF, email it to yourself or put it in DropBox, then open it on the iPad. In the video above, I use GoodReader to show the PDF file.

Hint: Unfortunately, the Keynote iPad app does not support hyperlinked navigation, so if you open this keynote file on the iPad it will only advance sequentially.

Bonus Hint: Keynote has an automatic tweening/animation feature called Magic Move. If you want to have fun by adding animated transitions, fading pop-ups in and out, you can do so by copying and pasting the shape across two slides, select both slides then selecting the effect as shown below. I found this feature to be unpredictable at times.

Final Words

Remember that a prototype doesn’t need to be perfect. It just needs to convey your idea better than your words do. Don’t over-engineer it, and don’t prematurely optimize it. Just put together something that users can see and play with. You will get many more insights than spending hours in focus groups, market research and surveys.

Next time you’re giving a pitch, remember to show more and talk less. If a picture is worth a thousand words, a prototype is worth a thousand pictures.

Creating prototypes is like doing magic: once you understand that all magic happens in the spectator’s mind, you can focus on bringing what matters to the audience. Everything else is a distraction.

If you think this tutorial is useful, or if you have any feedback or questions, leave me a comment below. I will do my best to reply to every single one of them.

Update

Wow! I didn’t imagine when I wrote this blog post that it will generate so much buzz and love in the blogosphere and the Twitterverse. In the past two weeks alone, more than 10,000 people read this post and more than 500 downloaded the iPad Keynote toolkit.

Having received so many requests to create a variation for the iPhone, I spent the past few days creating the most comprehensive prototyping toolkit for Keynote. Over 200 assets total, all created in Keynote. The premise of this toolkit is to help anyone put together an interactive prototypes of their idea and test them with users in less than 30 minutes. The other benefit is to embed these prototypes in product pitches and demos, and be able click-through screens without leaving the presentation.

Here is a video of an apartment hunting app prototype assembled with the toolkit and exported to the iPhone as PDF (displayed in GoodReader, which is the best PDF reader on iPhone/iPad).

You might also like reading...

• How it all began (A personal story)
• Listening
• Is your product a “hot chick”?

Lady Gaga’s best feature is her voice. Her strong and unique voice will likely capture your attention if you hear to it on the radio; when I first heard Bad Romance in my car, it sounded interesting; it was different than the other songs playing on the station. It broke the monotony of my drive. And the song kept repeating in my head for the rest of the day.

Then there is the form. Lady Gaga consistently delivers each of her songs in a unique style that complements her voice, her feature. Each video is interesting, polarizing, shocking, intriguing and provoking in its own way. You can’t help but watch. And if you can’t watch, you switch it off and later you may talk to your friends about how weird or abnoxious it was. Your opinion would make your friends intrigued enough to check it out, and they may agree or disagree with you. Either way, Laday Gaga made you listen, made you look, and made you talk.

Let’s face it, most products are boringly similar: A landing page with taglines, list of features, screenshots, a video walkthrough, and a big sign up button. Seriously, how many landing pages have you seen that are just few variations away from each other? How many times did you stop and think “Hmm.. Now that’s interesting!” How many products you look at that you actually remember enough to talk about?

The secret word here is INTERESTING; We’re not just looking forward to add more features to our lives, we want to make our lives more interesting. If people choose your product because it’s got better features or is a bit faster, that’s because they want to get the job done and proceed with the more INTERESTING stuff in their lives.

People don’t make their decisions rationally, by the time they are consciously making their minds, their subconscious would have already decided for them. If you don’t capture them in those first 2-3 seconds, you may lose their interest forever.

It’s not enough to be good. You must be different. And it’s not enough to be good and different, you must be CONSISTENTLY good and different. Remember these two equations:

Features + form = character

Great features + Unique form = Memorable character

Lady Gaga is a memorable character, and your product should also have its uniquely memorable character.

I previously wrote a post about the user’s journey how to drive users to ecstasy (and boredom) . And to drive them to ecstacy, you need to find the G-Spot (I am referring here to the Gaga-Spot). Your product’s G-Spot is where form and function intersect with a unique style. It could be a visual style (Mint), a language style (BaseCamp), your voice (Vaynerchuck) or your customer service style (Zappos).

Don’t settle for a boring landing page or a list of features. Don’t talk too much about yourself. Don’t use jargons like “state of the art”, “innovative” and “revolutionary”. Leave these diluted phrases to big companies, and find what makes your product unique, what makes your customers tick, and how you can address their problems in an interesting style. Understanding the human side of business, knowing what people NEED and WANT will give you a competitive edge: Not only you’ll be delivering what they need, you’ll be delivering it in a way they would want it. You’ll be selling to their conscious and subconscious minds!

If most businesses fail anyway, this should be a liberating fact! If it might fail, why not fail with a style and have fun doing it. Or as James Cameron put it:

You might also like reading...

• Adobe Flash Catalyst – First impressions
• Useful advice from Lao Tzu
• Home

After the first day orientation, I went to my mentor’s office to find out which project I’d be working on. When I sat across the desk, he peeked at me through the stacks of research papers and notes, and said with a big smile: “Well, here you are. You’ve got 12 weeks to spend with us, so come up with something useful and exciting!” I looked at him waiting for a specific task, and he proceeded ” You’ve got access to hundreds of researchers and thousands of employees. Make good use of it. Good luck!”. He then introduced me to the rest of the team members, and showed me the way to my office where I would spend the next 12 weeks coming up with the next big thing. Or at least, that’s how I felt back then.

On the following morning, other interns were already printing out research papers, looking at source code, and discussing tasks among their teams.  I didn’t even know where to start. I was scared and excited.

I started by browsing through existing tools, and I read previously published papers. That led me to plan B: If I failed to come up with something original in the first couple of weeks, I could improve on an existing project.

I also brainstormed several ideas with my team, but I couldn’t decide on any of them. I spent the first weekend in the office, trying to come up with my “cool and exciting” idea in the stereotypical lone scientist way: a whiteboard full of ideas and papers scattered all over my new desk. But that didn’t seem to go anywhere, since I had no criteria to judge on which idea is better than the other. That was when my first realization hit me: I’ve been too focused on ideas and I forgot about the most valuable resource: people. My research was about programmers productivity, and I had access to tens of thousands of programmers at Microsoft.

I erased the whiteboard. And with all the ideas gone, I was free to focus on finding out, instead of guessing, the real pain points that developers go through every day.

Lessons learned: Great ideas are seldom found behind office walls.

Step 1: Listen

The following Monday, I prepared a list of interview questions, bought a voice recorder, and prepared a list of developers to interview. That week, I spent close to six hours each day asking them about about their projects, their environment, and their teams. I didn’t know what I was looking for, so I listened to everything they had to say. And they talked as long as I was willing to listen. Every day, I would refine my interview questions based on interesting patterns or triggers I was getting from the day before. Having voice recording helped me go back and confirm a point that someone made earlier.

At the end of the week, I met with my mentor to analyze the results. It became clear to us that there was a common pattern among all interviewees: The most painful and time consuming part of the development process wasn’t writing new code, but understanding existing one. In a large organization like Microsoft, source code moves across several developers, and sometimes they need to go back to what someone wrote few years ago to comprehend it and add a new feature. Without access to the person who originally wrote that code, it was a pain task.

Lesson learned: Be willing to listen without judgment.

Step 2: Validate

I’d found a good pain point, and I needed to know what people did to solve it. I thought about writing another set of questions and go interview more developers. But I wanted to get deeper insights; I wanted to know what they did when faced with the pain point. So I instrumented Visual Studio, the development tool of choice at Microsoft, to record all navigation and editing activities. Then I designed an experiment where users were given an existing project (A Tetris game written in C#) , and they were asked to fix a bug and add a feature. To accomplish these tasks, a developer needs to navigate a couple of the 25 classes in the project, and learn the role of few existing functions and variables.

I had two assumptions I wanted to validate: First, experts were faster than novices in program comprehension (easy one). Second, there is something in common about how expert went about understanding code, that’s less experienced developers don’t do. So, I invited 5 senior and 5 junior developers to help with the experiment. I recorded time, success rate, and frequently asked them to think aloud about what they were trying to accomplish and what they would imagine the solution to be. While they were working their way through the code, their activities were being saved to log files.

Later that week, I wrote some Excel macros that aggregated all the “activity streams” inside visual studio and created charts that summarized the various code areas that developers navigated, and the various paths they took.

To my delight, both assumptions were true: experts were faster than novices in understanding source code, and they took common paths to understand it.

Lesson learned: Don’t just listen to what users say, watch what they do.

Step 3: Collaborate

At that point, I knew I had a problem that was worth solving, and I had some ideas about how to solve it. But I wanted to do more than just get in a meeting room with my team and brainstorm more ideas; I wanted users to be involved. So I scheduled more interviews with developers, told them about what I am trying to accomplish, and brainstormed solutions with them. And because these users were suffering the pain point I was trying to solve, they came up with some of the most creative ideas! That was new to me, as I’ve always thought that good ideas will come from the team creating them, not people who’d be using them. Once again, I was realizing how abundant this resource was, and how little it was being used.

At the end of the week, I had gathered enough ideas to keep the whole team busy for the following couple of years. We met to discuss those ideas, we agreed that some of them had good potential and were worth prototyping and testing.

Lesson learned: Customers may have problems, but they also have solutions.

Step 4: Prototype and test

During one of the brainstorming sessions, a user asked an intriguing question: “What would it be like for me to browse source code like I browse books on Amazon? you know? with all the social recommendation goodies!” That question inspired us to create the first prototype: the FAN (Frequently Accessed Next) – a social recommendation panel that provided users with a list of places to which previous users navigated after leaving the current location. It carried the same spirit of Amazon’s recommendation language: “People who debugged this variable also looked at the following functions”.

Another prototype was inspired by the recorded log files: users typically worked with a small subset of classes for each task, which required them to repeatedly find it through a long list of all classes. To address this, we created a customizable working set of classes that is automatically filtered to provide users with the classes they need for a specific task. Finally, we wanted to provide users with a gestalt view of their source code, so we created a heat-map UML diagram that provided users with the “hottest” areas in the in the project.

We were curious to know if these prototypes delivered on their premise, so we ran a series of experiments with seven programmers, and measured their performance with and without the prototypes. The results were significantly better.

Lesson learned: Small changes can lead to big improvements.

The prototype has since evolved into a much larger project, with several full time researchers working on it. It has also been internally deployed to help multiple product teams at Microsoft.

I feel that I can take very little credit for what’s been created: users told me about their problems, they helped me with the solution, and they showed me how well the solution performed. They deserved most of the credit!

If you are interested in reading more about the experiment and prototype, you can read the paper published at InfoVis’05 .

If you find this post useful, I highly recommend Steve Blank’s book on customer development, and Eric Ries’ blog on Lean startups.

Updates:

• I am thrilled that this post made it to the homepage of Hacker News, and stirred many conversations with great people. It’s even been translated to Japanese!
• I no longer work at Microsoft, so I can’t confirm the current state of development on this project. Feel free to contact any of the three co-authors of the paper if you’d like to schedule a demo, or learn more.
• I still consult with startups to help with user experience and product design. If you’d like to work with me, drop me a line.

Related Posts

• How to build interactive iPad applications in 30 minutes using Apple Keynote
• How to prototype desktop and web applications in 30 minutes using Apple Keynote
• Finding the G-Spot: What startups can learn from Lady Gaga

You might also like reading...

• If you love something, give it away
• Don’t be a wimp
• The catch

We then thought about raising the communication bar further, and wondered what it would be like to have clients as active participant in the design process. So we decided to invite each client to spend a full week on-site with us. During that week, the client brings marketing, business and engineering team members to our offices and we spend 5-6 hours a day together, working on the following:

• Day 1: Vision and success metrics
• Day 2: Users and stories
• Day 3: Tasks and flow
• Day 4: Ideation and brainstorming
• Day 5: Requirements and sketches

Here are some of the reasons why we believe D3 works great:

• Spending a day hearing clients share their dreams, their vision and their motivation proved to be a great bonding exercise. Being on the same page is the most valuable starting point. We fully get the WHAT and the WHY behind the project, and we become part our client’s story.
• Our design process becomes fully transparent to the client. They learn our language and they later use the same terminology to communicate feedback and requests.
• The client returns with a very good idea about how the design vision aligns with the rest of the product, with insights into many of the design detail that will be delivered over the following weeks.
• Marketing, business and engineering team members provide ideas and feedback on feature design. We found that everyone in the team can be a great design thinker, if they are placed in the right environment and provided with the right tools and vocabulary to express their ideas. They see how easy it is to capture ideas in crude sketch format, and how to express designs visually and effectively.
• Team members go home with practical design thinking lessons that they continue using as they discuss the product among each other.
• D3 is ideal for scrum and agile teams as they get to see the big picture while working on the detail. They don’t just remember features, but users and stories as well. Later on, they use personas names and stories to reference the features that they are working on. Many times we had engineers prototyping ideas that we didn’t think about, and showing them to us saying “We thought that Jessica would really enjoy having this feature when she’s picking up her neighbor’s daughter”.
• The process reduces surprises to a minimum. There are always some new ideas that we will think of when we design the detail, and more requirements that the marketing or business teams will ask us to include, but they are never disruptive to the big picture.
• At the end of the week, everyone is more excited about getting started with the prototyping process. We started the week on the same page: the problem, and we ended it also on the same page: the solution. We know we hit the jackpot when, at the end of the week, we look each other in the eye and exchange the silent agreement: We’re going to make this happen. Together.

You might also like reading...

• My four steps to the epiphany: Lessons learned from creating a minimally viable research product
• Design thinking for startups
• Malcolm Gladwell outliers – A very personal review

Act without doing;

Think without effort.

Think of the small as large,

and the few as many.

Confront the difficult,

while it’s still easy.

Accomplish the great task,

by a series of small acts.

You might also like reading...

• The eagle who lived as a chicken
• How it all began (A personal story)
• Docverse acquired: An Inspiring Success Story

You might also like reading...

• Customer Development Hacked: How to find and interview 10,000 customers in one day
• Design thinking for startups
• The Day Death Spared Me

[Update] This presentation is currently featured on SlideShare’s homepage

[Update 2] I’ve received numerous emails and comments asking about the video for this presentation. I will be delivering a webinar next month that will use this presentation as a guideline to discuss the topics covered, answer the most common questions that I received so far, and dive into some case studies. If you’d like to be notified when the webinar is available, please sign up here.

You might also like reading...

• The catch
• Don’t be a wimp
• Every man dies, but not every man lives.

After some tweaking to the fonts and colors, here is what the output looks like:

Click on the image to see it in full resolution.

You might also like reading...

• The human side of business
• My four steps to the epiphany: Lessons learned from creating a minimally viable research product
• Listening

Here is what Theresa Neil thought of the design:

Delve designers realized content creators weren’t interested in navigating through a bunch of screens to accomplish tasks. They have applied the one-screen-per goal philosophy which results in a lot less screens, each with deep interactions. To keep these rich screens from being completely overwhelming they have employed the following patterns: inline editing, dialog overlays, refining search, and progressive disclosure.

This is a very accurate description of our design goals. We were not interested in creating yet another digital asset manager. We studied the tasks that users wanted to perform at every step, and we took a task-centered approach in creating the interface and interaction. One of the unique interaction paradigms in Delve is that each screen contains a component that acts as a bridge to connect it to subsequent screens and tasks. Animated transitions are used to enforce that mental model for the user and keep them in context while taking them to the next part of the interface.

Here is a demo of Delve’s UI in action

You might also like reading...

• The Feature is Not The Experience
• Lean Interactive Requirements – The End of Specification Documents
• Docverse acquired: An Inspiring Success Story

Doctor: “I think you might have broken your toe.”

Me: “I guess so.”

The doctor moved my toe in various degrees of freedom.

Doctor: “We will probably need to get an X-Ray.”

Me: “What for?”

Doctor: “To see if it’s broken.”

Me: “What do we need to do if it’s broken?”

Doctor: “We’ll have to continue taping it together with the other toe.”

Me: “And what if it’s not broken.”

Doctor: “We’ll probably keep it taped together.”

I held myself from laughing: “I think I will skip the X-Ray.”

Doctor continued: “Okay. Does it hurt?”

Me: “Only when I walk for a while. But I can tolerate the pain and get some rest.”

Doctor: “I will prescribe some pain killers for you, in case the pain gets worse.”

I thought, “There is nothing wrong with that. The doctor is probably just doing her job.”

The reason I was reminded of that experience was that my dog was pretty sick yesterday and I had to take her to the vet. The doctor looked at my dog, asked me a few questions about what she’d been having and doing, then proceeded, without even having touched her, to list the lab tests, X-Rays, and injections that she needed to get. Then, without asking for my consent, the vet gave my dog a shot to stop her from vomiting. The rest of the day was a nightmare for me, my dog, and my wallet. But on my way home I thought, “The doctor was probably just doing his job.”

Then it hit me that this was THE fundamental problem. The doctor was just doing a job. For him, my dog and I were just part of the job. He didn’t ask me about who she was, what her lifestyle was like, and how I would like her to be treated. He proceeded with her as part of his job. For him, she was just another dog, and I was just another owner.

The reason I have mentioned E.R. at the beginning of this note is that the show has opened my eyes to something that I rarely pay attention to: E.R. doctors, nurses and hospital staff have their own lives too. They are human. They are not just the labels and functions that they carry. I had a similar experience as a child when I saw my third grade teacher in the supermarket buying food. Before then, she was a “teacher.” After that, I started thinking of her as human, beyond the label that was assumed during our daily roles and interactions.

Every day, I deal with at least a dozen people assuming various roles: the cashier at the mall, the parking valet, the clients, the vendors, the bloggers, the service providers, the telemarketer. And for each of them, I remember that there is a role that our conversation or interaction assumes, but there is fundamentally also a human being behind that role — one with a life, dreams, challenges, happiness and sorrow. And in every conversation, especially one with my clients, I don’t just assume the role that’s expected of me during that conversation. I always remind myself of the human behind that transaction – of their dreams, their challenges and most important, their humanity. And whether I am providing a service or being provided one, I like to know that I somehow have made a positive mark on that person’s life, that I haven’t just fulfill the expected part of the business, and that I’ve bridged a gap, reaching across to communicate and work on the human level.

As a designer, I am reminded that design is all about creating human solutions. Design is not applying one’s style to a problem. Design is empathy. It’s finding the most humanized solution for the problem. It’s being able to recognize that person who’s being cast as an “end user” of the product and to understand her challenges and her expectations. Great design goes even beyond that. It cares about the user’s dreams, not just her expectations. It empowers her to believe she is much better than she has thought, and she can do much more than she has done. And in so believing and doing, she can feel human again.

You might also like reading...

• Standing out – Advice from Seth Godin
• The User Journey – How to Design for Ecstasy
• Useful advice from Lao Tzu