Developer Exchange Blog
The Case for Wireframes
Wireframes can save your project time and money. Jump on board and get constructive functional feedback sooner rather than later.
Nothing lights up a person looking for a new application solution like showing them the actual screens that they will ultimately use. That really gets them going. Suddenly, after seeming stymied by questions about what they really want and not really being able to clearly and completely articulate their true needs, they are awakend in new ways and can quickly arrive at "that's great!" or "no, no, no that wouldn't let me do XYZ."
We have found presenting screen designs to be the best way to make sure everyone is truly on the same page. Unfortunately, for applications of significant size and complexity, you really can't start there. There really is a need to explore the business goals, functional needs, outcomes necessary, constraints, available inputs and so forth before any useful attempt can be made to crystalize a user's needs into something they would recognize as a potential solution. Nevertheless, you should attempt to get to screen designs as early as possible (whenever that is) to make sure your users can attest that your understanding of their need is truly aligned with their actual need - which quite often you will find not to be the case. The reason is usually rooted in the fact that the users have a very hard time explaining all the details about the tool they need without a visual image to crystallize their thinking.
There is no single "right way" to do this. However, and again, for applications of significant complexity, I want to make a case for using wireframes to drive out valuable user input as early in the process as possible. Before I do, let me make sure we are all thinking of the same thing with regard to what I mean by a wireframe drawing.
Screen designs can be created in many different ways with many different levels of fidelity and sophistication. The simplest approach is a sketch. Slightly more sophisticated, but still visually crude, is a wireframe. A screen design that's more realistic looking is usually called a mock-up. And at the far end of the spectrum and the most complex is a prototype.
The simplest, most crude form (for most of us that have educational degrees begin with BS and not BA) is a sketch. This can be done quickly, at least from the perspective of going from nothing to something visual to share. However, for most of us a sketch is usually too crude to be useful. Plus, sketches are often pretty hard to change. If you are truly hand drawing the sketch, it's a real problem. If you're using a computer based drawing tool, things are a little better, but still it's often hard to build templates that can be modified easily and the sketching becomes tedious and costly to maintain as requirements and changes are considered.
At the far end of the spectrum we have prototypes, and not far behind that, mock-ups. These can be great! The user can really tell what the proposed solution will look like and can weigh-in on all sorts of things. The problem is, these can be really difficult to produce. To do a good job, you'll need a graphic designer. Plus, you'll likely need to do some CSS and Javacript (if it's a web based UI) warfare to have the controls react so that the user can really tell what the proposed user Experience will be like. This is all great with one caveat - it's expensive to do AND it's not the fastest way to get input from the user. If the functionality has any complexity to it, you're going to be wasting a lot of time and energy on things that are NOT SETTLED. The whole point is to get good feedback as time and cost efficiently as possible so that everyone can truly work through both key and subtle aspects of the necessary functionality that will ensure the success of the project.
That leaves wireframes. These fall in the middle of the spectrum. From a visual perspective they can be quite crude, but they are useful at communicating concepts, functionality and major aspects of the user interface. They look kind of like a sketch but enough like a real application that the user can relate to them. On the other hand, they are crude enough that they help people to avoid wasteful sidetracks that have to do with aesthetic until the core functional needs are driven out and visually confirmed. Here are a couple of simple examples of wireframe designs from balsamiq.com.
The best part about wireframes is that they are much quicker to produce than mock-ups. You aren't trying to create a beautiful rendering of graphics and controls, you're just trying to demonstrate your understanding of the end users' needs in a way they can relate to and visualize as an application they would use. And, you're trying to do it in a way that makes it easy and cost effictive to quickly make changes as new requirements come to light - and they will.
There are some barriers to be aware of, though. The first one is perception. Sometimes end users, unfamiliar with this approach, may confuse a wireframe with a mock-up. It's important to establish the distinction early so that there's no anxiety over whether the crudeness of the wireframe will manifest later as a crude application. Everyone needs to understand and embrace that the wireframing techique is intentionally crude to keep people from wasting time on graphic design issues and subtle visual aspects until the important functional needs are truly vetted.
Another barrier is having the appropriate wireframe design tools and having skill with those tools. To be able to do this effectively, you'll need an appropriate wireframing tool. There are many to choose from, and we have our favorites. The person creating the wireframes will need a tool that's appropriate for the target application. If it's a mobile app, you'll need a wireframe tool that has the relevant controls that represent the typical controls for the mobile device you are targeting. The same is true for any other target. And, you'll need someone that has skill with the tool; otherwise, you'll be barely better off than using a basic drawing tool, draging you back toward sketching. With the appropriate training and a good tool, though, you'll be able to fly through screen designs, and you will be able to make templates that keep your models modular and easy to change as the feedback comes in.
I don't mean to imply that wireframes are the only tool necessary for building apps that your users will love. You still need to tackle the aesthetic that make your app cool and pleasing to the user, but if you focus on that too early, you'll add risk late in your project as you delay the discovery of important functional characteristics that might affect the underpinnings of your solution.
So, save yourself and your customer some time next time and get on board with wireframes as a cost effective way to get helpful feedback sooner rather than later.