After an extensive search, I find I have not written this down (at least in a blog– I have referenced it in talks.) Now, most of these points can be/have been addressed in one way or another. But one might ask yourself, what other deliverable is as criticized as wireframes, and could there be something better?
Firstly, wireframes emasculate the designer. Wireframes have often had a place in multi-disciplinary teams where the graphic designer had come from print, and didn’t really understand interface design. The interaction designer came from software and was making ugly terminal-esque interfaces. So in order to make sure the end result was palatable, the interaction designer (or information architect; I’ll use this term interchangeably in this post) would make a pig, and then the graphic designer would put lipstick on it. This was 1998.
But as designers got savvy to interface, they started resenting the restrictions on their ability to creating compelling and useful designs. After all, a designers toolkit is essentially font, color and layout. The web browser stole the first, if the IxD steals the third they are relegated to the sorry position of kid with crayons handed a coloring book. Think hard of the last wireframe you saw. Didn’t it look a lot like a paint-by-number, with only the numbers missing?
Now there is a new fresh crop of kids coming out of schools like Carnegie Mellon who are well rounded and can do both jobs, as well as a crop of old dogs who have worked hard and learned the principles of graphic design (if you can learn it in two years in college, surely some IAs and IxDs have picked it up). We should ask ourselves how often we need separate roles for interaction and interface design. Then, when we do need the deep knowledge the two specialties provide, we need to ask how can we create a process that allows both to fully utilizes their skills. Getting them to team up, do whiteboarding, have the designer do early sketches, have the IA use balsalmiq or even– gasp!– paper to express their thinking are all fine solutions. Even keeping wireframes, but having the designer do them can help, since it moves the job (layout) to the person with the skill (graphic design).
Secondly, wireframes create design lockdown too early. I had a theory about the birth of wireframes. It’s cynical I know. I imagined an agency in the ’90’s, who loved the idea of IA/IxD (since one more person means one more person to markup). But they needed deliverables for the client to sign off on (and thus bill for.) Well sitemaps were big and impressive, and so were flows, but no one understood them. What could the client really dig his teeth into in the early phases? Early versions of the design! Voila! and a billing cycle was complete.
Let’s be honest. The wireframe shouldn’t reflect the final layout of the site. Because there is no color and type treatment, you have to do goofy things to get elements emphasized like put a box around it, or make the type bold. You are essentially designing with two hands tied behind your back. If the wireframe was just for you, you might be picturing red accents, or iconography, or georgia 30pt. But once you have to show it to your client or your boss, the wireframe has to communicate and without color, image and font it doesn’t. So you do goofy things, and dang it if those goofy things don’t make it to the live site! We’ve got a million sites out there with little boxes around each piece of content like the content was a cow that, if not fenced in, might try to mate with the form fields. I think wireframes and blogging tools are the two worst things to happen to web design in the last 5 years. (more on why blogging is bad for design later…)
Lastly, wireframes create a false sense of security about the completeness of the work. Wireframes are not interactive, but they look done. Most engineers are annoyed by wireframes, unless accompanied by usecases because wireframes typically don’t reflect every single state and error case possible. Most would rather just have a prototype. Oh, I know your engineer loves your wireframes. Have you ever given him a prototype? Did he scream and say, please give me wireframes so I can go back to making up the functionality like I did before? The boss has signed off, yet the web dev is rolling his eyes at you because the wireframe doesn’t represent load order. I know many folks out there heading for the comments field will list the eighteen ways they have figured out how to document these things, and I don’t want to stop you because many many shops can’t give up wireframes. But I do want to encourage you to talk to your engineers as if they were a precious end user (because they are, of your documentation) and find out what they need.
There is another downside here, which is hard to put into words. I’ll try. Interfaces either feel right or they don’t. Your mouse either slides naturally to the correct button, or it slides naturally to the wrong one. There is no wireframe on earth that can help you get the feel right. Because feel is made up of many elements, including color (red means bad) , type (8 pt means legalese), and interaction (dialog box asking “are you sure means” committing an action). The faster we get to using all the tools at our disposal to replicate the final experience, the faster we’ll know our design stinks. Or is intuitive.
I haven’t heard much lately about why wireframes are so awesome. I know they are incredibly useful as a thinking tool. I can’t work through an idea without getting out a pencil and scribbling out some wireframes on a pad of paper. I’m not sure they are good as a communicating tool. The feel like an odd leftover from a day when sites were static and you could make a sitemap on one piece of 8 1/2 x 11.
Anyhow, now I’ve written something down, go to town. The comments are your playground. I’ll try to swing by and approve regularly (I had to turn off autoapproave because the russians find my site way too delicious.)