Technical Writing: Graphics For Software Documentation
What you'll learn
- Which rules you need to take into account from technical writing perspective when using images in documentation
- What types of graphics you can use in software documentation
- Which tools to use to create instructional images and graphics or infographics as a technical writer
Course content
- Preview06:07
- 00:57How to Use This Course?
- Preview01:57
Requirements
- Experience in writing software documentation
Description
Are you a technical writer who has a hard time figuring out how to create graphics and images that help the user of the documentation? Are you looking for a way to deliver the information in a simple to understand, visual way?
In this course, I am going to show you how simple and easy it can be to create graphics and images to guide your users. No complicated tools! No special software that requires weeks to get started!
Just simple strategies and free or common tools that help you deliver the visual information in a matter of minutes with no special preparations.
By the end of this course, you will learn:
- why and when to use graphics in software documentation
- what are the basic rules to consider when adding graphics to software documentation
- which tools you can use to quickly and easily create great-looking graphics“I was tired of hearing my documentation is hard to read and understand!”
Creating an instructional image or a graphic for the software documentation must be a simple and easy task. There are tools dedicated to that purpose, where the web designers have already created templates with the images your customers would use to better understand a concept or a task.
It is so simple to create a graphic that I am widely smiling when I see documentation that needs a graphic. I know that it is so easy to add one!
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 more SIMPLE to use... In the end as a technical writer, what can you do?!
BURN OUT!
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 a simple truth that people don’t read!
CUSTOMERS DO NOT WANT TO READ THE DOCUMENTATION!
Why?
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 learning to read and write. It is not a 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.
Images activate your brain. You can understand what you see in a fraction of a 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 in 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!
Join me in my course on how to make graphics for software documentation and make your customers happy by offering them simple and easy to understand graphics and images!
P.S. This course comes with a 30-day full refund policy - no questions asked!
Who this course is for:
- Technical Writers
- Business Analysts
- Software Developers
- Information Developers
Instructor
Learning technical writing is easy - after all, it's just plain docu!
JPDocu School of Technical Writing is a training company that is passionate about user assistance, technical communications and making it a positive user experience. Our e-learning courses help us shape the next generation of technical writers and information developers, by providing them with simple to follow and practical, hands-on experiences with technical writing.
Our mission
Nowadays everyone talks about the professions of the future. People are scared that they are not prepared for the needs of the future of work. We believe that change is not to be feared. We believe that with the proper training, education and practical experience, our customers will be ready to meet the future with joy. The best way to concur with this fear is by studying and learning.
JPDocu School of Technical Writing transforms this fear into practical knowledge, getting people ready for the job of the future - Technical Writing. Taking our programs online allows us to reach all of you across the globe!
Our Vision
JPDocu School of Technical Writing is here to deliver top-quality e-learning courses and training (both online and on-site) that help you learn the profession of the future. We bring our courses to the world using various training platforms and interactions with our students.