Trainers Talk Tech

This past week I finished up my last ASTD Essentials Webinar Series and again had a "virtual" room full of highly engaged, highly interested learners. It was interesting hearing from this group: they are all going to be the eLearning Obmudsmen I commented on in an earlier post. As I was going through the software examples and demos, I started getting some really good questions about process. I have a standard routine that I use when building my eLearning project from scratch, and I thought that it might be of benefit to my reading audience.

After meeting with a client and getting my first installment check (!), we start the following process:

1) Instructional Design Phase

Some of my clients have at least an outline of the content to the site, some have complete storyboards, but most are somewhere in between. Its my team's responsibility to take what they have and build out a storyboard for their review. We use a PPT based storyboard to document screens, activities and simulations in a way that makes it easy for the client to see how their program will function and flow.

Follow up:

2) Design Phase

While the ID work is getting finalized, the graphic design team is busy creating a user interface. The look and feel gets built in Photoshop CS4 and is shared with the client via a flat image file I host on my web site. That way, the client can get a picture of what the learning project will look like. At this point, nothing works, its just a static image. The client can go through several phases of review at this point to ensure it looks exactly like they want. It is much easier to edit a Photoshop file than to tweak HTML or Flash files. Once the client approves the design, we can move forward with the build out.

3) Rapid Prototype Phase

Once the ID work and the interface design is approved, we quickly produce a rapid prototype. This usually happens within 3-4 days of design approvals. The rapid prototype is a sample of what the entire program will look like by watching/experiencing just a few screens. I usually have a multi-media page, a sample interaction/simulation and a generic content screen. These screens actually work and the client can get a very clear picture of how the entire project is being built out.

All character models, colors, interactive elements, sound effects, music and video elements are in the prototype and approved. If the client wants clip art over photos, funky music over country or any other creative variable, its unearthed and decided upon here.

I think this step is very important. I don't want the client to feel in the dark during the development phase, so providing a prototype gives them a real working project they can play with, very early on in the process. If they don't like the way the menu animates, the buttons change or the live interface in any way, it is easier to change it now than after the entire project is built out.

4) Development Phase

Once the rapid prototype is complete, we crawl into a cave and build it out. We use Flash CS4 and Dreamweaver CS4 for our development tools. The eLearning program is built out entirely in Flash CS4 - the code to hold the .swf file is built in Dreamweaver CS4. Sometimes we use dynamic text files, XML or other technologies, but when the rubber hits the road, during development, Dreamweaver and Flash are open all the time.

Our strategy when using Flash is to consider how the application is going to be hosted and served up to the learners. If it going to be a stand-alone application sitting on a web server and there is low media/low video, we would consider a single .htm/.swf file as our deliverable. If the application is going to be hosted in an LMS and has to be SCORM compliant, we generally break up the Flash .swf files into SCO's or modules for easier tracking in the LMS. We generally don't do a single .htm/.swf pair for each page of the learning, but tend to bunch them up into learning objectives/modules. Just our choice... there are lots of ways to do it, but I find that the integration into a SCORM compliant LMS goes a lot easier if each module is its own .htm/.swf pair.

5) BETA Phase

We enter into BETA phase when we have completed the entire project and it has gone through a first review by me or my team. After our review, we release it to a secure spot on my web site for the client to review. There may be some small edits, but a good storyboard and rapid prototype will generally eliminate most of the bugs in the application. Personally, my biggest blind spot is typos. I work to eliminate them completely, but when I have my programmer hat on, I am focused on code not text. Sometimes I miss blatant errors, but that's why we have a BETA phase...

6) Final Phase

The final phase is when we have the blessing from the client to "go live". This usually means zipping up the files and sending them off to the client. Sometimes we upload to their site, sometimes we put it in a SCORM wrapper for upload into an LMS. We then copy all the core files onto a CD and send them off to the client - they get the .fla, .psd, .png, .ppt files... everything. We believe that the client pays for the entire program so they get all of these core files. They can pay me to make changes for them, I can teach them how to make changes to the program, or they can never use me again. I want their experience to be amazing from start to finish, and for me, delivering those files is one of the differentiators that I offer to my customers.

I hope that you found this process helpful. Let me know what you think!