A colleague recently asked us to look at a design audit he delivered for a web-based service. He knows his stuff and it’s super-thorough. The client hired him because they know they have problems. They should be all over it. But now he can’t even get them to read the report, much less respond to or act on it.
The report has a lot of information. I mean a lot, and it happened to be delivered as a single, long document, meaning it’ll require a huge effort (from an already busy client) to internalize its findings and put into practice its recommendations. We ended up suggesting the Big Report format as the crux of the problem, and that he could get traction by breaking it into a series of smaller reviews the client could digest a piece at a time.
That got us got us thinking about how we changed our way of looking at presenting information to clients over time, and the realization we made along the way.
Every project has, at its core, two problems: the one we’re hired to solve, and finding the right way to bring the client into that process.
Rather than assume a shared context where clients want to, and can, consume and understand the things we produce as we make stuff, we take time to understand their way of working, then present our work so they understand what’s happening, why, and what their options and obligations are.
Some clients see sketches and wireframes, some see prototypes at different stages; some see five font choices and three colour palettes while some see two. Some clients see code and hear about server needs, other clients get a cloud-hosted account set up for them and a monthly bill from it; some clients get presentations every so often and others spend time with us in group chats every day passing small files back and forth.
If you don’t solve both problems, your client doesn’t get the full value of what you do. What you make might work fine, but they won’t understand and will lack the buy-in that makes your work a complete solution.