Return to: GROK Dot Com 10/01/2001

(Proto)Type-Cast Yourself

You'll recall we recently discussed the concept of wireframing (see (Wire)Frame Yourself) and its critical role in site planning. I promised you we'd hear more from my friend, John Quarto-vonTivadar, on another planning tactic that will make your site development process sing with efficiency from the very start and will save you a bunch of money, too! Well, John's back from a well-earned vacation and has emailed me some thoughts on the topic of prototyping, which I'm gonna share with you now!

Prototyping is a pre-development method for integrating all the elements that must go into your website so you have the most effective and efficient conversion "machine" possible. And there's no doubt about it - taking the time to do all the fussing up front, before you carve anything in stone, saves you lots of time and money later in the game. Sound like something you'd go for? Then stick around!

There are three critical components in the planning stage of your web project. First, you wireframe your entire site, creating a text-based model that establishes the flow of your specific logical and business functions by identifying all the entry and exit points your users will experience on every page of your site (see (Wire)Frame Yourself). Once you've completed the wireframing, you are ready to move to storyboarding, where you begin to define the look and feel and specific content of your site (see Behind the Scenes: E-commerce Secrets from Hollywood?). As storyboarding moves forward, you are ready to turn to prototyping.

A prototype is a “model” of your finished site. When it’s finished, it should be indistinguishable from the final delivered project, with the exception that it has not been coded and is not fully functional. Actually, it's a lot like putting on a play. Long before the curtain officially rises, the director and producer have cast the show, choreographed it, rehearsed it repeatedly, and finally held the dress rehearsal.

Think of your website as such a play. Your opportunity to prevent an “opening night" disaster comes during the prototyping phase. This is when all the participants who have an interest in the project can continue to influence the final outcome, at a time when the costs of making changes are relatively inexpensive.

We mentioned how all too often the final project gets developed and delivered and suddenly the client (hey, that’s you!) has questions like “Well, can’t you make it do this?” “That’s nice, but I’d rather have this show up in blue rather than red” or “Uh … that’s not what we expected!!!” These sorts of objections and comments only occur because the prototype was left incomplete (or didn’t even exist!) before the hard-core development (programming, database design) was done. And at this late stage, it costs big bucks to fix these problems.

The solution is to employ - and completely finish! - prototyping first. Your goal is to establish a final frozen prototype that is indistinguishable from what the final product will do. If you do the pre-development correctly, when it comes to debuting your project officially, you should find the unveiling rather boring. Why? Because you will have seen it all before! And because you have signed off on the final frozen prototype, there should be no surprises.

How can you achieve such a positive and cost-effective outcome? The key is in realizing that the prototype stage “evolves” in a way the earlier stages of wireframing and storyboarding do not. Prototyping of a static web site (what is often called “brochure-ware” on the web) can often occur in tandem with storyboarding. You may have seen this in action: some designers will demonstrate the “look-and-feel” of design and layout elements, while in the active window content area they insert a whole bunch of pig Latin text (or 17 million blah blah blahs, my personal favorite). Why? Because at that moment the idea is to focus the website owner on the user interface rather than the content. But as the storyboard begins to take shape, the prototyping continues to evolve as content is solidified. Here, especially in a dynamic site or application, it is vitally important to continue reiterating each and every piece of the application so the appearance of the prototype becomes more and more what you want to see in the final project.

As you progress, you will note your concerns shifting from user interface issues to more content-driven topics: "Ok, great … this is where we get the results of a search form the user filled out. But what exactly will be displayed on the screen?" If you’ve done the previous pre-development steps correctly, you already will have sorted out the look-and-feel issues, so now you just need to produce a screen shot that mimics exactly what you want to see in the finished product. You do this for each and every screen your users will see. Addressing problems now is guaranteed to be a lot cheaper than ignoring them or simply overlooking them and then having to fix them in the hard-core development phase, when much more expensive people are on the payroll and a change to one area may require changes to many other areas.

John asked that I make a point of mentioning two neat ideas he's been using recently1. The first is the notion that you evolve towards a frozen prototype using “development notes” that you manage on a screenshot-by-screenshot basis (this can be done easily if you are developing a web-based application, since these notes, which relate only to their associated pages, would appear at the bottom of each and every page). This helps keep a record of change requests as they occur. Doing this provides a vital history of how things have evolved. And you know you are truly done when the entire list is checked off.. The first is the notion that you evolve towards a frozen prototype using “development notes” that you manage on a screenshot-by-screenshot basis (this can be done easily if you are developing a web-based application, since these notes, which relate only to their associated pages, would appear at the bottom of each and every page). This helps keep a record of change requests as they occur. Doing this provides a vital history of how things have evolved. And you know you are truly done when the entire list is checked off.

The second idea is this: once the final prototype is complete, you make sure all the decision-makers who have a say in the end product sign-off on the prototype, freezing the format. After this point, you don't allow any further changes, and they can’t argue they weren’t informed or involved.

If you’re the client, you might want to consider writing these points into a development agreement, such that any changes after a prototype is frozen occur at the option and expense of the developers. Pity the poor project manager faced with $500/hour change requests that he might have got for a fraction of the price had he just taken the time to finish the prototype!

John says every time he's seen this process implemented, the result has been delivery of the final product in weeks rather than months, months rather than quarters. And often, quite delightfully, under-budget! (Is he my wireframing hero or my prototyping hero? Decisions, decisions!)

So … what are you waiting for? Start prototyping!!

1 John tells me these ideas originated with fellow Cold Fusion guru Hal Helms.

How do you prefer to be addressed:

Your email address



We Value Your Privacy!

Return to: GROK Dot Com 10/01/2001

© 2001 Future Now