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
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).
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?
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!
There are a couple good threads going on about this post around the Internet: