Two dice: which total comes up most often?

Learning goal. Students can explain why 7 is the most likely total when two fair dice are rolled: it can be made in 6 of the 36 equally likely ways. They can explain why totals near 7 are more likely than 2 or 12. They also know that a few rolls can give a misleading picture, while the share of each total settles towards the exact chance over many rolls.

Who uses it. Year 7–9 students in pairs, one device per pair, in a 20–25 minute lesson segment after single-event probability has been taught. The teacher leads the debrief at the end.

The learning move. Guided inquiry. Students predict first, run the simulation and compare with their prediction, check the exact chances, then explain. The teacher debriefs afterwards.

How students reach it. One .html file, opened in a web browser on the student's device. There is no login and no account, and it needs no internet. Publishing it as a link is a stretch (card 17).

Must do.

• Require a locked-in prediction before any roll.
• Offer Roll 1, 10, 100 and 1,000.
• Show a live bar chart of the totals, with the count and share of each total written as text.
• Mark the predicted total in words.
• After at least 100 rolls, reveal the exact chances and a 6 × 6 grid of all outcomes. Show each chance as ways out of 36 with a rounded percentage, e.g. "6/36 (16.7%)", say that percentages are rounded, and give the expected count for the student's rolls.
• After at least 1,000 rolls, ask one explain question with feedback that explains. Show the student's earlier prediction and reason beside it.
• Use a fair random-number generator.
• Work with the keyboard alone and at phone width.

Must never do.

• Let students roll before predicting.
• Show the answer before any rolls.
• Add sliders or extra variables.
• Animate dice or flash anything.
• Use a biased random-number generator.
• Use colour as the only signal.
• Save or send anything, or call an AI.

Acceptance criteria.

1. The exact chances match a full count of all 36 outcomes.
2. The dice are fair: 100,000 of the page's own rolls pass a chi-square goodness-of-fit test.
3. Rolling is impossible until a prediction is locked in.
4. The counts always add up to the number of rolls, and every share is correct.
5. It works with the keyboard only, at 320 px, at 4.5:1 contrast, with no network requests.

Test cases (written before building).

Non-goals. No biased dice, three dice or other dice shapes (see Remix ideas). No game or score. It does not replace the teacher's explanation of sample spaces. Students' predictions are not recorded.

Teacher's debrief script (after the explain question).

1. "Who predicted 7? Who predicted something else, and why?"
2. "Why do (3, 4) and (4, 3) count as two different ways?" Picture a red die and a blue die. Counting each pair once gives only 21 outcomes, and they are not equally likely.
3. "After 10 rolls, did everyone's chart look the same? After 1,000?"

Reuse plan (checklist item 11). Two weeks later, open it again and roll only 10 times: "Why is this chart not trustworthy yet?"

Check of learning (checklist item 12). Exit question a week later, without the tool: "With two four-sided dice (1–4), which total is most likely, and why?" Answer: 5, which can be made 4 ways out of 16.

Copy this, fill in the five [YOUR CLASS: …] gaps with your partner, then give it to your AI tool with the .html file.

Learning goal. [YOUR CLASS: in one sentence, what should your students be able to explain after using this?]

Who uses it. [YOUR CLASS: year group, pairs or individuals, and when in the lesson]

The learning move. Guided inquiry: predict first, run the simulation, compare, check the exact chances, then explain. The teacher debriefs afterwards.

How students reach it. One .html file, opened in a web browser. No login, no account, no internet needed.

Must do. A prediction is required before rolling. Roll 1, 10, 100 and 1,000. The bar chart also shows counts and shares as text, and the prediction is marked in words. The exact chances (as ways out of the total, with rounded percentages) and the grid of outcomes appear only after 100 rolls; the explain question only after 1,000, beside the student's earlier reason. One explain question with feedback that explains. A fair random-number generator. Keyboard and phone width must work. [YOUR CLASS: the one thing you want to change, e.g. the explain question, the dice, or the wording for your students]

Must never do. Rolling before predicting; answers before rolls; sliders or extra variables; animation or flashing; colour as the only signal; saving or sending anything; calling an AI.

Acceptance criteria.

1. [YOUR CLASS: how will you check the exact chances by hand? For example, list every outcome in a grid and count them.]
2. The dice look fair: roll 1,000 at a time a few times, and check that each total's share gets close to its exact chance.
3. Rolling is blocked until a prediction is locked in.
4. The counts add up to the number of rolls.
5. Keyboard, 320 px and contrast all work; no network requests.

Test cases. Keep T1–T6 and T8 above. Rewrite T7 for your version: "The exact chances are ___ (worked out by hand), and the page shows ___."

Debrief questions. [YOUR CLASS: the 2–3 questions you will ask the class afterwards]

• An automated browser test ran every test case above at 320 px wide, using the keyboard only. All passed. Being random, the counts differ on every run.
• The exact chances were counted from all 36 outcomes, and each one on the page was compared with that count.
• The page's own dice were rolled 100,000 times, and the totals passed the chi-square test in T8. The dice code was also tested on its own: 100,000 single rolls, and 100,000 two-dice totals.
• Accessibility: text contrast at least 4.5:1, a visible focus outline at every Tab stop, controls at least 24 × 24 px, no sideways scroll at 320 px, nothing moves by itself, and no issues found by the axe-core accessibility checker. Every bar has its count and share as text in a real table.
• The page made no network requests and stored nothing.
• Not tested: real screen readers, Safari and Firefox, or real phones. Try it on a class device before you use it.

What went wrong in testing, and the fix

• Unreadable bars on a phone, found by looking at a screenshot rather than by an automated check. At 320 px each bar was about 12 px wide. Fix: on narrow screens each bar gets its own full-width line, with its numbers underneath.
• A misleading prompt nearly shipped: "compare your bars with the expected column: are they closer after 1,000 rolls?" The gaps between counts and expected counts usually grow with more rolls; only the shares get closer. The prompt now compares shares with chances only.
• The explain question gave the answer away. It asked "Why does a total of 7 come up more often than any other total?", which can contradict a student's own results. It now asks a neutral question in step 4, which opens once the student has rolled 1,000 times; step 3, the exact chances, opens at 100 rolls.

The teacher's build checklist (12 points)

1. "Change the dice to two four-sided dice (1–4). Update the totals, the exact chances and the grid to match, and keep everything else the same. Show me how to check the new chances by hand."
2. "Replace the explain question with this one: [your question], with three options and a note on each wrong option. Change nothing else."
3. "Change the unlocks from 100 and 1,000 rolls to 50 and 500, and the wording for Year 7 students who are new to probability. Change nothing else."