Designing for AI

Cheap to make, hard to trust. A generative model will read a style guide and follow it straight off a cliff. Not because it is careless, but because it complies, confidently, with whatever it was handed, including the rules that went stale last sprint. The output looks plausible, which is exactly what makes it risky.

The same is true of an AI research product. A model can draft a report in seconds. Whether an analyst will put their name to it is a different question, and it is a design question. Most teams are asking how to make the model generate faster. The harder question is how to make what it generates trustworthy, correctable, and on-system.

Put control where judgment is. When a whole report generates at once, the expert can only accept it or start over. I replace one-shot generation with progressive narrowing: the output sharpens through stages the expert can validate or redirect before the system commits further.

Direction → Structure → Content → Final

Being wrong at the direction stage costs almost nothing. Being wrong at the draft stage costs one section, not the document. The amount of structure should match how much the system actually knows: propose directly when intent is clear, ask a few questions when it is broad, collect a brief when it is unclear.

The AI research workspace reached that model over four iterations, from one-shot generation to a collaborative workspace. At SBI I rejected a fully automated recommendation flow because it removed the analyst judgment customers were paying for.

Make output verifiable. Show where each claim came from. Keep a sourced result, an estimate, and an item that needs review visibly distinct. Return explorable tables with attribution instead of paragraphs to take on faith. The labels carry real weight, because they tell the expert where to spend attention.

In the research workspace, reasoning and completed tasks stay visible beside the report

Sometimes slower is the right design. A one-shot generator wins the demo. For daily expert work, cheap correction wins. I added checkpoints to the research workspace knowing they cost steps, because the expensive failure was never a slow report. It was a fast wrong one nobody could correct or trust.

Chat is one interface, not the interface. Chat suits open-ended exploration while the question is still forming. Repeatable, structured work wants a form and a preview. On S&P Global’s internal AI platform, the most-used tools were collecting structured inputs through a chat thread, because chat was the only mode available. The fix was an interface layer on the platform that already existed, not a rebuild: its advantage was never the model, which every company can buy, but internal data with compliance built in. The same gap is where the AI-native design system started.

SBI’s report builder showed the other side. A template-first version felt like filling in a form, and a conversation-first version worked better, but only once chat had persistent access to the client’s data and parallel threads for a second hypothesis.

Encode the rules where generation reads them. Documentation is a copy of the rules, and copies drift. My first fix for off-system AI prototypes was better component documentation. It worked until an API changed, and then the model followed the old contract perfectly into broken output.

So the rules moved into the pipeline: tokens as the only allowed values, component APIs as TypeScript schemas, deprecations as data, and an MCP server that reads live component source instead of a written description of it. The same constraint now governs a person writing code and a model generating it.

Generated from documentation · Generated from source

Evaluate before a human looks. Treat generated output as untrusted. Before anyone spends attention on a generated screen, scan it for invented components, hardcoded values, and deprecated patterns. In the AI-native design system that is a tool called check_project. Zero findings means ready for review, not finished.

Name the limits. Constraint is not control. A schema stops an invalid component; it cannot judge whether the screen is good. Evaluation catches the failures you have already seen, not the next one. Some rules cannot be automated at all: in dark mode, no token change fixed brand-color contrast on floating surfaces, so the answer was a documented usage rule.

The goal is not to remove the human. It is to spend their attention on the decisions only a human can make, and let the system carry the rest.