Web inSite Journal
AddThis Feed Button Bookmark and Share



Web inSite Journal Index


Right Point Web Index




How to Keep Your Clients Happy — Documentation and Sign-off
by William Szczepanek

Article 12: April 28, 2008

The customer is always right. Right?  In the end, yes — at the beginning and during the process, not necessarily.  We need to protect clients from themselves. More than in most other kinds of business a Web designer/developer needs to be very much a people person.  Determining the best solutions for your clients depends on your ability to communicate effectively, both with your clients and for your clients.  The first step is to listen intently to your clients needs, while asking probing questions and then confirming the answers in your proposal and documentation.

The science of Web design presents many pitfalls for the designer/developer who ventures forth to meet with clients, determine their needs, and fulfill those needs in a way that prevents all involved from killing each other.  If you find yourself dominating the conversation rather than listening to your client, then you are not likely to find out what the requirements really are.  People don’t learn well while they are talking and the initial conversation with your client should definitely be a learning experience for the designer.

Often, when asking a client that has no previous experience in working with designers what they would like the site to look like, they will often answer with something like, “I like green.”  Designing anything for someone else is a difficult endeavor, particularly when strong opinions exist on all sides.  Will providing what the client wants make them happy?  It may until they realize that the end product isn’t what they really wanted and you didn’t tell them that they didn’t want it.  So, how can we prevent these occurrences from happening again… and again… and again?

The answer is documentation and sign-off.  But, you say that documentation takes time and time is money and you couldn’t make any money at this business if you had to document everything.  As it is, many people believe that if they had the time they could do just as good a job as the designer and that it really shouldn’t cost much.  Just put out some color and photos, generate some text, make sure the links work and voilà! It’s done.  I can say that the same is true for most magazines that are sitting on the rack in the grocery store.  If that’s the case why is the average price about $6.99 for a magazine that’s about 80% advertising?  It takes a lot of work to format all of that advertising in a pleasing way.

Before a client will follow your suggestions you need to build rapport; you need to get to know your client’s personality and adjust to it; you need to identify and show that you understand their problems; you need to define the objectives and the deliverables and decide who will be responsible for which parts; you need to write a project schedule, and you then decide if you really want to do this job. The final step can be the most difficult to determine.

Now that you’ve listened to the client and gotten them to listen to you, how do you convince a client to read the documentation?  By telling them it’s their website and that by participating in the documentation process it will take less time and money.

What needs to be documented initially?  What needs to be documented first are the answers to the questions necessary to start other documentation.  These can be included in a document called the Planning Meeting Checklist.

Planning Meeting Checklist

Initial interview questions

People

Tasks

Design

Content

Competitive analysis

Project Description

List of Tasks

Comprehensive List of Features

Overall Design Goal

Metrics

Answers to these questions will drive the overall design and begin to define things like the number pages and the link names.

These questions either generate answers or no answers.  To the extent that there is no answer, the question causes an increase in cost to generate an answer.  For instance, if the client does not want to write the content then, it will cost extra for the designer to write the content.  But, ultimately the client will have to sign-off on the text no matter who writes it.

The process of asking these questions and documenting the answers will show the client that their site is important to you and that you care about its content.  At some point the written documentation can be replaced with prototyped web pages and verification can occur through the development server.  Wireframes, flowcharts and diagrams ultimately fall short as the site becomes more complex and the work involved makes documentation an afterthought. Good prototyping can save a lot of work and keep the project moving.  The point at which the method of documentation becomes too much work must be viewed in relation to the importance of the documentation to the project and the team.   The design, prototype and evaluate cycle with written evaluations and next steps can go a long way toward keeping a project on course. A really good system will be able to have the electronic documentation drive the website content and look.  That scenario is rare and is usually confined to specific Web application types.

The higher the level of complexity of the site, the more good documentation is needed and the harder it is to maintain the documentation. Defining what kind of documentation techniques will be required should be part of the early documentation. Documentation is the first step in the definition process.  The next step is the Project Schedule, which we will investigate in another journal article.