How to manage a client's expectations

Question

So I am running in to a bit of an issue, and although there are similar questions on FL nothing this specific:

How do I manage a client's expectations for a new website?

The issue arises when they first see it go from mock up to actual working website. I'll give you the two approaches I have taken

Show them the end product only Once I am happy with the site I will show this to them, but only once I am happy. This often results in phone calls of "what is happening" and "where is the site can I see it now"? I do keep them in the loop with multiple emails per week so it doesn't look like I have run off - but clients seam to want to get their hands on it before they should. Note: all time-scales, with contingency, are laid out before hand.

Involve them in ever step On the other hand I can show them the site every step of the way. However I have found when I do this they seam to like to request odd changes and get a bit confused with it all (understandable). The main issue is, it seams to encourage them to request more and more, and increasingly not-the-right-thing changes; though they do not take kindly when I say "this is the way to do it". It just seams as I say that this encourages more changes, though the benefit is if there is anything they really do not like we catch it early on.

So my question is really: Are there any approaches I have missed or is this just as hazard of the job and I should accept the lesser of two evils (the first I am currently thinking!)

Answer 1

In my experience, it depends on the client.

Some clients like to micro manage and in this case it is probably better to wait until the website is nearing completion before showing them.

Other clients may have some useful input along the way and can be helpful.

The problem with a new client is that you may not be able to tell which type of client you have.

There might also be a third option where you can occasionally email a screen capture or similar to show clients the current status and and ask for specific feedback if needed.

I lost one client because I involved them along the way in the development of their website. I was focusing on the most challenging part of the job which was developing multi page forms and PDF reports and planned to make it all look pretty at the end. Unfortunately, the client lost confidence because of the way the website looked even though most of the difficult part of the job was done.

The lesson I learned was to progress the aesthetics and back-end development in parallel when clients are involved along the way.

Answer 2

One thing I've learned to really appreciate is the power of agile development. Too often did I spend too much time second guessing the requester, creating something I was sure would be appreciated just to find out that they didn't like a button where it was or that they wanted changes which were very difficult to implement at that point.

The problem is often that eventual product owners can't properly envisage a final solution. Once they see results they realise that they need more complex or additional features.

In my experience it is best to start with user interface designs. Understand the problem that needs resolving, then design what the user will see, what they will interact with - don't worry too much about the actual functionality at that point. Involve the user, almost let them 'design' their solution. agree what's most important and develop that first. Demonstrate what you've done, then agree the next bit.

That approach makes it often a little difficult to agree time scales, but with experience it becomes easier.

For me this approach resulted in happier end users and solutions being used for years.