Welcome back to part 2 of the trilogy about Sketches, Wireframes and Prototypes

This time I will be talking about wireframing and different points of view about its role in designing the UX.
Wireframes are to websites and software what blue prints are for houses.
The building of a interface has to be divided into the interface and the design. Here, by design I am referring to color scheme, fonts, images and other attributes.
Dan Brown in his book “Communicating Design” indicates that wireframes focus on:
  • The kinds of information displayed
  • The range of functions available
  • The relative priorities of the information and functions
  • The rules for displaying certain kinds of information
  • The effect of different scenarios on the display
Wireframes lack realism, they are not interactive. Instead, they are a way to present how the content will be organized and their relative priority, not what the content will be or how the user will interact with the solution.


It is really important to make the distinction to both visual designers and clients of what the wireframe is and is not.
Adding colors, fonts, or any graphic element could create a distraction from the real purpose of the wireframe. They will add emotional elements that could harm the process. At this part of it, what is important is how the information is structured and organized, not how it looks.


Here is good point made by the good fellows at onextrapixel about wireframe, visual designers and clients:


Note for visual designers
At this point in the process, visual designers should conduct exploratory meetings to understand the client’s visual preferences and the visual elements of the client’s brand. Wait until wireframes are set before showing any visual-design treatments of the pages to the client.


Note for clients
For clients who insist on seeing visuals earlier rather than later, ask visual designers to design page mock-ups representing possible colours, imagery, its look and feel, as well as possible styles of what is being considered at this stage. However, you should do this only if absolutely necessary – that is, if they won’t take no for an answer – and be sure to emphasize that these mock-ups, in no way, reflects the final designs (repeat this warning early and often).


Wire-framing is not prototyping
While wireframes can be set to look as an interactive system, they are not. They are a good help to describe how users will relate to the product, but to know how the product will work there is a need for a prototype.


The importance of wire framing
The guys at Zurb present us with their reasons why wireframes are important. The article could be resumed on the following points:
Order out of chaos
At the beginning of the designing process (the Define Phase) there are many ideas floating around. Wireframing will put all these ideas together in a logic way helping to get rid of the ones that are not relevant or necessary.
It is not about putting in as many features as possible, but to leave only the important ones.
It translates the ideas into something tangible. Helps getting the ideas through to the design team and everyone involved.
One step at the time 
The goal of the wireframes is to “outline the structure and elements that go on the page”. No color, no typography. Only structure and content.


Adam Little from 45 Royale gives us other reasons why Wireframing is important:
Role of Information Architecture
It is easy to make adjustments at this stage of the design process. It helps to spot potential usability problems
Help client to focus
Avoid the distractions of the visual treatment. A wireframe will facilitate the feedback on the sizing, layout and placement.
Teach us about the client
One great thing, says the author, is that wireframes help us getting to know the clients. Their likes and dislikes. He recommend to watch for feedback patterns.
Save time
Wireframes help to spot potential problems. Doing revisions at this stage is faster, easier and cheaper than doing them with an almost finished product.


Wireframes are a necessary step in the development process. From all the ideas and concepts that comes out from a brainstorming, and all those doodles and sketches during the sketching part, on the wireframes one should collect the best of the best and what works best!


Having not presentation involved, and using only basic figures to avoid “design cross-contamination” means that the design part (color, fonts…) will be left for a later stage, once things are in place.


But…. (I guess the conclusion was a little ahead of time)


Not everyone thinks wireframes are the best way to communicate how things will be organized and how they will work.


Matt Conway, from Simple Contraction tells us why “Wireframes Must Die”.
He makes reference to Andy Rutledge by highlighting the following problems:
  • Wireframe often don’t express what we want: motion, emotion, sound, transitions.
  • Often express things we don’t want: Typography, placement, copy.
  • Are confusing for clients: Separation of visual and interaction design
  • Interactive prototypes are a better way to express design intent.
To these points, Matt Conway adds:
  • There is no way to describe relationship between things
  • Can be difficult for clients to read and understand
  • They don’t age gracefully. The final product could be different from the wireframe
There are other points, but it will be redundant to write them down here. The article is worth reading, so I encourage everyone to take a look at it.


The role of sketching is still important. Using static wireframes  as an internal communication tool on the design process is still important. What it is not important is to show them to the client, they are a help for the designers.
His solution: To create, or promote other ways to use wireframes using some sort of modeling tool for UX (more like drawing, less programming).
This tool should allow us to make progressive refinements and not re-do what has been done.
This model, unlike rapid prototyping, should aloud the designers to add notes. Or video-notes, voice overs, text or links to other assets or pictures.
He talks about how this model should be and what it should do.
The main takeaway is that we need to re-think what wireframes are, their role and how they impact the design process and the involvement of the different stakeholders in a project.


It is now enough with static wireframes
In another article, from the same guys at Zurb, they give us another point of view: Traditional wireframes are dead.
There is a need for responsive wireframes that will change depending the device with complex layouts.
Wireframing for different platforms is more relevant now with all the options we have, and translating the ideas from one to the other should be done from the beginning of the design process. A wireframe should adapt to the medium, and not being a time consuming process.


There are many different solutions to create wireframes (both static and dynamic). The one that I used is Omnigraffle. This is, or so I read somewhere, the equivalent of Visio for mac. I don’t have a PC, and never worked with one (except for some photo related applications), so can’t really do a comparison.
What I like about Omnigraffle, besides the really clean interface and the many stencils that are available to download, is the possibility to create simple slideshows and turn the static wireframes into presentations to demonstrate how the user experience has been predicted (I don’t dare to write design yet, because a prototype will be more appropriate to do that).


On the iPad I am using  UI Sketcher and LovelyCharts. Another application that one could use is UIConcept. Again, all these applications have different strengths. What I like of UISketcher is he ability to create quick wireframes for iPhone and iPad. It is, as the name implies, a sketching application, but if one spends some time on it, it can be used for good static wireframes.


I hope as always that all this rambling about wireframes and the different opinions and ideas presented here serve of inspiration to whoever reads this blog.


Next week I will talk about prototyping.
Stay tuned!


Lucas Wxyz

Leave a Reply

Your email address will not be published. Required fields are marked *

− two = 1

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>