No matter the impression we get from a client’s initial request or brief, let’s always assume, with all due respect and modesty, that our client is no incompetent fool. In all likelihood, they are a capable and successful company that truly knows its stuff, and is professional, prudent, and meticulous. They will have an in-depth business plan and marketing strategy, detailed key performance indicators they can track and measure efficiently, they will have well defined goals and objectives, they will have a clear vision for their projects. The only thing is, they consider everything from their own point of view, from the perspective of their business, which is what they understand. What is lacking is any expert insight from the point of view of interaction design, which is where we shine, and where our future responsibility lies. This is where we usually find the so-called project gap.
We cannot assume (and we cannot ask) the client to understand our online business, the website creation process, internet marketing, the laws of how online presentations and services work. Quite contrary – this is what the client expects from us. But we are still at the very beginning, and everyone’s expectations are very inaccurate – we think we have an idea of some sort about how their ball-bearing business works, the client think they have an idea of some sort about how their future website should work and look. The first step forward is to take note of this and keep it in mind when approaching subsequent negotiations with the client.
Whether our client’s initial inquiry seems to be detailed and sensical, or whether it is obvious at first glance that it is way off, and it transpires that the client has no clue about what they need, we should remain prejudiced against this inquiry regardless, as if it were a flawed and incomplete set of specifications. Whether the aforementioned project gap is obvious in it, or less so, we cannot go wrong if we automatically assume it is present. And believe me, something will always come to light, even if it is a tiny crack.
It is useful to be a priori sceptical of each new set of project specifications, approaching them as flawed and inaccurate, and subject them to strict verification procedures.
For even what appears to be a thorough and detailed brief can hide defects and shortcomings. And some hidden defects can prove to be completely fatal. It quite often turns out that an incorrectly set goal, wrongly ordered priorities, or a tiny flaw in the sequence of steps can lead to a series of carryover errors that pile up into entirely misleading conclusions. And no matter who prepares the original specifications and how well, it is the designer who will be held responsible.
Regardless of what the client’s initial request describes, a good web designer (or, more generally, project designer) must always undergo pretty much the same process of verification and analysis, check the correctness of the specifications, fill in missing details and fix inaccuracies, if not redo the specifications completely. With small jobs and seasoned designers who have been around, just one glance, some quick mental arithmetic, and a few guiding questions will do the trick. But more often, some tools that offer more accuracy and detail will be helpful to the designer:
- a questionnaire
- checklists
- own research
- personal interviews with the client
We will discuss all these tools later, together with specific examples of how such client questionnaires and our own checklists might look.
Note: Exceptionally, the client will insist intransigently on their own detailed specifications-slash-solution, and will refuse to even discuss the matter. In this case, it would be correct to caution them that a substantial portion of the design will be of their own making, and that we, the designer, cannot be held liable. As a last resort, we can refuse a job like that – to add our signature, figuratively speaking, under a very bad proposal that the client has created and insists on will only lead to problems down the line and bad references. My personal experience tells me to run from such a job as fast as I can, and this would be my recommendation to you, too.
Clients who already come with clear specifications and refuse to change them in any way do not need our designer expertise. They are likely looking for a student to do the website coding cheaply. Do not try to stop them, and run away as fast as you can.
With every job, just like any business, we have to analyse potential risks and potential benefits. A client who has a ready and detailed notion of the outcome, who does not let us change practically anything, are not the client for us. The best we can do for him is to call a spade a spade and explain that he does not actually need an expert designer (he likely would not want to pay us as such), only an implementer. If your company has an in-house implementation team, you can close the deal and redirect the job to it: the graphic designers who will make visuals for the already designed website and coders who will transform those into a website, or alternatively refer the client to someone who does pure website implementation.
I have come across a client of this kind I think three times in my career, and with what these experiences taught me, I would with all frankness recommend everyone to send a client like that to any of your competitors. These jobs have always turned out to be extremely risky and highly problematic. These customers felt (misguidedly) to be experts in our discipline, including the coding of pages and programming of scripts and databases, and they even showed a tendency to edit the coders’ HTML and dictate to the programmers which JavaScript libraries to use. Not to mention that, at the end of the day, one of these three clients never even paid for the work.
I do not want to generalise too much and say it will always end up like this, but in my experience the client’s refusal to listen to expertise and insistence on their amateur ready-made solutions is quite a strong indication that I should have nothing whatsoever to do with the job, if at all possible.
