I don’t often write directly to my instructional designer colleagues; usually I try to impart some of the occasional nuggets of wisdom I’ve gained from teaching, research or just plain trial and error to faculty, so they can avoid making the same mistakes I have. This time I’ve found a new way to stay inspired and reduce the burnout that can happen in this line of work, and I’m excited about how it has affected my approach to Instructional Design (ID) that it bears repeating.

Over the past decade or so, we have all witnessed a major change in health care. The medical profession has shifted focus from just treating the symptoms to preventative care—the idea that by changing life and health habits earlier on, it will reduce the amount of symptomatic care required for patients later in life. It does seem to be having a positive effect so far, as hospitals have more time to deal with emergencies, and their doctors and nurses spend less time in consultation over health conditions that are ultimately preventable.

So why not bring that approach over to the way we support faculty? Too often I have found myself dealing with minor technical support issues in course sites, or with site specific software or hardware, when I would much rather spend my time creatively throug design or research projects, training, or consulting with faculty on higher-level instructional design and technology issues. I get calls and email about the same thing time after time, and even sometimes from the same people. Obviously the message has not always not reached the intended recipients, and I keep repeating the same technical processes time after time. Finally, in a moment of frustration, I asked myself:

“What do I have to do to stop the calls from coming in the first place? How can I give them just-in-time support, without them actually being aware of it? ”

That changed the conversation a little. Wait, that’s what I really want. It’s also what faculty want. They literally want the “Easy” button like in the Staples commercials so they can solve their technical issues quickly, without needing my intervention, or better yet, not have any issues in the first place. I want to keep solving problems with creative pedagogy and technology like I always have in this job, yet not get bogged down by technical issues. This is going to be a sea change in the way I (and hopefully we) design, but I think it will be well worth the effort in the long run. So here are the steps I’m currently taking. I hope they will reduce the amount of less enjoyable work, increase my own time for research and training, and allow me to be more frequently and in better contact with the faculty I serve.

Templates

I began working with simple course site templates years ago, but this idea bears revisiting. By far the comment I receive from faculty the most often about our LMS is that “it’s not intuitive.” Sure, I can keep answering questions about how to do things, or where a certain function is, but what if I could make the course design that faculty receive for their courses simple enough to use that they won’t need to ask? If it’s obvious how and where to get started, or if there are at least clear instructions present, we can teach faculty to fish, and hopefully they will be able to go it alone eventually. Some faculty are comfortable exploring on their own and deviating from the norm. This is perfectly acceptable, but then again, those are the faculty we have the most interesting relationships with. Their phone calls are more like “Hey, I had this crazy idea for my course. Can we do this?” The majority of the faculty I work with, though, mostly ask “So what do other people do? What’s typical?” For these folks, I am working to standardize course navigation, course home pages, and approaches to course content from department to department, and within the college as a whole. It’s a dream, but maybe some of this will rub off on others through osmosis. If many faculty want to use the discussion boards, and don’t seem to know how, I’m putting the instructions right in the discussion tool so they can’t miss them and can at least get started. If they just arrived at an online course home page for the first time ever and really have no idea where to get started or what to do, I’m putting instructions right there that only they can see that will guide them where they need to go (or to further instructions at least).

Documentation

Some issues just can’t be solved or prevented with just-in-time instructions. There are too many variables, special circumstances, or simply too many steps to solve with just a picture and a paragraph. However, standardizing templates across many areas will hopefully reduce support calls and increase the time available to answer these questions through documentation. For the simpler stuff, it’s with instructions; more complicated problems require a more in depth approach.

We have been quite successful with both print documentation and video tutorials in reducing the amount of support calls we get, since there is an online or downloadable reference guide for most common questions about course tools and design, and usually several videos that can address them as well (and we keep records of the questions we answer so we can keep updating in response to them). As you might imagine, development of this sort of thing is a fluid process. An LMS gets upgrades, faculty ask different questions, and best practices in online teaching and learning change over time. The bad news is, you can’t only create documentation once that will stand the test of time; documentation isn’t literature. It is a way to keep answering specific questions faculty have without needing to address them specifically every day. Regular maintenance and updates will be necessary to keep things current, but the more you can have people regularly assigned to that sort of work, the less of a chore it is to do it all at once. When we first made video tutorials, there were almost 150 to make, which was a monumental task. But after that initial push, we only had to make one once in a while, or update one where a tool or procedural flow had changed. Print documentation, too, was a huge task. But again, once the initial offerings were finished, they only required occasional revisiting and revisions. In the long-run, it’s worth front-loading tasks like documentation. Although it is a lot of work, only occasional maintenance is required afterward.

Consultation

After the everyday questions and low-level tasks are answered or can be easily answered without personal intervention, it’s time to take the pulse of the departments and faculty. If they feel that, for the most part, they can answer their own questions through self-service, this builds their confidence in your department and in your abilities. Then they will begin to ask the design questions you want to hear instead of the support questions you would like to answer less of. With the extra time you gain by reducing the number of support calls, you can instead reach out to them in person. Go to department meetings and introduce yourself. Do more “dog and pony show” when you meet with a faculty member, now that you’re not just helping them fix technical or how-to issues. Does your school have online programs? How could you move beyond course to course work and improve things on a programmatic level? What kinds of resources are many of the department’s professors using, and what could you do to help improve the delivery of those materials in their courses?

Training

It’s a common problem that people don’t go to training. Especially the people who could really use it the most. Faculty don’t have a lot of free time to become technology experts, since they are usually busy in their disciplines trying hard to be subject matter experts. Although they may not always be very tech-savvy, if you ask them, they have a very clear idea of what they would like to accomplish in their courses, and what sorts of assessments they would like to use. This is the piece we’re trying to solve: how to bridge the gulf between faculty objectives and their technology skills so they can get their work done. If they are guided through the technology as they are using it, they will not be spending nearly as much time asking you to do it for them.

This is not to say that you should abandon face-to-face workshops; on the contrary, they are important, but the trick is getting people there. A few tactics have been effective for me and others in my department. First, the importance of good titles cannot be underestimated. It might sound silly, but finding enticing titles for workshops that will pique faculty interest and get them in the door means you get another opportunity to be face to face with them, win them over, and have a teachable moment. For example, rather than “Gradebook Fundamentals,” try something like “Help! My Grades Are Due!” Replace “Introduction to [LMS]” with “[LMS] for the Busy Professor.” With a title that speaks to them emotionally in a way they can relate to, they will anticipate getting something valuable out of it. “Yeah, I’m real busy…sounds like they will give me the most important stuff without wasting my time!” So will the workshop content change any? Not a bit. But you might get more people in the door if the title makes it sound intriguing.

It’s also valuable to set workshops up as part of a series. We have “Emerging Technology” and “Technology Tuesdays” events that occur regularly, and they provide faculty with a low-pressure opportunity to check out a workshop. If they know the series is held regularly, they won’t feel as bad if they miss one, so they might actually be more likely to show up to some that do interest them. Also, if you have a series, you can do some events that are purely informational, to demonstrate new technologies or other pedagogical content that will assist professors, but will also get them coming to the workshops because they are interesting rather than purely because “I need to know how to…”

The third big tactic that will get people in the door is food. Even if it’s their own brown bagged lunch, giving people an opportunity to eat sometime during your presentation will get people in the door. We have well-attended social events for graduates of our DOTS program because there is food and drink involved. But we also get to sneak in some pedagogy and tech demos while they’re eating, so they are in effect learning while they munch. A “Lunch and Learn” series is a great way to get faculty coming to workshops regularly; encourage them to brown bag it together, get them in a room and talk about something that interests them. The more camaraderie they find, and the more interesting things they learn, the more likely they are to keep coming back because it’s something fun to do instead of just eating in their offices.

It’s not easy to rethink training either. But given the right circumstances and faculty climate, it’s definitely possible to make training something we enjoy doing rather than something we have to do. The ultimate goal is be able to frame it as providing information rather than support; the training is coming to faculty because they are interested and want the training—before they need it to overcome obstacles. Train for the interests rather than the need, and you will find that when you can accomplish this all the time you will just be doing these workshops because they’re fun to do than because faculty really need answers.

* * *

Overall, I can say that at least for me, the more time I spend attempting to anticipate the support needs of faculty and create contingency plans for those needs, the less time I will have to spend later. It’s true, the shift to preventative care with faculty is major, requires a lot of upfront work, and does not necessarily come with big rewards attached. But the recognition isn’t really why we’re in this game in the first place, and every time we get a question that begins with “So…I had a great idea…” it makes everything worth it.

Let’s stop bandaging our faculty problems and taking them to the ID ER; it’s time for an instructional design “wellness program!”