Home / Writing

AI product

Designing an LLM Feature Users Actually Trust: Lessons From an ADHD Task Planner

By William Souef · 2026-10-13 · 7 min read

Rockie is a planner for people with ADHD who struggle to start tasks. Its core feature sounds simple: type an overwhelming goal, like "do my tax return", and get four to six small steps you can start right now. Getting a language model to produce a list is easy. Getting a list that feels reliable for every user, every time, took real product and architecture work.

Define the model's job narrowly

"Help with ADHD" is not a job a model can do well. "Turn this goal into four to six steps of two to five minutes, each with a visible result" is. The narrower the job, the easier it is to test and the more predictable the experience. Every time the feature drifted towards advice or motivation, quality dropped.

Design for users without the model

Rockie uses Apple's on-device foundation model, which keeps tasks private and costs nothing per request. But not every iPhone has Apple Intelligence. The first version had two very different experiences: a decent AI breakdown for some users and a generic five-line fallback for everyone else. That's a product problem, not a technical detail.

The fix was an architecture where the model is one engine among two:

• A local analyser runs for everyone. It detects the family of the task (tidying, paperwork, creative work…) and extracts its object, deterministically.
• Without Apple Intelligence, a hand-written bank of templates per task family produces the plan. Selection is based on a hash of the goal, so the same goal always gets the same plan: it never feels random.
• With Apple Intelligence, the model generates a typed, structured plan, anchored on the detected family and a few-shot example from the same bank.
• If the model's output is invalid, the app makes one targeted repair attempt, then falls back to templates.

The interface never knows which engine ran. Users just get a good plan.

One quality gate for every engine

Both engines pass through the same validation before anything reaches the screen:

• four to six steps, each two to five minutes long;
• each step starts with an action verb and ends in an observable result;
• no duplicates, no placeholders;
• the first step is deliberately easy, because starting is the whole point.

A shared gate turns "the AI is usually good" into a guarantee you can test. The rules are covered by unit tests, which means a prompt change can't silently make the experience worse.

Languages are engines, not translations

Rockie works in French, English, Spanish and Brazilian Portuguese. None of the pipeline can be translated: a keyword lexicon, a list of action verbs and a model instruction only make sense in their own language. So each language has its own hand-written templates and prompts, in its own register, and detection uses only the lexicon of the language the app is displayed in. Mixing them created false matches between languages.

Show the value before the paywall

The most convincing demo of an AI feature is a real, messy task broken down in front of you. Rockie's onboarding shows the breakdown working on a household task before any purchase screen. Users also have a one-tap way to split a step further, because "still too big" is a feeling only they can judge.

Measure action, not answers

The wrong metric for an AI feature is "the model responded". The right one is "the user did something with the response". For Rockie that means: did they start the first step, did they finish it, and did they come back? Those signals tell you whether the output is genuinely useful, and they're the ones that predict retention.