Why Wireframe?

wrote this on in . 64 reactions

As part of our work with clients, we're often called upon to explain our process and why we do things the way we do: it's good practice for us, keeping us sharp, and always evaluating whether we can do things better. Recently, we found ourselves explaining why we wireframe, and what it brings to the project: clarity of purpose, a streamlined set of features, and a focused, compelling way to communicate with users.

A client had brought ZURB on to redesign a fairly complex suite of web apps from the ground up. Restructuring a commercial app with paying customers is not a task to take lightly, so this was definitely a process that would require a lot of thought at each stage of the project.

So we started by defining the product: identifying pain points in the current app using a web audit, exploring new ideas with opportunity sketches, and talking to key stakeholders in the company. Next we moved into more detailed page sketches, and finally hi-fi wireframes in Omnigraffle -- the last stage (in this project) before moving into implementation (visual design and code).

But before we went over the wireframes with the client, they had just one question:

"So, before we start - can you explain exactly what these hi-fi wireframes are for?"

It's a good question. As obvious a step creating wireframes seems to us, it's easy to forget that other companies often skip that step - or even the process of defining the product entirely. Startups especially are under immense pressure to get a product out the door, often at the expense of thinking through some of the finer details.

So what are wireframes for? And what should a team do with them?

Order Out of Chaos

The early phase of a project (what we call the Define phase) is all about expanding horizons. Brainstorming sessions and opportunity sketches and customer interviews generate a sea of ideas, from new features to ways to solve pain points to UI details that will help elevate an app from good to great.

Wireframing, on the other hand, is all about corralling these ideas into a cohesive flow of pages with a clear, well-executed focus. A ruthless eye for editing is paramount: throwing every "nice to have" feature haphazardly into the mix will do nothing but create a mediocre product that frustrates users. (Think of Microsoft Office - now cringe.)

Remember: knocking a few key features out of the park is far better than getting 70% of the way there with a slew of semi-useful features.


But wireframing isn't just about cutting down - what fun would that be?

Wireframing also takes the hodgepodge of ideas from the sketching stage, the layers and generations of features of an existing app, and disparate opinions and ideas and thoughts from the team, and distills and translates these ideas into something tangible.

Before the wireframe stage, ideas are there, but like the sharpie they're written in, they're big and loose and lack detail. They're great for communicating ideas and gaining momentum, but to really define the app and get everyone on the team to rally around a new vision, we need to show that these ideas can really work. We need to think through those interactions and details that make a new app possible.

Wireframes can make the difference between a great idea dying in committee and getting a redesign out the door.

To succeed at this, it's important to approach the app with fresh eyes. This is easy for us when we work on client projects, but not so easy on our own products. When you know how you're supposed to use an app, it's easy to forget how a new user might see it. If you're too close to look at the app as a new user, bring in some people for user testing, or even ask a friend to walk through a couple of tasks. It's bound to be eye-opening.

One Step at a Time

If wireframes outline the structure and elements that go on the page, where do we draw the line between wireframes and visual design?

They do share some common challenges, after all. Visual hierarchy, placement of whitespace, and balance of typography are all just as relevant in Omnigraffle as Photoshop.

But at the wireframe stage, we want to focus on structure and content, not the color of the text or the drop shadow on that sidebar. It's far better to limit the possible variables at any one stage of the project so conversations stay focused and productive.

We use a few visual cues to draw a line between wireframes and visual designs: wireframes are almost entirely grayscale; the only exceptions are links (which are a shade of blue), and the occasional color element to demonstrate function (e.g. a warning scale from yellow to red). We'll often bring in the company logo and turn it to grayscale as well. We're spare with our use of gradients and drop shadows unless they clearly illustrate a function.

We want the wireframes to give a polished, concrete vision of the final product, without giving the impression that we're committing to a particular color or style.

Give It a Try

So what are you waiting for? Whether you're defining the next great thing or overhauling an existing app, wireframes can be an invaluable tool to create a focused, well-thought-out product. When design is truly well-done, those UI details seem simple and obvious (just look at Apple). But that seeming simplicity didn't appear fully-formed from the mind of a single person (visionary though Steve Jobs may be): it's the result of discipline, critical thinking, and hard work on the part of many people.

Swing and a Miss
You're Design Thinking Too Much
Design pot
Design or Get Off the Pot

It has 6 comments.

Dmitry (ZURB) says

Sweet post. Absolutely love the visual examples illustrating the points on there. Helps to understand the concepts so much better. It's important to note again that sketching comes first before wireframes, we iterate through sketches a LOT before we get to this stage as Tanya points out. It's a crucial part of solidifying the idea and getting the whole team behind it. I keep hearing from teams out there that they don't sketch early on and jump into wireframes- that's just failure waiting to happen.

Suggestion (ZURB) says

Prototyping/wireframing not only saves our money but also a lot of time and stress-instead of going over tons of documentation you just show a prototype to your client. One of the tools to use is JustProto. I'm using it to build fully interactive prototypes.

Greg (ZURB) says

In one of your recent posts What Our First Hour in Photoshop Looks Like, there was an interesting discussion in the comments about the usefulness of wireframes and if we should use them. I have run into difficulty with clients when using a wireframe because they are stuck on the little details and can't see the bigger picture. They want to talk about colors and font family and struggle to visualize how the components on the page will fit into the final design.

Although I believe they still save time and effort, how has ZURB been able to overcome some of the shortcomings that wireframes inherently have?

Liza (ZURB) says

Wireframing is really tricky, some designers forget that laying out project structure is just a minor phase, but interaction and strategy is the key. Plain wireframes can't show entire interaction as good as prototypes, which are rather costly on the other hand. I like technology and I think that we need to teach our clients to implement technology into their business ideas, so it is important to show this technological possibilities at the very beginning as well.

When someone with little or no experience tries to do wireframes, he treats them like blueprints and it's not good. It's important to use wireframes thoughtfully, I like to use them instead of project documentation, still only like one of the deliverables.

Your idea about coloring elements to demonstrate function is great. Thank you for sharing.

Tanya (ZURB) says

@Greg: You're right, sometimes it can be difficult to get clients to look at wireframes in the way we intend them, but we've had pretty good luck by 1) showing them examples of our work during the up-front negotiation process, so they know what to expect, and 2) reiterating at every phase of the project what we're doing, how it will benefit their site/app, and what we need from them. Setting expectations and reiterating what we need from them throughout the project goes a long way.

Tanya (ZURB) says

@Liza: Thanks for the comment! It's true - there's definitely a certain "skill" to doing wireframes that just comes with practice. Experience helps us decide what level of detail is going to work best for a particular project.

And that's a good point, wireframes are a great substitute for quite a bit of documentation. They can't capture everything - we often use Notable to annotate them with notes on how certain interactions should work - but they can cut down on the amount of Powerpoint/Word/Excel detritus dramatically.