Pen(cil) and paper to live prototype – where’d the wireframe go?
by petermeUser experience designers are very comfortable in the land of architecture diagrams, user flows, and wireframes. We love our black-and-white drawings that specify interaction. And this is a problem.
One of my key realizations from last week’s UX Week 2008 conference was how no one talked about such things. Instead, conversations about the act of design had one of two loci – putting pen (or pencil) to paper (or whiteboard), and creating live prototypes in the form of the final delivery.
So, with respect to the former, we had Leah’s UX Team of One talk, where she uses hand-drawn illustrations and talks about sketching, we had Mark Baskinger’s “Drawing Ideas: Quick Sketching for Interaction Design” workshop, we had Michael B. Johnson from Pixar talking about how important it is for Story Editors to “draw fast”. As user experience evolves, and we think about interactions that happen not just on a PC screen, we’re needing to be freer and looser when we come up with ideas, which means sketching, lots and lots of sketching. Whether it’s the sketchboards that Brandon and Leah taught as part of their workshop “Good Design Faster,” or the video Jesse made to explain the Aurora interface, facility with a pen is crucial.
On the other end we heard a lot about prototyping experiences. Jensen Harris, in his session The Story of The Ribbon, talks about how early on in the development of what became Office 2007, they were making live prototypes so that they could really appreciate the *feel* of the software. Michael B. Johnson, in my interview with him we posted on the blog (and he reiterated this on stage), “if you’re trying to build a prototype that you want use as a blueprint, it should exist in the same medium as the final product.” Basically, specifications are not close enough to the real thing to communicate what it’s like to actually use something, and we need to just build stuff and feel how it works.
So, where *did* the wireframe go? I think the role of the architecture diagram, user flow, and wireframe belongs very much after the fact, after we’ve sketched and prototyped an experience. Those are tools to document what has been agreed through sketching and prototyping. They are not the best means for solving challenging design problems.
Speaking of sketching, we’ve noticed that a couple of attendees (Ty Hatch, T. Scott Stromberg) have put their sketchnotes of the event up on Flickr. Cool!
August 21st, 2008 at 7:52 am
I could not disagree with this trend more if I tried.
I think — from reading things like this, from some training sessions — there is a general, though not universal, opinion that all drawing is bad. Design is such a pure endeavor that every tool gets in it’s way. This seems to have led to a desire to get to the final state as quickly as possible.
Wrong. Design is a process. You should be iterating and incrementing as you draw those first sketches. And continuing as you explore the details of the interaction. Only diagramming, grid development, flow charting and wireframing can actually help develop designs. And this is nothing new. Print designers who work without guidelines (without exploring the grid) and go ’straight to prototype’ tend towards repetitive design or just straight-up poor designs.
There’s another serious issue I have with design-straight-to-prototype, and that is limiting innovation. I routinely come up with new and exciting ways to present information. When it gets built (it doesn’t always) these are often not visible until shortly before launch. No prototype tool can shortcut this design and development phase. Those I have worked with who latched onto rapid prototype ended up executing a lot of the same tried-and-true Flash doodads as always.
August 21st, 2008 at 3:43 pm
Good riddance to wireframes.
I have always found them to be completely misguiding for everyone involved: clients, developers, designers, even the information architects. They do the opposite of providing clarity. They use words (usually poorly written) and complicated appendices to try and explain complex relationships and dynamic functionality – words and appendices that few people actually read and certainly nobody completely understands.
Information architects create systems that are poorly structured because they only make sense in their abstract mental model, but frustratingly make no sense when you’re in the middle of their labyrinth. They haven’t had to feel their way around, they’ve just thought about it on a purely abstract, intellectual plane.
Developers and designers end up guessing what they’re being asked to build and often invent their own solutions in the absence of a clear direction.
Clients generally go along with it, thinking they “kinda get it”. But when they see the end product invariably they find it’s significantly out of line with their expectations.
Prototypes, on the other hand, let people feel the flow and experience the relationships. Building prototypes allows architects and interaction designers to quickly identify broken pathways and iterate quickly to find better flows – by feeling the experience, rather than thinking about it in the abstract. Developers, designers and clients also get a much more tangible sense of what the end product will be.
The world will be a better place when people abandon wireframes and create prototypes instead. I’m really glad to see that finally happening.
August 21st, 2008 at 5:57 pm
The #1 reason sketch-to-prototype works well is because it forces people to write. The road to hell is lined with Lorem Ipsum.
August 21st, 2008 at 10:41 pm
The lovely thing about sketching around a whiteboard or sketchboard is that it promotes collaboration around a thing thats evolving. You can also communicate a story as your draw and invite feedback. Framing the discussion is important and this is where a good facilitator can bring the discussion back to business goals, user needs etc
Wireframes are also useful but later in the process. The more finished a product looks the more likely thats the thing that will be implemented. Seen it happen many times
August 27th, 2008 at 8:59 am
I agree with the idea that interactive prototypes are the evolution of wireframes but I still use wireframes in most of my projects. The clients I have been working with find them really useful before the design process. Wireframes are an easy tool to work with and clients feel that they can make alternations easily than being presented with an example of the final product. They focus more on the structure and layout of information than being distracted by designs and colours which is the next phase of the product development. My opinion refers to websites designs as this is the product I work with so far.
I believe that wireframes are useful both in the beginning and later in the process.