Change Is The Only Constant

This is true of most things in life, but even more so for website design. Most requests for changes come after the site has launched and all the stakeholders have had a chance to look the site over.

One simple way to avoid this headache is to set up a development site for your client to review during your final stages of quality assurance.  This way, changes can be requested and made within the project timeline.  This will make the client more comfortable knowing they can see what the final product will be, and it saves your design team the hassle of having to revise their work after the project launch.

While this solution works most of the time, there is always a chance that not all the stakeholders are able to review the site, or someone new comes on board late in the project and hasn’t had any input on the site’s design and/or functionality. In these two cases, post-launch changes are almost inevitable.  Thankfully, there are a few ways to educate your clients and make the process a little easier:

• Create a second “phase” to the project, with a quote and timeline that notes any necessary content due from the client.
• Inform the client that the changes will take time.  This is especially important if you have other projects queued to start immediately after their site launches.
• Explain the costs associated with changes that require additional development and/or design time.
• Make clear the difference between design changes and simple content changes, and the time and costs associated with each.
• Review the approved information architecture and wireframes that the client signed off on.  Note how the changes deviate from one or both, and discuss whether the change is actually necessary.

DIY

Many times the changes aren’t complicated enough that your team has to make them. Ask the client if they are comfortable making the content changes themselves via the CMS (after training, of course) or if they have someone (i.e. a graphic designer or webmaster) who is comfortable making design changes in-house. This solution is usually less costly and time-consuming for both your team and the client.

Don’t say “no.”

If the changes the client is requesting aren’t doable, give them an alternative. If the change is something that the design lead or developer doesn’t agree with, have them explain why the change is undesirable and have the head of your team explain the reasoning to the client.

Feel free to offer insight on dealing with client change requests that happen when it’s all been said and done.

FIU Web Communications is a full service web team that provides support and consulting for departments at FIU. If you need help in implementing any of your web needs, please contact us.

If you enjoyed this post, please consider leaving a comment or subscribing via rss feed or email to have future articles delivered to you.