Getting Your Design Built
Kim Goodwin

Review

By Pabini Gabriel-Petit

Cooper generously welcomed the fortunate members of our community who were able to attend this event to their offices, where Kim Goodwin gave an excellent talk about a subject that is of great importance to all digital product designers—getting buy-in for our designs and ensuring that they get built. First, she enumerated various reasons why a product might not get built as designed or even get built at all—some of which are beyond our control—like shifting corporate priorities. However, the substance of her talk was about the many things that we can do to help set the proper scope for our projects and get buy-in for our designs. Important factors in getting buy-in include

• small design teams, following an explicit design process
• getting the level of detail right in your design and deliverables
• doing good design

Small Design Teams

Kim contrasted the nimble Cooper design approach, in which a small team drives the design process, involving the product team as necessary, with the common big-team approach, in which a design team achieves consensus by involving the entire product team in the design process. The big-team approach is communications intensive and, therefore, time consuming and expensive. Kim said, “Code is invisible, except to engineers, but design isn’t, and everyone has an opinion about design.”

As Kim explained, a Cooper design team comprises just two core members: an interaction designer and a design communicator who work collaboratively to

• gather product requirements through stakeholder and user interviews
• develop personas, scenarios, requirements, interaction frameworks, and form and behavior specifications

The interaction designer is primarily responsible for defining a product’s form and behavior, while the design communicator is responsible for providing the narrative for the design, challenging weaknesses and ensuring completeness in the design, and effectively communicating the design and its rationale. Kim described the design communicator as “a thought partner and a bit of a skeptic.” She said, “There are other people who are critically important in this process, but we don’t need them in the room every day.” Depending on the needs of a particular project, a Cooper design team also typically includes a visual designer and sometimes an industrial designer or usability tester as well, and a Design Director or VP is always available to help with difficult problems.

Kim likened the role of a design team to that of a physician, who can diagnose a problem, prescribe a cure, and try to persuade the patient to follow the prescription, but has no control over the patient’s decisions. She said, “Even if you do great, compelling design, people have to buy into it. You have to persuade people that this is the right idea.”

An Explicit Design Process

Kim described the phased design process that Cooper follows, which includes

• researching the domain—building buy-in by
  • involving key stakeholders and decision makers at the executive level—preferably the CEO or a VP
  • doing ethnographic research
  • initiating communication with the product team early
• modeling users and defining requirements—helping the product team develop a shared understanding of “the big issues”—such as user needs and product scope—“based on actual data, not opinion”
• defining the framework of the design solution—which includes conceptual modeling of solutions that meet the needs of users, as represented by personas, the development of scenarios to validate conceptual models, and visual design—enabling the product team to “see the big ideas early” and raise issues
• iteratively designing and specifying the product’s form and behavior—which includes the development of scenarios to validate the design—letting everyone see “how the product should look and behave” so you can
  • do usability testing, if necessary
  • work collaboratively with developers to ensure the design’s technical feasibility within the project’s timeframe
  • get stakeholders’ support for the design
• supporting developers—providing “design consultation on implementation priorities and trade-offs” and creating any additional documentation that the developers need

Kim talked about the importance of having adequate time for design, saying, “Ideally, not a line of code is written until you at least get to the Framework stage. You need to get design a jump ahead of development.” To achieve that, it may be necessary for the design team to “ignore an incremental release or two. Most companies do design and development in parallel, putting pressure on design teams to rush out something, because the engineers are just sitting around idle. Design should be at least one revision ahead of development. It can be difficult to get management buy-in to skip a design cycle and let engineers complete the current revision using existing designs in order to get design ahead of development.” Another way of achieving this is to “get developers working on proof of concept” during design.

In describing how Cooper gets buy-in, Kim said that the interaction designer is responsible for presenting the design framework to the product team. He or she has to be prepared “to defend the design on the spot. … This is the most terrifying step for stakeholders. You have to build the rationale. Use scenarios to explain your design. Talk about how you got there and why it’s good. Use personas and human factors studies to justify your design ideas. ‘Because it’s cool’ or ‘because I say so’ are never acceptable justifications. Ask engineers, ‘Does anything in here terrify you? Is any of this impossible to build in the timeframe?’ Engineers will accept it when you have a thorough design rationale. … If you’re confident about the design, that’s going to show.”

About the design process at Cooper, Kim said, “You have to wait until a certain amount of interaction design is done before you can do visual design. Otherwise, it’s like trying to paint a house with no siding.”

Kim recommends, “If operating under a tight budget, try to convince management to spend more money on design and less on usability testing, unless you are designing a mission-critical product like an airplane or a medical device, where usability testing is of critical importance and usability errors may be life threatening. If you have a limited budget, spend more of it on design, because you’ll get more value for your money. Usability is to design what quality assurance is to engineering. It can’t replace good design.”

About getting buy-in from developers, Kim said “It’s a good sign when … most of the questions are about what people don’t see yet, not about the parts you’ve designed. … Technical constraints are almost always time and money constraints. … It’s better for you to find alternate solutions than to have developers do it. It’s a good sign when developers call and ask you for help. That means they respect you and think you can help them.”

About Personas

At Cooper, the creation and prioritizing of personas is key to user modeling. Kim stated, “There are a few misconceptions about personas. … If you have different products, you need different personas.” While personas are based on real data about users’ observed behavior patterns, they represent “archetypal users—a distillation of what you’ve really seen.” It’s important to avoid edge cases. Personas eliminate elasticity in the product team’s conception of the user. As Kim said, “Personas last for years. You want them in a persistent form. … Personas are a powerful team-building tool. … Developers are still skeptical about personas.” You know your personas have buy-in when

• you hear developers say, “I know somebody just like that.”
• stakeholders say, “I see my ideas in there, but I never said it so clearly.”
• team members “start using the personas’ names or want to make persona posters or T-shirts”

In talking about satisfying users’ needs, Kim said, “Features are meaningless. They mean nothing to users. A coherent product user interface is the product to users.” She compared the results of developing products to satisfy lists of required features to the Winchester Mystery House in San Jose, California, which grew by accretion and has stairways that go nowhere and unexpected precipices.

The Right Level of Detail

Clear communication of design rationale and specifications that are sufficiently complete are essential to getting buy-in. Kim made it clear that “the more detailed the design (and the documentation), the more likely it is to survive implementation.” She said that incomplete specifications are a common obstacle to getting buy-in. Kim thinks that, in Form and Behavior Specifications, “pictures and text communicate better than either one alone.”

According to Kim, experience at Cooper shows that “clients who get partial design take a lot longer to ship a product. More design is cheaper than less design. The more design we give our clients, the faster they can build, and the more faithful they are to the design.”

The right level of detail in your design and deliverables varies depending on the needs of a specific project. Kim elaborated, “For experienced developers familiar with the domain, you may get away with a few holes. For offshore development, distributed teams, or less experienced teams, you won’t. The bigger the development team, the more detailed you want the specifications to be.” Kim thinks designers should ideally draw every screen “down to the pixel,” draw and document every state of every widget, and document detailed error handling. However, it usually suffices to draw “every archetype screen … in its most common state … down to the pixel,” draw “every non-standard widget … in every state,” document all “non-standard behaviors,” and provide “a set of principles and guidelines for extrapolating the design, plus its rationale.”

Kim emphasized the need to explain design rationale. “Sell the design. If someone understands why this is good, they’re more likely to stick to it.”

What Makes Good Design?

Kim explained that, when evaluating good design, we must balance what serves the user best with business goals. “If a client is involved early in design and design ideas are effectively communicated during the design process, when the detailed design specification is delivered, nothing in it should be a surprise to the stakeholders in the client company.

“We need to push on presumed constraints, but respect the ones that are real. The better partnership you build with developers, the better off you are.” Assess developers’ skill level and, if necessary, provide less ambitious design solutions. If an engineer says something that is important to usability is technically infeasible, “let the decision-makers make the trade-off choices. Ask programmers, ‘What would it take to do this?’ not ‘Can you do it?’—so engineers get involved in problem solving. Pull in the CEO to make a business decision.” Set priorities. “Document which things are ‘must haves’ and which are ‘nice to haves’.” Focus your effort on key screens.

Kim suggests that we “temper our idealism with pragmatism.” We need to balance ideal design with business objectives. “Somebody’s got to be willing to go out on a limb and say it ought to be like this and defend it. If there’s a sticky point, test it. But don’t test every design decision, or you’ll never get anywhere. You’re going to get more bang for your buck when you spend more on design than testing.”

Style of Delivery

Kim Goodwin is a gifted teacher. She develops her ideas very logically and completely and communicates with great clarity. During her presentation, she told stories about Cooper projects—without mentioning any company or product names—interjected humor, and engaged in dialogue with members of the audience, keeping things lively throughout. In Kim’s view, “Every question is a good question.” If you get the chance to hear her speak or take a class with her, I strongly recommend that you avail yourselves of the opportunity.

Original Announcement

While doing great design is no easy task, sometimes the hardest part of a designer’s job isn’t figuring out how the product should behave and look—it’s persuading everyone else that the direction is right and keeping the final product true to the design intent. Every organization is different, but many people are surprised to see how many organizational tendencies and challenges are common across companies. Kim Goodwin will talk about how Cooper has used its design process to build buy-in across hundreds of projects.

• How research, personas, and scenarios work as communication tools
• What design team and larger product team structures are most successful
• What formal deliverables and informal collaboration methods are most effective
• What approaches and techniques are less likely to work
• A comparison of tactics for external consultants versus internal team members

Visit Cooper, the firm that pioneered personas in interaction design, and meet their staff of interaction designers, visual designers, and design communicators. This is your opportunity to experience Cooper up-close and personal.

Cooper, the Interaction Design Group (IxDG), and BayDUX were co-sponsors of this IxDG Face to Face Silicon Valley event. Its organizers were Pabini Gabriel-Petit and Frank Ramirez.

Kim Goodwin is vice president of design and general manager at Cooper. Her design expertise and teaching skill have made her a popular speaker at universities, corporate events, and conferences, including CHI, STC, and various UIE events. At Cooper, Goodwin applies her years of experience as a creative director to ensure excellent delivery of Cooper’s design consulting and training services. Goodwin has played a major role in developing Cooper’s goal-directed methods and has led the effort to turn those methods into the Cooper U interaction design curriculum. Goodwin has led a wide range of design projects, from e-commerce applications to information appliances, IP telephony systems, and healthcare applications. In addition to her work with clients and industry leadership, Goodwin provides career management to designers, works to improve Cooper’s design methods, and keeps the company running smoothly. She is a member of the IxDG Advisory Board and a former member of the IxDG Steering Committee.