Instructional Technologist, Explained

I bill myself as an instructional technologist, which means I’m often met with blank or puzzled stares. I thought it might be useful to explain my rational for using this title.

Warning: this post may bore you to death, or cause you to get caught up in a tangled web of semantics.

In my opinion, an instructional technologist is a person who specializes in utilizing technology for instructional purposes. (Duh!) It’s a very broad title that can cover many different and often only tangentially-related duties.

When I was younger (so much younger than today), I worked in a number of educational and non-profit organizations in a technology support capacity, including print production, radio broadcasting, audio engineering and video production. With the dawn of the internet, I expanded my skill set to include web development. I relished working in a variety of mediums, and began to think of myself as a media generalist. Being a jack of all trades* was fun, and it felt good to know that most of my projects were educational or somehow helped the community.

When I decided to go to grad school, San Francisco State University’s Instructional Technologies (ITEC) program seemed like a perfect fit. I assumed that the program’s title meant that we would learn how to use technology in an educational capacity. Turns out I was only half right — technology was definitely involved, but I was also informed that “technologies” sometimes referred to adult learning theories and principles, not just just tools. Instructional design, which is completely independent from common notions of technology, was the primary focus of the program. I learned a lot about educational psychology and learning theories while in the ITEC program, and oddly didn’t really learn much about technology as I had traditionally defined it.

Once I graduated from the ITEC program, I jumped right into e-learning development, as both a content author, a course developer, and a course delivery systems programmer (SCORM, course development tools, etc… probably what pipwerks.com is most associated with).

As a content author, I often performed instructional design tasks, including needs assessments, research, writing, and content sequencing. For these tasks, instructional designer seemed most appropriate. However, because I also handled the media authoring and programming side of the courses, many people thought of me as a programmer, web developer or e-learning developer — all of which I felt were also too restrictive. I don’t want to be stereotyped or painted into a corner.

What to do? Well, I hearkened back to my grad school days and copped the title instructional technologist. It felt flexible enough to work for my needs, while still being accurate and even a tad mysterious. Mystery is fun, especially when most of your co-workers have bland titles like “analyst.”

Instructional technologist is also portable. Last week I left my old job and started a new one. While I used to focus on e-learning development and LMS administration, I now work with classroom support in a university setting, with a focus on administering a lecture capture system. Although I’m working in a completely different environment with very different technology, I’m still working with technology in an instructional or educational capacity. I was able to retain my working title of instructional technologist (kudos to my new bosses for agreeing to it).

Many people in universities use a title such as educational technology specialist. That’s a nice title, and very fitting for what they do. However, it also has the connotation of educational institution, such as university or even high school. Since my work has spanned corporate training as well as community and university work, I prefer the word instructional over educational.

So there you have it. Instructional technologist, explained. Think it’s great? Ridiculous? Have a better idea? I’d love to hear your thoughts.

* “Jack of all trades, master of none, though oftentimes better than master of one”
[ citation ]

Advertisements

Things to consider when working on a project

I read not one, but three great blog posts today regarding what kinds of questions you should asking yourself when working on a project. Two of the blogs were not specific to the e-learning industry, but they apply nonetheless.

Why?

The first blog, by Jason at 37signals.com, suggests that you should always Question your work. He lists the questions he feels we should always be asking ourselves when working on projects:

  • Why are we doing this?
  • What problem are we solving?
  • Is this actually useful?
  • Are we adding value?
  • Will this change behavior?
  • Is there an easier way?
  • What’s the opportunity cost?
  • Is it really worth it?

As instructional designers, we’re trained to perform high-level impartial needs assessments, but we’re only human and get tripped up in the details as easily as anyone else. One of the easiest things to do is to forget to ask yourself “is the training I’m about to create really going to solve the root problem?” Taking a moment to step back and ask yourself Jason’s questions (especially if you’re a freelancer trying to decide if a project is worth your time) is a good idea.

Taking care of business

Speaking of freelancers, Joeflash had a great blog post today titled Business tips for freelancers. Again, not specific to e-learning development, but still directly applicable to contracting work in almost any field. His sixteen tips are very practical, and the list is a quick but very worthwhile read.

Looks matter

Lastly, Tom Kuhlmann at Articulate wrote a nice blog entry about Why Looks Matter in E-Learning Courses (And What You Can Do About It).

This particular blog entry gives great tips about the visual design of your e-learning course. He advises readers to:

  • Understand How to Use Colors
  • Create a Fresh and Contemporary Design
  • Maintain a Consistent Look and Feel

These are the kinds of things I would expect most course developers to already know, yet it isn’t very hard to find examples of courses that don’t adhere to these basic design principles.

Side note: I’m generally not a fan of Articulate’s products, but I think Tom’s blog is a must-read for e-learning developers. He usually has great tips and practical advice, in easy-to-understand language, without trying to do any hard-sells of Articulate products. We should all strive to write so clearly, especially in our courses!