Wireframes vs. Prototypes Wireframes and designers……. oh boy! Some people have begun to doubt the need for wireframes. Christina Wodtke, an IA par excellence, highlights three problems with wireframes: wireframes weaken the designer wireframes create design lockdown way 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 freaking conga line. 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 the 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. Here’s how it goes in a team format: 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. 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, I have delivered those systems in the past and they can become much more than what they seem. Wireframes vs. prototypes For all the reasons listed above, I don’t wireframe the way I used to even a few years ago. Now, I 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? I 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.