Design & UX

Did we butcher wireframes?


Adriaan Fenwick

Adriaan Fenwick

I speak human. Helping man and machine get better acquainted through methods and principles of design. Designer @ Atlassian and aspiring mountain goat. Views & opinions on here are my own.


New era for design tools 15th July, 2015

Design Quotes As Principles (Part 3) 18th June, 2015


Did we butcher wireframes?

Posted on .


Wireframes are dead…or should be as we’ve lost the reason for creating them in the first place…and it’s our own fault. (I’m specifically referring to static low-fidelity wireframes). It’s not because wireframes are bad, it’s that we’ve butchered them into something that tries to achieve the same thing that a high-fidelity wireframe does (Photoshop look and feel design).

Far too often I’ve seen designers (myself included) spend countless hours tweaking wireframes meeting after meeting until the business/client is satisfied with the perfect version of the wireframe – and this is a really bad idea.

Butchered wireframes

A wireframe should never be a finished design. It should be treated as an iteration in the right direction of the UI structure and layout; something that can be understood and agreed upon by stakeholders; something that can be validated with users early in the process; something that can communicate with teams about the possibilities between code and design.

You’ll see that a lot of wireframing tools (like Balsamiq) mimic a sketched effect. This is particularly useful when having conversations with business/clients, not users (I’ll get to that later), to focus on the design and keeps you from debating font choices or colours.

However, I have found myself in situations where the debate turned into content changes, pushing pixels (moving boxes a few pixels to the left/right) or ever so slightly different versions of the same screen and if you work with many files becomes a maintenance nightmare when you have to tweak all the screens to be pixel perfect.

In the article Wireframes: A Good Comminication Tool, a Poor Design Tool, Dan Ritzenthaler talks about why a wireframe is a poor design tool:

Let’s be honest: wireframes are a lousy design tool. To get the most accurate understanding of how a customer will interact with an interface you need two things: (1) Believably real interfaces, and (2) Customers. Wireframes are usually too simple to be percieved as believable interfaces.

If you do find yourself pushing wireframe pixels this early in the design process you should consider switching to final look and feel designs (which is a really bad idea, but at least it will be more productive).

Wireframe iterations should be quick and mainly driven by user feedback to test early thinking to get us moving onto the final design – and although we spend a lot of energy educating the business/client on the lifecycle of wireframes – it somehow gets lost along the way and we end up in such a wasted cycle.

In his article, Tony Santos defends wireframes by highlighting one of the key purposes of why they exist:

Wireframes are to UIs as storyboards are the feature films, they’re the road map. They tell you roughly how things are going to play out and what’s supposed to be happening.

Another problem I’ve seen with wireframes, once they have been signed off by business/client, is usability testing. It’s easy to get caught in the moment and forget that when you are testing your wireframes with real users that you are looking for fundamental big problems in the UI as well as testing to see if the solution can solve their problem.

Testing wireframes WILL NOT identify usability issues in the smaller details (and equally important) – and WILL NOT make a great user experience. This is a small step in the right direction to get you to the next phase.

Once you’ve identified and fixed the major problems with your wireframes it is time to go into prototyping or final design where you can address those issues.


After considering all of this, wireframes aren’t really bad and they needn’t be dead if you make use of them in a productive way that will help you deliver better products quicker.

However –
My recommendation is to start with prototyping as many of the current prototyping tools (such as Axure) allow the same quick iteration in the early stages that can directly be taken into fully interactive high-fidelity prototypes – sometimes skipping final look and feel design completely. (I’ll talk more about prototyping in the future).

Take caution when you do decide to prototype as Neil Turner pointed out in his famous article Wireframes are dead, long live rapid prototyping:

Of course like wireframes, prototypes can also be misused. A classic mistake is to mock-up a design to the nth degree and then chuck this over the fence for the development team to build. Prototypes can also be even more prescriptive than wireframes, so it’s just as easy for visual designers to get upset because they feel left out of the loop.

I will leave you with the thoughts of Cristian Pascu where he writes about the top 10 reasons you do wireframes the wrong way.

Too much time spent on wireframes
Too many (similar) screen mockups
Too many possible future features
Too many details, too low, too deep
Too much talk
You don’t think it through
Too few people involved
Too little, too early
Too few explanations
Throwing the wireframes into the wild

Further reading on wireframes (dead or alive)

Wireframes: A Good Communication Tool, a Poor Design Tool
The Right Fidelity for the Job
Wireframes are dead, long live rapid prototyping
Quora: Is wireframing dead?
Wireframes are Dead, Long Live Wireframes
Getting back into the (right) deliverables business
Top 10 reasons you do wireframes the wrong way
The wireframe is not dead, dying, or even ill

Photo credits:

I created the introductory image by using the following Flickr commons photos:

Wooden texture
Blood splatter

Adriaan Fenwick

Adriaan Fenwick

I speak human. Helping man and machine get better acquainted through methods and principles of design. Designer @ Atlassian and aspiring mountain goat. Views & opinions on here are my own.