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

• The human side of business
• [Video] iPhone running an interactive Keynote prototype
• Delve Networks ranked among the top 50 Most Usable RIAs

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

• Useful advice from Lao Tzu
• Finding the G-Spot: startup lessons from Lady Gaga
• Docverse acquired: An Inspiring Success Story

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

• The human side of business
• Is your product a “hot chick”?
• D3 – Designing with Clients

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

• D3 – Designing with Clients
• Purpose
• [Video] iPhone running an interactive Keynote prototype

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

• Useful advice from Lao Tzu
• Standing out – Advice from Seth Godin
• From corporate design to startup design: A love story

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

• Design thinking for startups
• Don’t be a wimp
• The Apple Hierarchy of Needs

“… I want to own that moment.”

I started thinking about which successful products own which moments in my daily life. Here are some examples:

• ” I want to share some files with my team”. DropBox owns that moment
• “I’d like to show you how I am imagining this interface”. Balsamiq owns that moment
• “I want to embed a form in my blog”. Wufoo owns that moment
• “I want to create a cool slideshow for my website”. Animoto owns that moment
• “I am starting a new client project”. BaseCamp owns that moment
• “I’d like to know what my friends have been up to lately”. Facebook owns that moment
• “I’d like capture some thoughts.”, Evernote owns that moment.

You get the point.

Unfortunately, many products come out so bloated with features that it’s hard for them to own any specific moment. They are trying to offer too many features and several benefits that users are left wondering “When will I need this?”.

I believe that products should focus as much on WHEN as they focus on what and how. If your product is the first name that comes to mind at a specific moment, then you’ve owned that moment. And when you own a moment, you don’t just have a user; you have everyone involved in that moment.

So how do you identify that moment?

You can guess it, of course. But that’s not the best way to go about it.

One of my favorite activities is to ask users to think aloud while they are trying to accomplish certain task. I constantly encourage them to tell me what’s going on in their mind while they are looking at an interface or clicking through dialogs. After the task is done, I ask them more questions about that moment. Why were they struggling with that screen? What were they looking for? Why didn’t they try to accomplish it another way? What would have been the best way to accomplish that?

When I identify a recurrence of that moment, I make sure it goes into the user stories and is highlighted as a potential moment that the product can own. When marketing and sales are consistent with these stories, they can provide a clear message that will trigger the product’s name when someone finds themselves in that moment.

You might also like reading...

• My four steps to the epiphany: Lessons learned from creating a minimally viable research product
• Customer Development Hacked: How to find and interview 10,000 customers in one day
• How it all began (A personal story)

One of the most useful design practices to create good landing pages is to visualize each website visit as a journey that leads users to a destination. That destination is not just a goal that the user needs to accomplish, but also an emotional state that the user would like to experience.

It’s important to understand that the journey doesn’t typically start when the user reaches a product’s homepage. It starts earlier, when she identifies a need to have or accomplish something, or when she finds a recommendation from a friend or blogger to try a new product. When she comes to the site, she will have many questions in her head that she wants answered.

There is a wide range of emotions that users experience during a website visit, including: indifference, boredom, confusion, disappointment, curiosity, engagement, and ecstasy.

Let’s look at how a good design can create an ecstatic user experience:

Our journey starts with Danielle doing some search on Google for a solution she needed for her small business. She’s already visited various websites and looked through many alternatives, and she finally clicked that link that’s taking her to your landing page. She reached that page feeling a bit bored, somehow curious, and a bit more skeptical. She took a quick glance at the page, knowing that it usually takes her about 5 seconds to realize whether or not she’s found what she’s been looking for. At first glance, she saw a tag-line that grabs her attention. She read through the story below the tag-line, and she found herself relating to it. The story didn’t talk about the product. Instead, it talked about her! Next to the story, she found a screenshot that showed how the product will help her through her challenges. She became more curious to learn about what the product was offering her, so she started reading further. She liked how the information was presented: No marketing jargon, no mention of “innovative” or “revolutionary”, and no one trying to sell anything to her. It was as if someone had already anticipated the questions she had in mind about the product and answered them directly and simply. She felt as if she was having an engaging conversation with the person who designed that page. And she liked that person, and the conversation she was having with him.

She finds a “Try It Now!” button and clicked it. Based on her experience with previous products, she expected herself to land on a page that compares plan options, or at best, a sign up form that she needed to fill out to try the product for free. She was happily surprised to find herself face to face with the actual product, and with real data that put her immediately in the driver’s seat. She loved how the product had the exact features she needed: No more, and no less. She also discovered that the features she’s been using the most are carefully laid out to be easily reachable and quickly executed. As she tried each feature, she started experiencing fast results that she’d been looking for. At that moment, she realized that the product would save her a lot of time and she was ready to take out her credit card and happily pay for it.

In contrast, here is what it feels to have a disappointing user experience:

While reading through a product review blog, Mark stumbled upon a product that seemed to offer a solution for a challenge he’s been struggling with. He clicked the link and landed on a page with plenty of text and pretty looking graphics. The page had a bold tag-line, a product pitch, screenshots, video tour, a list of unique selling points, client testimonials, and even quotes from the press. He felt overwhelmed by the amount of information on the page, and confused about what’s in it for him. The page was all about the product, not about him. Among other graphics, a bright “Try It Now” button jumped at him, so he clicked it. To his disappointment, he found himself facing a grid of plans, options and prices. He was surprised that someone expected him to take out his credit card without giving him a good idea about what he would be paying for. He scrolled through the plans and found a tiny link at the bottom of the page that granted him limited free access to the product. He clicked it and realized that he had to fill out a long form to access the product, and he did so patiently. He felt that he already gave this product too much of his time, and received nothing in return. His disappointment turned into frustration as he stared at the message asking him to check his email to activate his account, and his cursor found its way quickly to the x icon on his browser’s tab.

Here are some notes about how to design for ecstasy:

• Understand where your users are coming from, and what they need to know.
• Design pages that anticipate and answer their question in a simple and direct manner. Avoid marketing jargon.
• If you’re saying more than one thing, then you’re saying nothing.
• Give them instant gratification, before you ask them to sign up or pay. Make the “Try It Now” button a “Try It NOW” button.
• Enable them to experience the product with real data. Don’t give them a blank canvas and let them figure out how to use it.
• Make it easy for them to accomplish something you already know they need to.
• Understand that it’s about them, not about you.
• Don’t give them a product that just enables them to accomplish a task, but also enable them to feel good while doing it.

You might also like reading...

• Listening
• The monkey trap
• The Apple Hierarchy of Needs

When I started using the application, I liked the visual skin of the application but was frustrated by its usability: the application, as shown below, dedicated the largest screen real-estate to a giant microphone icon, and placed the functional buttons of the app in the two bottom corners, occupying less than 5% of the screen space.

What’s wrong with this?

One of the fundamental laws of interaction design is called Fitts’ law, which states that the degree of difficulty to reach a target depends on the size of the target and the distance. This means that further and smaller targets are harder to reach than closer and larger ones. In the voice recorder example, the most frequent target is the record/pause/stop function, which should be the largest and closest one.

This becomes very important in contexts where it’s important to build good muscle memory for that frequent action so that one doesn’t need to look at the device to perform that function. With the voice recorder application, I typically need to look to locate the button, and look again after tapping it to see if I hit the right target and can start speaking. And that’s not safe.

What’s the fix?

Make the microphone clickable. When clicked once, it should record, clicked again it should pause/stop. When recording, the microphone should glow a saturated color that shows with a quick glance the state of the application.

I remember my first Human Computer Interaction quiz, we were asked to redesign the Windows start button to make it work best according to Fitts’ law. Given that there were no other requirements to the design, the winning solution was to make the button occupy 100% of the screen. This way, the degree of difficulty in reaching that button is zero.

Note that this is not the first time Apple violates this law. The tiny close/minimize/maximize icons on the top left corner of each application are good examples of tiny buttons that are responsible for frequent tasks, and that require precision to hit.

Next time you’re designing a button, please make sure it Fitts.

You might also like reading...

• Adobe Flash Catalyst – First impressions
• The catch
• If you love something, give it away

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

• From corporate design to startup design: A love story
• The circus elephant
• How it all began (A personal story)