Early and often: how to avoid the design revision death spiral

One lesson we’ve learned over the past several years here at Cooper is that on the vast majority of our projects, intimate client collaboration is a critical ingredient for success. This is a lesson that we have sometimes learned the hard way; collaboration can be messy, unpredictable and has often forced us to compromise what we thought was a supremely clear and elegant vision. Despite these growing pains, we’ve learned to embrace the unpredictability and compromise; through well-managed client collaboration, our designs are stronger and are more likely to serve our clients’ needs and satisfy the goals of end users.

Our objective in client collaboration is to work together to design the most effective, innovative solutions that meet user and business needs. Some of our clients have a good sense of what their customers are looking for and what they will find desirable and useful. Our clients also often have fantastic ideas and we are thrilled to incorporate these into the designs.

As David Kelly puts it, "Successful design is done by teams. Creative leaps might be taken by individuals, but design thrives on the different points of view found in teams. You want a multidisciplinary team… You want different brains working on the problem. Otherwise, the person with the power, or the person who speaks the loudest, sets the direction for the whole design." [1]

It is in this spirit that we endeavor to involve the best thinking of different stakeholders in the design process. As designers, we not only must provide the creative force, but also must serve as facilitators in group problem-solving and creation activities.

An equally important outcome to collaboration is to build support for the proposed solution and to foster a sense of ownership on the part of the clients who must carry our work forward. Software construction is a difficult and costly process. For us to be able to serve end users, obviously our designs must first be built. Building support and commitment to the designs is critical to ensuring that the end product resembles our specifications. This sense of commitment and ownership is best developed through an intimate involvement in design activities. Decisions are less likely to be second-guessed down the road if the appropriate people are involved early on.

Finally, it is critical to our clients’ business (and our own) that we are able to do this according to a predictable timeline. As I just mentioned, software construction is expensive—dramatically more so if scheduling becomes confused and disorganized. Therefore, while it is absolutely crucial that we develop solutions that incorporate our clients’ knowledge and insight, it is equally important that we incorporate this knowledge and insight within the confines of the project schedule.


As much as we all have our clients to thank for our very livelihoods, I’m sure it is the rare designer who has never said to himself "this would be a great project, except for the client." Without turning this entirely into a collection of designer war-stories and picaresque adventures featuring clients with personality disorders, I’d like to discuss some of the more common ways in which client feedback and collaboration can seriously derail a project.

The revision death spiral

The objective of iterative design reviews is to narrow in on the appropriate solution, using the decisions of one meeting to improve the breadth, depth or fidelity of the solution for the next meeting. The most common affliction I’ve seen in the world of design at large is the "revision death spiral," where designs are repeatedly revised without any progress towards a coherent solution. The symptoms here are easy to recognize: an initial visual design direction review where the client "doesn’t like" any of the proposed approaches; or subsequent meetings where the client decides that the currently chosen path should be scrapped in favor of a previously abandoned path. If every meeting involves re-considering first assumptions or second-guessing previous decisions, it is impossible to move forward.

Unfocused and unspecific feedback

A second challenge I’ve repeatedly encountered in collaborating with clients is that of receiving and trying to act upon unfocused and unspecific feedback. It is rare that a client is sufficiently knowledgeable about interaction and visual design to articulate their reaction to a proposed solution or approach. Also, many clients I have worked with have had a hard time focusing on the appropriate level of detail—early in the project they want to discuss the intricacies of one small widget when the design team is trying to come to resolution about the overall interaction framework.

Preconceptions and prejudgments

At times, preconceptions and prejudgments can be somewhat difficult to sort out from expectations, but they’re easily identifiable for their specious rationale. When a client assumes that, for example, a business analytics application should have an "executive dashboard," without any research to suggest that this functionality satisfies an observed user need, that’s a potentially harmful preconception; it can impede progress on designs of functionality that does support user needs and goals.

Other kinds of preconceptions can arise from technology choices or other successful (but unrelated) products. For example, it is a common assumption that just because an application is delivered through a browser that it should behave like a Web site. (There was the C-level executive at one client company who believed that a common use of an enterprise application platform should be to "browse for functionality.") And I don’t even want to think about how many clients believed that their problems could be (inappropriately) solved by the use of a Windows Explorer-style hierarchical tree.

Compromise does not always lead to the best solution

In observing political enterprises the world over, it’s clear that consensus-building and negotiation do not always lead to the right answer. Effective and compelling design solutions are often thought of as such because of an underlying conceptual integrity. Compromises can undermine this integrity, reducing the effectiveness of the solution.

When decision-making is diffused among a committee, the variety of interests in the committee often necessitates compromise in the design. The smaller the group of decision-makers, the more focused the mandate, and the less stress on the integrity of the design.

No accounting for taste

The final challenge that we have attempted to overcome in our practices is the situation where client feedback is based upon personal taste, rather than an assessment of the design’s potential satisfaction of user and business goals.


So, in the face of these challenges, how can a design team collaborate effectively with its clients to produce a solution that ultimately meets user needs and business goals? Over the past several years, we’ve refined our methods and processes in several ways to improve our abilities in this regard.

Manage your communications

In the early days of Cooper, several designers would pack into a meeting room, excitedly come up with piles of good ideas, and when they eventually were too tired or bloodied to continue, they would walk out leaving the valuable work on the whiteboard, ultimately recalling the tree-falling-in-the-woods question: "If a bunch of designers come up with some good ideas, but no one is there to communicate it to the client, do the ideas even exist?"

Since those days we have developed the role of the design communicator. The vast majority of our design teams feature at least one interaction designer and one design communicator. Where the interaction designer is ultimately responsible for the conceptual integrity and visual renderings of the design solution, the design communicator’s primary responsibility is to ensure that our solutions and ideas are clearly communicated among design team members and to our clients.

Numerous times, I have seen strong design fall flat in the face of client feedback because its virtues are not clearly communicated. It is not enough to merely stick one’s work in front of the client and ask, "Whadya think, do you like it?" We have found that it is critical to clearly articulate several things as part of any design review:

  • Which aspects of the screen or device are being focused on
  • How the solution behaves (a single rendering is often insufficient here)
  • Underlying assumptions (including technical)
  • Strengths and motivations of the proposed solution
  • Known issues and items still under consideration
  • What decisions are under consideration
  • Possible decision-making criteria

Some designers may feel that I’ve omitted something crucial from this list—other possible solutions. This is intentional; while there are certainly situations that call for the presentation of multiple competing solutions to an interaction design problem, we generally show our clients the single solution we believe to be the most effective and compelling. We may verbally discuss other approaches we consider, and why we favor the proposed solution, but when possible we prefer not to spend our clients’ money exploring multiple solutions, if we think we know the right answer. (Also, it should be said that when it comes to visual style, we almost always use the traditional three-directions approach. This often does come down to taste to some extent.)

As a final note on the subject, I’d like to add that while it may sometimes seem like clients are not concerned with such information as part of a design overview, we have found that it is critical to provide it nonetheless. The design team’s ability to facilitate lasting decisions is dependent on how well a client is informed when they make those decisions. If a client has failed to consider critical information before making a decision, there is the distinct likelihood that they will have to reconsider their decision when eventually faced with that information, possibly upsetting days or weeks of subsequent design work.

Get the right people in the room

Is this too obvious to mention? Maybe, but it is absolutely critical that client representatives in design reviews and collaborative sessions have some decision-making authority over a product or project. Of course, at many organizations, decisions are made by committee, in which case it is sometimes useful to have a smaller subset of the committee be part of design reviews, while at other times it is preferable to include the entire group.

When it comes to work in the studio and collaboration with clients, we attempt to maintain a balance between small design teams and larger cross-functional teams. Initial ideation and framework design is very difficult to do in a large group—this is where conceptual integrity is critical, and while some divergent thinking is crucial for creativity, large groups tend to be uncontrollably divergent, making it impossible to establish momentum or direction. We are also somewhat hesitant to perform initial design framework development with clients because we’ve run into situations where very senior client representatives grow quite attached to initial brainstorm ideas that subsequently turned out not to be satisfactory solutions. This can introduce unnecessary friction into the management of the design.

Consequently, we prefer to do our initial work in small, agile teams in the studio, with a single client representative if necessary. Once we have something that we think hangs together we involve a small number of strategically chosen client representatives to refine our ideas, and when they are satisfied, we open feedback up to a larger group.

At this point, it really starts to kick in: the client representatives who were involved in the development of the solutions create a crucial bridge to individuals in the larger group, helping wrangle divergent (and potentially divisive) interests.

We try to make all of the strategic product definition and interaction framework decisions early in the design process, and then move inwards to progressively more detail about specific aspects of the interface (more on this below). As a result, we generally find it useful to have the more strategic client representatives such as product management and software architects part of our meetings early in the design process (when we are deciding what the product will do), and more detailed, execution-oriented people as part of the later meetings, as we get down to the nuts and bolts of how the product will look and behave.

Finally, as I’ve already mentioned, developing commitment on the part of clients to the agreed-upon solutions is an absolutely critical part of the designer’s role. In his classic Flawless Consulting, Peter Block discusses how developing client commitment should always be a goal of the consultant. "We may cling to the fantasy that if our thinking is clear and logical, our wording eloquent, and our convictions solid, the strength of our arguments will carry the day. Clear arguments do help. But they are not enough. The client and his or her colleagues will experience doubts and dilemmas that block commitment." Block then continues to describe how the best way to overcome resistance is to confront these doubts at every stage of the process through effective collaboration. [2]

Planning and scheduling

The vast majority of our large projects are contracted on a fixed-fee, fixed-schedule basis. As part of the sales process we use our methodology as a basis for scoping and scheduling our work down to the day. What this means for managing client feedback and collaboration is that we are able to predict which subjects will be discussed with clients on which days, and we are able to make sure we are able to get on decision-makers’ busy schedules. We are then able to plan our work in the studio around this schedule. (Of course, unanticipated challenges always arise, forcing us to do a little juggling.)

We’ve found that working according to a pre-defined schedule helps motivate clients to commit to decisions by clearly illustrating the impact of delay. If our clients are unable to make a decision according to the schedule, they are presented with a choice between following our recommended course of action and extending the duration of the project at increased cost. In other words, we tell them where we are marching, then march there according to the schedule, unless specifically directed otherwise. For an overview of project structure and collaboration points, see Figure 3 at the end of this paper.

Collaborate early and often

One of the problems we recognized with our former practice of minimizing client involvement until formal presentations is that no one likes to be surprised. We now try to involve our clients as soon as we have something that is substantially coherent. The benefits here are twofold: we have more time to accommodate the feedback, and clients become more committed to solutions that they have been involved in developing, thereby reducing the chance of getting torpedoed at a major milestone check-in.

We also endeavor to maintain frequent contact with all client decision-makers. We find that if we help them keep their heads in the game, they have an easier time understanding the critical issues and are better equipped to make decisions.

Structure meetings around specific decisions

Rather than simply exposing our clients to our work-in-progress (in whatever state it happens to be), we attempt to build every collaborative session around making one or more specific decisions. As a result, we can structure our preceding work to explore possible solutions, determine our recommendations and develop appropriate supporting information and materials.

Further, by working towards set objectives in each meeting, we are able manage the length of each meeting and minimize unfocused and off-topic feedback. Focusing discussion on particular decisions also helps clients be more specific in their feedback, and helps to ensure that designers leave the collaborative sessions with clearly actionable direction.

Involve key stakeholders early through interviews

Some client stakeholders simply want to be heard and ensure their perspective is factored into the new product. If their first opportunity for involvement is a design review session, they may object to a proposed solution simply to make their presence felt.

To mitigate this possibility and to ensure we are considering the valuable viewpoints of all stakeholders we begin each project with a series of one-on-one stakeholder interviews where we discuss their vision, objectives, and concerns. Not only does this help us to further understand the brief, but it also helps us develop a vocabulary to express the value of our designs in terms of client objectives.

It is rare that a client is primarily motivated by "good design." Rather, as Cameron Foote discusses in an article for the Design Management Journal, clients commonly desire for design consultants to "take more of an interest in [their] organization and its markets. Not just what you need to know to complete the design project you’re working on, but our business, our industry, how we operate, and what our challenges are." [3]

Use personas and scenarios to provide context

Personas and scenarios are among the most powerful tools available to an interaction designer, and there are a variety of different instantiations of the concepts floating around out there. At Cooper, we mean something very specific when we say "persona." Personas are archetypal user models: they are fictional characters that are based upon real behavioral patterns observed during ethnographic user research, that are developed in such a way that a single persona represents the goals, needs, attitudes and aptitudes of a large group of actual users.

When it comes to client feedback and collaboration, personas help us maintain the proper context for assessing the fitness of a solution. Rather than relying on personal taste or aesthetic judgment, we are able to assess a design on the basis of whether it helps a user achieve her goals, and whether she would find the experience pleasurable or compelling. We typically introduce a design solution by describing a persona going through a scenario where she uses the product to accomplish something. We find this to be a much more persuasive rhetorical technique than simply showing a single screen and asking for feedback.

A strong complement to the use of personas is the addition of several real-world scenarios. Once we are satisfied that the design serves the needs of personas (who may reflect one or more of these real-world scenarios), we are also interested in how the product is able to achieve the desired outcomes of actual customers. Again, this can be an effective tool for focusing collaboration. If the client voices a concern about an aspect of the design, we always bring it back to actual human needs; doing this ensures that we will know how to solve the problem and satisfy the concern.

As Hugh Beyer and Karen Holtzblatt (among many others) describe, research-based models of user needs and workflow give developers and marketers the information they need to define and structure a product. [4]

Of course, personas are not a magic bullet. Applied incorrectly, they can cause as much thrash and confusion as they prevent. Common mistakes we have observed in the use of personas include not basing them in actual user research (in which case they just become a vehicle for prejudgment and untested assumptions) and not choosing them to be sufficiently archetypal (for example, choosing a computer programmer as the primary persona for a consumer music sharing service).

A classic example of this phenomenon returns us to the case of the executive who believed that a common interaction with his company’s business analytics platform would be for users to search and browse for functionality. To support his perspective he developed a persona named Penelope who (for an apparent lack of actual job responsibilities) spent her day looking around for novel ways to use enterprise software. Penelope was not based on user research, and did not represent the needs of any users we encountered in our 2 month long round-the-world research expedition. Designing the software to meet Penelope’s needs would have had seriously detrimental effects on its ability to satisfy actual human needs.

Define and agree upon the problem before defining solutions

Having defined and agreed upon a set of personas, our next step is to methodically define product requirements before attempting to render a solution. The goal here is to build consensus around what the product must do before discussing possible solutions for how the product does it. By doing this, we are able to compartmentalize the decisions that must be made in the course of product design. Without such compartmentalization, clients are generally forced to respond to the "what" and the "how" simultaneously. It isn’t surprising that this conflation can lead to unfocused, unspecific and un-actionable feedback. Further, if the design team has any part of the "what" wrong, clients often articulate this by objecting to the "how." This is a surefire ticket to the revision death spiral.

In an article discussing how medical research methodologies can effectively serve as the basis for design research, Andy Schecterman describes how particularly complex or "chaotic" problems aren’t effectively solved by linear protocol- or pattern-based approaches. He argues that a "…nonassumptive approach is critical; drawing conclusions or moving toward proposed solutions too soon means going back to the drawing board." [5]

To be clear, it is important to differentiate what I am referring to as a "requirement" from a feature of the product. We often use "need" and "requirement" interchangeably as an abstract description of a product capability. We try not to conflate the need and the solution because doing this can stand in the way of truly creative breakthrough solution. (For example, at a grocery store, the need is "remember what to buy"; the solution could be a paper list, a PDA or a shopping cart console that talks to the smart refrigerator in the user’s home.)

We define requirements in an analytical manner (rather than synthetically), to ensure that each and every requirement is tied back to one of several sources:

  • A specific action or information need of a persona in a scenario
  • Personas’ attitudes, aptitudes, goals, environments and mental models
  • Business goals
  • Technical architecture and infrastructure

Once again, by developing this type of accountability to users and real-world conditions, we are eventually able to tie every aspect of the user interface back to personas and the business. This takes personal taste and preference out of the equation, helping the design team to lock down the "what" on a logical basis, before moving on to the "how" where they have the freedom to be very creative and divergent because they can are always able to return to a solidly agreed upon set of requirements as a touchstone.

Figure 1. This table from a Cooper User & Domain Analysis document depicts the connection between requirements (right column) and user scenario actions that motivate the requirements (left column).

Develop visual renderings in progressive detail

There’s really nothing more frustrating than showing a client what is intended to be a rough sketch of the big picture and having him or her get hung up on the visual style or a specific icon. For this reason, as our design process starts at the big picture and works inwards to define more and more detail, we are very sparing with detail in our high-level sketches.

In fact, we have developed visual styles and templates specifically for the rough napkin-sketch phase of the process (which we refer to as "Framework Definition"). These visual styles have rough edges and are designed not to require pixel-level attention to detail, and as much as possible, the style of these renderings is that of "no style whatsoever." Once our clients get over the question of whether we’re actually suggesting that their product be tan and brown, we find it much easier to focus on the important question at hand: does the big picture solution achieve the previously agreed-to requirements?

In a nutshell, the renderings must strike the fine balance of providing enough detail for the group to imagine how the proposed design solves the problem, but not so much detail that they get hung up on specifics. This concept is somewhat similar to the use of "wireframes," but I would like to point out one significant difference. While there are clearly many different flavors, wireframes are often intended to be a functionally complete depiction of interface elements devoid of visual style. While we certainly do find these useful at times, they do not satisfy the need of addressing the big picture without getting hung up on specifics.

Figure 2. Progression from the Framework-level to final rendering. Note how the orientation of major elements has changed. (Omitted are several interim versions of the Framework rendering.)

As with the requirement definition phase, the goal with progressively detailed renderings is to lock down decisions before moving on to another layer of detail. However, it may be more difficult to compartmentalize decisions here. It can certainly be the case that the group is leaning towards a given solution but more detail is necessary to make a final decision. At this point, we by all means take the next step to exploring additional detail.

Be willing to throw things out

A final realization I have made in coming to grips with client feedback is that the process is much easier if the designer is able to maintain a certain professional detachment from the solution. Of course it is critical that designers express energy and enthusiasm for the proposed ideas, and that they argue persuasively for the solution they think is best, but nothing contributes to difficulties in collaboration and consensus-building quite so acutely as inflexibility and intransigence. In fact, I have sometimes found clients to rush to the defense of previously questionable design solutions in light of my own willingness to throw them out.


When it comes down to it, every client and project is different, and this Practice Study is intended not as a recipe for success, but rather a list of ingredients. Ultimately it is up to design firms and the businesses they work for to structure projects in such a way to ensure timely and effective decision-making and design refinement. Project plans must accommodate the unpredictability that can accompany collaboration. Quite simply, collaboration takes time, and if that time is taken away from design work, then the collaboration may be for naught. Success, then, depends on design firms’ ability to be entirely transparent with clients during the pre-sales and scoping process. Strive to articulate the assumptions that inform the structure of the project—if we designers can clearly articulate the value of time devoted to accommodating collaboration, and the risks of eliminating room for discussion from the schedule, then we can feel confident that our clients will make the decision that best meets their business needs.


[1] Kelly, D., Hartfield, B. The Designer’s Stance. Bringing Design to Software, Terry Winograd, ed. New York, NY: ACM Press, 1996. p. 159
[2] Block, P. Flawless Consulting 2nd edition. San Francisco, CA: Jossey-Bass Pfeiffer, 2000. p. 21
[3] Foote, C. Thinking More Like a Client. Design Management Journal, Volume 14, Number 3. p 44
[4] Beyer, H. Holtzblatt, K. Contextual Design. San Diego, CA: Academic Press, 1998. pp. 205-208
[5] Schechterman, A. Good Medicine for Good Design: Evidence-Based Planning. Design Management Journal, Volume 14, Number 3. p. 66


Figure 3: Cooper process overview with key design activities and collaboration topics

This article was first presented at the DUX 2005 conference in San Francisco, California. Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. To copy otherwise, or republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee. Copyright © 2005 AIGA | The professional association for design.
Dave Cronin

Learn more

Subscribe to our mailing list and stay up to date on our latest thought leadership and learning opportunities.

Connect with us

Want to know how we can help your company drive real business progress?

Let’s talk

Stay up to date on our latest thought leadership and learning opportunities