I wasn’t surprised that developers didn’t like reading them. Spec review meetings used to feel like one of the scenes from office space – and I didn’t even have my red stapler.

An interesting shift happens when a fellow PM started prototyping instead of writing specs. And because we were basically creating a prototyping tool, he was testing the tool along the way. Dog-food’ing, as we used to call it at Microsoft. I followed his footsteps immediately. And not only I was having a lot of fun creating prototypes instead of writing requirements, developers were having fun using them and providing feedback, and spec review meetings went by like a breeze. Instead of spending time on making sure everyone understand the description of the interaction, everyone was on the same page much faster.

Needless to say, the final product matched the interactive requirements far more than it ever did with written spec documents.

As I recently started using Keynote to create interactive prototypes, I found more startups teams willing to use the prototype as their requirements. I realized that Keynote is ideal for this task.

Here is how I use Keynote to capture and communicate requirements

I won’t go through the detail of creating an interactive prototype in Keynote, as this has been covered in several previous posts. Once you’re done iterating on the prototypes, it’s very easy to annotate them in Keynote using comments and presenter notes.

Comments are sticky-notes that you attach anywhere on the slides to indicate a special case for user interaction or a message for development or testing teams.

And presenter notes are great way to track discussions on a specific screen or interaction.

The best thing about this workflow is that neither presenter notes nor comments show up in slideshow mode. So they won’t be interfering with the actual interaction when the prototype is being tested.

You can also export to PDF with presenter notes included, and still maintain the interaction within the prototype – in this case, the sticky notes will not hide/show nicely in slideshow mode as they do in Keynote. This is a screenshot of the PDF export:

If you’ve been writing long spec documents, give Keynote a spin. This is the lean approach to capturing and communicating requirements. And you don’t need to use different tools to create your prototypes, take screenshots, embed them in documents or wiki, and make sure the screenshots are synchronized with written requirements.

If you’ve been using better tools/techniques for faster requirements, please let me know about them in the comments.

You might also like reading...

• Design thinking for startups
• Don’t violate fundamental design laws – even when you are Apple
• If you love something, give it away

I’ve finalized the Keynote iPhone template, and currently putting together a comprehensive guide with tips and tricks that should help you get from an idea to interactive prototype on iPhone and iPad in less than 30 minutes.

Here are some of the assets that I’ve used in that prototype:

Over the past couple of weeks, I’ve created different Keynote theme packs for iPhone, iPad and web apps. I’ve also created a generic freehand theme pack for putting together low fidelity wireframes and prototypes.

You might also like reading...

• Purpose
• How to spot a good designer in an interview
• The eagle who lived as a chicken

First, let me thank you for all the feedback that you provided about the iPad keynote prototyping. I hope that the hundreds of developers who downloaded the theme template are finding it useful.

As promised in the last post, here are some additional assets (all created in Keynote) that I’ve been using to rapidly prototype web applications and demo them within my presentations.

Once you download the Keynote template file ( link at the bottom of this post), install the file “Web Theme.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.

You might also like reading...

• From corporate design to startup design: A love story
• D3 – Designing with Clients
• Is your product a “hot chick”?

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

• Design thinking for startups
• The User Journey – How to Design for Ecstasy
• From corporate design to startup design: A love story

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

• The Day Death Spared Me
• The human side of business
• Malcolm Gladwell outliers – A very personal review

You might also like reading...

• Useful advice from Lao Tzu
• Every man dies, but not every man lives.
• Lean Interactive Requirements – The End of Specification Documents

What’s unique about Docverse’s user experience is that it never tried to change the way people did something. Instead, it tapped into people’s existing habits and workflows to provide them with easier, faster, and more secure way to share and collaborate on their documents. We carefully observed how people already used email attachments, how they changed and saved documents, and how they previewed and merged each other’s changes. Andwe brainstormed for days at a time about how to make every part of that workflow better, without forcing users to do anything different, and sometimes without asking them to do anything at all. The best user experience was to have no user experience: the more transparent the product became, the more users were focused on the main task: editing a document together. It was the document, not the product, that’s always been the center of the universe.

Docverse just works.

I am grateful for having the opportunity to work with this amazing team, and being part of that great journey that started less than 18 months ago with a spreadsheet of ideas, to sketches and designs hanging all over the green walls of their Howard street office, to a functional product, and finally, to a successful acquisition. It’s been a true rollercoaster ride through a unique and inspiring Silicon Valley success story.

I blame Docverse for raising the standards of what I will be expecting from technology teams to make a user experience, no matter how challenging, come to life.

You might also like reading...

• Standing out – Advice from Seth Godin
• The secret life of ideas
• Every man dies, but not every man lives.

One day, an elephant came to the village.

Since none of them had ever seen an elephant before, they all gathered around the animal to figure out how it looked like.

The man who touched the trunk said: "An elephant is like a thick tree branch".

"No! It’s like a pillar," said another who touched the leg.

"You’re both wrong!", said a third who touched the tail, "the elephant is like a rope."

"Oh No!", shouted another who was feeling the belly, "it’s like a wall"

And a man who was touching the tusk said "Come on, guys! The elephant is nothing but a solid pipe".

They began arguing and fighting, and each of them insisted he was right.

They were getting agitated and frustrated at each other.

A wise man was passing by the village, when he heard the shouting.

He stopped and asked: "What’s the matter?"

So they told him that they could not agree about what an elephant was, and each told him what he thought it looked like.

The wise man smiled and said:  "

All of you are right.

But because each one of you touched a different part of the elephant,

you all had different images of what an elephant looked like.

And because each one of you imagined an elephant through his own experience,

doesn’t mean that the other person’s image of the elephant is wrong.

An elephant has all the features that you described, and much more.

But you can never tell what an elephant is by just touching one part of it."

Let’s not forget that each of us is looking at a different version of reality; a small aspect of life that’s colored with our own perception and experiences.

The more we accept to see life through other people’s perspective, the richer version of it we will have.

Photo Courtesy of Ashes and Snow

You might also like reading...

• The eagle who lived as a chicken
• Purpose
• Is your product a “hot chick”?

Here is one of the traditional methods for conducting customer interviews:

1. Make an educated guess about your target audience’s demographics

2. Look in your contact list and social network for people who might match your criteria

3. Create an online survey and send them to these people. (better, ask them for a phone interview)

4. Ask for more recommendations and introductions.

The biggest flaw with this method is the assumption that your contacts provide a valid sample of your target audience; At best, you might get few answers that help you refine your questions, and your criteria for interviewing future, and at worst, you might end up believing the wrong answers because they happen to support your idea.

So what’s a better strategy?

Start with the tribe leader, because his voice is worth 10,000 voices. This person might be a bestselling author, a blogger, or one of the top consultant in the field. What’s important is that this person is seen as a leader and expert by your target audience; they listen to him, they trust his opinion, and they share their thoughts and feedback with him.

For instance, if you’re working on a new presentation tool, Garr Reynolds would be a great example. If you’re creating the next agile project management tool, Mike Cohn might be your guy.

Keep in mind that this expert is not just a tool expert, but a community expert as well. He uses best practices, works with the tools, and knows other people who use them.

Why is his voice worth 10,000 voices?

• He reads dozens of books on the topic, so he might save you the time to read them by sharing his insights and conclusions, or by recommending the most useful ones to read.
• He interacts with your potential audience on a daily basis; he writes for them, he reads their comments, and he speaks to them in conferences and seminars.
• His blog analytics provides him with great insights about the audience’s demographics, which he might be willing to share if you ask nicely
• He knows other experts in the field that he can introduce you to
• He knows his active readers, and can suggest some people for you to interview
• He is a power user of other products in your market, and already knows what people like and dislike about them
• He probably knows your potential competitors, and some of their current and previous employees

Once you’ve identified the tribe leader, get in touch with him and ask for an interview. Keep in mind that his time is valuable, so you will need to find a good incentive to get his attention: If the person is offering consulting services, hire him. If he’s a second degree connection on LinkedIn, ask for an introduction from a common connection. If you’ve already started a blog on the topic – which is a great way to find early customers – then ask the expert if he’d like to be featured in an interview on your blog.

When you interview the customer expert, make sure you ask him questions about him and his audience. Keep your interview questions open-ended to give him a chance to share wisdom and insights that you didn’t ask about. Find out what his readers like and dislike, what they read, where they hang out, and what they buy. Ask him for introductions to other experts and active community members that you can interview later.

By working earlier with this community expert, you will find that he may be able to provide you with insights that would otherwise take you a long time ,and a large number of users, to get on your own.

And if you continue to work closely with the community expert, and you’re creating something that he (and his followers) care about, it’s likely that he’ll give you a good mention on his blog once you’re product is out. That’s probably worth 10,000 more voices.

Interviewing the leader is not a substitute for interviewing other tribe members, but it’s probably one of the best ways to get started.

This blog post was partly inspired by an insight from Tyler Perry’s biography (recommended), where he talks about the turning point in his career. After he’d exhausted all his financial resources seven years in a row, and couldn’t find audience for his plays, he finally went about it a bit differently: he visited the city’s churches and persuaded their most powerful musicians and choir members to take roles in the production of his plays. The opening night was one of the coldest nights in Atlanta, yet there was a line around the corner trying to get in the theater. His show sold out that night, and almost every night since then. Perry hired community leaders, and made them into cast members. That made all the difference.

You might also like reading...

• The Day Death Spared Me
• Design thinking for startups
• Every man dies, but not every man lives.

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

• 2008 – A year in review
• Don’t violate fundamental design laws – even when you are Apple
• Malcolm Gladwell outliers – A very personal review