TecEd’s Garett Dworman provides his insights into the sometimes confusing topic of discerning when a wireframe is adequate or when a prototype is necessary…what are your thoughts?
Good question! For me it really depends who I am communicating with, and what I’m trying to communicate. In this manner, wireframes (of various fidelities) can be useful for illustrating a quick concept to the design team, or having some editable resources on hand that can be adapted as needed for a large or ongoing project.
If I’m working on a prototype, I’ve pretty much always done wireframing of some sort on those screens beforehand - often hand sketches or Balsamiq mockups. I include prototypes in most of my projects - mostly because I like bringing development and design together, and because I like the way Stakeholders can also see the product coming together on screen (rather than on paper) but obviously this depends on the creator’s code literacy, where decisions are yet to be made, and the complexity or otherwise of what is being produced. Prototypes also become more useful for me when working on flow and interactions, and when putting things in front of a test participant (whipping paper prototypes around isn’t always ideal).
I think Garett’s article is actually a great articulation of the key points. What stood out for you?
I definitely think its about the approach more or less. My process usually works from a basis of napkin sketch of concept B[/B], refined sketch and interactions in sketchbook B[/B] to wireframing in Omnigraffle B[/B]. In this approach, the easy toss it away - [I]all the way to[/I] - lets see the mockup approach allows for my clients to feel engaged in every step and provides context for transparent communication.
I only consider prototyping ([B]visual to html/css[/B]) once some of the kinks are ironed out in the [B]mid-high wireframing[/B] stage. Also, it helps shed light on items/interactions missed. As Luke mentioned, some stakeholders don’t value the regular hand sketch as they feel like its not as concrete to use for a discussion.
It ultimately boils down to the audience/stakeholders into what approach may yield the best results for communicating the end goal. You technique may very.
This caused a lot of conversation on Twitter…
To follow on Dean’s post, I do also feel like there is some movement towards skipping over wireframing to prototyping. I’d agree with Luke that prototyping is important for designing/testing interactions, because it’s much closer to the real thing than a wireframe. And now there are really good prototyping tools that can even take hand-drawn sketches and make them interactive. What I have found is that for my more traditional point and click website clients, wireframing is enough, but for my new product-from-scratch SaSS clietns where everything in the UI, including all the click and hover-over interactivity is more complex, sketch-to-prototyping is more efficient (wireframing can also take a lot of time).
Agree that the usual caveats apply: depends on who you’re communicating to.
I prefer computer to pen and paper (quicker to adapt for me), and I like that there are some tools that bridge the gap from wireframing to interaction. Have been using Moqups to do both wireframing and prototyping, which works well enough for my purposes.