I do not know whether you know it, you can frequently find and read articles how to draw wireframes, hints about software tools to draw wireframes, but articles about the “why” are rarely to find.
I can’t count the number of wireframes I have drawn. And throughout various projects I saw pros and cons – sometimes again and again the same and from time to time new one.
Don’t get me wrong – I believe in the force of wireframes - I like wireframes and they are a powerful communication technique – but as much as I like, use and recommend them in the same way I am skeptical and unconvinced – in these moment I feel “A tremor in the Force”
The main problem is that “average” people don’t understand wireframes – why is that so?
The answer is short and easy – These people can’t read the drawing.
Already in my early years as architect and town-planer I had to realize and to except that third parties are not as familiar in reading and understanding of drawings as professionals are.
As architect I became conscious that even ground plans with measurements and furniture have been unable to give the “average” person a sense, feeling and or understanding of proportions and design. They are not as familiar in interpretation of drawings as we are. I deliberately used the expression familiar and not the word literate – because it has nothing to do with high education or knowledge but it has something to do with experience and thus guide us consequently to helpful instructions and support and furthermore user centered deliverables.
Drawings and sketches with its lines, frames, elements and symbols are just like each other language with its characters and letters.
This takes us back to the principles of the UX - the faculty of speech and communication depends on the experience of the individual.
But unfortunately we have had to recognize that the developer, for example IA “speaks” their own language.
What does that mean for us and to develop wireframes? Should we stop drawing wireframes?
Unequivocal - NO !
Hence it is of utmost importance to examine and pay attention very acutely to be able to identify the real bones of contention, communication and understanding, in turn to be able to intervene in a helpful and constructive manner to deal with and, if possible, to solve the conflict of smooth and hassle free communication.
We are always asking and being asked: what are the deliverables. Throughout my career as an IA, UX-planner and designer, as well as during my study of architecture and town planning, I have constantly asked myself following the questions:
The deliverables are not for us. The deliverables are a means of communication with several people: manager, decision maker, client, designer, front-end developers, back-end developers, etc. Sometimes I have the feeling we overlook this from time to time. After I think about the project I have to ask myself, where will my deliverables and other efforts fit within the process of design?
Wireframes are very useful and maybe one of the best deliverable for a project-internal and team-internal purposes especially within information architects, interaction designer and each team member who deals with planning and concept in detail. But already within the next level of colleagues we have to anticipate first problems regrettably – all too often I discovered and recognized more or less important and serious problems when visual designers or project managers try to read wireframes. And step by step within the further decision-making levels we have to expect further and more serious and problematic problems.
I still know a few agencies and designers work without wireframes either because they do an equivalent and related deliverable like page description diagram or by a text-document or they design directly a visual design.
Before I draw wireframes I often start to sketch similar and analogue drawings = Function sketches.
A function sketch helps me organize and simplify the elements and content within a website and is an essential tool in the development process- but in contrast to function sketches wireframes depend to some extent on a design and layout grid.
In opposite to a function sketch a wireframe is principally a visual representation of a layout but it shouldn’t represent the design.
The wireframe acts as a model and prototype that give you an idea about the placement of page features, such as header, footer, content, sidebars, and navigation.
A wireframe is a general outline for understanding the different high level components that go into making an interface - The successful creation and invention of digital products requires the appropriate blend of analyzing, planning and design of different components, characteristic and aspects …
Components like …
… Information
… Interaction
… Look and feel
Characteristic like …
… Structure
… Appearance
… Staging
… Activities
Aspects like …
… Content
… Aesthetic
… Behavior
These different components, characteristic and aspects influence and affect your interface in every detail and also in general. But each of the former enumerations mentioned one point which is hardly, almost not or just to a certain extent to meet by wireframes.
… Look and feel
… Appearance
… Aesthetic
The more the essential and main quality of your project is constituted by these facets you should prove whether wireframes are the best deliverable for your project.
This means that we have to be able to respond flexibly to project requirements and aims.
I should add, that wireframes are more than boxes and arrows and that this should not lead to a superficial documentation, but that it is very important to do more than scratch the “surface” and, particularly, to give team members a role in their specific fields.
If you ask me whether wireframes are good tools, I would answer, YES wireframes are powerful, effective and adaptable. But if you ask me “Are wireframes good for you and your project?” - My answer would be as so often – “It depends on!”
You should evaluate the use and utility of wireframes before you come to the decision whether or not to create wireframes and its quantity and quality / level of details. You should do this for the internal (designer, developer and project management) and external (decision makers, clients, etc.) use an purpose.
No matter whether you use to draw fast-scribbled sketches on napkins, notebook paper (http://www.uistencils.com/browser-sketch-pad.html ), detailed ink drawing with stencils (http://www.uistencils.com/iphone-stencil-kit.html - http://www.uistencils.com/website-stencil-kit.html ) on graph paper, lineart or greybox drawings or highly detailed illustrations with software or web applications (http://articles.sitepoint.com/article/tools-prototyping-wireframing ) you have to take into account who is your addressee and what is his experience and knowhow, what is your aim, what is the phase (early steps, etc.) and character ( new invention, improvement, etc.) of your project .
The function and purpose of wireframes and every other deliverable is no secret or shouldn’t be a secret. But again and again I have to recognize that a lot of agencies and colleagues act, develop and do what they do just because they did it already several times before.
As IAs, UX planner and UEs we have to develop several deliverables. These deliverables should give your team members, clients and decider an opportunity to take a look at the organization of single page and features but also of the whole website and allows them to make review, adjustments and corrections without problems before visual designer and or other developer waste time and efforts.
They can inspire the designer, resulting in a more fluid creative process and they should give the developer a clear picture of the elements they will need to code.
And by the way … May the Force be with you !
Update information:
Dec. 2012 - Article about diagram software / wireframing software / prototyping software
http://ux4dotcom.blogspot.de/2010/12/prototyping-and-wireframing-its-your.html
I can’t count the number of wireframes I have drawn. And throughout various projects I saw pros and cons – sometimes again and again the same and from time to time new one.
Don’t get me wrong – I believe in the force of wireframes - I like wireframes and they are a powerful communication technique – but as much as I like, use and recommend them in the same way I am skeptical and unconvinced – in these moment I feel “A tremor in the Force”
The main problem is that “average” people don’t understand wireframes – why is that so?
The answer is short and easy – These people can’t read the drawing.
Already in my early years as architect and town-planer I had to realize and to except that third parties are not as familiar in reading and understanding of drawings as professionals are.
As architect I became conscious that even ground plans with measurements and furniture have been unable to give the “average” person a sense, feeling and or understanding of proportions and design. They are not as familiar in interpretation of drawings as we are. I deliberately used the expression familiar and not the word literate – because it has nothing to do with high education or knowledge but it has something to do with experience and thus guide us consequently to helpful instructions and support and furthermore user centered deliverables.
Drawings and sketches with its lines, frames, elements and symbols are just like each other language with its characters and letters.
This takes us back to the principles of the UX - the faculty of speech and communication depends on the experience of the individual.
But unfortunately we have had to recognize that the developer, for example IA “speaks” their own language.
What does that mean for us and to develop wireframes? Should we stop drawing wireframes?
Unequivocal - NO !
Hence it is of utmost importance to examine and pay attention very acutely to be able to identify the real bones of contention, communication and understanding, in turn to be able to intervene in a helpful and constructive manner to deal with and, if possible, to solve the conflict of smooth and hassle free communication.
We are always asking and being asked: what are the deliverables. Throughout my career as an IA, UX-planner and designer, as well as during my study of architecture and town planning, I have constantly asked myself following the questions:
- What kind of project is it? What are the key points?
- What should our steps and milestones be in the project?
- What should our/my deliverables be?
- How can we/I explain the main idea?
The deliverables are not for us. The deliverables are a means of communication with several people: manager, decision maker, client, designer, front-end developers, back-end developers, etc. Sometimes I have the feeling we overlook this from time to time. After I think about the project I have to ask myself, where will my deliverables and other efforts fit within the process of design?
Wireframes are very useful and maybe one of the best deliverable for a project-internal and team-internal purposes especially within information architects, interaction designer and each team member who deals with planning and concept in detail. But already within the next level of colleagues we have to anticipate first problems regrettably – all too often I discovered and recognized more or less important and serious problems when visual designers or project managers try to read wireframes. And step by step within the further decision-making levels we have to expect further and more serious and problematic problems.
I still know a few agencies and designers work without wireframes either because they do an equivalent and related deliverable like page description diagram or by a text-document or they design directly a visual design.
Before I draw wireframes I often start to sketch similar and analogue drawings = Function sketches.
A function sketch helps me organize and simplify the elements and content within a website and is an essential tool in the development process- but in contrast to function sketches wireframes depend to some extent on a design and layout grid.
In opposite to a function sketch a wireframe is principally a visual representation of a layout but it shouldn’t represent the design.
The wireframe acts as a model and prototype that give you an idea about the placement of page features, such as header, footer, content, sidebars, and navigation.
A wireframe is a general outline for understanding the different high level components that go into making an interface - The successful creation and invention of digital products requires the appropriate blend of analyzing, planning and design of different components, characteristic and aspects …
Components like …
… Information
… Interaction
… Look and feel
Characteristic like …
… Structure
… Appearance
… Staging
… Activities
Aspects like …
… Content
… Aesthetic
… Behavior
These different components, characteristic and aspects influence and affect your interface in every detail and also in general. But each of the former enumerations mentioned one point which is hardly, almost not or just to a certain extent to meet by wireframes.
… Look and feel
… Appearance
… Aesthetic
The more the essential and main quality of your project is constituted by these facets you should prove whether wireframes are the best deliverable for your project.
This means that we have to be able to respond flexibly to project requirements and aims.
I should add, that wireframes are more than boxes and arrows and that this should not lead to a superficial documentation, but that it is very important to do more than scratch the “surface” and, particularly, to give team members a role in their specific fields.
If you ask me whether wireframes are good tools, I would answer, YES wireframes are powerful, effective and adaptable. But if you ask me “Are wireframes good for you and your project?” - My answer would be as so often – “It depends on!”
You should evaluate the use and utility of wireframes before you come to the decision whether or not to create wireframes and its quantity and quality / level of details. You should do this for the internal (designer, developer and project management) and external (decision makers, clients, etc.) use an purpose.
No matter whether you use to draw fast-scribbled sketches on napkins, notebook paper (http://www.uistencils.com/browser-sketch-pad.html ), detailed ink drawing with stencils (http://www.uistencils.com/iphone-stencil-kit.html - http://www.uistencils.com/website-stencil-kit.html ) on graph paper, lineart or greybox drawings or highly detailed illustrations with software or web applications (http://articles.sitepoint.com/article/tools-prototyping-wireframing ) you have to take into account who is your addressee and what is his experience and knowhow, what is your aim, what is the phase (early steps, etc.) and character ( new invention, improvement, etc.) of your project .
The function and purpose of wireframes and every other deliverable is no secret or shouldn’t be a secret. But again and again I have to recognize that a lot of agencies and colleagues act, develop and do what they do just because they did it already several times before.
As IAs, UX planner and UEs we have to develop several deliverables. These deliverables should give your team members, clients and decider an opportunity to take a look at the organization of single page and features but also of the whole website and allows them to make review, adjustments and corrections without problems before visual designer and or other developer waste time and efforts.
They can inspire the designer, resulting in a more fluid creative process and they should give the developer a clear picture of the elements they will need to code.
And by the way … May the Force be with you !
Update information:
Dec. 2012 - Article about diagram software / wireframing software / prototyping software
http://ux4dotcom.blogspot.de/2010/12/prototyping-and-wireframing-its-your.html
You make a good point that does already apply to information documentation in general. The format has to be in a way that your audience is able to understand it. Whether that may be a presentation, a wireframe, or a ground floor. However, as I mentionend in my article http://www.designitsimple.de/2010/01/not-so-much-is-wrong-with-wireframes/ it is also a deliverable to talk about the what and not only how.
ReplyDeleteFortunately we do have other means to show our work to stakeholders, etc. such as designs or prototypes.