When I started building WordPress sites I actually thought my job was done once I handed off the site to the client; the code is written, it is theirs now. I suppose that worked: I was able to pay my bills, but didn’t see many of those clients again.
Then I started providing some documentation and training for clients. Yes, it was a bit of a pain, but curiously enough they kept coming back for more work, and not just more training work, also development work.
I firmly believe that upping my game by providing training and documentation is the reason clients started coming back. Expanding my level of service created a great way for me to earn more, both with my hourly rate and also by having more items to charge for.
How to Document
The backbone of any solid documentation, for me, is to have it appear where the client can easily find it. I always use WP Help by Mark Jaquith to add documentation to client sites.
Once the client can find it, we need to remember a few other things:
First, our clients aren’t developers, there are many items that we take for granted which they simply don’t know. Take shortcode parameters, for instance; they may seem easy to us, but to the vast majority of clients shortcodes are simply code and look odd.
Secondly, many of your clients may not have any idea of what WordPress is. Telling them that they can change the menus doesn’t tell them that the menus are located under the Appearance menu in the WordPress admin. They may never find it, or just spend a bunch of time and be frustrated with how ‘bad’ WordPress is, even if they do find it.
When writing documentation for users, you need to assume that they have no idea where anything is. Provide twice as many screenshots as you think you need, and twice as many explanation steps. Don’t assume anything.
The ‘over documentation’ point was brought home to me with a recent client, whom I had provided with a site built on WordPress and WooCommerce. All of the staff adding content to the site had used WordPress before. We had been running a local kayaking blog together for years, but when it came to the higher level admin stuff, like changing menus, they had absolutely no clue. I started with less steps which resulted in getting calls to clarify. As soon I doubled the steps and screenshots, I got emails about how awesome the documentation was.
What to Document
Should you provide documentation for all of WordPress, or just for the items that are custom to your client’s site? By default, I write documentation for any of the custom stuff and not for all of WordPress. That premium service is what allows a premium price.
But what if your client is 100% new to WordPress? What if they do need total WordPress documentation? Should you write it all yourself, or find it somewhere else?
A great place to point your client is the Working with WordPress section on the Codex. There you can find lots of information on how to use WordPress. Another great thing about the Codex is that the documentation is kept up to date by the community. You don’t have to check back in on client projects to make sure their documentation is up to date with the current changes in WordPress.
Once you have a great series of basic WordPress tutorials, you only have to provide documentation for any of the custom items. Make sure you cover subjects like how to set up the home page slideshow, how to use shortcodes, how to add or remove the social links on the site, and anything and everything that wouldn’t be covered in a basic ‘how to’ WordPress tutorial.
What Type of Content
So far, we’ve talked about written content on your custom documentation. While it is a good start, it’s certainly not all there is to it. There are many learning styles, and trying to accomodate them may create the need for other types of content: WP101 and Lynda are not going to be able to provide screencasts for your custom development work.
I always include a screencast on how to use the custom shortcodes, and even make sure I provide a link to the page on the site that uses it; not only does that show the user how to use their own custom shortcodes, it also shows them how to use shortcodes in general.
Learning to record screencasts and all that editing is a big job though. If you don’t want to learn that you still have a few options to provide screencast documentation for your clients.
WordPress.tv is a great place to start, specifically the how to category. You can find tons of videos that are applicable to your clients’ training needs, which can be included directly in your WP Help documentation.
If you don’t want to spend the time curating the basic training materials, you can always include a membership to a service like WP101 or Lynda. Yes, it costs you a bit, but then again so does the time you spend finding great tutorials. Providing these to your clients is a huge value addition, in the eyes of clients.
It’s important to note here that I don’t think screencasts stand totally on their own. Some people simply don’t learn by watching a screencast and you’ll need to provide both written and screencast documentation.
Either option allows you create a complete documentation site for a client, based on markdown. The resulting site will not be built in to the WordPress dashboard, but having a separate site also allows you to have a repository of not only your documentation, but also of business processes, branding and print, and more, which probably wouldn’t really make sense in the WordPress dashboard.
I hope that I’ve managend to convince you that simply writing code for a client is but a small part of the service you cloud be offering. Tying the whole project up with a full set of documentation is a great way to provide more value for a client, which in turn means that you can charge more, and more often, for your services.
It’s not just about the money. Providing documentation for your development work will not only make your professional services stand out above most, but also your client will love how empowered they are with their site.