Yesterday, I got myself a new phone. Last time I had bought one, it was April 2004 - a time when cellphones here did not have built-in FM radios, internet support, multimedia messaging, and all such exciting features that are so much passé today. Consequently, it was a very celliterate me that held the phone gingerly and regarded its QWERTY keyboard with interest. And thence started my frustration. I could not figure out how to do any of those exciting features that all phones have nowadays (let's not blame the UI now. All UIs seem non-intuitive to first-time users).
So, I reached for the user guide. A glance at the ToC, and I could not find answers to any of my three questions.
To magnify the picture, click on the picture
"So what", I told myself. "Just a 37 page booklet. I'll flip through it and will surely find something."
Five minutes later, I threw the booklet away, powered my laptop on, asked Google, and found answers to all my questions:
- How do I transfer a photo taken on the phone to my laptop?
- Where do I get the Missed Calls list?
- How do I disable the keypad beeps?
I see several things wrong with this user guide but the one thing that stands out prominently is - this guide is describing the features of the phone; it's not describing the tasks I, the user, do.
5 comments:
Perfect example for why we should move to DITA and implement topic-based writing procedures.
Eaxctly!
It's absolutely critical that, as a community, we start analyzing our products in terms of what the customer does with them and write to those tasks. If not, then our product message becomes the purview of others and there message may not be as good as we want it to be, at best. At worse, the experience you had can translate to not purchasing another product from the company that so failed my needs.
Someone was paid a lot of money to make that manual useless.
Have you looked at the minimalist technical writing on Apple products? Sometimes I wonder if they assume people know more than they really do.
@Julio
I agree. We absolutely must find out how our product is used, and then document the How.
@WJS
My first Apple product was an iPod Classis and I confess I never had to look at the guide but then, I had someone showing me the How-s. All my friends (without exception) complain about Apple's non-existent documentation. Over the past few months, I've noticed a trend: retail products sold to a large consumer base almost always have no documentation (or bad documentation). The example in my blog post is from a Nokia manual. The thing with such products is - consumers rarely stop buying them because the docs suck (I'll definitely buy a Nokia again. Because I think their product is first class). Documentation makes a difference only for enterprise-level buying decisions, I think.
Post a Comment