12.8. Design Collaboration
Once you've developed blueprints, wireframes, content models, and vocabularies, you'll find yourself collaborating more with other people involved in developing the sitevisual designers, developers, content authors, or managers. You'll move from capturing and communicating your own design concepts to integrating them with the visions of other members of your team. Naturally, this is as challenging as design getseveryone wants his own ideas to play a role in the final product, and because the group's members often come from interdisciplinary backgrounds, there are often competing vocabularies and breakdowns in communication. But if each person goes in with an open mind and good tools for collaborating, this difficult phase is also the most gratifying one, ending with a shared vision that's far better than anyone was likely to arrive at individually. Design sketches and web prototypes are just two tools for merging differing ideas.
12.8.1. Design Sketches
In the research phase, the design team developed a sense of the desired graphic identity or look and feel. The technical team assessed the information technology infrastructure of the organization and the platform limitations of the intended audiences, and they understood what was possible with respect to features such as dynamic content management and interactivity. And, of course, the architect designed the high-level information structure for the site. Design sketches are a great way to pool the collective knowledge of these three teams in a first attempt at interface design for the top-level pages of the site. This is a wonderful opportunity for interdisciplinary user interface design.
Using the wireframes as a guide, the designer now begins sketching pages of the site on sheets of paper. As the designer sketches each page, questions arise that must be discussed. Here is a sample sketching-session dialog:
Developer: "I like what you're doing with the layout of the main page, but I'd like to do something more interesting with the navigation system."
Designer: "Can we implement the navigation system using pull-down menus? Does that make sense architecturally?"
Information Architect: "That might work, but it would be difficult to show context in the hierarchy. How about a tear-away table-of-contents feature? We've had pretty good reactions to that type of approach from users in the past."
Developer: "We can certainly go with that approach from a purely technical perspective. How would a tear-away table of contents look? Can you sketch it for us? I'd like to do a quick-and-dirty prototype."
As you can see, the design of these sketches requires the involvement of members from each team. It is much cheaper and easier for the group to work with the designer on these rough sketches than to begin with actual HTML pages and finished graphics. These sketches allow rapid iteration and intense collaboration. The final product of a sketching session might look something like Figure 12-23.
Figure 12-23. A basic design sketch
In this example, Employee Handbook, Library, and News are grouped together as the major areas of the web site. Search/Browse and Guidelines/Policies make up the page navigation bar. The News area defines space for a dynamic Java-based news panel. This sketch may not look much different from a wireframe. In fact, the team may have begun with an information architect's wireframe, then iterated on the design until arriving at this sketch, which in turn may be the basis for a revised and final wireframe.
Starting with a sketchwhether a formal wireframe or something more "back-of-the-napkin"is critical to the success of interdisciplinary meetings. The sketch provides a common focus for each participant, minimizing the attention paid to the individual personalities around the table. It also makes it more likely that participants will be using the same terminology to discuss the design; shared terms for design concepts often emerge directly from the sketch itself.
Finally, note that design sketches aren't necessarily "owned" by the information architect. For example, sketches that describe functional requirements may be under the purview of the designer or developer. Be wary of getting caught up in ownership issues; contributing to the design, regardless of who is driving Visio, OmniGraffle, or Illustrator, is far more important to the project's outcome.
12.8.2. Web-Based Prototypes
For the information architect, a high point of the design process is the creation of web-based prototypes. More than sketches or scenarios, these digital renditions show how the site will look and function. They are concrete and often aesthetically compelling; you can actually see how your work will really come together, and maybe even kick the tires yourself.
While the balance of attention now shifts toward aesthetic considerations such as page layout and graphic identity, the prototypes frequently identify previously unseen problems or opportunities related to the information architecture. Once your architecture and navigation system are embodied in actual web pages, it becomes much easier for you and your colleagues to see whether they are working.
The designer may begin with two concepts based on a single information architecture. After getting feedback from the client, the designer and architect may work together to adapt and extend the preferred concept. At this point, conceptual design officially ends, and production actually begins. The most exciting challenges for the architect have been met, and you now begin the days of detail.
12.8.3. Point-of-Production Information Architecture
Ideally, the production process would proceed smoothly in a paint-by-numbers manner, and the architect could sit back and relax. In reality, you must be actively involved to make sure the architecture is implemented according to plan and to address any problems that arise. After all, no architect can anticipate everything.
Many decisions must be made during production. Are these content chunks small enough that we can group them together on one page, or should they remain on separate pages? Should we add local navigation to this section of the site? Can we shorten the label of this page? Be aware that at this stage, the answers to these questions may impact the burden on the production team as well as the usability of the web site. You need to balance the requests of your client against the sanity of the production team, the budget and timeline, and your vision for the information architecture of the web site.
You shouldn't need to make major decisions about the architecture during production because hopefully these have already been made. Discovering a major flaw in the architecture at this point is an information architect's nightmare. Fortunately, if you've followed the process of research, strategy, and design, this is unlikely. You have worked hard to define the mission, vision, audiences, and content for the web site. You have documented the decisions made along the way. You have resolved the top-down and bottom-up approaches through content mapping and detailed blueprints. Through careful planning, you've created a solid information architecture that should stand the test of time.
Still, it's worth reminding yourself that an information architecture can never be perfect. Factors of content, users, and context are constantly changing, and the architecture will, too. It's more important to invest your energy in educating your colleagues that information architecture design is an ongoing process, rather than fighting with them to get it "right."