Earn the model before you use it

Tags: onboarding, personalisation, cold start

A personalised product is at its worst on first run — no history, no signal, recommendations built from nothing — and first run is exactly when a person decides whether to keep it. The usual repair is to ask them what they like. That is the wrong repair, and it fails in a predictable way.

People cannot describe their taste

Ask someone to tick the genres they enjoy and you get an answer, but not a useful one. People describe taste in the abstract badly: they tick what they think they like, what they would like to be seen liking, and whatever sounds reasonable in a list. Their actual behaviour — what they finish, what they abandon, what they rewatch — diverges from the form almost immediately.

So the form is expensive twice. It costs attention up front, at the moment the user has seen nothing in return, and it produces a signal that is worse than the one you could have collected by watching them react to something real.

React, don't describe

The fix is to collect preference as a response rather than a description. Show real examples and let people react — yes, no, not now — quickly enough that it reads as play rather than configuration.

Three things make that work:

• The examples are real. A reaction to an actual show, product or passage carries information a checkbox cannot, because it bundles everything the person would never have thought to name.
• It is fast. Seconds per item. The moment it feels like a survey, it is a survey, with a survey's completion rate.
• It stops early. The point is enough signal to be useful, not a complete profile. Ask for sixty seconds, not six minutes.

Show what it bought, immediately

This is the half that gets skipped, and it is the half that earns the second request.

The collection has to visibly pay before anything more is asked. The user reacted to twenty things; the next screen should be obviously shaped by those reactions, in a way they can see is theirs. If the output after onboarding looks like the output anyone would have got, the user has learned that the effort did nothing — and the next time the product asks them for signal, they will decline.

The bottom-left branch matters. If there is no playful way to collect signal, the honest fallback is not a form — it is a strong default and a product that learns from use without asking. A form is the worst of the three options, and it is the one most products choose.

Grounded in

WatchWorthy's onboarding is a fast, playful swipe — closer to Tinder than to a settings form — so the app earns its taste read before asking for anything.

The bet was that a decade of crowd votes could only feel personal if the app knew something about you, and that asking would kill it before it started. Roughly sixty seconds of reacting to real shows produced recommendations people trusted, and in early testing they settled on something to watch in minutes instead of scrolling across services. It paired that with a visible taste profile, so the payoff of the swiping was on screen rather than implied — which is the half that made people willing to keep telling it things.

Anti-patterns

• A preferences form as the first screen. Expensive, before any value, and it collects the least reliable signal available.
• Onboarding that feels like a survey. Too many items, too slow, too clearly for the product's benefit rather than the user's.
• Collecting signal and not showing its effect. The user cannot tell the effort mattered, so the next request is refused.
• Asking for what you already have. Making someone re-enter preferences the product could infer from an import or an account is a demonstration of not listening.
• No way to correct it later. Taste changes and first reactions are noisy; a profile the user cannot adjust becomes wrong and stays wrong.

The smallest version worth building

Fifteen real examples, one reaction each, under a minute. Then a first screen that is visibly different because of those answers, with one line saying so.

That is the whole mechanism. Everything after — refining the model from behaviour, letting people edit what it learned — builds on having earned the first read.

Related patterns

• Capability before the cursor — the other first-run problem: showing what the product does before it knows anything about who is using it.
• Make the score answerable — once the model has a read on someone, the recommendations it produces need to be open to question.
• The character is a state machine — onboarding is a sequence of states too, and "learning about you" is one worth showing.