Designing a Learning-Before-Access Product: Prototype the Exceptions First
A product that asks someone to complete a learning activity before getting internet access has two jobs: make the rule understandable, and handle the moments when following that rule is unreasonable or impossible. A polished quiz screen solves neither on its own. For makers exploring this category, the most useful first prototype is a map of exceptions—not a reward animation.
Our new experiment WonderFi—which shares ownership with MakerPad—explores short learning activities before Wi-Fi access, making it a useful starting point for discussing product rules, exceptions and unanswered validation questions rather than proven educational outcomes. The model below is proposed design guidance, not a description or audit of that product’s implementation.
Start with a hypothesis you can actually test
Replace “this will make children learn more” with a narrower statement: “A child and parent can understand the agreed access rule, recognize when it applies, and recover when the activity or connection fails.” That is still a hypothesis, but a prototype can expose misunderstandings without pretending to measure learning.
Keep three questions separate. Can someone complete the flow? Can they explain the rule in their own words? Does using the product improve learning over time? Completion does not establish comprehension, and neither establishes educational benefit. The last question needs a separate evidence plan with suitable measures and attention to alternative explanations.
Write down non-goals too. An access gate is not a content-safety system, a substitute for parenting, or control over cellular connections and other Wi-Fi networks. Defining those limits early prevents an attractive interface from promising more than the underlying product can deliver.
Prototype the states, not just the screens
Make a paper or clickable prototype with the following states. The table is a starting specification; it does not imply any particular networking architecture or technology stack. Each transition needs an understandable next action and a recovery owner.
| State and trigger | Message or action | Recovery owner | Minimum information |
|---|---|---|---|
| Needs access: a session begins | Explain the current rule and show help | Parent can review the rule | Applicable rule |
| Activity offered: child chooses to continue | Show the task, instructions and an alternative | Child can ask for help | Current activity |
| Struggling: answer is not accepted | Preserve the answer; offer a useful explanation | Child or supporting adult | Temporary response state |
| Help requested | Say what happens next without promising an instant response | Available parent or carer | Help request, not a full answer history |
| Access granted | Explain when access ends and how to review the rule | Parent can change the agreement | Grant and expiry |
| Grant expired | Explain the change without surprise or shame | Child can find help or an exception | Current access state |
| Schoolwork exception requested | Offer a clear parent-controlled path independent of quiz success | Parent or carer | Exception scope and duration |
| Offline or service failure | Identify a service problem, not an incorrect answer | Adult recovery route | Transient error state |
Walk every arrow twice: once with an attentive adult available, once without. What if the parent’s device is unavailable? What if the request succeeds but the confirmation is lost? What if the child refreshes while waiting? The prototype should make these decisions visible before implementation turns accidental behavior into policy.
Treat exceptions as core functionality
School access should not depend on winning a challenge. Specify how an adult can authorize essential access and how the family recovers if the service is unavailable. Do not merely place an “ask a parent” button on a screen: define who receives the request, what the child sees while waiting, and what happens if nobody responds.
Offer an alternative when an activity is inaccessible, instructions are unclear, or a child needs assistance. A wrong answer, an empty required field and a server error are different events. They should not all produce “try harder.” Preserve effort where possible, explain the next step, and avoid taking away already completed work because a request timed out.
Reward mechanics also deserve scrutiny. Avoid shame-based copy, escalating streak pressure and unlimited loops that treat more interaction as success. The UK Information Commissioner’s Office discusses potential detriment from data use, including reward and engagement techniques, in its Children’s Code guidance on detrimental use of data. That is a reason to assess a design carefully—not evidence that this product category necessarily helps or harms children.
Make the family’s settings legible and reversible
Before saving a parent-selected rule, show a plain-language summary: what activity is requested, what access is offered, when the rule applies, what limits exist and how schoolwork is handled. If an exchange involves time, show both sides explicitly rather than hiding the duration in a tooltip.
The GOV.UK check-answers pattern offers a useful general model: let people review information and change the relevant answer before submission. Transfer that pattern to parent setup thoughtfully. It is not child-specific research and does not mean every exercise needs an extra confirmation screen.
Test edits as well as initial setup. If a parent shortens an allowance during an active session, does the change apply now or next time? Is that consequence shown before saving? Can they undo an accidental change? “Settings saved” is not enough when the real question is “what happens to the current session?” Record an explicit rule for each case.
Minimize data before adding personalization
Use synthetic people and answers in mockups. Before requesting real data, create a purpose-and-retention worksheet. A prototype does not need a child’s full name, school or permanent response history simply because those fields are easy to add.
| Proposed data | Question to answer | Design decision to record |
|---|---|---|
| Current answer | Is it needed beyond feedback? | Keep transient unless a justified purpose requires more |
| Access grant | Which fields are essential to operate the rule? | Limit scope and define deletion timing |
| Help request | Can help work without storing answer content? | Separate notification from response history |
| Optional analytics | Can a less detailed measure answer the research question? | Separate optional collection from essential operation |
| Personalization history | What specific benefit justifies retention? | Document recipients, retention and removal before collection |
The ICO’s data-minimisation guidance calls for collecting and retaining only the minimum personal data needed for the service elements a child actively uses. This is UK guidance; assess applicable laws and obligations in each market rather than presenting the worksheet as legal compliance. If an external AI service processes answers, identify what is sent, who receives it and what retention applies before enabling that feature.
Data minimization does not replace access control. When a prototype becomes a multi-user app, use checks such as MakerPad’s two-user data test where relevant to the chosen stack. That implementation article is not evidence that any example discussed here uses Supabase.
Validate comprehension and recovery before outcomes
Begin with expert and adult walkthroughs using synthetic scenarios: an unclear question, a wrong answer, schoolwork due soon, an unavailable parent and a lost connection. Ask participants to explain what the interface says will happen. Record ambiguous wording and failed recovery paths, not just whether a task eventually finished.
Research involving children needs an appropriately designed consent and assent process, safeguarding, privacy protection and the ability to stop without penalty. Adult walkthroughs cannot substitute for child usability research, but they can remove obvious problems before involving children. Avoid putting essential school access at risk for a prototype study.
Useful early measures include whether the rule can be explained, whether help can be found, whether input survives a recoverable failure and whether an alternative works for someone excluded by the default activity. Do not turn completion rate, conversion or time spent into a claim of educational efficacy.
A release acceptance sheet
Leave these items unchecked until there is actual evidence, with a test date, reviewer and unresolved issue beside each:
- The child-facing rule is understandable without reading parent settings.
- Schoolwork and accessibility exceptions have usable recovery paths.
- Wrong answers and service failures produce distinct, useful feedback.
- Changing a rule explains its effect on an active session and permits recovery from mistakes.
- Each retained data field has a defined purpose, recipient and retention decision.
- Optional collection is distinguished from essential operation.
- The team can state what the prototype has demonstrated—and what remains untested.
A good prototype does not prove the concept by concealing awkward cases. It makes those cases easy to inspect, challenge and improve before a family has to depend on the result.