More what you’d call “guidelines” than actual rules

Edit: Forgot to link this in the original posting: “Help Vampires: A Spotter’s Guide” by amyhoy (Twitter)

If you have ever interacted with me on IRC, you know I spend a fair amount of time in the WordPress end user support channel, as well as jQuery so far in 2012. During the years I have spent helping others, I have observed a lot of success and failure in helping people solve issues they run into using these tools. Originally this was going to be more of a proper “tutorial”, but thanks to collaborative help from trepmal (Twitter), andrea_r (Twitter), ericmann (Twitter), sabreuse (Twitter), ipstenu (Twitter), idiot_girl (Twitter), DarkArtist69, and StevenCodes, it will come off a bit more like guidelines. I want to thank them all for their contributions and know that the feedback will be quality as many have participated in support for WordPress for a long time, either by way of the forums or the IRC channel.

There are two sides to support. The people providing the support, and the people seeking support. For each side, I have provided two types of guidelines: respecting each other and helping to resolve the issue at hand. While I have used WordPress and jQuery as examples so far, these are meant to be agnostic and should be true for any type of online support. The one point that I am going to put the most emphasis on, for both sides, is this. DO NOT BE AN ASSHOLE.

For the helpers

Respect the user seeking help:

• No matter what the person claims about themselves, be respectful and do not call them a n00b/newb/etc. It is demeaning and does not help.
• Be tolerant of different levels of knowledge and experience. Not everyone is at the same level.
• Avoid using language like “You did this” to the user. It can make them feel like you (the support person) are blaming them for their problem. Also avoid sarcasm as much as you can. Nine times out of ten, it does not translate well in text.
• Apologies can go a long way, such as “I am sorry you are experiencing this issue.” The user wants to know you genuinely want to help them and are willing to help.
• Some people do not ask for support until they are already really frustrated, be sympathetic to the problem and do not assume they are mad at “you”
• Do what you can to assess the person’s experience level. For some, a link to a plug-in is a better answer than a code sample, and vice versa. The right answer for the person beats the “best” answer in abstract terms.
• Do not make things personal. It is not about the person seeking help, their level of expertise, their language skills, or even their tone when asking for help. Stay calm and professional and focus on the question/issue, even if they come across negatively.
• Be patient, as the person you are aiding may be at their wit’s end. If you are unable to be patient or calm with them then just step back and let others help. Also, be patient with typos, misspellings, and “wrong” word choices. Not everyone speaks English as their first language or may be rushed to get their question answered. Communication barriers plus frustration results in many confusing typos.
• Avoid criticizing site design when possible. If you must comment on anything, make it constructive criticism and not “zomg this sucks!”. They may be working on functionality first, then style.

Helping answer questions:

• If someone is unclear with their question, ask for more specific information and try to pinpoint exactly where the issue is occurring.
• Do not be afraid to say “I don’t know”. You should not and can not be expected to know everything.
• Just because you, specifically, can not solve the issue or you feel you are not knowledgeable enough to help, does not mean you can not help direct the person to a solution. Any new information that can help is better than no information.
• If there is a more appropriate channel for help, do not be afraid to suggest it IN ADDITION to where they are now.
• Do not be afraid to ask for pointed out examples, code pastes, or jsfiddles. Also, ask for a URL so that you can look at the HTML source. This can help show various plug-ins in the header, any enabled caching or allow you to look for software/theme version numbers to see if anything is outdated. Firebug an Chrome’s debugging tools can also be used to troubleshoot.
• In relation to browser debugging tools, do not just point to them and say “use this”. The person may not be familiar with the tools at all or how to use them. If you do, provide links that show, at least, the basic features and how to get started.
• If you know someone who has more knowledge regarding the area for the issue, ask if they have a few minutes to help.
• If you are responding to someone with a code sample, be sure to explain what it does, why it does what it does, how to use it, and whether or not you have tested it beforehand.
• Ask the user “What have you tried?” or a variation, to determine what steps they have already done to attempt solving the issue. This can also give you the steps to replicate solving the issue, if needed.
• Provide links to further documentation. Do not assume that they have read the docs or even know where documentation is. Ask “Have you followed these steps at all?” If they have read the documentation, ask at which step things stopped working at.
  • If documentation does not exist, try to find resources or Google results for them, for the time being. If the documentation *should* exist and does not, make a note to write some in the future or to pass it on to whomever is in charge of the documentation of which area is missing.
  • If you provide an external resource, READ through it carefully. Too often support people can buzz through quickly and skip already provided information.
• Do your best to answer the question the person meant to ask, not the one they literally asked. “Is this possible?” should never be answered with, “Yes, it’s possible.” They are asking *how*, just not correctly. If someone asks how to do something that is clearly a case of “doing-it-wrong”, it helps to answer what they asked AND also explain why it is the wrong approach, then explain how to do it right. Do not just “cop out” and answer the question, but also do not smack them with a “you are wrong” answer while leaving them grasping. Educate on proper ways to solve a problem.
• Asking “Can you explain what your overall intent is?” can go a long way as to why they are asking what they are asking, if the question seems off the wall. If you can see their big picture, you may be able to go “oh, here is a better way to do this..”.
• Do not give answers to questions they did not ask. If someone asks for plug-in suggestions for a task, do not tell them that they should build their own solution from scratch, no matter your personal feelings towards other plug-ins that try to solve the same task.
• If the person is willing, help educate “how to fish”. Helping them learn how to research and solve their own questions can go a long way, but is not an end-all-be-all solution all of the time. Some people just do not have the time to research though, and need a more immediate solution. Sometimes talking things out can help “flip the switch” in their mind. This does not only apply to talking things out to remind them of an answer – it is also a model of the kind of thought process that happens in troubleshooting. Talking it through is educational in itself and helps explain why, more so than just getting the solution.
• Sometimes you will have to help calm the person’s fears. Let them know what will happen when they push the button. “This button?” “Yeah that one right there.” “The one I have circled in the screenshot?” “Yes, please click it and that thing you want to happen, will automagically happen, and your site will not blow up. I PROMISE.”

For the person asking for help:

Respect the people providing support:

• Respect the specified topic for the room you are in, and try to stay within its bounds. Off-topic chatter may be directed elsewhere.
• Do not assume that the support people automatically know what you are talking about.
• Realize the support personel are not there to judge how your site appearance, but to help you solve your problem at hand. They should not offer opinions unless requested.
• Support personnel may ask you to go through troubleshooting steps (like disabling certain components). Understand that this is a process to try to isolate the problem, not a suggestion that you can’t/shouldn’t use XYZ widget/plug-in once you are back up and running. However, there may be some cases where it is advised not to use XYZ widget/plug-in. This should be for good reasons, like known security issues or multiple varying issues indicating it is not ready and stable enough for distributed use. It is not intended as an insult to your site or personal taste.
• Be patient. At times there may not be anyone around, or the people who are there may not know an answer to your question. In time, someone with more experience may join and know how to better help. The present time of the week or different time zones can also dictate activity levels. Many people may want a break throughout the weekend and opportunity to socialize with friends and family. Others may not be awake when you are there. If an IRC channel is “dead”, seek out a forum that would provide a more persistent posting that people can read once they get back to their computers.
• Be calm. If you are agitated or aggravated, you risk coming off as so in your typing and may put others off from helping. Take your time when asking questions if you are irritated. There is chance that someone helping you will get just as irritated if you are rushing things.
• Do not make things personal. People are here to help you, so do not take it out on them if you did not clearly articulate your question the first time. Just try rephrasing or offering examples of what you mean. Once you start taking personal shots, the person may not wish to continue helping. You also risk alerting the support moderators who may ask you to take a brief break and return later when things have cooled down. If this persists multiple times, you may lose your ability to use the resource temporarily. If issues still persist, it could become permanent.
• Using CAPS LOCK, exessive!!! exclamation!! marks!! and OMG WTF BBQ ELEVENTY!!! may delay receiving help, as behavior like that is perceived as immature. Insisting that “It’s for a client” or “I’m on a deadline” will not likely prioritize your questions as “high importance”. Everyone’s questions are of equal importance, but other users may be kind enough to let you receive attentive help first.
• Many times people in support channels are helping for free and on their own time. Do not assume that the person helping has a specified amount of time available to help you work through your problem from start to finish.
• Try to respect the primary speaking language that the support channel uses and proofread, the best you can, what you are posting before you post it. Sending “I need hleps with teh ting n my page” is going to hinder the speed at which you get help at.

Help them help you:

• Brief answers can be construed as terse. Sometimes you will have to explain more. Smilies go a long way when displaying your emotion to the user, if you are happy about how the problem is getting solved more or less the helper will be excited for you and help you solve the problem fully.
• Provide links to your website in question, if possible. Local development is more difficult to help with, but is not impossible. You will need to provide a lot more examples and pastes since only you can actually see the website. Support personnel will often look at various aspects of your website, in order to determine different factors and to eliminate a lot of back and forth questions. Screenshots can help with describing visual issues and can provide SOME help for CSS related issues in regards to different browsers.
• Be willing to try things. The reason you are asking, is because you are putting trust in the support help having more experience.
• Explain what you have already tried on your own, what resources you have found, and what happened with what you have tried. Merely asking for help leads to a lot of “let me Google that for you” sentiment from observers. Some people will do a search for you because they know of somewhere that the same issue has been discussed and solved already. If they provide you with that, and it still fails, let them know and seek more guidance.
• Follow up with found solutions, especially if asking on a forum ( [Wisdom of the Ancients XKCD Comic][2]. This will help future searchers who have the same issue. ). Drive-by “I need help with X” questions just irritate support types. Coming back to explain “OK, that worked” or “That did not work, but I am moving on” provide at least some closure for those dedicating their time to helping you. If you found a completely different solution that worked, show how you solved it.

Hopefully using what is above, as well as anything not listed, you can aid in many pleasant support channel experiences for anyone you encounter, whether you are helping or receiving help.