Why Agile Documentation Makes Sense for WordPress

A few months ago I wrote an article for Smashing Magazine on Writing Effective Documentation for WordPress End Users. One of the points that I made was that documentation should not be written until there is a features freeze. A commenter responded:

I disagree with this statement. Tech writers are often also the sole user advocate in your organization. The sooner you get them in, the better your product will look and feel. Writers will ask questions from a user perspective that you may never have anticipated. From a workflow perspective, if you wait until the product is “done” to start documenting, then the writer is always behind, and so is your documentation. When the doc doesn’t match the UI, users get frustrated, and your support calls increase.

At the time I was all “ugh, I’ve got this wrong and now I look like a doofus”, but I still feel that documentation in the WordPress context should be carried out towards the end of the development process. Working with so many WordPress and other businesses has convinced me that I’m right.

In an effort to refine my own processes, I’ve been doing a lot of research into different documentation practices. In doing the research I’ve discovered that all along I’ve been taking an agile approach to documentation writing and that (yay!) I was right about the whole features freeze thing. This doesn’t mean that you shouldn’t get your writer involved earlier, the commenter is right that the documentation writer is essential to the development process as they bring the user’s perspective, but writing shouldn’t start until a features freeze.

To celebrate, I thought I’d write an essay about why an agile approach to documentation is the best (and only, from my perspective) approach to documentation WordPress products. Extrapolate to other products as you will, though I’m focusing really on WordPress.

What is Agile?

Agile is an approach to development that is based on iterative and incremental development. In 2001 a whole bunch of developers met in Utah and came up with the Manifesto for Agile Software Development. The aim of the manifesto is to find better ways to develop software. It has four core principles:

  • Individuals and interactions over processes and tools
  • Working software over comprehensive documentation
  • Customer collaboration over contract negotiation
  • Responding to change over following a plan

The second principle,  working software over comprehensive documentation, might freak the professional documentation writer out. After all, with less documentation what happens to our jobs?

I like to see it differently. Less documentation is a good thing. Users don’t read documentation. How many times have you answered a support forum request with a link to the documentation? How many times has someone tweeted a question when there’s an answer in the WordPress Codex? This can be frustrating for someone who provides support, and for the person who writes the docs – after all, it sucks when no one reads your writing.

But seriously, who wants to read a big documentation manual? who wants to read thousands of words in which you document your theme? It’s boring. It’s more fun to get started and break stuff.

What is Agile Documentation?

The best way to describe what agile documentation is, is to paraphrase what I think are the critical points for WordPress from Scott Ambler’s excellent Agile/Lean Documentation: strategies for agile software development

  • Communication, not documentation
  • Write documentation only if it’s the best way to achieve a goal
  • Document stable things, not speculative things
  • Let your documentation evolve: look for feedback, act on it
  • Choose someone to own a document
  • Be concise: choose roadmaps and overviews instead of detail
  • Travel light
  • Aim for just barely good enough
  • Comprehensive documentation != success. It can increase your change of failure.
  • Documentation is as integral to the system as the source code.
  • The documentation’s benefit’s much outweigh the cost of creating and maintaining it.
  • Developers rarely trust documentation, especially if it’s detailed as it can be out of sync with the code
  • Each system has its own documentation needs.
  • Ask whether you need documentation, not whether you want it.
  • Create documentation at the appropriate point in the life cycle.
  • Update only when it hurts

Hopefully from that list you get the sense that agile documentation is light-touch, written when it’s needed, and written iteratively, based on user feedback.

Why Agile for WordPress?

WordPress has a fast release cycle – you can expect a new version, with new features at least twice, perhaps three times, a year. That means that the documentation changes regularly. One major change, such as the new menu feature in WordPress 3.0 or the new media uploader in 3.5, affects products across the ecosystem. WordPress themes and plugins that rely on WordPress features will also need to have their docs updated. WordPress themes often have fast release cycles, and plugin developers are forever adding new features.

I worked with a client on a major documentation project, only for them to change how the framework worked when I was about to finish. That meant that large swathes of the documentation were no longer relevant. That’s a waste of my time and the client’s money.

Taking an agile approach mitigates against these issues. In fact, I think it’s the only way to work in the speedy world of WordPress. If you ask me to write documentation for you, I’ll be taking an agile approach. With that in mind, here are some best practices I follow to ensure that documentation is useful and agile.

Agile Best Practices for WordPress

Focus on user experience and user interface

A lot of the work I do as Words for WP involves ensuring that the information that the user needs is communicated through the user interface. Ideally, the user should be able to carry out basic tasks without leaving their user interface. Documentation should only ever be an aid. It is no replacement for a user interface that creates a seamless user experience. Beautifully crafted documentation along with a crappy UI is dumb.

Improving the UI can involve everything from ensuring that fields have clear labeling, to mapping out different user journeys beforehand. I use Balsamiq to create mockups of how the user with work through the UI, and also how they will work with the documentation. This sort of high level planning pays dividends in terms of enhancing your users’ experience.

Produce as little documentation as possible

Give your users the documentation that they need to get the job done. If it’s setting up a theme guide them through the setup. Don’t clutter your documentation with stuff your user doesn’t need to achieve their goals. Avoid being too comprehensive. Keep in mind that the user won’t read it, especially if it’s too long.

I like to think in terms documentation layers:

  • The top level provides what your user needs to achieve their primary goals – setting up the theme or plugin.
  • The second level provides additional learning, this could be supporting tutorials or links to more advanced topics.

The top level is the most important. Everything else is nice to have. It could even come in the form of tutorials or articles on your blog.

1,000 words is always better than 5,000. Too much documentation leads to various problems:

  • You have to keep it updated. If there is loads of documentation it will get out of date quickly
  • Users won’t read it.
  • Too much work!

WordPress itself has its own resources that you can use for supporting documentation. Tell your users how to set their pretty permalinks and provide a link to the codex for people who want to learn more.

Update when it hurts

Not every release of your software requires that you update your documentation. For example, if there are changes to the colours of the UI you don’t need to spend hours retaking screenshots. If the user can do everything that they need without you having to update things, then don’t bother. If a major feature, however, is introduced, then you need to get updating. Take a look at your docs and ask whether the user can still achieve what they need. If they can’t, update; if they can, go drink beer.

Know your audience

You should approach developer and user documentation as two separate entities. The aim of user documentation is to help your user use your product, the aim of developer documentation is to enable developers extend and develop your product. User documentation will not help developers extend, developer documentation will not help users do what they need. If the different groups have a need then they can refer to the other docs. By mixing the two up you confuse users and force developers to sift through content to find what they need.

You should also try to get a sense of the types of users that you have. If your product is for more advanced WordPress users then aim your documentation at them, for novice users you’ll need to keep things simple and cover the basics.

Don’t document unless you have to

If everything that your user needs is self-evident from the UI then why bother documenting? You’re adding a whole level of unnecessary work for yourself. Most of the plugins and themes I encounter require some documentation, but they don’t need to be comprehensive. Aim for an intuitive user experience and helpful user interface, document to support that.

Test and iterate

Documentation is for your users, whether they be users or developers. It should adhere to usability standards. Test your documentation and ask for feedback from your users.  If they are having issues fix the documentation. WordPress developers have excellent access to their users, usually via a support forum but you could have a feedback tab in your documentation to ask your users to report issues. Listen to your users – that’s who you work for.

A trick that I like to employ is to give documentation to my husband and get him to work through it. If he can do it, anyone can. If you’re writing more advanced documentation find someone at the appropriate user level.

Document your code inline

Documenting your code is awesome. It makes your code easy for other developers to work with. It helps documentation writers like me to look at what you’ve done without bothering you for more information. And it makes it easier for you to understand what you’ve done when you return to the code after a break.

If you have great inline documentation then a tool like phpDocumentor will be able to spit out all of the developer documentation that you need.

Make notes as you code

Making notes as you code can be really useful for documentation writers. Just noting stuff down will speed up the documentation process as the writer won’t have to go hunting for information. Memory is frustrating. You may think that you’ll remember something important but it’s easy for things to slip your mind. Even the scrappiest of notes make for a great resource.

Document stable things, not speculative things

If you want Words for WP to write your documentation, get in touch with me when you’ve reached your first beta (or earlier, but only if you want to check my diary). Writing should start when you reach release candidate. Don’t waste time documenting things or taking screenshots when your product still might change. I’ve had this happen a number of times and it doesn’t make anyone happy.

Have a document owner

It makes sense to have someone who is responsible for ensuring that your documentation gets created and is updated. I’d normally recommend that this is the lead developer. By own, I don’t mean “write”. The document owner can update docs themselves or assign someone else to do it. It makes sense for the person who knows the plugin or theme inside out to be in charge. They’re the one who knows what needs to be changed when an update is released.

Add value

This is perhaps one of the most important best practices. If you’re not adding value stop what you’re doing. It doesn’t add value to describe every field in your UI with things like “Address: insert your address” or “The products area is where you add your products.”

Everything that you do should add value to the user. If it doesn’t, ask yourself why you’re doing it. If you’re fanatical about being comprehensive, stop. Slap yourself about the face. You’re not only wasting your time but you’re making a worse experience for your users, and making them less likely to read it.

Create a Workflow

Creating a useful workflow means that your documentation is updated as painlessly as possible. I always recommend that WordPress businesses use WordPress to create their documentation section. You can’t beat a Docs custom post type with a page template for displaying a top level table of contents. Custom taxonomies can be used to organise the content. Use a hierarchical taxonomy for displaying content on the front end, and use a non-hierarchical taxonomy for flagging documents that need to be updated. You could use a plugin like Edit Flow or Content Audit to streamline your workflow and allow for editorial comments on individual documents.

My final tips for writing WordPress docs

  • Do some research amongst your users to see what they do and don’t need
  • Strip out everything superfluous
  • Think user experience
  • Have an awesome user interface
  • Complement your documentation with tutorials, use cases and hacks on your blog. This is a great opportunity to create dynamic content. Link to these in your docs (but don’t use your blog for essential stuff!)
  • Write documentation that is useful for your users
  • Keep your documentation action-based
  • Separate developer and user documentation
  • Test your documentation – if it doesn’t work, ditch it
  • Always, always, think about your user

Resources

 

5 Responses to Why Agile Documentation Makes Sense for WordPress

  1. Interesting post!

    I’m not entirely convinced I don’t think, and you do seem to mix documentation types (the Agile/Lean book talks a lot about “process documentation” such as specifications and requirement docs) but there is a lot of value in the approach you outline.

    There are many caveats of course, and I’ve yet to see a comprehensive set of product documentation (where comprehensive = usable and ‘complete enough’) for a large application built using Agile principles.

    I think it can work but there is a point in scale where it doesn’t. Hence why Agile is good for startups or small projects, but tends to drop away as the scale of the build effort (the final deliverable) starts to grow.

    There are, of course, exceptions, but they require an entire company to be aligned behind an Agile development group and many companies aren’t structured that way.

    Interesting read though!

    1. Hi Gordon!

      Thanks for your comment. I definitely don’t think this is the only way to approach documentation, but I think it is an excellent approach for people working in the WordPress ecosystem. This is largely because of the fast release cycles and the speed with which new products and features are brought out. The teams themselves may not be implementing agile, but when they get me on board these are the techniques that I use.

      I don’t think that this approach is appropriate for a large application but WordPress applications are very rarely large (except for WordPress itself). I almost exclusively work with WordPress development teams and this approach definitely works.

      Also, apologies for not responding to you sooner! I’ve been travelling over the past few weeks and I’ve been quite distracted :)

      Thanks again!
      Siobhan

  2. Excellent article. I wish more developers would heed your advice.

    I am so frustrated in the lack of or useless documentation most themes and plug-ins have. The assumption seems to be that anyone using WordPress is an expert coder so they don’t need documentation.

    The reality is if I were an expert coder I wouldn’t need your dang software.

    Even the tools for providing help tutorials seem to have lousy tutorials.

    The lack of professionalism from small companies is understandable in this wild West environment but I’m afraid will be the difference between success and failure for many.

    Please keep up the good work. You are making a great effort to improve the situation.

    1. Thanks for your comment Ric! I’m doing my best to help people to improve their docs. So far my clients seems happy with it :)

  3. Dates that go along with documentation are incredibly helpful. Knowing what month/year something was written will directly influence how much I trust it, yet it’s surprising how often I come across documentation that has no such context.

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>