By Peter Bell

Wireframes, Comps and Prototypes

I think there is a pretty well understood set of distinctions between wireframes, comps and prototypes, and for larger applications you'll typically use all three. When You're developing an application on a smaller budget is where things become interesting as you often have to choose only a subset of these deliverables, and the best choices are heavily dependent on the type of project you're building . . .

Most web applications or websites need comps. Comps are high fidelity mockups that show exactly how the site will look. Because most customers are very picky about how their site looks, it is usually a good idea to create comps of the main pages within the site using something like Fireworks or Photoshop, so that when you build the site you shouldn't have to spend too much time tweaking the look and feel (or at least you can charge for any such tweaks). I don't come across many web projects being built that don't at least include comps from the designers so the client can sign off on the look and feel before you start to build the HTML and CSS to render the design in the browsers that the site is designed to support.

For very simple website, that might be all that is required. If there are only five pages, there is no functionality and the pages fit common patterns (e.g. Home, About Us, Products, Services and Contact Us), a wireframe may not even be required. As the amount of information within a site grows, wireframes will often be useful as they allow you to look at different ways of accessing the information within the site and to mock up the general navigational strategies. Of course, a clickable prototype is always more likely to pick up issues than simple wireframes, but in my experience, sites that are fairly information heavy but that don't contain substantial functionality can often be planned using just wireframes for the Information Architecture followed by comps for the look and feel.

Once you start getting into web applications as opposed to web sites (i.e. there is more functionality), you often start running into issues where you describe use cases in writing, but unless you build out some kind of clickable prototype and get the client to drive (this is key), you will often find that when the application is complete it doesn't actually meet the clients needs. Of course, the flip side is that clickable prototypes are expensive to build and sometimes even have to be thrown away when building the final app. Also, if you use an iterative prototype driven approach, you will probably come up with a more usable app, but because there is no way of determining in advance how many iterations you will go through, you can't provide a fixed bid unless you use a time boxed approach in which case you don't guarantee to finish the work/satisfy the client within the timeframe which can be a difficult sell in its own right.

I think the value of clickable prototypes depends on how good the usability must be and how different the application is from previous apps you've built. Once you have built 300 content management systems, prototyping the admin may well help to improve usability, but even if you don't prototype the app it'll probably still be fairly usable if the general requirements are similar to those of other sites you have built.

What are your thoughts? What combination of comps, wireframes and prototypes do you use - and why?

Comments
BlogCFC was created by Raymond Camden. This blog is running version 5.005.