by Dan Brown on 2002/07/01 | [26 Comments]

In 1998, I was working for USWeb/CKS, perhaps the largest Internet consulting firm at the time. Information architecture was new to the organization, and I was the only one in the Washington, D.C. office who had the chutzpah to call himself an IA. At that point, we hired a new creative director, and together he and I formalized the user experience group in our office. As part of that process, and based on our own bad experiences, he told me that I needed to find a way to take design out of information architecture.

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.

admin 产品项目流程和规范, 提高个人效率的软件或服务 Wireframe, 产品经理

[#2: Edit Options>MightyAdsense>Adsense Code]

从事网站建置工作的人想必一定对Wireframe(以下简称WF) 这个字不陌生。

WF简单来说就是网站页面的蓝图，主要的功能IA是让用来(信息架构分析人员，时常会是网站必须企划兼任的角色) 与网站置作团队的其它成员沟通想法的工具。

WF的表现形式有很多种，可以精细也作出与真实页面相近的WF，也可以用很简略方式表达页面中应具备的元素，对麦斯而言，WF是一种沟通的工具，因此最重要的是能够让看WF的人了解你的想法，要用那种形式来表现，应该视当时的需要，以及合作的对象。

麦斯有时会被要求制作一些十分接近真实页面的WF，精细形式的WF表面上看来似乎会让工作流程变得顺利，但实际上，在看不到的地方却有许多潜在的危机。

l .首先，WF是用来沟通IA的工具，但一个拟真的WF常会让讨论的焦点转移到页面的视觉设计，然而那是创意人员的工作而不是IA人员的专业。因此，当一份拟真的WF出现后，常会出现两种情形：
(1)创意人员觉得WF 阻碍了他们发挥的空间。
(2)上面那点是对比较勤劳的人来说，至于比较懒的，就会直接把这个WF加上图片颜色做出网页。

2.再者，也许因为拟真的WF容易让非专业的人也看懂网页设计，因此这样的wf常被拿去与客户沟通，这样的作法也许对能让客户看到一些实质的产出，因而签下合约，但却是非常不正确的作法。
(1) 让客户看到拟真的WF会让他对页面中会出现什么产生不当的期待。我们知道WF只是页面的IA架构，最后完成的网站通常会与wf有许多不同之处，如果客户在一开始就看到拟真的WF，而之后完成的网站却与他心中的期待不同时，客户常会认为一开始所看到的wf是一个不实广告，这样一来会为自已制造许多不必要的麻烦。
(2)如果客户太早看到拟真的WF，那么他的会将焦点放在接口视觉设计上，这时从客户口中听到的就会是：我要这个在这里，这个页面中应该有这个功能，还有，某个图应该要出现在页面上。
但是，在未进入实际的制做前，我们所应该了解的是到底有那些信息是重要的? 这些信息之间又有那些关系? 通常客户对这方面的想法会是散乱的，IA人员需要有些技巧才能让了解客户真正的想法，然而过早秀出拟真的WF只会让客户的想法失焦，这样一来我们就更无法得到设计IA时所需要的信息。

Dan Brown (http://www.boxesandarrows.com/archives/where_the_wireframes_are_special_deliverable_3.php) 提出了一个用Description Diagram 来代替WF的沟通方式，这种方式感觉上似乎更能让创意与客户focus在IA的设计上进行讨论。

与其用WF来与创意及客户讨论网站的信息架构，Dan Brown则改用以内容描述为主的Description Diagram，这种方式是将网站可能会有的内容以文字描述的方式，依重要性不同列在一份文件上来进行讨论，这样一来，文件中少了视觉的要素，因此讨论的内容就可以专注在IA议题上，较可能针对内容类形与重要性与客户进行讨论。

Dan Brown在其文章中只谈到这两个例子，麦斯认为，如果能先以这样的Description Diagram来沟通想法，那么IA人员接下来，只需将网站中会出现的各个分页标定出来，然后将每一页中将出现的内容以描述的方式说明，剩下的就可以让创意自由发挥了。

网站的建构通常需要的是team work，而这种team就像是一个Jazz Band，其中每个人都有不同的专长，要让team的效能发挥到淋漓尽致，就要让不同才能的人都能在自已的领域尽情的发挥，彼此之间能够多一点互补，少一点干扰，而以Description Diagram进行沟通最大的好处正在于此。

再进一步，可以依内容的不同放入一些初步的功能设计，这些功能设计在视觉上都以灰阶的方式呈现，如此一来，对创意人员而言，既能达到沟通内容的目的，又能保有很大的创意空间。

admin 产品项目流程和规范 Wireframe, 产品经理