Design & Test

It's time to start building. You have an idea. You have a plan. Now you need a product.

But there's one more step before diving in and coding (or having someone else get started). Right now, it's time to start building a design – creating a layout of what this is going to look like and how you're going to make it a reality.

This is the dry run that will save you an IMMENSE amount of time if done properly. And the best part? All you need is a pencil and a piece of paper.

Pencil Sketches

A pencil sketch is exactly as it sounds. It's a drawing of what your app will look like. A hand drawn wireframe of the app from start to finish with multiple screens and the ability to "test" functionality in an extremely low risk, zero cost environment.

Basically, it's a way of working out the kinks before you get anywhere near a keyboard – this process can save you THOUSANDS of dollars. It's that important.

And if you think it's just first time startup founders out there drawing on napkins, consider the number of famous startups that began as a sketch on a piece of paper.

This gave the founders of those companies time and opportunity to review what works and what doesn’t in a format that doesn’t cost them a penny.

You're going to do the exact same thing.

Another reason I love the idea of a pencil sketch is that it can be reworked fast. You can erase what you don't like or just rip it up and start over again if it really doesn't get the job done.

It's also an extremely effective way to avoid feature creep early on. When you see just how many more "screens" you have to draw out when you think of a new feature, you start to understand how much more development will be required to make your ideas a reality. It's costly and time consuming.

And all of it is free, so yeah, you have no excuse not to do this.

Sketching Out Your Idea

This is as simple as it sounds. You will quite literally be sketching out your idea. What will your app look like and how will it operate?

Don't worry about how to turn what you're drawing into a reality. Don't worry about the cost of the development process. Don't worry about the time it will take to build something. Just draw what you see in your mind.

This is the free writing of business development – it allows you to make changes faster and more hands-on than you could on a computer screen. There's something immensely satisfying about having these things in your hands and manipulating them without a keyboard or mouse in the way.

And as you get started, don't be afraid of messing up. In fact, I highly encourage you to mess around and try to mess up. Make mistakes. Take stupid risks and see what happens. Add big features to see just how badly it breaks the app.

Only by seeing how big of a pain in the ass these mistakes would be will you be able to learn from them and start creating effective drawings that will eventually translate into your finished prototype.

The bottom line? You're not going to get it right the first time.

There is no wrong answer – there are a lot of bad ones (adding features for example), but nothing you can't or shouldn't try to do in this setting. Have fun with it.

Use Your Drawing Like Software

Here's where things get really interesting. The drawing part is easy. You put on paper what you see in your head – simple, yeah?

But now you have to use it. Run through the software step by step, tapping the paper and moving it to correspond to screens of the process. If you tap something and there's no paper there to shuffle, draw a new one.

You'll end up with a pile of papers that link to each other in the end, but this is exactly what you need. A clear idea of what it looks like to go from step one to step two to step three, back to step one and on to step four seamlessly in your eventual interface. Better to find out now than when you've already paid thousands to have it developed that something doesn't work.

This will feel immensely silly at first. Don't worry about it.

Trust me when I say this works extremely well and will become an integral part of your development process.

Just like reading an essay you wrote aloud, this is one of the most effective ways of finding your mistakes and making adjustments to the work you're doing BEFORE you get to the point of making permanent commitments to any one part of the process.

Taking Notes

Keep your laptop nearby or another notepad of paper you can write on. You're going to need it.

Every time you find something that doesn’t work, a feature that you like but know won't work in this version, or a problem that might pop up during development, write it down.

Keep a couple of different lists here too. One for potential problems or development notes and another for features and functionality that you can't add just yet.

This is so important because otherwise you're going to come back to these hand drawn notes later and not remember a damn thing about what you liked, didn't like, or couldn't make work. It will be a huge waste of time.

And you'll probably end up trying to incorporate more features than you really should.

Your lists will become a major part of the next stages of development and will probably grow and change over time – one reason you may just want to keep a list on your computer for now.

Rinse and Repeat

Don't do this just once. What you're creating is a working, hand-drawn model of how your project will look and feel when finally built.

It's not something you get right on the first try, no matter how many times you've run through it in your head.

And if you just thought of this idea three days ago? You're going to need a few runs through this before you start to develop a clear idea of how it's going to eventually look.

How many times is enough?

It really depends. You should be able to go through the tapping and testing process of running through your software without any major hiccups or surprises a couple of times through before you stop. And even then, this is an iterative process – you're not going to be "done" for a long time.

The Feature List

It's one thing to plug features into your drawings to see what happens, but let's face it – too many features will make this project a headache.

The last thing you want to do is add features that don't need to be there to your project. It's going to drag things out, cost more, and create a development and testing nightmare that you'll never be able to get through.

So you create a list of features instead.

A good feature list will do a few things:

1. Prioritize Features – You're going to have a lot of cool ideas over the next few weeks. Write them all down but don't feel like they need to be done now. Create a master list and the more interesting or in-demand a feature becomes, the higher on that list it can be placed. This is how you'll avoid over committing without giving up on the cool stuff you're thinking of doing.
2. Help You Strip Out the Unneeded – The core functionality of your app should do one, maybe two things and do them very well. If you find yourself with an app that does a dozen different things and you can't make them work together without getting a headache, you have too many. Cut them out and strip it back to bare basics. Use your list for that.
3. Put Your Mind at Ease – The list means the ideas aren't forgotten. They exist, they are ready to be worked on, and they can be integrated back into development…later.

One last note on the use of a feature list in development. New features always take a back seat to bugs and other issues that actually keep people from using your app as it was originally meant to be used.

All the more reason to avoid adding too many features too early. If you have a bunch and they keep breaking, you'll be stuck fixing bugs forever. Get the basics down first and then worry about bells and whistles.

Testing

One of the reasons this day is set aside for the hand drawn maps is to ensure you have ample time and resources to test your ideas before you ever start creating your product.

It's hard to test something that doesn't yet exist, of course, so that's why we draw it out. In the course of the next few days you're going to be building the initial prototype of your product and that means you'll need to have something in place in advance that you can learn from.

Some sort of user feedback and personal insights that can guide development of your project. Testing with your drawings allows you to do just that.

Self Testing

We already talked about this a little bit. Self testing is your chance to tap through each page of the documentation you're creating and see if it works the way you want it to.

This is where you take notes on things like how transitions will look, what happens when someone enters a strange combination of commands, and how the navigation will work from the top down.

It's also how you start making tough decisions about what will stay in your app and what you'll strip out to make it something that can realistically be built on your budget.

Friends and Family Testing

Here's the trickier part. You need to sit down members of your family and friends and ask them to do the same.

This is so important that it's not optional. You need that feedback and you need it in a format that will allow you to get your app into a better format before it starts being built.

Have your friends and family sit down and click through your app on paper. Give them a notebook or sit there with them and take notes. Yes it's silly – feel free to admit to them that it's a silly endeavor. Buy them some pizza for the help.

I guarantee, though, that no matter how silly it feels and how much razzing you get from your friends and family (hopefully none), you will learn something from this in a way that you never could from doing it on your own.

This is where you'll need a third list in your notebook – the questions.

As people go through your papers and attempt to "use" your app, they are going to have a lot of questions.

• Why doesn't it do this?
• Where is the button for this?
• Why not just do this instead?

Some questions will seem silly. Others will be enlightening.

You would never turn in an assignment without at least one person having proofread it. Neither should you start building your app without at least one person looking over your sketches.

Is one person enough? Ideally, no. I'd recommend getting at least three people to go through this exercise and compile their notes. The last thing you want is to change direction and adjust how you approach this project based on the advice of one person. What if they were confused? What if they have a strange bias in how apps run? What if they are a technophobe? Don't let one opinion drive your development (even your own).

Get five people, take notes on their questions and build a better app. Trust me, this will be well worth the time spent getting them to sit down and help you.

Telling the Story of Your App

Other than visualizing the app you are trying to build, what is the point of all this? Why spend an entire day drawing everything on paper when it needs to be crafted in a digital format eventually?

Throughout this process, you're going to find numerous instances in which you are surprised. The development process can only be planned so much – surprises are bound to happen, but every surprise, revelation, and feature swap is going to cost you both time and money.

The more time you spend now developing a clear idea of how this is going to go, the less of an impact such situations will have.

More importantly, though, you're learning the story of your app. Every piece of software has a story to tell – a process through which you guide your users when they tap the icon and open on their phone, tablet or computer. That story – the feeling that your software evokes and the process through which you put your users – is going to be integral to the development process.

It's what you need to convey to your developer or keep in mind if you are doing the programming – and without this step it's that much harder to both understand and communicate that journey to the user.

Even with a script in hand, directors don't shoot movies without every scene mapped out in advance. Storyboards are a must – to the point that they are often done multiple times for the same film as the filmmakers realize at each step of the process that changes are needed. It's a flexible, low cost way to visualize the finished product without committing the big money to the process.

It's going to be one of the most important things you do in preparing to create your app. It's also frustrating and tends to be something even the best developers skip over some parts of. I implore you not to do that.

Hand Drawn Wireframes

Up until now, what you've been drawing is a visualization of your app. It's what you see it looking like when it's done.

But a wireframe is a bit more technical. A good wireframe will visualize the pieces of an app from a visual and functional perspective.

Wireframes are used for web development, app development, and just about anything else with a comprehensive user interface.

There is software to create these and I recommend moving to that step next if you find yourself with an app that will have multiple screens or if you are going to be creating a hybrid app that needs to scale to different screen sizes. But for now, the hand drawn route will get the job done.

These are what your developer will reference as they start building out the core of your app – using them to guide him in the dimensions and other aspects of design in the app. So it's important that you have at least a good idea of what you want this to look like.

As such, don't be afraid to rip these up and start over at any given point. Draw, redraw, and throw away as many times as is needed to get to the point that you feel good about what you're handing off to the developer. This is the brief, the directions, the walkthrough for what he's going to build for you – if you don't spend a good amount of time on it, it's no one's fault but your own when it comes out looking like crap.

How Much Detail Do I Need?

To be honest, there's no such thing as too much detail in a hand drawn wireframe. The more detail you provide, the more accurately your developer can create a finished prototype that actually looks and feels like what you originally drew and tested with friends and family.

Here are some specific things to keep in mind when creating your wireframes.

• Annotate Heavily – Your wireframe is a blueprint. It's the plan by which your app will be built. So don't be afraid to annotate heavily in your drawings. Hand written notes, arrows to show the direction animations will flow, and numbers to indicate the change in size an element will see when swiped – these are all important.
• Use Other Apps – Choose a handful of apps you like the design of and use them heavily. Go through every screen, tap and swipe every element. See what happens and what doesn't happen. This isn't to get ideas – hopefully you have plenty of those already – but to make sure you aren't skimming over something simple that your developer would need to know.
• Reference Inspirations – If you're going to stick with just hand drawn wireframes, you probably won't have a Hi-Fi version to show the developer. So provide him with links and references to the examples and resources you really like. The stuff that you referenced when creating your wireframe and that he can reference in turning that into a working prototype.
• Wireframe Everything – Don't skip "basic" stuff like login pages or settings menus. Have everything clearly outlined in advance to avoid having to double back later. Don't be lazy.
• Make Note of and Look for Repetition – Repeated elements in your wireframe will make it easier and faster to develop the app and easier for your users to use it. Look for things that can be reused across different screens and make note of it.
• Make Note of Dependencies – A wireframe for a shopping cart page does you no good later if you end up using a third party service to power your shopping cart and the dependency requires changes to the layout. Do your research now and indicate where changes can be made down the line.

There are a lot of things to consider here. Two basic rules you can follow though – outline everything that could possibly be in your app and take copious notes. If you do those two things, you'll eliminate the vast majority of potential issues that might crop up down the line.

Screen Mapping

Up to now you've been drawing individual screens with notes about how they interact and react to user input. Those wireframes will serve as the blueprint for the developer – they are incredibly important.

But equally as important not only to the development process but to the user experience is the flow of those screens.

How are they going to interact with each other? How many taps does it take to get back to the home screen? How buried is the settings menu? Can the user find the most important features quickly when in a rush? These are all extremely important and can be mapped out in advance with a little bit of screen mapping.

Every app has an inherent flow to the way information is contained and connected to different parts of the app.

Again, it's all about visualizing complex information at this point – this is the easiest way to do so.

Step 1 – Identify the Model

The model is the highest level of this process – what basic high level information is included in your app and how does it interact with other components?

This is a basic app that does one thing – it has five elements. Simple enough.

Step 2 – Screen List

Once you know the high level architecture of your app, you can create a more comprehensive list of screens.

With Twitter, for example, the information model involves the X steps we listed above. But if you were to list out all of the individual screens that are available it would be much longer.

This doesn't include some of the more advanced features either – advertising, API access and DMs aren't included but could be if you were doing this from a very high level. Even the mobile app has a fair number of screens to include in this map:

Step 3 – Screen Mapping

Once you have your comprehensive list of screens you can start mapping them out to show the relationship between those screens. This is a step further than the information model you created in step 1 because it shows how every screen in an app relates to the others.

Step 4 – Combine with the Wireframes

Finally, you can combine the screen map you just created with your wireframe. When paired, the two offer a fairly comprehensive blueprint for your developer. He now knows the order in which screens will display, what each screen will look like, what the purpose of that screen will be, and any other special instructions you provided within the screen's notes.

There's more you can do in this stage, especially as it pertains to the digital components. But you don't need to.

At this point, if you have the screen map and the drawn wireframes, you can start the application building process.

Avoiding Feature Creep in the Screen Mapping Process

There will be times as you map out your app when you realize there is a gap. Something that makes sense to include or that would greatly enhance the user experience if included.

Don't do it.

The risk of feature creep is worst at this stage when it's all theoretical and makes perfect sense in your drawings. The more you add, however, the higher the risk that you'll overburden your project and reach the point that you fall behind in development.

This is where your feature list comes in the handiest and where you should very consciously step back from the ledge when a new feature looks you in the face.

Instead, make notes where the new feature would best fit and patch it in the meantime. You can even create a separate drawing showing what it would look like to include that feature in the future and then set aside your screen map for future reference when you have the resources to add that feature in.

Whatever you do, though, don't add the feature to your list…yet.

Storyboarding the Journey of the User

A storyboard is more about the process and how the user will get from Point A to Point B in your app. Rather than showing the path, this illustrates what that path looks like.

Sounds the same, right?

It can be. Honestly, if you feel comfortable with a screen map and your wireframes, you're probably good to move to the next step.

But if your app has a fair number of screens and the user experience is important enough in the context of your app to focus more intently on that journey, this step is very important.

What the Story Looks Like

A good storyboard shows the process rather than describing it. So it will outline what someone is doing at each peg of the journey from the first item they click on to the last.

More importantly, it will annotate why they are tapping a certain button or why they are lost or confused by a certain part of the app. It's a chance for you to get out in front and try to guess what the biggest problems your users will have will be and how you can address them in the context of your design.

Creating a Storyboard for Your App

The best part about a storyboard is that it takes any form – the goal here is to create a visual representation of your user will navigate through and use your app. Again, this is why a screenmap is often enough for some developers.

It shows the same information in a cut and dry format.

But when you take it to the next step and show what the user is actually doing at each step and where they might get hung up in the use of your app, you anticipate better how that experience will unfold.

Here are some more things to consider when drawing out a storyboard for your app:

• Consider the Paths – One option is to create a visual checklist of each step someone might take to complete any number of tasks. For example, someone using the Twitter app might open it to browse tweets, compose their own, retweet something they saw, or check statistics. What do each of those journeys look like? Yours will be shorter, of course, since your feature set won't be as robust (yet).
• Annotating Your Screen Map – Make this even easier by reusing the screen maps you already created and making notes on them. Write short lists or notes about the use of each screen for your developer to reference instead of drawing it out again from scratch.
• Reference the Wireframes – Number your wireframes and reference them in this step so it's easy to see what a single step or frame of the storyboard is referring to from a feature set.
• Keep the Feature Load Down – Remember when I told you that more features make development harder. This is one of the first instances where you can really feel that. If you have three features, you'll end up with three lists or maps drawing out how the user might get from step one to the end. Now imagine having 10 features in your app, many of them with branching paths to the others. It would take MUCH longer to draw all of that out.

This is an important step, but don't let it bog you down too much. At this point you've already drawn out how your app will work, done hands on testing, shown it to your friends and family, and mapped out the screens in your app and their relationship to each other.

A good storyboard will take all of that one step further and illustrate what it takes to complete certain actions in the software, but it doesn't need to go into every possible minute detail – it's more of a tool to make sure the app works as well as you envisioned.

What About Digital Wire Framing?

Throughout all of this, I've left out the digital parts. It's all hand drawn.

A common question I get at this point is whether it's a bad idea to use a digital wire framing tool as well.

Personally, I feel that a good hand drawn wireframe combined with the maps I referenced above will get the job done just fine.

If you've followed my suggestions, you only have a handful of features in your app. More than that and you're overdoing it and probably need a more robust outline of the app.

But for a small feature set and a first time app, these will be more than enough.

If you are interested, however, in taking it to the next level and testing out some of the more powerful tools on the market, there are a bunch of them.

There are some desktop applications, but there are even more SaaS products, which means plenty of options to try out these tools on a free trial.

Is It Worth It?

For what we're doing, no it's not. But if you're doing something bigger or if you just want to get the hang of using a more powerful toolset, then yeah, it might be worth playing around with them a bit.

At the same time, keep in mind that this is going to cost you money (once your wireframes are in a tool like this, you'll want to pay for it to keep them there) and time. Drawing something on paper takes a few seconds and can be redrawn over and over again without a huge waste of time.

Mapping them out on a screen with these toolsets takes longer. If you don't plan on using the more advanced features offered by these tools. It's not worth it. These include:

• On screen guides for placement
• Drag and drop dummy text and images
• Precise measurements for your development team
• Options for moving to a Hi-Fi mockup
• Easy to share with people

Sounds cool, yes, but it also takes a lot longer to build a wireframe with all those bells and whistles. It's all a matter of what you need out of it – don't pay for something you don't need yet.

Options for Those That Need Them

If you do choose to do your wireframes digitally, there are a bunch of tools out there. Here are some of the top free options to start:

• Framebox – lightweight and easy, it will still take longer, but it's free.
• Appery – It's a paid service with a very basic free version. It'll get the job done for basic wireframes though.
• iPhone Mockup – Helps you mockup screens on different iPhone models if you are building an iOS app.
• Pencil Project – Great for building prototype designs for free. A bit more of a learning curve (because it's free), but decently powerful.
• OmniGraffle – This is a more general graphic-document creation tool, but that means it works for both your wireframes and your screen maps equally.

There you have it – your options for creating a mockup and wireframes for your app. With this done, whether you draw it by hand or use a digital tool, you are now ready to move to the next step and start translating all of these lines and boxes into code.