Comments on: Documentation as a Tool for User Centered Design http://blog.lugiron.com/2009/04/documentation-as-a-tool-for-user-centered-design/ Social Media Analytics Done Right Fri, 23 Apr 2010 22:30:10 +0000 http://wordpress.org/ hourly 1 By: Paulm http://blog.lugiron.com/2009/04/documentation-as-a-tool-for-user-centered-design/comment-page-1/#comment-181 Paulm Tue, 12 May 2009 23:46:10 +0000 http://blog.lugiron.com/?p=110#comment-181 Documentation definitely needs to be part of the development process (not an after thought) to get the most value from its development. Often times we fix things in the product rather than relying on the documentation itself. When the user has a problem, they are already irritated. If we fix it in the product, we can avoid this irritation. I have several topics about embedded help and usability on my blog at <a href="http://www.useraid.com/blog" rel="nofollow">http://www.useraid.com/blog</a>. Documentation definitely needs to be part of the development process (not an after thought) to get the most value from its development. Often times we fix things in the product rather than relying on the documentation itself. When the user has a problem, they are already irritated. If we fix it in the product, we can avoid this irritation. I have several topics about embedded help and usability on my blog at http://www.useraid.com/blog.

]]> By: Paulm http://blog.lugiron.com/2009/04/documentation-as-a-tool-for-user-centered-design/comment-page-1/#comment-22 Paulm Tue, 12 May 2009 18:46:10 +0000 http://blog.lugiron.com/?p=110#comment-22 Documentation definitely needs to be part of the development process (not an after thought) to get the most value from its development. Often times we fix things in the product rather than relying on the documentation itself. When the user has a problem, they are already irritated. If we fix it in the product, we can avoid this irritation. I have several topics about embedded help and usability on my blog at <a href="http://www.useraid.com/blog" rel="nofollow">http://www.useraid.com/blog</a>. Documentation definitely needs to be part of the development process (not an after thought) to get the most value from its development. Often times we fix things in the product rather than relying on the documentation itself. When the user has a problem, they are already irritated. If we fix it in the product, we can avoid this irritation. I have several topics about embedded help and usability on my blog at http://www.useraid.com/blog.

]]> By: Documentation as a Tool for User Centere … Writer River http://blog.lugiron.com/2009/04/documentation-as-a-tool-for-user-centered-design/comment-page-1/#comment-20 Documentation as a Tool for User Centere … Writer River Mon, 11 May 2009 22:46:47 +0000 http://blog.lugiron.com/?p=110#comment-20 <p>[...] Documentation as a Tool for User Centered Design Louis Marascio | May 11, 2009 | permalink Tags: usability, user experience   [...]</p> [...] Documentation as a Tool for User Centered Design Louis Marascio | May 11, 2009 | permalink Tags: usability, user experience   [...]

]]> By: robbyslaughter http://blog.lugiron.com/2009/04/documentation-as-a-tool-for-user-centered-design/comment-page-1/#comment-10 robbyslaughter Thu, 30 Apr 2009 02:56:51 +0000 http://blog.lugiron.com/?p=110#comment-10 Most documentation is not proactive, but defensive. You often write user manuals because <em>everybody else</em> has a user manual, because customer support believes it will reduce their costs, because the sales team insists it will increase percieved value or because it makes your product seem more legitmate.<br><br>To counter this problem, some advocate writing documentation before developing the product. This sounds like an even more nightmarish version of the waterfall methodology, but is curiously discussed and supported by agile enthusiasts (see <a href="http://c2.com/cgi/wiki?WriteTheUserManualFirst" rel="nofollow">http://c2.com/cgi/wiki?WriteTheUserManualFirst</a>). In some respects, how you explain the product to others should inform how the system actually works. If it cannot be outlined effectively in written form, it follows that it will not be intuitive when willed into reality.<br><br>@robbyslaughter Most documentation is not proactive, but defensive. You often write user manuals because everybody else has a user manual, because customer support believes it will reduce their costs, because the sales team insists it will increase percieved value or because it makes your product seem more legitmate.

To counter this problem, some advocate writing documentation before developing the product. This sounds like an even more nightmarish version of the waterfall methodology, but is curiously discussed and supported by agile enthusiasts (see http://c2.com/cgi/wiki?WriteTheUserManualFirst). In some respects, how you explain the product to others should inform how the system actually works. If it cannot be outlined effectively in written form, it follows that it will not be intuitive when willed into reality.

@robbyslaughter

]]>