Skip to main content or search

Understanding the Limited Value of Wireframes

Thursday October 13, 2005 / 10 Comments

I’ve spent the last year or so working on a large web app that’s quickly approaching 300 pages. It’s been a lot of fun, but I’ve come to one realization.

If at all possible, wireframes should only be used for very rough prototyping. HTML and code should be put in place as soon as possible, and wireframes should almost never be shown to clients. Wireframes are technical documents and should be treated as such. Show them to the engineering and creative teams, but not to your client.

Give your client something real to look at and touch and understand. You’ll both be on the same page a whole lot faster. That will naturally lead to better communication and a more successful project.

Why

This might seem a bit extreme at first, but bear with me. Despite weekly wireframe reviews for months, we’re still uncovering requirements from our client because we incorrectly expected them to fully understand the wireframes. They shouldn’t have to understand wireframes and it’s unfair for us to expect them to see what we see when we look at a black and white paper prototype.

Wireframes are clearly better than functional specs, use cases, and other forms of abstract requirements documents, but they are still too abstract for those not in the industry. Expecting anyone that isn’t technical to view a wireframe and understand all of the subtle details of how it will actually work is ridiculous.

Let’s take a look at some of the areas where wireframes fall short of communicating requirements and functionality.

  • Interaction – Wireframes cannot communicate AJAX or JavaScript changes. They can try, but it’s not going to work. The web is dynamic. Paper isn’t.
  • Flow – Wireframes cannot easily show page transitions. Depending on your choices, you could end up in several different places, or the same page might be used in several different flows.
  • Error & Confirmation Messages – It’s just not efficient to display every possible error message and the action or inaction that would cause it to appear. Error messaging cannot be an afterthought and should be addressed sooner rather than later.
  • Shared Elements – You will invariably be using or describing common elements that will appear on multiple pages.

Wireframes just can’t communicate these concepts clearly. Sure, you could litter them with callouts and explanations, but as soon as you begin relying on words to describe the experience, there will be a disconnect.

37signals may be receiving a lot of flack of how difficult it it to implement this part of their getting real concept on a project where you aren’t your own client, but I now firmly believe it can and should work that way.

Next, I’ll touch on how this can work in situations where you aren’t your own client. After the last year of wireframes and weekly meetings, I know this isn’t working, and I believe there has to be a better way.

Featured Stuff - Resources: Wireframes & Page Description Diagrames

Omnigraffle and Visio versions of the wireframe templates and stencils I use on all of my projects. There’s even a few examples included for good measure. More about Wireframe & Page Description Diagram Stencils and Templates

I agree. You have to be careful and thoughtful with what you show to the client, because they are not always privvy to the intricacies of the process. I’ve even had a client who wanted to keep the “Lorem Ipsum” text – he liked it as part of the design, and didn’t realize it was placeholder text. Now I only use live text or brief explanation blurbs.

Recently I’ve begun to rely Rails fairly heavily. It allows me to rapidly prototype an app, and virtually skip the wireframe stage. I can jump right from requirements to UI design to working out the functionality on real data. Ryan Heneise
Rails has kept me awake some nights, trying to figure it out and make it work, but wireframes almost 100% of the time are only beneficial to the developer, and what I mean by that is: By wireframing to thyself you better visualize the contents and the paths of workflow. I also agree with Garrett, I made the same mistake of showing wireframes to clients before, it usually leads to a 200% longer meeting in which the client leaves unhappy and confused. Bruno
Garrett, I agree to certain extent. The problem is that wireframes are cheap to produce relative to other deliveberables, and thus get used more than HTML or Illustrator mockups.

I don’t think there’s any reason why the client needs to see 300 wireframes, but they need to be shown enough of them up front so that they have a general understanding of the I/A, page/site navigation, page flow, etc.

And I agree, wireframes are really technical documents. I’m working on an app now in Rails where I’m the sole developer, and I’ve estimated the need for about 65 wireframes (scaled down from a realistic target of 75 or so), and I’m realizing that when I show these to the client, they feel almost drowned in information. However, I still find wireframes extremely helpful for my own development purposes, and the only reason I’ve scaled the number down is due to simple error and/or routing pages that I feel comfortable capturing solely in a scope matrix.

Honestly, I have only an introductory background in wireframing, and this is the first time I’ve been the sole person doing them, but my primary benefit of wireframes has been to get an exact inventory of the screens that I need to build, as well as the application code that I need to build to tie everything together. All I know is that I love doing them, and as some who doesn’t have a background in CS, and is more of a jack of all trades, it helps me understand the logic of the code better.

In general, though, the lack of doing wireframes, or heavy upfront planning withinin the 37s Getting Real process is one of the few glaring examples of where I think they get it wrong. It might be nice for those working in light weight frameworks such as RoR, or doing strict product development. But for those of us doing client consulting, it’s been my experience that the good clients want documentation.

I agree with quite a bit of what the 37s espouse, and thanks to them, I’ve got job coding Rails. However, I don’t agree with everything they do or say.

Anyhow, longer post than I anticipated, sorry.

p.s. For anyone thinking about doing wireframes in Omnigraffle, the upgrade to Pro 4.0 is a necessity, not an option, especially if you’re coming from a Visio background. Kyle
Kyle – I’m not advocating building without wireframes, and I don’t believe that the guys at 37signals are either. They serve as a great internal tool for rough drafts.

What I am saying is that’s where it ends. Trying to create high-fidelity through wireframes is a dead end. With some exceptions, after a wireframe has been turned into a screen, the wireframe shouldn’t be updated or used again. Make the changes to the screen. Don’t fall back on wireframes.

Documentation and related investments should exist directly in the code in the form of comments and refactoring. After projects go live, nobody every touches the documentation again. However, somebody somewhere will definitely have their hands in the code. I’d much rather have a very well put together code base than hundreds of pages of abstract documentation.

I feel that it’s a problem of mis-placed priorities. The investment should be in the code and the parts that people will use, not in an unecessary and irrelvant document that nobody cares about. Garrett
Hey, Garrett, yeah, I definitely don’t think wireframes should be reedited after you already have a screen up and running, waste of resources, just iterate over what you have in place. However, I think the only area that we disagree is the ability to make high fidelity wireframes,

And I definitely agree regarding comments in the code, etc. However, when you’re working on 1/2 million dollar plus projects, I tend to prefer soup to nuts documentation. And perhaps that’s where I’ve misunderstood the 37s Getting Real process.

As a point, the last project I was on prior to my current one, was a 3/4 of million dollar a year contract that basically fell in our lap due to mismanagement by the previous people handling the account. The only documentation we had available to us was the comments in the code because the previous group either didn’t want to share it, or didn’t feel good documentation was necessary. Add to that the fact that their code comments weren’t all that helpful, and the system was built on a legacy architecture, a bit more documentation definitely would have helped.

Needless to say, it ended up costing the client a lot more time and money to have us go through and dissect the applications architecture and nuances.

I think I’m getting off point, though, and in reality probably agree with you more than not. My position, however, is that I would rather instill the need for good documentation into my employees/coworkers than worry about the quality of our docs continually sliding over time. To me, it speaks towards my/our professionalism, and more importantly, an unshakable client focus.

That all said, I had a documentation nut drill the need for it into me at the start of my career, and it was a very good experience in terms of successfully meeting deadlines while using very cool technology, and making clients very happy, so I realize that I’m a bit biased towards heavy documentation. Kyle
Garrett, as usual, you’re a freakin’ genius who says things that I think in my head but don’t have the cojones to put on the screen.

I like wireframes because they get me strapped to an interface so I can start developing and stop dreaming what it “could have” looked like. But then I hate wireframes a month down the road when I get a new idea and it doesn’t work with the approved ‘frames. But then I remember how I’m getting paid 20% less than I should, smile, and say the hell with it I’m gonna do what’s easiest ;) Mike
I don’t know guys. I use wireframes as a second step in the process of specifying the content and functions needed for the web site. (First step being the structure of the highest level, like we will have this and this section on this site…).

Of course I am talking here about smaller sites – for example this one: http://www.nordicchamber.cz – where I spend something like 12 hours on all the wireframes.

But back to the point: I cannot imagine not showing the wireframes to the client during further consulting the specific of the content… I think it have to end up in graphic proposal where the client will tell you: Yes, we like it, but now looking on it we think we need big banner here for this and then here is this other section…. You know what I mean.

So for me, wireframes are indispensable tool in clarifying the content as early as possible. Jan Korbel
I agree with Mike that you are a freakin’ genius that says things I do not want to hear and yet I cannot deny, but I’m not sure about this one. I understand that no one particularly likes using wireframes to checkpoint front-end designs with clients, but for large-scale Web development projects, I’ve not encountered a more functionally and financially effective medium. I look forward to the fruits of your search for that “better way” that even I can admit must exist. Keith
Good article G man. Justin
Great piece. But where’d you go man? Jeff Yamada

Comments are closed for this entry.