RSS 피드 구독하기

The easiest way to get people to read what you write is to make diagrams and technical illustrations prominent in your documentation. A graphic should represent every key concept in your document. Why? Because pictures get attention and convey a lot of information quickly.

Don't believe me? Try this experiment.

Understanding the power of pictures

Below are two videos.

Take a look at this first one only once with no repeating or pausing.

Tell me, what's it about? Bet you can't answer the question.

Now take a look at the second video, again only once with no repeating or pausing.

(A description of the contents of each video is provided at the end of this article.)

I'll wager that you can figure out some of the content in the second video. Let me explain the details.

People read by pictures first

Back in the early 1990s, before the Internet was what it is today, the way people learned how to set up a computer was by reading the user manual that came along with it. Back then, I worked at the third-largest computer manufacturer in North America. The company used a direct-to-customer business model. People called up by telephone to purchase a computer which the company shipped to them via UPS. Part of the purchase was free tech support.

It turned out that non-technical users had a hard time setting up their machines, despite having a manual at hand. As a result, they called tech support for help, and each call to them cost the company a good deal of money. Wanting to reduce technical support costs, the company decided to find out why the user manuals weren't working. So they sent the problem to the Usability Department.

This is where I come in. At that time, I was attached to the Usability Department.

We ran a study where we put an unopened box with a computer in a laboratory room that looked like a home office. The room had several video cameras positioned at different angles to observe and record the activities in the lab.

We paid subjects to come in to unbox and set up the computer. We watched them very closely. The first thing most of the subjects did was to open the manual and try to follow the setup instructions. Just about all of the subjects leafed through the pages of the manual. However, when a subject came across a page with a picture, he or she stopped, looked at the picture, and read the page. This observation was an important piece of information.

After the study, the company implemented a new policy for writing user manuals: every page that described a concept or action had to have an illustration on it. The hope was that as the number of images went up, the call rate would go down. The correlation was hard to ignore. And, as I recall, I think that the call rate did go down.

No matter what, the lesson I learned from that study is one that I use today. People read by pictures first. The following is a concrete example that proves the point.

A concrete example

Consider the following piece of technical writing that uses only text.


In this scenario, you will install a demonstration microservice written under Node.JS and installed as a Docker container from DockerHub.

The application has two subordinate services, frontend and business. The frontend service delegates to business to call worldclockapi.com to get the current time. However, because the microservice will be running under a Kubernetes cluster controlled by an Istio service mesh, users cannot access the frontend service by default. An ingress rule is needed to allow access. Part of this scenario is to apply a pre-installed ingress rule to Istio.

However, even if users could access the microservice, the microservice would not be fully operational because the subordinate service, business, will still try to access worldclockapi.com. Istio will not permit this unless an egress rule is set to allow calls to the external site. The final part of this scenario is to apply a pre-installed egress rule to Istio to allow access to worldclockapi.com.


Now take a look at the same text with a diagram added.


In this scenario, you will install a demonstration microservice written under Node.js and described as a container.

Control routing with ngress and egress rules

Figure 1: Using ingress and egress rules to control routing in an Istio service mesh under Kubernetes

The application has two subordinate services, frontend and business. The frontend service delegates to business to call worldclockapi.com to get the current time. However, because the microservice will be running under a Kubernetes cluster controlled by an Istio service mesh, users cannot access the frontend service by default. An ingress rule is needed to allow access. Part of this scenario is to apply a pre-installed ingress rule to Istio. (See Figure 1.)

However, even if users could access the microservice, the microservice would not be fully operational because the subordinate service, business, will still try to access worldclockapi.com. Istio will not permit this unless an egress rule is set to allow calls to the external site. The final part of this scenario is to apply a pre-installed egress rule to Istio to allow access to worldclockapi.com.


Which version of the documentation will get the reader's attention quickly and will be easier to comprehend? I'll hazard to say the version with the diagram will be your preference. As you can see, pictures work!

Putting it all together

Pictures are a powerful way to express complex concepts. Adding text to describe the abstract ideas in the given illustration provides the added clarity needed to ensure that the reader can comprehend content fully and quickly. Using text and pictures to communicate complex technical ideas goes hand in hand.

A good rule of thumb to follow is that an illustration should represent each concept in a piece of technical documentation. Then, once the image is in place, write "around the illustration" to provide the descriptive details necessary to express the idea or action at hand adequately.

Creating informative, engaging technical documentation is an essential part of software development and enterprise architecture. Using both text and illustrations will go a long way to creating technical documentation that users need and will actually read.

What's in the experimental viewing videos?

The first video used in the view experiment above is the front page of the New York Times reporting the assassination of Abraham Lincoln. The second video is the front page of the New York Times reporting the sinking of the Titanic.


저자 소개

Bob Reselman is a nationally known software developer, system architect, industry analyst, and technical writer/journalist. Over a career that spans 30 years, Bob has worked for companies such as Gateway, Cap Gemini, The Los Angeles Weekly, Edmunds.com and the Academy of Recording Arts and Sciences, to name a few. He has held roles with significant responsibility, including but not limited to, Platform Architect (Consumer) at Gateway, Principal Consultant with Cap Gemini and CTO at the international trade finance company, ItFex.

Read full bio
UI_Icon-Red_Hat-Close-A-Black-RGB

채널별 검색

automation icon

오토메이션

기술, 팀, 인프라를 위한 IT 자동화 최신 동향

AI icon

인공지능

고객이 어디서나 AI 워크로드를 실행할 수 있도록 지원하는 플랫폼 업데이트

open hybrid cloud icon

오픈 하이브리드 클라우드

하이브리드 클라우드로 더욱 유연한 미래를 구축하는 방법을 알아보세요

security icon

보안

환경과 기술 전반에 걸쳐 리스크를 감소하는 방법에 대한 최신 정보

edge icon

엣지 컴퓨팅

엣지에서의 운영을 단순화하는 플랫폼 업데이트

Infrastructure icon

인프라

세계적으로 인정받은 기업용 Linux 플랫폼에 대한 최신 정보

application development icon

애플리케이션

복잡한 애플리케이션에 대한 솔루션 더 보기

Virtualization icon

가상화

온프레미스와 클라우드 환경에서 워크로드를 유연하게 운영하기 위한 엔터프라이즈 가상화의 미래