Fuzzy Thoughts

We haven’t talked about prototypes or wireframes yet in our design series, but they are a key component of our work. Prototypes are so central to how we communicate and such a big topic for us that several of the next design series articles will talk about just that.

Wireframes and designers oh my!

Some folks have begun to doubt the need for wireframes. Christina Wodtke, an IA par excellence, highlights three problems with wireframes:

• wireframes emasculate the designer
• wireframes create design lockdown too early
• wireframes create a false sense of security about the completeness  of the work

I humbly disagree with all of that. Though Ms. Wodtke is one smart cookie, that doesn’t sound like anything I’ve experienced. In the comments of the article Thomas Vander Wal notes how Andy Rutledge’s Where wireframes are concerned, influenced his thinking. It’s worth reading in its entirety, I’ll sum it up briefly here.

Rutledge’s well-written article argues that designers often mis-apply wireframes to their work as graphic designers, swinging the pendulum in firmly in the right-brained direction of “it can’t represent visual design well enough’ and clients may be spooked by wireframed representations of pages which rely heavily on graphic design (typography, color, imagery, layout, etc.) to sell the concept. If those things are happening through the use of wireframes (bad communication with your team or client), you need to make sure your work is communicating appropriately and helping your team members do their jobs.

These problems can happen in projects with a waterfall from Information Architect or Interaction Designer to Graphic Designer to UI coder to engineer to QA, with the client riding down along the falls in a barrel. It doesn’t have to be that way. Everyone does not have to see each iteration of a design. It doesn’t have to be one activity after another like a string of pearls.

Sketching and user centered design

Why not have the IA/ID and the GD create sketches, one being a wireframe and one being a comp? Think of these as the one you plan to throw away, not the one you plan to show to the client. You know, iteration, planning to throw one away, all of that. As Bill Buxton would tell you, that’s the way to go to generate lots of ideas quickly, then narrow them down.

Regardless, I find it hard to categorically deny the end product of many different types of activities because of its name, and a misapplied name at that. It’s like saying you’re allergic to cats and now you deny the need for animals. ‘Wireframe’ is a category, like ‘bird.’ Like birds, some wireframes are turkeys and some are peacocks.

The purpose of wireframes

Sketching generates dialog about a product with other designers and stakeholders, then to formulate the experience for construction. The IA sketches a wireframe, the team talks, the graphic designer sketches a comp, the team talks, they make revisions and they move on. The process allows for feedback and revision but keeps the ball rolling by moving towards releasing software. Ideally, if your budget allows it, that sketching happens often, and in tandem.

Whether the resulting software is great, that’s another story. Here’s where Wodtke gets it a bit more right:

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.

We don’t hear much about how awesome it is because people are much more visually and interactively literate these days than a decade ago. The experienced practitioners amongst us have been working that long, but now our most technophobic family members have cellphones. They all use the web. Our professional peers get the basics, what they need is the big picture experience.

Your wires should be more than a sketch only when your team is big, your product is big, or there are other drivers that make your knowledge management and communication needs heavy and worth the effort. Otherwise, nothing should justify the immensely detailed documentation system wireframes can easily become, in which each module and state is spelled out in painstaking detail. Believe me, we have delivered those systems in the past and they can become much of what Wodtke warns against.

Wireframes vs. prototypes

For all the reasons listed above, we don’t wireframe the way we used to even a few years ago. Now, we simply focus on prototypes. If wireframes use words to describe interaction and implementation notes, prototypes use interaction but often fall down on the details since they aren’t a spec. What’s a poor UX practitioner to do?

We create documents that include the good aspects of wireframes and prototypes in one handy package. Exported one way, it’s a clickable prototype to evaluate the experience and gain feedback. Produced another way, it’s an annotated wireframe that communicates task flow, conditions and other data. Over the next few weeks we’ll talk about how we use Omnigraffle to prototype solutions, and how we use AppleScript to make the prototype serve different audiences and needs.