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.Translate!
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.