📐 Design Memos

Why Wiz Kids works the way it does — each decision traced back to the research that forced it.

• Design memo: why we sign children out after 45 idle minutes
  A stale session on a shared classroom computer is an open door with a child's name on it. The incident that shaped the feature, the design details, and how the mechanic became a lesson.
• Design memo: why our consent gates are playable
  We built the ad industry's dark patterns — the glitter button, the settings maze, the nagging re-ask — into a children's product on purpose. The inoculation reasoning, the escalation design, and the line we drew.
• Design memo: why everything is wizards
  The pedagogical case for running a computer-skills curriculum inside a fiction — what narrative buys (names, reasons, emotional reframes), what it risks (seductive details), and the rules that keep the wizards working.
• Design memo: why our streaks forgive
  We drafted a loss-framed streak, ran it against our own dark-pattern test, and killed it. The redesign: celebration without hostage-taking, and what the fiction says on a missed day (nothing).
• Design memo: why the demo is free, full, and login-less
  Anyone can play real Wiz Kids lessons with no account, no email, no trial clock. The procurement argument, the zero-PII consistency argument, what it costs us (scrapers included), and the line we drew anyway.
• Design memo: why Wiz Kids requires a real keyboard
  The cockpit check gates on a physical keyboard, and touch devices get a limited away mode — the equity-flavored objections we weighed, the capability-not-device principle, and why we held the line.
• Design memo: why there are no leaderboards
  Leaderboards are the most-requested gamification feature and the best-evidenced way to harm the bottom half of a class — the research that made this a permanent no, and what we built instead.
• Design memo: why tasks have par instead of timers
  Every Wiz Kids task scores efficiency against a par — moves, blocks, edits — never against a clock. The decision, the evidence against speed pressure, and how we keep par honest (BFS-proven where we can).
• Design memo: why students sign in with picture sequences
  No child should need a text password before they can type — the developmental, security, and privacy reasoning behind picture-secret authentication, and what it deliberately teaches about secrets.
• Design memo: why our reviews never show their own answers
  We shipped review tasks that displayed the keyboard shortcut being reviewed — and the research says that quietly deleted the review. The audit, the rule, and the recall mode that came out of it.
• Design memo: why we simulate apps instead of using real ones
  Every Wiz Kids task runs in a working simulation — a fake browser, fake inbox, fake explorer. The pedagogy, safety, and assessment reasons, and the honest costs of the choice.
• Design memo: why Wiz Kids collects no personal data at all
  The decision to run a children's product with zero PII — what it cost us in features and convenience, the objections we raised against ourselves, and why 'we can't leak it' won.

© Glu IO Pty. Ltd. — Wiz Kids (wiz.kids). Link freely; republication requires permission — see terms. Found an error in our reading of the research? We correct fast: tell any teacher piloting Wiz Kids.