You know the effort it takes to build a website that has great UI/UX, is visually appealing, and has a CMS that is organized for optimal ease of navigation and use. You may even create a training manual, training videos, or conduct in person client training in order to pass the site off to your client seamlessly. A couple of months later, under their management and care, their website is the internet equivalent of Frankenstein. How does this happen? You delivered the project in flawless condition and the training you provided goes into detail about every aspect of the CMS. What's the problem?
The problem is not with your design, development, or your training. The problem lies in the way your client’s work. Just because you gave them in-depth training doesn't mean that they follow it; they might scan the manual, video, or notes a few times, but they all too often set them aside prematurely, thinking they know exactly how the CMS works and how they can use it or make changes to it.
Ok, so maybe this drives you crazy. Maybe you feel like your baby has been taken from you and is being ruined by its undeserving parents. Or maybe you get the added pleasure of being blamed for the mess made by a client that doesn’t take the time to use the site the way you trained them. We get it. But, even though the truth hurts sometimes, we’re here to tell ya’ the truth: it ain’t your baby. So, here’s a little insight into letting go of your need for control.
Once you complete the project, you no longer work with the CMS. This is obvious, yeah? You know this, and your client knows this. Now embrace what it means. The moment your client's internal team takes over the CMS, the way they use it, and the way they make changes to it, is completely out of your control. So, you wrote down details of the content model and a training manual for the CMS and you know that it is very important to be thorough with these. But, your clients either don't know or don’t care (not your fault) and they just skim the documents. Then, they start using it and making changes to it as per their needs. The result: something that is decidedly not pretty and maybe even problematic. The solution: there isn’t one that you want to hear, but we recommend deep breaths, bubble baths, and yoga. Or just really embracing the fact that the website is not yours—its theirs.
Design for your client, not yourself. Your design should handle anything your clients throw at it. The way to do this is by adopting a proper approach to design. Your client's team needs a sit that is easy to modify without turning the website into a monstrosity. Any changes they make to the CMS must fit right in, so your design should enable them to maintain consistency while also providing them a good degree of flexibility. How do you do this?
Design modules, styles, and page types. One approach is that instead of designing every page, you can design a set of “building blocks”. Your client's team can then use them like LEGO bricks. They should then be able to use these parts to reach a desired finished product, add to it to easily, and remove from it easily without screwing up the rest of the system. Every building block of your design should be reusable and self-contained. Remember that your client's business needs will change through time. This will also require them to use their website in different ways, to include more or to remove certain aspects. Your design should enable them to do this.
The CMS you design must teach your clients to use it. Since your clients would probably prefer to manage their own content, they should find it easy to do so, even without the training manual.
Educate your client's team. Even if you do all of the above, unless your client's team knows the hows and whats, they may still make a blunder. So, let them know. Sit with them and take them through all the aspects of the design. Show them that there are guidelines. Show them how to take things apart and put them back. Show them how to remove features and add new ones. Show them how the modules work with one another. Teach them everything. You must take the initiative to do so even if your client doesn't ask for it. We’re big advocates of in-person training over manuals. Best-case scenario? Have both.
Just because you had a face-to-face session, you should not neglect proper documentation. Go into as much detail as possible while creating help documents. Also, if possible, develop an easy-to-follow set of guidelines that will help your client's team to make changes without having to go through the exhaustive documentation.
Involve your client early on. It is not just enough to teach your client. You have to make sure that they have understood the process of using and modifying the system. How do you do this? You reverse roles, preferably towards the end of the project. Instead of being the designer, you give that role to your client's team. Let them participate in populating content/creating new entries, etc. so they can have early interventions when they hit obstacles or challenges.
This will help your client's team to work on the system under your supervision and you can ensure that the team knows what it is doing – that they are implementing changes the way they are supposed to. Of course, there is only so much of this you can do and it is definitely not possible to address every possible situation, but even a little bit of help at a time when you are still available to help can go a long way.
When you take on a project, your goal must not just be to deliver the final system to your client's specifications. Your goal must also be to enable your client's team to work on the system without you having to hold their hands by the time you complete your project, even if your client doesn't ask for it. Once you do that, you have to just… Let if Go, Let IT GO.
Besides, you know you can fix anything the client breaks anyway, right?
Did you know that the average visitor to your website spends about 70% of their time looking at the left half of their screen? Users are increasingly ignoring things in the right hand column of a page layout, which has many implications for how we design and build sites.