You learn more from users in 5 minutes than you do from 2 weeks of project meetings
I recently had a project with a small group of users, maybe 35. I joined the project about a month before the scheduled release. I wasn’t sure what kind of help the app needed, or what format. A wiki? Screencasts? Online help? A short PDF?
I talked with the lead customer, and he hadn’t given much thought about help. I talked with the project manager, a quality assurance engineer, and a developer. The PM didn’t know what kind of help the app needed either. The QA engineer thought it needed a few pages of help; a developer said it needed maybe 150 pages. After floundering around for about a week, I realized I was shooting in the dark.
I asked the interaction designer for some names of users I could contact, and he supplied me a name. After talking on the phone with the user for 5 minutes, I knew that my entire previous direction was wrong. They didn’t need a robust wiki. “If you created a help system,” the user said, “I’m really not sure anyone would use it. We all know the process so well here. The only thing we may need help with is to find where something is in the interface.”
This lightened my load incredibly. The way our department often works, we create applications so customized to a specific business process that only users within that business department understand how the application will actually be used. Trying to penetrate this business process requires learning an entirely new culture and knowledge base. But often it isn’t necessary to document this business knowledge — it all depends.
When I started the project, I was fixed on creating documentation that explained not only the how, but the why and who and where and other context. Now I’m basically creating a slideshow of screenshots with some callouts indicating where things are in the interface. I figure it will save me about 2 months of work and will actually be looked at by the users — all because of a brief phone call with users. I realized that I can learn more from talking with users for 5 minutes than I can from 2 weeks of project meetings. Why is it that I don’t talk to users more frequently?
photo from Flickr
![From Overlooked to Center Stage [3]](http://idratherbewriting.com/wp-content/plugins/related-posts/static/thumbs/28.jpg)
Absolutely true that talking to the users will give you more information quicker than relying on anyone else’s opinion of who the user is. This is especially true when software is tailored to specific environments where the user will know morea about the process the software supports than you could possibly learn in a year.
Why don’t you talk to the users more frequently? I think that depends on whether your working environment allows you that sort of contact. I’ve known corporations that shelter the user frmo the developers (both software and information) who are trying to meet customer requirements. The fear of loss of intellectual property far overshadows the ability to provide what the customer needs. Sound familiar?
I hadn’t even considered loss of intellectual property. Interesting angle. I’m in a non-profit org that doesn’t have to worry too much about that.
I’ve watched tons of usability testing through a one-way mirror, and it’s the same kind of thing.
Are your users internal? That might be easier than chatting with external ones.
I think my company would have serious problems that kind of contact. Mainly because EVERYONE wants to talk to the customers. We’d drive them nuts, so we have to be careful about it.
Internal users are better than no users at all.
I think that if software developers err, it should be on the side of driving users nuts rather than building something that doesn’t work for them. Over-communicate rather than under-communicate.
You are so right! One thing that helped me at a previous job was watching the usability tests that the UX team ran. It helped me better understand what the customers already knew, what they assume, what language they use to describe the product, and more.
That kind of stuff helps you figure out what kind of voice to use in the help and what words people expect to see or search for. And if a customer actually opened the help, that was even better (but that rarely happened).
Great stuff!
Great post.
Listen to the users and give them what they need. End result: happy customer AND you’ve saved time & money in the process.
Nice one!
So true. I learned so much the night I sat in a pizza shop’s kitchen, watching my users use our product to place phone orders. It was very eye-opening.
Tom,
You are fortunate enough to have a talk with the user directly. Not many technical writers will get a chance like this.
Rob (in comment above) makes a good point that everyone wants to talk to the customer, and allowing this would drive them nuts.
However, I would argue that most customers (depending on industry) want to be consulted, as it engages them and makes them feel appreciated.
On a different note, in some companies there may be a “control” issue where different units – support, sales, product management, etc – want to be the go-between between the customers and the company. This is one reason why letting “us” (tech writers) get in touch with “them” (customers) is not so easy.
However (right, Tom?), there is nothing like an external company blog to let you get customer feedback and opinions.
Thanks Gil. Sure, a blog can be a great venue for gathering customer feedback. I know there are good reasons for not letting everyone contact the customer, and certainly if the customer feels overwhelmed or annoyed, avoid doing it. But usually there are plenty of customers to go around, and them more feedback you can gather, the better. I would be elated if Adobe contacted me to ask what I think of Photoshop (or something similar).
I’m not saying that we shouldn’t try to get access, of course, and I don’t disagree with a single thing you said. I’m just thinking about why a lot of tech communicators might have a hard time getting that kind of access.
My company occasionally sends surveys, but we can’t put 1000 questions on there, and each department has its own questions to ask.
Incidentally, I used to have a link at the bottom of each help topic for people to email me with any feedback about the help. It didn’t actually produce much, but might be worth a shot for some products.
Of course, you were in the happy situation where the users actually were willing to talk to you. Sometimes, in some work environments, developers see their knowledge as their ticket to staying at a company (in an abstract sort of way) and are very reluctant to part with it. Their value is their knowledge and experience and sometimes they view technical writers as attempting to capture in a document their value to a company, and it scares them. Odd situation, but I have encountered it often enough to ponder why it happens.