This is the celebrated journal of Mr. Simon Collison A.K.A Colly

Process Toolbox, part eight: Prototyping

22nd March 2010

Okay, part eight - and the penultimate transcript from The Process Toolbox. As much as all parties may talk about requirements and argue over features, often they won’t really “get it” until they can see the concept represented visually, and understand its exact behaviour. This brings us on to various methods of prototyping.

How well do ideas work in practice

Paper Prototyping

It’s fun and bloody useful to create rough sketches of screens and behaviours, developing these sketches gradually through collaboration and experiments. I’m a big fan of Clearleft and their myriad experiments with paper and pens. They make use of what is around them to try things out and understand relationships. They’ve even been known to use Lego for layout. These experiments can then feed directly into perhaps flat wireframes, or browser prototypes.

Frieze sketch

Wireframes in Photoshop, Fireworks etc.

We know that a wireframe is basically a lo-fi prototype of a web page or screen, used to identify the elements that will be displayed on the page or screen, such as navigation, content sections, imagery or media, form elements, and call to actions. It’s a map.

As wireframes are typically created in black and white or shades of grey, using placeholders for images, and do not get into specifics on visual design elements, they allow us to share ideas and collaborate together without anyone getting hung up on thoughts of exact proportions, colour, typography, or imagery.

Basic wireframes

To pluck out a suitable analogy, if we were designing a house, at this point in the process we’d be concerned with what rooms the house should consist of, how they should be positioned in relation to each other, and roughly how big they should be. We wouldn’t be worried immediately about precise measurements, wallpaper or whether the taps are brass, bronze or chrome.

This is an iterative process. We can start by rendering the solution only in enough detail to provoke engaged consideration without spending too much time or effort creating renderings that may well be modified or abandoned. Typically, this is happening in Photoshop, Fireworks, OmniGraffle or other more lightweight tools such as the idiosyncratic Balsamiq app.

Browser prototyping

So, many of us love building traditional wireframes, but why try and explain how something will work when you can mess with multiple approaches on the fly and then _demonstrate_ how it will work instead? It isn’t always advisable to design and prototype in the browser - my colleague Gregory creates complex art-directed pages such as this gorgeous page that are better prepared elsewhere.

Browser prototyping

Still, for most projects browser prototyping is a great way of saving time and money. The prototype should ideally be on convention - perhaps using your reusable package, building up from that new prototype towards a finished product through constant iteration and experimentation.

It also allows you to hook up the CMS at a much earlier stage and use some real data. After preliminary data modelling, you can set about creating relationships between sections and examine how information flows and is manipulated as a user moves through a site.

The browser prototype is also a test-bed for a variety of jQuery behavioural experiments, API data and so on, much of which might see it through to the final design. Other experiments can be evaluated and perhaps be ruled out rather quickly.

More browser prototyping

Be sure to take some time to read Andy Clarke’s Walls Come Tumbling Down transcript for greater depth about browser prototyping.

Focus Group Testing & Feedback

It’s essential to evaluate how well you’ve hit the mark by putting your ideas in front of actual users. In part three (Collaboration) I outlined methods in which the design team and the client can seek to engage with the intended audience at the earliest stages.

When you move as quickly as possible to bring a project to life in the browser, this often means requesting feedback as you build, so that you can iterate based on the results.

An extra set of eyes is always helpful, but not if you can’t gauge the response. Too often testing comes post-launch, so its good to identify some level of prototype feedback - at points you and the client can designate around build progress, probably with an assigned focus group. This additional round of testing helps ensure that as few stones as possible are left unturned in order to deliver a project that has been rigorously evaluated.

I’m a big fan of the dynamic feedback form. Something as simple as an expand/collapse feedback form on every page does the trick. It’s inserted as a CMS or PHP include, and we like to use a few variables to dynamically insert the page title and send any other vital developer information (OS, browser info, screen resolution, window-width etc) with the user’s comments - either to email or to the CMS. This feedback prior to launch is invaluable, and often very frank. Accompanying information manages their expectations, so if it’s a navigable grey-box wireframe site, we explain that, and ask them to look at something in particular. Focus groups are often much smarter than many give them credit for.

Prototype feedback form

Other notable possibilities for prototype testing include more complex crowd-sourcing models, where users can provide on-page feedback by perhaps clicking from given options, multiple-choice responses, or filling in blanks by building real data.

I also like Andy Clarke’s method for implementing descriptive overlays with CSS positioning. This allows the developer to place notes on certain pages to put the prototype into context.

*Note:* Slides designed by Gregory Wood.

Full series…

This article was originally posted on Erskine Labs, September 2009.


# pixhell responded on 22nd March 2010 with...

“often they won’t really “get it” until they can see the concept represented visually, and understand its exact behaviour.”

How do you handle a situation where even low-fidelity prototypes, sketches, white board drawing and hand waving aren’t doing the job? The client still just doesn’t “get it” until they see high fidelity mock ups (nearly the final product) before they start giving feedback?

How do you justify the time spent on sketches and low-fidelity prototypes if the client never see’s them? How would you modify your process to work in this scenario?

# Lois responded on 24th March 2010 with...

The time spent on sketches should be rather minimal hence the lo fi nature of a wireframe but I think you will get the time back as it helps you cut down on design time on the final design.

Responses are now disabled Your ability to respond is disabled automatically some 30 days after articles are published, or manually much sooner if spamming guttersnipes target a particular article.

Prev 801 Next

Superfluous Aside

Archived in Design & Web, Writing & Speaking

Written in Nottingham

There are 2 responses

External References

Copyright © Mr. Simon Collison 2003-2017. Protected and licensed under a Creative Commons License. Grab the RSS feed

Engineered in Nottingham, scaffolded by ExpressionEngine, steam-pumped by United & kept alive with tea and hugs.