My initial reaction is to ask why bother with wireframes at all?

With access to the right skills, it may well be easier to go straight to a HTML prototype. This, I believe, could be better at overcoming the problems external people often have with wireframes.

Going straight to a prototype would be especially applicable if the project is to improve an existing page or site (is in the example), as the current pages provide a ‘template’ which can form the basis for the prototype.

This is especially important if the new proposed designs are very different from an existing design, as differences in colour and typography may be sufficiently apparent to the client that they end up becoming a focus, when really they have less significance than the layout of the page and UI elements. Going straight to a prototype means that early decisions about colour, branding and typography have to be made at a stage when really they shouldn’t be allowed to cloud the subject matter.

That all said, I think there is some value in having these chrome parts visible once you get to the user testing stages. Perhaps it would be an acceptable alternative to just use a generic stylesheet at this point?

I don’t think there’s a single silver bullet / best practice for how to prototype for every single project. One should consider who the prototype is for (investors? the client’s business analyst? end users in usability testing? your developers?) Each group will have different needs in each of the 3 attributes. Design your prototype to meet the needs of these interim users and you’ll find the right balance of cost/value for visual detail, functional depth, and technical reuse.

In my experience, increased use of rapid prototyping techniques makes having an intelligible prototype all the more important. I’ve used Axure for about a year, and of course I get the “it needs more colors” comment, but the most significant thing that I’ve noticed is that prototype test participants are unsure of whether they have completed a task if you use genericized page types. When I take the time to put in fake data that matches the tasks in the test, users have a lot more confidence about whether they’ve found what they’re looking for. It helps prototype tests more definitively answer the question, “is this usable?” This leads me to believe that a new rapid prototyping best practice would be to complete the prototype tasks *first* and then begin working on the prototype. This could increase rapidity even further.

Usually the wireframes that I’ve developed are minimal in color with an exception for links and icons. I try as much as I can to avoid lorem ipsum, not just for the client but also as a benefit for our copywriters to have something to start off of. Using real information is key in any wireframes, especially when testing the structural layout of the site.

An understanding of what wireframes are should be made during the discussion of the statement of work. Knowing that visual is separate from ID/IA work is key to the client’s understanding before any work has begun and should be reminded in instances when they do go off track.

I do find it however that wireframes and visual comps clash in a way – knowing that most clients will give “LATE” feedback on ID/IA work that has been signed off. Yes – Clients suck. Well most of them at least. =)

However, if the problem is users don’t understand the conceptual nature of the wireframe, this is as much to do with education and culture as it does wth the wireframe’s fidelity.

At the World Bank, user testing is fairly strongly embedded in the culture, and the usability guru does an excellent job of educating users as to what an HTML wireframe is, what it isn’t, and the purpose of the specific test. Users test both bare bones HTML wireframes as well as higher-fidelity, grayscale wireframes. The higher-fidelity wireframes had to be grayscaled because users believed color versions were work that had already been completed, and there’s a bias against critiquing already completed work.

A common reason for using lower-fidelity wireframes is that users may hesitate to provide the same feedback they would if they were presented “ideas” for the site.

At the other end of the spectrum, at Comcast Interactive, I’ve heard stories where hi-fidelity prototypes were interpreted as finished products by management who liked what they saw and mandated a launch.

The same education and culture issues come into play, but getting real is certainly not without its problems.

Ideally, your wireframe should be crafted with its use in mind. Documenting decisions for history or for feedback should create a different wireframe than one used for testing or another used for communicating design with the rest of the team.

I work for a software consulting company and am faced with a wide variety of application and user types. It might occasionally be useful to have higher or lower fidelity wireframes than a typical Visio mock-up, but I find this to be the exception. It really depends on the complexity of the application, the phase of the project, the extent of the differences between this and what the users are used to, and so on.

There are several types of information that we want to get from user reviews. For some applications, the appearance is a high priority, and for these we produce a visual prototype. I find standard wireframes valuable for evaluating the data semantics of the panels: the field labels, priorities, groupings of data, and so on. And I find that if we introduce too many variables, the focus of a review can be diminished.

I’ve never heard the comment “is the application also going to be in black and white?” But I have heard over and over again something like, “I don’t think this blue goes with that orange.” If users are given the proper perspective up-front, they can typically not only relate to the wireframes, but appreciate them as providing a visual focus around which to wrap a text-oriented business requirements document.

Having said this, we’re on the cusp of changing technology and are increasingly moving from paged to rich internet applications, in which static Visio wireframes are not so useful. But that’s another topic.

Zef Fugaz’s above comments are good too, these can be another step in different documentation that delivers to different needs. I’ve had to deliver upwards of 4 different “site/content maps” to a client, all valid “site/content maps” but all showing different perspectives of the data at hand. We sent different docs to different stakeholders that had different priorities.