I recently presented at a conference on the humble wireframe and thought it would be a good idea to run through some key points. I have also noted that some feel the wireframe is dead, though if anything its more alive now than ever. Pay heed to 37 signal’s take on the subject…
If a wireframe document is destined to stop and never directly become the actual design, don’t bother doing it. If the wireframe starts as a wireframe and then morphs into the actual design, go for it.
In the presentation I attempted to answer these questions;
Wireframes
- • What are they?
- • Why do we use them?
- • When should they be used?
- • What are the different types?
- • How are they used in a project life cycle?
- • Why are they important?
What are they?
 |
They are a visual representation of the content of a web page that is the culmination of user research, business objectives and content.
Best brought together in a sequence of pages to illustrate paths of navigation and interactions on the page. |
They are working documents that are not finished designs but are likely to change as the design process progresses and functional requirements are clarified.
They are NOT…
- • Meant for an external audience without an explanation of context
- • Meant to be the design of a page
- • To portray any graphic elements
- • To convey the brand of a website
Why do we use them?
| To help gain understanding They ensure the business understands that the interface is where the user interacts with their products, where engagement begins and conversations start. |
 |
To help project workflow
They allow us to focus on the functionality of a site. They are a fast and cheap way to produce an idea of how a page on a site may work. They can be developed in parallel to creative concepts, and redrawn easily.
| To help stakeholders They promote debate and conversation around important elements of a site. They are a focal point for collaboration between stakeholders in a team. To help designers and developers |
 |
When should they be used?
Jesse James Garrett very neatly summarised the five phases of website development in this model and you can read more about it here. His concise and accurate analysis of the project development phases is seen in the excellent book – The Elements of User Experience.
 |
In short, wireframes are the skeleton of a site and precede the surface design and come after the structure. However in the agile process of development a more layered approach enables developers and designers working simultaneously. Wireframes are evolving documents of discussion and this should always be remembered. |
What are the different types?
| Hand drawn sketches Are a very quick and fast way to convey a layout to others that can be changed rapidly. They are the best precursor to computer aided drawing and their low-fidelity format encourages experimentation and honest critique. |
 |
Collaborative sketches
The only real difference here is that a team produces the wireframes together. It helps the group to discuss reasoning behind solutions and iteratively sketch solutions. Several solutions helps the team explore different approaches and it provides a framework for participants to articulate their ideas.
| Annotated wireframes They are produced to describe the functional elements to development teams. Elements are explained in small paragraphs alongside the diagram and this enables the wireframe to be understood without verbal explanation. They are valuable tools to clarify function and focus on a page. |
 |
| High fidelity wireframes Mainly produced to canvas opinion from users in interviews about a layout or concept. They should always require a usability expert to explain the context and purpose of the diagram. It really is the nearest step before presenting the surface design of the solution. The line between wireframe and functional prototype is a thin one here, it may be better using resources on a working prototype. |
 |
How are they used in a project life cycle?
 |
Even in the Web 2.0 world of development with AJAX interfaces the wireframe has a place. It may struggle to show all interactive elements (though the Yahoo pattern library’s use of wireframe diagrams negates this somewhat) but it still gives a document that can digested by large specialised project teams. |
The wireframe can evolve into HTML or Flash prototypes and is a tool that encourages collaboration – this is its most important strength.
The diagram below highlights a typical journey of a wireframe through a product development cycle. It is an iterative cycle and one that moves at different rates to other tasks in the work flow of a team.
Why are they so important?
• They ensure accurate planning for functional specifications
• They ensure all project team members are well briefed
• They enable developers to start work on new functionality before the visual design begins, helping to minimise development costs
• They track changes in the design process as decisions are made to the interface, this minimizes project creep
In summary, they are critical to the success of a design. If anybody claims not to use them you should be wary of the methods they employ. A wireframe is the compass that will keep a project on course, and a journey without a map is a hazardous one.
Tags: Agile, Design Practice, Design Strategy, User Centred Design, Wireframes
June 27, 2008 at 4:43 am |
very nice summary. thx.
June 27, 2008 at 7:52 am |
Nice work James.
June 27, 2008 at 10:25 pm |
[...] wireframes son una representación esquemática de una página web. No es el diseño propiamente dicho sino la [...]
June 30, 2008 at 2:35 am |
[...] The what, when and why of wireframes – User Pathways “In the presentation I attempted to answer these questions: Wireframes – What are they? Why do we use them? When should they be used? What are the different types? How are they used in a project life cycle? Why are they important?” (tags: internet ia usability webdesign wireframes training tips) [...]
June 30, 2008 at 7:00 am |
[...] The what, when and why of wireframes A great presentation covering the purpose of wireframes, the different methods available and their place in projects. [...]
July 1, 2008 at 12:12 pm |
[...] very early in the design process. Kristina also recommends eliminating the practice of populating wireframe designs with “lorum ipsum” [...]
July 2, 2008 at 7:03 pm |
Great explanation of wireframes! I was missing something like this =)
July 11, 2008 at 1:43 am |
[...] The what, when and why of wireframes « User PathwaysIf the wireframe starts as a wireframe and then morphs into the actual design, go for it. [...]
July 11, 2008 at 8:16 pm |
Its amazing that wireframes have such an audience! I am trying to spin this out on Boxes and Arrows as a more in-depth piece. If you would like to see more try to check out the ideas area and vote on the What, When and Why of wireframes. Cheers all
July 14, 2008 at 7:47 pm |
[...] Paper Prototyping – before changes are made, work out the layout on paper and communicate with other team members, it allows honest critique and rapid iteration. It also keeps the team from being married to one solution [...]
July 16, 2008 at 5:01 am |
[...] – bookmarked by 4 members originally found by Oneblood121 on July 11, 2008 The what, when and why of wireframes http://userpathways.com/2008/06/26/the-what-when-and-why-of-wireframes/ – bookmarked by 1 members [...]
July 24, 2008 at 1:01 pm |
I love the organizational graphic. I’ll take being the frat boy IxD, and I certainly recognize the metal head database developer and headphone wearing UI developer! (and the magenta collared creative? He’s not quite out of the closet yet). Thanks!
July 24, 2008 at 1:27 pm |
Sorry for the stereotypes, but hey, we all have seen at least one in our time – surely?
August 5, 2008 at 8:19 pm |
does anyone know what typeface that is on the hi fidelity wireframe(fisher-price)- ‘MarqueSite’ in the header?
August 14, 2008 at 6:42 am |
[...] http://userpathways.com/2008/06/26/the-what-when-and-why-of-wireframes/, (viewed [...]
September 2, 2008 at 1:27 pm |
[...] what, when and why of wireframes James Kelway’s article on wireframes in the User Pathways blog summarizes what the different types are, what their purpose is, who the [...]
September 3, 2008 at 4:06 pm |
[...] The what, when and why of wireframes « User Pathways "They are a visual representation of the content of a web page that is the culmination of user research, business objectives and content. [...]
September 4, 2008 at 1:33 am |
[...] The what, when and why of wireframes « User Pathways (tags: wireframes design informationarchitecture) Filed under del.icio.us | [...]
September 4, 2008 at 7:23 am |
[...] The what, when and why of wireframes « User Pathways "They are a visual representation of the content of a web page that is the culmination of user research, business objectives and content. [...]
September 6, 2008 at 9:48 pm |
[...] http://userpathways.com/2008/06/26/the-what-when-and-why-of-wireframes/#comment-319 [...]
September 10, 2008 at 2:24 pm |
Very thorough presentation of vireframes. Nice work!
October 1, 2008 at 6:49 pm |
[...] The What & Why of Wireframes [...]
October 2, 2008 at 10:14 pm |
[...] act as a blueprint or a schematic and show only information, not design. There are a number of reasons why you should use wireframeswhen designing a website, some of them being; to help gain understanding, to help project workflow, [...]
October 11, 2008 at 2:07 pm |
[...] can help so much more than just producing wireframes. More than the bit between client liaison and project management. IAs can help define strategy [...]
October 20, 2008 at 2:16 pm |
Thanks for your article, I think it sums up nicely the benefits of wireframes.
One thing: imho you underexposed functional specifications a bit.
In your article you mention that annotated wireframes are produced to “describe the functional elements to development teams.” While this is true to a certain height, I believe that wireframes are not the tool to capture ALL functional elements.
Where I work we use a seperate document called functional design. This takes the wireframes a step further, and describes in detail how the website will work.
The main benefit of a seperate functional design is that you are forced to describe your design in depth. My experiences are that (no matter how thorough you design your wireframes) is that you come across unexpected, overlooked items etc. which did not surface in the wireframes. Also it often brings up technical issues.
A functional design can save you a lot of time, while you probably would otherwise bump into these problems in a later stage. And they might not be so easy to resolve at that time…
Second benefit is that there are no (or less) unclarities with the development team and your client.
October 20, 2008 at 6:15 pm |
I completely agree with you on these types of documents though I expect them to be produced by a Product or Project manager in my situation. Ideally an interaction designer would do this but unfortunately the workflow and a small team makes this a job that has to be moved on and checked over. They are a key part to the development process as they ensure transparency, particularly for the people who will deliver it!
Thanks for clarifying this – its made me realise that as ever we only scratch the surface with wireframes and other ways of communicating the intended product always needs stating.
However a new approach is to show states of a web page and that way the different modes of the page are shown. This sounds like it could do the same job as the functional design document but in a visual way. What do you think?
October 21, 2008 at 1:53 pm |
The question ‘who has to write the functional design’ is a question that also arises in our company from time to time. In my previous job there where special functional designers – that would be the ideal situation, but with smaller companies (or time-, planning- or budgetstretched projects) not always achievable.
Concerning states: it depends on the project. In general: I prefer that the interaction designer at least _designs_ the most important states. This is because in most cases there are a lot of interaction design decisions to be made. I would not depend on the project/productmanager/whoever writes the functional design to decide that.
You can differ in the details of how much you describe. For example: you could design the main states, and let the exceptions etc. be written out full in the functional design. This is where actual demo’s sometimes come in handy (Dreamweaver, HTML, Axure etc) to test if the solutions you have designed really work.
But, as said before, it mostly depends on the project (and time, and client, and development team, and so on). Over here we call it the search for the Holy Grail for interaction designers
November 5, 2008 at 11:20 pm |
Thanks for this article. I am lecturing part time and needed to give an overview to students. I was looking for images online when I came across this summary. I am now giving them the link instead of the document I was writing myself.
November 6, 2008 at 4:30 am |
[...] The What & Why of Wireframes [...]
November 10, 2008 at 10:48 pm |
@Anita – if there is anything you think is missing or would like more information on let me know as I am trying to get an article together for an online magazine on the subject. Thanks for the interest
December 1, 2008 at 12:04 pm |
[...] we know what we have is a concrete strategy. From here we roll out the production of the wireframes, based on the sitemap and taxonomies and other [...]
January 6, 2009 at 11:32 am |
[...] http://userpathways.com/2008/06/26/the-what-when-and-why-of-wireframes/ « 2008.12.24 Wo, Day [...]
January 15, 2009 at 7:28 am |
i like this “The what, when and why of wireframes”
January 20, 2009 at 3:53 am |
A great article that justifies the importance of the wireframe. Most times we are creating sites for clients that have no idea or little info on what the they really want or need. Documentation including functional specs etc only confuses the client to a point that they have no idea what they are getting until they get to UAT. They usually have limited time to read the documents and fully understand them. A well detailed wireframe which accompanies the functional specs are a great way to assist the client and prepare them for the final product. As you can understand after reading a 100page document a lot gets lost, but when the client sees a representation of the site in wireframe they finally get it. Long live the wireframes.
February 25, 2009 at 3:24 pm |
This is a great summary. Thanks a lot for your article !
March 12, 2009 at 7:48 pm |
Thanks for the comments. The wireframe is due to become even more critical as Flash catalyst takes it into an entirely new, useful domain. The wireframe is about to become a real conversational tool and not the conversational hurdle we know it can be. Hope to blog about it soon…
March 18, 2009 at 7:45 pm |
[...] The what, when and why of wireframes [...]
April 27, 2009 at 10:34 pm |
[...] The what, when and why of wireframes [...]
June 24, 2009 at 6:54 pm |
[...] http://userpathways.com/2008/06/26/the-what-when-and-why-of-wireframes/ [...]
June 29, 2009 at 10:12 am |
[...] http://userpathways.com/2008/06/26/the-what-when-and-why-of-wireframes/ [...]