20 Steps to Better Wireframing

Possibly the biggest mistake in any development project is failure to plan. Recently, the owner of a prospective start-up told me that planning was unnecessary and a good developer could just start coding. This, I promise you, will end in tears.

Wireframing is one of the first steps in your planning process and arguably it’s one of the most important ones. This is when the idea starts to take shape as an application, becoming boxes and buttons that users will interact with. This article will take you through a wireframing process; who should be involved, the tools to use and tips to enable you to make better wireframes.

1) Be Clear About Your Objective
As a developer I can understand the temptation to jump in and start coding. Often the initial idea seems so simple that surely you could just sit down and bash it out? Unfortunately, projects are rarely simple and anyone with experience will know what a myriad of unforeseen issues and challenges await you if you go down this route.

A wireframe will help you identify many of these issues in a way that is time and cost effective. It is far easier to make changes to a collection of paper screens than after you have written a thousand lines of code.

The process also helps to create a better understanding of the application. Putting it down on paper raises questions and ideas and leads to changes.

The final output will be a blueprint from which designers, developers, architects and project managers will work and makes sure everyone is in sync.

2) Make it Functional, Not Pretty
There are variations in how wireframes are presented and this is reflected in the various tools available. Fundamentally it is about the functional parts of an application, e.g. that a page will have 3 text boxes and 2 buttons. It’s about function not form.

At Howard Baines we take an austere approach to this and our wireframes include nothing but the functional elements (boxes, buttons, dropdowns etc). We ignore anything that could be seen as design or layout. Others may go a little further and include layout and other visual elements. Whatever works for you.

3) Draw on Your Experience
You do not need skills in design or development. All anyone needs is experience in using web apps or websites. Of course the more experience the better but you don’t need to understand relational databases to wireframe.

4) Decide Who’s in Charge?
Make sure someone owns the wireframe process. They are responsible for keeping it up to date and managing feedback, changes etc. In the case of a start-up this is often the founders, the ones with the idea and vision who understand the end goal. In the case of our clients we often take on this role. It doesn’t matter who it is so long as ‘someone’ is in charge.

5) Involve Everyone
Maybe not at the first meeting, that should focus on simply getting the idea on paper and involve the key stakeholders whose idea it is. Fewer, people involved makes this process quicker. As the wireframe develops involve other members of your team and your client’s team. For example, if you are integrating your app or site with existing databases then make sure the DB owner can check that all the data fields exist in their database before you add them to your wireframe. Collecting a user’s fax number is no good if there is nowhere to store it. Equally designers have a good understanding of user experience and can spot potential problems in the flow early on.

6) Set a Deadline for Completing the Wireframe
It is important to set aside predefined periods of time and deadlines for deliverables to keep a project moving. The initial wireframing session could be one day or several depending on the size of the application. But set a period and stick to it. Follow up review meetings can be much shorter or even done remotely.

7) Keep it clean
If a particular page requires two text boxes and a button then it should have just that, no more, no less.

8) Avoid Designing Your Wireframe Too Much
Wireframing is about the functional way in which something operates it’s nothing to do with presentation or design. We try to avoid anything that could be construed as design. This will almost always distract the audience. Add a little blue just to try and make it more interesting and you will have a half an hour conversation about the merits of blue. Design should be left to designers.

9) Remember that UI is not UX
It can be extremely tempting to start thinking about the use of presentation methods such as AJAX. Remember that a wireframe document is about the functional elements and not the way they are presented or users interact with them. For accessibility reasons applications need to work without features like AJAX and therefore more like the wireframe.

10) Think About the User
It sounds obvious but it’s so easy to get caught up in creating a wireframe and forget about the user. The functional is what we’re focused on but it is still important to consider the user experience that is being created. For example, if you create a registration form that is three pages long you probably won’t find that many people fill it in.

11) Don’t Get Lazy
It’s often easy to say “the login page is obvious let’s not include it in the wireframe”. Make sure you wireframe everything. At the end of this process you should have a document that can be stepped through just like the final website. Every step counts and none should be ignored.

12) Organise Your Wireframe into Sections
A website or app is often divided into sections such as news, products and user account. Break up your wireframe document accordingly for much easier reference.

13) Number Your Pages
A web application often consists of a number of processes; a checkout is a good example. Often these are linear but sometimes users can choose different paths such as skipping a step. Clearly number the pages in your document and then label which page a particular action (such as clicking a button) takes the user to.

14) Look for Repetition
Consistency within an application is helpful to users, developers and designers. Repetition of groups of elements can therefore be a good thing. For example, wherever a user enters an address it should be the same fields in the same order. Look for these areas of repetition as you wireframe.

15) Check it all Makes Sense
The final document should be easy for anyone to follow. If only a developer can understand your wireframe then something has gone wrong. Ask at least one person who has nothing to do with the project if they understand it.

16) Ads are Functional
Many sites include advertising for monetisation, this may be as simple as Google ads but it is functional and not design, so include it.

17) It’s Not Just the Public Site
Many sites have an administration area for managing content, viewing registered user profiles, resetting passwords etc. This may not be viewed by many people but it is still important. Sometimes it can contain data that is not publicly available (such as a user account enable button). This is important information to developers when designing the database.

18) Know When to Stop
Make sure all relevant stakeholders have the opportunity to give feedback but don’t turn this exercise into painting the Sistine Chapel. Typically I would say three drafts should get the job done. The first gets the idea onto paper. The second reflects feedback from other parties such as developers, and designers. The third should be the final polish.

19) Choose the Right Tools
Pen and paper is often the way to start. It is much easier and faster than using a computer and lets you get thoughts and ideas down as the concept evolves.

Once you start creating the document our advice would be to use the tool you’re most comfortable with. Developers for example may use Microsoft Visio, project managers PowerPoint, Designers Adobe Fireworks.

I think that the wireframe should be a document though rather than something interactive (like design, it can be a distraction) and therefore creating HTML may not be the best thing.

There are a number of specific tools for wireframing, for example Balsamiq provides an environment for quickly adding and customising common interface elements. They have given it a hand drawn feel to provide a visual lift while not actually being design.

20) Consider Dependencies
Everyone knows what a shopping cart process is, right? Therefore it’s easy to wireframe and put to one side. Not entirely. What if you’re using a third party payment provider such as PayPal? That may influence how parts of the site must work. Research the areas where there will be dependencies and make changes accordingly. It’s easier to do it now than later.

Hopefully this article has provided a clear sense of the wireframing process, who’s involved, how to approach it, the tools to use and what the final output should be. The most important thing to remember, however, is that a thorough and well put together wireframe can save you a lot of time later in dealing with issues later on down the line.

Do you have any tips for creating great, usable wireframes fast?

Comments

181 comments on “20 Steps to Better Wireframing

  1. We create wireframes in the planning phase of a project. We first do a sitemap and then the wireframes which tie all the pages together in their relative interactions.As you mention, it's not important to define layout in wireframes, but we tend to present them with ready made elements like form fields, buttons, navigation bars etc.I find it visually illustrates the component level to the client, and as such opens the communication to more than just words and lists. More client understanding, less client problems.

  2. We create wireframes in the planning phase of a project. We first do a sitemap and then the wireframes which tie all the pages together in their relative interactions.

    As you mention, it's not important to define layout in wireframes, but we tend to present them with ready made elements like form fields, buttons, navigation bars etc.

    I find it visually illustrates the component level to the client, and as such opens the communication to more than just words and lists.

    More client understanding, less client problems.

  3. Clive,It is obvious from your post you feel very strongly that design should not be part of the wireframing process… so, that brings up one comment and one question:Comment: As a Designer, Developer, UI & UX guy, I am really having trouble either making the distinction you make in regard to design, or understanding how you can not include design during this phase. Good design can make or break the ease of use of a web form. Good design can take a three-page-long web form and turn it into a pleasing and non-overwhelming three step AJAX wizard. Would you not comp these things up as part of the wireframe?Question: I can totally see this process working (without design) as an internal exercise in a development company. However, do you ever use this process with external clients? I would have a lot of explaining to do if I showed my clients a series of B&W hand-drawn wireframes vs. nice color proof and ideas they are still used to from the print days. Finally, I plan on looking more into what you have written and trying to apply it. I have gotten used to sketching myself a quick idea, then coding. I normally use RoR, so changes are relatively easy to make.Thanks!Doug

  4. Clive,

    It is obvious from your post you feel very strongly that design should not be part of the wireframing process… so, that brings up one comment and one question:

    Comment: As a Designer, Developer, UI & UX guy, I am really having trouble either making the distinction you make in regard to design, or understanding how you can not include design during this phase. Good design can make or break the ease of use of a web form. Good design can take a three-page-long web form and turn it into a pleasing and non-overwhelming three step AJAX wizard. Would you not comp these things up as part of the wireframe?

    Question: I can totally see this process working (without design) as an internal exercise in a development company. However, do you ever use this process with external clients? I would have a lot of explaining to do if I showed my clients a series of B&W hand-drawn wireframes vs. nice color proof and ideas they are still used to from the print days.

    Finally, I plan on looking more into what you have written and trying to apply it. I have gotten used to sketching myself a quick idea, then coding. I normally use RoR, so changes are relatively easy to make.

    Thanks!
    Doug

  5. Thanks for the interesting article! I'm in the midst of wireframing a new app right now and it's starting to become a large project.I've been looking around (casually) for a wireframing tool that is more integrated with a site mapping tool. Something that would allow you to say create a site map first with just basic boxes and labels, and then “zoom in” on each page and create the wireframe for that. The problem I'm having is keeping the wireframes in an understandable order, because there are so many possible paths to take. Do you have any advice for the best way to organize wireframes once you have them? Are there good solutions for this problem, software or otherwise?Thanks again!

  6. Thanks for the interesting article! I'm in the midst of wireframing a new app right now and it's starting to become a large project.

    I've been looking around (casually) for a wireframing tool that is more integrated with a site mapping tool. Something that would allow you to say create a site map first with just basic boxes and labels, and then “zoom in” on each page and create the wireframe for that. The problem I'm having is keeping the wireframes in an understandable order, because there are so many possible paths to take.

    Do you have any advice for the best way to organize wireframes once you have them? Are there good solutions for this problem, software or otherwise?

    Thanks again!

  7. A really nice article. I have just started doing wireframes as the size of jobs we do grows, and i'm fast realising that i should be doing these wireframes on all websites! Thanks for the tips.

  8. A really nice article. I have just started doing wireframes as the size of jobs we do grows, and i'm fast realising that i should be doing these wireframes on all websites! Thanks for the tips.

  9. Good article although I'm not sure I entirely agree with the point about leaving out the UX. In these days of more advanced web apps that utilise Ajax or other rich interface technologies, I think it would be a mistake to completely leave out the UX side of things. This can often be the difference between something that's really compelling and something that's not. Sure, you can go down that path but eventually you're going to have to come back to it. And when you do, you may find that it completely changes many aspects of your original wireframes. Or that it forces you to re-think the original structure of your site/app because of the opportunities it allows. As you say, you need an accessible version but I think you can think about any non-accessible versions at the same time.Take Google Maps as an example. One of the main reasons it's compelling is that you can drag the map around (using Javascript). Without that, it's just another clunky map on the web. If they wireframed it without taking this aspect into account, people might have looked at it and said 'so what's the big deal? why are we investing in this project?'. Turn Javascript off and you will see the accessible version – it's extremely clunky and no better than loads of old map websites. It's the UX that makes it special.Overall, if you can, I think it's much better to try and short-circuit this whole process and take UX into account during the wireframing.

  10. Good article although I'm not sure I entirely agree with the point about leaving out the UX. In these days of more advanced web apps that utilise Ajax or other rich interface technologies, I think it would be a mistake to completely leave out the UX side of things. This can often be the difference between something that's really compelling and something that's not.

    Sure, you can go down that path but eventually you're going to have to come back to it. And when you do, you may find that it completely changes many aspects of your original wireframes. Or that it forces you to re-think the original structure of your site/app because of the opportunities it allows. As you say, you need an accessible version but I think you can think about any non-accessible versions at the same time.

    Take Google Maps as an example. One of the main reasons it's compelling is that you can drag the map around (using Javascript). Without that, it's just another clunky map on the web. If they wireframed it without taking this aspect into account, people might have looked at it and said 'so what's the big deal? why are we investing in this project?'. Turn Javascript off and you will see the accessible version – it's extremely clunky and no better than loads of old map websites. It's the UX that makes it special.

    Overall, if you can, I think it's much better to try and short-circuit this whole process and take UX into account during the wireframing.

  11. I'm all for wire framing, but I recommend 90% of the proposed graphic design being finished before one starts on any front-end development / UI. This is even more important in a rich environment such as Flash.

  12. I'm all for wire framing, but I recommend 90% of the proposed graphic design being finished before one starts on any front-end development / UI. This is even more important in a rich environment such as Flash.

  13. Stone me, but wireframes, like cad drawings, fail to communicate with the everyday clients…those who don't have the training to tame a wireframe into something that makes visual and structural sense…so this whole article, with all its confidence, misses the elephant in the room. Web developers need to develop and use better tools than wireframes to communicate effectively with their critical audience…the client.

  14. Stone me, but wireframes, like cad drawings, fail to communicate with the everyday clients…those who don't have the training to tame a wireframe into something that makes visual and structural sense…so this whole article, with all its confidence, misses the elephant in the room. Web developers need to develop and use better tools than wireframes to communicate effectively with their critical audience…the client.

  15. Very nice summary for good solid wireframe building. My personal favor is 19, use pen and paper – this is so helpful for the very first discussions. I would add 2 more items:21. Try alternatives. One way to do that would be have two teams work independently, or doing a second screen resolution (for mobile) with different starting conditions.22. Test your wireframes for two or three different user paths: home page down, landing page sidewards and detail page up. They will have different requirements for navigation and content.

  16. Very nice summary for good solid wireframe building. My personal favor is 19, use pen and paper – this is so helpful for the very first discussions. I would add 2 more items:

    21. Try alternatives. One way to do that would be have two teams work independently, or doing a second screen resolution (for mobile) with different starting conditions.

    22. Test your wireframes for two or three different user paths: home page down, landing page sidewards and detail page up. They will have different requirements for navigation and content.

  17. @123Column – Admittedly, wireframes often fail to help us connect with clients and stakeholders. From a website project perspective, however, this is usually because we do not effectively communicate with them. Many designers, no matter their role, find themselves educating clients. Wireframing tends to be one of the first processes we have to explain before pushing forward. As suggested in this article, why not really use it as a tool to continue the conversations that began in the project kick-off?The dreaded 'content delay syndrome', where certain content is promised but never delivered, can hurt us in the visual design phase: creating around 'air' is decoration, not design. This can prove frustrating, and is certainly futile. Wireframes can, in part, cure this ailment. As a planned deliverable, they can be used as bait, helping catch and reel in precious assets. Even if a client is skeptical about pieces of paper that don't convey visual ideas, they'll certainly warm up to them if they are used to start a dialogue: “The idea in this wireframe is to place content A here, and related content B here. What else would you like to see on this page? Do you have copy or images that might be appropriate? When can we expect to see those?”Although wireframes are just a stepping stone, they can lay the groundwork for the entire project, and certainly the tone. If you're using them as a communication tool first and foremost, project collaboration can only be more productive.

  18. @123Column – Admittedly, wireframes often fail to help us connect with clients and stakeholders. From a website project perspective, however, this is usually because we do not effectively communicate with them.

    Many designers, no matter their role, find themselves educating clients. Wireframing tends to be one of the first processes we have to explain before pushing forward. As suggested in this article, why not really use it as a tool to continue the conversations that began in the project kick-off?

    The dreaded 'content delay syndrome', where certain content is promised but never delivered, can hurt us in the visual design phase: creating around 'air' is decoration, not design. This can prove frustrating, and is certainly futile.

    Wireframes can, in part, cure this ailment. As a planned deliverable, they can be used as bait, helping catch and reel in precious assets. Even if a client is skeptical about pieces of paper that don't convey visual ideas, they'll certainly warm up to them if they are used to start a dialogue: “The idea in this wireframe is to place content A here, and related content B here. What else would you like to see on this page? Do you have copy or images that might be appropriate? When can we expect to see those?”

    Although wireframes are just a stepping stone, they can lay the groundwork for the entire project, and certainly the tone. If you're using them as a communication tool first and foremost, project collaboration can only be more productive.

  19. Really nice post. I absolutely agree visual design should not be part of the wireframing/planning process. Effective design can only take place after the information architecture, pathways, and function are understood. Premature visual design is bad design.

  20. Great article! The way I've always approached wireframes is an assembled decomposition of different elements/components that create a page. As such, pencil and paper are an excellent way to start. My personal favorite is to get a nice tablet of easel paper and a bunch of different sized Post-It notes and start identifying key areas of a wireframe — this makes the exercise tangible with very little investment in committing to a design tool (until later). Variants of a layout can easily be done by breaking out another sheet of paper and more Post-Its. This gets put into Visio to be incorporated into a document.Having conducted a large number of wireframe reviews, I've learned to keep the wireframes in grayscale and one font — some clients simply can't escape commenting on colors, or fonts or images, which really detracts from the purpose of a wireframe.I've also found that this is also good starting point for user testing with paper prototypes.

  21. Great article! The way I've always approached wireframes is an assembled decomposition of different elements/components that create a page. As such, pencil and paper are an excellent way to start. My personal favorite is to get a nice tablet of easel paper and a bunch of different sized Post-It notes and start identifying key areas of a wireframe — this makes the exercise tangible with very little investment in committing to a design tool (until later). Variants of a layout can easily be done by breaking out another sheet of paper and more Post-Its. This gets put into Visio to be incorporated into a document.

    Having conducted a large number of wireframe reviews, I've learned to keep the wireframes in grayscale and one font — some clients simply can't escape commenting on colors, or fonts or images, which really detracts from the purpose of a wireframe.

    I've also found that this is also good starting point for user testing with paper prototypes.

  22. Wireframes are fundamental to ensuring that the client and your team of designers and developers all understand what the expectations and deliverables are for the project before design and development takes place. In regard to the client not understanding what wireframes are, well that is the challenge for the project manager, information architect and designer to educate them. When you consider how budgets are being slashed and margins are reducing, creating wireframes are one of the key methods to ensuring that you reduce the risk of the project going wrong. To echo Andy's post…Fail to prepare, prepare to fail. Best for 2009 to all!

  23. Wireframes are fundamental to ensuring that the client and your team of designers and developers all understand what the expectations and deliverables are for the project before design and development takes place. In regard to the client not understanding what wireframes are, well that is the challenge for the project manager, information architect and designer to educate them. When you consider how budgets are being slashed and margins are reducing, creating wireframes are one of the key methods to ensuring that you reduce the risk of the project going wrong.

    To echo Andy's post…Fail to prepare, prepare to fail. Best for 2009 to all!

  24. A colleague and I are currently working on the functional design which we aim to get developed externally. We are effectively The Client, but we're trying to produce a very detailed spec which we can hand to a selection of developers to quote on and we will engage a separate UI designer.We find Microsoft Publisher really good for doing wireframes (less demanding than Visio) but as we often work remotely we were really struggling to manage the documentation – until we found Google Sites!If you're not familiar with it Google Sites is what has evolved from Google's purchase of JotSpot. It's basically a wiki builder. On the Google Site for our project we create a page for every page in our site, arranged in sections and sub sections, such as front end (public) and back end (cms/admin) pages. This is automatically represented as a sitemap. Each Google Site page consists of a web page plus attachments and comments.We save each Publisher wireframe as a 1024×768 jpeg and insert that into the relevant Google Sites web page. This allows us to step through the site via the Google Site Sitemap and see the wireframe for each page we click on. We also upload the Publisher document as an attachment for the page in case we want to change it later. Anything that we need to explain to one another is entered into the comments section for that page.Because the Google Site has wiki functionality it includes automatic version control. Google Sites also includes user configurable notifications of changes to the site. So all team members (2 in this case) get notified if a page is created, moved or updated.Finally, I have to agree with some other comments – I cannot see how UX can be divorced from the wireframe process.

  25. A colleague and I are currently working on the functional design which we aim to get developed externally. We are effectively The Client, but we're trying to produce a very detailed spec which we can hand to a selection of developers to quote on and we will engage a separate UI designer.

    We find Microsoft Publisher really good for doing wireframes (less demanding than Visio) but as we often work remotely we were really struggling to manage the documentation – until we found Google Sites!

    If you're not familiar with it Google Sites is what has evolved from Google's purchase of JotSpot. It's basically a wiki builder. On the Google Site for our project we create a page for every page in our site, arranged in sections and sub sections, such as front end (public) and back end (cms/admin) pages. This is automatically represented as a sitemap. Each Google Site page consists of a web page plus attachments and comments.

    We save each Publisher wireframe as a 1024×768 jpeg and insert that into the relevant Google Sites web page. This allows us to step through the site via the Google Site Sitemap and see the wireframe for each page we click on. We also upload the Publisher document as an attachment for the page in case we want to change it later. Anything that we need to explain to one another is entered into the comments section for that page.

    Because the Google Site has wiki functionality it includes automatic version control. Google Sites also includes user configurable notifications of changes to the site. So all team members (2 in this case) get notified if a page is created, moved or updated.

    Finally, I have to agree with some other comments – I cannot see how UX can be divorced from the wireframe process.

  26. Thanks,Your steps for better wireframing is very good. i like it…………………….With all the wireframing tools out there like Visio®, OmniGraffle®, Illustrator, InDesign, Flash®, Fireworks®, and HTML/CSS, why create a framework based on InDesign and Illustrator.http://www.profitablenuggets.com/

  27. Thanks,Your steps for better wireframing is very good. i like it…………………….

    With all the wireframing tools out there like Visio®, OmniGraffle®, Illustrator, InDesign, Flash®, Fireworks®, and HTML/CSS, why create a framework based on InDesign and Illustrator.

    http://www.profitablenuggets.com/

  28. Hi Clive, Interesting article and some useful tips. But I agree with Douglas Neiner. I too have some comments and suggestions.While I do not agree with the principle of ignoring design and layout, I think I understand the spirit of what you were trying to say. Wireframes are a representation of screen content and priorities. They should illustrate functions and behaviors. So, even in the most minimal presentation, wireframes inherently contain some indication of placement or layout. I think your point is that wireframes are not design comps/mocks. They are tools for hammering out user experience as you work toward a final user interface design.I'd like to suggest that IxDs not be afraid of testing a wireframe. On several projects, I've conducted usability tests with nothing more than an HTML wireframe prototype. This is an effective way to ID assumptions that worked or didn't. Plus, it gives you some usability data to work with and share. Lastly, you alluded to prerequisites early in the article, but didn't address directly what information people absolutely needed as a precursor to wireframing. For instance, it's impossible to create *effective* wireframes without first having created a flowchart based upon the scope worked out between you and the client. There are several other possible deliverables that would help too, but at a minimum you need flow and scope nailed down before tackling wires.Very interesting and useful article. Thank you for the opportunity to comment.- Jon

  29. Hi Clive,
    Interesting article and some useful tips. But I agree with Douglas Neiner. I too have some comments and suggestions.

    While I do not agree with the principle of ignoring design and layout, I think I understand the spirit of what you were trying to say. Wireframes are a representation of screen content and priorities. They should illustrate functions and behaviors. So, even in the most minimal presentation, wireframes inherently contain some indication of placement or layout. I think your point is that wireframes are not design comps/mocks. They are tools for hammering out user experience as you work toward a final user interface design.

    I'd like to suggest that IxDs not be afraid of testing a wireframe. On several projects, I've conducted usability tests with nothing more than an HTML wireframe prototype. This is an effective way to ID assumptions that worked or didn't. Plus, it gives you some usability data to work with and share.

    Lastly, you alluded to prerequisites early in the article, but didn't address directly what information people absolutely needed as a precursor to wireframing. For instance, it's impossible to create *effective* wireframes without first having created a flowchart based upon the scope worked out between you and the client. There are several other possible deliverables that would help too, but at a minimum you need flow and scope nailed down before tackling wires.

    Very interesting and useful article. Thank you for the opportunity to comment.
    - Jon

  30. I'm with the other designers here. Before I got involved in the planning side at my work, Business were doing thorough wireframes, but it wasn't until I was mocking them that we created MUCH better user paths that were cleaner and more user friendly. This meant that dev had to redo things because we hadn't realized the processes were, as said here, clunky.Now, I'm more involved at the initial concept page, wireframes are only top level elements, and our app has improved in both dev/design time and in how it works.

  31. I'm with the other designers here. Before I got involved in the planning side at my work, Business were doing thorough wireframes, but it wasn't until I was mocking them that we created MUCH better user paths that were cleaner and more user friendly. This meant that dev had to redo things because we hadn't realized the processes were, as said here, clunky.

    Now, I'm more involved at the initial concept page, wireframes are only top level elements, and our app has improved in both dev/design time and in how it works.

  32. Very good list. I've heard a lot of argument for killing the old fashion wireframe in favor of prototypes to show interaction. Any thoughts on that?

  33. Very good list. I've heard a lot of argument for killing the old fashion wireframe in favor of prototypes to show interaction. Any thoughts on that?

  34. This is an excellent topic — its apropos — for I have been in the cross hairs of a development team thats focused on WCM migration; that has used my wireframe prototypes to explain to the client how the site is going to build out in a WCM system!This would be all fine and dandy — if it weren't the first round of wireframes produced!!!In the process of defining the “UI” — (very glad you made that distinction from UX) — we expanded 4 different divisions into 9 respective audience based markets. Now — while this was consistent with customer surveys — we were still aways away from flushing out additional content/features of the UI per a market group, and the complete redesign process.Smelling victory — the development team worked with the client to flush out the “functional” aspects based on the preliminary wireframes — without my or the PM's knowledge. We conducted follow up workshops with the client to ensure validation — only to have to course correct the wireframes — which they “thankfully” agreed with — as they were major improvements to visual/content hierarchy, etc.That said — we were fortunate.At times — and in good faith — developers look at wireframes to review with clients — as a “decision framework” — while designers — obviously in good faith as well — look at wireframes to review with clients as a “user interface / content / design framework. Point being — it should be “iterative” — before functional decisions/business rules made.I really like number 18.) Know when to Stop. I like the three stage process — I just call it “Scrub, Polish and Shine:)Would love to hear similar / relevant stories.Thanks,JD

  35. This is an excellent topic — its apropos — for I have been in the cross hairs of a development team thats focused on WCM migration; that has used my wireframe prototypes to explain to the client how the site is going to build out in a WCM system!

    This would be all fine and dandy — if it weren't the first round of wireframes produced!!!

    In the process of defining the “UI” — (very glad you made that distinction from UX) — we expanded 4 different divisions into 9 respective audience based markets. Now — while this was consistent with customer surveys — we were still aways away from flushing out additional content/features of the UI per a market group, and the complete redesign process.

    Smelling victory — the development team worked with the client to flush out the “functional” aspects based on the preliminary wireframes — without my or the PM's knowledge. We conducted follow up workshops with the client to ensure validation — only to have to course correct the wireframes — which they “thankfully” agreed with — as they were major improvements to visual/content hierarchy, etc.

    That said — we were fortunate.

    At times — and in good faith — developers look at wireframes to review with clients — as a “decision framework” — while designers — obviously in good faith as well — look at wireframes to review with clients as a “user interface / content / design framework. Point being — it should be “iterative” — before functional decisions/business rules made.

    I really like number 18.) Know when to Stop. I like the three stage process — I just call it “Scrub, Polish and Shine:)

    Would love to hear similar / relevant stories.

    Thanks,

    JD

  36. It seems to me that it is easy to overthink things like design. But it is essential to follow through with a plan for the design. You want to be sure everything works and is dependable before you consider it done. It is always a hassle trying to go back to fix something later, and sometimes not possible.

  37. Before starting any project I am always out with my yellow note pad writing down an outline. Its just clear sense to do so because you dont want to leave anything out. Either be it writing an ebook to web design I have my pen and paper out brainstorming everything that could possibly be added. Great post people need to be reminded of this time to time to go back to the old methods.

  38. A lot of good points here. My husband has built many web sites and he often starts the process with a paper and pencil.Keep it simple but not too simple.Make it functional but not too complicated.Include only relevant information.Don't clutter with un-necessary stuff.Do include some good, relevant images.Check your spelling then get someone to proof read it.

  39. A lot of good points here. My husband has built many web sites and he often starts the process with a paper and pencil.
    Keep it simple but not too simple.
    Make it functional but not too complicated.
    Include only relevant information.
    Don't clutter with un-necessary stuff.
    Do include some good, relevant images.
    Check your spelling then get someone to proof read it.

  40. Possibly the biggest mistake in any development project is failure to plan. Recently, the owner of a prospective start-up told me that planning was unnecessary and a good developer could just start coding. This, I promise you, will end in tears.

  41. I'm a web designer and have been learning IA/UX design for the past year or so. I started doing wireframes in Illustrator using grey-scale so as not to distract the client with colours etc. I've moved to using paper wireframes for speed, this also lets others get involved in meetings. I recently tried “Stickyframes” http://wireframes.linowski.ca/?p=96 during a client meeting and found it give a level of agility and client involvement in the process that sketching on paper alone didn't give me. At the end of a meeting I whip out my camera and photograph the wireframes – then use them for sign-off.

  42. I'm a web designer and have been learning IA/UX design for the past year or so. I started doing wireframes in Illustrator using grey-scale so as not to distract the client with colours etc. I've moved to using paper wireframes for speed, this also lets others get involved in meetings. I recently tried “Stickyframes” http://wireframes.linowski.ca/?p=96 during a client meeting and found it give a level of agility and client involvement in the process that sketching on paper alone didn't give me. At the end of a meeting I whip out my camera and photograph the wireframes – then use them for sign-off.

  43. Wireframing is one of the first steps in your planning process and arguably it’s one of the most important ones. This is when the idea starts to take shape as an application, becoming boxes and buttons that users will interact with. This article will take you through a wireframing process; who should be involved, the tools to use and tips to enable you to make better wireframes.Here are 20 short tips that you should take in consideration: 1. Be Clear About Your Objective 2. Make it Functional, Not Pretty 3. Draw on Your Experience 4. Decide Who’s in Charge? 5. Involve Everyone 6. Set a Deadline for Completing the Wireframe 7. Keep it clean 8. Avoid Designing Your Wireframe Too Much 9. Remember that UI is not UX 10. Think About the User 11. Don’t Get Lazy 12. Organise Your Wireframe into Sections 13. Number Your Pages 14. Look for Repetition 15. Check it all Makes Sense 16. Ads are Functional 17. It’s Not Just the Public Site 18. Know When to Stop 19. Choose the Right Tools 20. Consider Dependencies

  44. Wireframing is one of the first steps in your planning process and arguably it’s one of the most important ones. This is when the idea starts to take shape as an application, becoming boxes and buttons that users will interact with. This article will take you through a wireframing process; who should be involved, the tools to use and tips to enable you to make better wireframes.

    Here are 20 short tips that you should take in consideration:

    1. Be Clear About Your Objective
    2. Make it Functional, Not Pretty
    3. Draw on Your Experience
    4. Decide Who’s in Charge?
    5. Involve Everyone
    6. Set a Deadline for Completing the Wireframe
    7. Keep it clean
    8. Avoid Designing Your Wireframe Too Much
    9. Remember that UI is not UX
    10. Think About the User
    11. Don’t Get Lazy
    12. Organise Your Wireframe into Sections
    13. Number Your Pages
    14. Look for Repetition
    15. Check it all Makes Sense
    16. Ads are Functional
    17. It’s Not Just the Public Site
    18. Know When to Stop
    19. Choose the Right Tools
    20. Consider Dependencies

  45. A plan is essential to reach the target you have set because it breaks down several checkpoints to achieve and complete, so in final you reach your goal with better motivation and speed.

  46. Excellent article. Love the “half an hour conversation about the merits of blue” bit….any design elements in wireframes always take the discussion off course. I often use only black and white to create wireframes for my clients specially so they will focus on the functionality. As a designer/developer I've always found wireframes to be an important step. I do differ with you on the inclusion of ajax and other layout elements. I consider those to be part of the functionality and include them within the wireframes.

  47. Excellent article. Love the “half an hour conversation about the merits of blue” bit….any design elements in wireframes always take the discussion off course. I often use only black and white to create wireframes for my clients specially so they will focus on the functionality.

    As a designer/developer I've always found wireframes to be an important step. I do differ with you on the inclusion of ajax and other layout elements. I consider those to be part of the functionality and include them within the wireframes.

  48. This I can personally vouch for. I have been in a situation where before where I was badly burnt by not following the above article. Although it may sound like common sense I can assure you most people forget about grass roots when planning.

  49. One small (yet critical) addition to your points, would be to *keep testing* the integrity and flow as a part of the development cycle, and not just a one-time blueprint. Force yourself to go over everything on a weekly(?) basis, as a sanity check.It's very easy to under-estimate the influence small changes in the development can have over the entire user experience.And sure.. Balsamiq is a great for quick mockups. You can read my impressions of using it here: http://www.aboutux.com/?p=22

  50. One small (yet critical) addition to your points, would be to *keep testing* the integrity and flow as a part of the development cycle, and not just a one-time blueprint.
    Force yourself to go over everything on a weekly(?) basis, as a sanity check.
    It's very easy to under-estimate the influence small changes in the development can have over the entire user experience.

    And sure.. Balsamiq is a great for quick mockups. You can read my impressions of using it here: http://www.aboutux.com/?p=22

  51. Tim Wright wrote: “I've heard a lot of argument for killing the old fashion wireframe in favor of prototypes to show interaction. Any thoughts on that?”

    I guess it depends on what “old fashion wireframe” means. But essentially I would agree. The wireframes we produce are quite sophisticated, sometimes we include things like functional drop down lists and dummy images, but we find it really worthwhile when working on the functional design of a site. I'm sure most clients would appreciate more detailed wireframes.

    Kev said: ” I started doing wireframes in Illustrator using grey-scale so as not to distract the client with colours etc. I've moved to using paper wireframes for speed, this also lets others get involved in meetings.”

    There are many tools for wireframing that are easier than Illustrator! One of the guys who works for me was cursing his Uni lecturer once he discovered how easy it was to create wireframes using MS Publisher (because his Uni lecturer had steered everyone down the Illustrator path). There are two of us working on the functional design for a complex site and Publisher enables us to share documents for modification or re-use of elements. It also allows pages to be saved in MHTML or as a jpeg. Much more efficient than pen and paper. IMHO :)

    Of course at the end of the day there's no right or wrong, there's just different ways of approaching the functional design phase.

  52. Tim Wright wrote: “I've heard a lot of argument for killing the old fashion wireframe in favor of prototypes to show interaction. Any thoughts on that?”I guess it depends on what “old fashion wireframe” means. But essentially I would agree. The wireframes we produce are quite sophisticated, sometimes we include things like functional drop down lists and dummy images, but we find it really worthwhile when working on the functional design of a site. I'm sure most clients would appreciate more detailed wireframes. Kev said: ” I started doing wireframes in Illustrator using grey-scale so as not to distract the client with colours etc. I've moved to using paper wireframes for speed, this also lets others get involved in meetings.”There are many tools for wireframing that are easier than Illustrator! One of the guys who works for me was cursing his Uni lecturer once he discovered how easy it was to create wireframes using MS Publisher (because his Uni lecturer had steered everyone down the Illustrator path). There are two of us working on the functional design for a complex site and Publisher enables us to share documents for modification or re-use of elements. It also allows pages to be saved in MHTML or as a jpeg. Much more efficient than pen and paper. IMHO :)Of course at the end of the day there's no right or wrong, there's just different ways of approaching the functional design phase.

  53. Excellent article. I work in web development and I know first-hand how crucial it is to go through use-cases before delving into actual code. Coding comes only after you've drafted up a solid design doc.

  54. Excellent article. I work in web development and I know first-hand how crucial it is to go through use-cases before delving into actual code. Coding comes only after you've drafted up a solid design doc.

  55. For people who are total beginners and have never seen wireframes and how they look like, is there any resources or examples? Would really appreciate it if you gurus could point out towards the right direction.

  56. understand a structure of project. make a tree or map of prototypegreat article. we are following all points

  57. understand a structure of project. make a tree or map of prototype

    great article. we are following all points

  58. If you wish to be associated with a professional sporting tournament, that is, you wish to be a part of live action; you need to purchase valid Tickets to a match. for more information please visit at Concert Tickets . you will get your ticket over here without any obstacle.

  59. If you wish to be associated with a professional sporting tournament, that is, you wish to be a part of live action; you need to purchase valid Tickets to a match. for more information please visit at Concert Tickets . you will get your ticket over here without any obstacle.

  60. Interesting articles and shows the complexities that need to be covered prior to the coding. impressive read and the points make it easier to understand.

  61. And here I am thinking I was in the minority that designs websites on paper before going directly to photoshop. Im going to start wire framing with marker like you did. Its a good idea and looks a lot better then pen chicken scratch lol

  62. I'm a designer and I absolutely agree that design should not be part of the wireframing process, wireframing helps me show the scope of the project to a customer (as well as giving me a path to follow when I'm designing). Once this is approved any changes become billable, you don't want to create a presentation and take away where the focus should be, at least initially, on usability and the scope of the project.

  63. I'm a designer and I absolutely agree that design should not be part of the wireframing process, wireframing helps me show the scope of the project to a customer (as well as giving me a path to follow when I'm designing). Once this is approved any changes become billable, you don't want to create a presentation and take away where the focus should be, at least initially, on usability and the scope of the project.

  64. Good article about wireframes. My team and I creates wireframe during the initial stage of the project. But sometimes wireframe failed to please the client so therefore, we go back again to the step. What the web developers need is to have a better tools than wireframe, to be more client friendly. One of my friends suggests Axure, he said it is much easier to use.

  65. I agree with all the points you made except for one: “I think that the wireframe should be a document though rather than something interactive”. You are designing something interactive so the wireframe needs to be interactive. In my experience, a HTML/CSS wireframe gives the UX designers, programmers and writers a much better understanding of how the page, section, form, etc. will work. This is especially true in dealing with dynamic navigation or content. Instead of explaining that a user has to select “Y” to get “X” in a written or illustrative form, you can just show it. Doing the upfront HTML work has saved me a lot of time explaining in the long run.

  66. I completely agree about including something about planned/thought of interactivity. In my case (I design a lot of data driven flash-based apps), without describing the interactivity to some extent would sell the idea short. If I'm wireframing or sketching a whole page design and there's some interactivity/widgets that's required to view layers of info, that's included as well. I'll also do smaller sketches of the widgets with a little more detail.

  67. I completely agree about including something about planned/thought of interactivity. In my case (I design a lot of data driven flash-based apps), without describing the interactivity to some extent would sell the idea short. If I'm wireframing or sketching a whole page design and there's some interactivity/widgets that's required to view layers of info, that's included as well. I'll also do smaller sketches of the widgets with a little more detail.

  68. I completely agree about including something about planned/thought of interactivity. In my case (I design a lot of data driven flash-based apps), without describing the interactivity to some extent would sell the idea short. If I'm wireframing or sketching a whole page design and there's some interactivity/widgets that's required to view layers of info, that's included as well. I'll also do smaller sketches of the widgets with a little more detail.http://www.Start-an-Internet-business.net

  69. I completely agree about including something about planned/thought of interactivity. In my case (I design a lot of data driven flash-based apps), without describing the interactivity to some extent would sell the idea short. If I'm wireframing or sketching a whole page design and there's some interactivity/widgets that's required to view layers of info, that's included as well. I'll also do smaller sketches of the widgets with a little more detail.
    http://www.Start-an-Internet-business.net

  70. Perhaps a print page would be nice. Printed out this article and got about 20 pages of comments.

  71. I haven't read all the comments, but I don't fully agree with your article on a few points and would like to make a few other points clearer.

    1. You state that "You do not need skills in design or development. All anyone needs is experience in using web apps or websites. Of course the more experience the better but you don’t need to understand relational databases to wireframe."

    Here you imho underestimate the importance of wireframes, and the fact that not everybody is suitable for creating wireframes. Also: a wireframes document is a method to get the goals of the client clear ánd to help gain insight for that same client. If you create wireframes you should always consider two goals: the business goals ánd the user goals (which might be the most important!).

    2. "All anyone needs is experience in using web apps of websites".

    If you want to make good wireframes you have to know about conventions, how users think, research what users need, what they want, you need knowledge of usability, mental models etc etc. Preferably you research before you design wireframes: talk to the enduser, stakeholders, observe, interview etc.

    3. "Equally designers have a good understanding of user experience and can spot potential problems in the flow early on."

    My experience is that not all graphic designers are suited for the task: you need someone who can think analytic and oversee the overall meaning. This doesn't always match with a creative person ;-)

    4. You also state that three sessions with the client are enough to get wireframes finished.

    While this can be true for smaller projects, in bigger projects this is almost undoable. Wireframes become more complex, you have more stakeholders, insights may change because the client understands impact etc.

    5. What I miss in your article is the relation with a functional design: you identify the functionality and place it in context in the wireframes, but imho you have to describe it in detail in a functional design. This way you will come across a lot of 'minor' details which might not be so minor after all. Besides that it clears out a lot of uncertainty for the client and developers (it helps scoping).

    Also: wireframes are input for graphic design. When the wireframes are agreed on by the client, you can start graphic designing (if you use design in your wireframes, or skip the wireframes, the discussion with the client is unclear. A client will always be distracted by design and therefore focus on – in that stage – unimportant things like color etc).

    Anyway: interesting article and thanks for sharing it!

    PS: there is a name for people who – amongst/with others – create wireframes. They are called interaction designers ;-)

  72. Pingback: Wireframe Websites That Wow | Web Design Blog by Union Room Web Design

  73. Another important step to consider before you put pen to paper is to decide who the intended audience is for the wireframe – is it an internal workproduct to be handed off to design & dev, or a communication/sign-off specification to be presented to clients, etc.

    Also, consider what role the wireframe document has in your workflow. Some places use it as a convenient "bible", making it the authoritative repository for final text copy too. Thus editorial and legal need to be included on the distribution list.

  74. It's easier to conceptualize using pen and paper, but it's better to avoid miscommunication with clients/other teammates when we have something more detailed, even though not complex. If you allow me to recommend JustInMind, you can do the wireframe, prototype, mockup and document, all in one application, then share it with clients.

    It's worth a try.

  75. It's easier to conceptualize using pen and paper, but it's better to avoid miscommunication with clients/other teammates when we have something more detailed, even though not complex. If you allow me to recommend JustInMind, you can do the wireframe, prototype, mockup and document, all in one application, then share it with clients.

    It's worth a try.

  76. I’m about to start wireframing soon, I have run some contextual enquiry interviews, some card sorting exercises (open and closed) and now I’m going to start testing the levels of IA using wireframes. I have found the Axure software useful, though I keep having to stop myself from being so picky about lining boxes up too neatly!

  77. Pingback: links for 2009-07-17 « Köszönjük, Emese!

  78. I’m in agreement with those who question the effectiveness of wireframes as an external client tool. Wireframes are invaluable as an internal tool. They work best when shared with a team to help understand functionality, flow, and intent of an app or site. In my experience it is rare when a client really understands a wireframe, and why should they, really? The intent of the wireframe can be better conveyed through a diagrammed flow or even a narrative word document.

    Another issue that drives me mad is usability testing on wireframes. What that says to me is that design is not valued; design is superficial and is merely a “skin” for the wireframe. Sorry but design is an integral part of the process; design thinking is very much about structure, flow, and how to guide a user through an experience.

  79. Pingback: Wireframes and Design | monkeyshinemedia.net

  80. Pingback: Wayne State Web Communications Blog » Blog Archive » [Friday Links] The eduWeb Edition

  81. Pingback: 15 Indispensable Elements of Website Design for Serious Graphic Designers | Pixelactic

  82. Pingback: 精品阅读(8)20090901 -- 寂寞如哥

  83. Pingback: 画好线框图的20个步骤 « 海上风

  84. Pingback: Links for the day | CssGalleries

  85. Pingback: links for 2009-10-22 « Minesa IT

  86. Pingback: Redesign: When To Do It And Best Practices - Smashing Magazine

  87. Pingback: Redesign: When To Relaunch The Site and Best Practices

  88. Pingback: Redesign: When To Relaunch The Site and Best Practices | Buddy's Blog

  89. As important as scheduling is, customers do not seem to believe them. So, in the proposal stage, I word my document’s presentations to include that meeting due dates without meeting schedule dates will alter the due dates and may alter the cost of the project.

    Does anyone else work this sort of understanding into their work proposals?

  90. Pingback: Wireframing Guidelines | Susana Vilaça

  91. Pingback: Website Wireframes «Mário Andrade

  92. Pingback: INFLUX library user experience › askINFLUX: Wireframing Tools?

  93. Pingback: Wireframes - More Detail Please

  94. Pingback: End of Year Link Compilation | CssGalleries

  95. Pingback: Guidelines, Tools and Resources For Web Wireframing - Memphis, Tennessee's Premier Web Design Agency

  96. Pingback: Guidelines, Tools and Resources For Web Wireframing Ajax Help W3C Tag

  97. Pingback: Redesign: When To Relaunch The Site and Best Practices « Top 10 Web Hosting

  98. Pingback: Designing User Interfaces For Business Web Applications - Smashing Magazine

  99. Pingback: Designing User Interfaces For Business Web Applications | World Wide Web

  100. Pingback: Designing User Interfaces For Business Web Applications | Best Web Magazine

  101. Pingback: Designing User Interfaces For Business Web Applications | Web Design Cool

  102. Pingback: Designing User Interfaces For Business Web Applications « wonnab

  103. Pingback: Designing User Interfaces For Business Web Applications « Usability – My Love

  104. Pingback: Designing User Interfaces For Business Web Applications « DesignerLinks

  105. Pingback: Designing User Interfaces For Business Web Applications | MarketingTypo.com

  106. Pingback: Designing User Interfaces For Business Web Applications | iDezigner.Com

  107. Pingback: » Blog Archive » Designing User Interfaces For Business Web Applications

  108. Pingback: Guidelines, Tools and Resources For Web Wireframing - Free Templates and theme

  109. Pingback: Designing User Interfaces For Business Web Applications | Blog

  110. Nice hints and tips for wireframing! Yet the logic is a little chaotic and hard to recall after reading.

  111. Great post. So important to set time aside for wireframing. We are trying to get better at it – but it’s always a challenge when deadlines are near.

  112. this is great, it makes me sick to my stomach when designers/developers move right into code or photoshop without sketching out ideas. For larger sites I think it is always important to wireframe all important modules/pages, for smaller sites its a judgement call depending on the client and scope. Thanks!

  113. Pingback: Wireframes — Information Architecture and Usability - btk-fh

  114. Pingback: Week 6 | Online documentary Tutorial 2012

  115. Pingback: Escape Velocity Podcast » EV Discussions : All about Wireframing

  116. As the saying goes, if it ain’t broke, don’t fix it. It’s also far too easy to criticise without offering a better alternative. If you’ve got a ‘better’ approach, let’s hear it.

  117. I am very grateful for this post. I suddenly got saddled with the task and your post pointed me in the right direction. Thank you :)