152 WHO: Riding the Project Life Cycle: We Never Forget a Phase

Analysis (or “Talking to the Client”)

In this phase, you will meet with the client as often as necessary to fully understand what the client wishes to achieve with the project, to determine the best ways of meeting those needs, and to sell those solutions to the client. You’ll also continually interface with fellow team members to make sure these solutions make sense and can be executed.

Even before sitting down to brainstorm with the team, you must help the client articulate and clearly define the site’s goals. Is the site selling something? If so, what is being sold and to whom? Is the site intended to serve as a portal—if so, a portal to what and for whom? How will this portal differ from its competitors? If the idea stinks, don’t be afraid to say so. (First, of course, do enough homework to be certain that the idea really stinks and be prepared to offer the client a better idea.)

These responsibilities are not the web designer’s alone. Project managers, information architects, and marketing folks will be all over these meetings, but the web designer plays an essential part.

Indeed, the web designer is often the only person in the room who even thinks about the end user. The project manager is scheming ways to get the project done on time. The programmer is itching to try out some new technology or lazily conceiving ways to reuse code from the previous project. The technology director is fretting about server farms. The junior designer is nursing a hangover, and the client is lost in fantasies of market domination.

The web designer must help the client articulate objectives, both broad and narrow, to begin delineating the project’s scope. If this work is not done up front, it will haunt the project (and the whole team) later on.

In these early meetings, the web designer should be prepared to discuss possible site structuring options, technological baselines, and related issues. Even if these ideas change later in the process—and they will—the web designer must be comfortable articulating possible solutions “on the

fly.” This begins establishing a client comfort level, which will be essential throughout the process. If the client does not trust the web designer in the beginning of the cycle, the project will begin to self-destruct further down the line.

Taking Your Talent to the Web

153

To summarize what we’ve just said: It is essential that the web designer possess the ability to understand a client’s marketing goals and to discuss potential issues and solutions with regard to design, site architecture, and technology.

To assuage your fears, the only part of this that is new (from your perspective as a professional designer) is that technological issues have been added to the equation—much as ink, paper stocks, and such are part of the traditional design equation. You will learn what you need to know in this book and on the job.

The early phase

Earlier, we urged you to get involved at the very beginning of the process. There is one phase in which you cannot participate. That is the client’s own analysis phase. You will not meet with your clients until they’ve sat down

first to figure out their needs. Ninety-nine times out of ninety-nine, those needs will change once you’re involved in the process.

How does the analysis phase operate? Just as in traditional design projects, it typically begins at the highest levels of detail and works its way down. In initial meetings, the focus is on broad strokes (such as, “We’re a community for young women.”). As the project progresses, lower-level decisions emerge (such as, “Should we put buttons or text labels on tertiary search results pages?”).

Though most of us are happiest alone in our cubicles, staring at our monitors and though many of us would rather undergo gum surgery than face another meeting, in many ways this phase is the most critical and creative part of the job. The movement, over successive meetings, from the general to the particular takes place on many levels and extends beyond issues of graphic design and technology.

Many times, even the most sophisticated clients have only a rudimentary and confused idea of what they wish to achieve. In their own realm, they are kings. On the Web, they are lost little children. If your background includes marketing experience and if you have made yourself knowledgeable about the Web, you can guide your clients away from vague or even nonsensical plans and toward worthwhile, achievable goals.

154 WHO: Riding the Project Life Cycle: We Never Forget a Phase

Take a simple project. Your client wants to sell videotapes online. He has lined up a supplier and a fulfillment house, and after a full two hours of online experience, he is convinced that his site will be “the Yahoo meets AOL of online videotape e-tailing,” whatever that means. Because his daughter, an art major, showed him the Monocrafts site (www.yugop.com), a brilliant and beautiful work done entirely in Flash, he figures his site should have “something like that” as well—oh, and a chat room. He read about those in an airline magazine while flying between Seattle and New York last year. He then describes the in-flight movie.

We wish we were making this stuff up, but it happens all the time. Not that this client is necessarily an idiot—he may be brilliant in his accustomed sphere of business. He may even read French literature and know fine wines. It’s just that the Web is a mystery to him, and he’s not used to admitting ignorance on any subject, even to himself. With tact and kindness, you and your team will guide him toward a workable plan. Six months from now, if you do your job well, he may have a fine site that includes movie reviews by Roger Ebert, streaming video clips of selected films, and a thriving movie lovers’ discussion area. But it can happen only if you work with him during the sometimes painful early analysis phase.

Defining requirements

Before all else, the web team must define two types of requirements:

■Technical. These include anticipated performance, bandwidth, security issues, and so on.

■Business. These include needs and constraints (having to accommodate first-time web users), as well as overall marketing objectives.

These requirements are summarized in documents with impressive-sound- ing names such as “Functional Spec,” “Requirements Document,” or the ever popular “Use Cases Document.” And the fun doesn’t stop there: parent documents beget baby documents—all of which will be used to guide initial development, and none of which are carved in stone. The more stuff you figure out, the more you realize you have yet to figure out. Digital projects kill more trees than the Daily News. You will be buried in paper. Read it, absorb it, and set it aside.

Taking Your Talent to the Web

155

Happy families are all alike, but every web project is different. Generally, though, the purpose of early analysis is to define goals, determine constraints and requirements, and establish trust. Without goals, constraints, and requirements, it will be impossible to know if the project is on target. Without trust, you are looking at months of sheer Hell. With trust in place, you may still be looking at months of sheer Hell, but you have a better shot at enjoying the process and creating something useful.

If this sounds familiar, it should. The only difference between analysis in traditional design and analysis in web design is the medium itself. Instead of die-cuts or film transfers, you’ll be discussing bandwidth and browsers.

How it Works: Analysis in Action

Dishes Plus is a regional chain of successful retail outlets, known for its reasonable prices, wide variety, and “break proof” guarantee. Dishes Plus has decided to sell its product online. Naturally, you learn about the company’s existing business, its competitors, and its brand image before the meeting. You and your team help Dishes Plus define large goals (selling dishes), small goals (branching out into soup tureens), and in-between goals (establishing a bridal registry division).

You find out about the company’s audience (mostly women/mostly men, young/old, urban/rural) and sketch the impact that may have on technological and design considerations. If Dishes Plus has a loyal audience of people over 50, tiny type is out, and plug-in based multimedia is probably out as well. If selling is key, technological considerations leap to the forefront and should be examined carefully.

How many clicks from expression of interest to final sale? If the inventory is vast, a search engine will be needed. If Dishes Plus shoppers tend to spend hours poring over the goods, artificial intelligence may be called into play on searches (“If you like the Dixie Deluxe Classic Set, you’ll love the Colonel’s Tea Service”).

Does Dishes Plus anticipate an overseas market? You might need to consider building the site in several languages and using iconography to facilitate navigation by non-English speakers. Do details matter? You can’t assume that the client’s photography is up to snuff. You may need to budget for a good shooter, conversion from photography to digital images, and a database to store and serve the relevant images.