We’re a software development company, so documenting software products is part of our job.
A project is considered done if the features work as expected, and the product is handed over to the client with a user guide and training. It doesn’t end there, however. What if the client wants some changes on the interface? Our technical writer (that’s me, by the way) will have to update the screenshots in the user guide so that the client won’t be lost the next time she wants to use it. What if new functionality is added later? You guessed it, the user guide will have to be updated. This iterates as many times as the software is updated.
Documenting consumer products vs documenting software
As anyone working in customer support can tell you, out of date documentation can be worse than having no documentation at all: screenshots and videos are the most important visual clues that inform a user if they are still on the right track. If the interface changes, and the screenshots aren’t updated, the user will be lost and confused. And the situation gets even worse when a small change on the interface affects many related tutorials.
That’s why documenting software products is a totally different setting than documenting consumer products. Traditionally the functionality of consumer products didn’t change after you bought them: a vacuum cleaner was the same vacuum cleaner for years to come, so it was natural that you could use the supplied documentation for the lifetime of the product. With today’s smart appliances and software products, functionality is updated, changed or added all the time, so it’s just natural that their documentation should follow up on these changes.
When we set out to build a better documentation format for the websites we build for our customers, we had to come up with a solution to address the issue of continuously changing products.
Why do products continuously change, anyway?
Agile has become a widely adopted software development methodology for small and large businesses alike. Methodologies like scrum and kanban let you quickly respond to change and ensure customer satisfaction through close collaboration between the development team and the client. The project is broken down into the smallest possible tasks that are then assigned a value based on complexity and a priority based on business goals. Scrum team members take on tasks, and release working software versions in very short release cycles. The client can change the priority of tasks if needed without interrupting the process.
This approach has great advantages, like allowing the client to change priorities and requirements quickly, promoting transparency, keeping team members motivated and presenting a predictable release cycle. Some teams update their software products several times a day.
That’s crazy, how can you keep up with this?
We’ve learned that to keep up with software updates, documentation has to address the issues of design changes, solve the problem of outdated screenshots, automatise as many processes and reuse as many existing assets as possible.
WalkHub is still very much a work in progress, but we are developing its features with all this in mind. We are building the Ultimate User Guide to the Internet, so it’s crucial that it’s something that people will actually use. It’s free (and will stay free), so if you’d like to try it out, we’d be very happy to hear about your experience!
