20110926-dapb99jehy7weccnw21tq12j2p

Why, Why, Wireframes.

The debate rages on about how wireframes fit into a studio’s overall process.  I suspect that wireframes or sketches, to some degree, have always been a personal choice for a designer.  Some designers may find it easier to get into photoshop right away and start working away at a blank canvas until something takes shape. Others prefer to approach their work a little more methodically and sketch out high level ideas and then work within photoshop to efficiently produce a fleshed out concept.  The latter, being the digital designer’s version of ‘measure twice, cut once’. Even so, not everyone needs to be methodical to produce excellent work–I’m certainly envious of those that don’t need to think through ideas with pen and paper because, quite frankly, I’m too insecure to not bounce ideas off other people before diving headlong into a concept.

But creating a uniform, one-size-fits-all process isn’t really the point, is it?  We all have different ways of working and getting things done.  Whether you work within a team environment or as a solo freelancer the issue isn’t how we work rather, the issue, as always, is how can we work more effectively.

We’ve taken a good long look at our process and how it, and our business, has evolved over the past 10 years.  Like most, when we were first starting out, we didn’t we know what we didn’t know. Nor, did we have a clue how to manage a workflow.  We just got the work done all willy-nilly and, eventually, as our clients got larger, our budgets and timelines grew too. All of a sudden we found ourselves with multiple projects at various stages of completion.  We just got to a point that we knew a responsible method for delivering client work was necessary.  That or, we’d soon be uttering words that can be so hard to say.

We introduced various stages to our workflow and all were very well received – Things which, now, seem like a no-brainer. Concept reviews, production reviews etc. All things that that made the creative process less and less nebulous.  They also provided an opportunity to include our clients early on and it really helped us get on the right track quickly. We took this same approach with wireframes. Not only were they a great tool to get the client to see how relationships between types of content created a hierarchy but, it also helped by removing a lot of decision forks that previously slowed down the design stage–making life for designers infinitely easier.

About 4 years ago we made wireframes a mandatory part of all web and app design and, internally, it was a great success. At first, we used pen and paper sketches and then quickly moved to Balsamiq as it offered us a way to present wireframes and quick site prototypes to clients.  And this is where we started running into friction.

Because we presented the wireframes as a deliverable that required client sign-off , it created a sense, rightly or wrongly, that  it should look polished.  No matter how much we tried to explain to clients that what they were seeing was a prototype and wasn’t what their site will eventually look like they couldn’t get their heads around it. For us, it was a quick way to determine if we’ve captured all the technical requirements, user goals and content interactions for each page.  For them, it was the first glimpse of their website that they are paying good money for.

After asking some trusted clients how they felt about our process and about wireframes in particular, they all said that everything was fantastic but when they saw the wireframes of their website, their hearts sank.  This lead us to the conclusion that wireframes shouldn’t be a client deliverable.  At least not for us. But, I just can’t escape how powerful and helpful they are.

The truth is, wireframes, when a client gets it, can be a god-send.  Not only do they involve the client early but also gives them a sense that the website or application is approached from a logical and methodical perspective rather than a nebulous ‘creative process’ – which for most clients, gives them the warm and fuzzies.   Just as important as the client warm and fuzzies, our team gained a greater sense of what each of us needed to do in order to bring a project to completion.  So, we decided to pull an about-face and keep wireframes in as a client deliverable but, client education was going to be key.  We were going to really have to explain the ‘why’ behind using them. We did this by showing clients past examples of wireframe prototypes and finished projects side by side.

Ultimately, we’re glad we’ve stuck with it because the ‘wireframe’ has become the quintessential planning tool. What good is creating interesting layouts and beautiful concepts if you can’t do so without the proper content? It’s like asking a builder to construct a house with out a set of plans from the architect. If the content doesn’t exist, neither does the design. Let me say that again – if the content doesn’t exist, neither does the design.  Getting the proper content at the wireframing stage or prior is the best way to get through design and development, with minimal scope creep and headaches. In the end,  clients can see how their content actually works and if it is in line with the overall objectives of the site–providing we’ve done our job and they understand the purpose of wireframes in the first place.

After some time, clients have really come around to the idea and purpose behind wireframes.  It also helps that, from a presentation perspective , there are now so many options to get wireframe sketches or interactive prototypes in the hands of clients and solicit feedback. We’ve recently run the gambit of these tools (which deserves its own post)–some of our favourites being myBalsamiq, Notable App and Invision.  We’ve landed on the amazing Invision because it’s so flexible and feature rich.

We’ve had success and failure with wireframes. We’ve won our clients’ hearts and lost substantial pitches because of them.  While I wouldn’t say we live and die by them, but if done right  they can be compelling, a huge time-saver, and a great way to get early client buy-in.  We’re still evolving our process and getting it perfect is a nice thought but its more of an endless pursuit than anything else and that, at the very least, is something that experience teaches.

 

Posted in Methodology | 4 Comments
  • Jon

    This is a good write. Are wireframes necessary? Yes. The human (client) variable is web experience. Varying degrees of web experience creates an unknown factor of how the client will receive (or perceive) the wireframe. I see static side-by-side visuals of the final draft wireframe, and what took shape in the lab… and I GET IT. But the next guy might not. We as a technoculture are so much more visual-spatial than ever before that we need to be spoon-fed data. We might even be behind technologically since our brains seem to want to jack-in to the system. I personally think someone should break that barrier and provide a representative animation of wireframe development for a page, and fade in the final product, then blinking all the elements side by side so that you visually guide the user to how the elements correspond to each other. E.g., blink wireframe1 element on left, then finished1 element on right, etc..

  • http://twitter.com/steeben Stephen Megitt

    @jon Thanks, glad you liked the write-up. I love the idea of showing draft iterations blending into the final. It’s always nice seeing the process–sheds some light on the mystery of it all. But, for me at least, it always leaves me wanting more. Understanding the decisions that go into making those tweaks are really where its at.

  • http://twitter.com/verneho Verne Ho

    Solid post. I was afraid mid-way that you were going to ditch wireframes as a client-facing deliverable, so I’m glad you guys turned to client education as the better solution. The truth is, wireframing is about more than just a designer’s preferred process. For us, it’s about isolating the variables so that we can make sound focused decisions each step of the way. We wireframe (and do any kind of IA) first because we need to make crucial decisions on structure, content relationships and sometimes interactions without clouding that process with decisions on visual design. When you get to comps, you make a different set of decisions that build on top of those previously made decisions.

    I think what your post highlighted best was the need to acknowledge that not every client will get wireframes from the get go. The solution is one part education and one part process tailoring. To your point about not aiming for a one-size-fit-all process, I think it’s important to have an assortment of approaches to wireframing that can be suitable for an array of client types (e.g. collaborative paper prototyping, groupboarding, interactive prototyping, etc). On the education front, it’s important to make it stupidly clear what decisions need to be made when a client is reviewing any deliverable (not just wireframes) or you’ll end up with, as you mentioned, false expectations or, in our case previously, blind sign offs.

    Thanks for sharing!

  • Anonymous

    Hey Verne, Thanks!

    We definitely agree on a ‘content first’ philosophy. Seems silly to me now that ‘lorem ipsum’ even existed in some of our concepts from years gone by. Now the process feels so much simpler because, as you say, we’re making decisions and choices, at the wireframing or IA stage, about how a user interacts with the proper content–which then informs the visual design. The days of just ‘dropping the content in’ after visual design are pretty much done.

    Let’s meet for a beer and I’ll tell you a funny story about the impetus for the rethiking of our wireframes.

    Steve