A little knowledge can go a long way, and often suffices to empower customers to solve their own problems by giving them the knowledge they need.
In a previous article, we talked about the difference between onboarding steps and onboarding guided tours.
This part of a broader context of documentation for your users. Let’s examine the different ways you can provide documentation in a bit more depth, including the formats of the documentation and in what ways these may be beneficial to you and your customers.
The first, and most obvious way of providing documentation, especially if you have some kind of application product, is a help page. Documentation in the most traditional sense. This might an FAQ, a Wiki on your site or something else that is available to users that explains how to accomplish common tasks, whether that’s adding their own customers to the system or how to process a workflow.
This could be hosted on your own site or it could be a part of a helpdesk software like Zendesk. This tends to be very good as a baseline to have, especially if you have any kind of support staff. It’s something you can share with customers if they are emailing in for support without duplicating the effort.
Ideally, you want to populate the system with some of the basic instructions that tell your customers how to get started and how to accomplish primary tasks. Then, when your own customers have questions, write up the response to them. Rather than emailing this response to them, add it to the helpdesk system and send them a link. Of course, you’ll then want to follow up.
Again, this is a great baseline because its self-help, but most customers don’t tend to dig through documentation unless the application is core to their job.
Videos, screencasts especially, can augment written documentation. We’ve done this ourselves with clients, showing them how to use new and even legacy tools, often so they have the training available for onboarding future new hires.
A screencast eliminates some of the ambiguity that you might find in written documentation no matter how well you’ve written it. This is going to be, again, for specific workflows in the application or specific tasks you want to accomplish that you can do with the application or specific interfaces.
In an ideal world all interfaces are so intuitively designed that they’re self documenting. In the real world some interfaces are necessarily more complex and require some finessed explanation.
And then, of course, you can have something that’s more of a guided tour. The guide, as we discussed before, will go through a tour pointing out things in the interface. It can be oriented around the interface or tasks.
The benefit of guided documentation it taking content you have in typical documentation and injecting into the context of the interface.
Not just an onboarding tool, a guide can be something you allow the users to toggle on or off, as well. Let them have something to reference as needed. And if you make changes to the application, you can update the guide for new users and existing users as well.
Don’t forget ‘always-on’ help content that you might not consider documentation. This can include short descriptions for pages or sections and even form field labels, help text, and validation messaging. It’s important to consider this part of your documentation because it explicitly tells users how things are supposed to work.
By default you should be including this kind of documentation, but keep in mind it’s not a cure-all. If its part of your application that typically means its not something that support staff can update on their own.
One solution to this particular problem is to add minor content management features. We created Django Addendum to fit this need, and you may find that integrating richer content controls enhance your team’s ability to respond to customer questions.
Ultimately the best thing you can do for your users is provide an interface and processes that inherently describe how they work. And even if you do that… document!