I haven't shipped a large-language-model feature to consumers, and I'd rather say that plainly than dress up a tooltip as an AI product. What I have done is design the experience of a physiological model that learns each user's baseline and drifts; decide, deliberately, not to put a generative model in front of eleven-year-olds; spend this year designing how people find, evaluate and trust AI agents inside a global financial institution; and rebuild my own practice around AI as a collaborator. Those four things are the substance of what teams shipping adaptive products are actually hiring for: user trust in systems that adapt, and the judgement to know when adaptation helps and when it harms.
Hilo: making a model's learning visible enough to trust
Hilo's wearable converts an optical signal into blood pressure and calibrates that conversion to each person with cuff readings. The model gets better with data, which is a wonderful property for an engineer and a confusing one for a user: the first readings are the least reliable, and the person has no way of knowing that. Users compared early readings to a cuff they trusted, found a difference, and concluded the device was wrong. Support tickets and reviews said so in almost exactly those words.
The design job was to make the learning legible. Four calibrations across four days instead of one, so the baseline is an average rather than a snapshot. Copy that says what the model is doing in plain terms: "Your Hilo Band is learning your blood pressure patterns", "Over the next few days, with more calibrations, your Band will learn your patterns for greater accuracy". A dashboard that shows the habits the model can already see (sleep, steps, heart rate) before it shows the number it's still learning. And when a later calibration disagrees with the baseline, the system says so and asks for a repeat within 48 hours, listing the likely reasons (cuff placement, posture, a change in medication) rather than silently accepting the drift.
Hilo Lens, the camera-based measurement, is the same problem in miniature. The interface has to manage what the inference needs (a warm finger, stillness, the right lens), show something honest while it computes, and diagnose the specific failure when it fails. Designing for the most constrained handset first cut drop-offs by 70%.
The questions I framed for the next phase were about the insight layer on top: how might we make insights more personalised to individual baselines, and how might we make insight messaging adaptive to the actual data, avoiding over-positive or generic language. That second one is the whole discipline in a sentence. An adaptive system that is always encouraging is not adaptive; it is a greeting card.
Radish: a scripted guide, and a door to a human
Radish Learning teaches digital literacy to children who don't have a phone yet. Its guide, SkillzBot, talks like an older sibling and delivers every lesson as a chat. It would have taken an afternoon to make SkillzBot a live model. I chose not to, and the reason is the product's whole premise: a parent has to be able to read exactly what their child will read before the child reads it, and a child must never be answered by something unpredictable. Every lesson is written by hand. Predictability is the safety feature.
What replaced the "ask the bot" pattern is a door to a human. "Tell a grown-up" sits in every lesson header; a small "?" inside the lesson flags the exact paragraph a child didn't understand and sends it to the parent with the context attached; the parent's review screen replays the lesson with the child's flags inline. The human is the intelligence in the loop, and the product's job is to route to them well.
The AI in Radish is in the tooling. The project's instruction files are a design-decision log that an AI collaborator reads before touching anything: which timings testers validated, which words confused people, which colour means action and which means status, and the line "No gamification (no XP, streaks, unlocks)". Keeping a capable collaborator inside the rules is a design problem too, and writing the rules down where the collaborator will read them turned out to be most of the answer.
Current work: how people find, evaluate and trust AI agents
This year I'm working with the London agency Else as a Senior Experience Architect on an internal platform for a global financial institution: one front door for employees to discover, evaluate, reuse and govern AI agents, tools, skills and data products, with compliance designed into the path rather than bolted on afterwards. The client and the specifics are confidential; the design problems are not, and they are the ones I expect every AI product to face.
Proactive surfacing over search
The system knows who you are at login. Relevance should be pushed, not typed for. "Know what I'm looking for before I ask" is the bar, and it's also the trap: what's surfaced has to be explainable.
Show why a result was returned
Every ranked result carries its reason: which concepts matched, which people like you used it, what status it has reached. A result you can't defend is a result you can't act on.
Never auto-execute on intent
Natural-language intent produces options, never actions. The person picks, the trace is visible, and they can interrupt. Speed is not worth an action nobody chose.
Provenance is the trust object
Who approved it, when, for what data, at which version. When the artefact carries its own audit trail, trust stops being a feeling and becomes something you can read.
Compliance in the path, not at the gate
If the evidence is generated as you build, the sign-off is a formality. If it has to be reconstructed at the end, it's a wall. Walk people through it; don't test them on it.
Judge for the user, and show your work
Non-technical people can't evaluate an agent technically. The system has to do the judging, out loud: social proof from people in their role, approval status, and what it applies to.
Decisions made against working artefacts
I built Radish Learning with Claude Code as a design partner: from concept to a live, paid product in about six weeks and 336 commits, the design system, both dashboards, the lesson and quiz players, payments. When a choice needed making, I built the options: three live-code directions for the child's dashboard on one page, compared side by side, one chosen. When the lesson pacing felt wrong, I changed the timing constant and felt the difference in seconds, then wrote the validated value into the decision log so it would never be "fixed" by accident.
At Hilo I introduced Figma Make into the design-to-development workflow, generating working components from Figma so that handoff became a conversation about behaviour rather than a spec about pixels. The pattern in both places is the same. AI did not make me faster at mockups. It made the mockup unnecessary for a whole class of decisions, and it made the decision log a first-class artefact, because the collaborator reads it.
What I hold to
- Say what the system is doing, in the user's words. "Learning your patterns" beats "calibrating" and both beat silence.
- Show uncertainty as a question, not a shrug. "We noticed a change; can you confirm?" keeps the person in charge.
- Adaptive means sometimes unwelcome. A system that only ever encourages isn't adapting to the data.
- Options, not actions, from intent. Let people choose; make the trace visible; let them stop it.
- Provenance before polish. Who approved it and for what is the first thing a trust screen should answer.
- Know when not to. The most important AI decision in Radish was leaving the model out.
- Write the rules where the collaborator reads them. A decision log is a design tool now.