http://blog.lugiron.com/2009/05/write-answers-not-documentation/ Helping Companies Grow Happy Users Sat, 20 Feb 2010 20:07:25 +0000 http://wordpress.org/ hourly 1 http://blog.lugiron.com/2009/05/write-answers-not-documentation/comment-page-1/#comment-118 Twitter Trackbacks for Write Answers, Not Documentation | The LugIron Software Blog [lugiron.com] on Topsy.com Mon, 31 Aug 2009 01:02:03 +0000 http://blog.lugiron.com/?p=189#comment-118 <p>[...] Write Answers, Not Documentation | The LugIron Software Blog blog.lugiron.com/2009/05/write-answers-not-documentation – view page – cached In a recent discussion over on the Business of Software Forum a poster asked for help after noticing that a recent improvement in documentation has resulted — From the page [...]</p> [...] Write Answers, Not Documentation | The LugIron Software Blog blog.lugiron.com/2009/05/write-answers-not-documentation – view page – cached In a recent discussion over on the Business of Software Forum a poster asked for help after noticing that a recent improvement in documentation has resulted — From the page [...]

]]> http://blog.lugiron.com/2009/05/write-answers-not-documentation/comment-page-1/#comment-134 Paul Sholar Mon, 01 Jun 2009 02:41:06 +0000 http://blog.lugiron.com/?p=189#comment-134 <ol> <li>Would like to see more factual background about the case mentioned. Is this a new product? Is the product addressing a new market? In what forms and in what volume did the software company previously provide its product documentation? <br><br>2. I would agree with the notion that more documentation is almost always better and with the notion that provided lots of documentation is a sign to customers of a higher quality total product offering. Some products are very "large" and have many features. Not to provide documentation (if not in the product's first release, then as soon thereafter as possible) that addresses all the product's features is a mistake.<br><br>3. Support staff must already be familiar with all the documentation's contents. As a first response to a customer's question, they can in effect read to the customer what's found in the documentation. I have also seen shops where for some documentation there is an alternative version (exactly the same content) produced and uniquely formatted for use by Customer Support.<br><br>4. There must be in place a definite mechanism for Customer Support team to provide feedback to the documentation team. And the documentation must be designed in a way such that its success at meeting its goals can be measured.</li> </ol>

Would like to see more factual background about the case mentioned. Is this a new product? Is the product addressing a new market? In what forms and in what volume did the software company previously provide its product documentation?

2. I would agree with the notion that more documentation is almost always better and with the notion that provided lots of documentation is a sign to customers of a higher quality total product offering. Some products are very “large” and have many features. Not to provide documentation (if not in the product's first release, then as soon thereafter as possible) that addresses all the product's features is a mistake.

3. Support staff must already be familiar with all the documentation's contents. As a first response to a customer's question, they can in effect read to the customer what's found in the documentation. I have also seen shops where for some documentation there is an alternative version (exactly the same content) produced and uniquely formatted for use by Customer Support.

4. There must be in place a definite mechanism for Customer Support team to provide feedback to the documentation team. And the documentation must be designed in a way such that its success at meeting its goals can be measured.

]]> http://blog.lugiron.com/2009/05/write-answers-not-documentation/comment-page-1/#comment-51 Paul Sholar Sun, 31 May 2009 21:41:06 +0000 http://blog.lugiron.com/?p=189#comment-51 <ol> <li>Would like to see more factual background about the case mentioned. Is this a new product? Is the product addressing a new market? In what forms and in what volume did the software company previously provide its product documentation? <br><br>2. I would agree with the notion that more documentation is almost always better and with the notion that provided lots of documentation is a sign to customers of a higher quality total product offering. Some products are very "large" and have many features. Not to provide documentation (if not in the product's first release, then as soon thereafter as possible) that addresses all the product's features is a mistake.<br><br>3. Support staff must already be familiar with all the documentation's contents. As a first response to a customer's question, they can in effect read to the customer what's found in the documentation. I have also seen shops where for some documentation there is an alternative version (exactly the same content) produced and uniquely formatted for use by Customer Support.<br><br>4. There must be in place a definite mechanism for Customer Support team to provide feedback to the documentation team. And the documentation must be designed in a way such that its success at meeting its goals can be measured.</li> </ol>

Would like to see more factual background about the case mentioned. Is this a new product? Is the product addressing a new market? In what forms and in what volume did the software company previously provide its product documentation?

2. I would agree with the notion that more documentation is almost always better and with the notion that provided lots of documentation is a sign to customers of a higher quality total product offering. Some products are very “large” and have many features. Not to provide documentation (if not in the product's first release, then as soon thereafter as possible) that addresses all the product's features is a mistake.

3. Support staff must already be familiar with all the documentation's contents. As a first response to a customer's question, they can in effect read to the customer what's found in the documentation. I have also seen shops where for some documentation there is an alternative version (exactly the same content) produced and uniquely formatted for use by Customer Support.

4. There must be in place a definite mechanism for Customer Support team to provide feedback to the documentation team. And the documentation must be designed in a way such that its success at meeting its goals can be measured.

]]> http://blog.lugiron.com/2009/05/write-answers-not-documentation/comment-page-1/#comment-50 Paving the Road to User Utopia | Simplifying Complexity Sun, 31 May 2009 17:51:40 +0000 http://blog.lugiron.com/?p=189#comment-50 <p>[...] of technical content, we strive to help reduce the number of technical support calls. Yet, a recent post on the blog of LugIron Software refers to a quote stating that documentation can also increase the number of service [...]</p> [...] of technical content, we strive to help reduce the number of technical support calls. Yet, a recent post on the blog of LugIron Software refers to a quote stating that documentation can also increase the number of service [...]

]]> http://blog.lugiron.com/2009/05/write-answers-not-documentation/comment-page-1/#comment-49   Weekly links roundup by Communications from DMN Fri, 29 May 2009 09:27:36 +0000 http://blog.lugiron.com/?p=189#comment-49 <p>[...] Don’t write documentation. Write answers [...]</p> [...] Don’t write documentation. Write answers [...]

]]> http://blog.lugiron.com/2009/05/write-answers-not-documentation/comment-page-1/#comment-47 Links for today: WikiPatterns, TecDoc Hints, Mootools Forms | MarkSimon.de Wed, 27 May 2009 07:10:28 +0000 http://blog.lugiron.com/?p=189#comment-47 <p>[...] Hints for writing technical documentations: Write Anwers, Not Documentation [Link] [...]</p> [...] Hints for writing technical documentations: Write Anwers, Not Documentation [Link] [...]

]]> http://blog.lugiron.com/2009/05/write-answers-not-documentation/comment-page-1/#comment-43 Twitted by rachelhpeters Fri, 22 May 2009 19:28:00 +0000 http://blog.lugiron.com/?p=189#comment-43 <p>[...] This post was Twitted by rachelhpeters - Real-url.org [...]</p> [...] This post was Twitted by rachelhpeters – Real-url.org [...]

]]> http://blog.lugiron.com/2009/05/write-answers-not-documentation/comment-page-1/#comment-42 marascio Fri, 22 May 2009 14:02:03 +0000 http://blog.lugiron.com/?p=189#comment-42 <p>Very interesting ideas. I particularly like the analogies :). Thanks for stopping by.</p> Very interesting ideas. I particularly like the analogies . Thanks for stopping by.

]]> http://blog.lugiron.com/2009/05/write-answers-not-documentation/comment-page-1/#comment-41 marascio Fri, 22 May 2009 13:55:00 +0000 http://blog.lugiron.com/?p=189#comment-41 <p>Especially if you consider that not only do they have a different model for change they all have very different and isolated ways to communicate with users and gather feedback.</p> Especially if you consider that not only do they have a different model for change they all have very different and isolated ways to communicate with users and gather feedback.

]]> http://blog.lugiron.com/2009/05/write-answers-not-documentation/comment-page-1/#comment-37 Write Answers, Not Documentation Writer River Fri, 22 May 2009 12:36:59 +0000 http://blog.lugiron.com/?p=189#comment-37 <p>[...] Write Answers, Not Documentation Louis Marascio | May 22, 2009 | permalink Tags: community, help, search, wiki   [...]</p> [...] Write Answers, Not Documentation Louis Marascio | May 22, 2009 | permalink Tags: community, help, search, wiki   [...]

]]>