Screenshots in software product documentation have always been a contentious issue – you either like them or you hate them. Personally, I am not a great fan of having them in the documentation.
Let’s look at the arguments made to include screenshots in product documentation.
Provides the user context: This assumes that the user is reading the documentation away from the application – a rare occurrence. In a universe where the documentation is usually provided within the product and not as a printed book separate from the product, this is a relic from the old days when user manuals were printed books. Today, I cannot see someone sitting in bed at night and trying to read up on how to file GST using their accounting software. The chances are much higher that they are in front of their computer with the application open in one window and the user manual in another.
Helps explain the interface: This is the most common reason given for requiring screenshots. But pause a bit, think about it and you realize that the real complaint isn’t that there isn’t a screenshot but that the screen is designed badly.
While instinct tells us that the user needs to know this information, the fact is that a lot of software actions are learned behaviors. As long as there are no unexpected surprises, users tend to learn very quickly where they will find what. To key to making such an approach in the product work are two – consistency in placing the right things in the right place and using common, easily identifiable icons. Failing to do either cannot be fixed by all the documentation and screenshots in the world.
Simplifies complex workflows: Many software today try to do too many things on the same screen. Let’s take a payment screen as an example. Today we have multiple ways in which a customer may want to pay for a purchase. In an attempt to cater to every payment option, we clutter the page. The aim should be to declutter the page and show only the required options based on the user’s last selection. Every time I am told that an article requires a screenshot because it is a complex page, my answer is (even if I don’t say it out loud) that the solution isn’t a screenshot but a page redesign.
Makes the article look appealing: While what is more appealing or less is a very subjective thing, most people don’t come to a product documentation article to see a page that is pleasing to the eye. Going to help is the last resort for most users, if not all. They are usually there because they have looked all over the interface and haven’t been able to figure out how to complete a task. On the Help page, they expect to find the instruction that will unblock them so they can get back to their task. Screenshots don’t add any value in this situation unless what they are looking for is hidden away from sight. In which case, it is a product or screen design issue rather than a documentation issue. This dovetails beautifully into what I want to talk about next.
I guess you get the gist of where I am going with this – the call for more documentation is usually a sure shot indicator of a badly designed product. A good product requires minimal how-to documentation. If we had well-designed products, documentation teams can focus on documentation that focuses on the why and what-else rather than describing the how.
Comments