I, too, have rarely had a wireframe presentation to a client go well. The problem arises from different expectations of what a wireframe is.

Wireframes are many things: scoping documents for developers and project planners; documents that focus teams on a common set of deliverables; visual representations of priority and propinquity. Wireframes are elements of the design process, and teams of site developers know this. The problem with showing them to clients is that they look like designs. And, while they are conceptual designs, they're not DESIGNS - that combination of art and science that a good team of information, visual, and interactive designers impart to a project. And clients expect to see designs, and they comment on them thusly.

In my past, we used wireframes to iterate quickly through an evolving idea, but we showed first-round graphic designs as distillations of the design process. First round graphic designs are less conceptual and more practical. The feedback from clients is specific to the design, not the concept, and changes made to the design have a higher probability of making it to launch. I've hacked together image maps to show how they might be navigable- an ugly process that yields a decent level of communication to the client.

Your idea to not show them to clients is NOT radical. It makes perfect sense. It doesn't mean wireframes don't get done; they always will - but they might take a different form, like prototypes or navigable PDF files (where is Adobe Thermo, anyway?), before being shown to clients.

Wireframes are seldom completely understood by clients, it's true. But that may be absolutely fine, because they serve other purposes.

1) They are a useful tool (as are site maps) for nailing down requirements and functionality for the development team. If the dev team is able to understand these things prior to getting the comps (and can therefore begin development early), that benefits everyone, including the client. It's just efficient.

2) They are great for nailing down scope. Even if the client doesn't really get the finer points of interaction design presented by the wireframes, they can usually understand the sequence of events (workflow) and the functionality per screen. Do you want to work this out in the comps, with accompanying back-and-forth about colors and pixel placement and logos, ad infiinitum? I don't think so.

The problem with a lot of wireframe presentations is that the team mistakenly believes that the client -has- to understand wireframes 100% in order to proceed confidently with wireframe signoff. This isn't usually true -- it's enough to invite the client into the requirements definition process (which is, after all, what wireframes are: the first concrete expression of requirements) in order to give them a sense of the project direction. Yes, the comps will be different. But they'll be about 80% the same. Because of wireframes, the eventual comps aren't a complete surprise to the client, and the client reaction may be (and usually is, I think) more along the lines of giving helpful feedback to the team rather than "Whoa! That's not what I was thinking!"

I agree that clients don't understand wireframes. I look at moments like these as an opportunity to get the clients invested in the design process. You get a chance to promote your work by educating the client in a concept.

The great thing about agile is that if you begin to apply the principles into the design process, you get a model of rapid prototyping and design cycles. The client participates in the development of highlevel wires, click models and/or paper prototypes, design wires, etc...but still gets to provide experience and functional feedback (and request changes) on designs and production pieces.
I think the key is really keeping all of this feedback on an agile style of prioritization rather than signoff. It makes it all a lot less painful -- Clients don't need to sign off completely on any one thing, they just need to understand how things are shaping up as the process evolves, and continually prioritize their requests. The spot that this stage of UX and wireframes can be extremely useful is building clickmodels to use in getting consumer feedback...which then helps in the prioritization bit...
It's all a big evolving agile mess, but the things being developed are rarely the simple html sites with decks and decks of page paths, so the static waterfall processes don't make much sense either.

I've been thinking about this topic a lot recently... I'm lucky because my team only needs to present wireframes to internal clients who tend to be a bit savvier than traditional clients.

That said, I ran across an approach that I'm going to try for my next project: Design Description Documents [ http://www.thinkvitamin.com/features/design/deliverables-that-work-design-description-documents ]. Essentially, it's a wireframe with comments.

Rick, I agree wholeheartedly that wireframes don't do what they're supposed to.
BUT, the problem isn't the wireframes. It's the inherent misconception the client has of what wireframes are, and what they're supposed to do.

It's their expectation. They don't know what they are so they don't know what they're getting. When we present it to them as a formal presentation, like they're used to getting for a visual design review, they are most definitely expecting "more" from the wireframes. Even referring to them as blueprints is a misguided analogy, because in a blueprint it's still WYSIWYG - that shit has to be nailed down, precise to the millimeter. Wireframes are more like a general direction of stuff that should be included on a page or site, and through discussion and design between all parties, evolve into a representation of what the site will be.

I have always felt that wireframes should be used as an internal design tool ONLY and that low fidelity comps should be created at the same time based on the wireframes and these should be client deliverable instead. I find it very strange that the industry continues to use wireframes as a key client deliverable.

I'm a new I/A, for a small firm, and though in our process wireframes are useful, I'm not always sure how many wireframes are needed. Does that knowledge come with more experience?

Thanks to those who commented about how to best present wireframes to clients given that they've been mollycoddled into seeing only finished design comps in the past and how this presents an opportunity to effectively engage your client in solving objectives rather than treating them like a child.

And thanks to Kyle for the link.