I’m at the start of a new phase of our development, and we’re at the point where we need to generate ideas for our interfaces. I’ve observed that wireframes aren’t always well-received by people who don’t understand them – clients who think they need more color, developers who want to code over it, etc. If the only resolution we have to this problem is educating the public, I think we’re in for a very long ride.
This might be because wireframes aren’t obvious enough to people.
You heard that right – if people are misunderstanding your wireframes for a finished product, or your sketches for a placeholder for a WYSIWYG dev tool like Visual Basic – there’s clearly something inappropriate about the tool’s use.
I believe some of us take wireframes for granted, such that we see no other way of implementing a product. While wireframes work well for some designers, I sometimes think they take up time and that there might be better, faster, more efficient ways to build software.
Also, wireframes aren’t great for super-dynamic AJAX-heavy interactions. And they aren’t great if you want to break out of the 2D mode, and work with more dimensions (how do wireframe a keypress, or an animation, or audio?).
I remember the first time I used tons of wireframes on a project, and ended up realizing that we wasted all that time building hi-fidelity prototypes just because I felt it was the right way to design an application. Time was wasted testing the prototype because we didn’t get THAT much insight out of it, simply because it was so blatantly obvious – we should have just tried it on ourselves before testing it on other users.
I’m probably stepping on some UX no-go zones – aren’t we supposed to test apps on real users, and not ourselves? Well, I think there are some things which are so blatantly obvious you needn’t waste the users’ time to fix or test. Testing via paper prototypes a la Carolyn Snyder isn’t always going to save you time. There are much faster ways to get it done, if you think through it a little.
I’m not advocating against wireframes. I’m just advocating against getting locked down on a specific method – against “methoditis” – you know, when you start believing that one method is better than another just because.
Basically, you might want to re-think wireframes if they:
- confuse the people you’re communicating to
- take up time when something else can be so much faster
- cut down too many trees
Here are some examples or ideas of doing without wireframes:
- http://gettingreal.37signals.com/ch11_Dont_Do_Dead_Documents.php
- http://code.new-bamboo.co.uk/polypage/ (a tool developed by Clearleft and New Bamboo)
- method-acting (see Bill Buxton’s Sketching User Experiences for an example a designer “being” the device)
- plasticine? feel free to add your own examples.
