Wireframes are one of the main tools in the user experience designer’s toolkit. Most usability and web design books devote a considerable section to sketching, paper prototyping, and other forms of planning. But while I agree wireframes can have their place in some projects, I think they are actually detrimental in a lot of cases.
A new environment
In recent years, a few factors have started shaping the world of web design and development in a new direction. I’m talking about things like:
- The emergence of frameworks like Rails or jQuery, and services like Heroku or EC2, who all contribute to minimizing development time.
- The success of 37Signals and other bootstrapped companies which show that you can be successful with limited resources.
- The lean startup movement and the notion of minimum viable product.
All of these things have come together to create an environment where web products are quicker to develop, focus on fewer features, and are flexible enough to adapt to a changing market.
The downsides of wireframes
I’m increasingly unsure that traditional wireframes have their place in this new landscape. It’s a basic truth of the design process that the more time you spend working on something, the more attached to it you get. So if you spend hours on a Photoshop mockup, you’ll probably hesitate to discard it even if it becomes apparent that your design doesn’t work in the browser.
A wireframe’s rigid boxes and simple aesthetic can provide comfort compared to the web’s chaos. So even though we should all know better, it’s easy to get attached to a wireframe. You might not think this is a problem. After all, we often hear things like “a good prototype is 50% of the work”. But think about it, this means that you’re restricting your options at the earliest stage possible, before your product has even been used by a single customer!
What’s more, obsessing over wireframes can eat up valuable time, without much to show for it. You can’t even be sure that the solution you found is really better than any other. Wireframes are usually not interactive, and unlike Photoshop mockups they don’t show you contrast or hierarchy, color or typography. It’s easy to find a solution that “works” when most of the problems aren’t addressed at all.
The right way
So what are you supposed to do? In many cases, wireframes are used to kick off a project because they’re relatively fast to create. But many designers work just as fast in Photoshop, and good coders can whip out a html/javascript prototype in a couple of hours. So first, you should ask yourself if you need to use static wireframes at all.
If you do use them, make sure everybody understand that each step of the process exists to support the next one, not dictate what it should be. The wireframe should remain a tool that helps with the creation of a higher fidelity mockup or html prototype, not a perfect blueprint for it. This means that no part of the wireframe should be off limits when it comes to changes (and this is also why I don’t raise a stink if a client’s finished product doesn’t look exactly like my Photoshop mockups).
Beyond wireframes
If you want to go beyond wireframes, there are alternatives. For example, a simple list of a page’s element can be a surprisingly effective way to guide a designer without influencing him, and keeps the focus purely on the content.
But in my opinion, the ultimate replacement for a wireframe is simply the site itself. This might come as heresy, especially on a design blog, but I actually advocate for development before design whenever possible.
Why force a designer to work from uninspiring and ugly (there, I said it!) Balsamiq mockups when you could simply give him access to your test server and let him try out your prototype by himself? Don’t be ashamed of your site’s bare looks. After all, if you’re not ashamed of your first version, you’ve waited too long.
So here’s my takeaway on wireframes:
- They can be a useful tool for people who can’t design and can’t code.
- Getting attached to them is a surefire recipe for wasted time and energy.
- Wireframes are guidelines, not blueprints.
- Ask yourself if your time wouldn’t be put to better use actually coding or designing.
How about you, do you use wireframes? Have you ever encountered some of the problems I talked about?
Update
I just had to quote this answer by Russel Jurney to the question “Is it important to create wireframes before building your webapp? Why?” on Quora:
Absolutely not! HTML is a wireframe. Your prototype is your spec, and can be improved and iterated to become the final product. Spend that wireframe time iterating against analysis of real use of your prototype and you will build better stuff.
I couldn’t have said it better myself. The fact that this is currently the most up-voted answer gives me hope!
Elsewhere
There are a couple good threads going on about this post around the Internet:


Pingback: Tweets that mention Why wireframes can hurt your project | Attack Of Design -- Topsy.com
Pingback: A simpler and faster alternative to wireframes | Attack Of Design
Pingback: Sacha Grief – Freelance Designer from Paris | Interviews | Web Courses Bangkok
Pingback: In defence of wireframes « Cookie Dough
Pingback: The Great Wireframe Debate | Attack Of Design
Pingback: Fábio Caparica » del.icio.us entre 05.02.2011 e 02.03.2011
Pingback: plain mag » Archive » UI & UX + Wireframes
Pingback: Wireframes – Worth Their Weight In Gold | Domain Slasher (www.domainslasher.com)
Pingback: Litteraturliste | cmyk101
Pingback: What’s wireframes, precious? « Todd Soligo
Pingback: Website Wireframes: Necessary or Nuisance « webelwriter
Pingback: User Experience Link Roundup | crackedhorizon