D E S I G N J E R K
the design communicator role at cooper
Note: This summary was written while I worked at Cooper; thus the use of present perfect tense.

Designers at Cooper generally fall into one of two roles: Designer (D) or Design Communicator (DC). (The D and DC monikers are only internal designations—we are all known as Designers outside the company.) One Designer and one Design Communicator form the core of a Cooper design team; a band of supporting players perform various other project-related duties, but the two designers are essentially responsible for the quality of the design and the success of the project.

Typically, I work as a DC. The distinctions between the two roles can be blurry, however—especially across projects—and I've played the part of Designer on several occasions. In general, though, as a Design Communicator, I'm part researcher, part interface designer, part writer, part business consultant, and part project manager.

Our projects typically start with a research phase in which we gather intelligence about all things related to the product or problem at hand. We investigate the domain of the product or service; we analyze and synthesize user needs, goals, and trends; we capture the vision and business goals of our client; and we delve into the technical constraints and opportunities. This phase can last anywhere from an hour to a day to three months, depending on the timeframe and the complexity of the domain. Often (and ideally), our research includes numerous interviews with stakeholders, subject matter experts, and, most importantly, customers—the people who will ultimately use the thing we design. As a senior staff member, I often lead these interviews, while my partner captures the salient points of the discussion and asks follow-up questions. We also review any potentially relevant written materials we can get our hands on. Our aim is to understand all the issues involved to the degree that we can ask intelligent questions, draw well-formed conclusions, and make smart decisions.

When our research is complete, my teammate and I begin distilling it into the key concepts and ideas that will form the foundation of our design work. We summarize and reflect back to the client what we heard as their main concerns and goals, and we develop fictional characters called personas that represent the needs and goals of users. When we're getting our heads around the issues, we work primarily at the whiteboard and through discussion, but when it comes time to collect our thoughts, I shift into writing mode.

At the end of a research phase, we typically deliver to the client a document that summarizes our findings and conclusions. More than just an outline or bullet lists, this deliverable is often a 40-60 page document written in rich, descriptive language accompanied by diagrams and other visuals. While my teammate and I generate the concepts that go into the deliverable, I am responsible for both developing the structure and composing the content of the document. Additionally, I often co-present the work to the client (via PowerPoint).

After making sure we are in agreement with the client on the scope and direction of the work, we begin designing. Our first objective is to develop the conceptual model of the product that best meets the needs and goals of our personas and the business needs of the client (even if we are only delivering a low-level interface design, we first think about the entire experience the product will, or should, deliver to the user). At this stage, the design is very nebulous and sketchy. My teammate and I meet for long hours, filling whiteboards (the designer's best friend) with scribbled ideas, notes, directions, and interface layouts. The design may look completely different from one day to the next, until we finally hit on the framework that (almost magically, it seems) satisfies all of the objectives. In these meetings, I put on my facilitator hat: I make sure we're discussing the right things, that we don't veer off (too far, anyway) onto tangents, and that the needs of the users are being accounted for properly. The fun part is balancing these responsibilities with contributing ideas of my own and asking clarifying questions in pursuit of the best design solution.

Next, to avoid going in a direction that is not technically feasible or that is otherwise undesirable, we present our conceptual model to the client. Usually this takes the form of a PowerPoint presentation, which my partner and I create. Although there is no formal document at this stage, effective communication between my team and the client is crucial to ensure the final design we deliver satisfies everyone's needs; it is my responsibility to see that the client fully understands our design concept and that we, in turn, fully understand any suggestions, questions, or objections they may have. Later on, I make sure the client's concerns are adequately addressed in the design and our documentation.

The remaining phases of the project center around fleshing out the design framework. Step by step, my teammate and I move through the various elements of the design, refining them to greater and greater levels of detail. During this period, we share the challenge of solving the design problems equally—a person wandering by during a design meeting would be hard-pressed to figure out who is playing which role. We work collaboratively at the whiteboard, hashing out potential solutions to design problems by drawing different layouts of information, interface widgets and tools, and process diagrams (on longer days, after we've gotten a bit loopy, the boards also include cartoons and bad dot-com company logos)—whatever it takes to figure out the most appropriate design for the user. Back at our desks, our roles become clearer again: my teammate generates refined, pixelized versions of our whiteboard sketches, while I document (usually in raw, outlined notes) our decisions and technical descriptions of the behaviors and appearance of each interface element.

The degree of detail we deliver to the client at the end of an engagement varies depending on the scope and length of the project. Generally, though, we deliver a final document that describes, in an appropriate level of detail, our design and how it works. Sometimes this document takes the form of a series of scenarios in which we describe the personas' use of the product with text and screen sketches. On longer projects, we will follow a scenario-based document with a design specification that provides descriptions of every interface element and its behavior in detail sufficient for developers to begin coding the actual product software. Sometimes, the client will request just one or both of these documents. In either case, I am again responsible for generating the written component of the document(s) and for organizing all of the content into a cohesive, understandable deliverable. Occasionally, we will produce demos that highlight and animate certain features of the design or that serve as interactive prototypes, either in lieu of or in conjunction with a written deliverable. My teammate and I work together to create a script for these demos and work closely with a visual designer/animator to produce the final piece. Finally, we present our last deliverable to the client and, depending on the circumstances, spend a few hours to a few days going through the design to help make sure the transition from design to implementation goes smoothly.

Throughout any design project, I also perform certain project management duties. I make sure all the project materials and resources are organized and available to my teammates and colleagues, I handle communication with the client (including fielding questions and coordinating meetings), and I work closely with our account manager who is responsible for financial and contractual issues.

The Design Communicator role is unique in the design industry—few other jobs in the field require you to write extensive documentation, present complex work to a demanding audience, manage project timelines and resources, research foreign and widely varied domains, work collaboratively and ego-free, and develop intelligent design solutions that satisfy the needs of client and users.

Back to my resume
Back to my portfolio