scenario html game mechanic

Decision swiper

A Tinder-style mechanic for rapid project management decisions - built to explore how choice architecture affects decision fatigue in learning scenarios.

type

Scenario

built with

Vanilla JS

play time

~3 min

L&D principle

Decision making

live experiment

scenario 1 of 5

swipe or tap

[ complete ]

3 / 5

decisions made correctly.
Read the theory to see why.

The swipe mechanic works because it collapses a complex decision into a binary one. Left or right. In or out. That constraint is not dumbing down the problem - it is forcing a priority signal that open-ended questions rarely produce.

When learners are given too many response options, they optimise for avoiding wrong answers rather than making genuine choices. Binary constraints surface real instincts.

In L&D terms this maps directly to scenario design. The best branching scenarios do not offer five nuanced options - they offer two real ones with genuine trade-offs. The drama lives in the trade-off, not the number of paths.

The Tinder reference is deliberate. People already know the gesture. Zero tutorial needed. That is a principle worth carrying into every interaction you design: borrowed interaction patterns eliminate the onboarding problem entirely.

Built entirely in vanilla JS with no framework or dependencies. Intentional - keeps it portable and embeddable in any authoring tool or LMS.

Card stack uses CSS transform with slight rotation on lower cards to create physical depth. No 3D rendering, no library - just two rotate() and scale() values.

Swipe direction is tracked via pointer events so it works identically on touch and mouse. The hint overlays appear based on drag distance, giving the learner feedback before they commit.

Scenario cards are data-driven - swap the array and you have a completely different experience. The mechanic and the content are fully decoupled, which is the right way to build reusable learning interactions.

Score is tracked per session. The completion state shows correct decisions out of total - giving learners a result without turning it into a high-stakes test.

Principle

Desirable difficulty

Constraining choices to binary options creates productive struggle. The decision is harder than it looks - and that friction is where the learning happens. Removing it in favour of multiple-choice removes the point.

Principle

Cognitive load management

Reducing interface complexity to a single gesture frees working memory for the actual decision content. The UX is serving the learning objective, not competing with it.

Principle

Familiarity as affordance

Borrowed interaction patterns eliminate the tutorial problem. If learners already know the gesture, onboarding cost is zero. Design for the interaction people already have, not the one you invented.