Four Tips for Training Clients on a Drupal CMS

Posted Apr 5, 2011 // 0 comments

We’ve forged a process over the years for conducting client training sessions -- it’s been chock full of trial and error methods and deliverables, from 4-hour long enterprise trainings with lunch to PDF guides with screenshots and annotations.

But the importance of sitting down with your clients and walking through the interface just can’t be emphasized enough. Probably because of decades of proprietary (painful) technology systems, users (especially in enterprise environments) are skeptical of how easy managing website content actually will be once they take the reigns from us. And maybe rightfully so; which is why conducting a successful client training session for a Drupal CMS presents such a great opportunity to change minds by making clients feel both relieved and excited.

So to ensure we capitalize on making the client training session a memorable, informative, and enjoyable experience, we typically follow these four tips:

1. Understand your audience before you arrive. This requires some questions posed over email or a call to your point of contact (or to a few of the people who might be in the session, ideally). Find out their prior experiences with Drupal, with content managementm systems in general, and with web tools often used in conjunction with publishing (like browsing the web to get links, or uploading videos to YouTube or images to Flickr).

• Group people together by level of tech savvyness. This is something we learned early on since trainings are much more effective if everyone is learning at roughly the same pace.
• Group people together by job responsibility. If you can create smaller chunks of trainings that educates users just on the type of publishing they’ll be doing, this makes a great use of time.

2. Keep the group small. We ideally can schedule large numbers of folks into several smaller sessions; we try to keep the number of attendees to a maximum of five to seven people with each person having his or her own computer or laptop. That way, we can walk them through actual scenarios so they get hands-on instruction, and this amount of people seems to be the magic number where they’ll help each other and ask us loads of questions, too -- rather than keeping to themselves.

• If we have a larger-than-ideal group of administrators (which often is the case at our enterprise rollouts), we may bring up the interface on a screen at the front of the room and ask people to bring laptops where they can walk through it at their seats.

3. Arrive early and prepared. There’s nothing like trying to give a relatively complex training session to complete strangers with varying levels of skills after running late. So we’ll fly in the night before, take the train several hours earlier than necessary, or arrive at least 30 minutes prior to the training start time so we can be sure technology is covered and water’s on the table before the training session officially begins.

• Create talking points for all the main actions needing to be demonstrated. By prioritizing these, we’ll be sure to cover the meatiest part of the training first. Then we can fold in outlier cases of occasionally publishing needs or incorporate potential add-ons for future releases based on questions asked during the training.
• Take phone numbers to reach the client (or a person who’ll be in the training, if a lead is designated in case the usual point of contact is unavailable), and have all laptops, power cords, and projector cables packed.

4. Break down the subject matter into logical flows through the system. The talking points above may follow the workflow, and then further discussion can be devoted to digging into additional features and details that complement the workflow.

• Sometimes, we’ll go through the workflow twice (or more) just to start creating a sense of repetition. (We all know that watching someone walk through something and then having to do it later -- when no one is helping them -- can be problematic.)
• If the group is huge (and sometimes even in smaller sessions), we may walk the users through typical publishing scenarios and then actually ask them to tell US what they want to do -- publish new content, edit existing content, upload images, etc. That gets them involved because they’re driving this portion of the training themselves after the initial demonstration is complete, and we’re just facilitating and filling in the blanks to help them remember.

In the end, we still find that a written guide with screenshots is a good way to supplement the in-person training, and the guide can regularly be updated and pushed to a common area where all administrators can view (or download it).

Let us know what ways you plan for, deliver, and support successful client trainings with Drupal CMS.