Early in my web career, long before I started at Chromatic and when the word "webmaster" was still in use, I worked on the client side of a web project. As clients, we would send our content to the developers and we were always miffed that they entered it without correcting our spelling mistakes! On the other side of the ledger, I have seen a developer ask a marketing client, "Do you know which column in the database table has that data?" I've even had a web manager [Not at Chromatic!] with several years experience ask me if our website uses HTML!
I'm not revealing these things to embarrass anyone (myself included), I'm just emphasizing the fact that there can be a gap in understanding as wide as the Grand Canyon between clients and developers.
So How Do We Narrow That Gap?
Educate the client, of course! Teach them the difference between front end and back end; teach them that some data is stored in the database while other stuff is in code. Dizzy them with jargon until their heads spin. But, wait...should the client really have to learn all this stuff? Isn't expecting them to do so, a tad arrogant? Haughty arrogance isn't what development teams should be known and loved for.
What about us? If educating the client is important, then surely we narrow the gap by educating ourselves too. How do we do that? What can I learn about my client that will make me a better developer?
Put Ourselves In Their Shoes
It seems obvious, but what if we look at the project from the client's perspective? As developers, it is easy to talk of building semantic, performant, accessible, beautiful websites, but that clashes with the reality of banner ads, content that is copy/pasted from MS Word, pop-ups and limited budgets. It costs real money to build these virtual web properties and ROI is where the rubber meets the road.
With limited time and budget, trade-offs need to be made and it is our job to explain these trade-offs to the client. For instance, security professionals are loathe to allow 3rd party scripts, but how can you block those scripts if your client depends on advertising to produce revenue? Or imagine telling your client that committing to a strict security policy means they can't have Google Analytics!
So in my experience, one thing I keep coming back to is the importance of communication. I personally prefer to know the "why" behind what the client wants us to do. "Why don't you want to enforce strong passwords?" or "Why do you want 3 separate sliders on the home page?" At first blush these might sound like bad ideas, but maybe the client's reasoning will sway me. And maybe having to explain it themselves will make them question their premises. Speaking of questions, one question that cannot be asked enough of the client is, “What problem are you trying to solve?” Hearing the answer gives me context and I find it gets me on board with what the client is trying to achieve. If I'm in tune with what the client's really trying to achieve, then maybe I see the issue from a different, broader perspective and I can better come up with a fresh solution that solves a universal problem.
I love this quote from Theodore Levitt: “People don’t want to buy a quarter-inch drill. They want to buy a quarter-inch hole!” 1 But many think that that doesn't go far enough - maybe what they really want is to hang some pictures. You don't necessarily need a hole in the wall to do that. If we ask and listen and understand our clients' motivations, then we can come up with solutions that might even surprise ourselves.
