One of the reasons why wireframes are often confused is that they come in many forms and can serve many purposes. A “quick-check” of what wireframes are doesn’t point to one single object – just try searching for wireframes in Google images. We like to call it the 50 shades of wireframes:
You’d have to dig deeper in research to get your answer. One of the most answers you can find is how there are “good” and “bad” types of wireframes, or that some company prefers a certain kind of wireframes over other. The basic thing that doesn’t get answered that way is “why”. Why should I use this type of wireframes, or this particular tool or include this level of fidelity or finally why should I even do wireframing? Let’s get to that.
In the A Practical Look At Using Wireframes we covered the first initial steps about wireframing. The absolute basics: who uses wireframes, what’s their purpose & how do they work together. The short answer is that graphic designers, engineers, business analysts, interaction & UX designers and other stakeholders use wireframes to work on:
- Structure – How will the pieces of this site be put together?
- Content – What will be displayed on the site?
- Informational hierarchy – How is this information organized and displayed?
- Functionality – How will this interface work?
- Behavior – How does it interact with the user? And how does it behave?
So let’s take a step further to practicing wireframes and let us answer another question – how should my wireframes look or what style of wireframing should I go for? Well, how things look is very often how things work. In this case, this intuition leads to a correct solution – how your wireframes should look is how your wireframes should work. It makes perfect sense if you think of wireframes as a language. It’s a form you of communication used to be understood. At that point sketches are as good for communication as hi-fidelity wireframes – they both communicate something. And they look how they should work – sketches can look abstract of “unfinished”, because they are usually prepared quickly to communicate some basic idea in a short time, while hi-fidelity wireframes need more preparation, because they represent details the closest to the working product at some point of time in product development process.
So instead of copying soltions that you don’t know the “why” behind, what would work for you is probably a style of wireframing you develop on your own. A good idea is to choose:
- Wireframing tools & medium: sketching, paper cut-outs, stenciling, wireframing software
- Level of detail for your wireframes: block diagrams, so called gray boxes, hi-fidelity text, hi-fidelity media, hi-fidelity interactions, etc.
… and know how to tie this all together in wireframe styles like annotated wireframes, clickthrough wireframes and so on.
50 shades of Wireframes is an article we wrote to help you through the the details of this process, so wireframes never confuse you or your team again. The only way of knowing the “good” from “bad” in the wireframing world is how your wireframes serve to communicate the ideas and progress in the product development process.