(Why the customer isn’t always right)
Firstly, this article isn’t intended to be a rebuttal of Rob Swan’s excellent article on A List Apart (In Defense of Difficult Clients). It’s a really good piece and makes important points regarding the developer/customer relationship.
My intention with this post is to raise the, somewhat thorny, issue of what to do when a client wants something that’s against your techie morals. Consequently, I hope this posting is of interest to both developers and customers.
Problems within the developer/client relationship
There are two big problems faced by Web developers when managing a relationship with a client and the expectations of that client:
- A customer may feel that, by spending most of their working day surfing and gleaning information from the Web, they are ideally positioned to describe how their corporate site should be put together in the most minute detail. Uncharitably this could be described as the “I want a widget that does this, get it on the site asap and don’t bore me with the details!” approach. There’s nothing wrong with clients requesting new features but some features may have a detrimental effect on their Web presence and it’s a developer’s responsibility to highlight that.
- The other problem is that everyone, and I mean everyone, knows someone who can create Web pages. This puts competent developers in a very difficult position. There are instances when a client may request something that will reduce the effectiveness of their Web presence. In these situations it’s hard to say no and offer a well-argued alternative when the client can respond with “My mate Dave does Web sites and he says it’s easy, why can’t you do it?”.
I’m not saying that customers don’t have the right to ask for new features on their Web site or question the advice given to them by developers. However, customers are basically paying developers to know more about the Web than they do. So, whilst it might be difficult to accept, the customer isn’t always right. There, I’ve said it!
From the client perspective…
If a customer is frequently requesting new features and are being told by the developer that it’s not a good idea for this reason or that, they may be forgiven for feeling that a developer is just being difficult. It’s therefore easy to appreciate how tension might build up between customer and developer.
A further issue is that many clients don’t appreciate that the processes associated with developing Web sites are different to those associated with other media.
For example, a common question posed by client’s is “Why is it harder to work with Web developers and designers than Print designers?”. I’m afraid the answer is simple, the Web is not Print. The issues associated with each medium are different and require different working practices.
An example of one of these differences is the issue of screen resolution. A Web site will need to be usable on a range of different screen resolutions from the most advanced workstation monitor to a tiny screen on a mobile phone or a PDA and you don’t know what device will be used. In comparison, once a leaflet is printed, the format is set. The leaflet doesn’t change from A5 to A4 or even A0 depending on who views it.
This isn’t to say Print design is easy, the point I’m making is that the media are different and direct comparisons of the working practices aren’t applicable.
Working practices associated with the Web are specific to the Web. There are important considerations to be investigated when implementing any new feature. For example:
- Will this exclude some user groups?
- Will this contravene privacy laws?
- Will this reduce the ease with which search engines catalogue my content and affect the position of my site in the search rankings?
In many cases customers can’t answer these questions and you wouldn’t always expect them to. It’s a developers job to know this information.
From the developer’s perspective…
A good developer will always have their client’s interests at heart. For example, if a client wants an entirely Flash-based site then it’s the developer’s role to explain why this isn’t a good idea and usually this needs to be from a business perspective (see The Web Standards stick). Continuing this example, a developer may then explain that, Google cannot catalogue content from within Flash files, so an all Flash site will not appear highly within search results (in comparison to HTML sites on the same subject).
At this point one of two things can happen:
- The client appreciates the potential implications for their business and works with the developer to come up with a more appropriate alternative.
- The client discounts the developer’s argument and insists that the work is done, they are the customer after all.
This second situation is the hardest to manage. Does a developer accept the client’s decision and do the work even if the result is damaging to the client’s business or would cause them to fall foul of disability discrimination laws (for example). Alternatively, does the developer go back to the client and try to argue their point again at the risk of appearing even more ‘difficult’?
I’m sure most of us hope that our developer/client relationship is sufficiently good to be able to cope with some to-ing and fro-ing but the client might be adamant.
The Web standards stick
I’ve previously admitted to being a standards evangelist and think that adherence to standards is of real importance. However, is the knowledge of Web standards and guidelines of importance to anyone other than developers, designers and people developing authoring tools and browsers?
The benefits resulting from sticking to standards are of importance to clients but do they need to know the reasons behind why we use the strong tag rather than the bold tag, for example?
Similarly, when discussing a feature request with a client I don’t think it’s helpful to say “You can’t do that because of the standards” – this perpetuates the myth that the standards are restrictive.
There are good, commonsense, business reasons behind a lot of the standards and guidelines (especially the Web Content Accessibility Guidelines) and it’s sensible to draw on these for explanations rather than the wording of the documents themselves.
Can this situation ever be fully resolved?
Fortunately, I’ve never been in a situation where I’ve been forced to do some work that goes against my techie morals. If this was to happen I’d like to think that we’d refuse the work as I don’t think we’d want to work with that “type” of client… but it’s a tough one to call especially if they’re an existing client.
Ultimately, if a client wants something that goes against your techie morals, you’re almost damned if you do and damned if you don’t.
If you air your concerns but are forced to do the work, and the site plummets from the Google rankings or the client receives a lot of negative feedback on the new feature, then they’ll probably blame you for “Not doing it properly”.
If you refuse to do the work, the client may get some third-party (who don’t ask ‘difficult’ questions) to do it and the client will then ask you to add it on their existing site anyway. Alternatively, it could just be the end of your current working relationship/contract.
At the end of the day, what’s needed is for developers to appreciate that clients will always want new features added to their site but to appreciate that clients probably don’t always understand the complexities. In explaining these complexities you need to focus on the business perspective and not the technical one. It’s a developer’s job to make sure a client understands the issues, how they may affect their business and offer suitable alternatives.
The client should also appreciate that a good techie will not be deliberately difficult but may argue strongly against what the client wants if the idea is likely to cause problems. The client should also realise that, for some techies, just getting the work done and not worrying about the consequences is against their morals and, if truth be known, it’s not good for the client either.