Why bother with user documentation in recessionary times?

Although many organisations see user assistance as a "good thing", it's not immune to the belt tightening that many organisations face in times of difficulty.

Business expert Mike Southon recommends that in recessionary times, organisations should focus on getting sales from existing customers - so customer retention becomes ever more important.

There's a virtuous circle of a customer finding user assistance helps them and becoming a loyal and happy customer. Whilst user documentation can help with the perceived quality of a product before the sale, its key value is in keeping customers: customer retention in marketing-speak. It's the philosophy of Toyota and others - the focus on quality and customer service.

Chris Bose of In Press PR Ltd, told me that recessions are the times when market share changes. This is why successful companies reduce their advertising spend, but never cancel it. They know that when the economy turns and business improves, they'll get more sales than the competition - more sales than they ever did before, most likely.

Recessions are also often the times of greatest technological change. The Great Depression saw the wide-scale introduction on electricity to houses in Britain, and, today, we're seeing significant developments in Help Authoring software. Those companies that can adopt these new developments in user assistance now will be able to differentiate themselves from their competitors - something of importance in these highly competitive times. As the economy swings upwards, this competitive edge will make a difference in sales.

However, it can very hard to measure the effectiveness of documentation. Again, this is where recent technological changes come into the place. A number of Help tools now enable you to measure how many people accessed your documentation, whether it assisted them or not, as well as many other useful measures. Indeed, Web based user documentation can be the trick to increasing your Search Engine rankings (but keep that a secret!).

It may be that you can provide better user assistance for less money. You may find you save on translation costs, lower support calls and lower printing costs.

Perhaps the question should not be "why bother?", but "how can we do it better?"

What I learnt from 21 hours of interviews with UK Documentation Managers

After conducting 21 hours of interviews with Documentation Managers and writing a 7,000 word report on the findings, two factors stand out:

1. The importance of usability testing documents.
2. The importance of measurement.

As the saying goes, you can't manage what you can't measure.

UPDATE: The report is now available for purchase via the Cherryleaf online shop: Benchmarking Survey of UK Publications Teams - Special Report

Who says documentation doesn't matter?

From Ars Technica

Judge: Microsoft documentation unfit for US consumption

By John Timmer | Published: September 25, 2008 - 07:50PM CT

Microsoft may have made a big push to settle many of the antitrust actions facing it around the globe, but those efforts have run up against a major stumbling block: the company's inability to document the protocols need to interoperate with its own software. Documentation problems got Microsoft in hot water with the EU, and they're now the only reason it continues to be under court supervision in the aftermath of its antitrust settlement. But, despite having interoperability become a corporate strategy, its documentation efforts came under fire in a court hearing earlier today.

In the wake of antitrust actions, documentation of Microsoft technologies has become a method of allaying the concerns of legal authorities in both the US and EU. By providing documentation of the APIs and protocols used by its products, Microsoft would not only allow third-party and open-source software to interact better with Windows and other software, but potentially enable them to write replacements, in whole or in part, for Microsoft products. This, in theory, would enable more software companies to compete on equal terms with Redmond.

Unfortunately, the company has consistently had trouble with producing complete and useful documentation. As noted above, the company struggled to satisfy EU authorities that it was complying with the agreement—that was 2006. By 2008, documentation was rearing its ugly head in the US court system. Microsoft's consent decree with the federal and state attorneys general was set to expire, and most of the conditions were allowed to. But Judge Colleen Kollar-Kotelly, who is overseeing the consent decree, ruled that Microsoft still hadn't sufficiently documented some protocols, despite those documents having been due in 2003. As a result, the consent decree will remain in place at least until November of 2009.

(continues)

Poor documentation helps land Microsoft with a $1.35bn fine

Arjuna Krishna Das posted a link to an Information Week article on Microsoft's fine from the European Union.

http://www.informationweek.com/news/showArticle.jhtml?articleID=206900497

"Specifically, the EC ruled that Microsoft was overcharging rivals for the documentation they need to make their server products interoperable with Windows-based PCs and servers. The decision was upheld last year by Europe's second highest court.

Following the ruling, the EC ordered Microsoft to make its technical documentation available to rivals under "reasonable" terms and conditions and to work to make its technologies more interoperable with third-party products."

I seem to recall a presentation a few years back, where someone said that Microsoft was using journalists rather than technical authors to develop the Help for the Microsoft Vista Operating System.

Maybe there's now a ROI case for Microsoft using more technical authors?

The ROI of documentation and support

In two conversations this week, the issue of "how do you measure the value of documentation?" has come up.

The benefits of user documentation (reduced support calls, increase in the perceived value of the product, happier customers, better customer retention, increase product usage etc) can be identified, but it can be hard to measure them and accurately quantify the Return on Investment.

Here are two ideas:

1. Conduct a test with two groups of potential users. Give one group your product to install and use for a period without documentation. Give the other group the product with documentation. Ask each participant (a) At what price should this product be sold for? (b) What monetary value would you place on the documentation? For (a), those that had the documentation should value the product more highly than those that didn't. The difference between the two prices gives you one indication of the monetary value of documentation.
2. If you have a Web-based application, use Google Analytics to measure the number and types of people using the Help pages. By placing a value on each visit (e.g. every 2 Help pages visited equals 1 support call avoided), you have another indication of the $ value of documentation. You can use Google Analytics to measure usage by embedding its code into the HTML of each page. Also, some of the Help Authoring Tool vendors offer analytics software for LAN based Help.

What is the value of user documentation?

One of the biggest challenges for technical authors is to demonstrate and assess the value of the work they do. This is is also true in some other professions as well, such as those in design.

I came across an article by Suzan Boztepe on what exactly constitutes user value and how design can contribute to its creation. Although her focus is on design, some of her findings have relevance to technical communication.

The article is here - http://www.ijdesign.org/ojs/index.php/IJDesign/article/view/61/29

Boztepe identified four major categories of user value: utility, social significance, emotional, and spiritual values.



Typically, the value of user documentation is measured by its utility. Perhaps it should be valued by these additional categories as well?

Create User Documentation - Is this really what we're doing?

One of our business partners, Dr Alan Rae, has written an excellent report on Web 2.0 early adopter research.

In partnership with Brunel University, Alan's company has been talking to some early adopters about how they have been using Web 2.0 techniques to punch above their weight.

Again, it raises issues that relate to how technical authors might use Web 2.0 technologies to engage (or not) with their audience.

Here are some quotations from Alan's article. My comments are in brackets:

"They (early adopters) learned to start with on-line conversations, develop trust, build collaborative partnerships which spread the costs of customer acquisition and use the tools of Web 2.0 to build and deploy an on-line knowledge base of testimonials and examples of their work to build credibility and attract interest and referrals...

But the most interesting thing of all is how individuals - often in their second or third careers and often one man bands - use the collaboration implicit in web 2.0 to rapidly develop their own knowledge of how to exploit these tools - a knowledge denied to their corporate counterparts by the IT department and the rigours of having to compete with each other...

Contrast this with the situation in the corporate and public sector ghettos where the worker bees huddle behind their firewalls drinking skinny latte and answering emails...

Because this is the other difference. In the "official" world the role of the IT department is to keep everything locked down in the interests of security...

If a sufficiently large section of the population gets its information and does its business in an informal and creative way, how does the corporate marketer (or technical communicator), ensconced behind his firewall communicate with them?

This seems to be a key fault-line in many areas of life at present. There is a discrepancy between the official world of security, audit, tick-box and prescription on the one hand and the behaviour patterns for learning, communication and doing business that people adopt when they are able to drop the bureaucracy and behave honestly, immediately and creatively."

His project will produce a workbook and workshops based on the case studies later in the year. Our report on applying Web 2.0 to technical communication is here.

Information Development

I've just finished reading JoAnn Hackos's book, "Information Development". It's very good - probably the first book that a technical author should buy. Indeed, we're making sure all our in-house authors have access to a copy of it.

At 624 pages, it covers a lot. However, I felt it could have done with covering in depth: (a) the behaviours and motivations of team members, and (b) real-life advice when you're faced with a organisations that are at Capability Maturity Model levels 0 (Oblivious), 1 (Ad hoc) and 2 (Rudimentary).

Whilst we'd all like to deal with stable, well organised organisations, it's a fact of life that there are many start-ups who are at levels 0-2.

There's mention of XML, but little of Web 2.0, which is in some ways understandable.

The importance of documentation in business

Ian Boyd Livingston, someone I know who specialises in helping organisations around the world that are facing recruitment difficulties, sent me an email yesterday:

"I've been reading Michael Gerber's "The E-Myth Revisited"...It's a great book! In it Gerber talks about the importance of documentation and, though you may be tired of hearing this, I immediately thought of you and Cherryleaf."

He then sent me another message:

"On the basis of "pay it forward" I have just ordered you a copy".

It arrived today.

I look forward to reading it and returning the favour.

Accurate estimating and reporting for technical publications projects

We've added "Estimating time budget for software documentation projects - An e-learning training course" to our Web site today.


It's an online training presentation that looks at methods for accurately estimating the development days and associated costs for software documentation projects. The material is based on research principles and experience of what works. It provides clear and practical advice.

It is for anyone who needs to estimate the time needed to complete a software documentation project.