Designers gather input from various sources that affect the direction of a project: There’s bespoke research around the problem space, relevant case studies, regulators (both external and internal), subject matter experts, validation sessions with end users, etc. But there’s one entity that tends to have more influence on the direction of the project than others: the client.

By “client” I mean the entity that has commissioned the design project — i.e., the person or team who is paying the designer to focus his or her attention on the problem at hand. The client has money and reputation at stake; the designer has a contractual obligation to deliver results. The client is tasked with changing the state of whatever is being designed. “We are at point A, and need to get to point Z by X date.” The designer is there to shepherd that transformation through designerly means; that is, by manifesting key decisions in ways that reflect intended changes so they can be tested against reality.

The designer has an important responsibility in creating these feedback loops, but the client ultimately owns the results. This is obvious when the designer is engaged as a consultant – i.e., not an employee of the client’s organization — but is no less true when the designer is an “innie.” Many internal design teams don’t “own” the things they’re designing; they work with counterparts in other parts of the organization who have bottom-line responsibility for the thing being designed.

Charles Eames's sketch of the design process. Image: Eames Office. http://www.eamesoffice.com/the-work/charles-eames-design-process-diagram/

Charles Eames’s sketch of the design process. Image: Eames Office.

The client-designer relationship is central to the design process. Understanding the dynamic of this relationship, and knowing what each party is expected to bring to the process, is key to success. That said, it is up to the designer to ensure that directions are clear. In architectural projects, these directions are often manifest in the form of a brief, or architectural program: a document that lays out the requirements for the project.

The content for this brief must ultimately come from the client, but is formulated in close collaboration with — and often led by — the architect. Architects shepherd what is an initially vague set of requirements towards something more specific and actionable, much like they shepherd design artifacts. The brief is a sort of meta-design artifact that is also designed. Given its importance to the project, the designer and the client must develop it together.

Successful design projects call for relationship-building among all parties involved. Few relationships are as important to the success of the project as that between the client and the designer. At best, these relationships are true partnerships, with both parties having a healthy respect for what the other brings to the project. That said, both parties can’t be expected to have the same degree of understanding of this fact. While this may be the one time in his or her career that the client will be working with a designer, the designer will work with many clients over time. Because of this, it behooves designers to understand the client-designer dynamic and create the conditions necessary for these relationships to be fruitful.