How to Report Tech Problems to Get Answers
The more we use computers and technology, the more questions we have and problems we need solved. But it's hard to get answers and solutions without asking the right questions and describing the problem at hand. We're specific when visiting the doctor or auto mechanic: we describe what's wrong and when it began. We may even imitate the noise our car makes for the mechanic.
But when faced with computer oddities and malfunctions we sometimes revert to unhelpful generalities such as "My email is broken" or "My printer stopped working" or "I get an error when I start Word". Problem reports such as these don't allow diagnosing a problem; at best, they elicit a response like "Tell me more". It saves time to collect as much information as possible before asking for help. As a bonus, gathering problem details and considering relevant factors can often allow solving problems oneself!
Just as a doctor or mechanic needs details, someone analyzing a computer problem must know the environment in which it occurred. So describe your computer (hardware/software/networking/application/etc.) to provide context. Mention your operating system (Windows 98/ME/XP, Mac OS, Linux, etc.), what version of what application failed (Internet Explorer 6.0, MS Word XP, etc.), what Internet connection is used (dial or cable/DSL), and any other details that may help. Don't omit details -- it's better to have too much information than to miss a crucial factor. Sometimes it's worth capturing screen images showing a problem; tools for doing this will be described in a future article.
Other important steps in describing symptoms and getting help are:
- Distinguish facts from guesses and interpretations.
- If an error message was issued, write it down, word-for-word. Then check it for accuracy. (Often searching Google for the error message text or a distinctive chunk - entered in quotation marks -- will yield information on a problem.)
- Note what you did just before the problem occurred and whether anything else odd happened since you last rebooted and before the problem at hand.
- Mention whether the problem happened before, and if so how you resolved it.
- List whatever (hardware, software, settings, network, anything) has changed recently.
- Explain if you attempted to solve the problem and what resulted. (Remember that rebooting often cures problems, though without explaining them.)
- Note where you've already looked for information (product manual or Help, company Web site or FAQ, etc.).
- Reread your query imagining you know nothing about the problem except what's in the query. Add what's missing that someone else needs to know in order to help.
- To help friends or service personnel respond to your question -- and to let the question be filed and found -- use a meaningful Subject line, not Help!, Urgent, or Question. Describe the context (e.g., Windows XP) and the problem (e.g., Windows Update never finds new patches).
To help your helper help you:
Be clear about your overall goal, don't focus on an intermediate step you think is necessary -- you may distract someone into addressing how you're trying to do something rather than what you actually want to do.
Ask for help in the right/best place. AARP's Computers and Technology Message board hosts many people with deep and diverse experience who are most generous with their time offering help and advice. And the Internet hosts thousands of mailing lists and newsgroups specializing in every imaginable topic. Searching for the best place to pose a question will get you better and more complete answers and avoid your seeming like a novice for posting out-of-place queries.
As you work with an individual or a group, collaborate -- don't try to overpower them. Be respectful, not belligerent; don't make them feel stupid even if you feel they are. They may have missed a detail, you may not have conveyed the whole story. If you're working with someone at a company help desk, don't try to "pull rank" based on age or experience or professional credentials. Mention past interactions with the company, emphasizing positive outcomes.
Finally, a longish document from Eric Raymond -- an influential leader of the "open source" (shared software development) movement -- provides useful tips, though it's a little too harsh in some places for my taste. But his comments on how to ask questions and where to seek help are interesting and helpful.
