“I am tired of hearing my documentation is hard to read and understand!”
What if you could make professional looking graphics, using no-sweat tools to deliver simplicity in consuming software documentation?
Hi, I’m Jordan Stanchev.
Years ago, I was terrified every time in my documentation I wrote needed to create a graphic to make complex information easy to understand.
I already know that the customer does not actually want to read the software documentation. Imagine all the hassle of purchasing, installing and setting up the software. And just when you are about to begin using it - “Oh! I need to read the user manual…”. Do you think that’s fun?
If there is one thing that is so hard and at the heart of our technical writing work, it is to provide the necessary instructions when they are needed. But how to deliver it, if nobody wants to read it? Doesn’t this drive you nuts too?
It’s this constant expectation towards technical writers to both write all the possible details for using the software, and then dealing with the criticism that there is too much documentation, but not the needed one. Not the right one. Not easy to consume and understand.
What can you do as a technical writer? Usually, tech writers go and re-write the docu. Again. And again… they call that “work”.
But it’s still the same pile of words that the user needs to read. And every time you rewrite it, I bet you are adding even more words!
Come on, let’s be honest here, how many times you have actually deleted pages from your documentation, when you were asked to make it “simple and easy to use”?
Did the complexity decrease? How about the volume of the documentation - did it grow up or down?
And you start searching for the answers. You sign up and pay for technical writing courses. You start asking questions on Quora. Try to seek advice and talk (complain) to colleagues. Wonder how to make it; restructure, change the architecture of the documentation, make more and more customer interviews to figure out how to make it SIMPLER to use...
In the end as a technical writer, what can you do?!
Constantly reworking your documentation is like telling a person with weight problems to start 3 diets at the same time, to satisfy his or her hunger!
Yeah, true, but HOW? Do you need to change the order of the documents? Do you need to invest in SEO? Do you need to write a ton of new documents? Do you need to start from scratch?
None of these tactics will make much sense, unless you change the actual root cause of the problem.
What is the root cause? It’s the simple truth that people don’t read!
CUSTOMERS DO NOT WANT TO READ THE DOCUMENTATION!
One of the greatest inventions of humanity, ever, was the discovery of writing. Written words that can be put in stone or paper or on the computer screen, that can be understood by other people.
But is that easy?
We spend years at school to learn to read and writer. It is not NATURAL skill that you are born with. Nobody is naturally born with the skill to read!
It is something that we learn - at school!
How do we learn to read? May I ask you to search and find a book for kids that teaches them how to read? What do you see in there?
Z is for Zebra!
Take a look again as a technical communicator! Now think - there is a Zebra image next to the Z letter. An image! Next to the letter!
Why is that? What makes the image so important?
It’s because, unlike reading, human beings are prone to understand visuals in a matter of milliseconds! Not minutes! Not seconds! But a fraction of a second!
As if our lives depend on it. And in reality, that is the actual truth - our lives as humans depend on visuals and our ability to understand visual messages from the world around us.
Let’s test your own perception: which one triggers a reaction in you:
The word: stop.
How about this one now:
Which one triggered a reaction in your brain - when you read the word stop or when you saw the big STOP signal?
It’s the sign signal, of course!
Images activate your brain. You can understand what you see in a fraction of the second. It’s a natural skill that you were born with.
Not like reading! Reading requires conscious effort, then analysis of what you’ve read and then understanding what you’ve read.
Do you think it is different with software documentation? Which one is easier to grasp a 2-page long text description of the architecture of your software or the graphic that shows the different components and how they are related?
Obviously, as a technical writer your first reaction will be: “I need to write this down!”. But if you really strive for simplicity, for made-easy-to-consume information, it is a graphic that you should be working on right this minute.
Simplicity in software documentation means you need to make the information visual! Easy to use for the customer!
Not for your manager, not for the development team you work in, not for the information architect of your project, but for the end-user who needs to understand and figure out how to use the documentation!
For the user! And for the user only!