Minimizing Confidential Content in Documentation Images

Monday, May 12th, 2008 | Tech Tips, Technical Communication

With so many electronic storage systems that contain sensitive or private information, it’s inevitable that technical communicators are involved in documenting these systems. Personal, medical, and financial data reside in massive databases that someone probably uses an application interface to manipulate, and that someone may need some user assistance along the line.

Illustrations go with technical writing like chips with bean dip. But how do you document a system that deals with confidential information without displaying that information? Some people need little excuse for a lawsuit, and you don’t want it to be over what you did in the documentation. Management would frown more than a little on that.

Using Fake Data

One way is to use test data—the kind that’s phony as a nine-dollar bill. Obvious test data, but not too obvious like the sort the testers use.

Name: Joe Test McJones
Address: 123 Just a Test Street, Testville USA

Look familiar? I try to keep away from that. I also like to keep it professional; for example, if an electronic form has a field requiring explanations for changes, I would avoid putting “I felt like it” in the sample image. Using fake data works well especially for areas of the application that focus on one set of data, such as one individual or organization. It’s pretty simple to change a name or title, some mailing address information, and telephone numbers in the interface and then capture your image.

If you can access test versions of the system and generate your own set of data, you’ve got screenshot-ready interfaces.

Making Use of Graphics Tools

Let’s complicate this a little. Say your application shows list or summary screens that would require large amounts of fake data in order to protect privacy. What is your game plan then?

Here’s another wrench in the works: There is no test database, for example in a second system that your application connects to. Therefore, all data that your test builds borrow from the second system belong to real people or organizations.

This is where using a good graphics program comes in handy. I have fallen to using marquee tools to move text around. For example, if I have some seven-digit identifying number associated with a name, I use the marquee tool to grab one of the numbers and slide it over each of the others, so I end up with something like 3333-333. If there are a few identifying numbers shown on the same screen, if they all use repeating numbers like this, it becomes apparent that you’re not representing actual data. Ascending and descending numeric arrangements are ever classic and probably safe.

Common names for people and streets in your country help. Some American writers fall back on the run-of-the-mill names “John Doe” and “Jane Doe.”

For me, it’s a lot faster to take a marquee tool and move some characters around than to spend hours cooking up fake data for a screen that I will have to capture once.

Another option that I tried once was a smudge or blur tool when there was only one or two sensitive items on the screen, but that came out looking sloppy. I definitely prefer the obviously fake data approach.

A Disclaimer Is Your Friend

Of course, one way to cover yourself is to include a notice somewhere in your deliverable that explains that no images contain real data, and no resemblance to actual people (or organizations, etc., if applicable) is intended—you know, the blurb that runs at the end of the credits of movies and TV shows. If the lawyers come knocking, you can at least show them the disclaimer.

Remember that when you fake data in your images, you’re not protecting just those whose information is being scrambled—you’re protecting your organization and yourself.

Share This