Fake It Make It

Highlights and notes

This book will teach you a super-fast and cheap approach to prototyping and validating app ideas, before spending the time and money to develop them.

I will show you how to use Apple Keynote and Microsoft PowerPoint to create realistic interactive app prototypes that you can demo, test and outsource for development. And by “realistic,” I mean that your prototype will look and feel like a real working app when you show it to others, and it will respond to their interactions, even though you won’t be writing a single line of code.

If you can create a presentation in Keynote or PowerPoint, then you can prototype a web or mobile app using the same tool.

A prototype is an early representation of your idea. It allows you to see it, interact with it, demo it to others, and get feedback about it. Your prototype doesn’t need to show how the entire idea works; it just needs to demonstrate the core concept behind it, so you can validate it before deciding to commit your time and money to it.

What keeps most people from executing on their ideas?

1. Fear

   Most ideas aren’t as good as we imagine them to be. And that’s okay, because we will always have more and better ideas.

   But isn’t it better to just get all those good and bad ideas out of your head, and to turn them into prototypes that you can play with and show others? If they are bad ideas, you won’t waste too much time thinking about them and you’ll move on to the next ones. If they are good, you’ll figure out how to make them happen and learn along the way. And if you don’t succeed with the early ideas, you’ll learn so much that you can apply to making your following idea a success.

2. Lack Of Skills

   Another challenge that first time entrepreneurs face is that they think there is a lot to be learned before they know what they are doing, so they wait too long to start.

   While most people wait until they figure out the entire journey before taking the first step, successful entrepreneurs start moving as soon as they get an idea, and they figure things out as they go.

3. Lack Of Certainty

   A prototype helps you reduce your risks, because you’ll get early feedback and validation on something you spent a couple of hours creating, instead of spending lots of time and money implementing it.

   If your prototype isn’t the right direction for your idea, you can throw it away and create another one quickly and cheaply.

4. Running Out Of Ideas

Oftentimes, the idea you start with isn’t the one you end up with.

If you can’t see it, interact with it and show it to others, you can’t improve it or change it.

Prototyping is what breathes life into an idea.

The first step to take after choosing an idea to prototype is to write a few stories that capture how people would use your future product to accomplish their goals. Write a couple of paragraphs that describe what people can do with your product, rather than how your product works.

The next step is to review the stories you’ve written, and to list all the tasks users can perform with the app. A helpful guideline here is to think of each verb in the stories as a task.

Next, create a list of screens where these tasks can be accomplished. You can combine a series of tasks into a single screen, or you can have each task accomplished in a separate screen for now. Good design is iterative; so don’t worry about getting it right the first time.

Once you have a complete list of the app screens, you need to draw a diagram that shows how users will move from one screen to another. This will help you create the menu and navigation later on, and will also help you validate further steps of the design process by walking through this diagram to make sure what you’re prototyping matches the user flow.

The best way to design a user interface is to first sketch the layout and building blocks of each screen using broad strokes, and then gradually add details.

If you’ve never sketched app screens before, here’s the best way to get started: grab a marker and some papers, and spend a couple of hours copying existing apps. Copy screens from your favorite mobile and web apps, from popular app screenshots on Dribbble, and from design pattern sites like PatternTap, Pttrns and Mobile-Patterns

Here’s my best trick for sketching and storyboarding apps: Get a bunch of blank index cards (small for mobile, and large for web), sketch screens on the front of each card, and I write notes and ideas on the back.

Whatever technique you use, remember that you’re creating this blueprint for yourself, not to show others. Your sketches or blueprints don’t need to “look good”. As long as they capture your ideas for each screen layout, they are good enough.

One of the tricks that helped me become a master-prototyper is that I spend at least an hour every day browsing websites for great app designs. Whenever I find a design that I like, I add it to an “Inspiration Board” notebook on Evernote or a board on Pinterest. And if I find a design that I really like, I re-create it in Keynote, so that it becomes part of my prototyping vocabulary. If you want to become good at designing app interfaces, copy an app screen every day. Start with the apps you already use and like, then move to popular UI shots on Dribbble, PatternTap, Pttrns and Mobile-Patterns

if you’re working on a client project, wireframes might be necessary to get approval on the functional direction and layout direction of the app. High-fidelity prototypes sometimes confuse clients, because it’s difficult to give feedback about the app’s functionality and screen layouts, without giving feedback about fonts and colors. If, on the other hand, you’re prototyping your own app, wireframes might be a waste of time, because you’re better off testing a prototype that looks close to a finished product, even if it doesn’t reflect the final visual direction. Consumers use apps, not wireframes, and showing people app wireframes to test might confuse them.

How many features should you prototype?

The good rule of thumb is to remember the problem you’re trying to solve with your product, or the core idea you’re trying to visualize, and focus on that. Figure out what MUST exist in your prototype, and eliminate everything else. The simpler your first version is, and the more focused it is on solving the core problem, the more success you’ll have.

You can add more features later on, but don’t add too much too early. Having a simple product, with a few well-designed features, helps you get better feedback.

Your product is simple, not when there are no more features to add, but when there are no more features to remove, without impacting its main purpose nor its ability to solve the core problem.

The best apps are the quickest to understand and the easiest to use. One of the keys to achieving this is having a simple and intuitive interface.

However, trying to create a simple interface early on could be paralyzing. It’s better to develop your first interface to include all the features that users need to accomplish the core tasks, then iterate multiple times to simplify it.

Here are a few ways to accomplish simplicity: Grouping: gather related actions together under a single menu Contextualization: only show the actions and interface components that are relevant to the current state/context of the app. Hide everything else Elimination: Remove things that users don’t need for the core tasks (keeping your love of a feature out of the equation allows you to simplify things faster.) Collapsing: make frequent sequences of actions into a single action (e.g. every time a user creating a new post ends up tapping the camera icon to take a picture, make it so that posting a new item automatically turns on the camera to take a picture)

As you’re adding the hyperlinks to your screen, check that your app navigation is working correctly by running your presentation in slideshow and clicking through it.

In Keynote, you need to specify that the presentation should run in “hyperlinks only mode”, so that you won’t accidentally advance to the next slide by clicking a random place on the slide.

Apple Keynote comes with two different types of animations: transitions and builds. Transitions are animations between slides, and builds are animations within slides. For instance, if you want to flip a screen to reveal the next one, you need a transition. If you want a circle to move from one location to another when the screen loads, you need a build.

To make things simple, the animation you would be using 80% of the time is the Magic Move. This animation figures out how shapes change location and properties from one side to another, and animates that change so that transition is smooth.

A good rule of thumb to remember here: if animations make your interface usable and fun, too many animations will make it more difficult and less fun to use.

Keynote offers another great way to export your prototypes as interactive HTML5 files and JavaScript code. This preserves hyperlinks and animations, and you can load up the exported HTML file into any browser and use it without needing any additional software.

If your prototype MUST use live data to work, then prototyping with Keynote or PowerPoint isn’t the right approach for you.

If you want to have someone type their username and password to login, or search a catalog for a specific item, how do you do that when all we have in our prototypes are just static screens? The trick here is do the input for the users: To show them a before and after screen.

Once you’re done with a couple of initial prototypes that capture your idea, it’s time to go and get real users’ feedback.

Your first prototype is seldom the best one. James Dyson created 5,127 prototypes before he got his first vacuum cleaner right.

Here are some tips to help you test your prototypes with real users:

• Choose users from your target audience (people who would pay for your app when it’s developed), rather than testing with friends and family. Pick people who will give you honest feedback, rather than people who want to be nice to you.
• Create and test different prototypes at once. This makes users more comfortable giving you objective feedback, rather than feeling that they are “judging” your work. Testing different prototypes also helps you figure out what works and what doesn’t in each one of them.
• Decide which features you want to test, which tasks to give users to test them, and how you’d measure success.
• Let the users know you’re testing how well your prototype works, and not how smart they are.
• Don’t tell them how your app works. Just tell them what it is about, and let them explore and use the interface to see if they can figure it out on their own.
• Ask your users to think aloud while they are using the prototype and performing tasks.
• When you’re done testing, ask users some questions about their experience with your app, what went well, what went wrong, and what they would do differently if they were to redesign the app.

If you create a wireframe or low fidelity prototype to validate your idea, you need to redesign the screens from scratch in a design tool like Photoshop or Sketch.

Once you have your final prototype ready for production, fire up your screen-recording software (I recommend using ScreenFlow on the Mac, or Camtasia on the PC), and record a full walkthrough of your prototype with voice-over. Explain every part of the interface, how the user will interact with it, how it handles input and errors, what the different use cases are, and how the backend should provide data. Divide your walkthrough into several video segments for each feature.