Click here to monitor SSC

Roger Hart

Technical Author - Red Gate Software

What if bad documentation gets there first?

Published Monday, November 23, 2009 3:06 PM

I read an interesting blog snippet a while ago about information visualizations and their capacity to set change our view of the world. It asks whether we as information designers have a moral responsibility to our users that governs how we model their worlds ("First, do no mimetic harm.").

I feel like that about documentation sometimes: it's not ok to keep kicking the rescue dog, regardless of how used to that he is.

I've spent a bit of time with the documentation for a very large, very serious and business-y product lately. We'll be doing something in a similar sphere. Some of it is loathsome. There's poor design, poor writing, typos, and inconsistencies. It's hard to navigate, and harder to get quickly into and out of if you have a specific workflow problem. And its users lap it up. They laud it; it's what they claim to want.

This makes me sad. But is it better to pander to their lowered expectations, or take the moral high ground and give them help that, well, helps?

At a glance, it's a no-brainer. Existing documentation in the sphere is "bad" (my definition, admittedly), and a user-centred approach is "good", so we'll do it the good way, right?. But the bad documentation has set the expectations. So by making something that looks like the existing offering of obtuse reference tomes, we'd look less threatening, less unusual, maybe more serious and credible. Could it, pathological though this may seem, even be more usable?

In that blog post, Andrew Walkingshaw argues that information representations can shape experiences more powerfully than we might first realise. We know that a bad (or worse, misleading) documentation experience has a detrimental effect on a user's view of a product or brand, but what happens if the documentation is useful and true, but fails to match a pre-existing mental model?

Do existing users really love the "bad" documentation, or are they just habituated to it, experiencing a contorted kind of of Stockholm Syndrome for manuals?

It reminds me of a tweet a while ago, something like "If you knew it would increase revenue, would you change your website's font to Comic Sans?" There's a whole separate blog in that, but briefly, I'd want to know exactly what users were responding to, and why.

I guess I feel just as queasy about high-handedly deciding I know what's best as I do about continuing to kick the puppy. It comes back to content curation again - if it isn't working as designed, we'll have to revisit and likely change it. Still, it's hard to know which way to go first.

Comment Notification

If you would like to receive an email when updates are made to this post, please register here

Subscribe to this post's comments using RSS

Comments

 

John Ellam said:

I can hazard a guess at the product in question although I have not used it.
A couple of observations from previous employees spring to mind:
1 - A manager expressed concern at the help actually being too helpful because it would reduce demand for Support and Consultancy. He wanted the golden goose alive & didn't see any benefits of good documentation.
2 - End users may proclaim the current help as exactly what they want while not actually being very happy with it. Criticism of a system into which your company has invested (sunk) millions can be a fast track to the exit with a P45.
You can always make something that looks like the existing offering but make small improvements and add features to make it more usable.
Good luck with it.
November 23, 2009 10:10 AM
 

Roger Hart said:

A couple of interesting points there, John.

Being in an organisation that doesn't charge for documentation, or sell training, it's easy to forget that plenty do. I wonder how authors in those situations feel about the demand (which may not always exist) to produce documentation just bad enough to leave that market open.

Of course, where documentation supports the pre-sales process, you really don't want your evaluators to be unable to get started, or understand the benefits of your product.
November 23, 2009 11:13 AM
 

Twitter Trackbacks for Roger Hart : What when bad documentation gets there first? [simple-talk.com] on Topsy.com said:

November 23, 2009 11:43 AM
 

timothyawiseman@gmail.com said:

People often do not realize how bad something is until they start using something better.  

For instance, I did not realize how poorly Java suited me, until I started using Python.  That is not a perfect example because Java is definitely well suited to some developers and some tasks, but I did not realize how poorly it suited me and the tasks I was doing until I tried Python, but the general idea is the same.
November 24, 2009 5:43 PM
 

John said:

A lot of my work is implementing commercial software packages for my employer, then supporting them.  Regardless of the package, the documentation that is supplied is fairly generic.
Modern packages typically have large numbers of customisable settings, configuration options and data entry fields that can have their labels changed. As a result, there is noway that the "out of the box" documentation is suitable for deployment to end users directly alongside the application it supports.

Instead, it needs to be replaced with something that takes account of an organisation's customisations, conventions (both naming and language) and eliminating unnecessary information, keeping the vendor information for access by internal support staff only.
November 28, 2009 1:57 PM

What do you think?

(required) 
(optional)
(required) 
<November 2009>
SuMoTuWeThFrSa
25262728293031
1234567
891011121314
15161718192021
22232425262728
293012345
How to Kill a Company in One Step or Save it in Three
 The majority of companies that suffer a major data loss subsequently go out of business. David Wesley... Read more...

Migrating from OCS 2007 R2 to Lync: Part 4
 Having migrated the rest of our users and legacy resources across, and start getting ready to... Read more...

Automated Script-generation with Powershell and SMO
 In the first of a series of articles on automating the process of building, modifying and copying SQL... Read more...

Seth Godin: Big in the IT Business
 Seth Godin has transformed our understanding of marketing in IT. He invented the concept of 'permission... Read more...

Using SQL Test Database Unit Testing with TeamCity Continuous Integration
 With database applications, the process of test and integration can be frustratingly slow because so... Read more...