Blog : Wireframes: High Fidelity vs. Low Fidelity

Wireframes are a commonly used deliverable in the web design process. In general, they help designers communicate intentions for a site to clients and developers. Arguably, they're invaluable and shouldn't be skipped, especially for larger and/or complex projects.

There seems to be a general disagreement in the web design community, however, about whether wireframes should be low fidelity or high fidelity.

Low fidelity wireframes – like this one – keep things minimal. Their goal is generally to focus on layout and maybe feature sets such as navigation, but not on details such as interactions.

High fidelity wireframes show more detail, like this one. Sometimes a lot of detail. These types of wireframes define visual hierarchy, interactive elements, images and icons, and sometimes, real or close-to-finished copy.

This disagreement surrounding low and high fidelity wireframes tends to center on one question: Which is better?

So here's the answer: it depends. Yep. It depends. Sorry to burst your bubble.

It doesn't mean any part of your web design process is broken if you use one or the other, despite what some people believe. What it does mean is that many designers are aware of their client's needs and what makes the most sense for a given project. To me, that is what's key – not if one method is better than the other. (And I truly get a little disgusted by designers that disparage other designers for not using their chosen method.)

Not all projects are created equal. There will be instances when low fidelity makes more sense than high fidelity and vice versa. You, as the design professional, need to know when one is more appropriate than the other. Hell, if you swear by one, great! Use it, stick to it, but don't assume it's the only way.

I'll admit, I have a soft spot for high fidelity wireframes. I enjoy looking at them and I've created my fair share. But I can't help but feel that they can be too much at times. While I'll agree that the client can more easily visualize what's being built, statements like this scare me:

It takes the burden our of having our UI designers make decisions and allows them to react to what they see.

If UI designers aren't making decisions, what the hell are they doing?

I don't know about other designers, but as a designer, I'd rather make decisions than simply color between the lines. And I think that's the problem that some designers see with high fidelity wireframes.

For us here at Block 81, wireframes help us and our clients focus primarily on one thing: content hierarchy. (Notice I didn't say just content.)

In our web design process, not one single pixel gets pushed until we have content in close to final form. Why? Because content is why people are going to websites. Few people are going to websites just to check out that sweet design of yours. Sorry to burst your bubble (again). In my view, this is why content is king. Design elevates content so that it gets us interested, is easier to read, easier to scan, easier to digest, and gets our clients paid.

We help our clients figure out how to organize their content – whether they are writing it or our copywriter is – by creating a content hierarchy document. That document outlines the content for every major page (or page type), complete with ideal word counts and importance (high, medium, low). And that is what we base our wireframes on.

We generally create what we call blueprint wireframes. Of course, we aren't the first to do this. In fact, we were inspired by Derek Clark. In our wireframes, we have callouts for each major element and use the BLOKK font for copy. Using BLOKK for the content ensures that the focus for us and our client is on the overall hierarchy and layout of each page – keeping important elements are more prominent. This type of wireframe leads to great discussions regarding elements that may have been glossed over in earlier discussions or discussions surrounding what-if scenarios. That kind of input – from the client especially – is priceless and only makes our work better. This works for us. Very well, in fact. But it doesn't mean it's the right way for every designer.

So what's my point? It's this: wireframes are a tool and while you certainly need to know how to use this tool (or any tool in the web design process for that matter), just because you prefer one over the other doesn't mean it's the right answer for every client, every project, or every designer. Like with most things, use what works for you, your process, and most importantly, your clients. But please, for the love of all things good, don't go around scoffing at other designers because they choose something different.