Hope it's ok to blog for this chapter without an initial posting...
The audience/user needs are so important and this chapter provides a good list of tips for analysis such as worker's motivations, level of computer use, knowledge of program's subject matter, learning preferences, and usage pattern to list some of them. I especially agreed with the idea of including those who have a personal stake in the outcome with the planning, implementing and revising of any new program. This approach changes the procedure writer from an overseer position to a collaborative position. I've found this approach definitely makes the users feel their ideas and suggestions are important and this provides an atmosphere of teamwork. I've been a usability testor for various new web page applications at work and when the administrators of a new program encourage my feedback, I feel open to express more than I normally would about the process. This also increased my motive to learn a new program. Barker wrote about the role that attitude plays in introducing a new program so when I write my usability testing document, I will remember to include the benefits for the users prior to testing. I also need to take into account users' prior knowledge, learning methods and experience in order to hit my target audience.
Subscribe to:
Post Comments (Atom)
7 comments:
I agree with Joan's comments. I have also found while "serving as a guinea pig" working with the creators of several online training modules, and having them really interested in my opinions and suggestions, went a long way in creating a superior tool. I believe my opinions and suggestions were valued because I am a resource for operational users of our billing software when they have questions about the system generated an unexpected outcome. I heard that echoed in this chapter about getting the right users' input. While some people can get very picky and wordsmith to death, there is a huge advantage to getting different opinions from various levels of users. And if you can make usability testers feel as though they have a real stake in the final product, all the better!
I agree with Joan and Mary, I too have been involved in projects for online training modules, it is nice that corporate includes the users from the many plants to get feedback from us when they are developing new software. Currently, the IS department is collaborting to create a new single source document management system for our use. Barker offers some good insight into the importance of looking at the opinions of the different users and user types. He suggests some good ideas for usability testing. I look forward to using this information for our usability project. Usability testing is on the top of my list for tools to learn while at MNSU.
I liked the part in this chapter about preparing for a user interview. When beginning work on documentation, you know you will need to conduct user interviews, but that section is really helpful. The interview plan s a really good idea that helps you get an idea of what the interview will cover, and keeps you well prepared for the interview. I agree that a poorly planned interview can be a waste of time.
I was somewhat surprised that analyzing the user can be a complex process that even delves into the psychology of the user. I would suspect that software programmers would consider this an important part of the overall process of creating a new program and its successful marketing. Even the best written programs could slip through the cracks if it didn't have documentation that the user could follow and learn from. Good marketing strategies can promote a product, but if good documentation isn't there to back it up, users would quickly feel something lacking and give up. That has happened to me before. I'd get all hyped up about a new software, purchase it, and then quickly dump the thing because I couldn't learn it or the documentation was so poorly written, I could not get anything out of it. So, based on that I see the importance of sound user analysis prior to creating software documentation in order to keep the user interested in learning the product after it has been purchased.
I couldn’t get a feel for how long this analysis takes. How much time would software developers invest in analysis before creating the documentation? I get the feeling that many times, developers are under the gun and anxious to get their product on the shelves because of some deadline. Would user analysis be one area where corners are cut? How many developers focus on the short run rather than the long run and omit some important user analysis. From reading the chapter, it seems that a lot of forethought and preparation must go into getting decent results.
This chapter helped me understand how to analyze your audience better and it will be helpful in my documentation project because I'm trying to decide how much information to include. The job description for the users of my documentation requires that they have basic computer skills so I will revise my instructions with this in mind. When conducting my usability tests, I will keep in mind "tacit knowledge" because both workers have been employees for about 2-3 years and will have an attitude toward our computer system. Unfortunately, we don't have any new enough employees to try my documentation on at this point because that is what I am writing for.
The section on connecting user analysis with documentation features seems appropriate for this chapter and I will keep these ideas in mind while working on projects and in a future job. It is important to make documents that are going to be helpful for users in different aspects of their jobs and activities. By have different ways to learn tasks--such as illustrations, texts, tutorials, graphs, charts, glossaries, etc--more users can use the documentation and in different ways to accomplish workplace tasks. This all starts with user analysis done by the authors.
I agree with what everybody is saying here. I think it could possibly be most important thing to ensure that you have properly analyzed your users. Afterall, if you have misidentified your intended you user then all of your work is for nothing. The user will stop immediately when they no longer feel engaged with what they are being taught. I think this chapter transcends in to many different aspects of manual or instructional writing. Whether it's how to build a house or how to use software, it is always important to know who will be using it.
Yes, Joan, those are all great comments. I remember professor Nord saying that writing isn't individual but collaborative. This nails that on the head. Sharing ideas back and forth is what makes a product great. If a single person did all the work, then they might have missed something that wouldn't make it as efficient because somebdoy thought of something else that might be better or useful. Great job summarizing. Also, I have used products where the creator didn't likely test on it and I always found it to be very frustrating. That's where the complaint department comes in thought, I guess!
Post a Comment