Comments on: The Joy of Product Manuals http://effectivus.com/2009/03/the-joy-of-product-manuals/?utm_source=rss&utm_medium=rss&utm_campaign=rss Technology product development, management & marketing Wed, 28 Jul 2010 07:05:13 +0000 hourly 1 By: Chris http://effectivus.com/2009/03/the-joy-of-product-manuals/comment-page-1/#comment-43 Chris Mon, 06 Apr 2009 09:29:32 +0000 http://effectivus.com/?p=424#comment-43 Thanks for the comment David. It is really hard to get this right, especially for smaller technology companies who don't feel they can afford to employ lots of writers. Face it, they don't even think they can afford QA, but that is another story! Do people read manuals, or use the help? I think they do, but I suspect that we do not understand how, when and why they use them, just like we often don't really understand those issues around the product in the first place. Me, I'm certainly not a, "let's start at the very beginning", but do expect to be able to find the answer when I hit problems. Just yet another of the very many things that are hard to get right in NPD. Thanks for the comment David. It is really hard to get this right, especially for smaller technology companies who don’t feel they can afford to employ lots of writers. Face it, they don’t even think they can afford QA, but that is another story!
Do people read manuals, or use the help? I think they do, but I suspect that we do not understand how, when and why they use them, just like we often don’t really understand those issues around the product in the first place.
Me, I’m certainly not a, “let’s start at the very beginning”, but do expect to be able to find the answer when I hit problems.
Just yet another of the very many things that are hard to get right in NPD.

]]> By: Product Manuals « Ramblings on Product Development http://effectivus.com/2009/03/the-joy-of-product-manuals/comment-page-1/#comment-31 Product Manuals « Ramblings on Product Development Fri, 03 Apr 2009 23:48:26 +0000 http://effectivus.com/?p=424#comment-31 [...] 3, 2009 by EC Just read this post on product manuals: <http://effectivus.com/2009/03/the-joy-of-product-manuals/> - thanks to the Productologist for the link: [...] [...] 3, 2009 by EC Just read this post on product manuals: <http://effectivus.com/2009/03/the-joy-of-product-manuals/> – thanks to the Productologist for the link: [...]

]]> By: David Locke http://effectivus.com/2009/03/the-joy-of-product-manuals/comment-page-1/#comment-30 David Locke Fri, 03 Apr 2009 20:28:22 +0000 http://effectivus.com/?p=424#comment-30 Simple, direct instructions are hard to achieve. If the interface doesn't have these characteristics, then its going to be difficult to make the manual match those expectations. Even a simple form has a navigation path to the form, and that path may not be simple. Microsoft uses a 1:5 ration of writers to programmers. Of course, they are rich, and manuals are just market barriers anyway--nobody reads the manual, ask technical support. Their writers write document specs, not a manual. Then, those specs go to an external contractor, so the real ration is more like 2:5. Trainers write based on the manual and their own more task focused knowledge. By the time the marketers write, the sales trainers write, the trainers write, and the manual writers write, the ratio is probably more like 1:1. Writing starts before you code. That writing won't have much to do with the actual code. If you wait until you have code to hire a writer, you have waited too long. If you don't know your market, aka your writer's audience, don't hire a writer. If the instructions are not simple and clear, fix your interface, particularly the navigation path to the page or form. Why do you need instructions in the first place? If that state diagram sucks, fix the code. It's not the diagram's fault, or the writer's fault, or the artists fault. Fault the code. Fault the plan. Look in the mirror. In your defense, I will say that some manual writers are fiction writers in diguise who could never write Press OK, and mean it! I will also say that manual writers are trained by their professors that they know nothing, and that they must ask about everything under the sun, rather than experiment and test. Even if your writer can experiment and test, that takes time. When it's gotta be next month, you might was well sit in their cube, because they don't have time to experiment and test. Hire them early enough to get their estimate and dependencies in your estimate and schedule for the next release, as in way back at the beginning. And, no, they can't finish the day the code is finished. No, don't let a programmer write it. Maybe you should write it, ah, but you have other things to do. Oh, well. Simple, direct instructions are hard to achieve. If the interface doesn’t have these characteristics, then its going to be difficult to make the manual match those expectations. Even a simple form has a navigation path to the form, and that path may not be simple.

Microsoft uses a 1:5 ration of writers to programmers. Of course, they are rich, and manuals are just market barriers anyway–nobody reads the manual, ask technical support. Their writers write document specs, not a manual. Then, those specs go to an external contractor, so the real ration is more like 2:5. Trainers write based on the manual and their own more task focused knowledge. By the time the marketers write, the sales trainers write, the trainers write, and the manual writers write, the ratio is probably more like 1:1.

Writing starts before you code. That writing won’t have much to do with the actual code.

If you wait until you have code to hire a writer, you have waited too long. If you don’t know your market, aka your writer’s audience, don’t hire a writer. If the instructions are not simple and clear, fix your interface, particularly the navigation path to the page or form. Why do you need instructions in the first place? If that state diagram sucks, fix the code. It’s not the diagram’s fault, or the writer’s fault, or the artists fault. Fault the code. Fault the plan. Look in the mirror.

In your defense, I will say that some manual writers are fiction writers in diguise who could never write Press OK, and mean it! I will also say that manual writers are trained by their professors that they know nothing, and that they must ask about everything under the sun, rather than experiment and test. Even if your writer can experiment and test, that takes time. When it’s gotta be next month, you might was well sit in their cube, because they don’t have time to experiment and test.

Hire them early enough to get their estimate and dependencies in your estimate and schedule for the next release, as in way back at the beginning. And, no, they can’t finish the day the code is finished.

No, don’t let a programmer write it. Maybe you should write it, ah, but you have other things to do. Oh, well.

]]>