Often we’re told, “Put this information into a course.” But what happens if we put the information into a job aid instead, and then design mini-scenarios that help learners use the job aid?

This approach not only keeps boring blather out of our elearning, it can also make our activities more memorable. Here’s how it could work.

Example

Let’s say we’re designing a course on needle safety for a hospital. A common approach would be to display some slides of information about dos and don’ts, and then to present a generic fact check, like, “What’s the best way to dispose of a used needle?”

Instead, we’ll plunge our learners directly into an activity that somewhat simulates real life and that includes real-life job aids. So here’s the first thing learners see in this module.

We’re tempting the learner to respond without thinking, but we’ve also given them access to more information. For example, the learner could click the first thumbnail to see the safety poster that appears in every examining room and that explains what to do with a needlestick injury.

But our sample learner thinks, “Everyone knows you pour Betadine on that kind of wound,” and they choose that without looking at any other information.

Here’s the feedback we give them.

The feedback describes the results of the learner’s choice, letting the learner conclude that they were wrong. It also includes a snippet of the safety poster, pointing out where the learner should have looked. The learner sees for themselves that they not only skipped a step, they also used the wrong washing method.

Why did we do this?

Even though the safety poster appears in every room, we suspect that people aren’t looking at it, because they’re making basic mistakes with needles. So our course not only corrects the common mistakes but repeatedly reminds learners of the job aids they should be using.

And, importantly, this approach lets us surprise learners with their own mistakes. If we first listed a bunch of rules, including “Wash needlestick injuries with soap and water,” the learner might be mildly surprised, thinking, “What, not Betadine?” But by letting the learner give Magda Hepatitis C, we’ve surprised them more vividly and, ideally, will help them remember their mistake the next time they accidentally jab themselves.

This is a very simple demonstration of how we can have learners practice using job aids. For more complex procedures, we could have learners refer to the job aid as they carry out each step, showing the results of each decision in a realistic way.

Upcoming webinar for Australasia

I’ll talk more about scenarios in a one-hour online presentation for the Elearning Network of Australasia. The event happens Tuesday, Oct. 18, at 10 AM Sydney time (convert to your local time). Join us in this Blackboard Collaborate room.

It’s easy and tempting to write activities that test whether learners know something. How can we make learners use their knowledge as well?

You might be familiar with Bloom’s Taxonomy. Its current form identifies six categories of intellectual performance, from remembering to creating.

To make the taxonomy easier to apply, I grabbed my Unsubtle Machete of Oversimplification and in a few whacks reduced the categories to just two:

• Know activities ask learners to retrieve and maybe categorize or explain information.
• Use activities ask learners to apply information to realistic situations.

Often, a “use” activity includes a test of whether the learner “knows” something — you get two activities in one!

Example

Your learners create widgets. To speak with their coworkers, they need to know some technical terms. One term is “transmogrification,” which means modifying a widget so it will work at high altitudes. What can we do to help learners master this term and the related concept?

Know activity: Drag the term to its definition — drag “transmogrify” to “modify a widget so it will function at high altitudes”

Use activity:

Your client wants to use their widget at 2800 meters above sea level. What modification do you need to make to the widget?

1. Transmogrify it
2. Redorbinate it
3. Neoplyordinize it
4. No modification needed

The “use” activity tests whether the learner can apply their knowledge of transmogrification in a realistic situation, not in an abstract definition activity. At the same time, it answers three “know” questions for us. It tells us whether the learner knows that:

• 2800 meters is officially “high altitude”
• You need to modify widgets for high altitudes
• The necessary modification is called “transmogrification”

Of course, if these bits of information are crucial or frequently misunderstood, we’ll want to have more questions or activities to reinforce them. Also, our feedback goes beyond “correct” or “incorrect” to show the consequences of the learner’s choice and reinforce stuff some more.

If you write strong “use” activities, you don’t need to write “know” fact checks at all.

More examples

There’s more discussion about this and lots of know-vs.-use examples starting on this page in the Elearning Blueprint. The pages will be public for the next couple of weeks, so feel free to check them out.

Have I been too brutal to Bloom? Our focus here is on corporate training, where the goal is usually immediate application in complex situations. I’m not convinced that we need to minutely examine whether our activity requires “analyzing” or “evaluating.” By simulating complex, real-world situations, we can’t help but cover several Bloom categories.

I’ve also seen Bloom interpreted as “Write learning objectives using terms like ‘define,’ ‘identify,’ and ‘compare,’” which tends to inspire abstract thought-juggling activities and not real-world applications. For a rant about objectives, see Why you want to focus on actions, not learning objectives.

Photo by SOGKnives

Branching scenarios can be a pain to design. Happily, you can use a simple tool called Twine to easily draft the scenario and produce it. In this post we’ll look at a scenario that I wrote to demonstrate Twine’s basic features and to make a point about teaching through stories.

In the scenario, you’re a journalist in a hurry to get to a hot story in Zekostan, and your “guide” can’t speak English or drive. You have to quickly learn the necessary Zeko terms to navigate the roads and respond to events along the way. The scenario was inspired by a language-learning activity designed by Kinection.

Try the activity, keeping in mind that it’s a casual, unfinished experiment. Then come back here for more about Twine and my design decisions.

Twine

Twine works in Windows and on the Mac, it’s free, and it publishes scenarios in easily customized, accessible HTML. It’s based on TiddlyWiki, a lightweight information management tool.

Each scene in a scenario is really a small record in a wiki database. The links you create determine the path that the learner takes through the records. Thanks, Steve Flowers, for pointing out Twine in the Articulate forum.

Here’s the flowchart view, which Twine automatically creates as you link your scenes (click for a bigger image):

Twine offers some advantages over other ways to write scenarios. You can:

• Quickly switch between flowchart view and story-editing mode
• Link scenes using simple text
• Add images and sound files and otherwise use HTML
• Export the story in text format for review and proofing
• Publish the finished story in HTML
• Use simple codes to keep track of variables or limit learners’ choices (not shown in the sample scenario)

Since Twine produces a standard web page, you could conceivably embed a Twine story in any elearning tool that lets you embed web pages and that doesn’t interfere with Javascript. It might also be mobile-friendly — at least, the sample scenario works on my iPhone.

Here’s the editing window for a scene. The “bookmark” tag means that this scene will appear as an option when users click the “Rewind” link to the left of the story.

Visual design

The default publishing styles might not work well for corporate audiences. For example, the default version of the sample scenario had white text on a black background. However, you can quickly change the style by creating a special passage in the story that contains CSS. You can then copy that passage into future stories.

With four lines of CSS, I changed the background, text, and link colors. Here’s how one much more customized Twine story looks:

A few drawbacks

I was very happy with how easy it was to write in Twine, especially compared to my usual approach involving a separate flowchart and script. There were just a few things that didn’t work super well:

• I put a few bookmarks in so you could see how the “rewind” function works. However, the feature displays the first few words of a scene instead of its (guaranteed unique) link text. In the sample story, the first few words are usually Ludo confirming or correcting your previous choice, so the feature doesn’t exactly shine this time.
• Your browser’s back button should take you to the previous scene, but in my tests it occasionally went back one scene further.
• The flowchart layout got bizarrely spread out about halfway through the story, and I had to manually drag scenes closer together. This might be related to the fact that Twine requires a more recent version of the Mac operating system than I have installed.
• If you want to track learners’ performance in the scenario, you could use variables, but I’m not sure how that would interface with an LMS.

Development time

I didn’t track my development time because it wouldn’t have been realistic — I was learning to use Twine while I wrote the scenario and was writing this blog post at the same time. I can say that the “production” phase takes literally 2 seconds: you click “Build Story” and an HTML file immediately appears.

So you might assume that producing a scenario in Twine takes this long:

• However long it takes you to write the story in text
• + Some time for creating any images and sound files and embedding them using HTML
• + Some time for tweaking the CSS to avoid the white-on-black theme (took me 20 minutes because I’m not fluent in CSS)
• + About 2 seconds to click “Build story”
• + Some time for quality checks (this goes quickly because it’s easy to find a particular scene in Twine’s flowchart view)

Teaching through a story

The sample activity is an attempt to show that we don’t have to front-load learners’ brains with vocabulary or other facts before the “practice activity.” Instead, we can plunge them, clueless, directly into an activity that exposes them to the new information in a way that helps them figure it out.

A traditional approach to this type of language activity would be to first tell learners how to say “left,” “right,” and similar words in Zeko. We might have a little drill or game to get them to recognize the words quickly, with “correct” and “incorrect” feedback. Then we’d use the journalist’s story as a practice activity.

What I’m suggesting instead is to skip the information and go straight to the story. Design the story so the learners can discover meanings on their own. Then provide a natural pause to review what they’ve learned and make sure they got it right.

But you can’t teach everything through a story!

Of course, it would be tedious to teach all the vocabulary of a language through branching scenarios.

In the Zeko sample, I’d pause the action where the story currently stops and include an optional game to reinforce the new words.

I’d then finish the story, probably including a scene in which you win an exclusive interview with the Minister of Science by correctly using Zeko to warn her away from some sort of danger.

Then I’d revert to “normal” instruction to more efficiently cover additional vocabulary and grammar for awhile. Another branching story would appear later, to both reinforce what has been covered so far and to introduce a handful of new terms or concepts. Maybe it would require learners to recognize the grammatical pattern of a phrase and build new phrases using the same pattern.

But it’s just text!

Yeah, it’s just text. I wanted to show you Twine’s default behavior. The sample scenario is an example of the quickest and cheapest way to generate scenarios with Twine. I added a sound clip and image just to see how easy it was (it was very easy).

While some designers shun text because they (incorrectly, in my view) think it’s boring, I think its greatest weakness in the sample scenario is that it teaches people to read Zeko, not to speak it or understand it when it’s spoken.

If I were serious about teaching language this way, I’d produce the dialog in audio only. It would probably be simplest to produce the narrative as audio as well and make each scene’s audio file play automatically when you land on the scene. Instead of displaying redundant text, I’d need to come up with visuals that support the story. That’s way more work than I wanted to do for a quick sample.

Soft skills might work better

I wrote a fake language story because that was the only way I could guarantee that none of you knew the answers and you would therefore experience being clueless in a scenario.

However, scenarios might be more suitable for teaching soft skills, such as having difficult conversations, overcoming buyers’ objections, and leading a team through change. Soft-skill materials don’t have as much information that requires memorization, and they have more grey areas to give the stories depth.

For a much deeper, more polished scenario that also plunges learners directly into a situation, see the Haji Kamal piece for soldiers in Afghanistan.

Possible advantages of this approach

By skipping the formal teaching and going straight to the story, we:

• Let learners who already know some Zeko skip explanations that they don’t need
• Encourage learners to build meaning from (somewhat) realistic experience and mistakes, mirroring how we learn in the real world
• Give learners a more challenging puzzle to solve than rote memorization
• Possibly improve recall by connecting facts to a story

Basically, we avoid making the material too easy and therefore forgettable.

But it’s not fair!

Some people argue against this approach because it increases the likelihood that learners will make an incorrect choice: “You’re setting them up for failure!”

But we’re not just throwing learners into the deep end. We’ve given them a life preserver by designing the story in a way that introduces new information a bit at a time.

The harshest choice in the story is the first choice between “left” and “right.” You have a 50% chance of getting it right. If you get it wrong, you learn “no” and you immediately get back on track. It isn’t likely to be a catastrophic experience.

Story characteristics

The sample story is just a lightweight tale that I outlined in five minutes. But it does include the characteristics that I recommend be included in real scenarios:

• A big goal with emotionally compelling consequences: you have to be first on site because you screwed up your previous assignment
• Minimal setup: four sentences establish the back story and the challenge
• Suffering: your guide doesn’t speak English; your competitor might be close behind
• Time pressure
• An increase in tension partway through the story: is that the Agence France-Presse car behind you?

What do you think? Have you had success with this “let them figure it out” approach to instruction? Are you eager to try out Twine? If you do try it, please consider sharing the stories you build so we can get ideas from each other.

P.S. I have nothing against Agence France-Presse.

You’re a US Army sergeant in Afghanistan. Can you help a young lieutenant overcome cultural differences and make a good impression on a Pashtun leader?

That’s the challenge behind “Connect with Haji Kamal,” a decision-making scenario that my cool client Kinection and I developed for the US Army. The online scenario is the homework part of a lesson plan that includes in-class discussion about how to build rapport across cultures. It’s part of a much larger effort in the Army to strengthen soldiers’ cross-cultural and peacekeeping skills.

Turn on your speakers and give it a spin, and then come back here if you’re interested in the design decisions behind the activity.

The goals

The activity is designed to be completed as homework before a culture class, and it includes a facilitator guide with debrief questions. Our goals were to model specific rapport-building behaviors and inspire class discussion.

To follow the “good” paths, you need to see things from Haji Kamal’s point of view, show respect and patience, and otherwise apply cross-cultural skills that will be discussed in class. You end up on less successful branches by making more ethnocentric choices.

Complex branching

Our original content was a short description of a real-life discussion between a soldier and Pashtun leader. We added enough twists to end up with 12 paths through the material, using a flowchart to keep track of everything.

The paths cross at several points, so usually one bad choice doesn’t doom you to a bad ending.

The debating squad leaders

The debate between two characters has its roots in classroom scenarios that we developed. During tests of those scenarios, we found that requiring participants to defend each option got them more deeply involved. The debate also simulates the kind of thinking that soldiers need to do in the field to challenge their cultural assumptions.

For this scenario, the debate also replicates real life — often a sergeant asks squad leaders for their ideas and then advises the lieutenant. To make the player think independently, we also included an undebated option.

To make sure the story and arguments were believable, we ran a classroom debate version of the scenario with a group from our target audience. We collected their arguments for each option and then wrote the script for the online version.

Minimal media

In focus groups about their training preferences, soldiers made clear that they prefer video. However, that wasn’t in our budget or timeline, so we went with the soldiers’ second best, graphic novel illustration. The images are comic-ified photos.

We used audio for the debating squad leaders because their arguments were core to the game. The lieutenant and Haji Kamal are limited to silent dialog bubbles mainly to avoid the challenge of providing audio for Haji Kamal, who in real life wouldn’t speak English. Our audience members are sticklers for authenticity, so the best solution would have been to have the Haji speak in Pashto and display his dialog bubble in English, but that would add a distracting layer of complexity.

We kept animation to a minimum for the same reason — we wanted players to focus on the ideas and story.

Experimental surprises

At two decision points, we tried different twists:

• Rogue lieutenant: At one point on a mediocre path, the LT ignores what you recommend (no matter what it is) and says his own line. Unfortunately, it’s not a good line. You have to do damage control to get back on a decent path — just like in real life.
• Defend your choice: At another point, the LT asks you why he should say what you’ve recommended. Pick a good defense, and you go down a good path. A weak defense sends you down a mediocre path. This adds a layer of complexity to the branching that could get seriously challenging for the designers and developers, but it could also be used to make players think more deeply about their choices and defend them in ways that are most persuasive to someone from the lieutenant’s background.

Learner feedback

The game and its accompanying facilitator guide were tested by soldiers in a culture class at Fort Huachuca NCOA. It looks like the activity met our goal of inspiring discussion: 70% of the players said that they were looking forward to discussing the game in class the next day, and instructors reported that the activity “prompted the majority of the discussion” and encouraged soldiers to share their own experiences.

The activity will be part of a larger toolkit for military educators. The toolkit includes more decision-making scenarios in several formats, all of them designed to help soldiers practice specific cross-cultural capabilities.

Design time required

A scenario of this length and complexity takes me about 20-40 hours to plot and write. That’s the time I need after the goals have been identified, we know what the learners need to do in the real world, we understand the mistakes they commonly make, and the SME has provided at least the germ of a realistic story. It doesn’t include project management time, audience testing, audio and graphics sourcing, Flash development, QA, etc., and it assumes that reviewers don’t make major changes.

That’s a lot more time than it would take to throw together a slideshow on “Key Concepts in Rapport Building: Afghanistan,” but we like to think the resulting activity is more memorable and more likely to change behavior.

In an ideal world, instructional designers could spend our limited time on immersive activities that have a big potential impact, and all those Flashified information dumps could instead be cheap PDFs or intranet pages.

What do you think? Have your say in the comments section.

When employees of the US Internal Revenue Service need to find out what taxpayers are doing, they look online. How would you train them to dig deep into the web without violating privacy laws?

David Anderson has linked to the script of an online course that the IRS uses to train its employees. It was released during a Freedom of Information Act case and posted by the Electronic Frontier Foundation (EFF). As David points out, the script uses the common tell-then-test approach.

What could they have done differently?

Here’s the script, thanks to the EFF. You’ll see that it’s clearly written and organized, which is great.

Like most elearning, it presents a lot of information and then quickly tests our understanding of that info. It also uses some interesting examples from real life.

The course is a perfectly capable information presentation. But since my tax dollars helped pay for it, I can’t help wishing they had done it differently. So let’s give the IRS some friendly suggestions.

What would happen if we changed the objectives?

The IRS course has these objectives:

• Identify internet research do’s and don’ts
• Identify how to locate relevant taxpayer information with internet searches
• Identify additional internet research tools

If you’ve spent more than 5 seconds with Action Mapping or the Elearning Blueprint, you’ll easily predict what I’m about to say. The objectives need describe action, not knowledge. Do we really want employees to passively “identify” what they should do, or do we want them to actually do it?

When we start out with “identify” objectives, our activities tend to become “identify” activities — typically, multiple-choice questions that ask learners to recognize something they just read. They test learners’ short-term memory, not their ability to use the new information on the job.

Imagine how the course might have turned out if all stakeholders had agreed to an objective like “Find accurate online information about a taxpayer without violating privacy laws.” The activities that would naturally flow from that objective would be realistic simulations of what the employees need to do each day on the job.

How could scenarios help?

The course hints at some interesting examples — a taxpayer reposted a web site he was supposed to have shut down, officers of a corporation were dodging responsibility for taxes, and a restaurant owner tried to hide online businesses. However, these are presented as isolated examples, usually after a presentation of more abstract information.

What if the IRS had elevated those examples to decision-making scenarios, and used them to replace the “knowledge check” mini-quizzes?

For example, instead of asking, “What is the best way to save multiple pages of a web site?” the designers could present a scenario in which an IRS employee has found a taxpayer’s illegal web site and wants to save it before the taxpayer can pull it offline. What should the employee do?

Ideally, the IRS would have a fake website to practice on, and the learner would actually go to that site and save its pages. But even a decision-making scenario in which the learner chooses actions for a fictional employee would be more effective than a basic knowledge check because it would more closely simulate what the learner does on the job.

What info should go in the course, and where?

The course includes lots of how-to information that would benefit from screen shots and explicit steps (“On the advanced search screen, enter the taxpayer’s name…”). There’s so much how-to info that learners might want to look it up again — which means that the procedures are probably better off in a job aid than the course.

I’d suggest offloading a lot of the how-to information to a few easily found pages on the intranet, and using the course to teach employees how to use those job aids.

Then, once they’ve put together the job aids, the designers could make the course seem more like a stream of interesting activities.

Instead of this:

They could do this:

Each activity could be a decision-making scenario based on a realistic case. The learners would use the job aids to complete the activities, which simulates what they’ll be doing on the job. Because this approach is more realistic and “applied,” it’s more likely to change real-world behavior.

What do you think?

Tell the IRS what to do! How do you think they should change their course to make it more memorable and more likely to affect behavior on the job?

Are you dreaming of an immersive simulation while your team members plan yet another Jeopardy game? If you want stakeholders to expand their horizons, a working prototype is your best friend.

A working prototype has simple placeholder graphics, but the clicking and dragging work as they will in the final activity. Build a quick-and-dirty version of the activity of your dreams, and use it to convert everyone on your team.

Here’s a two-part video that shows what I mean. Leif Cederblom of SmartBuilder compares two prototypes of the same activity and highlights the goals and benefits of prototyping.

Part 1: The conventional drag-and-drop: busywork that’s easy to forget

Part 2: A more realistic activity that’s more likely to change behavior

Try both prototypes yourself and see how the contrast between the two underscores the power of the more realistic activity. No amount of polish would make the drag-and-drop more than a rote activity, while the “leave the lab” prototype is effective even in its raw, prototype form.

For a quick overview of the Action Mapping process described in this interaction, see Be an elearning action hero. For in-depth help with applying this process to your own materials, check out the Elearning Blueprint.

How I designed and built the scenario

Some people avoid creating branching scenarios because they seem too complex. In case it’s helpful, here’s the approach I took.

I kept track of the branching by writing the dialog and results in an informal flowchart. I used OmniGraffle for the flowchart, but you could use any tool that builds basic flow charts or just draw one by hand. Click the image to see a larger version.

As I built the slides, I wrote the slide number by each node of the flowchart for future reference. Then I tested the interaction by following each branch of the flowchart, marking the path with a crayon so I could see at a glance which paths had been checked.

To produce the slides and SWF, I used Keynote 08 (not Keynote 09!). Keynote is a slide editor for the Mac. You could create the same interaction with PowerPoint and a conversion tool that supports branching.

The images of Allison used in the Flash come from one of several sets of fun stock photos designed for use in scenarios, available from ElearningArt.

The “order taker” meter is a static PNG in three versions (“order taker,” midpoint, and “instructional designer”). The learner’s path determines which of these graphics is displayed, just as the path determines which slide is displayed. There are no variables involved.

The scenario in this post is about as long as I’d want to build using a presentation tool like Keynote or PowerPoint. For longer or more complex branching, I’d look at a tool like SmartBuilder, which would let me put multiple results on one “slide” and would display a flowchart of the interaction.

What’s your favorite way to guide your client or to design a branched scenario? Please share your tips in the comments.

Seminars

Webinars to come: Starting in early 2010, I’ll offer some lively, interactive webinars. I’ll announce them in this blog and look forward to seeing your name pop up in the meeting chat some day soon. (To make sure you don’t miss an announcement, you might want to sign up to receive the blog as emails or in your feed reader.)

I’d like to meet you in Australia! I’ll give workshops on how to dump the drone at a series of events organized by the Australian Flexible Learning Framework. The schedule:

Nov. 10: Darwin
Nov. 12-13: Adelaide
Nov. 18: Hobart
Nov. 20: Perth
Nov. 26-27: Brisbane
Dec. 3-4: Melbourne
Dec. 7-8: Sydney

You can find details about each conference here. The Knowledge Tree has published an audio interview with me about the main message of the workshops (basically, “No more information dumps!”).

Learning and Skills Group: I enjoyed giving an Action Mapping webinar for the UK Learning and Skills Group on Oct. 8. Thanks to all who participated for your great questions and comments!

Hooking learners with a simple story: Kevin Shadix describes why he uses a short story to motivate learners with a “teaser” scenario. He shows his scenario and asks, “Does a introductory story/scenario like this make you more likely to be interested? Or is it too goofy?” Stop by his blog and give him your feedback.

Your (teeny-tiny) brain on drugs: Join the Mouse Party to learn how drugs affect the brain. When you drag a drugged mouse to the x-ray-type machine, a narrator first explains what’s happening in the brain–and then text appears with the same info, reinforcing the narration. This seemed much more effective to me than simultaneous text and narration.

E-tired of e-hype? Reinvigorate your e-commitment to e-learning with this e-learning cheer!

Find out what 15 of your colleagues have to say about learning at work at the second Working/Learning blog carnival, hosted this time by Manish Mohan.

Marvel (or not!) at the advanced special effects used in the 1927 silent movie How to Use the Dial Telephone. See more old training movies at the Internet Archive.

What generation are you? This test uses your social media habits to determine your generation. (I’m Generation Y trapped in a Boomer body.)

Learn absolutely nothing from the PowerPoint presentation Chicken Chicken Chicken.

Can’t afford a full-fledged simulation? You can still recreate the learner’s world in your materials, even if your only tool is the lowly multiple-choice question.

Let’s say you’re writing materials for people who create custom pet hedgehogs using genetic engineering. You might be tempted to write a question like the one below.

It’s a good idea to include parrot genes in a custom hedgehog.

1. True
2. False (correct)

How could you make this question more realistically reflect the learner’s world?

First ask yourself, “Why does the learner need to know this fact?”

Then write a question that tests both the learner’s knowledge of the fact and their ability to apply it in the real world. “What if…” questions come in handy for this.

What would happen if you included parrot genes in a custom hedgehog?

1. The hedgehog would become depressed by its inability to fly.
2. The hedgehog would charm customers with its bright plumage.
3. The hedgehog would develop an offensive vocabulary.

The “before” question tests only basic knowledge. The “after” question tests the same basic knowledge and at the same time tests whether learners understand why the fact is important.

Of course, make sure your materials answer the question.

Obviously, the “after” question has more shades of meaning and suggests that the materials contain more information than simply, “It’s a bad idea to include parrot genes.”

I’m a big advocate of writing questions before you write the main materials. So if you want your low-tech materials to simulate real life, you might:

1. Write questions that learners must be able to answer in order to fully understand (not just perform) their jobs. These probably aren’t fact-based questions but instead are “What if” and “Why” questions.
2. Then write the materials that will precede the questions, assuming you’re doing the standard “tell, then test” approach. Also consider putting the questions first, then explaining why the correct answer is correct.

What are some other ways to give basic questions more depth? Are simple fact checks ever appropriate?