Let me be clear: I don't buy that argument and remain unconvinced. When given a URL to a website, I don't believe a user is going to first go to the user guide. My opinion is that the user will go to the URL first. The scenario that is being proposed seems to be cut and dry:
- User gets URL
- User enters URL in browser.
- URL doesn't work.
- User reads ""I/C are not supported" in the user guide.
- User thinks, "Oh, well at least it's in the user guide".
The other dimension that comes into play is that we were discussing a new user guide for a new product. The suggestion was made that we should include what isn't supported as an "exception to the rule." The suggestion to include this information in a memo, in an email, and/or in training was rejected. As I watched the flurry of emails fly, I tried to analyze what I was reading.
As a side note, I consider myself flawed. I have the curse / blessing (pick one) of the ability to see both sides of an issue.
- Is Anakin Skywalker (Darth Vader) not a hero? Consider, just for a moment, that he was just a kid that was screwed up because he was in love and when he sought acceptance from Obi-Wan Kenobi, he was put in his place.
- Fictional characters like "How I Met Your Mother"'s Barney Stinson famously considers "Johnny" to be the hero of "The Karate Kid", not Daniel LaRuso.
- On "The Big Bang Theory," Amy ruined "Raiders of the Lost Ark" when she told Sheldon that Indiana Jones had nothing to do with the Ark of the Covenant being recovered - the Nazis were going to find the Ark and open it anyways.
I think there are two issues.
The first is the idea of setting a standard / precedent for this product. The product is "new" & the documentation is "new" so upon its release, we are defining rules so, right now, there are no 'exceptions' to the rules - just rules for how the documentation for our new products
The second issue is finding a balance between two types of information that need to be communicated effectively: what the product / system does and what it does not do.
Personally, I don't see an issue with stating, in a training class / demo / video that "This product doesn't run on ____" and not having that tidbit in the user guide. The user guide is intended to tell the user what is supported and what they need to use it.
During the course of the discussion, Matthew, bassist extraordinaire for Lou's Classic Ride and my co-worker, summed up the issue we, as technical writers, face. With his permission, I give you these words:
Back when we bought software in boxes, say Microsoft Office, the packaging would tell you what the enclosed software would run on and might occasionally say something like "This will not run on a Mac". The manual or other documentation inside would tell you only about what it did run on and how it worked.
Today, we download our software and the provider tells us up front which version to download or whether the software is for specific platforms. The documentation discusses how that software works on the platforms it supports.
I'm sticking with the industry standard here, guys. Sorry.
<snip>
We are producing the technical documentation about what the system does and how it does it. That is our job and we commit to do so as clearly and completely as possible and make changes as quickly as we can when changes to the software happen or errors in our information are found.
It not the technical documentation's job to communicate information outside that realm. We do not document policies, procedures, or what platforms the software won't work on. We're sticking to that now and setting the long term expectation.
Ironically, when you go to the system in question, you select a value from a drop-down and click Next. On the page that displays, there is a note at the bottom that says "NOTE: I/C are not supported." The problem is that that page won't load if you are using an I/C so the user will never know why the page didn't load.
What makes the discussion even better is that there is no sense of "You must do your job the way I say you must." Instead, it's a discussion, an honest exchange of ideas. No one wants the user experience to be negative. Customer satisfaction is everyone's goal. Whether to state "I/C are not supported" in a user guide as a way to satisfy the user is where the fine line is being drawn. We say, "It won't satisfy the user" whereas others say, "It will satisfy the user."
More developments as they happen, but probably not today.
No comments:
Post a Comment