How To Train Your Client

Training is arguably one of the most rewarding parts of any project. It’s the big reveal, where you get to take the client behind the scenes and show them the cool things that you’ve built and how they, as the site maintainer, will be able to make it work. However, without a successful training process, it doesn’t really matter what you’ve built for a client. To them, it’s a monolithic black box of functionality, that reacts in strange ways that may intimidate someone from ever using a site to its full potential. In this post, I’d like to talk about elements of successful training sessions. By keeping these points in mind, training can become a way to build the client’s confidence in your work and help them use the product you’ve built for them the way it was meant to be used. h2. Planning Obviously, there are common elements to what (for example) a content editor needs to know on a Drupal site: creating and publishing nodes, managing taxonomy terms, and so on. However, a key component of the planning phase should be *knowing your audience*. As simple as it sounds, It’s incredibly important to remember that every client is different. If you have a script for node creation that you run through with every client, you’re likely going to miss a lot of important details that are relevant to the client. For example, here are a few questions that are helpful to ask any client, and which can usually be done in an email prior to training (or, if your improv is good, the first 5-10 minutes of the training session): * Do they have prior CMS experience? More specifically, have they worked with Drupal before? * What part of the workflow process will they be responsible for? * What’s their background in site management? * In a general sense, how tech savvy are they? Are most of these questions common sense? Sure. Will they go a long way to establishing your relationship with the client before you ever open your screen sharing? Absolutely. I’ll talk about *compassion* in detail later on, but steps like this go a long way to showing a client that you care about their understanding of the product. Tailoring the training experience to their level of expertise and background immediately starts you off on the right path. Once you have an idea of what you’ll need to cover in the training, it’s important to think about both the *timeline* of training and, drilling down into detail, *individual roadmaps of training sessions*. Your timeline is the big picture: your 10,000 foot snapshot of how many sessions you’re holding, what needs to be covered, and the order you want to introduce things. Putting thought into this can help keep you on track during training itself; when a question gets asked 10 minutes into the first training session about document management, it’s nice to be able to say with confidence, “We’re definitely going to cover that in a later session”. Roadmaps, by contrast, should be a more fine-grained agenda of what an individual session will cover. These should be done a day or two before the session, to allow for any questions that come in from the client to be incorporated in the schedule if necessary. Personally, my roadmap is usually a handwritten list of individual concepts or workflows that I’ll be covering that’s beside me during the training call or screenshare. My roadmap will always include more things than I have time for: if the training session is 1 hour, I’ll plan between 75 and 90 minutes of material, and draw a line on the roadmap where I suspect we’ll reach by the end of the hour. That way, if the session moves faster than expected, I’m not left with nothing to say for the last 10 minutes. Lastly, planning your training should encapsulate the practical side of things, such as your own tools & supplies. As obvious as it may seem, making sure you’ve reserved a phone line (if necessary), set up screen sharing (if you’re training remotely), and gathered your own materials such as pen and paper for quick notes means that you don’t have to worry about anything except the training itself during the session. !http://imagexmedia.com/sites/default/files_new/imagecache/content/images/ImageX_Media_Work_Station.JPG! h2. Setting Expectations So now that you’ve planned and mapped out your training, how do you make sure that things stay on track? Nothing feels worse than a training session running away from you, or getting 10 minutes into a session and having it turn into round-robin Q&A for the remainder of the hour. Luckily, there are some simple things you can do to keep things on track while simultaneously working with the client to make sure their questions are getting the attention they deserve. First and foremost: *share your roadmap*. Ideally, this sending the session roadmap to the client a day or two in advance, via email, Basecamp, or whatever tool you use. Additionally, the first minutes of a training session should be used to recap the previous session (if it’s not the first session) and explain what you’d like to teach during this session. I mentioned earlier that you’ll want to plan for more material than you think you’ll get through; in the case of sharing your roadmap, you probably don’t want to explain the extra material you plan, so as to not make it seem like you’re always behind. We all know the cliche of *underpromise and overdeliver*, but it rings true. If you get to the extra material, so much the better, but if at all possible, don’t make the client think you’re going to cover something and then not do it. As you work through your topics, an important thing to do is *check for understanding* with the client. By the time you’ve reached this point you should be pretty well prepared with your material. A key component of the training, as obvious as it might sound, is making sure that the client is responsive to the concepts you’re trying to teach. Again, each client will be different; some clients may pick up concepts quickly and you may find that you’re going too slow for their liking (in which case, it’s good you planned those extra topics, isn’t it?). Other clients will have slower comprehension and may need you to slow down. Your roadmap isn’t set in stone; it’s a guide that you can recalibrate to match client understanding. At the end of the day, it’s less important that you get through the roadmap in a single session and more important that the client understands what you’ve taught them. In that vein, it’s important to *ask open-ended questions* when checking client understanding. A closed-ended question--that is, one that can be answered by a “yes or no” response--won’t start a conversation as easily as an open-ended one. Consider the following questions: * “Does that make sense?” is closed-ended, and if a client feels well and truly lost, they may feel inclined to just answer “yes” rather than start the uncomfortable process of figuring out where they lost the thread. * “How do you feel about what we just covered?”, by contrast, is open-ended. It encourages thought and a more in-depth response. It shows that you’re more interested in client understanding than just simply running through a list of components to cover. Getting feedback from a client often presents a unique challenge; while it’s absolutely necessary for understanding, it presents the distinct possibility of derailing an entire session by delving into a series of increasingly off-topic “quick” questions. Luckily, there are strategies for incorporating questions while still staying in the driver’s seat of the training session. As stated before, it’s best to plan out time for questions into your roadmap. I personally like holding questions until the end, but depending on the client and the material you may want to structure your sessions differently. In general, the bigger and more tangential the questions are, the more you’ll want to defer them in order to stick to the roadmap. Offering to follow-up on unrelated matters via Basecamp or email is a great way to compartmentalize topics and keep your focus on the topic at hand. As always, judgement calls need to be made in the moment. If a client has a question that’s relevant to the topic at hand or segues nicely into your next item in your roadmap, maybe you’ll want to field it in the moment, even if it takes a little extra time. If the question is better served at a later time, it’s good to defer it until either the end of the session or, in some cases, to a different session altogether. No matter what, though, it pays to acknowledge the question, make a note for yourself to remember it, and factor it into future plans. h2. Compassion Take a look at the following sentence: “Okay, so this is an autocomplete field that will create new taxonomy terms when you save the node which you can rearrange in the admin screen for the related vocabulary” Now, as a developer, this seems like a simple descriptive sentence to me. Once again, however, clients come in all shapes and sizes, and what’s immediately obvious to some might need more explanation for others. There are at least 5 terms in this sentence that, if someone didn’t have any experience with Drupal, could potentially find confusing. When combined, it would be extremely difficult for anyone with a low level of experience to hope to understand. This, in a nutshell, is the core of the idea of compassion in training. It’s not enough that we come across as knowledgeable or competent in training; we should be *patient, understanding, and interested* in how well the client is learning. Training is more than teaching someone how to use something; it’s also about showing someone the value in the product you’ve built for them. And if you come off as pushy, impatient, or disinterested, the client can be put off from learning the ins and outs of using the end result. No one knows the product better than you; after all, you built it. If a client feels that they can’t ask you how something works, who can they ask? h2. Follow Through This last component builds on pretty much everything I’ve talked about thus far. After the session is over, *staying in touch* can go a long way to encouraging clients to ask questions and get involved with the learning process. At ImageX, we use Basecamp for the majority of our client communications. Before a training session, we’ll start a new thread on Basecamp with the roadmap for the training session. After the session, we’ll usually post a follow-up message recapping what was covered in the session. Any questions related to the topics we covered can now be captured in a single thread; additionally, any follow-up information you said you’d provide can be posted in this thread as well. And related to that, as obvious as it may seem: *if you said you’d follow up on something, do it*. Depending on the client and what stage the project is in, *giving the client a sandboxed version of the site* can be incredibly helpful. In a remote world, training usually isn’t in person and isn’t hands-on; a demo site where the client can try out the concepts you’ve been teaching them allows for a higher level of comprehension than can be achieved by simply showing the client something. It allows the client to try things out, ask questions when they run into issues, and provide feedback on things that can inform the next training session and save you time in the future. Lastly, as discussed, if you’ve got another upcoming training session, *prepare the client for the next session*. Post the roadmap agenda in advance and check in with the client to see if there’s anything that they feel is missing from the agenda or that they’d like covered again. h2. When it all goes wrong Naturally, despite all of your best efforts, training isn’t a precise science and things will sometimes go wrong. A common derailing scenario I’ve come across is when a client, upon seeing a component you’ve built, responds with “Well, this isn’t how we expected [component x]”. As with much of training, what happens next will always be a judgement call. It’s always worth a quick conversation about what they did expect; it could be nothing more than a simple misunderstanding about how a component works and then you’re back on track. If it is a larger discrepancy between what they wanted and what was built, however, it’s always worth deferring the conversation to give you a chance to review requirements and talk to your Project Manager. If you end up needing to defer, you’ll probably need to rearrange the order of the session--yet another reason to plan more material than you can cover in the session! The worst moment for any trainer is hearing the client say the inevitable two word phrase, “I’m lost”. In this moment, Douglas Adams said it best: don’t panic. The most important thing in this case is *don’t push ahead*. Put the brakes on and ask questions (open-ended, natch) to find the pain points in the training thus far. Let the client explain what they do and don’t understand, and re-evaluate from there. Again, you may find that it’s only a small misunderstanding that got the client lost; then again, you may need to re-cover half of your material. Again, in this scenario, *compassion is key*. If you act impatient when you have to redo the training, you don’t do the client any favours and they won’t be as willing to respond next time. h2. A final thought As web developers, it’s sometimes too easy to dive into code and configuration and forget that we’re in a client-facing industry. Training, as much as it’s about teaching, is also about relationships. Whether establishing a new client relationship, strengthening an existing one, or repairing one that has become frayed, training a client properly goes a long way to establishing confidence with the client that you, the developer, know what you’re doing. At the end of the day, all you need to remember is to be *reasonable and be prepared*.