Information Architecture Blog Posts
Do you want to share your thoughts and expertise with the community? Post a blog in the Information Architecture group to get the information exchange started.
Showing results for 
Search instead for 
Did you mean: 
Product and Topic Expert
Product and Topic Expert

"I am tired of hearing that my documentation is hard to understand!”


What if you could make professional looking graphics using no-sweat tools, to take the pain out of consuming software documentation?


I used to be terrified whenever I needed to create a graphic to simplify complex information.


I already knew that the customer didn’t want to read the software documentation. Imagine the hassle of purchasing, installing, and setting up the software. And just when the customer beings to use the product, they hit the pain of reading the user manual.


Providing the necessary instructions at the point when they are needed is at the heart of technical writing work. But how do we deliver it if nobody wants to read it? Doesn’t this drive you nuts too?


There is a constant balancing act that technical writers undertake to write all the possible details for using a product while trying not to overwhelm readers with mountains of text. Then they face criticism because the exact use-case isn’t covered, or because the documentation is difficult to consume and understand.


What can you do as a technical writer? Usually, we end up reworking the documentation over and over in search of that elusive “golden document” that provides our users with exactly what they need.


But the document is still the same pile of words that the user needs to read. And every time you rewrite it, chances are that you add even more words! Let’s be honest here, how many times you have 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 online. You seek advice and talk (complain) to colleagues. You change the documentation architecture, and undertake 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 an exercise in futility. 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 make much sense unless you tackle the root cause of the problem. What is this root cause? It’s the simple truth that people don’t read!






One of the greatest inventions of humanity, was the discovery of writing. Written words that can be put on stone, on paper, or on the computer screen, to be understood by other people.


But is that easy?


We spend years at school to learn to read and write. It is not a NATURAL skill that you are born with. 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 wired to understand visuals in a matter of milliseconds. Not minutes, not seconds, but a fraction of a second! As if our lives depended on it. In the early days, our lives as humans depended 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.





Which one triggered the biggest reaction in your brain - when you read the word stop or when you saw the big STOP sign?


It’s the sign, 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 now.


Simplicity in software documentation means you need to make the information visual, making it easy to consume for your reader.


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 your product.


Do you agree with this? Have you replaced text with multimedia before? How did it go? Let us know in the comments.

1 Comment