A bias is a design brief

The situation

Two hundred named biases is a long list, and a team that reads it comes away with roughly two responses. One is to be more careful. The other is to add a warning. Both put the fix inside the head of the person the bias is acting on, and the record on that is bad. People who sit through an overconfidence demonstration leave as confident as they arrived. Markers who accept that marking bias exists doubt it in their own marking. Telling a learner that rereading feels better than it works changes nothing about what they do on Sunday night.

Meanwhile the product is making those decisions for them, screen by screen. What a learner sees first. What a dashboard sorts by. Whether the answer is revealed before the attempt or after it. What the default notification is, and what the streak counter rewards. Each of those is a condition, and each condition either presents the case a bias fires in or removes it. Most were set by whoever built the screen, for reasons that had nothing to do with either.

I have set them that way myself. The default that flattered the engagement number went in without anyone asking what it would teach.

The question

What if every entry in a bias catalogue were read as the description of a condition rather than of a fault in a person? A bias is a rule that earns its keep most of the time and fails in a describable set of cases. The describable set is the useful part. If the failure cases can be described, the product can be built to stop presenting them, and nobody has to be clever at three in the afternoon with thirty tabs open.

That is a stronger claim than it sounds. It says the people with the most leverage over bias in learning are the ones setting the defaults. It also says that awareness training aimed at teachers and learners is the least effective instrument, pointed at the least powerful people in the system.

The move

The biases run in two directions, and a team has to read for both. The first is the biases of the people using the product. The second is the biases of the people building and buying it. The same move applies to both: name the condition, change it, and never rely on anyone noticing.

On the learner side the conditions are mostly about order and default. Attempt before reveal: an item that shows the answer first has removed the step that produces retention, so the input box goes before the reveal, with no path around it. Confidence as data rather than placement: a self-rating at onboarding is paired with a short diagnostic, and the diagnostic sets the level. Explanation before recognition: a free-text account of how the thing works, asked before any multiple-choice item, replaces the fluent feeling of having watched a video with evidence. And the incentive review that gamification usually skips. Points attach to inputs a learner controls, they stay off the activities that already carry their own reward, and the withdrawal is measured a term after the campaign ends.

Teacher-facing surfaces have their own set. Judgement before score, on anything automated: the teacher enters their own reading before the model’s is shown, and disagreement is one click and logged as data rather than justified as an exception. A dashboard that ranks by activity promotes whoever is already loudest, so the quiet non-participator surfaces by default. A red-dominant progress screen trains everyone to see only deficits, so mastered material gets the same visual weight as errors.

On the building side the conditions are about process, and they are cheaper. Write the success measure and the failure threshold before the pilot opens. Run the pilot past the novelty window and report the last weeks separately from the first. Score a tool on evidence about the tool, and keep provenance and the word innovative out of the rubric. Forecast the migration from the last three migrations rather than from the plan. Record at commissioning what evidence would justify retiring the item bank, so the two years spent authoring it cannot later become the argument for keeping it. Give every default a named owner and a review date.

None of these asks anyone to be less biased. Each removes the case in which the bias would have had something to act on.

What it produced

The first thing was a field guide, built because I could not hold two hundred entries in my head and did not trust a summary. Every entry got a section on what it means for learning and a section on what it means for a learning product, written as design implications with a surface named: a review queue, an item bank, a marking interface, a procurement rubric. The exercise was the point. Writing the edtech section for two hundred biases is what turned a reading list into a lens, and it showed how many entries share one counter.

The second was a question for design review that sits next to the one about effort. Where in this flow does the product rely on a person noticing something? Every place it does is a place the design has handed its job back to the user. Some of those are unavoidable. Most are a default nobody set on purpose.

The third was a change in how I hear a request for a warning, a tip or a training module. Each is an informational fix. It tells a careful person something true and asks them to go on being careful. I now ask what the structural version would be, and whether the reason it was not proposed is that it would cost the engagement number something.

The fourth was some humility about the catalogue itself. A good share of the best-known entries are smaller or shakier than their popular versions, and the newest, on automation and AI, have almost no replication record. A team that builds on the popular strength of a finding is showing a bias of its own. So the guide grades the evidence inside the entry rather than in an appendix, and says plainly where nothing reliable is available.