PokerMath

The problem

Plenty of people have taken an introductory statistics course and met expected value and probability through coins, dice and urns. Few of them ever see the same ideas deciding a real choice. The knowledge stays abstract because it never has to do any work.

PokerMath was my term project for a graduate HCI course on digital systems for learning. The brief was to design, build and evaluate a learning system around a small set of objectives. I chose poker as the context because it closes that transfer gap: the math decides real decisions, a wrong answer has a visible cost, and most people already know the surface of the game.

The audience was adults with some probability background and a passing familiarity with Texas Hold ’Em. People looking for poker strategy training were explicitly out of scope.

Three objectives, in a fixed order

The course required each learning objective to map to a level of Bloom’s taxonomy. I kept the syllabus to three, each depending on the one before:

The third objective sits a level higher and can’t be performed without the first two, so the lesson runs in a straight line. Learners can still jump anywhere from the sidebar, and they’re never blocked from moving on.

Explain it before you name it

The Rule of 2-and-4 is a shortcut: multiply your outs by 4 with two cards to come, or by 2 with one. Taught on its own, it becomes a memorised trick that falls apart on the first unusual hand. So the equity lesson works the exact probability out first, from the addition law, and only then names the rule as a fast approximation of the number the learner has just seen derived.

Every lesson follows the same pattern: a worked example placed beside the cards it refers to, so the learner reads and counts in one place instead of looking back and forth.

Compute, don’t recognise

Each objective ends with an assessment where the learner types the answer in. There is no multiple choice to guess from. Retrieval and calculation are the skills being taught, so they are what the assessment asks for.

When an answer is wrong, the feedback doesn’t simply say so. A hint engine compares the inputs against the common mistakes for that objective (miscounting outs, using ×2 when two streets remain, leaving your own call out of the pot-odds denominator) and responds to the likely error. Each further miss moves one step down a ladder of hints, from a nudge about the concept to the specific step that was missed. It never shows the answer, which keeps the learner working the problem.

Getting the tolerance right mattered more than I expected. The equity field accepts answers within 3 percentage points, while outs, streets and the pot-odds ratio must be exact. The Rule of 2-and-4 is an approximation by definition, so grading it to the exact figure would mark a correct method wrong and teach learners that the shortcut can’t be trusted.

The climax is a decision

The final assessment brings everything together. The same hand from the equity lesson returns with a bet in front of it. The learner works out their equity and the pot odds, then commits to calling or folding. This is the one point in the system where the math becomes a choice, which is the transfer the whole project was built around.

A calm table

The visual direction is a study tool rather than a game: a deep felt-green work surface, a light sidebar for navigation, a serif for headings and one gold accent kept for the next step. There are no badges, streaks, lives or celebratory animation. I left those out deliberately. Gamified extras add load the lesson doesn’t need, and the motivation I wanted came from the task itself: seeing that a wrong number would have cost money.

The cards use a four-colour deck (red hearts, blue diamonds, green clubs, black spades). Suit is always shown by symbol as well as colour, so nobody depends on colour alone, and the distinct colours make counting the cards of one suit for a flush draw noticeably faster.

Measuring learning

A learning system has to be judged on whether people learn from it. I built the measurement into the product: an optional six-question pre-test and an identical post-test bookending the lesson, two questions per objective, so one lucky guess can’t inflate the result for an objective. The wrong answers are written to catch specific known mistakes, such as using the pot before the bet in the ratio. The app scores both tests, shows the gain for each objective and exports the answers as CSV for analysis. The analysis plan is a paired-samples t-test with effect sizes, and the participant study is the next step.

Building it

PokerMath is a static Svelte and TypeScript app with no accounts, no persistence and no analytics. It’s designed for a single 15–30 minute session, and state clears on reload. The validation rules, hint selection and quiz scoring are pure functions with unit tests. Keyboard operation, visible focus and reduced motion were in the baseline from the first build.

Reflection

Two things stayed with me. The first is that each detail of the feedback design reflects a view of how people learn: the tolerance band, the order of hints, the decision not to reveal answers. Getting those right took more thought than any of the screens. The second is about what I’d change next. The integration step is the hardest by design. I’d give it its own bridging exercise between pot odds and the final decision, and I’d add a drill mode with generated hands, so learners practise across varied situations instead of one fixed scenario.

Try PokerMath