no more wireframes?

1. 1

   Nadav Savio on October 15, 2003 at 5:06 pm

   Never say never, of course, but I too have grown increasingly disillusioned with wireframes. In most cases, I find what’s called for is either significantly more or significantly less fidelity than the traditional grey boxes and Helvetica treatment.

2. 2

   Mike Steckel on October 15, 2003 at 6:58 pm

   This seems a little strong to me, but that may be the result of the way things are done at my place (I am in-house). When I use them, my wireframes are paper prototypes with little or no notation. We carry them around to various departments, lay them out across the tables, and try to build consensus on why certain pieces should be designed as they are on the page in front of us. Colors and fonts are added so late in the process that I don’t know how I could talk about page structure without something visual to point to and argue over. The only notation I use is for the programmers. While there are problems with wireframes (as you lay out in your book!), and IAs may include too much on them, it seems almost non-sensical to disregard wireframes all together. It is rare that I disagree with you so I am assuming I am misunderstanding something.

3. 3

   Paul Nattress on October 16, 2003 at 2:17 am

   Here’s an example of how we use wireframes (I work in-house).

   We’re redesigning a contact form. As we’re a small team, we’re designers, HTMLers, IA, usability and content people all rolled into one. so, we design visuals in PhotoShop (or whichever image tool takes our fancy) and put together Wireframes in PowerPoint (makes them easy to distribute).

   The visuals show the information/interaction design and the wireframes show the functionality. The options in the drop-down boxes, the logic that defines which fields are shown when certain boxes are ticked are defined in the wireframe. Wireframes can be chopped around and changed very easily.

   Problems can occur when an out-of-date visual is given to the developers with an up-to-date wireframe. However, our team is very good and can design the new layout from the wireframe into the visual design of the visual. Of course we’ll make sure that any major deviations are noted in the visuals.

   Wireframes are useful to us, but only in conjunction with visuals.

4. 4

   Austin on October 16, 2003 at 9:20 am

   I think wireframes are absolutely necessary for interaction design, as I depend on the layout to communicate everything without color, without type, without icons, logos, or other graphics.

   For brochure websites, I agree that wireframes are unnecessary. And, when I’m working with a really good visual designer, I create “cognitive task maps” instead of wireframes.

   I group the types of navigation together in a visual diagram. I also prioritize the various groups of elements in a text list. I try and communicate what’s important and what belongs together.

   Unfortunately, with bad visual designers, not only do they want a wireframe they can paint by numbers, they need one. In my experience, they’ll design crap when given free reign.

   In a few rare instances where you have a team that really understands and ‘feels’ the web, I think you can go from wireframes to stunning visual designs without any compromises, without the wireframe limiting the creativity of the visual design. That’s how it’s supposed to work.

5. 5

   erin on October 16, 2003 at 12:34 pm

   I would tend to disagree with you about this but my disagreement is dependent on the nature of the team involved in the creation of the experience. The more joined at the hip visual design and UI/IA/Exp designers are, the less need for formal wireframes done by the interaction folks. The work would be collaborative and the page hierarchy and layout would be developed together in a symbiotic manner between designer and interaction/IA person. I don’t think being in-house versus consultant has anything to do with it. If on the other hand you are in an orgaqnization that is made up of several geographic locations and teams are dispersed and not joined at the hip as much as they should be then wireframes are imperitive to make sure that the full intent of the interaction design (hierarchy of important details, actions, messaging etc) are understood.

6. 6

   erin on October 16, 2003 at 12:37 pm

   I would tend to disagree with you about this but my disagreement is dependent on the nature of the team involved in the creation of the experience. The more joined at the hip visual design and UI/IA/Exp designers are, the less need for formal wireframes done by the interaction folks. The work would be collaborative and the page hierarchy and layout would be developed together in a symbiotic manner between designer and interaction/IA person. I don’t think being in-house versus consultant has anything to do with it. If on the other hand you are in an orgaqnization that is made up of several geographic locations and teams are dispersed and not joined at the hip as much as they should be then wireframes are imperitive to make sure that the full intent of the interaction design (hierarchy of important details, actions, messaging etc) are understood.

7. 7

   Paul Nattress on October 17, 2003 at 12:40 am

   I would agree with you there Erin. We’ve given work to outside agencies that don’t think with a similar mind-set to us and the wireframes have had to be bullet-proof. But our in-house development team (which is in a seperate location) has grasped the concept well. If the visual designers, the IA people and the developers were all sitting next to each other then I think you are absolutely right – there is less need for formal wireframes.

8. 8

   vanderwal on October 18, 2003 at 8:23 pm

   I agree with Erin, in that the make-up of the group one is working with dictates what tools to use. It would we be a detriment to throw out wireframes for those of us that still work with clients that are new to the whole process. The wireframe is still a great tool to have the client and content owners focus on how information should be structured on a page and how a user interacts with the site. I still have to state “it is not about anybody around this table, anybody we can touch, or anybody we can easy contact, the Web is for those we can not touch and are not sitting around the table thinking alike”. Needless to say, color and and visual design elements are what these clients find fun and they do not want to get to the information structure questions.

   Christina works in a great environment that may be mature enough to toss out the wireframe, but a global indictment of wireframes would do more damage to IA and having IA grow than any thing I can think of. Maybe a guide line should be written outlining what work environments needs which tools and which tools are not conducive to others. As always it still depends. As always we still need all the tools in our belts, in addition to the tools we do not have yet.

   I am continually amazed that there is such a large pocket of Web practitioners that do not yet grasp IA and its benefits. The structuring of information is lost on many. The environment Christina is in is an outlier on the chart of normal environments. It is also the type of environment many of dream of working in so we can move on to the next levels and make better products and sites.

9. 9

   vanderwal on October 18, 2003 at 8:27 pm

   I agree with Erin, in that the make-up of the group one is working with dictates what tools to use. It would we be a detriment to throw out wireframes for those of us that still work with clients that are new to the whole process. The wireframe is still a great tool to have the client and content owners focus on how information should be structured on a page and how a user interacts with the site. I still have to state “it is not about anybody around this table, anybody we can touch, or anybody we can easy contact, the Web is for those we can not touch and are not sitting around the table thinking alike”. Needless to say, color and and visual design elements are what these clients find fun and they do not want to get to the information structure questions.

   Christina works in a great environment that may be mature enough to toss out the wireframe, but a global indictment of wireframes would do more damage to IA and having IA grow than any thing I can think of. Maybe a guide line should be written outlining what work environments needs which tools and which tools are not conducive to others. As always it still depends. As always we still need all the tools in our belts, in addition to the tools we do not have yet.

   I am continually amazed that there is such a large pocket of Web practitioners that do not yet grasp IA and its benefits. The structuring of information is lost on many. The environment Christina is in is an outlier on the chart of normal environments. It is also the type of environment many of dream of working in so we can move on to the next levels and make better products and sites.

10. 10

    David Locke on October 20, 2003 at 6:24 am

    So IA uses wireframes to control other designers? Is that really the point? And, what affect do constraints have on creativity? Do they lessen creativity or increase it? Architects know the answer to that one.

    It’s funny that programmers are ditching methodologies, because they were taught that they don’t work. You end up with Agile processes, which are still methodologies, or you end up with just plain hacking.

    We hired an interface artist, not an interface designer and unfortunately for him he was an interface designer. His job was to change the color scheme of the week. Red this week. Green the next. Maybe the VP would go for Blue the following week. Anything to make the VP hacker happy. Heartburn!

11. 11

    christina on October 20, 2003 at 7:38 am

    I’d like to repoint to this fine article and most importantly in it, this diagram. Now I want to ask you, assuming your designers are competent (and in this market, there are plenty of competent signers to be hired, at least as many as IA’s competent in layout, in fact, most likely more) what does a wireframe do that this document does not?

    I can start the list– wireframes get people talking about layout before color, line and font are added which will make the page actually work. I’ve seen inverted L navigation that worked beautifully and inverted L navigation that failed utterly, simply based on how the global and local were treated visually. Why would one consciously choose to try to make a design work without the rich palette of tools a designer has?

    While I understand how one might choose to test a rough prototype of a design (a sketch, a very raw wireframe) even that gives me pause, having seen so many designer that worked not work, and vice versa once the “veneer” layer was added…

    Finally not much gives me horror as much as hearing an IA say wireframes are a major part of their value, or critical to their work (assuming they are doing IA as a pure role, with a visual designer as their team mate). The time you spend on wireframes could be profitably spent doing conceptual models, rich controlled vocabularies, task analysis, and so on… while a wireframe is you doing double work.. you do layout, then the designer redoes layout. What a waste!

    One alternative solution (I call the JJG solution, as he did this when he was big IA at metrius) is having the designers do the wireframes, since they are on the road to design anyhow, and hand off earlier.

    Another is do pencil sketches, which tend to impose less fidelity (though, again, still tend to seduce one into the act of design). We are doing this with one group and it has really sped us up remarkably, as well as improving overall quality of the products.

    Another is hire someone broad rather than deep who can do IA and interface design. Not all sites have to be graphically rich and not all sites need the practiced hand of a skilled designer as much as they need a skilled IA. And some just need someone with a bit of both.

    And finally there is Dan Brown’s document… tell me, what is it missing? Our Web Dev’s love it as they head toward semantic IA, as it suggests a list of importance a wireframe does not have as te choose how things should load. Our designers love it as it suggests hierarchy without dictating layout, and we’ll see how the product managers love it as we pilot it… but I have showed ti to a couple and they can read it and understand it.

    When I speak of wireframes, many people scream… don’t take my wireframes away! But I really wonder if they are necessary as a standard practice, or if the seduction of the interface, the ease of the veneer just pulls IA’s away from their important work, the structure of the invisible layer of structure, which is the secret sauce behind any easy-to-use website.

12. 12

    ak on October 21, 2003 at 7:02 am

    I believe wireframes are very important for content on the page, not what the design should look like. There are many times when I see a design that didn’t accomodate for the third level navigation (no designer wants to try to decipher functional specs and site maps).

    I use wireframes to make sure all the content that needs to be on the page is there. The designer looks at it and we TALK about how things needs to act. Our designers are free to do whatever they think is appropriate, as long as they don’t remove content from the page without discussing it with me.

    Wireframes also make it easy to show a client just what I meant by “subheading” or “summary” because it shows what copy needs to be written.

13. 13

    andrew on October 21, 2003 at 7:57 am

    Wireframes? Don’t get me started on *site maps* for IA documentation problems. Those damn things never look the same between two IAs, are never structured the same (Is a box a *page* or a *link to a page*? What’s an arrow, then?), and are very often hard to read by most stakeholders.

    I think Nadav’s right: to communicate properly you either need drasticly simplified gray box wireframes, or else you need drawings that verge on page comps.

    I’ve finally got a documentation process that I like, and wireframes don’t appear in it until almost everyone on the team is really just spilling over with ideas for how everything should look. Up to that point, we will have already made decisions about task flow down to a pretty detailed level. So once I do wireframes, it’s *primarily* as a visual design specification. Yes, there are additional interaction changes that happen in them, but there are no major decisions left about interaction at the start of wireframes.

    Hasn’t everyone had the experiece of a client saying “I really just like the way the wireframes look. Can’t we just use these as the visual design?” I’ve also had clients want to include wireframes as user documentation.

14. 14

    vanderwal on October 22, 2003 at 3:36 am

    I loved the Devil is in the Wireframes article, but I think we have taken different things out of that article. Liz’ points she breaks out of simplification, cut out details, and annotate relevantly gets us back to where wireframes began.

    In a current situation I am working with (and mentoring) a visual designer to restructure and redesign an intranet with 2,000 to 5,000 pages of content (depending what is left once house cleaning is done too). We are also working on a new site design for another client for a small Internet site. In both situations the clients wanted to focus on the visual redesign and have that drive the process. The visual designer was happy to oblige with excellent visual designs.

    We quickly found detrimental structural problems with content categorization, browsing structures (more than local and global navigation – still believing navigation is a poor term and really has boxed IAs into a corner, but that is another discussion). We went back to the wireframes, which we do in Dreamweaver so that they are interactive and we can build upon them, as well as content inventories and categorical structures. With regards to the Intranet the problem was it was an organic site that had second and tertiary level pages with their own formal browsing structures. We also had to accommodate senior level client and political appointees that want buttons or links to their pet project prominently displayed. Using the wireframes we ( the visual designer) and myself were able to replicate the problem areas, but also able to get logical structures that we could present to the client. The wireframes helped define the project so we could test the structures with the client to show the direction changes needed. The client and visual designer realized we had just save two to four weeks of work. We now have better buy-in from the client to work through restructuring up front and he understands we can not just start designing.

    In working with the new Intranet site the client had been working with another visual designer. Our group also manages clean-up to meet minimum standards and posting of pages. The client was trying to build their new site with out having an idea of what content they had or what they wanted to put under the buttons the designer had built for them. Each time the Webmaster asked for their content and refused to let us build their site with under construction messages or broken links the client would come back with a new visual design.

    We quickly knocked together a list of documents and their suggested content areas and put together a wireframe of the structure with very little design. The black and white representation made their content problems clear to them. The wireframe allowed us to not only tie the content we were given to the site structure in a half hour meeting, but pointed out problems with the layout that we needed to tweak to improve findability.

    Not using wireframes in our processes would be a huge mistake. Jumping to visual design with out wireframes can also mask problems that come out in the wireframe stages. A great visual designer can collapse some of these steps and I greatly agree that visual design can greatly correct problems and that just the wireframe alone is not a great tool. There are many visual elements line line weight, bolding, shading, color, etc that can help the attract the user to the information they are seeking and provide areas on the pages to scan for information. Given that these visual tools can not cure problems with poor grouping of information or local/global browsing structures that are too large or long. The wireframes can help choosing what type of local and global structures will be used as well as finding out quickly what information is above the fold for heuristic assessment.

    Many of the sites I work with we have found the users print certain types of pages with a fairly high frequency (user feedback is a great friend), which means we use the wireframes (in valid HTML) to test printing. The sites that have higher print frequencies we have move the local browsing structures to the right so that the content of the page and images are printable without being cut off.

    I can see not using wireframes in some situations, but I strongly believe having a simple wireframe to reference is very helpful in 95 percent of projects I encounter. I also believe being overly dogmatic about strictly following the wireframe is often detrimental to getting to the best solution.

15. 15

    vanderwal on October 22, 2003 at 3:46 am

    Christina, which Dan Brown piece are you referencing?

16. 16

    Javier Cañada on October 22, 2003 at 4:03 am

    Christina,

    You are not pointing at wireframes as a problem but at the actual separation of roles.

    I believe there is no doubt here on the utility of wireframes: they are a low cost way of defining certain issues, discussing and assure overall consistency. Better call them prototypes, because that’s what prototypes are for.

    The problem starts when we (as interaction designers) loose control on our wireframes and someone else applies visual criteria to serve other goals that are not ours: brand issues, values, etc. They are killing our baby!

    If we could be in control of typography, color, etc, it would be completely different. Right? After all, we are designers as well. Aren’t we?

    Then the problem is simple: wireframes are a diplomatic and consensuated way of splitting design between two different kinds of people.

    It is artificial. It is useless indeed. But since most of us don’t have enough visual skills, we are not able to do the whole thing, and we try to go as far as possible. The more skilled is the usability guy, the closer he gets to the “real design”. Therefore, the wireframe is the materialization of our frustration.

    We should all learn some design principles and do all the process. We could use prototypes for what they are meant for, and then have control of the rest of the things that matter.

17. 17

    Kelli Covey on October 22, 2003 at 4:29 am

    I think the artists where I work would freak if wireframes disappeared. In addition, the notations we include beside each one define the functions for engineering in order to code the page as well as the documentation needed for QA to test them. So, clients may have difficult grasping the leap from wireframe to design comp (and this is an ongoing issue that requires examples to aid understanding). But I don’t think it’s realistic to think we could throw out the wireframe altogether.

18. 18

    christina on October 22, 2003 at 7:44 am

    One more time, what if you did the prioritization, had a white board session with the graphic designer to discuss layout schemas, then showed clients sketches, then designs, and annotated the designs instead of wireframes?

    (Artists?!?!)

    I know some people think wireframes are the best web techinque (pdf)and I’ll admit to being a bit contrary when I suggest throwing them out all together, but I do think by really asking ourselves what are wireframes supposed to do and by asking ourselves is there a better way, we have a chance of improving our work.

19. 19

    Gene on October 23, 2003 at 10:08 am

    Interesting discussion. I wonder if Dan’s prioritized interface elements aren’t just another version of the “shut up and colour” problem that can be created by wireframes. In this case it’s “shut up and assemble my pre-designed widgets into a page,” and just a step removed from a high-fidelity wireframe.

    When I’m working with a good designer I try to make my initial wireframes quite loose and exploratory, since they’re really just a jumping-off point for discussion. Something like Dan’s document would be fine for this, too–basically, whatever starts the collaboration process.

    Later, wireframes turn into interface documentation, and then I think it’s important to show layout and placement of elements without all the filigree of the visual design. Though hopefully by that point a designer’s been involved.

20. 20

    vanderwal on October 24, 2003 at 10:01 pm

    I actually started with wireframing on whiteboards, when I was leaning on my communications background to layout newspapers, journals, newsletters, etc. The white board was a quick way to knock out ideas that would allow me to work through problem areas as my computer booted. I often would work through interactive components on whiteboards also. The whiteboards allowed things to stay simple, but also allowed others modify. I would often redraw the whiteboards in Visio. I found keeping the wireframes off the whiteboard allowed for more discussion and better ability for me to capture feedback and reasonings behind suggested modifications. The capturing suggestions often opened paths to solutions/problems no others had seen.

    I have since moved away from Visio to Dreamweaver or HTML text editors. This allows me to move from very simple (I do not like annotated wireframes, but annotations are in bulleted lists or spreadsheets) wireframes to rough prototypes very quickly.

Comments are closed.