Solving Communications Issues Between Developer and Client

Web site development can become a standoff between developer and client without a predefined agreement. Web developers have the expertise, but the client knows what he wants – or at least what the thinks he wants. Open the lines of communication before the project grinds to a halt.

slide 1 of 2

The dilemma

Web developers do not want to compromise their standards, even on a small budget. The answer to small budget woes is appealing visual design. Even if the website doesn't have much interactivity, it can still look pretty and have simple navigation. But for an extensive site loaded with features, the problem can become even more pronounced. The two biggest obstacles a web developer will need to overcome are the client's unreasonable expectations and impractical design ideas, and programmer ego.

Each person in this confrontation brings something different to the table, and all are at odds. The programmer has a certain structure he adheres to. Designs will vary, but based on his experience he knows what the website really needs to be search engine friendly and easy to navigate. He also knows that potential clients will leave any site they can't find their way around and not come back.

The client, on the other hand, wants the website he's sinking his money in to look cool and do cool things. He's been to high tech websites and has no unit of measure to determine whether the features he's seen will fit his budget, or even whether he really needs them. Maybe he thinks that if it has already been done, it should be no problem to plug that code right into his site. That house color visualizer at the Sherwin-Williams.com, for example. Can he have that? To make matters worse, he has bad instincts. He wants giant text in different colors. He wants colored backgrounds. He wants to use multiple fonts. Maybe he doesn't have a logo, but that's part of website design…right?

slide 2 of 2

The solution: communication

The result of an uncommunicative developer paired with an enthusiastic client can be disastrous unless you follow a development methodology that includes listening to the client and allowing him to be a part of the design process. The Service Level Agreement (SLA) should define the parameters of project scope and should be well understood by the client, so when he tries to sneak in extra features or logo design, you can remind him that it's not part of the agreed-upon work. Or you can simply answer "yes, you can have that hugely complicated flash item. I estimate that it will take [x time] to build in addition to the current time frame and will cost [some large amount of money]. Would you like to write that up and put a deposit down today?"

Part of the web developer's job is to educate. By sharing your ideas and telling the customer why he wants clear navigation instead of a big white splash page you have to roll around randomly trying to find links, or mystery picture links with no explanation about where they might go, you build trust. Communication makes the project less likely to wind up producing a design that leaves him dissatisfied and unhappy.

It's not always the customer, either. Some developers really don't listen. They consider themselves experts who know what's best for the customer and don't accept compromise. This developer won't even show the client their work in progress until it's too late. This is another situation that can be remedied by communication, and perhaps a little humility. The customer might not be an expert, but if the programmer simply won't listen, he won't be in business for long.

When the client is included in the web development process, educated and informed all along the way, and feels like part of the team, he can be proud of the final product. The web developer can often help the client pinpoint goals by asking for examples of websites the client likes, and why he likes them. It may be a feature, the colors, the curves, the navigation…whatever appeals to the client should be considered and discussed, either to be incorporated or explained as impractical. In terms of communication, documentation is often the key to a result everyone can be happy with.