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.
kat neville
· 10 months ago
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.
Douglas Neiner
· 10 months ago
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
Ross
· 10 months ago
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.
Kanwal Khipple
· 10 months ago
One of my favorite apps is Balsamiq Mockups. It has helped deliver quick wireframes that clients can understand.
furley
· 10 months ago
Use AXURE!!!! Best wireframing / prototyping tool. I got it a few weeks ago. It makes wireframing so easy.
it`s true. but in this aplication there are functions of which it is not in visio
Joe Fritz
· 10 months ago
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!
Ali Reid
· 10 months ago
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.
rogoff
· 10 months ago
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.
Michael Locke
· 10 months ago
Great list. Only if every company followed these rules, life would be grand. :)
Stephen James
· 10 months ago
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.
andy
· 10 months ago
nice tips - failing to plan, is planning to fail
123column
· 10 months ago
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.
andreaswpv
· 10 months ago
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.
LizHunt
· 10 months ago
@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.
raygulick
· 10 months ago
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.
vsolanoy
· 10 months ago
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.
Martin
· 10 months ago
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!
Kevin Howard
· 10 months ago
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 1024x768 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.
Phil Shaw
· 10 months ago
Please get a print stylesheet that doesn't print useless navigation.
Jon Kranz
· 10 months ago
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
Tim Wright
· 10 months ago
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?
Kevin Howard
· 9 months ago
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.
Johnny741
· 10 months ago
That is so very true, you either plan to fail or fail to plan and that really is the bottom line.
petenice
· 10 months ago
Great article. Nice to see that I'm not alone in the wireframe world.
Jerome
· 10 months ago
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
lindaevv
· 10 months ago
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.
Using Balance Transfers
· 10 months ago
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.
simon
· 10 months ago
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.
steven
· 10 months ago
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.
Kev
· 10 months ago
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.
stevenhill
· 10 months ago
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
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.
Ally
· 10 months ago
As some other said, we also use wireframes in the beginning phase of a project.
Joel McHale
· 10 months ago
Thanks for the article on wireframing - very informative.
Yanay Zohar
· 10 months ago
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
raymondphilippe
· 10 months ago
Very informative! I like it..
vst plugins
· 9 months ago
I've always used wireframe to make notes when starting projects
vst plugins
· 9 months ago
I use this to take notes before starting any project
weboncloud
· 9 months ago
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.
Oleg
· 9 months ago
understand a structure of project. make a tree or map of prototype
great article. we are following all points
Ahmad Amran
· 9 months ago
I love iplotz.com better than balsimiq . +1 to iplotz.
Linda012
· 9 months ago
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.
Dave scott
· 9 months ago
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.
Daniel
· 9 months ago
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
LMartian
· 9 months ago
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.
com
· 9 months ago
Thanks for the info. This is important for time managers like me.
Chance Bliss
· 8 months ago
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.
JasonSt
· 8 months ago
Thanks for the article. I for one find myself rushing the code a bit too much and making mistakes in the process. My last site looks better by slowing things down and doing them right. JasonSt <a href=” www.vimax-penis-enlargement-pill.com”>Men's health issues
jane4455
· 8 months ago
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. www.Start-an-Internet-business.net
theme park consulting
· 8 months ago
Awesome article. I've started doing wireframes recently at work and this article was certainly a good reading
Matthew
· 8 months ago
Perhaps a print page would be nice. Printed out this article and got about 20 pages of comments.
sharmin
· 10 months ago
i like this article..it's realy good information.realy realy informative post
All Comments
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.
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.
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
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.
http://www.axure.com/
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!
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.
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.
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.
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.
To echo Andy's post...Fail to prepare, prepare to fail. Best for 2009 to all!
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 1024x768 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.
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
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.
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
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.
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
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
great article. we are following all points
JasonSt <a href=” www.vimax-penis-enlargement-pill.com”>Men's health issues
www.Start-an-Internet-business.net
<a href="http://www.crystalfeel.com ">crystalfeel