Let’s start this year’s articles with a subject I am very fond of: Wireframing
I personally have always found the wireframing process to be so useful for the project development that I virtually can’t live without it. But is it just me and my working habits?
Lately I’ve been reading a lot of very good rapid-prototyping related articles, but I’ve also read very good articles that explain why the wireframing process is important for communication and understanding. So what, then, should we do?
My conclusion is simple: What suits you best? I think our time schedules are a very determining factor. We can also consider the amount of people available and the load of work each of them has to deal with. Is it possible to stop and work on wireframes?
Then maybe we just need to be a little less perfectionist and take it down a nodge in what comes to working on wireframe details. There’s already an article that explains this consideration, but let’s take it a little further and talk about the pros and cons.
To begin, here’s a definition I really liked about what a wireframe represents:
“Wireframes typically outline the components for a screen, together with any associated behaviours, such as what happens when a button is click and where a hyperlink should go. They don’t show exactly how a screen will appear, only how it will be composed and how it will behave.” — Neil Turner
Let us review a list of reasons of why wireframing should be maintained as a crucial part of our project development process:
Improvement of the communication with clients
It is always better to show your clients what you’re talking about BEFORE they have to see it implemented. There’ll always be need for changes once you do this, and you definitely save time if those changes are discovered through a well-detailed wireframe instead of a half-way through development product.
Improvement of the internal team communication
Wireframes also help unify the creative process of the team throughout the project. What is it that you’re suggesting? A picture is worth a thousand words. And a descriptive and clear one is worth thousands more.
You can even work on wireframes with the use of team dynamics like the one proposed through this very interesting article about paper wireframing.
Physical history of changes throughout the project
We always end up with tons of different versions before we finally decide on the definitive one, and it is useful that we keep track of all of them. Why? Because, between versions, need for elements and components can change. What seemed like a very bad idea in one version, could actually be an enhancement of a later version. Being able to visualize them all, therefore, brings value to our working process.
Better visualization of design ideas and concepts
Setting aside the fact that we need to communicate our ideas with other people, sometimes it’s even necessary to make ourselves visualize those ideas in order to make sure they are actually good ideas. Sometimes, the way something looks inside our heads is nothing like the way it actually looks.
In other words, I need to see it.
Need more reasons to love wireframing? Andrew Maier mentions the utility of wireframes when designing interaction as part of his Complete Beginner’s Guide to Interaction Design at UXBooth.
Not to Wireframe
And now, what are the reasons that rapid-prototyping is giving us to kill wireframes in our design process? You can read the article on rapid-prototyping that I’m considering while I write this.
Prototyping isn’t the same as wireframing
Wireframes, contrary to what many people think, are not dynamic. Prototypes are dynamic and, therefore, better suited to portray the interactions withing the pages of a website. For this reason, a prototype needs less explaining and, therefore, less documentation.
Also, the word “prototype” is a lot more familiar to everyone than the word “wireframe”.
Wireframes aren’t very user friendly
Apart from being unfamiliar to stakeholders, they are also perceived as something of a highly technical nature, and tend to be intimidating because of this.
Wireframes tend to be too subjective
Because of their static nature, wireframes don’t offer the solidity of prototypes. They are too open to interpretation and confusion. They depend too much on the verbal or written descriptions provided by the designers, and the original idea is in danger of being misunderstood.
The documentation load tends to increase way too much
Since they require explanations in addition to the visual representation of the ideas, these explanations end up being included in added pages of the final documentation.
In the end, it’s really all about what you find more appropriate for your team, isn’t it? I work in a small company, so confusions are really scarce once a wireframe has been issued.
What’s your personal experience?