This blog entry is part one of a two part series about the process of building prototypes through wireframing.

In the past several months, we've been fortunate to work with a number of entrepreneurs and small companies actively building their businesses on the web. Working in industries from clothing to industrial thermal oxidizers, these companies are creating, designing and launching applications on the web either as a service or a small piece of the business. After completing several of these projects and stepping back to review the entire project process, we've put together a short guide on how to:

  1. Effectively navigate through the prototyping process
  2. Quickly and successfully moving from prototypes to designs and builds

So, what do you mean by wireframing?

We define wireframing as the process of mapping out an application using mockups that actually work. If you were a home builder, the wireframe would be the architectural drawings. The document gives you the plan on how to build out the final result. We recommend building wireframes that are more than just pieces of paper or illustrations – wireframes that work. In other words, you can click and follow through a process, whether it’s an order, a registration, or white paper download.  As a result, the wireframe becomes more than just a drawing of what the application will be – it's a functioning document.

Our goal for the wireframe is to define necessary functionality and all the other pieces which will comprise the first build - version 1.0. The first version represents the best effort to define what's known, answer as many questions as possible and leave as little grey area as possible. We know that once the design and development begins, there will be changes, but the vast majority of what's included in the wireframe will make it into the first version. The process involves making a lot of hard decisions – what gets included and shelved, what resources are required, and much more.

Defining Your Difference and Flow

The wireframe should illustrate your idea conceptually, explain functionality, and define a competitive advantage - it's not supposed to be pretty – at least not at this point anyway. In most cases, you haven't reinvented the wheel with your software, so you need to show how you're different (bigger, faster, stronger, etc.).

Take time to consider your initial presentation and your audience. Are you presenting to potential stakeholders (partners, investors, potential customers)? If so, they will be most interested in the flow and process of your application, not any pretty colors. In other words, can your investors see the value in what you're going to produce with their money?

For designers and developers who are using the final wireframe to build the application, you’ll want to show the same level of detail into process, but pay attention to the periphery of the as well. Details like “What fields do I need on my registration form?” or “how many different page layouts are going to be required?” are important to them, but not as important to other stakeholders.

  • How do I use the application to accomplish my task?
  • How is this better than what I'm using now?
  • How is this different than someone / everyone else?
  • What do we need to do well within the application in order to be successful?
  • Which 20% of the application will require the bulk of the development resources available?

Stay tuned for Part Two of this blog entry, "3 Steps to Building a Successful Prototype...Quickly!"

Back To What We're Up To