It’s always a problem trying to explain to somebody how their website is going to work, at some “later than now” state of the design. I don’t know what it is, exactly: whether it’s difficult to find the right words, too challenging for people to imagine what will happen, or whether the way that websites work is simply so foreign to some people’s way of thinking that they just don’t follow you on your way from point A to point B.
(If a web developer describes a website interaction at 50 mph, and their client understands their description at 30 mph, when will web developer and client meet at website launch “C”?)
Regardless of these challenges, it continues to be critically important that whoever you’re working with understands what it is you’re proposing to do before you pursue the work, if the interface will be at all complicated. Your time is too valuable to waste by starting over because the client didn’t understand your intent.
There are a number of simple ways to demonstrate these sorts of things — and, to be honest, I tend towards the non-technical. Very non-technical, actually.
-
Little pieces of paper with words on ‘em.
Yes, I’ll just take all the potential components of the page (navigation items, control buttons, text boxes, etc.) and make little mobile collages. For clarity, I’ll sometimes splurge and use colored construction paper. If you’ve got younger kids, I’m sure you’ve got plenty around! Using these images, I’ll diagram the site processes to make a demonstration. For in-person demos, I might just push pieces of paper around: or for a distant example, I’ll photograph the different states and set up a demo.
-
Whiteboard and plastic with erasable markers.
For a more improvisatory experience, I’ll just start scribbling ideas in different layers to show interactions between elements. This can be more effective when brain storming ideas with a client; the collage method being a little too preparation intensive.
-
Plain old pencil and paper.
This one doesn’t really work for me, actually. Maybe it’s because I can’t really draw…live sketching is inevitably going to lead to a poor design impression for me. However, it’s a tried and true classic method of communicating graphical concepts — so I’m definitely willing to suggest it to those of you who can put it to effective use!
Yes, you can make it much more complicated. You can build complete XHTML mockups, create Photoshop design concepts, or create Flash interaction demonstrations. For some projects, this might be the best way: although I’m trying to take some of the burden of imagination out of the equation, using paper cutouts certainly doesn’t completely eliminate the necessity. Some clients really want to know exactly what you’re going to do, making this kind of approximation unacceptable.
However, in many cases, just providing a visual example will make a concept clear which otherwise leaves your client shaking their heads. Some would argue that this kind of methodology is unprofessional: I’d say that it’s just efficient. Technology is not required to lay out an effective interface design.





I tell you want r0x Joe, http://napkinlaf.sourceforge.net/ – which is a project to create a “napkin” set of design tools, i.e. a set of tools that look like they are drawn.
The screenshots are busted, but http://www.clientjava.com/blog/2004/08/02/1091458389000.html has a good shot.
This helps to demonstrate the design, without implementing it ina format a client EXPECTS to see, and creates a nice lil visual REPRESENTATION, rather than a functionaless creation that looks (to the uninitiated) ready to rumble.
Comment by Michael — April 2, 2007 @ 3:14 pm
“rather than a functionaless creation that looks (to the uninitiated) ready to rumble.”
No question, THAT’s one of the worst problems: when you’ve created a mockup, and they don’t realize that the mockup interface is only scratching the surface of the work!
I feel like somebody’s mentioned that tool to me before…it’s pretty clever! Reminds me of college…
Comment by Joe Dolson — April 3, 2007 @ 12:47 am