He was referring, of course, to wireframes, though at the time we called them page schematics. We’d been burned too many times, and it started creating a rift between the visual designers and me. A wireframe, as you probably know, describes the contents of a web page by illustrating a mock layout. Usually wireframes are rendered in some kind of drawing program, like Visio or Illustrator, but can also appear as bitmaps or even HTML.
It would have been easy for me to resent the directive. After all, I’m an IA, that’s what we do! But I could see the value in his suggestion, particularly since I’d experienced conflict on projects where I’d trod a bit too heavily on designers’ toes.
The conflict arose after clients had seen the wireframes. The layout, even explicitly caveated, would set their expectations, and they did not appreciate screen designs that strayed too far from them, no matter how carefully crafted. Clients also struggled to talk about information priorities, taxonomies, and functionality. Placing these concepts in a layout made them more accessible, but our conversations were too tactical, and their feedback had more to do with design than with structure.
We tried using wireframes as a strictly internal tool: no client viewing allowed. But as much as a wireframe helped designers visualize the functionality and interaction of the site, it cramped their style. Designers who stuck close to the wireframes did not exercise their creativity, and all our sites started to look the same.
These are the two main risks associated with wireframes: client expectations and designer innovation. (There are others. See below.) While strategies exist to mitigate these risks, they are not 100% avoidable. When the creative director asked me to “take design out of IA,” I had to make a choice:
I could pursue risk mitigation strategies, learning how to set client expectations better and work with designers to avoid compromising their creativity.
OR
I could develop a different approach to documenting information architecture, one that would avoid these issues completely. Devising a way to communicate issues that sit squarely in my court means no more conflict with designers over client expectations or layout. Such an approach would also force clients (and designers for that matter) to talk about content, priorities, and functionality —the issues we needed to address in early stages of the project.
The first option felt desperate, as if I were the little boy trying to plug the dam with no end in sight to the number of leaks. (In college, I took a class in social ethics. The professor, Gary Comstock, once said that if people are fighting over pie, make a bigger pie.)
It was on the redesign of USAirways.com in 1999 that I decided to try a different approach. After building a site map, which described the relationships between the web pages, I created the first “page description diagram” —a bigger pie, as it were.
In a page description diagram, the content areas of the page are described in prose, as in a functional specification. The content area descriptions are arranged on the page in priority order. Typically, I will define the horizontal axis of the diagram as the page priority. Thus, content areas described on the left side of the page are higher priority than those on the right side of the page.
 Page Description Diagram Mock-Up |
 Page Description Diagram Mock-Up with Component Layouts. Click to open a high fidelity PDF of diagram. |
With this approach, the diagram represented the two main issues: priority and content. I found that I could include layouts of individual content areas to show, for example, how the “check flight status” form might look. These mini-layouts helped our client visualize the interactivity, but did not lock the designer into any particular approach. Our conversations with the client focused on the nature of the content and functionality and the relative priority of the page contents.
On this particular project, the art director appreciated the approach. He found he could focus more on creating a synergy between the brand and the functionality, rather than being forced into wrapping colors around a predetermined layout. At the risk of speculating on his thoughts too much, I wonder if he had to spend less effort than he would have with a wireframe, which predisposed him to a particular layout.
The page description diagram, by demonstrating priorities and providing a context for the content and functionality, gives visual designers the information they need to create an effective layout. On any given web page, a piece of information can have more or less visual weight depending on the use of color, contrast, typography, and position. But these are the tools of a visual designer, the fundamentals of graphic design, and no business of the information architect.
If a project requires an information architect, the scale of information must be vast. Without a person who understands the nature of the information, other people on the team would spend their valuable time trying to get their heads around it, preventing them from focusing on their own tasks. Information architects who have to worry about layout are distracted from their tasks: defining functionality, content, and structure.
Ultimately, designers are paid because they are good at thinking about visual relationships. Presumably, an information architect focuses on relationships among information, categories, and content, not among shapes, color, and contrast. The page description diagram is a tool to allow designers and information architects to stay comfortably within their own realms without compromising communication.
(This idea, of course, reopens the “defining the damn thing” discussion. Perhaps some definitions of information architecture include page layout, but as a creative director who must consider the interests of both architects and designers, I need to draw a discrete line between the two.)
Whenever I show a page description diagram to designers, they love it. It provides more information without compromising their processes. Information architects, on the other hand, have mixed responses. Some latch onto the concept, eager for some relief from common project problems. Others do not see value in the approach, perhaps because they have not faced the same issues, or perhaps because they have associated their craft with wireframes, they cannot conceive of one without the other.
Page description diagrams do not have to replace wireframes. Indeed, if we are to grow as a craft, we must find additional means for communicating information architecture ideas. Just as laptop computers and desktop computers do similar things but are used in different situations, wireframes and page description diagrams can also peacefully coexist as useful information architecture tools.
 |
| The Pros and Cons of Wireframes
These lists originally appeared on the poster I presented at the ASIS&T 2002 IA Summit in Baltimore, “Where the Wireframes Are: The Use and Abuse of Page Layouts in the Practice of Information Architecture.” You can find the poster at http://www.greenonions.com/dan/portfolio/
Pros
Cons
|
|
| Dan Brown has been practicing information architecture and user experience design since 1994. Through his work, he has improved enterprise communications for Fortune 500 clients, including US Airways, Fannie Mae, First USA, British Telecom, Special Olympics, AOL, and the World Bank. Dan has taught classes at Duke, Georgetown, and American Universities and has written articles for the CHI Bulletin and Interactive Television Today. |
|
I first read this article in 2002. I loved it. I have used page descriptions on a few projects around the time the article was published, but I found myself creating regular wireframes for most of my projects (mostly web app work) — I was also doing most of the visual design or had a graphic designer readily availble to brainstorm. It wasn’t until recently when I started to work with remote graphic designers that I thought about using page descriptions again. So I used page descriptions for the redesign of my employer’s website to see how they would work for content rich site.
The graphic designer we used loved them (not in house), but he did something interesting and suprising: his first deliverable back to us was regular wireframes that dictated layout. I was expecting him to create full-fledged comps. His rational for creating the wireframes was that he wanted us to concentrate on the layout of the items on the page and not the final graphical treatment. It was a great process and I wrote about it in greater detail and included a shot of one of the page descriptions. I wonder if anyone else has ever had a graphic designer return them a wireframe?
I have been calling myself an information architect probably as long as Dan has. Of course there was that terrible period in the early 00’s when I was calling myself unemployed. But it is good to see that the development world and the likes of Mr. Rosenfeld and Morville have kept the field alive. I have been teaching introduction to Multimedia at the New England Institute of Art since 1998, and during students very first course they have to develop a proposal, flow chart, storyboard, blue print and a working wireframe for their first professional project.
It may be a lot to ask of freshmen, but they always rise to the occasion every semester, even though they don’t have the business experience to support some of their ideas. At first, we didn’t know what to call “wireframes” and so we called them prototypes, for lack of any other term. But after reading Dan’s description up above about page schematics, well, it made me feel less alone in trynig to define new terms in an industry that generates so many. I am so thankful now that the world embraces wireframes, and that I can convince students of their value.
Bob Griffin
Full-time Faculty
Interactive Media Design
New England Institute of Art
Dan,
I’m interested to know how you produced these documents. Did you use Visio in conjunction with Word, Illustrator, etc?
I’m asking because the idea that your format eliminates having to navigate between two documents (a functional spec and wireframes, for example) is tempting. However, I’m not looking to make things more complicated for myself or for others who have to update my documents.
Thanks.
Dan,
First off, let me say great article… it depicted my life within an agency several years back… they had no IA, no user exp department… just a bunch of markup monkeys and creative artsy types… all in one group.
Now, I have been developing and designing web sites since 1995 so it would be no shock to me to say that a good web designer is also an IA. I am curious what your thoughts are on that. Do you feel that they are so far apart that one could not conceptually pair the two?
In this article here you seem to indicate that the two are very close… the IA cramping the designer’s creativity, the designers creativity cramping the IA’s …well, IA.
Does not a good web designer think of the IA, usability, functionality, branding, layout, and navigation all at once? Is there a need to have a new [yet, I admit, old] craft called an IA or is the need to educate ad-hoc designers with the true skills needed for the job?
Food for thought.
Dan,
I have been following your (earlier and current)articles closely.
Can I see a slight shift between your earlier article -Opening Pandora’s Box: Special Deliverable #1
and this current one?
In your current article, I see that you have made a conscious effort to create a comfortable situation for designers as well as IAs. The earlier article however, stated that ‘it is the information architect
that puts a stake in the ground: the finished product will look like this!’
Being a UI designer, I have personally faced situations when the IA, and site structure has been given to me with the line of ‘caution’ that, “the client has seen this and likes it. so please dont stray too far.”
Like you, there are days when I think I will be making things look pretty all my life…
I really appreciate your efforts to:
1. Realize that there is a problem in the current way of working
2. Come up with a solution…
I do hope this process gets gains the required popularity and ‘designers’ like me (and many others) get space for their creativity. 🙂
Thanks,
Dan.
Good stuff here, although the effort of writing a good consise page description diagram like this would be quite high in some cases. I find that wireframes are at times the quickest way to express an idea.
I must be in the minority: I’ve worked with designers who *prefer* getting wireframes from me. This is partly because I tend to work on projects that designers consider boring: “What, another giant catologue of 5000 products with a bunch of categories and search functions? No Flash or tricky stuff? Give it to Andrew…”
RE: I’m interested to know how you produced these documents. (Jonathan)
For better or worse, all in Visio. The advantages are that it allows me to do layout pretty easily, and it allows me to put the little component diagrams in-line. The disadvantage is that… well… it’s in Visio, though for clients I export to PDF. I suppose it would be easy enough to do the entire document in Word or PowerPoint, using Visio only to diagram the functional components.
RE: Does not a good web designer think of the IA, usability, functionality, branding, layout, and navigation all at once? (Nick)
Of course! A visual designer must have a general understanding of all those issues (as well as color, contrast, typography, etc.). I’d take it a step further and say that a good IA needs to have a general understanding of a graphic designer’s issues. A good IA must also have an understanding of database design and object-oriented programming, not so that she can do it herself, but so she can have intelligent conversations with other people involved in the process. (Of course, the column is about deliverables, so I’m well out of scope here.)
Perhaps the distinction is best understood through the responsibility of the details. An IA must pay attention to the details of the functionality: what happens when users traverse the entire hierarchy, how do we classify this piece of information, what happens when users click on this combination of buttons. The domain of a graphic designer encompasses an entirely different set of details. The page description diagram allows information architects to elaborate on their own details.
RE: The earlier article however, stated that ‘it is the information architect that puts a stake in the ground: the finished product will look like this!’ (Satya)
Yikes! I hope I’m never inconsistent from one article to the next, so thanks for keeping me on my toes. I suppose I should clarify what I meant in Special Deliverable #1. When I say, “look like,” I don’t necessarily mean visually. The finished product, being an interactive system, will have a set of behaviors. (If you want to get philosophical, those behaviors are expressed through the visual design.) The IA puts a stake in the ground by describing the system’s behaviors, through functional documentation, vocabularies, or what-have-you – perhaps in conjunction with a technical designer who will describe a database schema or infrastructure topology.
RE: I find that wireframes are at times the quickest way to express an idea. (Andrew)
No doubt wireframes are speedy, and that’s what I was referring to in the first bullet under Pros: “demonstrates a site concept quickly.” You’re absolutely correct in that good page descriptions can require a lot of effort. But I believe that effort is not in adjusting layout or typography, but actually describing the functionality. Ultimately, this is the best use of an information architect’s time.
As for projects designers find boring, I can’t help you there: I work for the US government!
Great article. I think it’s always important to reviews existing work methods with regard to IA.
I’m sure some designers might have problems with wireframes feeling restrictive at times. However, as a designer you should be able to take loads of information and formulate a cohesive visual solution. If designers have the site concept and various page layout levels designed PRIOR to production on the pages (when wireframes are really used)–the wireframes should just help them to produce the pages.
As a designer I always appreciate well-worked wireframes. But they don’t lead the creative concept that’s being developed–they really are a reference which allows me to check that my design will function properly as i go along.
We had the same problem with IA was first introduced. But, we had a pow wow with the Designers and arrived at something that worked for all of us: wireframes (primitive or complex) were spatial, hierarchical, and prioritizing in nature — and whatever appeared to be “design” wasn’t. Instead, those things showed content relationships and were to be interpreted against the design concept. Wireframes are only starting points for grounding the design studies.
We then graduated to Experience Models, which were detailed. By this time, however, the IAs and Designers had design concepts (“vernacular”) that the IAs could use to draw wireframes that corresponded to a large degree to the design concept, minimizing to that same degree the amount of interpretation needed.
Not all of our IA was anticipated. And while there are a lot of aspects that appear to be layout “design,” the precedent had already been set that these aspects would be interpreted. We could tell a “green” designer by designs that came out looking remarkably like the wireframe or x-model.
This mutual education took a lot less time than coming up with deliverables that didn’t “interfere” or presume upon design. The perspective we took was that Design needed to grow past the traditional to some degree.
-ron biggs
Sr. IA/Experience Designer — Euro RSCG Interactive
Ok, I can’t let it go … Dan, I think you are absolutely right. If the set up is IA > Visual Designer then I can see great value in your process that you created.
Even if these are just roles and not people you HAVE to have a place to do interaction design and this is also in the wireframe. IA > ID > Visual Design.
This being said, you can still employ your techniques if you have a dual-role visual designer who can do UX/ID design as well as visual and information design. Most Visual Designers don’t do this.
Who is going to say this is a drop down list? or no, I prefer radio buttons instead? Or this needs to be a browsertree navigation? but the browsertree needs to be employed in this metaphor not this one. Who is to say that the flow if interaction (even on the client side only) will go a specific directly? These require a storyboard of some kind to communicate.
Lastly, I think that the whole stepping on toes of visual designers argument is overstated. I have refused where I have worked to give into the uppidity status that visual designers afford themselves. I realize this is more of an agency culture issue, but it is one that needs to change. Visual Designers just have to learn to play well with others and we have to learn not to be scared to play in their sandbox. We are a team of people with different expertises, that doesn’t mean we step on each other’s toes it means that we all have a stake in the final user interface and thus are implicitly in the same sandbox.
I have a shovel and you have the pail and she has the rake. Time to build a kick-butt castle.
Katie, Ron, and David:
Thanks for your comments. I’d anticipated a LOT more controversy surrounding this article. What I’m seeing instead is a description of different approaches to the same problem. From Katie’s “wireframes after design” idea to Ron’s “experience models,” IAs clearly have many approaches to choose from.
To respond to David’s comments: conflict might be a trigger event, a pointed opportunity to explore these alternative approaches. Adopting alternate approaches, however, might evolve into something more than preventative measures for toe-stepping.
There is, however, a more rigorous business case for clearly delineating the responsibilities of IAs and visual designers. As a manager, I want to use my personnel in the most effective and efficient way possible. The toe-stepping is less “personality conflict” and more “getting people to do what they do best.”
To transform your excellent shovel-pail-rake analogy into a bad one: why would I have my shoveler use a rake or a pail?
We could get into the Platonic parallels at this point, but that is, perhaps, for another column…
Hi all, I’ve been using wireframes (storyboards) for all web project for a couple of years now and ran across the exact pros/cons described in the article. I find them extremely helpful on larger teams and on teams with non-technical/novice to the web producers/editors, etc. Often the client is not sure what they want and is looking for so much guidance that it is crucial to have multiple wireframe signoffs.
We are in the process of launching a Content Management system and our web native editor is based on the concept of a living storyboard. Exactly because of the challenges surrounding a storyboard. Our editor _is_ the wireframe. It may start out vanilla flavor (no design at all), folders, pages, content are created and arranged (by IA or the team wearing the IA hat on a project). When design comps start finalizing they are templetized and become available in the storyboard, so content creators can preview the content with crome, images, css, etc. As business logic is added it also becomes available in preview/generated html. But the order is not important. Never worked on projects where we could stick to the same process especially in larger organizations. So if design comes first and wireframes later – our goal is to accomodate any workflow that people are familiar and comfortable with. Everything is reusable because content/design/code are the components of the complete site.
I would be very interested to hear what your thoughts are on this concept of a living wireframe(storyboard).
Best,
Iva
Hi,
I think it all depends on the company you are working with .
In the various companies I worked in, I could not implement similar processes. This is basically due to the wide differences between the visuals designers and developers I work with .
I produced different processes for the various companies, but they all have the same elements of user experience and they all enabled us to produce a better product.
So, I believe, you should choose the right elements that enable your company to work harmoniously .
My two cents of experience.
Thank you.
Melvin Jay Kumar
I like this approach, but I feel a better way to solve the stated problem would be to develop projects in a less linear fashion.
My agency experience was very linear. A project would go from VP to AE to Project Manager to Site Map to Visual Design to Production, etc.
This, of course, was the actual problem as each step would bring up issues that SHOULD have been addressed earlier, but weren’t due to the linearity of the project. This, I’m guessing, is the actual problem you were attempting to adress in your article.
This issue is also compounded by the mis-use of the term ‘design’ to refer solely to the visual designers. This is a dangerous habit, IMHO that seems to be wide-spread. Not calling IA design is a detriment to the project.
My solution? The IA should be working directly with the Visual Designers to develop the wireframes. Simple: a multi-step process turned into one. The client begins seeing the ‘site’ earlier, the Visual Designers start seeing the ‘goals’ earlier and there are significantly fewer revisions during the process.
Shovel, Rake & Pail:
The reason why people share in this is that their primary skill sets require them to do so.
Graphic Designers have a particular point of view on visual design. It is not the best point of view, but a particular one. An IA’s job requires her to take part in the visual design process. I can’t imagine doing my job w/o picking up the graphic designer’s tools from time to time. Visio is my home, but Fireworks is my garage and illustrator is a small 1/2 bathroom.
I think the business case you make is not reality at all, nor is it actually the business case. It is very old school personnel management. In a more modern flexible organization the goal is to get the right people in a room who will create the most profitable experience for my customers. That means I need to make sure I have all the skills I can afford, to work as efficiently as possible together to create the most usable and most sellable products I can. That is a management strategy. Pigeon holing has been proven to cause inefficiencies in the work place by many studies, if for no other reason, it creates anxieties that make people less wanting to work.
I have worked in a pigeon hole and I have worked collaboratively. I’ll take collaboration over the birds any time.
–dave
Hey,
*nice* idea — good designers would appreciate the flexibility and less, umm, focused designers won’t get to simply add fonts and colors to the wireframe and call it a day. (side note: if you are not confident in your designers’ abilities, this approach could end up creating more trouble that it is worth.)
Another reason why I like this approach is that a complex site will frequently re-use components on different pages. This approach to wireframes treats each component of the site as an independent entity with differing priorities based on the page, preventing inconsistencies and making documentation, QA, etc, much, much easier. Engineers and htmlers will appreciate this change as well, particularly if it is coupled with detailed specs for each component.
Also, this method seems a lot easier to update — keeping the UI spec current as the project progresses will probably always be painful but it never hurts to try and alleviate the pain a little bit.
One downfall: I find that most clients have a hard time envisioning how the site is going to work. Standard wireframes (particularly if they are linked up) are really good at helping clients feel comfortable signing off on site functionality relatively early in the process. I wonder whether IAs will have to stick with wireframes in cases where clients seem particularly intransigent.
thanks for the idea!
–hk
Wow. David Heller said what I *think* I was trying to say in a much more eloquent manner. I agree completely.
Dave, Darrel,
I should have elaborated on the concept of separation of concerns – I really don’t see it as ‘Pigeon holing’ at all.
I agree about getting the right people in the room, but once the team is on the same page, do your editors write code? Do your designers make copy changes in html? Are your components reusable? Can you publish your content to multiple media without reengineering? Or reentering the copy in some other system? That is not efficient, but sadly the reality on many projects. Our solution does not lock you into a process, it allows for the Xtreme Programming approach of iterations, validation, improvements, etc.
The IA and Designer can collaborate on a wide brush stroke wireframe initially, get approvals. Editorial can walk in immediately following and start replacing Lorem Ipsum with 1st drafts. Usability testing can happen much sooner that way too. IA/Design can validate their initial ideas quicker and correct errors sooner.
Unless your projects have unlimited resources, the $10,000/hour meetings will quickly prove very dangerous schedule and $$-wize. To kick off a project – of course, but on an ongoing basis, I am said to say I’ve worked on too many high-visibility projects, where I knew I could have done the whole thing with one or two other people for a fraction of the time and a fraction of the cost. Realizing and adressing that does ensure building the best product you can sell to your clients.
Separation of concerns is emphasis on core competency, it promotes efficiency, reusability, cutting cost. It is an oversight to dismiss the proven benefites of this method by assuming it simply advocates uncoordinated effort or disfunctional corporate silos.
Best,
Iva
Your “Page Description Diagram Mock-Up with Component Layouts” is moving in the right direction from a documentation perspective. I do think it can go much further and in fact, it needs to as we further refine the types of documents used in our practice to communicate conceptual and tactical strategies and blueprints
One of the more glaring deficiencies within the typical wireframes is that they are only good for one instance of a page view. Most often you will find an IA/UE wasting precious time developing multiple versions of the same wireframes to illustrate various behaviors or states of specific page components. Wireframes should really only illustrate the page types that define the different layouts to be employed to present a view on the site. They provide a structural view of a particular aggregation of components and content, but do not infer specific functionality, instead acting as containers in which functional components can reside depending on business rules, user input, and system feedback.
The real excitement and challenge we face is the producing the types of documents which illustrate a user lifecycle through the site by showing how a particular user type matures over time as they progress through our flows (e.g. from ‘anonymous’ to ‘recognized’ to ‘registered’). The events that trigger this maturation (e.g. providing zip code, using and advisor tool…) are identified and correlated back to the particular page type, but more importantly the display of an aggregation of a page components for that particular view instance.
Too often you will find “systems” or some other lot of people are inferring and defining the behavior of a site based on wireframes. Without shifting the focus away from the container (wireframes) to the documenting the component within the container, we will continually see the end product something less than we had envisioned. Nice to see you heading down this path.
Hi Iva,
hmmm? I don’t see how your clarification addresses my main point … Wireframes are good. I haven’t seen anything to say otherwise.
I also think you, nor Dan have addressed the point that IA/ID are close siblings and his presentation is mean to be all encompassing. If I was ONLY dealing in content, his ideas work great, but to express interaction alogorithms I need something more sophisticated that show flow, metaphor, and results.
His main reason is also faulty. I do not change my documentation b/c Visual Designers weren’t a part of the process in developing that documentation and feel their toes are being stepped on. I change the process for creating the document b/c the Visual Designer is only ONE player that requires my documentation. Engineers, Content authors, etc. require the added context that a wireframe gives them, b/c it brings in the spatial. It also brings in the technological b/c it includes methods of interaction and navigation.
In my work, I have taken the opposite approach. We have stopped doing sitemaps in favor of ONLY having wireframes. The engineers LIVE off of these wireframes and the visual designer sits with the engineers to create/design each component together with the ID to make it happen. I don’t think we are caught in extra meetings at all.
As for the XP analogy, XP has basically said that documentation is a waste of time. We dont’ need IA’s or ID’s. Just code and get it done. To try and meet them half way falls way short. There was a great interview between the founder of XP and Alan Cooper about this … Alan really did a good job of showing how important initial design is to a project, that XP doesn’t respect. In fact XP is not really a model I want to head towards, but away from. Of course this is a personal preference.
— dave
“Another reason why I like this approach is that a complex site will frequently re-use components on different pages.”
I agree completely. One frustration I have with JJG’s visual vocabulary, and to a certain extent wireframes, is the focus on the page as the fundametal unit of design. Most CMSs I know deal with re-usable, conditional content “chunks.”
This debate brings up another question: does anyone have a GUT of IA deliverables, ie which deliverables to use at each stage of a project, how to do them properly, who to involve, how to tie them all together, etc.? (Not that the community could ever agree on such a thing, but it’s a neat idea.)
Gene,
We have developed a series of deliverables. Some are client facing while others are intended for internal groups. They are actually part of a larger integrated process which has proven very effective for us. We have taken some of the best practices and methodologies and morphed them into something that fits our culture and the specific client needs (faster, cheaper, better, more features…). Contact me privately for specific information on the contents this process.
I’m a little late to this party, but I can’t help but feel that an important point has been overlooked. I consider a critical goal of a wireframe to be to bring the client and user into the design process– to actively gather their input and thoughts and ensure that they’re on board for the next steps. The page description diagrams you describe really seem like they would fail in that goal in a number of ways.
First, they seem very conceptual. Sure, all us IAs can understand and use the diagrams, but how many clients can really conceptualize what they’re representing, and make intelligent comments? I imagine that this would seem great to begin with, as it just would seem that everyone’s in agreement with you, but down the road, don’t you find that people are more apt to “change their mind” about what they agreed to– because they never really understood it in the first place? We all know better than to present something so conceptual to a user (take a look at this multi-layer bubble diagram—does it include everything you do to make a decision?)—why is it different when applied to a client?
Second, what happened to paper prototyping? You mention a con of wireframes—“does not provide accurate usability testing results”. I’ve tested a lot of paper prototypes, and certainly I agree that you can get some wacky results based on layout or graphic issues, but I feel that they’re absolutely better than nothing… or than trying to user test a textual representation of what’s on a page.
Perhaps I should clarify the point of the article:
Page description diagrams are an ADDITIONAL tool in the IA’s kit.
To Dave’s point, if you don’t have any issues collaborating with visual designers using wireframes, continue to use wireframes. On the other hand, page description diagrams offer an alternative if you find wireframes to be sticky collaborative tools.
To Laura’s point, if you don’t have any issues with clients and users misinterpreting the wireframes, continue to use wireframes. On the other hand, if you find yourself struggling to focus conversations around wireframes on priority and content, perhaps the page description diagram will do.
(I have had these issues, and that’s why I devised the method. I didn’t sit down one day and say, “You know, the wireframe is evil. What can I do to thwart it and its heinous attempts to take over the world?” If I had, I would have much more serious problems.)
One of Laura’s points, however, is that clients and users might not be able to understand what a page description diagram is supposed to represent. I would argue the same thing about wireframes, particularly those done in vector-based drawing programs like Visio.
Wireframes and page description diagrams are meant to represent the same information, but the former includes additional data points like layout and typography, which might obscure data points like priority and content. Wireframes might, in the end, be more misleading to clients and users because the information they represent could be interpreted differently in the final design. I have had better success helping clients and users understand the purpose of the page description diagram than explaining why the final design doesn’t look like the wireframe they saw a few weeks ago.
Is it just me, or are clients and visual designers getting more sophisticated about wireframes? This article takes me back to ’98, when designers were outraged over the perceived infringement on “their turf” and clients were perplexed (“But I thought our web site would have color and graphics on it!”).
Sure, this argument still comes up from time to time. But generally I find that:
1. Clients are increasingly ASKING for wireframes (specifically, by name) to help sell/explain new functionality to their colleagues.
2. Experienced designers are grateful for (versus dependent on or hostile towards) wireframes just so they don’t have to “make it all up” – they can actually get a definitive, literal, straightforward document of what needs to be on each page and the relative weighting.
3. Wireframes are the only IA deliverable that developers will pay any real attention to. Process flows and site maps get a cursory look – meanwhile, wireframes get pulled into use cases and treated as gospel.
With an ironic nod to Dubya, “the trifecta!” Hard to beat in my opinion, although this Page Description doc is an interesting idea.
Has anyone else noticed an increasing acceptance of wireframes?
Also – to the above question about shouldn’t designers do the IA job – Of course good designers have IA skills, as do good copywriters, but (a) it can be more efficient to solve IA issues without the burden of reworking comp after comp, and (b) with clients wanting everything tomorrow, there just isn’t enough time in the day for one person to do it all, when you’re talking about big, complicated sites.
So a couple of years later- we continue to face the same problems but with an improvements in context and technology.
Does anyone have thoughts on documents/processes that help the IA and Designer better collaborate on designing rich media solutions? Furthermore on, sites that is information rich (several hundred pages) and time sensitive sites (updated 1-2 daily). We have been heading the way of storyboarding and scripting similar documents like the page description diagrams and open to other ideas. Thanks very much.