Explain the role of example prompts in onboarding and their downside.

Zanele Buthelezi coaches a squad of thirty age-group triathletes. Between in-person sessions, her athletes use PaceForge, a chatbot that answers training questions on their phone. The first screen shows five example questions to tap.

How to answer this, stage by stage

Six stages, because the question is narrower than a full design case. Say each one out loud, in order.

Let's learn

What happens the first time a new athlete opens PaceForge and sees a blank message box with nothing in it?

Most people freeze, or close the app. That's why PaceForge, like most chat products, shows five example prompts on the first screen: "What should I eat before a long run?" "How do I taper before a race?" and three more like them. Tap one, and you're talking to the tool within two seconds.

For the first few weeks, this worked exactly as intended. New athletes tapped an example, got a good answer, and kept using the app. Usage climbed fast.

At its worst: a 41 percent survey of athletes said they genuinely didn't know PaceForge could help with things like altitude adjustment or coming back from an injury flare. Some of them asked Zanele those exact questions by text message instead, the same questions the chatbot could have answered in seconds.

What I would leave alone: for a brand-new athlete's very first message, a blank box really is worse than five examples. The fix isn't removing the examples, it's making sure they don't quietly become a ceiling.

The lesson: onboarding examples do two jobs at once, whether you plan for it or not. They get someone started, and they teach a boundary. If you only design for the first job, the second one happens anyway, just badly.

Now here is the same thing as a story

The short version above is the tradeoff, argued. This one is how Zanele actually noticed it.

Zanele can read a runner's stride off a phone video before the athlete even feels what's wrong. She's coached age-group triathletes for eleven years, and she signed her whole squad up for PaceForge the month it launched, mostly so she'd stop getting the same taper questions by text at 10pm.

A menu with five dishes on it reads as "this is what the kitchen makes," even when the kitchen makes forty things.

It worked. Athletes tapped one of the five prompts, got a good answer, and came back the next day. For a while, Zanele's phone got quieter.

Nobody decided to stop trying new questions. It just never occurred to most athletes that there was anything else to ask.

Then one of the other coaches on her team made an offhand remark during a staff meeting: "Have you noticed everyone asks it the exact same five things? It's like they don't know it does anything else."

Zanele pulled the chat logs that week. Seventy-four percent of every question, across thirty athletes and sixty days, was a close copy of one of the original five examples.

The top right corner is the real loss: questions PaceForge answers well, that almost nobody thought to ask.

We did not build a narrow product. We built a product that looked narrow, because the only five doors we ever showed anyone were the same five doors, month after month.

One error costs a person nothing. The other one costs the whole product its own range, silently.

The fix wasn't removing the five examples. Zanele's squad still needed a fast way to start a conversation. The fix was making sure the five stopped acting like a ceiling.

The second callout, one weird edge case, did more work than the other three combined.

Now the five examples rotate, one swaps out every few weeks, and one has always been something a little unusual, an altitude question, an injury-flare question, a mental-fatigue question. A single line under the five reads: "these are a start, ask anything training-related." Novel questions climbed from 6 percent to 22 percent of all traffic within a month.

I built the narrow five because it was fast to ship and easy to test. It took a colleague's offhand remark in a staff meeting, not a support ticket or a churn number, to notice that the product's actual range and the range athletes believed it had were two very different things.

PICK, in one screenNot a preference. PICK is what forces the tradeoff to name which error you're actually protecting against.

The recap, one line per letter: position is keep the examples, impact is a stalled first message versus months of unseen range, cost asymmetry is the narrow-example cost since it's invisible and it compounds, and kill criteria is watching whether rotation actually moves the novel-question share.

And if you want to be sure it really works, try it somewhere elseSame four letters, a washing-machine repair chat instead of a training app. This time the five examples hide a completely different capability.

Grzegorz Wilk repairs household appliances and uses FixLine, an AI chat assistant, to help diagnose faults before he drives out with parts. FixLine's first screen shows five example questions: a leaking door seal, a drum that won't spin, an error code, and two more like them.

Mapped onto PICK: position is keep the five examples, since a technician standing in someone's kitchen needs a fast answer, not a blank box. Impact is a technician typing a rare fault by hand, which costs thirty extra seconds, versus a technician who quietly stops trusting FixLine for anything beyond the five shown faults, which costs a wasted truck trip when the real issue turns out to be something FixLine could have flagged. Cost asymmetry favors the second one, it's the one nobody notices happening. Kill criteria: if truck trips for "no fault found" don't drop after adding a wider set of examples, the real problem is diagnostic accuracy, not the prompt list.

The second branch is where FixLine quietly earns or loses trust, a real fault the five examples never mentioned.

Swap the trigger and it still runs.
Speed: an interviewer caps you at sixty seconds. Say "keep the examples, rotate them, name the edge," and stop.
Cost: there's no budget to build a rotation system this quarter. Say so honestly, and start by manually swapping one example each month, since even a manual fix beats a static one.
The model gets better, for real: if PaceForge's answer quality improves across the board, that's still not a reason to leave the same five examples in place forever, a better model with a narrower perceived range is still a narrower product.

Where people run it wrong.
They treat example prompts as a one-time onboarding decision instead of a setting that needs revisiting.
They assume low usage of a feature means nobody wants it, when it might mean nobody knows it exists.
They remove example prompts entirely to fix anchoring, trading one real cost for a worse one.

How to use it live. When someone asks about example prompts, ask yourself one question first: what percentage of real queries still look like the original examples, months later. Say that number, real or estimated, before you say anything about design philosophy.

Flashcards (tap any card to flip it)

Check yourself Score: 0 / 0