What’s Wrong with Wireframes?

After an extensive search, I find I have not written this down (at least in a blog– I have referenced it in talks.)  Now, most of these points can be/have been addressed in one way or another. But one might ask yourself, what other deliverable is as criticized as wireframes, and could there be something better?

Firstly, wireframes emasculate the designer. Wireframes have often had a place in multi-disciplinary teams where the graphic designer had come from print, and didn’t really understand interface design. The interaction designer came from software and was making ugly terminal-esque interfaces. So in order to make sure the end result was palatable, the interaction designer (or information architect; I’ll use this term interchangeably in this post) would make a pig, and then the graphic designer would put lipstick on it.  This was 1998.

But as designers got savvy to interface, they started resenting the restrictions on their ability to creating compelling and useful designs. After all, a designers toolkit is essentially font, color and layout. The web browser stole the first, if the IxD steals the third they are relegated to the sorry position of kid with crayons handed a coloring book. Think hard of the last wireframe you saw. Didn’t it look a lot like a paint-by-number, with only the numbers missing?

Now there is a new fresh crop of kids coming out of schools like Carnegie Mellon who are well rounded and can do both jobs, as well as a crop of old dogs who have worked hard and learned the principles of graphic design (if you can learn it in two years in college, surely some IAs and IxDs have picked it up). We should ask ourselves how often we need separate roles for interaction and interface design. Then, when we do need the deep knowledge the two specialties provide, we need to ask how can we create a process that allows both to fully utilizes their skills.  Getting them to team up, do whiteboarding, have the designer do early sketches, have the IA use balsalmiq or even– gasp!– paper to express their thinking are all fine solutions.  Even keeping wireframes, but having the designer do them can help, since it moves the job (layout) to the person with the skill (graphic design).

Secondly, wireframes create design lockdown too early. I had a theory about the birth of wireframes. It’s cynical I know. I imagined an agency in the ’90’s, who loved the idea of IA/IxD (since one more person means one more person to markup). But they needed deliverables for the client to sign off on (and thus bill for.) Well sitemaps were big and impressive, and so were flows, but no one understood them. What could the client really dig his teeth into in the early phases? Early versions of the design! Voila! and a billing cycle was complete.

Let’s be honest. The wireframe shouldn’t reflect the final layout of the site.  Because there is no color and type treatment, you have to do goofy things to get elements emphasized like put a box around it, or make the type bold. You are essentially designing with two hands tied behind your back. If the wireframe was just for you, you might be picturing red accents, or iconography, or georgia 30pt.  But once you have to show it to your client or your boss, the wireframe has to communicate and without color, image and font it doesn’t. So you do goofy things, and dang it if those goofy things don’t make it to the live site! We’ve got a million sites out there with little boxes around each piece of content like the content was a cow that, if not fenced in, might try to mate with the form fields.  I think wireframes and blogging tools are the two worst things to happen to web design in the last 5 years. (more on why blogging is bad for design later…)

Lastly, wireframes create a false sense of security about the completeness  of the work. Wireframes are not interactive, but they look done. Most engineers are annoyed by wireframes, unless accompanied by usecases because wireframes typically don’t reflect every single state and error case possible. Most would rather just have a prototype. Oh, I know your engineer loves your wireframes.  Have you ever given him a prototype? Did he scream and say, please give me wireframes so I can go back to making up the functionality like I did before? The boss has signed off, yet the web dev is rolling his eyes at you because the wireframe doesn’t represent load order. I know many folks out there heading for the comments field will list the eighteen ways they have figured out how to document these things, and I don’t want to stop you because many many shops can’t give up wireframes. But I do want to encourage you to talk to your engineers as if they were a precious end user (because they are, of your documentation) and find out what they need.

There is another downside here, which is hard to  put into words. I’ll try. Interfaces either feel right or they don’t. Your mouse either slides naturally to the correct button, or it slides naturally to the wrong one. There is no wireframe on earth that can help you get the feel right. Because feel is made up of many elements, including color (red means bad) , type (8 pt means legalese), and interaction (dialog box asking “are you sure means” committing an action). The faster we get to using all the tools at our disposal to replicate the final experience, the faster we’ll know our design stinks. Or is intuitive.

I haven’t heard much lately about why wireframes are so awesome. I know they are incredibly useful as a thinking tool. I can’t work through an idea without getting out a pencil and scribbling out some wireframes on a pad of paper.  I’m not sure they are good as a communicating tool.  The feel like an odd leftover from a day when sites were static and you could make a sitemap on one piece of 8 1/2 x 11.

Anyhow, now I’ve written something down, go to town. The comments are your playground. I’ll try to swing by and approve regularly (I had to turn off autoapproave because the russians find my site way too delicious.)


See this diagram as well 

Mike Monteiro on why wireframes fail as deliverables


Add Yours
  1. 1
    Livia Labate

    I think you’re right on about wireframes use being related to how skill sets are distributed in a team. If you still have the print designers doing your UI styling, you better make those wireframes (but yeah, very 1998).

    I like how you frames this in historical terms not in absolutes. It would be enormously helpful if people stopped to reflect on this and consider if it still makes sense to make wireframes in the context they find themselves now (not the context in which they started to work and how they’ve honed their skills).

    I am surprised that something like Page Description Diagrams are not more popular (http://www.boxesandarrows.com/view/where_the_wireframes_are_special_deliverable_3 ), but perhaps that’s a symptom of the legacy need to determine layout for the visual designer.

    Another deterrent for an evolution beyond wireframes is for those who have really mastered it and have not pursued prototyping instead, it’s a different skill that needs to be acquired. And since interaction designers and information architects are not unique little snowflakes, they are also afraid of change.

  2. 2

    “…the wireframe has to communicate and without color, image and font it doesn’t.”

    Sorry, but that’s just not true.

  3. 3
    Brad Nunnally

    Awesome post Christina.

    Wireframes filled a very necessary gap when UX design started becoming an accepted practice in software development/website design. However, with all the great tools we have today, and the shared language between UX designers and visual designer there is little excuse not to create something more robust in the form of prototypes.

    Time to put wireframes in the history books of user experience/design and use much more appropriate tools.

  4. 4
    Fred Beecher

    Thank you for that very well articulated argument. Now, let me attempt to articulate my argument equally well.

    On the emasculation of designers… Visual designers have a different and very valuable approach to site design than UXDs. While I’d say UXD is definitely a creative discipline, it’s maybe more analytical than visual design is. Visual designers have ideas that come from many different places, and more ideas are always better. Even if I were to learn to do graphic design myself (which I’ve considered), I would still want someone else with completely different ideas there so that we could come up with better ideas than either of us could alone.

    On premature design lockdown… In the early days of doing IA, I did experience a lot of resentment, confusion, etc. on the part of the visual designers in relation to wireframes. But after enough collaboration, enough instances of actually being okay with them altering the layout, the IAs proved that we *contribute* to the design rather than *dictating it.* In my current situation, I work with different visual designers on nearly every project and I make sure they understand that it’s our responsibility to create the site *together.* To be honest, it’s not always enough but I do what I can.

    On the false sense of security… Yes, this can be very true. While I now prototype on every project (thanks to Axure), my prototypes are essentially wireframes that move. But even before Axure I would *never* just hand over a stack of wireframes to a developer. I always spent a lot of time designing and diagramming and walking developers through the flow. The flow diagram would be the first page of a stack of wireframes that described each page (for page it was in those days) represented in the flow.

    I totally get you about the feel of a design too. That’s definitely something you can’t get in a wireframe, but through collaborating on a prototype with a visual (or industrial!) designer you can really go a long way to figuring out whether it’s there or not and how to add it if it’s not.

  5. 5
    Andy Polaine

    I completely agree with the idea of wireframes being a thinking tool, much the same as blueprints in service design too. More useful for internal thinking than communicating to clients (something that Jesse James Garrett said to me recently too). But I think you do an injustice to both interaction design and also interface designers in your post. The colour the numbers scenario really shouldn’t be the case. A wireframe is like a storyboard or script – they don’t replace the writer, director or cinematographer, but help them all communicate about the same thing and develop it further, adding their own skills.

  6. 6
    Jonas Persson

    Interesting post. I’m often creating both the UX design and the graphics in projects. We use clickable wireframes made in OmniGraffle to
    1) get an early feel about the flow of the site
    2) have something that the developers can look at when creating the technical infrastructure

    I’m not really sure what other tools would be appropriate for this, but it would be nice to hear how other tackle this!

  7. 7

    I really like this. Ironically, when looking at things historically (only talking a few years back) point two exists. The big advantage of wireframes early on was they were relatively low fidelity, no color nor ability to click. This low fidelity put the focus on content, structure, layout, and ensuring all the content objects that should be on the page were accounted for in the drafting stage. This low fidelity provided the context that things were still in draft mode and still subject to change.

    Oddly, I also see wireframes getting turned into visual mock-ups by those who have done the wireframes and are not visual designers. Most often the visual designer (at some point) was swamped with other projects and the fuzzy line between wireframes and moving up to increased fidelity was ignored. Once things start edging in on this stage it is far better to start making things real as a prototype that functions.

    Andy Budd this morning pointed to Andy Rutledge’s where “Wireframes are Concerned” (http://www.andyrutledge.com/where-wireframes-are-concerned.php), which brings up similar points.

    I am quite happy to see this popping up as it really needs to be considered. Wireframes are a great tool in the toolbelt, but like everything knowing when they are good to use and their limitations is incredibly important so it is easier to know when to reach for that tool and when not to.

  8. 8

    I’m tired of this distinction between “designer” and “information architect.” It’s as if there’s this stereotype “IA” who’s a total left-brain person who thinks in straight lines and shades of grey, and who’s job it is to hinder the creative process which only “designers” or “art directors” practice.

    My background is in graphic design. I’ve been an interface designer, and I’ve also done a lot of coding too. My current job title is information architect, but I’m really neither one or the other in an exclusive sense. I’m part of a team that builds websites and interactive user experiences.

    This is definitely a touchy subject and I want to say more, but I’m going to stop there because I realize I am reacting to the post rather than taking my time to think it through more objectively. Besides, I have to get on and finish some wireframes and after that I have to get to work on a new project in my, gasp, sketchbook.

  9. 10

    You have got an intensely design-centric viewpoint, my friend.

    Jason Fried wrote back in 2005 (http://37signals.com/svn/archives/001050.php) about how functional specs are ‘evil’ for developers. But you argue that functional specs should go that much further: just turn them into prototypes so developers don’t have to think… they can just build. (!)

    Well, wireframes were created so designers who don’t “get” information design wouldn’t have to think; they could just focus on what they do best: visually engaging users.

    You don’t like forcing designers to work within the restrictions of a wireframe… but you have no problem forcing developers to work with your prototypes (which equally restrict the free thought of expert developers).

    It sounds to me like wireframes aren’t the problem; a lack of collaboration is the problem. Handing ‘documents’ of any kind over the fence is a problem — be they wireframes, copy docs, func specs or prototypes.

    You’d need a lot less documentation if you just worked with greater agility.

  10. 11

    Thoughts on Axure/iRise-type tools?

    Seems to me they’re kind of midway between wireframe and a full-on html prototype (yeah, I realize iRise is supposed to be able to bind data…).

  11. 12
    Andrew Hinton

    Part of the problem here is the semantics around “wireframe” and the assumptions people bring to the artifact.
    I assume you have no problem with sketching before going to prototype. It just makes sense.
    I’ve always thought of wireframes as part of the preliminary sketching, and rough descriptions of the particulars one finds in one context or another (the things that are being linked to each other in the overall architecture).
    But that only works well when I’m collaborating with whoever will be coding a prototype, plus the content strategist & someone with a solid background in the visual design aspects (or whatever combination of people covers those roles — I suppose I could feel bad that I do not personally cover all those areas of expertise equally well, but I don’t).
    Most of the flaws you point out really have more to do with how people work together than the “wireframe” itself — which is just an easy whipping boy.
    I suppose I’m saying — I agree we should question the fetish status the community has ended up giving to “wireframes” and what that term assumes/represents. But going straight to prototype doesn’t sound like the solution to me.
    You have to look at which skills you have on hand, in whatever combination among a given set of people, and then figure out how *that* group of people needs to work to get the job done.

  12. 14
    Wireframes are good for flows

    I use wireframes for capturing initial thinking or accounting for what needs to be on a page but my no means do I feel like I’m a slave to it. As the final design / interactive pieces are implemented; there are opportunites to make the experience even better that you wouldn’t otherwise see at full fidelity.

    For instance, you can keep a user on a page to look at products or even to make updates to an account without the need to navigate to another page. You can’t see how you’re going to execute that from a wireframe. You can make an attempt to capture rich interactions with modals or whatever but until you design it out, emotionally; you can’t predict what it’ll be like until you see the final pieces working together. It’s like real painting, not paint by numbers.

    I just finished a project where there was pre-work done with prototypes that was sloppily put together and tested with users. I think I ended up changing 70-80% of the original thinking once I started to design the emotional experience for it.

    The big takeaway from this article is… the hybrid designers can get you get to your final destination sooner, with less rework and can help guide the thinking up front. Wireframes are heavily relied upon by traditional UI designers and are void of any emotional thinking and are more about the mechanics of solving a problem. They are a great way to work collaboratively with cross functional groups to agree on base principles and should be viewed as a point of reference. It’s not a set of instructions to hand off to another team and say. Go build this.

    An easy way to think about this is, use wireframes to evolve your ideas that probably started out on a napkin. That’s how raw it should be viewed.

  13. 15
    Brett Lutchman

    Wireframes do not have a date or time period on them. From the beginning of time, people sketched out their plans to create and/or build something whether it was painting on walls, drawing lines in the dirt or sitting at a drafting table to flesh-out blueprints.
    Wireframes are as much a part of the design process as graphic design is. To me, not having wireframes is like giving an architect a day off and letting the interior designers make plans on how they want a house to look like when they themselves don’t even know what the house should look like.
    As a graphic designer turned IA, I know that the fulfillment of my craft was met when I understood that graphic design had to be tailored to serve business needs rather then artistic expression.
    I do not look at wireframes as restricting graphic designers, I look at wireframes as liberating business needs for the client.
    If it’s one thing that I can hang my hat up on at the end of the day, it’s that clients are more interested in business results then pretty pictures.
    When a building architect crafts up a new schematic, the builders who receive this plan know exactly how to read and interpret it. I think that this is where the disconnect is between architects and designers.
    Builders don’t go back to the architect (if he knows what he’s doing) and tell him what he should have done. The architect was hired by the companies to design and represent a specific brand of complexes. Even when an interior designer is hired, a true and professional interior designer has the discipline and expertise to work within the confines of their surroundings. They are not hired to complain about the architecture, they are hired to work within the architecture. They are free to operate within the parameters that have been set before them. And let me say this, if the designer is good, they know how to make a small room look bigger, a room with no light look brighter and a room with a low ceiling look taller.
    Graphic designers need to wise up and be professional about what they are working with. It’s easy for designers to design with no parameters, they’re eccentric, that’s their job.
    There is no way I’d ever go to prototype without wireframes. I have been around for over 20 years in the design field to know that basic schematics and high-level parameters need to be in place.
    I think the real issue here is communication.

    I have taken an extreme view on this subject and I know that Christina is not saying “No wireframes forever”. For me, the decision making process is too easy as I tend to be black and white rather then grey. Thats just the way I think.

    Like all decisions, and design issues that arise, break it down to its simplest of terms and do what works best for your process flow, your team and your clients.
    There is no 1 right answer, only best practices that work for you on a project by project basis.

  14. 16
    Nick Finck

    A wireframe is just a hammer in one’s toolbox. They come in many different sizes and shapes for many different tasks. Low fedility, high fidelity, XHTML wireframes, pencil sketched wireframes, Photoshoped wireframes, annotated, specification wireframes… you name it.

    You don’t need to be an IA or UX professional to create wireframes. Our Creative Director creates wireframes. My mom can create a wireframe. Knowing when and where to use wireframes or not is important and that takes understanding and experience. Likewise, placing a box in a wireframe takes seconds, knowing where to place that box and why takes years of experience.

    I am not one for others telling people what they should or should not have in their toolbox. Nor do I appreciate it when someone oversimplifies someone else’s role and skill set by saying such things as “its all just design.” It is, but all of us under that grouping have very specific skills and expertise that simply doesn’t carry on to the generalist all that well. We should embrace this, not try to eradicate it.

    Lets put the nail in the coffin on this one, shall we? Wireframes are just as valuable to our process today as they were in the early ’90s.

  15. 17
    Jay Fienberg

    I had just been writing a post about why wireframes are awesome — I’ll post a link if I get time to finish it soon.

    But, I think it’s smart to recognize that any tool or technique one uses (or fails to use), in the wrong situation, could: emasculate the designer, cause design lockdown too early, or give a false sense of security about the completeness of the work.

    I’ve seen literally all those things happen because a team DIDN’T use wireframes. That is, specifically, wireframes could of saved the day. But, the day needed saving because the team’s process wasn’t right from the start.

    A good process defines whether or not (and, how or not) wireframes are useful. If wireframes define your process, there’s a problem with your process, not with wireframes in general.

  16. 18
    James Nutter

    I am all for the industry moving forward and coming up with various “innovative” ways to approach software, hardware, and service problems. But if wireframes along with effective communication work for your team, then I think you should go with what works for your company, and if you are able to produce a product or service that matches the project, user, and business goals then you should stick with what works.

  17. 20
    Catherine Conoley

    I am a UXer and designer. I play both cards, all the time. My wireframes sure as heck DO NOT replace design, nor inhibit – unless the designer is one of the walking dead.

    Like Andrew said,it’s what kind of a team you collect, and who wants to do what with whom. Who will step forward and bravely push the creativity ball.

    It’s all about time: for my client, project manager, my designer, my developer.

    The client throws their jumbly mass at me, and I make sense of it, so my team doesn’t have to spin their wheels and do mass rounds that don’t cinch up. And yes, my team depends on me to wade through most of it, so they don’t have to. Sometimes my WFs carry a huge load and become the spec, even w/o my intention. They make for a good place for everyone to add, though.

    Yesterday a design mate called me to his desk, and we blew through a client’s email that was bah-LOATed with mysterious layout requests. I scrawled on scrap paper, while we compared the current site, a mockup, and the bloat. Things were revived within 30 minutes.

    I admit, I’m getting better and faster, via this example. I want my wireframes to (slightly) tame AND free those wilderbeasts within. So we can celebrate creativity to the max. How 1998 of me to say that…to the max…where is my scrunchy?

  18. 21

    I believe Brett Lutchman & Nick Finck nailed it. As an art collector who comes from a family of architects, I know that on a very deep level, that there needs to be some order in place or at least a holistic sketch as to where elements will be placed. I love Brett’s example with the interior designer. This is indeed true for all designers in one way or another. A sculpturer is limited to the slab of marble he has, a painter is limited to the canvass she has, an industrial designer is limited to the area on a car dashboard when designing and add-on like a smart phone holder.
    Information Architects are not only digital strategists, but they are designers as well. The problem comes when an IA is too anal about their blueprints and wants to keep everything on lock down, and the designer is a free-spirited loving nudist who wants to express themselves. IAs are becoming more and more sensitive to graphic designers, and designers are slowly learning the business values and logical placements from IAs and BAs. But if I had a business had had to choose 1 side in particular to represent my objectives, I would fall on the side of the wireframing IA. At least that way I can see my business values being represented in black and white.

  19. 22

    I like this post because it causes one to really think about the web design process and how team members work together during the design and development process (or don’t work together, as is the case for many project breakdowns). This post not only sparks the many discussions we see in the comments, but helps people reflect on the effectiveness of their current processes and if they should modify their approach.

    Of course, I think wireframes are good, but they need to be approached and created with the right balance of contributions from designers and IAs – if they happen to be separate roles. Wireframes also should not be the end all, be all of a design. They should evolve into interactive wireframes or the more detailed prototypes mentioned. This evolution identifies areas that should be modified prior to final development and allows teams to test and share interactive experiences with end users and clients. You’re right, clients don’t fully understand what a wireframe is and what the final product will actually look like, but it is a blueprint on the path to final development.

    As a few commentors have mentioned, it is important for the client, project liaison, IA, designer, and programmer to collaborate together to ensure that they take into account the client’s strategy and project goals and brainstorm content, pages, and layouts that will meet the client’s needs.

  20. 23
    OD Ntuk

    I am a graphic designer, UX developer, and information architect so I understand all the angles of what different users are looking for. Instead, of directly commenting on facets of the article I will instead write a short article on how to make wireframes work.

    How to Make Wireframes Work.

    Section 1: What are wireframes? What should a client expect?
    It should always be made abundantly clear to a client that wireframes are simply an interpretation of what the layout “can” be. The purpose of a wireframe, in my opinion, is simply to let designers or coders know what content should be present on a particular page and not to restrict where it should be placed or what the template should look like in regards to the header being here, the logo being there, or the color being this or that. In my wireframe docs I add this disclaimer in the footer: “This diagram does not represent the final structure, design, or copy.”

    Section 2: The importance of user studies.
    To fine tune a wireframe there should be user studies to definitively figure out where the content should be laid out on the page. Nobody knows what a user wants or needs till there are user studies. A designer may think something makes sense over here, while a developer thinks it makes sense over there, and an IA thinks it makes sense somewhere else. User studies can be done first on wireframes before they are done with graphic comps, or a prototype. User studies should be an iterative process through the life cycle of a project instead of when it is complete. Failing to perform regular user studies can render the work that all companies involved useless when a project is complete because it is far more costly and time consuming to go back and fix mistakes.

    Section 3: The importance of annotations
    Diagrams are never enough to tell the full story of what is going on in a wireframe. Developers need to know what functionalities are supposed to happen and where. With form fields, for example, information such as what fields are required, what happens when the form is submitted, or what happens when there is an error, and such need to be provided. Far too often IAs simply come up with a diagram but do not do enough to explain the full life cycle and flow of information. It is important for IAs to meet with the developers and go over wireframes to make sure all their concerns have been met.

    Section 4: Bring wireframes to life
    In addition to static graphic wireframes it is quite helpful to create wireframes with full functionality. In areas of a wireframe where functionality is usually lacking such as in cases of AJAX interaction I typically code the functionality so the client can see the wireframe with all the bells and whistles such as pop outs or scrolling effects. This is particularly important for clients that do not have UX coders as it allows the developers to pull the code and integrate it into their framework without having to hire an outside resource for additional help.

    Section 5: Variety is the spice of life
    Clients like options when it comes to the design from the wire frame. I typically provide clients with 3 to 5 comps to choose from. I usually do one on my own then hire freelancers to do their interpretation as well. I limit the design to the home page first and allow the client to pick and choose what they like from the comps to create a final comp before moving on to other pages. I believe this is the best way to solve the emasculation feeling of designers as I make it clear to my designers just design what you feel loosely off the content provided as all I care about is that the necessary content is there.

    Section 6: Serve the client
    As a consultant it is our job to serve our clients to the best of our abilities. We need to let them know what their expectations should be with wireframing i.e. this is not a graphic comp but simply an interpretation. We also should let them know the importance of user studies to affirm the wire frame ahead of graphic design, or development. Furthermore, we need to let them know the importance of iterative user studies through the life cycle. Some clients will not see the need for such work but you should feel comforted that you at least mentioned it. We also need to offer the client options to help with the project as I mentioned above with the 3 to 5 graphic comps, or a prototype version of a wireframe or the full wireframe package. Different clients have different budgets so it’s nice to include options for different packages so they can squeeze in work within their budget.

    If you would like to reach me you may do so at odntuk[at]gmail[dot]com.

  21. 24
    Jason Wishard

    First off, Nick couldn’t have said it better.

    My theory is, at the end of the day, everyone has an agenda for the tool they use or push in their organization, community or on their clients (if a consultant). I’ve had a wide range of experiences with delivering wireframes or even fully designed screens. I think any tool we use to convey a final product can either destroy it or make it stellar. In the end, I find it’s the practitioner, not the tool they use, that makes the final deliverable, whatever that may be, really sing to the stakeholders. If you are a poor communicator, bad designer or lack in the areas of polish on your final designs, you will fail. It can even be something as simple as whether the stakeholder likes you or not.

    I think blaming something that can’t explain itself or is only as powerful as the person using it to produce things, is passing the blame for either a poor process, bad designer or a once bad experience on a project turned into a blog post.

    Again, I like what Nick said and think the needling of tools is getting old. I think any tool holds value as long as it successfully communicates an idea or set of ideas, through a process, to a final stakeholder.

  22. 25
    Craig Kistler

    “Wireframes are just as valuable to our process today as they were in the early ’90s.” Completely agree with this thought.

    I get tremendous value, on a daily basis, in using wireframes as a tool to communicate ideas with business owners, designers and developers. I always would do a wireframe (high or low fidelity) before tackling a prototype. I’d argue that jumping into a prototype without a good understanding of what the prototype should do and how it plays within a current site is as problematic as placing too much weight on only a set of wireframes.

    And from my experience in both being a designer and working with designers I’ve never gotten the sense of a wireframe being emasculating.

  23. 26
    Sandy Marsh

    I think many in our field merely define “wireframe” too narrowly. If you think of a wireframe as just a thought/plannning tool, it can take shape as anything from a) a sketch on a napkin to z) a prototype – a moving wireframe.

    With each project, our team asks ourselves “what is the best thought/planning tool for this project”? Is it a pure branding assignment that can get by with just a napkin sketch? Is it a slightly more complicated page layout that can be collaboratively “designed” (IA + designer) and then annotated on the comp for the engineers? Is it an experiential/highly interactive interface that would benefit from a multi-discipline prototype? Or is it a complicated shopping process or application that needs upfront engineer/design/IA collaboration and a full-fledged wireframe? Also, if it’s going to usability testing pre-launch (and we hope with all our might, every time, that we can convince our clients to do so), what type of “wireframe” will get the point across to the test participants?

    I agree, wireframes in the traditional water-fall process sense are an outdated way of communicating ideas. But, there’s nothing wrong with wireframes themselves. What’s wrong is to perceive wireframes narrowly or to work in discipline isolation or a rigid process.

    Be free and wire.

Comments are closed.