Design Systems

Design Systems for AI Products Need Different Rules

Design Systems for AI Products Need Different Rules

AI introduces uncertainty, confidence, generation and correction into interfaces. Traditional component systems alone are not enough to manage those behaviors.

A traditional component system can describe a button precisely and still leave an AI feature underspecified. The button says “Generate.” What happens next is a product behavior, not a button variant.

Does output arrive all at once or in parts? Can the user leave? Will an edited passage survive regeneration? What context did the system use? If the output is wrong, does retry mean repeating the same request or asking for a different result?

AI design systems need reusable answers to these questions. They do not need one universal interaction model. A drafting tool, a recommendation system and an assistant that takes actions carry different obligations. The system should make those differences deliberate.

Generation is not simply another loading state

Loading usually communicates that the product is retrieving or processing something. Generation may involve constructing an output whose length, quality and completion time are not known in advance. Presenting both with the same indefinite spinner can conceal a meaningful difference.

Define what users can know while work proceeds. A truthful description of the current stage can be more useful than a progress percentage the system cannot support. If a task can be cancelled, explain whether cancellation stops the work or only closes the view.

Partial results need their own rules. Mark them as incomplete when that distinction matters. Decide whether they can be copied, edited or acted on before generation finishes. Avoid presenting a provisional result with the same authority as an accepted one.

These decisions should be shared across features where the underlying behavior is similar. Otherwise, people must relearn what waiting, stopping and finishing mean in each part of the product.

Uncertainty should change the interaction

An interface can sound certain even when its output is not. Typography, placement and action labels all influence how a result is interpreted. A polished answer beside a primary action can imply readiness that the system has not established.

Show uncertainty in a way that helps someone decide what to do. A useful explanation might identify missing information or a conflicting source. A generic warning attached to every output provides little guidance about which result needs attention.

Confidence scores require particular care. A number should have a defined meaning and a reason to be trusted before it is presented as evidence. If the product cannot explain what the score represents, ordinary language about limitations may be more honest and useful.

System guidance should connect uncertainty to available actions: inspect supporting material, provide missing context, revise a request or proceed with explicit confirmation. Trust is supported by understandable control, not by a decorative badge.

Correction is a primary workflow

AI output should not force a choice between accepting everything and starting again. In many products, the useful work happens through correction: editing a paragraph, replacing a suggestion or excluding an irrelevant source.

Make ownership clear. Once someone edits generated text, decide whether it has become their working document. Regeneration should not silently overwrite those edits. Preserve versions or provide an understandable comparison when replacement is necessary.

Retry and regenerate should also mean different things when the product behaves differently. Retry can repeat an operation that failed. Regenerate can request an alternative after a successful response. Using one label for both can obscure whether the previous result will remain available.

The system should define selection, replacement and recovery together. A reusable generation panel is incomplete if every team must invent what happens to existing work after its main action is used.

Provenance needs to support inspection

Source visibility matters when an output depends on information users need to verify. A reference should help someone inspect the basis of a claim, not merely decorate the response with the appearance of evidence.

Distinguish source material from the system’s interpretation. Where possible, make it clear which part of an output a reference supports. If a source is unavailable to the user, explain that limitation rather than presenting an inaccessible link as sufficient verification.

Not every AI feature needs citations. A tool rearranging user-written text has a different provenance problem from one answering questions across a document library. The reusable rule should be about what evidence the task requires, not a universal requirement to attach links.

This is another place where judgment matters more than interface generation. The team must decide what users need to inspect and what the system can actually substantiate.

Actions need a stronger boundary than suggestions

Generating a draft and sending it to another person are different operations. So are suggesting a record update and committing that update. Design the boundary explicitly when the product moves from proposing to acting.

A confirmation should explain the consequential action, its destination and its scope. Showing the generated text alone may not reveal which recipients will receive it or which records will change. Review needs to match the actual effect.

Calibrate confirmation to consequence. Repeated approval for harmless, reversible edits can create unnecessary friction. Silent execution of a consequential action can remove meaningful control. A design system should give teams a way to classify actions and choose an appropriate pattern.

Failure states must preserve that distinction. If an operation times out, can the product establish whether the action happened? Do not invite an immediate repeat when it could create a duplicate. Explain the known state and offer a safe next step.

Context and memory belong in the interface model

An asynchronous response may arrive after the user changes documents or leaves the page. The product needs to associate the response with the correct request and make its status understandable on return.

Context has similar boundaries. People should be able to understand which document, conversation or account informs a result. Persistent memory should not be confused with temporary context, especially when that difference changes future outputs.

Define how context is selected, displayed, changed and cleared. Test what happens when access changes while a request is running. These are shared product responsibilities even when their visual expression differs by feature.

Start with the behaviors your product repeatedly needs. Specify generation, correction, confirmation and recovery before expanding the component catalog. A coherent AI product lets people understand not only what the system produced, but what they can safely do with it next.

Back to Insights ←