Tek-Tips is the largest IT community on the Internet today!
Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!
-
Congratulations TouchToneTommy on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!
How to explain technical problems to users? 4
- Thread starter javedi
- Start date
I've found analogies work best!
The user's desk is like the memory in the computer. The hard drive is like the filing cabinet. You do not typically work directly from a filing cabinet, you have to pull the folder out and put it on the desk before it starts working.
etc, etc
Just find something they relate to, and put it in terms of what they know
The user's desk is like the memory in the computer. The hard drive is like the filing cabinet. You do not typically work directly from a filing cabinet, you have to pull the folder out and put it on the desk before it starts working.
etc, etc
Just find something they relate to, and put it in terms of what they know
Buy some good books, I suggest PCs for dummies by Dan Gookin. You will find plenty of stuff. I hope you do not mind that your users will get smarter ![[tongue]](/data/assets/smilies/tongue.gif "[tongue] [tongue]")
if they borrow the book. Checkout
Steven
if they borrow the book. Checkout Steven
straybullet
IS-IT--Management
Prothios - perfect! Relate it to something they're familiar with.
Let them hate - so long as they fear... Lucius Accius
Let them hate - so long as they fear... Lucius Accius
EdwardMartinIII
Technical User
Has any one here had problems with explaining technical problems to simple users, how is this achieved?"
Why are you explaining technical problems to simple users?
My job is explaining complicated things to people who otherwise don't know it, and one of the first things I try to do is to figure out what they need to know and why.
![[monkey]](/data/assets/smilies/monkey.gif "[monkey] [monkey]")
Edward
"Cut a hole in the door. Hang a flap. Criminy, why didn't I think of this earlier?!" -- inventor of the cat door
Why are you explaining technical problems to simple users?
My job is explaining complicated things to people who otherwise don't know it, and one of the first things I try to do is to figure out what they need to know and why.
Edward "Cut a hole in the door. Hang a flap. Criminy, why didn't I think of this earlier?!" -- inventor of the cat door
EdwardMartinIII
Technical User
Watch an episode of Numbers and pay attention to their laughable "math analogies" for examples."
Oh my, I wish such things were only limited to that show. Sometimes I think I prefer Tom Baker's approach in Doctor Who:
Some companion: Why is it doing that, Doctor?
Doctor: I'll tell you later.
(and he never says a word about it later, and they never ask)
Edward
"Cut a hole in the door. Hang a flap. Criminy, why didn't I think of this earlier?!" -- inventor of the cat door
Oh my, I wish such things were only limited to that show. Sometimes I think I prefer Tom Baker's approach in Doctor Who:
Some companion: Why is it doing that, Doctor?
Doctor: I'll tell you later.
(and he never says a word about it later, and they never ask)
Edward "Cut a hole in the door. Hang a flap. Criminy, why didn't I think of this earlier?!" -- inventor of the cat door
- Thread starter
- #10
Some very creative idea's and thoughts. Thanks for taking the time out for the suggestions. I too believe users do not need to know, but i have been asked to inform the users by order of management. The user's feel better knowing what should not concern them.
/Javedi
Thanks for taking the time out for the suggestions. I too believe users do not need to know, but i have been asked to inform the users by order of management. The user's feel better knowing what should not concern them./Javedi
-
2
- #11
lionelhill
Technical User
Just a few comments as a genuine "user":
(1) Don't assume users are plain stupid. We often aren't. But also don't assume we know all the acronyms and technical terms.
(2) We may, however, be very scared of letting you know we don't know the latest acronyms. If we don't understand something, we won't ask straight away, because we don't want to look stupid. We'll often wait and see if it comes clear. Frequently it doesn't, and then we find we can't ask because we've left it too late...
(3) It may help if you try to establish what sort of level of knowledge we do have. For example, if you're explaining something that involves entering data into a table, how we expect it to work will be greatly influenced by whether we're deeply into Word tables, or a keen spreadsheet user.
(4) If you demonstrate something, do it reasonably slowly so we can follow. IT experts who lean over your shoulder, tap frenetically at the keyboard for 15 seconds, lean back and declare "There you are!" are missing the point: there we aren't.
(5) If you honestly don't think we need to know something, explain why, without patronising. If we still want to know, treat it as curiosity. Anyone who enjoys their subject should enjoy satisfying others' curiosity about it.
(6) And if you do think we need to know something, be a little tactful about how you introduce it. A crude example from 15 years ago that I still remember with shudders: as we're nudging a piece of drawing exactly, carefully sideways using the cursor keys, it really doesn't help if the IT expert leans over a shoulder, grabs the mouse, and throws our drawing six cm across the page with the words "You could use the mouse, you know!"
And a final note: quite seriously, if you find that your users want to know something, and your manager wants you to explain it, but you can't see the point, then maybe you should be thinking about whether a sideways move into a different role would be appropriate, should the chance arise.
(1) Don't assume users are plain stupid. We often aren't. But also don't assume we know all the acronyms and technical terms.
(2) We may, however, be very scared of letting you know we don't know the latest acronyms. If we don't understand something, we won't ask straight away, because we don't want to look stupid. We'll often wait and see if it comes clear. Frequently it doesn't, and then we find we can't ask because we've left it too late...
(3) It may help if you try to establish what sort of level of knowledge we do have. For example, if you're explaining something that involves entering data into a table, how we expect it to work will be greatly influenced by whether we're deeply into Word tables, or a keen spreadsheet user.
(4) If you demonstrate something, do it reasonably slowly so we can follow. IT experts who lean over your shoulder, tap frenetically at the keyboard for 15 seconds, lean back and declare "There you are!" are missing the point: there we aren't.
(5) If you honestly don't think we need to know something, explain why, without patronising. If we still want to know, treat it as curiosity. Anyone who enjoys their subject should enjoy satisfying others' curiosity about it.
(6) And if you do think we need to know something, be a little tactful about how you introduce it. A crude example from 15 years ago that I still remember with shudders: as we're nudging a piece of drawing exactly, carefully sideways using the cursor keys, it really doesn't help if the IT expert leans over a shoulder, grabs the mouse, and throws our drawing six cm across the page with the words "You could use the mouse, you know!"
And a final note: quite seriously, if you find that your users want to know something, and your manager wants you to explain it, but you can't see the point, then maybe you should be thinking about whether a sideways move into a different role would be appropriate, should the chance arise.
-
1
- #12
I always found "Pixies and Gremlins" to be a good answer to "Why did this happen?" especially if it is truly something inexplicable that happened. Some things you can't know why they happened if you weren't there watching it at the time. At the right time a little humor can go a long way. I've usually followed this up after they laugh, with "I'm not sure exactly what happened but this is what we can do to fix it."
Of course, seriously, if a user needs an explanation (and an expanation can help you from continuing to support the same issue over and over), then to me the key is not to treat the user as if he or she is a moron (even if you think so) because no matter what you say if that comes across in your tone, you will lose the respect of that person and probably a good number of other people that person will tell about you. That doesn't mean you have to explain in highly technical terms either, analogies that relate to things they would understand based on their professional specialties work just fine. Don't get too cutsey with the analogies or use ones that are obviously insulting ("It's like the rubber ducky in the bathtub.") Try to keep analogies to the professional level.(Yes I know "pixies and gremlins" is a bit cutesy, but it is only to break the tension with a laugh, then go on to the more serious explanation. There's a difference that users can alawys tell between you saying something funny or saying something insulting to their intelligence.)
Or a simple listing of the steps to do something (like find their files),maybe even a handout for common problems that they can refer to in a simliar situation. An explanation as to why it is important to you in solving their problem if they report the actual error message using a screen shot to show it to you rather than just saying, "I got an error, fix it."
Jargon is another thing to avoid. Most users have no idea what alot of the acronyms in the IT world stand for, avoid using them. For instance, suppose you are explaning a bug inthe system that the person reported. You don't need to describe the details of the code. It is usually enough to say, "There was a problem with the search procedure and it was pulling the wrong results. Thanks to your report, we now see the problem and have fixed the code."
In the end it all boils down to talking to people with respect.
"NOTHING is more important in a database than integrity." ESquared
Of course, seriously, if a user needs an explanation (and an expanation can help you from continuing to support the same issue over and over), then to me the key is not to treat the user as if he or she is a moron (even if you think so) because no matter what you say if that comes across in your tone, you will lose the respect of that person and probably a good number of other people that person will tell about you. That doesn't mean you have to explain in highly technical terms either, analogies that relate to things they would understand based on their professional specialties work just fine. Don't get too cutsey with the analogies or use ones that are obviously insulting ("It's like the rubber ducky in the bathtub.") Try to keep analogies to the professional level.(Yes I know "pixies and gremlins" is a bit cutesy, but it is only to break the tension with a laugh, then go on to the more serious explanation. There's a difference that users can alawys tell between you saying something funny or saying something insulting to their intelligence.)
Or a simple listing of the steps to do something (like find their files),maybe even a handout for common problems that they can refer to in a simliar situation. An explanation as to why it is important to you in solving their problem if they report the actual error message using a screen shot to show it to you rather than just saying, "I got an error, fix it."
Jargon is another thing to avoid. Most users have no idea what alot of the acronyms in the IT world stand for, avoid using them. For instance, suppose you are explaning a bug inthe system that the person reported. You don't need to describe the details of the code. It is usually enough to say, "There was a problem with the search procedure and it was pulling the wrong results. Thanks to your report, we now see the problem and have fixed the code."
In the end it all boils down to talking to people with respect.
"NOTHING is more important in a database than integrity." ESquared
You will be surprised what harm they can do, if they find out how you think about them.
We once had an engineer who treated the users (operators) like dummies. When we had a problem (24 hours operation) who did you think we would call?
Strangely enough the problems only appeared during non-working hours, until he got the message.
Steven
The way I try to look at it is that we are all universally human. I cannot rattle off our product line, just like one of my users cannot tell me the difference between Java and Javascript. If our roles were reversed (and given an appropriate amount of time), I'm sure we could learn each other's knowledge.
In most cases I do not think "users" are incapable, but rather they sometimes have "more important" things to do. (Though there are some technology haters out there.)
That's what I feel our role is - to take complex technologies, and enable our "users" to use them with minimal effort/maximum gain.
In most cases I do not think "users" are incapable, but rather they sometimes have "more important" things to do. (Though there are some technology haters out there.)
That's what I feel our role is - to take complex technologies, and enable our "users" to use them with minimal effort/maximum gain.
A little knowledge is a dangerous thing"...
Be careful with users that appear to be PC-savvy. Never assume that they are. Most of my users don't have a clue, and they ask me about everything, which I think is fine (small org, 10 users, I'm the only IT-guy, as-needed).
I try to answer their questions the best I can in terms they can understand. My biggest problem is people storing stuff locally (analogy-in their purse or wallet) instead of on the network share (analogy-office file cabinet). I use the argument that the server is much more robust and is (severely!) backed up regularly. I've had users who (somehow) managed to move their network files to the Desktop! How they did it was a mystery to them.
We recently upgraded every system OS, (not Vista, XP!) and I sent out an email 10 days ago warning everybody that their hard drives would be wiped, and to backup their bookmarks and move everything from their "My Documents" to their shared folder on the server.
One of the first machines I did, the user appeared tech-savvy, I asked him to clean-up his Inbox as it was nearing the store limit, and he did. I had NO IDEA that he somehow created a local .pst file that held the last 1.5 years of email, that he used to reduce his total. He was devastated when he learned they were gone, but he got over it. I told him to PLEASE ask me before doing anything like that in the future, and I truly hope he will, but I doubt it. He's the kind of guy that just doesn't ask for help...maybe it's a macho thing, like asking for directions.
Anyway, I learned something too. For the rest of the PCs I am storing the user's profile on a flash key before wiping, just in case someone does not realize the files that they use everyday reside on their machines, not the server.
We have to anticipate problems and never assume that the user is as PC-literate as s/he would like us to believe.
Tony
Users helping Users...
Be careful with users that appear to be PC-savvy. Never assume that they are. Most of my users don't have a clue, and they ask me about everything, which I think is fine (small org, 10 users, I'm the only IT-guy, as-needed).
I try to answer their questions the best I can in terms they can understand. My biggest problem is people storing stuff locally (analogy-in their purse or wallet) instead of on the network share (analogy-office file cabinet). I use the argument that the server is much more robust and is (severely!) backed up regularly. I've had users who (somehow) managed to move their network files to the Desktop! How they did it was a mystery to them.
We recently upgraded every system OS, (not Vista, XP!) and I sent out an email 10 days ago warning everybody that their hard drives would be wiped, and to backup their bookmarks and move everything from their "My Documents" to their shared folder on the server.
One of the first machines I did, the user appeared tech-savvy, I asked him to clean-up his Inbox as it was nearing the store limit, and he did. I had NO IDEA that he somehow created a local .pst file that held the last 1.5 years of email, that he used to reduce his total. He was devastated when he learned they were gone, but he got over it. I told him to PLEASE ask me before doing anything like that in the future, and I truly hope he will, but I doubt it. He's the kind of guy that just doesn't ask for help...maybe it's a macho thing, like asking for directions.
Anyway, I learned something too. For the rest of the PCs I am storing the user's profile on a flash key before wiping, just in case someone does not realize the files that they use everyday reside on their machines, not the server.
We have to anticipate problems and never assume that the user is as PC-literate as s/he would like us to believe.
Tony
Users helping Users...
Don't ASSUME, because it means making an ASS out of U and ME.
I personally do not like the my documents etc.. If the computer suggests to save the file in my documents, why should an average user go against that?
I would suggest to the users that if they work locally, give them a folder called Data where they store all their stuff. In case of disaster it is easier to recover.
Steven
I personally do not like the my documents etc.. If the computer suggests to save the file in my documents, why should an average user go against that?
I would suggest to the users that if they work locally, give them a folder called Data where they store all their stuff. In case of disaster it is easier to recover.
Steven
EdwardMartinIII
Technical User
...especially if said "Data" folder is just a shortcut to a network location...
Edward
"Cut a hole in the door. Hang a flap. Criminy, why didn't I think of this earlier?!" -- inventor of the cat door
Edward "Cut a hole in the door. Hang a flap. Criminy, why didn't I think of this earlier?!" -- inventor of the cat door
- Status
Similar threads
- Locked
- Question
- Locked
- Question
- Locked
- Question