Design Overview: Childhood TB for Healthcare Workers

Childhood TB for Healthcare Workers, a six-module online course for which I was the learning designer and developer, launched yesterday on World TB Day. This course was a project of The Union in collaboration with the World Health Organization.

I’m going to give a high-level overview of the design here.

A challenging part of diagnosing tuberculosis (TB) in children is that it’s a big picture diagnosis. Even in settings that have access to the tests used to confirm TB in a patient (and some facilities don’t have these tests), the results will be negative for most children, even if the child does have TB.

So, from the outset, this course couldn’t just be about memorizing procedures and test interpretations; we also needed to give learners a way to practice using clinical judgement. Self-paced online learning can be a great practice space to make real world decisions without the consequences of real world mistakes. Here, we wanted a practice space that would help build learners’ competence and confidence in assessing a variety of clinical symptoms and risk factors to diagnose childhood TB.

As much as possible, we tried to design interactions that reflected real world activities, decisions, and thought-processes. For example, in each diagnosis case, learners ask questions to uncover the patient’s history and gather notes.

Screen Shot 2015-03-12 at 3.16.28 PM

Screen Shot 2015-03-12 at 3.21.07 PM

Next, they select body systems to prioritize in an examination and plot the patient’s weight to assess ongoing trends.

Screen Shot 2015-03-12 at 3.16.49 PM

After considering their notes from the history and examination, learners decide whether to order additional tests to confirm a diagnosis. As shown below, these tests may not always be available in the location where the patient is being seen, so learners sometimes need to decide whether to send the patient away for the test.

Screen Shot 2015-03-12 at 3.17.49 PM

As noted above, many children will not have a positive test result that confirms TB, which means that diagnosing TB in children requires clinical assessment and judgement. To promote this type of “big picture” thinking that takes into account a variety of symptoms and risk factors, learners identify (and highlight) notes that suggest TB at each stage. Learners can then review these notes later as they make decisions about diagnosis and treatment.

In addition to practicing the skills needed to diagnose TB in children, learners also develop treatment regimens, offer counseling, and conduct follow up visits.

Screen Shot 2015-03-13 at 5.56.05 PM

Screen Shot 2015-03-13 at 5.56.48 PM Other, non-case-based activities include analyzing data in a clinic, performing contact tracing, determining which patients should receive preventive treatment, and implementing infection control techniques in a clinic.

Screen Shot 2015-03-13 at 6.03.02 PM Screen Shot 2015-03-13 at 6.03.24 PM

Whether case based or not, all of the activities are designed to help learners quickly see how information in the course is relevant to real life, and hopefully give them the practice they need to be able to implement the same skills and decision making on the job.

At the end of the course, learners practice and assess what they have learned in earlier modules by making decisions about a series of patients in a comprehensive practice module.

Childhood TB for Healthcare Workers is freely available from the (also newly launched) Childhood TB Learning Portal.

Remote User Testing for Learning Prototypes

The two projects I’m working on currently have a global audience, many of whom are located in areas with less-than-ideal Internet connections. Earlier this year, I tested several sets of prototypes with about 30 of these learners total.

Remote prototype testing became much easier for me with time, so I wanted to collect some of the technologies and practices that helped me, in case they are helpful to someone else too.

Testing the Interface Design vs. Testing the Learning Design

First, I wanted to share just a few thoughts why I test prototypes with learners.

As part of my typical design process, I create click-able prototypes of the planned interactions and test them with members of the target audience. While this is partially user interface testing, mostly what I’m testing is the thought process of the learners as they approach the activities: I want to know whether they are pondering what I hope they are pondering. Seeing these early reactions helps me adjust both the interfaces and the content to better meet the goals of the project.

During this testing, I have learners complete the prototypes while I watch and take notes. I encourage them to think out loud about why they are making certain decisions. While I avoid offering guidance, I do periodically stop learners to ask what they think is the main point of an activity, or why they made one choice over another.

Until this year, most – though not all – of the prototype testing I’d conducted had been in person, where it was easier to observe actions and reactions. During these rounds of remote testing, I found that I needed to ask more questions about their experience than for in person testing.

Scheduling Sessions

Scheduling for many different time zones was a challenge, especially since I was in California (USA) while most of the testers were in Europe, Africa, and Asia. I kept my schedule open for early morning and late evening appointments and used Doodle to give a range of possible times that testers could select from. Doodle automatically adjusts to the time zone of each person, meaning that I spent less time converting times (and had less opportunities to make time-zone mistakes.)

Preparing for Sessions

English wasn’t the first language of most of the testers and set up was often the most confusing part, so I began sending instructions in advance with links to the prototypes and instructions on how to start Skype screen sharing.

Before we started, I would also open a Word template for note taking that listed all of the prototypes I planned to test as well as other more general questions. While I typically took notes about sessions on my computer, I would also keep paper nearby in case we had to switch to using my computer to access the prototypes (more about this below.)

Connecting to Testers

For the actual sessions, I generally tried to use Skype audio with screen sharing since it’s free and fairly widely used. I’d have learners load the prototypes and start screen sharing to let me watch and listen as they completed the activities.

This worked for most but not all of the sessions:

  • For two testers, Skype stopped working altogether (possibly, throughout the whole country.) For two other testers, Skype audio mysteriously failed (video and chat was fine.)
  • Two people had versions of Skype that didn’t seem to offer screen sharing.
  • For one person, the prototypes wouldn’t load at all.

To help with some of these challenges, I also signed up for a account. audio options were too limited/confusing for our needs, but the screen sharing software allowed for remote control of a shared screen – so, in addition to watching learners completing the prototypes on their computers, I could load the prototypes on my computer and give the learner control as needed.

Between the two projects, I had over 30 sessions. By the end, technical problems stopped fazing me. If we had a problem, instead of troubleshooting, I just switched technologies. So, if Skype audio failed, I’d ask for a phone number. If they didn’t have a phone number, we’d use text to chat. If a prototype wouldn’t load on their machines, I’d give them remote access to my machine. I was asking people to take time out of their day, and spending an hour troubleshooting why something wasn’t working was a waste of everyone’s time.

Analysis Questions for Learning Design

I definitely favor successive approximation over the waterfall method; by prototyping early and often, you not only get a better sense of what will actually be most effective early in the process, when you’re best able to make changes, but sometimes end up refining the goals for the project itself.

That being said, I think analysis is super useful, and I spend a fair amount of time on it early in most projects. The analysis questions I ask vary. However, typically my high level goals are to:

  • Learn what success looks like for this particular project.
  • Dig into the key differences between that ideal situation and the current state of things.
  • Learn about the target audience, their motivations, and their work environment.
  • Explore existing tools and resources, and identify the gaps between what these resources already provide and what is needed for success.
  • Begin to dig into behavior: what should people be doing, why aren’t they doing it, and what are they doing instead?

Below are some of the generic the analysis questions that I have in front of me when interviewing key stakeholders towards the beginning of a project. When I’m actually interviewing, I often jump around, adding and modifying questions as needed.

Target Audience

  • What is their background?
  • Where do they work?
  • What is their work environment like?
  • What are the biggest challenges on the job?
  • What motivates them?
  • What do they worry about?
  • What do they like most about their jobs?
  • What do they like least about their jobs?

Project Goals

  • In the future, a year or two years after we launch this course, how will you know it’s been a success?
  • What do you want people to do differently after taking this course?
  • Why aren’t they already doing this?
  • What are the most common knowledge-related barriers?
  • What are some of the non-knowledge related barriers?
  • What are the changes someone could make to have the most impact?

Skills and Behaviors

  • What would be the best sorts of practices (real life or otherwise) to prepare learners for what you want them to do differently?
  • Are there people already doing this well? If so, how did they teach themselves?
  • What are the best practices?
  • What are the common misconceptions?
  • What are the most common mistakes?
  • What are the most tempting mistakes?
  • What is most challenging?
  • What is the target audience already doing very well?


  • What resources already exist to help the target audience?
  • How frequently are these resources used?
  • Could these resources be made more useful? How?
  • What information does the target audience really need to memorize, and what information do they just need to know how to find?

The above questions are aimed at project stakeholders. I also try to interview the target audience early on in a project, either through focus groups or one-on-one interviews; those questions are similar, but typically focus on skills, behaviors, and motivations.

What do YOU think is most important to ask at the beginning of a project?

Other Ways to Inspire Change

What interests me most about learning is its potential to inspire change: ideally a measurable change in behavior, but barring that, at least a shift in attitude or understanding.

Very often, we decide we want something to change, we decide to create a course, lesson, document, or some other package of information that learners will absorb and, voila, change!

What if, though, in many cases it’s not actually a lack of information that’s preventing learners from doing things differently?

A couple of weeks ago, I was pondering how to create educational games that allow learners to practice avoiding common advertising tricks. I had hit a wall after play testing several game prototypes. Simultaneously, I was also lamenting the existence of holiday gifts, and how much pressure there is to buy meaningful gifts for an ever-widening circle of receivers within a commercial sea of expensive candles and scented lotions.

That was the moment of inspiration for Gift Instead, my latest project.

What if, instead of trying to teach about advertising, we just gave people tools to opt out of the whole purchase-more-oriented system – well, at least for giving and receiving holiday gifts this year?

Gift Instead is a web site that lets users create, customize, and share purchase-free gift lists. Users can explore prewritten ideas for purchase-free gifts, but they can also create their own.


My awesome husband Brian did most of the heavy lifting with piecing together a framework for the site and was my brainstorming partner in making this project come alive.

I’m really excited about the site we created. It’s still officially in beta mode, but it’s a very functional beta: please feel free to try your hand at creating and sharing a wish list and do send me any feedback about your experience.

I’ll probably revisit the idea of educational games about advertising schemes in the future. However, I really enjoyed working on another potential path into that same sort of change – less needless stuff purchased – by creating a tool rather than a packaged educational experience.


Learning-by-Doing: GuitarBots

Yesterday, I wrote about how most “learning-by-doing” is really is actually “learning-by-doing-something-really-similar-to-what-you-ultimately-want-to-do.” This is the a post in a series where I explore games and online learning that incorporate authentic practice.

GuitarBots is an online game where you learn to play the guitar by playing the guitar. Unlike similar systems, you can use any guitar, including an acoustic one, since GuitarBots uses your computer microphone to detect which note you’re playing.

After watching my husband (Brian) play for months, I decided to sign up for my own account yesterday. Until I signed up for this account, I’d never played a guitar, so please excuse any accidental abuse of guitar terminology in this post.


If this were traditional online learning, it would have started with an introductory module on the history of the guitar and perhaps some information about how guitars are constructed. Luckily, this wasn’t traditional online learning.

If this were more performance-focused online learning, I would have interacted with a web-based interface to tune a virtual guitar, by clicking the knobs to turn them and then clicking the strings to play the notes. This probably would have helped somewhat had I then immediately practiced this using an actual guitar. However, I certainly wouldn’t have had the visceral sense of knowing just how much to turn a knob, or how to juggle picking and knob adjusting without dropping the guitar. (I’ve never claimed to be particularly coordinated.)

Instead, in GuitarBots, my first lesson was learning to tune my guitar by tuning my real guitar.


GuitarBots stepped me through the basic tuning process of turning knobs and picking strings. I adjusted until the onscreen tuner indicated that I’d matched each note on my guitar.

Once I’d finished tuning the guitar, I immediately moved into learning to play a song by playing a song. (A very simple song.)


After each song, I received a report on my timing and accuracy, as well as my history playing this particular song.


As I played, I unlocked additional songs.


In addition to songs, GuitarBots guides you to practice related techniques.


I’m told that it’s possible to test out of early levels by demonstrating your competence on a song that very gradually increases in difficulty. With my limited guitar-playing skills, I didn’t bother. However, this seems like a great way to make a system that accommodates learners at a variety of competence levels.

At the moment, I’m not actively looking to learn to play the guitar. However, I’ve watched Brian’s path since buying a guitar two years ago. Since the purchase, Brian tried various books and practice exercises, but GuitarBots was the first time that he practiced consistently.

Some of the motivating and helpful features Brian mentioned:

  • Self-Directed Learning: GuitarBots lets him decide whether to push himself with new songs, or perfect a song he’s already learned.
  • Competition: GuitarBots shows how Brian is doing in comparison to his friends. 
  • Scaffolding: GuitarBots provides guidance for new techniques and feedback on areas where he is having difficulty. Additionally, if he’s having difficulty with a song, he can slow it down and then build it back up again until he is able to play at full speed.

These are all great for encouraging practice – and techniques that are often utilized in games and learning. In the end, though, what makes this game so strong in my eyes is that it creates an experience where learners are engaging in real world practice, versus something similar. Creating these types of authentic experiences – instead of “near authentic” experiences – is HARD, and understandably not yet done much on the computer. Here a key was utilizing the microphone as an input device, instead of depending on the usual mouse clicks, finger taps, key presses, or toy guitars.

The next post also features a game with a novel input device, this time a biofeedback sensor. More tomorrow!

This part of a multi-part post about games that require you to do exactly what you’re learning to do. Previous posts: