#31780
Are We Giving Readers What They Want, in the Way They Want and Need It?
With all the talk about Web 2.0 and the attendant technologies, are readers actually being better served by documentation now than they were in the past?
DMN Communications (2008). Articles>Documentation>Technical Writing>User Centered Design
#19743
Creating User-Friendly Documentation
We often hear that users do not read documents. To lure readers into reading our documents, we must make documents user-friendly.
Bhatia, Neeraj. Indus (2002). Articles>Documentation>User Centered Design>Technical Writing
#31748
The gaps in your documentation aren’t there because you haven’t consider a particular level of user; the gaps in your documentation are there because you haven’t considered how one level of user becomes another. How DO you get from Beginner to Expert?
McLean, Gordon. One Man Writes (2008). Articles>Documentation>User Centered Design>Technical Writing
#28311
Writers can increase the value of their documentation by visiting customers where the customers work and seeing what they are doing. It's easier to write targeted topics when you know what readers need. Ann Beebe, User Education manager for Visual Studio, gave me two examples of writers who went into the field and discovered how the customer's experience can be very different from the experience in the development team.
Miller, Harry. Microsoft (2006). Articles>Writing>Technical Writing>User Centered Design
#20552
IBM User-Centered Design for the Documentation Designer 
The user-centered design of documentation is an aspect of product design that has often been under-emphasized. Difficulties inherent in documentation design include obtaining user, feedback to high-level design objectives; extracting user. feedback specific to a product’s documentation. rather than to the product as a whole; and managing the various resource constraints inherent in product development. IBM User-Centered Design offers a solution to these difficulties by employing a set of user feedback methodologies from which the documentation designer, a member of a multidisciplinary design team, extracts pertinent data to set design objectives and follow through to low-level designs.
Righi, Carol and Lynn VanDyke. STC Proceedings (1996). Articles>User Centered Design>Documentation>Technical Writing
#30764
Low Bandwidth and the Highs of Web Design
The emergence of Internet was, and still is a fascinating thing to happen in technology firmament. The ease and the comforts of connecting to people, defying geographical boundaries, and getting a global audience for businesses were unparalleled -- first of its kind ever. So wonderful a thing has, unfortunately, got its share of woes -- the connection speed. The bandwidth of Internet connectivity was considerable at the time when it was entirely new to the world. The newness of the medium did not let it know to the excited lots of users and beneficiaries. Gradually, when people wished for more speed, they earnestly expected that things will turn favorable in the times ahead. Strategy is not something entirely applicable to chart out the direction of a corporation. Yeah, Your web design has to be strategized as well if you wish to serve your target audience in business friendly manner.
Azam, Rahbre. Amateur Writerz (2008). Articles>Web Design>Technical Writing>User Centered Design
#28229
Tech Writing 2.0: Special Report on New Trends in User Documentation
This report outlines the developments in what many are calling "Web 2.0" and the impact that these developments may have on technical and user documentation. We've called these trends "Tech Writing 2.0". Tech Writing 2.0 promises a new means of communication that business can use to promote and support their products and services. This means that the nature of technical communication will change.
Pratt, Ellis. Cherryleaf (2006). Articles>Writing>Technical Writing>User Centered Design
#23698
Technical Writing in Everyday Life: One User's Experience
The experience of setting up a new home theater system also sharply reminded me of what it is like to look at something as a new user: staring at a bunch of knobs and holes for the first time, holding a tassel of wire in one hand and a manual in the other, and really just wanting the darn piece of ?%^%! to do what it's supposed to do.
Vedrody, Sarah. MetroVoice (2002). Articles>Documentation>User Centered Design>Technical Writing
#32590
Use Cases for User Assistance Writers
It’s hard to find anyone who disparages use cases, but those who use them are still a minority. In a previous life as a UX designer, I used use cases and developed a great respect for them. But it wasn’t until recently that I began using them to design user assistance. Why did it take me so long to get back to these reliable work horses of user-centered design?
Hughes, Michael A. UXmatters (2008). Articles>User Centered Design>Writing>Technical Writing
#32824
Before you release a product, have some people use it. From these "test users" get solutions to problems, tips and knowledge that would help your real-life Users. Put that information in your User Documentation, and on your product support website.
Great Technical Writing (2008). Articles>Documentation>Technical Writing>User Centered Design
#34105
The parallels between the theories of technical communications and those of web design are very similar, the key aim is to keep the audience in mind at all times. The way you structure and present the information is also important, as is a sense of usability of the content itself.
McLean, Gordon. One Man Writes (2009). Articles>Web Design>Technical Writing>User Centered Design
#34328
If we really do believe in the importance of the audience, the reader, the user, then how have we changed our practice to reflect the changing characteristics, competencies and even literacies of our readers? Have our readers changed over the past few years? The evidence points to the answer being a resounding yes!
Self, Tony. HyperWrite (2007). Articles>Writing>Technical Writing>User Centered Design
#34378
User Paradox with Not Reading User Manuals
Users would save time by reading the manual, but instead they try to figure the application out themselves and then get lost/frustrated as they end up spending even more time getting up to speed with the application.
Johnson, Tom H. I'd Rather Be Writing (2007). Articles>Documentation>User Centered Design>Technical Writing
#34517
Growing Happy Users -- One Customer at a Time
Technical writing is a profession in transition. The way companies think of, use, and manage the people who help users make sense of and use products is absolutely changing. A lot of companies have started to use the term “information developer” to describe their technical writing positions. I don’t really care what label the profession chooses for itself, but I do know this: if technical writers don’t transition more than their job title then they will be missing out on a huge opportunity to move from the “gotta do it” category into the “can’t live without it” one.
Stern, Paula. LugIron Software Blog (2009). Articles>User Centered Design>User Experience>Technical Writing
#34775
Realistic But Hypothetical Examples
One of the reasons that technical communicators ought to know the business processes of their users (or at least the reasons they’re using the product) is to generate effective examples in the documentation.
Minson, Benjamin. Gryphon Mountain (2009). Articles>Writing>Technical Writing>User Centered Design
