Why user support documentation should be part of your design process
- Catherine Maughan
- Jun 14, 2021
- 6 min read
The way it usually goes is … you do some research, design your product, user test it, iterate, etc, until it’s ready to release to the public. Once it’s out there, you start finding and fixing bugs, and users complain or start asking about other functionality that, despite your best efforts, they can’t seem to find or don’t understand how to use. So, you build a knowledge base and compile a list of FAQs and stash them somewhere on your website.
Of course, a robust knowledge base and FAQs area is a great asset and a key part of your product support documentation and covers all the possible use cases, providing explanations for the least capable of your users. However, you can’t help thinking that if only you had designed the product better, you wouldn’t need all of this support documentation. If you had been able to anticipate some of these issues that your users are having, then you would have been able to avoid them. So, what’s wrong with your design process and why are these issues slipping through?
What? Why? Where? and How?
When I am writing support documentation for a new feature, I need to understand it from the perspective of the goals of the business, the design objectives and the user need. It is only the last one that concerns me, but this has sometimes been subsumed by the first two. To break it down for the user, I look at three key areas:
What does it do?
The first thing I need to explain is what the feature does and why they might need it. This is somewhere that the user experience can easily suffer, as business goals get mixed with design goals. Sometimes, this new feature makes all the sense in the world to the designer but serves no obvious purpose to the user.
In one example, I was documenting a new feature on a photography website which allowed photographers to send photos to clients for proofing. The feature allowed the client to mark the photos they wanted to order. But instead of using a simple ‘order’ button or a checkbox to mark photos, the designer decided to combine it with a ‘reactions’ feature, so that the client would choose from a range of emotions to select the photos.
The result was that neither the client nor the photographer actually knew whether an order was being submitted or whether they were simply showing appreciation. When the purpose of a feature is not clear, it’s not effective and can not only result in negative user experience but - in some cases - lost business.
Where do I find it?
The next thing that I need to make clear to the user is where to find the feature. This includes where it is accessed from but also where users are arriving from in order to get there i.e. is it obviously accessible at the moment when they need it? If the functionality is hidden or placed somewhere that isn’t intuitive to the user, this can create a very frustrating experience for the user or, in other cases, means that the feature just doesn’t get used.
The location of the feature may end up changing after input from stakeholders e.g. in order to make it more/less prominent, but without taking into account the user journey. It may end up in some compromised location which is counter-intuitive to the user.
In the below example, Add Blog Page seems to fit naturally alongside Add Content Page, so why not add both into a dropdown menu, providing for the eventuality that more items can be added in the future.
However, the user would typically arrive here after creating their blog post in the blog manager area looking to add the blog to their website. The user can’t find the word “blog” anywhere on the website editor interface. While, from the developers end, adding a blog page is the same as adding a content page, to the average user it’s quite different. Having your standout features hidden in a dropdown menu or behind copy that doesn’t speak to the user is going to mean that feature won’t get the interaction and use it deserves.
How does it work?
And finally, the purpose of support documentation is to explain how something works. This should be the easy part, as designers have already documented it extensively and it has been tested and iterated already.
The key here for me is explaining the functionality in terms that make sense to the user. Issues that can come up here are how the user interacts with the functionality in contexts that haven't been considered as part of the design process. Sometimes assumptions are made about the users knowledge of an entire ecosystem when they may only be interacting with parts of it on a sporadic basis, so functionality needs to make sense both in context and on its own.
In one example, a client wanted to roll out some gamification features to their platform. The tool introduced a number of elements that were completely new to the platform and which integrated a new storytelling element around spells and magic. The concepts were too complicated to understand within the context of the feature and the user ends up not knowing what it's for or how to use it. In the end, the feature was simplified, removing some of the gamification elements but improving the user experience.
In some of the examples I’ve given above, my input came too late into the process to be able to have any impact on the design. The feature had been designed, tested and launched already. So why had nobody spotted the flaw until then?
Bringing Support Documentation into the Design Process
The role of support documentation, as I mentioned above, is to cater for the least able user, and to plug the holes that the design hasn’t been able to cover. Looking at it in this way often uncovers issues which have been missed along the way, either because of blind spots in the design process, user testing which is too focused, or sometimes just an outside perspective is all that’s needed to highlight things.
“We hired Catherine to edit and revise the User Guide for our SaaS. She is extremely knowledgeable and a very quick learner. Her initial audit was extremely detailed and thorough, with great UI/UX recommendations as well. She worked in a very time-effective manner and asked great questions along the way to ensure the User Guide was concise, detailed, and user-friendly.”
Michael Few, Story Pro
Figuring support documentation into the design process is a great way of anticipating user needs before it’s too late, improving the user experience and saving money in the long run.
Creating user guides at an early stage, before your product or feature has been launched, is an easy and cost-effective way to uncover flawed or counter-intuitive functionality. I can audit your site or process to uncover things you might have missed.
Getting to “Documentation-Zero”
Ultimately, the better the product, the less documentation it needs. Apple, one of the most user-focussed tech companies around, revolutionised how we think about support documentation when it launched the iPhone’s minimalist packaging, with accompanying mini-user manual. They know that most users never read the manual and the way to perfect product design is to make the functionality as intuitive as possible.
And if you think it’s counter-intuitive for a documentation specialist to talk about killing documentation, well .... maybe, but I don’t think so. With technical writing, as with UX writing, conveying meaning in as few words as possible is one of the main objectives, so the editing becomes just as important as the writing. This “less is more” principle can also be applied to technical documentation in general: if changing one button on the interface saves the user from searching for and then reading an FAQ article, then that is what I’m going to suggest as a solution. Applying UI changes isn’t always so easy in practice, and FAQs are often used to paper over the cracks in the short term. However, if the end goal of serving the user is always kept at the forefront, then the documentation becomes part of an ever-evolving process of improvement and optimization, rather than an isolated last resort. That is why integrating it into your design process is key to a better user experience and a better product.
Comments