Skip to main content
Ben Nadel at cf.Objective() 2013 (Bloomington, MN) with: Guust Nieuwenhuis
Ben Nadel at cf.Objective() 2013 (Bloomington, MN) with: Guust Nieuwenhuis ( @Lagaffe )

Wireframing For Everyone By Michael Angeles, Leon Barnard, And Billy Carlson

Published in

This morning, I finished reading one the latest "A Book Apart" releases: Wireframing For Everyone by Michael Angeles, Leon Barnard, and Billy Carlson. A quick read, the book explores the value-add of wireframes from the individual, team, and product perspectives; and, steps through the creative process from raw idea to formulation to engineering hand-off to deployed solution. I loved this book! It felt like coming home.

Ben Nadel giving a thumbs-up to Wireframing for Everyone book.

Early on in my career, I had a stack of sketch pads and a box full of pens on my desk at all times. Whenever a random idea popped into my head, I would quickly draw the vision down on paper as a way to catalog my thoughts and to provide starting-off points for future conversations. It was thoroughly fulfilling to see my thoughts codified. But, more than that, I believe the act of sketching fueled much of my creativity.

Clark Valberg - my co-founder at InVIsion - captured this so eloquently a decade ago when he said: Low-fidelity is the new high-fidelity. What he meant by this was that by working in a low-fidelity context (like a sketch, like a wireframe), it frees us from the burden of incidental design and allows us to focus on the most critical aspects of software: solving actual problems for our actual customers.

Over the last 10-years, I lost my way. I stopped sketching. I stopped wireframing. I stopped getting feedback from those around me. Essentially, I stopped collaborating, in large part, due to a contentious relationship I developed with our Product team. I swung heavily into a "don't ask permission, ask forgiveness" mindset. And, when operating in that mode, it's best to just get things done now and then sweat the details later.

Which is the exact opposite of how great software is made:

Great experiences emerge from teams where everyone can participate in the design process. We've witnessed the power of informal, low-fidelity design that invites the whole team into the design process. (Page 6)

... Unlike a prototype, which must accurately reflect the final product, we determine a wireframe's effectiveness by the conversations it creates. Letting go of unconscious rules about what a design artifact should look like can lead to better early-phase wireframes. (Page 13)

I used to describe InVision as a collaboration platform that just happens to use prototypes as the means of conveying information. I always did - and still do - believe that the collaboration aspects are the magic sauce of InVision. A big misstep of ours - in my opinion - is when we started focusing more on the design of software and less on the people and process of designing software.

But, I digress; this book, Wireframing For Everyone, stirs up a lot of emotions for me. It shines a light on so much of what I should have been doing at work.

As I was reading it, I kept nodding in strong agreement and highlighting passages. I probably annotated 1/4 of the book's text. So much of it spoke to me:

We use wireframes to both illustrate and articulate what a product will do. They're created using a hybrid of sketching (a technique for capturing rough ideas quickly) and prototyping (a technique for demonstrating functionality that more closely resembles a final product). By harnessing the most effective aspects of each technique, wireframes tend to provide more information than sketches alone, and the process of creating them encourages more exploration than prototyping alone.

The primary benefit of wireframes to software organizations isn't their ability to represent a user interface but their ability to visualize and facilitate the transformation from idea to code - in the same way that a napkin sketch can instantly cause one person to understand what another is talking about. The understanding is the output.

That's why it's helpful to think of wireframes as more like sketches than prototypes. In a wireframe, like a sketch, you leave things out on purpose in order to focus on the idea. The lack of fidelity - and the ability to stand in for the real thing - works in its favor.

Starting out at a very low level of granularity allows you to evolve the design deliberately by moving on to finer levels of detail only as you become more confident about the coarser ones. One of the mottos of wireframing is: fidelity should correspond to certainty.

This isn't only apparent in digital design. Low-fidelity ideation is the foundation for creative work in architecture, painting, sculpture, performance art, automobile design, animation, and film. (Page 9)

This phrase - "fidelity should correspond to certainty" - is so freakin' juicy! It's exactly why I am keeping Dig Deep Fitness as raw HTML while I flesh-out the concept. It's exactly why I get so miffed at the idea of designers working on micro-interactions and animations before a feature is even fully considered.

This book is a value-add for anyone and everyone involved in software design and development. Sketching and wireframing are all about conveying ideas and information. And, we all need to be better at conveying ideas and information. That is how great software is made.

Reader Comments

Post A Comment — I'd Love To Hear From You!

Post a Comment

I believe in love. I believe in compassion. I believe in human rights. I believe that we can afford to give more of these gifts to the world around us because it costs us nothing to be decent and kind and understanding. And, I want you to know that when you land on this site, you are accepted for who you are, no matter how you identify, what truths you live, or whatever kind of goofy shit makes you feel alive! Rock on with your bad self!
Ben Nadel