I’m not a fan of documenting third-party software, but that software, as well as operating systems and settings, have a significant effect on user experience for your product. Especially if your product may be used by anyone using any operating system and any combination of settings, it may be impossible to document everything. If you’ve tried to document printer settings, you know what I’m talking about.
It’s nice when you have a user group working in a somewhat controlled environment, such as a corporate desktop configuration. You can count on a certain limit to the variation of user circumstances, and you don’t have to spend as much time chasing down the answers to a bunch of “ifs.”
It unfortunately complicates the designing, developing, and testing process when people work outside the users’ environment. As an example, our standard desktop configuration is Windows XP with Office 2007 and IE7. Yet many of our designers prefer designing internal Web apps on Macs with Firefox. Some of the developers like Firefox, too, and develop against that browser. Same for some of the testers. Granted, bugs logged against Firefox have low priority in this circumstance, but the amount of testing done in Firefox probably isn’t proportional to the amount of usage in Firefox.
(I was surprised, then, when a designer was showing me some prototypes, got frustrated, and then said, “No wonder it’s not working—I’m using Firefox.”)
This isn’t a discussion of which browser is king or what OS runs the best; it’s about replicating the users’ experience. I would imagine that Mac applications aren’t developed and tested on Windows machines. It doesn’t make sense to work the other way around, either. I think undue trouble is caused by not applying the users’ environments to the software during design, development, and testing.
In a way, I see myself (and the support team) as the user’s last hope for sanity: If designers, developers, and testers don’t focus on imitating users’ work environments, then I can save some difficulty by documenting the software the way the users will see it in their environments. Support should also understand users’ setup and know how the software relates to it, especially in controlled environments. When the support team and I both understand the users at this level, I think it helps us hold on to some sanity on our side.
Related entries (auto-generated):
Fight User Frustration: Give Users What They Expect
Writer-Dictated vs. User-Dictated Experience
Your Users Don’t Do What You Expect
Five Skills for Managing Documentation Projects in an Agile Environment
Suggestions for Survival in an Agile Environment as a Technical Communicator
Journals by Email











No comments so far. Keep the conversation going.
Set Me Straight. Leave a Comment.