eLearning Courses for Medical Librarians

I designed and developed five xAPI-enabled courses to help medical librarians better support their libraries' patrons.

• Responsibilities: Instructional Design, eLearning Development, xAPI Implementation
• Target Audience: Librarians worldwide (particularly those working in medical settings).
• Client: Medical Library Association (MLA)
• Tools Used: Storyline 360, Illustrator, Mindmeister
• Budget: Low to Medium
• Year: 2019-2020

The client, an education director at a large international library association, was tasked with building a vast portfolio of online courses to support the librarians and institutions that they partner with worlwide. Determined to build data-driven, action-oriented solutions, the client reached out to me very early in the process to provide xAPI consulting and build a solid foundation of courses.

Process

Before touching design and development of the courses themsleves, I helped the client envision how they could leverage Experience API (xAPI) data to gain deep insights about the user experience.

Important note: The first part of this write-up discusses the xAPI consulting process. If you're unfamiliar with xAPI, you may feel slightly confused by some of the terminology. In short, xAPI is a data specification for the learning industry. It helps us capture data about the user experience in a simple, human-readable format: Actor, Verb, and Object. For example, "Devlin read xAPI 101 Guide." For most use-cases, it's necessary to use custom JavaScript to send valuable xAPI statements.

xAPI Consulting

I started the xAPI consulting engagement by educating the client on what xAPI was capable of and how we were going to use it. The first part of the engagement dealt with strategy and data collection, and the second part consisted of data analysis.

Also, since the client would be working with many instructional designers to build the volume of courses that they were sponsering, I proposed building detailed step-by-step documentation to help non-technical instructional designers leverage xAPI in the courses that they would develop. I also proposed building an xAPI Statement Generator so that these designers wouldn't have to write a line of code on their own.

The client was on board with my proposal, so we moved forward with building out the solution.

Initial xAPI Planning

First, I selected a list of xAPI verbs that we would use to describe the user activity in the eLearning courses. It was important for us to start with a well-documented, mutually-agreed-upon verb list — this is because we needed to make sure that all designers would use the same verb to refer to the same activity. This makes it possible to conduct meaningful analysis on the data down the line.

Writing the xAPI Code

After ironing out the verb list, I wrote a JavaScript function for each verb. For example, for the "selected" verb, I wrote a "sendSelected()" JavaScript function. This allowed me to include only the necessary parameters for each type of statement that would be sent.

I also used regular expressions and other JavaScript validation techniques to reduce the room for error in the input that other designers would enter into the functions.

Building the xAPI Statement Generator

I used Google Sheets to build the xAPI statement generator that the other designers would use. In an effort to make the sheet as easy as possible to use by non-technical designers, I color-coded which columns should be filled out for each verb.

I also included succinct instructions on when to use each verb and how the respective cells should be populated.

Once the designer populates the cells, a formula that I wrote pulls the information from the cells and populates it into a JavaScript function in Column I. The designer can then just copy this code and paste it into a Storyline "Execute JavaScript" trigger to send the custom xAPI statements as desired.

Writing the xAPI Documentation

Giving designers the statement generator wouldn't be enough. I also wrote clear documentation for the designers. The documentation introduces xAPI, states when to use the different triggers, explains how to use the different triggers, and explains how to modify the published output to ensure that the data sends successfully,

Once this documentation was reviewed by the client and piloted with other designers, we knew that it was ready-to-go.

Other instructional designers could now send custom xAPI statements within an hour with only a basic understanding of how to use Articulate Storyline.

Course Design and Development

The client was also very clear about where they wanted to spend their budget — they didn't want flash and bling, but instead, solid text-based content that would immerse the learner in the situation, allow them to make real-world choices, and present them with realistic consequences.

We decided that we would use the action mapping approach to focus on practical takeaways. This would result in a real-world scenario with supporting content that would be available on-demand.

In all, I used the following approach to build five courses for the client:

1. Leading a Decision-Making Meeting
2. Managing Conflict in Decision-Making Meetings
3. Instructional Design Basics
4. Instructional Strategies for Active Learning
5. Strategic Communications

Creating the Action Map

By the time the courses got to me, the general topic and learning objectives were decided.

I used the first meeting with the Subject Matter Expert (SME) and client to solidify the instructional goal and learning objectives.

From there, we dove into action mapping. I led the action mapping process and helped the SME focus on the specific, observable tasks that librarians would have to perform to achieve the instructional goal.

We used the action map to guide all ensuing content and design decisions. If the content did not support performing one of the observable tasks on the action map, then it was not included in the course.

Creating the Prototype

After we were satisfied with the action map and all of us agreed on the design approach, I built a prototype that we could pilot with a group of users.

I sourced content for the prototype by working through part of the scenario with the SME, then I built the prototype in Articulate Storyline.

Once it was ready, we delivered it to the users. We collected raw quantitative data using xAPI triggers, and the client faciliated user interviews and surveys to collect qualitative data.

We used data during this phase to adjust our design approach as needed for the remainder of the course.

After resolving any issues that were highlighted by the prototype, we all agreed that our approach was sound and agreed to move forward.

Writing the Content

I wrote the content for the scenario(s) in batches by working closely with the SME. I kept the conversation focused on real-world scenarios and consequences associated with the actions we wanted the users to perform. The SMEs were excellent at sharing their real-world stories and expertise.

This resulted in rich scenarios that mirrored what happens in the real world.

I also asked the SMEs to provide supporting content that would help the users make the key decisions or understand why they experienced the consequences that they did. I worked with them to keep this content concise and focused.

Developing the eLearning

Once the content for a given module or task was finalized and reviewed, I put on my developer hat and built it out in Storyline. To provide the biggest amount of impact with the client's budget, we decided to use a "templated" approach for the eLearning slides.

We kept things largely text-based and swapped out the background image as needed to signify changes in the scenario context. We used several non-templated slides per course to allow for the variation in activities and content.

Since the scenario's story and decision points served as the driving force for the content, we were able to design an engaging experience without unnecessary spending on the development and graphic design front.

As with many of my projects, I sourced the vector graphics from freepik.com and modified them as needed using Adobe Illustrator.

Also, to add to the visual engagement and immersion, I used fluid animations to transition between slides. You can see these animations in the video below, but they look much smoother in the published product.

I added JavaScript triggers as I went to ensure that we were collecting the valauble xAPI data that we would use later to improve the course.

Evaluation

The evaluation for these courses occurred in three major phases:

1. The prototype. This is where we collected qualitative and quantitative data to ensure that we were on the right track with our design.
2. The post-course survey. This is the survey that learners take immediately upon completing the course.
3. The three-month follow-up. Participants complete this survey three months after completing the course, answering questions about how they've been able to put their skills into practice.

The client handled the post-course surveys, but I assisted him with interpreting the prototype data and leveraging the xAPI data to make sound decisions.

For example, in one of our early prototypes, we found that very few users were answering the questions correctly on the first try. The qualitative data reinforced this — we had complaints from people that they were getting questions wrong and they didn't know why.

After looking at the xAPI data, we found that 90% of participants were not looking at the "Learn more" content. Also, the 10% who did view that content answered each question correctly on the first try.

This was good news insofar as the effectiveness of our content was concerned, but we were clearly falling short when it came to drawing the users to that content in the first place.

We decided to provide more guidance up front regarding accessing the supporting content, and we also "locked" the answer choices on the first question of each course until the user viewed the supporting content. This guaranteed that they knew what type of content was there, as well as how to access it.

After implementing these changes, we saw users performing significantly better on the scenarios.

Project Takeaways

This long-term engagement left me with many powerful takeaways to use on future projects.

First, it showed me that it's still possible to develop a realistic, immersive scenario without a large budget. We could have made the scenario more immersive with branching, audio, a more refined graphic treatment, and additional animation, but we got the job done with simple visuals and text. I have action mapping to thank for this.

Next, and most importantly, it gave me a good opportunity to put my xAPI skills to the test and help the client leverage the specification to improve the quality of their learning programs.

I also got to provide tools and documentation that help other designers leverage custom xAPI statements — a capability that is very valuable when it comes to data-driven learning design.

This engagement has helped me grow as both an instructional designer and an xAPI consultant, and I'm looking forward to applying what I've learned to future projects.