Showing posts with label Documentation. Show all posts
Showing posts with label Documentation. Show all posts

Sunday, November 30, 2008

Please Don't Let Me Be Misunderstood

There's nothing more frustrating than trying to use documentation that you just don't understand. I'm going through that experience right now. My S.O. ("significant other") is having computer problems. A few months ago, his 4 year old computer crashed. Apparently, despite active virus protection software, it acquired some fatal disease that caused the desktop unit to look for a laptop battery. It is still not functional. As a stopgap measure, I loaned him my 6 year old computer that I had replaced recently before starting school in September. In all the time I had that old PC, I only had minor problems with it last spring when it started running painfully slow. I had it "tuned up" and, from then on, it worked like new. After only 3 months, however, he is having problems with it.
Diagnosis for the computer's demise: Teenagers!
He has two boys: 16 and 17. Despite warnings, they continue to visit sites and download material that they've been warned against accessing. They deny it but my S.O. continues to get suggestive invitations from young attractive women that point to the contrary. The latest dilemma is that the system does not recognize or cannot find Windows. So, I got my hands on a CD to reload Windows XP. Because I cannot access Windows to run it from the Start menu, I have to install it in the DOS environment - and it's been a long time since I've had to do something like that. Amazingly, I've remembered a lot but, regretfully, not enough. I visited the Microsoft website and the instructions are just plain useless to me. I searched the web further and nothing seems to help. So I am now off to talk to my friends on the help desk for assistance.
In the meantime, I'd like to say to Microsoft: "Invest is some better user readability testing. Not just with the techies - do some testing with folks like me. Or, better yet, people like my S.O. who don't even know what "underscore" is on the keyboard. All sorts of people are using computers these days and would like to be able to fix problems on their own. Work with us, will ya'?!?"
Do You Read Me?
I know of what I speak! For a good part of my career in mortgage banking, I've been responsible for creating user documentation - primarily policies and procedures along with some systems documentation and job aids. I learned along the way that not everyone thinks the way I do or learns the way I do. What to me is perfectly logical and clear can be convoluted or even gibberish to another person.
If the reader cannot understand and use the documentation, it's worthless. As individuals conveying complicated information to people who have to actually take action using that information, we must remember that we are writing for others, not for ourselves. Unfortunately, not everyone who writes manuals or explanatory material understands that.
How do we determine that our documentation is readable? That it can be understood by our intended audience? We need to test it!
Testing...1-2-3...Testing...

How do you test documentation for readability?
Well, there are several different ways and your best bet is to utilize a combination of them to achieve optimal results.
Things you want to look for in your testing:
  • Ease of learning - How quickly can the user understand what she reads? Does she have to read and re-read several times to get it?
  • Efficiency of use - How quickly can the user apply the material learned?
  • Memorability - Once the user understands how to apply the information, can he remember it or does he have to frequently return to the documentation for a refresher?
  • Minimizing errors - Does the user grasp the material or does the user consistently make errors even after reading the material?
  • User satisfaction - Does the user feel that the documentation is easy to understand and helpful?
Doing the Math
There are mathematical formulas for testing readability of documents. There are the Flesch Readability Scale, the Flesch-Kincaid Reading Grade Level, and the Gunning Fog Index which use elements in text such as the average length of sentences and the average number of syllables in the words to determine how hard a document is to understand.
These tests can be done manually but that is no longer necessary. Software is available to test your content. In fact, you can test for both Flesch scores in Microsoft Word.

  1. Click on Tools.
  2. Select Spelling and Grammar.
  3. Click on Options.
  4. Under "Grammar", select "Show readability statistics."









When you complete your document, run Spell Check. After Word has completed the spelling and grammar checks, a dialog box will provide a report that looks like this. A score of "65" or higher for Readability is considered "plain language". The desirable grade level depends on your audience.
While these tests are good starting points to make your documentation more accessible, they do not measure things like whether or not:
  • You've effectively communicated the information;
  • The information is well organized;
  • The format is user-friendly and the text is legible; or
  • The content is appropriate to the users.
For that, you need to work with real, live people - representative users.

Tell Me What's On Your Mind

All of the mathematical equations in the world will not ensure that your user documentation is worth the paper or computer screen it's written on. In order to test that, you need to consult with actual users.

Select a representative pool of users. There may be many types of people using your documentation. Think about it. Ask around. Who needs the information?
In my world, I was primarily writing for people who took loan applications, processed loan applications, and prepared loan closing documents. But I quickly found that it didn't stop there. I also had state and federal regulatory agencies looking at the documentation to ensure we were giving our employees adequate and appropriate direction. Our legal department had an interest in it to support our position in litigation and customer complaints. Other internal departments, like Accounting, Loan Servicing, and Underwriting consulted it to understand processes and opportunities for improvement. So, it was necessary to consider all of these areas when documenting policies and procedures.

Ask your sample users to document their findings. They should consider various aspects including:
  • Is the information accurate, complete, and appropriate?
  • Does it flow and match what happens (or should happen) in the real world?
  • Is the information presented in a logical order?
  • Are the graphics appropriate, necessary, and consistent with the policies, rules, and processes?
  • Would more graphic examples enhance the material or should some graphics be removed?
  • Is the layout easy to use and pleasing to look at?
  • Is the typeface legible? Does it need to be larger or smaller?
  • Can desired information be located quickly?
  • Is the language appropriate? Are there too many hard words or is the information too simplified for even a new employee? Are sentences too long or too short?
  • Are there cultural, gender, or class biases?
Testers must be reminded to be critical and honest. And you, as the documenter, need to put ego aside. Don't argue over feedback. It can be tough to have someone criticize your work and tell you they don't like or understand your material. Taking a few steps back and looking at it from the user's perspective can help. Taking user suggestions will improve your documentation. Like I said, if they can't use it, it's not worth a thing.

Going back to the criteria under "Testing..." above, it may be useful to test your users' comprehension. Monitoring performance in the real world can also measure the effectiveness of the documentation.

It's Getting There That Counts

In the long-run, the goal is to create thorough, user-friendly, useful documentation. Your users will be happier. They'll also be more productive and efficient. (No more spending hours trying to figure out how to do it right!) Better documentation supports training and reduces the need for continued follow-up training. It also reduces calls to help desk or support teams and time taken by supervisors and managers to provide individual instruction.

And it will mean that your documentation will be used and valued. I was surprised when I found out just how many people in my organization used and valued the manual I created in my last position. A lot of the success had to do with the fact that I listened to my testers. I didn't always like everything they had to say but they were most often right. I handed over the documentation to others 5 years ago. It's surprising how little has changed. It was slightly reformatted but not so significantly as to be markedly distinguishable from the original. And most of the text remains the same. Better still, people still refer to it and actively use it.
I take a good bit of pride in that!






Monday, October 6, 2008

At Least It's Not My Writing...

Some things you're just happier not knowing. I recently read an article about using typefaces. Most people probably know them as "fonts"...the various styles of the characters on your computer keyboard such as Arial, Lucida Grande, Trebuchet, or Verdana.

The article is entitled "Avoiding Typeface Terrors" by Kathleen Burke Yoshida. It is interesting material. (Well, it is if you create documentation for a living.) And, I found it very helpful. But it also put me in the position of having to make a change to my documentation approach.
Righting a Wrong
You see, it seems as though I've been using the wrong typeface for my policies and procedures and training documentation for years. I like Arial. It's clean. No fuss. Just like I try to write my documentation.

However, according to the article, Arial's lack of "
serif" - or the little feet or protrusions from the lines as highlighted on the "T" to the right - makes it harder for the reader to follow the text; the reader finds it difficult to continue through the many lines of words without the little feet to lead the way.

So, where does that leave me? You might say it's easy. Just use the Microsoft default -
Times New Roman. The problem is a little print related PTSD. Times New Roman and the lighter, wider Courier bring with them the baggage from my beginning years in banking.

It was in the early Reagan years and I unexpectedly found myself in an office job where I had to type...using a typewriter! Now, I took typing in high school so I could type my own college term papers. I didn't do well in the class - too slow with too many mistakes. But I could get by well enough to pull together a legible (if not smudged) paper on an old 1940s manual typewriter.

My job, however, had me typing legal documents - Notes and Mortgages - and mistakes were not permitted. The worst was the Mortgages. Each Mortgage includes a property description which basically defines the perimeter of the property. A nice rectangular property can be a short five lines. But an odd shaped property, especially in a rural area where landmarks are tree stumps and the intersections of neighbors' lots, can go on for pages. I could spend hours on one Mortgage.

Times New Roman and many of the other "with serif" typefaces remind me too much of the typeface used on the typewriter. I have my own "emotional" response to the little feet. Plus, I think it looks cluttered.
The Search
I want to do right by my readers so I'm in search of a new typeface. Normally, I really enjoy selecting typeface...when I have the opportunity. It's usually for a flyer or other material related to my volunteer activities. I can actually spend more time selecting the typeface than drafting the text. It can be fun. There are so many options. I recently discovered that there's quite a business in creating and selling typefaces. One site I came across (http://www.veer.com/) sells some amazing, interesting typefaces for $40 to $100. Not that I'm interested in spending $40 on a new typeface.
This search, though, leaves me with little opportunity for fun and creativity. There are rules and limitations.

  • First, it must be readily available in Microsoft Office.
  • Second, it must be legible.
  • Third, it must be readable.
  • Fourth, any "personality" it has must be professional.
After scrolling through the selections in Microsoft Word, I think I'm going to give Century a try. Here's what I like about Century:

  • It's open and round. The letters are not pressed together.
  • It's not heavy. There aren't a lot of thick lines.
  • Of the typefaces with serifs, Century is one of the cleanest. The feet are more like size 6 rather than size 9.
The down side to the openness is that it might take up more space potentially adding additional pages to each document.

Testing the Typeface

The question is, does it pass the tests outlined above?
  • Available in Microsoft Office: I found this in the list of available fonts and I have not added any to my computer. I also know it's available on my computer at work. Pass.
  • Legible: To test legibility, Ms. Yoshida suggests that you "place a piece of paper over the top or bottom half of a word or sentence. If you can read the word or sentence easily by just looking at half of the letters, then the typeface is likely to be perceived as legible." Pass.


  • Readability: The type size is easy to read and it has the obligatory serifs. Ms. Yoshida says to look for a large "x-height" meaning the body of the characters (the portion above the line that does not extend above the top of a lower case "x") is larger than the "ascenders" (the parts above the top of the "x") and the "descenders" (the parts below the line). Pass.

  • Personality: The personality of Century is not quite as formal as some of the other serif typefaces. But it's not casual. Because this typeface will be used for documentation that must be viewed as credible and must be taken seriously, it's important that it is not too informal. My opinion is that it passes but I think it requires a test drive from some discerning eyes.
Wish me luck!