3 Steps to Building a Successful Prototype...Quickly!

This is part two of a two part series about developing usable prototypes through wireframes. For part one, please visit "Defining a Successful Prototype"

Start Wherever You Want

When you begin the process at the ground level, you don't need to start at any one set point. For example, home pages are often the most difficult to start with. Why? A lot of pressure is put on the home page – it’s where most of your new traffic will go, and it's the easiest place to distract yourself. The real action, however, is almost always elsewhere. If you can successfully identify the most important pieces and functionality (noted above), then you have already defined a good starting point.

• Dive in at the more complicated areas and let the easier and less complicated pieces fill in to build a complete picture.
• Building backwards can answer questions before you have them. Starting at a product page before the search brings forward different questions: “How did the customer get here?” versus “How does the customer get there?”
• Many pages share common elements (header, footer, navigation) which can be designed in broad strokes at the beginning and revised completely across the entire application later.

Have the Difficult Conversations

When you start the process by having the difficult conversations earlier in the process, you can't avoid you save yourself frustrations later. It's easy to feel positive making a lot of progress, discussing and agreeing on easier issues through the process, but you will be quickly deflated when more complicated features come up for discussion.

If you find yourself and you're team saying anything like “Let's table that for now”, you might be missing the point of this process. Having the difficult conversations, arguments and fist-fights (well, hopefully not fist-fights, unless it helps of course) means avoiding having the same discussions at a later date when things have become more expensive and time is running short. In other words, conversations now are cheap while conversations later are expensive.

• Should there be a different meeting set up to handle this discussion? If so, wireframe that feature set separately and bring it back to the group.
• Are the appropriate people involved in the conversations?
• Is there something in the wireframe at this point which needs to be removed? In other words, have you gone down a rabbit hole?

Don't Sweat the Copywriting & Documentation

Resist the temptation to dive into the copywriting and documentation during this phase of your project. It matters less what the various buttons and text say and that they will exist or that you want to build in the flexibility to be able to change them later.

• Searching for the right word, phrase or marketing speak slows down the process.
• Conversely, avoid using Greek text throughout the layout. It's important to know, roughly, what type of content or copy is going to be included.
• If there is an important missing piece of copywriting, for example, a new tagline or a final decision on navigational text. Assign that task to someone. It can change later, but it's better to have a somewhat firm decision in the meantime.

Wrapping Up

We recommend that you start on and work quickly through the complicated and challenging pieces of the wireframe and have not be afraid to have the difficult conversations and making difficult decisions about the project. Include the right staff in the conversation and keep in mind the processes and feature set that will set your application apart when making functionality decisions.

Back To What We're Up To