If there’s one phrase in client services that irritates me, it’s “what the client expects.” Clients come in a variety of shapes, sizes, and types of experience. If a client has previously worked with a designer, then they’ll likely base their expectations on that process. If a client hasn’t worked with a designer, they may base their expectations on the second-hand experiences of friends and colleagues. In both cases, the process may not be the same this time around.
During a project, we build relationships with our clients while we learn how best to work together. Through talking to them, we establish what might be the best deliverables to help them understand our mutual goals in the design process.
It’s difficult to decide upon the most appropriate deliverables before the process begins. The concepts may become easier to describe in different ways at different times. You may want to create a document in lower fidelity when sharing rough ideas with a client. Or you might want to show design work in higher fidelity to help a client visualize exactly what you intend. They’re working documents, part of a working process.
“The client expects PSDs/wireframes/templates”
It’s part of our job to decide the most appropriate way to share our work with a client. If the client has already established what they believe to be the “right deliverables” based on their work with a previous designer, it’s our job to respectfully nudge them in the right direction, while explaining our reasons behind those decisions.
We can’t sit still and wait for clients to dictate the best process to us. The web is not a constant, and the solutions we offer are continually evolving. Some projects might require a working prototype so we can show a client exactly what we mean. Some areas of a project might just need a quick sketch to convey the basic idea to the client. We can’t expect to keep up with changing technology if we’re keeping our processes, and the work we create, exactly as we and others have done before.
Setting out specific deliverables in estimates and proposals
Detailing “I will deliver 1x Photoshop file as a final design” in your estimate or proposal is setting yourself up for failure. We can’t ever know how many deliverables we’ll need to convey our ideas effectively, or what fidelity will work best at each step of the design process. We need the flexibility to create the deliverables that best convey our ideas whenever we need them. Without creating deliverables as needed, and sticking to a pre-defined schedule and structure, we run the risk of wasting our time and the client’s budget by creating deliverables just for the purpose of fulfilling the proposal, and without any real meaning or value.
Design is the journey
In web design, the deliverables we create are rarely the final product; they’re rarely the thing we’re going to “put live” to any users. They’re throwaway documents, a history of the design work that evolved into that final product.
Often designers speak about their Photoshop documents, wireframes, or prototypes as if they are the “designs”—but they’re not. They’re a form of communication between us and the client. The act of creating these deliverables is the design. The decisions we’re making, the solutions we’re lining up and checking off, selecting and rejecting: this journey is the design. The deliverable is just a vehicle.
We need to stop acting as though deliverables are the be-all and end-all of web design, and treat them as the communication tool that they are. If designers are seen to be just the producers of design artifacts, we’ll be treated as technicians, not as the professionals that we are.
