A few weeks ago I wrote a post about how important it is for project and account managers at web development firms to have empathy. If you are able to see the world as your client does, chances are you are going to do a great job for them. You will be able to anticipate problems before they happen.
As a follow up, I wanted to share some real-world examples of client communication problems we’ve run into at the Brick Factory and explain how they could have been prevented. The underlying theme is that most issues can be prevented with good communication that comes from understanding.
Project management problem
You have been working on a site redesign project for three months and are a week from launch. While reviewing the beta version of the site, the client points out that a members-only section that was present on their old site is missing and must be built prior to launch. This is the first you have heard of this feature. Your launch date is now in peril and you have to have a difficult conversation with the client since the work isn’t in your original Scope of Work.
How it could have been prevented
No matter what project management methodology you use (Agile, Waterfall, etc.) or how small a project is, every engagement should begin with a discovery phase aimed at surfacing requirements. Write out the features and functionality of the site/feature you are building and get the client to review and approve to make sure nothing is missing.
Skipping the discovery phase is sort of like heading out on a cross country, family road trip without a map or GPS. You will probably get there eventually, but it is going to take a long time and there will probably be tears.
Project management problem
Your team has produced a series of design comps for a new site that you are ready to show the client for the first time. Language and photography are still being finalized, so you use placeholders in the initial comp. You send the client the designs via email and don’t hear back for a week. When they finally do get back to you most of the feedback is on the placeholder images and text, and it becomes clear that the client is confused by parts of the interface. You are able to clear up the confusion with a phone call, but you have wasted a week.
How it could have been prevented
This one is pretty simple: you should always present your first big design deliverable either in person or via a screen sharing service where you can control the experience. You should only send a link to the design after you have presented the work first.
By presenting the work you are able to explain the decisions you made, fully demo how the interface works and clearly define what kind of feedback you are looking for. It gives you the opportunity to make sure your work is properly understood. No matter how thorough or well written an explanatory email, it can’t take the place of a conversation.
Project management problem
You create a series of wireframes for a new website you are building. The wireframes are in black and white, and intended to demonstrate overall page structure and content priorities. After sending the wires to the client, you get a short response asking why the new site design is completely black and white.
Later on in the project, you send the client a complete, full color design comp that is in PSD format and optimized for widescreen desktop computers. The comp is posted in Invision so that the client can see what it will look like in a browser and provide feedback before you build it out in HTML/CSS/JS. The client calls you five minutes after receiving the comp in a panic, asking why the new site draft doesn’t work on mobile phones.
How it could have been prevented
In both of these scenarios the client misunderstood the deliverable you sent. In the first scenario they thought the wireframe was a full site design and in the second scenario they thought the design comp was a full working site draft.
If you are like us, your clients are smart people who are true experts at their jobs. But for a lot of them web development isn’t their primary job. They count on us to walk them through the process of building a site. It is a mistake for us to assume that all of our clients know what things like wireframes, design comps, mood boards, prototypes, etc. are.
One of the first things a project manager should do when onboarding a new client is explain the process that will be used to build the new site or feature. Walk them through each of the deliverables you are going to produce in detail, explaining what they are for, what their limitations are and what type of feedback you are looking for. I know this sounds obvious, but I personally have skipped this step and ended up confusing the client more times than I care to admit.
Sign up today to have our latest posts delivered straight to your inbox.
