While there remain certain specific contexts where it is advisable to craft and present wireframe layouts for client evaluation and approval, this practice is often a really bad move and one made at the wrong moment in the design process, and for the wrong reasons. Wireframes can be useful, valuable artifacts for informing the designer's process. But they often fail miserably as a first-step deliverable for clients.

The practice of compulsory client presentation of wireframes for all projects is not uncommon in the Web design profession. But rather than being based on sound, contextual reasoning, it is more often a thoughtless, vestigial process remnant or the result of careless misinterpretation of someone else's contextually-specific best practice. Put another way, many designers generate and present wireframes to clients not because they know it's a good idea in a specific case, but because they've seen or heard of others doing so and they therefore think they're supposed to as well. As always these sorts of assumptions are problematic. An action or choice without context is a step toward failure.

In this article I'll examine design and project management issues that surround wireframes, and how some specific contexts impact choices for producing and/or presenting wireframes to clients as project deliverables.


To wireframe or not to wireframe

Whether they're hastily-scribbled pencil sketches on notebook paper, detailed ink drawings on graph paper, rudimentary gray box layouts made in a graphics tool, or highly detailed monochrome comps with real text content and accurately rendered interface and form elements, virtually every project involves wireframes of some sort. They provide guidance for the rest of the design process …for the designer. They can, however, be problematic or useless for the client and in some cases they're simply a waste of time.

The value of this nice design (above) would not likely be well served by a wireframe presented to the client.

But not always. As mentioned before, there are certain contexts and cases where crafting wireframes for client evaluation and approval is a good idea or an advisable requirement. For instance:

  • forms
  • (some) Web app layouts
  • news sites
  • or in those lamentable situations where you're asked to design without the client having provided you with the content (where wireframes are used to help them visualize how content volumes impact the layout. A poor process!)

These are good contexts for client-presented wireframes. All but the last example are likely well-suited to client wireframe approval because of what generally allows these types of pages to be successfully designed: the lack of visual noise and obtrusive, non-content graphic elements. For those contexts, the plain, monochrome wireframe presents a fairly clear indication of an ultimate result. In these cases, most of what can be conveyed by a wireframe can remain unaffected by the full articulation of the design (though “Web app” is an admittedly generalized example here).

Even in these contexts, however, the design process can get derailed by the client's feedback and requests when made without the context provided by an already understood and approved full design direction. Wireframes are a sometimes useful "guess" that can help get design underway. But if your client doesn't share your appreciation for and understanding of the purpose of wireframes, things can go awry. Sometimes it is best that the fully realized design for one or more promotional/information pages be agreed upon before wireframes for some other specific layouts are generated so that the comparatively inarticulate wireframes can be viewed and evaluated in the right context.

Some problems with wireframes

Wireframes bring with them a host of potential communicative problems that must be understood by both the designer and the client where wireframes are used. Taking into account that part of your job as the designer is to win and maintain your clients' trust, you don't want to introduce artifacts or documents that might work to erode that trust. Design-communicative problems erode trust.

Wireframes as the design blueprint

Some may regard wireframes as entirely innocuous; as merely the blueprints for the page layouts. This analogy does not hold. The blueprints or the floor plan for a house are made in the context of the fully realized design and the client views these with the benefit of having seen detailed elevation drawings or paintings. When the project is fully realized as the house is built, the blueprints and floor plan encounter no modifying influence or pressure to change. They're set, solid. Their plan will likely hold through the entire process.

The floor plan above has the context of a design result as rendered in the elevation painting. Thus the client can form opinions based on a full, clear picture.

Wireframes, however, cannot easily accommodate and convey vitally important components of the design. Gray boxes and non-contextual dummy content cannot describe:

  • how contrast impacts content hierarchy
  • the impact of brand-specific design features
  • the impact of graphic and textural elements
  • the eye/energy paths created or interrupted by color and contrast of graphic elements
  • et cetera

As a result, what seems logical and sound in a wireframe may be trite and malformed when the actual design and content are applied. Gray boxes and generic filler copy may fit together very nicely for an initial plan, but relationships can often change as the graphic and textural layers and actual content are added. Revision becomes likely.

The impact of informational and promotional content

The further the page purpose moves away from sanitary news or purely functional requirements the less effective and articulate wirefames become. Counter to the previously cited example, there are common cases where what will be a compelling, effective design fully realized may seem dull and dubious as described by an inarticulate wireframe. As such, it may work to erode client confidence.

For example, this wireframe (above) is not very exciting and in no way conveys the impact and effectiveness of the fully-articulated design that will follow. A client presented with this wireframe as an example of the plan for the main page of their company's website may question the abilities and creativity of their designer. It is likely that the client would be compelled to begin asking for additions to help this page "pop," and the designer would find himself in the ridiculous situation of having the client demand to help design the wireframe. And everyone loses. However…

…the design as fully articulated (above) is a different matter entirely. Nice typography, crisp imagery, and consistent theme work to bring this layout together as a compelling design. Very little of what makes this design work could be communicated by a mere wireframe. And if the required detail was articulated by a wireframe, it means that effort was wasted and should have been directed toward crafting the full design for presentation to the client. Again, context matters.

As an anecdote from the above-referenced project, the original plan was to have the branding/nav and promotional areas as centered, distinct "boxes" on the page. In the fully articulated design it became clear that it was much better to have the upper area of the layout be a full-screen–width section rather than discrete, horizontally-limited boxes. This is just one example of how things change when the full design is applied to a wireframe plan.

Wireframes for informational and promotional pages quickly begin to lose their articulate nature, especially where brand-centric issues come into play—and especially when the actual content is not present. It's highly probable that only the fully-realized design can convey the successful or unsuccessful quality of a page when there is an informational or promotional purpose to the content. This issue is sometimes mitigated when you've got the full and exact page content, but why would you then create a wireframe? Communicating promotional information in the context of a brand requires more than gray boxes.

Faulty reasoning and greed

An idea like, "Wireframes will present enough specificity to allow developers to start crafting the functionality, as well as enough context to let the creative team (designers) start to working on visuals," ignores the fact that information hierarchy is design and is not merely a matter of top-to-bottom or left-to-right order, and that the addition of graphic, typographic, and textural elements can change content relationships, requiring layout changes. Furthermore, if the wireframes are crafted by an information architect (IA) rather than by the designer, design decisions will have been made that may prove faulty later in the design process due to a lack of the IA's design insight (or foresight). If your client has already signed-off on the wireframes, you could find yourself in a pickle.

So getting a client's approval of a specific layout and content relationship with the inarticulate boxes appropriate for a wireframe presupposes that the content and the graphic, contrast, and color textures as applied to the content won't necessitate changing things in order to create a good page viewing/using experience. This is naive at best and irresponsible at worst.

Another instance where wireframes are often inappropriately included in deliverables is when agency bloat and greediness are brought to bear. The common logic is that where a bloated agency charges four times as much as smaller agencies, they're compelled to offer many times the volume of deliverables in an attempt to represent value. The problem here is clear.

Disappointingly, this approach also typically involves the failed practice of including a scattershot approach to design, where many design options are offered as a matter of course. I've discussed that issue already on my blog, but the lesson here is that where you find the one bad behavior, you're likely to find another other. And another.

Speaking here to companies looking to enlist a Web agency, if your prospective agency describes wireframes as a part of the project deliverables when they don't yet have a full appreciation of your project, it means they're working from a script rather than thinking about you. It means you're talking to the wrong agency.

In conclusion

Before you create a detailed wireframe for any project, ask yourself: "How will this help my design process?" Evaluate your answer carefully before you decide whether or not to craft a wireframe. Actually, I think we're all in the habit of doing this and most of us intuitively understand how some sort of wireframe will help our process.

Likewise, however, before you create a wireframe for client evaluation and approval, ask yourself: how will this help my client in the project process? Again, evaluate your answer carefully before you decide to craft a wireframe for your client's evaluation…and before you commit to do so as a part of the project deliverables. Context matters.


This is a great article with many important points about the value of wireframes. Having used storyboards (on instructional design projects), I have experienced first-hand the problems that symbolic prototyping can create with clients. 

This Information is very concerned with the facts i was searching over a long time. Thanks for something this informative regarding the wireframes.

Hmmm...I think most of you have failed to understand the history of User Experience as a profession. I remember coming out of an HCI program in Psychology and then going to ITP in NYU in the early 90's. At that time the graphic based internet was quite new and we had to convince the need for user based design.

At that time, we usually prototyped our ideas in Macromedia Director and then later we used Flash. The wireframes were usually hand sketches with post it notes and transparent sheets layered on them. The whole point was to use these tools for creative idea formation.

But then another kind of person came into the picture, the library scientist. The idea behind this is that as websites got complicated, someone was needed to organize the information, separate from the visual designer. The web was still looked at as a database of information, like a giant library. This is why wireframes and sitemaps became important deliverables.

But as some sites became more visual and interaction based, the traditional UX person became relevant again. But now so many agencies and clients are even more confused as to what the function of the UX/IA/XD is and may even expect wireframes when they are completely unnecessary to the project.

There is a lot of work out there that is merely the shuffling of papers, but with the right kind of communication skills can look like something impressive is going on. I have been avoiding these kinds of projects at all costs, as I feel that honestly creating great interfaces that feel natural to use is what brings me and my clients a true sense of fulfillment.


Wireframes can be said to be a “thinking device” to help you set and explore a given problem! So to know the uses of wireframes, it is important to understand the nature of designing! Wireframes can be useful tool for informing the designer's process but not as a first step to be presented to clients! Your design has to be well laid out and explained to the customer before you make use of the wireframe or it will prove to be too complicated for the client!
Interactive Agency

I'm always struck by how proponents who defend the use of wireframes miss the underlying point on the process of design, one that Andy stated quite clearly:

"[Wireframes] provide guidance for the rest of the design process …for the designer."

Wireframes are a design tool for designers to express design thinking. Wireframes are NOT a design deliverable in and of themselves. Wireframes are not design artifacts that can be made to use throughout the design process without ever bothering with how the real product will ultimately look. Wireframes are a means to more fully rendered end, a way to think out loud, and a way to work a problem. Wireframes are a tool, not an artifact. That's the point.

But as a design deliverable, wireframes often get designers into hot water for the very reasons Andy stated in this article.

Seriously, designers in the digital realm need to go into any other design profession and you'll see wireframes are always supported by a fully rendered example. Clothing, architecture, industrial design, graphic design. Why is this concept so hard for people to grasp? Other design industries would be shocked to see digital designers only bother with wireframes.

A lot of people who defend wireframes as some sort of design artifact in and of itself need to re-read this article and step back a moment and understand what is being said here. Andy Rutledge is spot on.

Stop creating wireframes absent of fully rendered versions. Making design decisions using only wireframes is a crippled way to design anything, and further, you'll make poor decisions over the entirety of the project starting that way without at least one or two fully rendered expressions of the wireframe, even at the very early stages of the design process.

I enjoyed your article and find a lot of your points to be very intriguing.

However, your example using the blueprint analogy is a little off the mark. Although it's true that elevations and and architecture will affect the "floor plan", that's usually the first thing a client wants to see, i.e., room dimensions, placement, bathrooms, lights switches, drains, doors, windows, etc. Once those details are nailed down those criteria are extended into elevations, structure, ceiling height, roof lines and landscaping. The last thing to to tackle is the interior design, fixtures and final landscaping.

So in actuality, the floor plan does come first (e.g., wire frames). It is flexible initially but becomes less so as additional details are added, just like in Web site design.

Thank, I enjoyed your article.

I respectfully disagree.

Wireframes define the direction of the layout and keep the client focused on the organization of content at the early stage of a stage of a project.

Wireframes distill the design into its basic components.

If you show a client the full color option (i.e. unit interactive image above), complete with details and an image, you will here things like: "why is this so green?", "why is there a ladybug in that picture, people don't like bugs", "that text in all caps looks like you are yelling" and "what else do have for me to see?".

Prep the client, manage expectations, show them simple at first. This will allow your final presentation to have the dynamic effect you want to achieve. It lets them better appreciate your knowledge regarding the organization of information that has been optimized for the users flow.

Basically, if you skip straight to the comp, then you will be doing more design re-work.

I think it is a mistake to try and shortcut the process.

The success of a wireframe will depend upon how good the UX designer and the ability of the project manager or leader to explain to the client the final meaning of the wireframes and they purpose in the different stages of the design.

I found the wireframing process vital for a design process because allow to maintain a clean communication process not only with the client but also with developers and so on.

We cannot pretend from the customer to be knowledgeable in what a wireframing process is. The success of the wireframe stage will depend in how we keep the customer/client informed and educated about concepts, processes and graphics and our ability to present them in a language clear for him.

Wireframes are only as good as the person who creates them. The only reason why the wireframes fail to convey the design is the inarticulate way they are designed. In my experience, a wireframe should accompany supporting documents such as a content matrix that detail more specs. As they say, garbage in, garbage out.


Very well said. You are describing a very clear value that should be present in the documents. The translation of client objectives into something that the client is a part of because the documents help to translate their interests.

Maybe one of the reasons that so many wireframe-type deliverables have gone south with clients and production teams, is that there was poor stakeholder input process. Garbage in gargage out.

[ This applies to the "Quality Deliverables" part of my last comment. ]

I use wireframes to land projects. The reason I land them is because I listen to the client, and ask the right questions. Wireframes are a way to sketch insights and information learned from the client, and show them that we are listening. It's important to explain that these are sketches, and that final designs will look different as we evolve our understanding.

Honestly. I can't wait for the day when "because it will be misunderstood" ceases to be a factor in the argument of mock-up fidelity or anything else.

Since clients are capable of misunderstanding anything and everything about any kind of development deliverable whatsoever -- I've seen it all -- we could apply the "because it will be misunderstood" argument to everything, and simply advocate for a deliverable free process.

Quality deliverables, client education, the right people presenting; problem solved.

In my experience wireframes has helped me in the design process. It's all about communicating with your clients. They may not understand the term "wireframe" which is why I present it to them as a mock up. This term is easier to understand and I directly tell them not to focus on the colors, lack of graphics, etc. but how their contents will be placed and the pros and cons with each mock up. Once they select a layout that they are comfortable with then I go into the details of adding colors and graphics.

Wireframes are not a waste of time, for me at least, because without wireframes you're basically working blind. It gives you a sense of direction. Without a wireframe I'll just be coding elements that doesn't fit and end up wasting time because of a lack of a solid foundation.

I agree with most of the what the folks are saying here. My largest issue is that the UI example wireframe discussed above is not a "wireframe." That is a designed web page in its early stages. All things equal, if a wireframe at all approaches any of the aesthetic qualities of an actual visual design comp, it has the potential to be misunderstood and interpreted poorly.

In my opinion? Make it ugly. Make it look like a presentation of content, interaction patterns, and hierarchy. Don't try to make it pretty. You will have the client focusing on the wrong aspects of the artifact.

Yes. The whole premise of the article is off. All of the cautionary tales here have nothing to do with the question of the value of wireframe/UX mock-ups; they all actually relate to client education and perception management. In other words good process and a competent team with well experience UX members (whatever their exact job title happens to be).

In the the negative cases, either the deliverables themselves were garbage, or the deliverables were fine but the people presenting were not competent and client process/education/perception-management.

Sometimes you have good deliverables but you have an account rep or a creative director who have minimal or non-existent knowledge of how to present the documentation, or did not do the work so they cannot speak to the clients concerns. Sometimes the deliverables are crap because they are old-school IA docs that are not created by UX designers who know how to indicate optimal UI design patterns and cognitive ergonomics within the documents.

True, there was an example pointed out that may not benefit much from wireframes -- and while I did not look it over in enough detail to know whether that is true -- it is true that there are what I call "High Concept" site that really emphasize non-standard innovative approaches to the interface experience. These are typically artist sites, or singely products sites where you have to come up with some way to spend 200k or more talking about a tennis shoe. For these sites, wireframe and other interface UX docs may be more of an internal process for understanding basic content requirements, and need never be shown to the client, as the client really wants to see creative concepts, and not your typical practical interface that needs to be designed in order to help someone get something done. In the high concept site, high fideltiy designs are the prototype because they truly are the product. But these sites are the exception and not the rule. In most interfaces the majority of design effort is really in the interaction design of the UI components and visual architecture of the communication layer; aesthetic design has a smaller percentage of impact. It is an important impact from the branding/tone/atmosphere standpoint, but look-and-feel it is still a small percentage with regard to all of the other design disciplines which are embodied in a well designed interface.

I believe the comments sum up my feelings nicely, and I always appreciate when unnecessary process that inhibits innovation is questioned. It really does boil down to the client, project, timeline, and team structure.

However, I did want to dispute JaneM's comment:
"Most of the objections in your article can be done away with by simply explaining to the client what wireframes are and how they should be used."

I would hazard a guess that you are either still being a student with Utopian ideas, or at a company with an infinite supply of money and time and very few clients. That's not to say they aren't an important part of a long-term development lifecycle, and I've had my successes, but there is always a marketing executive or retail owner with a small project who only understands and expects visual design. We'll all eventually come across a more difficult client, and although inefficient, it may make sense to jump a step ahead in your typical lifecycle in order to please them.

I know I'm not the only one:

Actually, I've had more than 10 years of experience working both agency and client-side. Trust me, I have worked with my share of clients from hell.

Making wireframes into successful communication tools is all about how you work with clients and how you present the wireframes. There are some excellent comments above explaining successful techniques.

It takes years of experience to get really good at this, but I don't think skipping the wireframing stage and going straight to comps solves any of the problems presented above.

Hi Kevin,
I didn't mean to give the impression that we worked with web designers for 6 years. Actually we just worked with one 6 years ago and then did nothing until we hired a new designer.

But I do agree with your point that it's all in the presentation to the client. I also work in a service business and have realized that clients' reactions are mostly dictated by my presentation. Meaning that if I seem doubtful or don't have a clear strategy in mind, they sense it and feel doubt too. But if I know what I'm doing, and communicate that, most clients let go and allow me to do my job.

Hmmm. On a personal project where I actually was the client who also makes wireframes - I can say that diving into fully comped up screens would have been madness in terms of time spent determining initial functionality and hierarchy of information displayed then making fast iterations.

Here is an example of a page where certainly many rounds of wireframe development helped define the ultimate display layer design:


I am with many in this thread that question Rutledge's (I highly respect him and his work) "how will this help my client in the project process?" question in which he seems to imply that wire frames should not be client facing documents, but appreciate his questioning of how and where they are best used.

- Andrew @andrewkorf

Hmmm... I am the client Matthew mentions above (followed his link here from Twitter) and from my perspective, the wireframes were invaluable, even though the design has taken a different shape.

It makes me wonder if the issue usually isn't wireframes themselves but a) why the designer is using them in the first place and b) how he/she communicates with the client.

When we hired a designer to work on our first website 6 years ago, there were no wireframes. We told the guys what we wanted, they made a few suggestions, then they came up with a design we liked and basically built what we asked for. As the years went by, we soon found a thousand flaws with the design - things we hadn't thought of back in those early stages.

But with Matthew's company, the experience was night and day. We told them what we wanted and they listened, but then they put us through a rigorous strategy and planning exercise. Once we had challenged all our preconceived notions, and developed a strategy, they presented wireframes as a way for us to see that strategy in action, so that we could identify issues with navigation, or see places where the strategy was getting lost.

But prior to viewing the wireframes, the guys made it very clear that what we were seeing was only the function and not the design. Far from making us lose faith, it strengthened our faith in the coming design, because we were able to fix flaws at the stage.

Now that we are in the design phase, Matthew has made changes to the original wireframe page layouts, but not to the navigation or information hierarchy. And we have never once had to ask them to go back and change functionality. What's more, I know that this time we have a site that has been thought through to the nth degree - I didn't have that feeling last time.

All this is why I say that I disagree with the idea that wireframes are not useful to the client. I just think it depends on how well the design firm uses them, and how well they educate their clients.

It sounds like you're an experienced client, so to say. You've been working with web designers for 6 years, so you might have a pretty good understanding of how the web design process works. You might be comfortable with having a wireframe given to you because of that experience, while another first-time client may be unintentionally mislead or come off with the wrong idea about how the design is progressing.

I do agree with your point that a client may hesitate when wireframes are presented because of *how* they are presented. If a designer is good at making the client feel comfortable knowing that the wireframes are just part of the process, presenting them can get invaluable feedback from the client. They know their own audience better than you ever will so I find it important to keep them in the loop.

Wow. What an issue. I found myself getting irritated at your article till I started reading the comments. Then I understood the issue again from your point of view. Wireframes have been a consistent pain in the ass in every project I've worked on. No client, even a well trained design team, can fluidly move from wireframe to design without either changing elements as you mention above in the Unit example or compromising the possibilities for design and sticking to the wireframe strictly.

I'm engaged in a project as we speak where the wireframes were an incredibly useful tool to help the client make some strong business decisions about hierarchy, user-flow, and other interactions to support their strategy. Then I began to design, and I began to see massive differences in the way that the wireframes were designed and how I wanted to present things as a design.

*One Solution* is to do full or nearly full designs right from the getgo on two or three main "template" pages. This of course is flawed because it is not cost-effective. Or appears not to be. I can imagine that a strong designer, if they utilize a tool like mood-boards, and if they are a good listener, could created a strong first set of pages, and potentially remain profitable. Potentially they could meet a massive sink-hole of time though.

*A Second Solution* might be to have greater interaction with the IA and the designer _before_ the client is ever shown the wireframes. The wireframes could potentially be a higher grade of grey-box wireframe, perhaps even with imagery to allow the collaborated product to have a stronger visual presence for the client.

*A Criticism of The Article* that I have is that I don't see a consistently applicable solution as much as a broad critique of mis-used IA. I'd like to hear (Andy) what you suggest web teams do in scenarios where the budget for IA/Copy/Design/Dev is 30-50k, or even less for a large portion of our industry.

*Some Praise for the Article* is that I find it refreshing to hear you talking about something that I'm experiencing at this very moment, and trying to find a solution to. I really appreciate your focused and well written opinion on the topic. :)


I agree with the article. Frankly even if the blueprint analogy worked, truth is clients struggle to understand those too. There is too much special markup in a blueprint for most people to understand once you get to something functional like stairs. Same thing happens when a wireframe tries to convey flyouts or other interactions. The client can never be educated enough, even in-house. The visual cannot be divorced from the functional for all the reasons stated above. Any translation that the client needs to do is a hindrance to clear communication, so ideally we should be presenting as realistically as possible...as stated above.

But I think this is all a tools issue. If we look at the most common tool in our industry, Visio, that thing doesn't even work in the same unit of measure that we need! Most other tools we use come from other industries and duct taped together. I say we do a symbolic burial of Visio at Interaction '10 so we can get that ugly episode behind us.

Wireframes don't communicate aesthetics. Photoshop comps don't communicate functionality and flows.

I think the issue is less about what you show, and how you manage what you are showing, and how you balance the two (as well as other key devices) throughout the process.

>> Before you create a detailed wireframe for any project, ask yourself: "How will this help my design process"

I am a UX designer and I use wireframes as an interaction design tool to establish what information and controls will appear on a page. Whenever possible I try to use final copy and sample data in the wireframe, so that it reflects a reasonable state of the application.

As an example: if I am designing an application that has a list of customers and the client has a requirements document that says that the software should allow the user to be able to filter that list. With that information in hand, I can create 2 or 3 different wireframes to show the different ways that filtering controls could be presented. The wireframes make it easy for my clients to see the differences in interaction design approaches. Since I can produce wireframes very quickly, it lets us explore many different ideas together at a relatively low cost.

Naturally, I always take the time to explain what a wireframe is and how I use it in the design process. Some clients can be put off by the lack of visual design in the wireframes. When I think that's likely to happen, I will take the time to render one of the wireframes as a completed design early in the process. This enables my clients to see how a wireframe for their product can be turned into a final design ... and it also kick starts the discussion on the visual design.

The example you show, with the Promotional Area is an example of what I try to avoid in a wireframe - by making it look too polished, you've made it look like a finished product. Wireframes should look sketchy. It will help clients take the visual design aspect of them less seriously. When you have a polished looking wireframe, then the client can't help but react to the visual design.

Whilst wireframes are indeed my preferred way of working especially during the early stages of design I agree that not all clients react to them well.

Even with explanation of the benefits many see it as a waste of time or are not creative enough to separate the concepts of design and structure. In my experience this can be on quite large projects and not just simple stuff.

When you present them their wireframes, you talk about them in the context of their business, and how the design decisions you've made will benefit their business. I've seen so many designers present their work and talk about the layout, what this or that button does, etc., they dive into the fine functional details, so if you start put talking about layout details, that is how the discussion will go. I've found what works is to set the stage by talking about their business needs, the user needs, and the ensuing strategy, then tell them how your design solves those problems...show a client how they will benefit, and the rest is usually easy....granted, this comes with some level of experience ;)

Interesting comments from everyone...thanks! I agree with different bits and parts of what the article and comments say, but since everyone commenting so far has taken one side of the argument, let me add some thoughts on the other side:

I've been in more than a few meetings following some client snafu where someone has said, "We need to do a better job of educating our clients before showing them deliverables." I agree that if clients and stakeholders could be brought to understand the purpose and meaning of wireframes better, their responses to them would be more constructive. But how realistic is it to expect to be able to educate them in this way?

You can't show them wireframes from other projects and expect them to understand how wireframes will work on their project. They won't be familiar with the other project, and will be comparing final wireframes against the final UI of the sample project without seeing how the wireframes went from draft to final, or how the UI went from the wireframes to the final product. Looking at samples doesn't confer an understanding of how to use wireframes as a design and cognitive tool. The sample wireframes will just look like artifacts of something unfamiliar. It isn't until you've really used wireframes as a tool, instead of simply viewed them, that you begin to understand their purpose, benefits, and limitations.

The only time the clients or stakeholders get a chance to actually use wireframes is during the course of their own projects, at which point it's too late to educate them. It's a Catch-22; you need to bring them through a process of wireframing before they can be understand wireframes, but you need them to understand wireframes before you dare bring them through a process of wireframing.

I find wireframes a great way to present to clients the features that we plan to implement based on user research. Clients are often not knowledgeable enough to discuss a certain feature using "designer's language". Instead, a simple but visual communication tool is exactly what you need to get your point across to the client. As long as you make clear to the client that these are rough sketches you're presenting to communicate an idea, you shouldn't encounter too much trouble.

I think the point is rather about doing the appropriate research before wireframing. If you start wireframing without an idea about the brand, what content is to be present in the design, who you're designing for, and so on, you shouldn't be wireframing at all. You won't have a clear enough idea about what content and features you should design for. If you're wireframing, you should also be able to present a wireframe that is reasonably close to the final design, taking information architecture and content into account.

A wireframe's purpose should never be to convey "the impact and effectiveness of the fully-articulated design that will follow", but rather how we plan to communicate through the website, what will be where, and how it should work to allow that communication to take place in an effective way. The graphical design should then work to refine that specification.

The purpose of a wireframe, goes way beyond articulating layout and information hierarchy. It's a crucial step in the interaction design process to manifest business requirements into a user experience that meets the needs of the business, and the needs of the user. It illustrates a content strategy, or a conversion process...shows how we will solve a business problem. I'd hardly call a wireframe a "guess".

The mistake is not managing and educating the client as to what they are, and why we do them. Or in some cases, the mistake is not finding out exactly why you are designing the website to begin with.

As was mentioned, it's only the most basic of brochureware sites that don't need it. I'd be hard pressed to think of a project that didn't require them in some form. Visual design is a further refinement of an interaction design, and yep, the layout will change, but it should change to the benefit of the interaction, and an IA should have input to those decisions...well really designers should have a clue about UCD, but that's a whole other topic...

Most of the objections in your article can be done away with by simply explaining to the client what wireframes are and how they should be used. Plus, if you're working with a good UX Designer who creates detailed wireframes, information hierarchy is as clear in wireframes as it is in comps. The UX Designer is responsible for defining and creating that hierarchy so the Visual Designer can concentrate on creating the visual design.

It's only the most basic brochureware that does not require a good deal of forethought and planning to get the functional elements right - which can also be accomplished in the wireframing process.

Sure, if you think your client is not capable of grasping the nature of wireframes, don't present them, but if you want to save your Visual Design team a lot of time and save your developers from a lot of guesswork, you should still create wireframes to be used internally.