Redesigning AI in Databases

The problem

The AI writing assistant inside Notion pages had caught on fast. AI inside databases — Summary, Translation, Autofill — didn’t. People tried it once, and the usage graph just stopped.

A 67% drop between someone’s first AI property and their second, inside two weeks. That one number was the whole brief. Databases were where Notion’s AI bet actually showed its value — an assistant that thinks across a thousand rows, not just one paragraph. If the first attempt failed, the bigger story never got a chance.

Living inside the feature

Before Figma, I used AI properties for a week of real work — a task tracker, a content calendar, a research database. I logged every moment I got confused. Three other designers did the same. By the end of the week: 47 friction points, most of which no dashboard would ever have shown.

A funnel analysis with the PM and a data analyst confirmed the shape of it — Discovery → Configuration → First fill → Review → Repeat use, with the worst drops exactly where the dogfooding log said they’d be. Then 22 interviews, watching people set up an AI property in their own workspace for the first time.

What broke trust

The AI’s state was invisible. Running, queued, failed, done — a spinner couldn’t tell you which, so people refreshed mid-generation and killed their own request.

Nobody could see what the AI was reading. Properties pulled from other columns in the same row, silently. A bad output looked like the AI’s fault, not an empty source column — and one unexplainable bad output was usually enough to end someone’s trust in the feature for good.

Every action felt destructive. Re-generate overwrote the existing output instantly, no undo. People hovered and didn’t click, keeping a bad answer over risking a worse one.

Four bets

A two-day sprint with the PM, EM, engineers, researcher, and analyst turned the friction points into four bets: make the AI’s state legible, show it its own homework, protect people from actions that felt destructive, and give AI properties their own identity instead of burying them among fourteen others.

Four prototypes, tested with eight people. The source-property pill won by a wide margin — once someone could see what the AI was reading, they stopped blaming it and started fixing the real problem.

What shipped

AI property types got their own section in the picker, each with a one-line description and a hover preview. Every AI column now shows, inline, exactly which properties feed it — click the pill and the source columns light up.

A source-property pill — click it, and the columns it reads from light up.

A status pill on the column header now reads “47 of 47 ready” or “3 stale — source changed,” so no one scrolls the whole database to check. Re-generating shows the new output beside the old one instead of erasing it; old versions stay for seven days.

What changed

Weekly active usage of AI properties rose 48%. People who used AI in their first session were 2.3 times more likely to still be around at 30 days. “Is the AI broken?” support tickets fell 41%, and re-generate clicks rose 78% — people finally felt safe pressing the button twice.

“Oh — now I get what it’s doing. I was using this wrong the whole time and I didn’t know.” A subscriber, six months in, said the whole project in one line. The AI had always been capable. We’d just never shown people what it was doing.

Reflections

AI usability is state and provenance. People don’t need to understand the model — just what it’s reading, what it’s doing right now, and how to undo it.

Dogfooding finds what analytics can’t. The “broken or just slow” problem never showed up in the funnel — only in a week of sitting with the feature myself.

Trust was the real metric. Adoption was the headline, but the deeper win was people treating AI properties as dependable, not a trick they’d tried once.