Gerald Ajam

Interactive learning experiences

Most things described as interactive are merely responsive. The system does something when you click. Whether you had to think in order to decide what to click is a separate question, and it is the only one that matters.

Status Position

Published August 2026Revised September 2026

All work

Why it matters

Interactivity is the easiest quality to claim and the hardest to earn. Any interface responds to input, so any interface can be described as interactive without the description being false. This makes the word almost useless as a design target, and it lets a great deal of clicking pass as engagement.

The useful distinction is about what the learner has to generate. Choosing between options that have been laid out for you is a different cognitive act from constructing an explanation, predicting an outcome, or deciding what is worth attending to. Systems that ask for the second kind produce more durable understanding, and they are considerably harder to build.

What I have come to believe

Feedback should tell you what happened, not whether you were right. A simulation that responds with the consequence of your action leaves the interpretation to you, which is where the learning is. A system that responds with a correctness verdict has done the interpreting on your behalf, and has quietly converted a reasoning task into a guessing task.

Timing matters more than richness. Immediate feedback is right when someone is building a basic skill and errors would otherwise be practised into permanence. Delayed feedback is right when someone is building judgement, because the pause forces retrieval and commitment. Systems that default to instant correction everywhere are optimising for the feeling of progress.

Struggle is often the mechanism rather than an obstacle to it. Letting learners attempt something before instruction, and get it wrong in structured ways, prepares them to understand the explanation when it comes. This is uncomfortable to design for, because a well-run version looks like failure while it is happening and only pays out afterwards.

And a system should make its own model visible. If a learner cannot form a theory about how the thing works, they will resort to trial and error, which produces a score rather than an explanation.

How I approach it

I look for the moment where the learner has to commit — a prediction, a placement, a claim they can be wrong about. If there is no such moment, the experience is a demonstration with buttons, and it should be evaluated as a demonstration.

Then I read what the system says back. If the reply is a verdict, I ask whether a consequence would teach more. If the model behind the system is hidden, I look for a way to let the learner see enough of it to reason with.

In short

The position in five claims

The argument above, cut down to what travels.

  • 01

    Responding is the easy part

    Any interface reacts to a click. The design question is whether the learner had to think to decide what to click.

  • 02

    Feedback shows consequences

    Showing what happened leaves the interpretation to the learner. A verdict does the interpreting for them.

  • 03

    Timing follows the goal

    Immediate feedback suits basic skills, where errors would be practised in. Delay suits judgement, because the pause forces retrieval and commitment.

  • 04

    Struggle can be the mechanism

    An attempt before instruction, wrong in structured ways, prepares the learner to understand the explanation when it arrives.

  • 05

    The model should be visible

    A learner who can form a theory of how the system works reasons with it. One who cannot will guess, and guessing produces a score.

In practice

The questions I ask

Before designing anything in this domain, and again when something is not working.

  1. Where does the learner have to commit to something they could be wrong about?
  2. What does the learner generate, and what do they only select?
  3. Does the feedback report a consequence or a verdict?
  4. Is the feedback timed for building a skill or for building judgement?
  5. Can the learner see enough of the system to form a theory of it?
  6. What would a learner gaming this look like in the data, and could we tell?

Count the moments where a learner can be wrong. That number says more about an interactive experience than any count of clicks.

Unsettled

What I would still argue about

The honest list. These are open in my own head, not rhetorical.

  • How much guidance to remove, and when. Too little produces flailing, too much produces compliance, and the boundary appears to move with prior knowledge in ways that are hard to detect while designing.
  • Whether the productive kind of struggle survives contact with assessment pressure, or whether it only works where the stakes are low enough to permit failure.
  • How to tell, from interaction data alone, the difference between a learner reasoning carefully and a learner who has found an efficient exploit.
Singapore