Megan Lancaster, PMP®

Interactivity Generator

An AI app that turns a learning goal into a hands-on activity, and speaks up when a request won’t help learners.
At a glance

I designed and built the Interactivity Generator for Duke’s Learning Experience Design team during a summer 2026 AI pilot. Powered by the Claude API, the app turns a designer’s description of what learners need to understand into a suggested activity, chosen from six activity types. Designers can try it out in a clickable preview, edit the wording without touching code, and export it for the Coursera plugin, with an accessible text version. I’m now using it to develop Year 2 of AI for Nurses, a four-course Specialization.

01 · The inspiration

Coursera needed an easier way to add hands-on practice

Since 2020, faculty have asked me some version of the same question: “Can Coursera do this?” They wanted a quick, interactive way for learners to check their understanding after a new idea, recall a set of terms, or put steps in order. Most of the time, my answer was “not yet.” Concepts that called for a little practice often ended up as static text or a built-in quiz instead.

“They wanted Parsons problems. They wanted a way to introduce people to code without dropping them into VS Code.”
A teammate at our first sprint review, recalling requests from a Python course

New to coding?Parsons problems ask learners to arrange provided pieces of code in the correct order, rather than write code from scratch.

The pilot gave me a chance to say, “Yes, we can do this.” I built two connected pieces: a Coursera plugin that displays a custom HTML activity inside a reading, and an AI app that helps a designer turn a learning goal into that activity in minutes.

The appTurns a learning goal into a working activitySections 02 to 05 ↓The pluginMakes that activity run inside a Coursera readingSection 06 ↓
02 · Try itThe app

Try the tool

Explore the working interface with six saved requests, including three where the app pushes back. This demo uses saved responses, so you don’t need an account.

Analyze the learning challenge, compare activity formats, edit the wording, and try the export.

03 · How it worksThe app

From a learning goal to a course activity

A fast, lower-cost model makes the first recommendation. Claude Sonnet, a more capable model, runs only after the designer chooses a format, keeping the AI cost to a few cents per activity.

  1. DescribeDesignerExplains the content and where learners struggle.
  2. RecommendClaude HaikuSuggests an activity format and explains why it fits.
  3. BuildClaude Sonnet + HaikuCreates a working preview and a plain-text version.
  4. RefineDesigner and facultyReviews and edits the wording without touching code.
  5. ExportReady for CourseraThe designer copies the activity into the course, along with its text version.
The designer stays in control, choosing, editing, and approving along the way. The app never adds anything to a course on its own, and every activity is ungraded practice.
04 · Inside the promptThe app

What went into the system prompt?

I wrote the instructions that guide how the app recommends and builds activities. This is called the system prompt. The excerpts below come from that prompt. You can explore them in a tabbed activity, one of the six formats the app can create.

Start with the learning goal
If the learning goal is recall or retention of terms/abbreviations → click-to-reveal
If the learning goal is understanding a process or sequence → sequencing
If the learning goal is categorization or applying a framework → drag-to-classify
Tabbed explorer vs. click-to-reveal: use tabs when comprehension and comparison is the goal; use click-to-reveal when recall is the goal

The why: The app recommends a format based on what learners need to do, not how the activity looks. The same content may call for a different format when the learning goal changes.

Less is more
Before deciding what to include in the interaction, decide what to leave out.
…
A tight interaction with 3 strong items is better than a sprawling one with 7 weak ones.

The why: Models tend to include everything they’re given. The activity sits inside a reading that already covers the topic, so its job is to light up one part of it well.

Guide, then build
  • Too vagueAsks one or two specific questions instead of guessing, but only when it truly can’t infer a topic and a learning goal.
  • Out of scopeNames the limit in plain language, then builds the closest format that serves the same goal, such as annotated code in place of a live coding environment.
  • Too much contentEach format has an item limit (5 tabs, 6 cards, 7 steps, 8 items to sort). Past that limit, the app explains that it would be too much for learners at once and suggests how to focus or split it, instead of building.
  • Weak fitWhen a designer picks a format that fights the content, the app still builds their choice and adds a short fit note naming a better option.
If the designer specifies structure (section headings, tab labels, item wording, ordering, number of parts), follow their specification. Their named headings are the headings; their items are the items.

The why: Every guardrail came from a test that went wrong. The designer’s choices still win, but the app says so when a choice will cost learners something.

Same format, easy edits
List EVERY learner-visible text string in the interaction, in document order…
Each "text" value must match its occurrence in the html field character-for-character.

The why: Every step returns its answer in the same fixed format, so the app can rely on it. This rule powers the no-code editor: the app finds and replaces each string exactly, so designers never touch HTML.

Fix it once, for everyone
Render ALL content elements directly in the HTML string… Interactions built this way cannot fail to render; interactions that build their content in JS frequently render as an empty box.

A selector mismatch is the most common cause of an interaction that renders but does not respond to clicks.

The why: When an output broke, I traced the cause and wrote the fix into the prompt as a rule. The fix then holds for every designer and every request, not just the one I was testing.

05 · Stress-testing the appThe app

What went wrong, and what I changed

I tested the app with real content from several Duke courses, including Python, ESG (environmental, social, and governance), and nursing. I also tried requests designed to push it beyond its limits. Building and testing everything below cost about $6 in API calls.

Scope:Knowing what not to build
  • A live Python coding environmentOur sponsor asked for a place where learners could write and run Python code.What went wrongThe app couldn’t build it and didn’t explain why.What I changedRequests outside the app’s scope now get a plain-language explanation and a suggestion for a supported activity that could serve the same learning goal, such as annotated code.
  • Twelve astrology houses as reveal cardsI deliberately asked for more content than would fit comfortably in one activity.What went wrongThe app tried to build it anyway.What I changedEach format now has an item limit. When a request exceeds it, the app explains why and suggests narrowing the focus or splitting the content into smaller activities instead of building it.
  • Vocabulary practice without a recall optionI expected the app to suggest click-to-reveal for vocabulary content.What went wrongThat format never appeared in the recommendations.What I changedThe app now shows all six formats, ranked by fit, with a note explaining each. I also added an “I know what I want” mode for experienced designers.
Reliability:Getting activities to work
  • Code sequencing with impossible stepsWhat went wrongSteps appeared in an order that wouldn’t work.What I changedThe prompt now instructs the model to establish the correct order first, for example, creating a variable before printing it. The activity uses a drag-into-place layout, with a click option for learners who can’t drag.
  • Activities that appeared blank or didn’t respond to clicksWhat went wrongThe generated code tried to find parts of the page before they existed.What I changedEvery build now follows two rules: include all activity content in the page from the start, and check that the code refers to the correct page elements.
  • The same prompts in a Claude ProjectWhat went wrongResults were rougher and less consistent than in the app.What I changedI kept the structured app. For these design tasks, a defined workflow proved more reliable than an open chat.
Ease of use:Making it work for the whole team
  • Using the largest model for every stepWhat went wrongThe app was slow, with no indication of progress.What I changedA fast model now handles recommendations, a mid-tier model builds the activities, and a progress bar shows that the app is working.
  • Asking designers to edit generated codeWhat went wrongEditing an activity required working in HTML, which not everyone on the team was comfortable doing.What I changedA simple text editor lets designers change every word learners see, while keeping the code available underneath.
06 · Making it workThe plugin

Making it work inside Coursera

The app is only useful if its activities work in a course. So I also built a custom Coursera plugin with a simple goal: upload the plugin once, then use it to display any activity the generator makes.

From the app to the course
  1. 1 · AppGenerate the activity.The app packages the activity’s HTML and script in a small configuration: { html, script }.
  2. 2 · DesignerCopy and paste.The designer pastes that output into Coursera’s configuration editor. No coding or external hosting is needed.
  3. 3 · PluginDisplay the activity.The plugin reads the configuration, displays the content, and runs the script.
  4. 4 · LearnersLet learners practice.Tabs, sorting, sequencing, and other activities appear directly in the course reading.
No external hostingNo coding for designersNo H5P license required (H5P is a common tool for building interactive content)
Behind the build

I started by exploring H5P to decide which features to borrow and which to leave out. Then I learned that Coursera supports custom plugins through its Plugin Manager. I tested the approach with a simple accordion plugin, then built the general-purpose HTML plugin and tested it with real content from several courses.

Limits for now
  • The plugin is added to each course separately, for now.
  • Branching scenarios will need a separate plugin.
  • Graded work stays in Coursera’s built-in assessments.
07 · Access

Building in accessibility

Every export comes with:

  • A standalone text version. All the content is available in plain text, written to make sense without the activity, with no instructions like “click the tabs to…”
  • Accessibility requirements for each activity. Every build is instructed to support keyboard navigation and meet WCAG 2.2 color contrast requirements.
  • Text for other Coursera tools. Coursera’s AI tools, Dialogue and Coach, can read the text version, even when they can’t read the interactive activity.

These are starting requirements, not a guarantee of full accessibility. Each activity still needs to be checked before it goes into a course.

← PreviousAI for NursesNext →Teachers as Engineers