« Agent Google versus the semantic web | Main | Passwords: How to align usability and security »

January 18, 2010

TrackBack

TrackBack URL for this entry:
http://www.typepad.com/services/trackback/6a00d83452629a69e2012876eadebe970c

Listed below are links to weblogs that reference Stop showing your wireframes:

Comments

Feed You can follow this conversation by subscribing to the comment feed for this post.

Good post, Josh. I agree -- from a product management perspective, interactive prototypes gives stakeholders a much better sense of what to expect from the final product and offers a better chance of reducing the "What if we...?" conversations later down the line. I wouldn't do away with wireframes (I'm working on one today) but the audience is more development than business.

I still think that both sketches and some level of static wireframes are part of our process. Wehther we can get away with doing them but not showing them to clients is adifferent issue.

I find wireframes useful for communicating with developers and visual designers, but not with stakeholders. Increasingly, I've found that showing them to stakeholders is either unproductive or downright harmful. I'd rather show stakeholders a rough sketch than a wireframe, because of the expectations and potential confusion that wireframes create. And the higher up in the foodchain the stakeholder is, the less successful it is to show them wireframes.

I do keep them in my portfolio, though.

Thanks for writing the article. I've been paying close attention to this topic online. As someone who has created thousands of pages of wireframes over the years, I'm not quite ready to ditch the deliverable either.

I think the consideration to get away from wireframes depends heavily on two things. One, how you create your wireframes; and two, the type of project.

Our wireframes serve two purposes. One is to get consensus with the client on what we're building. The second is to communicate to our visual designers and developers how to build it. The wireframes are not the "vague site outline" you mention. They are detailed page sketches, accompanied by annotations that describe all of the functionality and requirements - including things like link destinations, multiple states of elements, data sources, menu values, error messaging, etc. While a lot of this is in the form of the written word, it's much more meaningful next to the wireframe visuals.

At Roundarch, we tend to work on very rich interfaces. Creating a simple prototype would not communicate much more about the site than the wireframes do. And creating a rich enough prototype to communicate exactly how the interface acts would essentially be building the final product - and of course we can't do that without defining it first.

When someone broadly suggests ditching wireframes, I always wonder what kinds of projects/sites they're working on. It seems like a leap to make a generalization about how everyone should work.

There's also a huge element of client communication. We try very hard before presenting wireframes to communicate exactly what kind of feedback we're after. We talk about labeling, functionality, navigation, relative priority of elements, etc. - not precise layout; not imagery. Sure, we still get questions like "can the logo be bigger?" and "do the links have to be blue?" but in general it produces a productive discussion.

However I do agree strongly with Amy on this point: "The higher up in the food chain the stakeholder is, the less successful it is to show them wireframes."

Thanks for the comments folks, and the different perspectives on wireframes.

John, I'd say all us UX designers are working on rich interactive sites or apps now. If you're showing wireframes in this context, I'm guessing you're key framing, a la this article: http://www.alistapart.com/articles/web3point0/. But it's not about what kind of RIA you're designing -- I've just found that stakeholders won't make what they consider final decisions until they see higher-fidelity design and interactivity.

Do you find you can make decisions that stick and move things forward with this kind of deliverable? Or is it more of a "here's what we're working on" to prove your productivity to the client before something higher-fidelity is available?

Hey Josh,
I guess I'm considering the difference between an image-rich site or one with stronger user feedback / interaction, vs. one that's more of a collection of links (e.g., LinkedIn). Not that designing one is easier or harder than the other - but that the leap from wireframe or prototype to finished product can be significantly different. We get good feedback that sticks from wireframes about functionality, structure, etc., but of course the final look and feel gets approved a little later when visual design gets involved. But I don't mean to imply that we have a strict linear progression - we get visual design involved very quickly and surely make tweaks that arise during that process.

I mainly use wireframes for myself. I have always felt that the end customer wants to see something with a bit more of a polish. Wireframes are great when I'm in my first design iteration. They are even better when dealing with rapid agile development.

There are several problems I see with not using them.

  • Design & Interaction can change rapidly. If you don't have time to create a full masterpiece it's a great tool.
  • Lack of a full concept can lead to dire interpretation of the design. Wireframes can help you decipher the primary & secondary functions as well as other outlying activity for an application.

Beyond that I prefer a combination of techniques to "get the point" across.

Now if we want to talk about an IA method that needs to be revised let's talk about personas. Unless you are building a web site for someone completely unaware of the internet, personas I rarely use - Customers and users today tend to adapt much faster.

As with everything, this is a matter of framing the discussion, and making sure stakeholders have the right expectations. I have great success using Balsamiq wireframes to get stakeholder approval on initial design direction, and as a developer deliverable. In fact, the annotated wireframes become the specs. The back end developers prefer working with wireframes rather than comps, since it allows them to concentrate on the functionality rather than the visuals.

I think that the stakeholders changing their mind at later stages of the design is a process issue, and not the fault of the wireframes. And I don't think that there is some kind of other magical deliverable that can solve that problem. I would rather have to go back and edit my wireframes than to waste my time creating fully functional prototypes that have to be thrown away because the design direction changes.

The comments to this entry are closed.