INTO THE FLOW

Here we go into the belly of the corporate beast! That was my thought as I began this week’s readings on digital design in the business world. Immediately I began to stumble over strange words and concepts like “deliverables,” “functionality planning” and “workflow management.”

“Deliverables” is an example of how corporate newspeak retrofits language, turning adjectives and verbs into nouns and nouns into verbs. I suppose “deliverables” is a convenient term for all sorts of things that get delivered during a project, such as proposals, reports, prototypes, etc., but imagine this memo: “To all departments – please deliver deliverables as soon as they are deliverable.”

I always assume that people design things to be functional, without need for “functionality” planning. I guess if they don’t sit down and do such planning, they may end up making stuff that has what Thomas Shelford and Gregory Remillard so wonderfully call “whacky functionality.”

As far as “workflow,” I have never experienced it. I’ve worked; I’ve followed procedures; I’ve made progress and I’ve completed tasks, but I don’t think I have ever flowed. I drew the cartoon above to show my impression of what “workflow management” might look like.

In Shelford and Remillard’s chapter on “Web Team Roles,” I was struck by how many different jobs there are on a web development team. Developing a complex website for a big organization must be somewhat like producing a motion picture, where there are also many jobs with a lot of overlapping functions and fine distinctions between similar roles. What Shelford and Remillard call a Project Stakeholder is what people in the film industry call the Executive Producer: the money guy or the studio boss. A web team’s Project Manager and Producer are comparable to a film’s Producer and Director, respectively, who do a kind of dance together as they balance the logistical and creative decisions of a project.

The rest of the team perform similar dances in both web development groups and film crews, with passionate graphic designers and art directors who cry “I must have this!” butting up against pragmatic HTML developers, cinematographers and electricians who reply, “okay, but it’ll cost ya.” I chuckled at the similarity between a web team’s Quality Assurance Group and a film’s Continuity Person (called the “script girl” in the old days), who must go up to the Cecil B. DeMille after he yells “Cut!” on the parting of the Red Sea, and squeak, “Excuse me, sir, but you’ll have to do that again because Moses had his stick in the wrong hand.”

The complexity of relationships on a web development team, with all the possibilities for conflict and office politics, reminded me of why I got into documentary-style filmmaking, where I could work pretty much alone. I hope that similar opportunities for loners exist in small-scale Web design.

No matter how many hats you can wear, however, you always end up working with somebody else in the long run, such as a client. In “Web Re-Design 2.0,” I liked Kelly Goto and Emily Cotler’s advice on how to put questions to clients and look out for “red flags” in clients’ expectations. I recognized some of those red flags in clients I have had. Particularly amusing is the client who “doesn’t know what the content should be but wants it to look cool.” This is exactly the kind of response I get from my high school video students when I ask them what kind of video they want to produce in class: “I know! I know! Let’s do something really cool with a lot of really cool action and some really cool music!”

Actually, I have been extraordinarily lucky in the clients I have had over the years – maybe because I haven’t really had all that many. Most of them have been very cooperative and down-to-earth and have given me a lot of creative freedom.

For the last five years I have had the absolute dream client. Each year around May she calls me up with the names and phone numbers of two people about whom she wants me to produce video biographies. Long ago we agreed on basic procedures and prices, so now we don’t bother with contracts, proposals, progress reports or any of that stuff. Off I go, traveling around and doing my work, seldom speaking to my client until I send her two finished products in early September. Occasionally she will need a tiny tweak, but usually she just emails me, “looks great; send me your bill,” and that’s it. Some years we don’t even see each other at all until the big charity ball in October where the videos are screened.

Doing business is seldom as simple or as sweet at that. I gulped when I read about the client surveys and audience research Goto and Cotler advise website developers to do. At first I was skeptical about the need for gathering all that background information, thinking it was just a way to justify more “billable time.” Then I turned the page and read about the ramifications of different browsers, screen sizes, computing speeds, bandwidths and so on. I thought we had it bad in the video world, where our biggest worry is what kind of video monitors our viewers have, and whether their brightness, contrast and color balance will be adjusted correctly. The possibilities of a website designer’s work getting “lost in translation” seem so much greater.

So much to do before we even begin talking about design! So much before we even start thinking about all the technical challenges that lie ahead! The little stack of unopened Dreamweaver software and tutorials beside my computer is starting to cast a long and ominous shadow across the room.