Pitfalls in Communication with Developers

(The following is based on actual events)

You have a fairly good idea of how you want your new website to look. You spend some time searching around for a developer, get some feedback and advise here and there, and are ready to proceed. You have someone plan your site, maybe add a few wireframes, a designer designs something that looks great on paper and the developers start working.

Your first surprise comes when they show you the first stage after uploading the site to a development server. “What’s that?” you ask, looking at the frame that has very little of what you had asked for. “Well that’s your site,” they say. “It’s coming along really well,” pausing for praise from you. “But there’s nothing here that I asked for.” You scratch your head. “It’s a work in progress — let’s get the design up and you’ll see what we mean.”

This is the start of a process that often frustrates both sides for the long weeks it takes to develop a new website. The next road block will come when you ask them to change something that really doesn’t look so good now that it’s functioning. “That wasn’t part of the design program,” they say, which is a synonym for “It will cost you extra.” After that you encounter the reality where some things don’t look quite like they did in the design and the developers will usually have a good reason for the difference, but one that you won’t really understand. It will have something to do with three-letter codes (asp, php, css) that you think they are making up.

There are many, many pitfalls to working with developers. Most have to do with expectations and communication.

What most people don’t understand is that developers work via a plan. The written website program (a site characterization) is a blueprint for the website. It includes a verbal description, the wireframes and then the design. Just as changing a blueprint of a house in mid-stride can cause problems and extra costs, so can changing a site plan of action. The site’s verbal description, if written well, will tell developers not only what needs to be done, but most importantly, why (See The Most Important Question When Creating Your Website ). Some changes are no big deal (like changing the color of a wall in your new house), but others are like moving walls after they’ve been built — not impossible, but what a pain in the ass. It’s important to understand the site plan documentation, make sure that it is clear to both you and the developer, and that you didn’t leave anything important out.

The design that developers received from the designer — the colorful one with pictures — you understand. It’s graphic. It’s worth a 1000 words. But that’s just part of the program, and often there are discrepancies between the design and the written characterization. Just a quick example: one site we worked on had a clear description of an upper menu with nine well described items that were critical for the site’s functionality and user interface. When we received the design sketch, there was only room for five items. Which do we remove? Do we change the design? Another site had lists on the left hand site of page titles. The site was in five languages. The design was only showing the English version. The German titles didn’t fit in the side bar (single words didn’t fit!).

Designs and plan documentation need to be flexible, but they are still the blueprints by which the site will be built. There are often items that look good on paper, but don’t quite work out in virtual reality. When you request changes understand that when you say, “it’s just a small change” there may be some major programming behind the scenes.

So let me give some clear tips:
1) Have a well written, detailed, clear and concise (more is not better) site description.
2) Go over the document with the developer and make sure she understands it.
3) Compare the design with the document and work out discrepancies before development starts.
4) Be flexible without compromising critical parts of your plan.
5) Understand that changes and additions mean more time and often more money.

Developers can’t always see what you’re thinking, so make sure the documents hold up.