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”#section2
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#section3
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#section4
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.
Great way of thinking, I love to combine the design and development processes. This gives an interesting twist in the whole process as you can test your designs immediately. I think it is a good way to have developers give advices during the design phase.
Good read Laura and fine points to make. I would also say that design process expectations change with region and tech-savvy. Building a website for a small mom and pop business in the sticks where they’re still running windows XP on a machine they bought in 2003 is a much different design presentation process than building one for a large company in the city where every employee is attached to a smart phone. It is GOOD to guide the client toward YOUR process in design and development but I would never be afraid to tailor that experience just a bit to better fit the client’s capacity to understand it. If you hit a the mom and pop client with the same fervor and pitch as the big city client, that is also a recipe for disaster. The methods you use to get to the design can be similar but just remember who you’re talking to when presenting it.
Yes, It’s about educating the client. The best motivator I’ve found for breaking clients of predetermined expectations is money. If you explain why they don’t need X, Y, and Z and it would save them money by not implementing it. The clients are usually open to the idea.
I understand the need for flexibility but I’m curious – if you aren’t outlining your process or deliverables as part of your estimate and proposal, what exactly are you proposing to the client? How do you estimate and schedule work when you don’t know what tasks you might perform?
Terrific article. Clients hire us for our expertise — because we have a skill they need but do not have internally. So basing everything off what the ‘client expects’ is putting our job on their shoulders.
Assuming that: a) we know what we’re doing and b) the client needs to be helped through the process (i.e. we take the lead) has always led to better, less stressful projects in my experience.
You can still respect the client without expecting them to know best.
Hi Jessie. I would definitely outline my process, and through that I tend to explain that there are these different types of documents that I’ll use to communicate my ideas, and that I’ll try to use them when I think is most appropriate.
Here I also try to emphasise to the client that if they feel uncomfortable with the fidelity of a document, or that it needs more work for them to understand where I’m coming from, then I’ll be happy to find a more effective way to communicate with them.
I made a set of worksheets that goes over possible deliverables, activities, and risks for each stage of a UI Design project. Sometimes I’ll go through them with a client to work out their project’s specific needs, and that’s also a good time to nudge them towards or away from deliverables for their own sake. It also includes the idea of formality – a set of requirements can be a bullet list in an email if that hit’s the right level of communication. A wireframe can be delivered as a hand-drawn sketch if the designer and developer really are on the same page (so to speak).