I would like to highlight one point you make towards the end and actually feel that, rather than being a Visual Layout vs HTML ‘prototype’ comment, the discussion of ‘context’ of usage of these tools is of far greater importance. (It’s been a long day today so apologies if my sentence structure is a little ‘squiffy’ ;-p)

On nearly all of my projects for the past 8 years, I have used lo-fi (scribbled post-it note style wireframes) and higher-fidelity ‘html prototypes’, plus the many myriad of hybrid solutions in between. On some projects I have used all these methods, on others just the one. It really does depend on the context of the project and the nature of the work.

You are right about the usability differences between the two however, and this is indeed a difference that should not be under-estimated.

Whilst ‘paper’ wireframes aid in initial problem indentification, and basic solution discovery, the results of nearly all of my user testing have differed quite considerably after transposing from flat ’2d’ paper and into a more interactive/immersive screen environment. I have always found it useful to be itterative within both environments as this, despite being initially time-consuming, really stops some of the later pitfalls of development.

An excellent beginners guide though Jeff, and something I wish there were more of ‘back in the day’ ;-p

(sorry about that)

1) Clients thought the HTML work was basically done after the wireframes, not knowing that I had done them as rough and ugly (code-wise) as I could.

2) Like you pointed out, Jeff, printing them is a pain. One trick: Make one master page that contains a link to all the other pages (which is, itself, a pain to maintain). Then, when you want to pint out a whole set of them (usually to show the client), under Print/Options in IE, check the Print All Linked Documents box. They will still come out pretty broken up, but it’ll save a lot of time.

3) Vanity. They look lousy in a portfolio. Seriously. I never got complimented on my HTML wireframes and my Visio ones looks infinately more professional. I lost a job over it, I’m sure.

4) Developers hate them because they have to leave their programming tool to flip through an HTML site to find what they are looking for, rather than just have a sheet of paper next to them.

5) Same deal with Designers. No one wants to hop out of Illustrator to see what a tab is named.

A cool article though, one I’ve been waiting to see for a long time.

Dan

I prefer doing my wireframes in Visio, because of all the reasons mentioned, but mainly because you can give things a distinct *look* that clearly converys this is *not* the website design.

1. Depending on how your organization’s methodology is setup, you may or may not have a detailed functional spec document. Some use use cases, others use separate docs. In my experience, it is a big pain (as Dan notes) to hop between applications or even printed documents to get all the information you need to develop. Therefore, I strive to place as much functional detail on the wireframe. This requires me to understand the technology that will go into building the application and I often consult a tech lead on the feasiblity of an idea that I have.

2. That being said, not everyone has a great development team backing them up and so we are forced to understand the technologies we design. Also, understanding these technologies allows us to realize, reach and push the boundaries of our interfaces.

3. Finally, I agree that IA is a unique discipline but it DOES need to follow a model. Even in a good economy we all switch jobs occasionally and need a certain methodology to follow so that our deliverables meet the needs of our current development team. Don’t misunderstand, I am not suggesting you quit using PowerPoint. If it works for you, great, but if it doesn’t deliver the kind of information your developers need to complete their builds on time and on budget, then perhaps I have given you a new method to use within the context of my article.

Thanks for reading!
[Jeff Gothelf]

All of your points are valid and ones which I wholly identify with.

Your first point about the client is an absolute reality, and something which I come across over and over again. But to simply move from paper onto ‘finished design’, without planning and mocking up web work in ‘vanilla’ html first has always proved really detrimental to my final work.

AND I have worked with clients who refuse to believe that anything planned/drafted/presented on paper (no matter how meticuously) can be in ‘any’ way indicitive of final design. Despite the fact that the basic interaction HTML models always look/feel ‘less finished’ than the initial screens from which their build is taken.

Perhaps what we really need is not an article on what tools to use, but on how best to teach the client the ‘ways’ of us; that we know best, and to trust us (even if our IA stuff consists of post-it notes connected with string) ;-p