The designer’s job is perhaps the most misunderstood on the Web. In some professional circles, the term may broadly define the job of fitting form to function, whatever that entails; on the Web, “designer” usually refers to someone in charge of coming up with a good looking layout for a page. More specifically, titles like information architect and interaction designer define design roles that involve more than just esthetic decisions. If these roles are not understood by all concerned, then difficulties in communication are bound to result. It’s hard to communicate if the people you’re talking to have a completely different concept of their job requirements than you do.
The vocabulary problem extends beyond job titles into the fabric of the Web site development process. Web design uses a combination of terms drawn from older disciplines and terms invented specifically for the medium. It’s unusual to find someone who comes to the Web knowing what to expect from both a “creative brief” and a “technical specification.” Both are important ways to document steps in the Web site building process, but the frames of reference are from different disciplines. If you’re from advertising, you know how to work with a creative brief, but probably have no idea why you’d need a technical specification. An engineer might tend to ignore the creative brief, but would flounder helplessly (or think you’re an incompetent fool) if you proceed without the tech spec. And such communication challenges extend beyond the team into dealings with the client. When you describe your process and deliverables, your clients may nod, but chances are they have no idea what you’re talking about.
Inevitably, interactive teams fall into the age-old standoff between the two poles of art and science, represented on Web teams by designers and engineers. On the Web, these two minds – the two key players in envisioning and realizing a Web site – absolutely must meet. No design can be accomplished without the advice, understanding, and support of the engineer. And it’s no easy task for designers to learn the technical tools of the trade in order to communicate better with technologists. Once you have mastered QuarkXPress, Photoshop, and CMYK, you can run with that knowledge in print. Take some classes in Director and Lingo and you have the outlines of CD-ROM. But on the Web, solutions are open-ended, set not by standard tools but by the much broader capabilities of programming languages such as Java. Ambitious designers might take on their own Lingo scripting in Director, but it’s a rare (and probably foolish) designer who would decide to dip into Java and database programming. There’s too much to learn, too much new technology to keep up with, too little overlap between tasks, and not enough time in the day to take it all on.
Such problems may fade over time. Sooner or later, the expectations attached to a certain job title, relationships between team members, and the process by which a project is completed will be accepted industry-wide. It takes time, though, for a profession to develop a standard production process and then for a vocabulary and expectations to solidify around that process. On the Web, the confusion caused by the field’s youth is compounded by its quick-changing nature. This inevitably leads to an ever-mutating design process and new relationships between team members.
Think of it. In the beginning, when Web pages were essentially print pages laid out with HTML, Web sites were differentiated by how well they used screen space to present information – sites were made or broken by the skills of the visual designer. Now a site such as Amazon.com is popular not because it looks better than other Web sites, but because it employs technology to help visitors complete their task in the quickest and easiest way. The site uses sophisticated database programming to assist in finding books and music that fit certain criteria, to gather and present other readers’ opinions of these titles, to intelligently suggest other works the consumer might like, and to fulfill the order efficiently.
On sites like Amazon.com – the model for the commerce-driven sites of the future – interaction design and engineering, not visual design, lead the development process. The world of Web design is always brave and new, and so far, no process has existed long enough to establish a tradition.
The only answer to this problem of communication on a Web team is to face it head on – you’re going to have to keep talking to your teammates. On the Web, no step can take place without the collaboration and understanding of several team members. Interaction design can’t take place without the advice and buy-in of the project engineers. Interface means cooperation between interaction design, graphic design, HTML engineering, and a writer. All of these roles are interdependent. Interaction design may precede graphic design on the schedule, but a sign-off at this particular phase may need to accommodate graphic ideas and constraints that emerge later in the process. And interaction design and graphic design may change again in response to needs that come up during engineering.
You could almost say that on a Web design team, communication is the process. That means in large part that the project manager’s job is to ensure that the necessary communication takes place, dependencies between the disciplines are understood, and space is created for necessary collaboration. And if you can get a writer, a designer, an interaction designer, and an engineer together to brainstorm concepts and approaches, so much the better. Communication also becomes item number one on the job description for those in charge of each discipline. Those in charge of different tasks have to understand that part of their job is helping other team members accomplish theirs.
Collaboration can be difficult, but once you learn the art, it certainly has its advantages. The process creates a sort of ad hoc user testing: the good ideas can snowball, and the bad ones can be nipped in the bud. Distributing the work among specialists creates an efficient division of labor, freeing each team member to focus on a particular area of expertise, the better to keep up with the rapidly changing state of the art. Most importantly, though, working together with such a group can be mind-stretching. As a member of a team, you will confront more ideas in the course of a day – some good, some useless, all challenging – than you would in any other way. When each member brings his or her own strengths to the process, the whole is definitely greater than the sum of its parts. And learning to approach design problems from the various perspectives represented on a Web team is the most exciting publishing process you may ever be involved in.