AI has produced three excellent options.
The first is a spacious card layout with progressive disclosure. The second is a dense operational table with inline actions. The third is a conversational workspace whose empty state has been designed with enough sensitivity to qualify for pastoral care.
All three are responsive, accessible and pleasantly animated. Nobody in the room can explain which one should be built.
This is not a failure of generation. It is the exposure of missing product judgment.
AI makes alternatives cheap. It can explore layouts, assemble components, rewrite content and implement interactions before a traditional team has finished naming the workshop. But choosing between plausible alternatives still requires an understanding of the user, workflow, data, risk and business consequence. Faster production does not remove that responsibility. It removes many of the places where its absence used to hide.
Options are not decisions
Product teams have often treated producing options as evidence of design progress. Options are useful because they make trade-offs visible. They become waste when the team lacks criteria for evaluating them.
The card, table and conversational workspace are not competing styles. They support different kinds of work.
A card layout may suit a small set of varied decisions requiring explanation. A table suits repeated comparison across consistent fields. Conversation supports clarification and direction when the task is genuinely conversational. The correct choice depends on frequency, information density, user expertise, consequence and what must remain visible after the interaction.
An AI can describe these general principles. It cannot know which matters most in a particular organisation unless the product context has been made explicit.
The design system should therefore contain decision guidance, not simply examples. It might state that operational lists default to tables when users compare more than five records across shared attributes. It might define when recommendations require evidence and alternatives. It might explain that chat remains secondary when durable workflow state must stay visible.
These rules do not eliminate judgment. They preserve previous judgment so every feature does not begin in philosophical isolation.
AI reveals vague requirements immediately
“Make it easier to use” used to survive several meetings before becoming a problem. AI can turn it into an interface within minutes, at which point the missing definition of easier becomes obvious.
Easier for whom? Faster for an experienced operator processing 40 requests, or clearer for an occasional approver reviewing one material exception? Fewer fields, or better sequencing? Less information, or more relevant information at the moment of decision?
Generated output gives vague requirements a visible form. The result may look convincing enough to tempt the team into treating appearance as resolution.
A stronger brief names the outcome:
reduce the time required to identify quotes awaiting the user’s approval;
show which pricing assumptions changed since the previous version;
let an approver request a correction without losing their place;
prevent issue while required customer data is incomplete;
preserve evidence of the final decision.
Now alternatives can be judged against the work. AI accelerates exploration while product judgment supplies direction.
The happy path flatters weak thinking
Generated interfaces often begin with complete data and cooperative users. Everything fits. The recommendation is accepted. The integration responds. The document contains every required field. This is a flattering environment for almost any design.
Judgment appears in exceptions.
Consider an AI-assisted quote recommendation. The model proposes a price using historical outcomes. The interesting questions are not whether the recommendation card looks modern. They are:
What evidence supports the recommendation?
Which relevant data was unavailable?
Has the market changed since the examples were recorded?
Can the user adjust assumptions rather than accept or reject wholesale?
Does acceptance create a draft or a customer commitment?
Who owns the outcome?
A design system can provide a recommendation pattern with rationale, provenance, uncertainty, alternatives and actions. Product judgment determines which evidence is material and which consequences require approval.
Without that judgment, the interface can display a confidence percentage whose precision exceeds its honesty. Ninety-two per cent looks reassuring until somebody asks, “Ninety-two per cent sure of what?”
Confidence is not a substitute for consequence
AI systems naturally produce probabilistic output. Interfaces are tempted to turn that uncertainty into a single score because numbers look governed.
Confidence may be useful, but consequence should shape the interaction more strongly.
A low-risk generated summary can be displayed with lightweight provenance and an edit action. A suggested contractual clause may need source comparison and formal review even if the model reports high confidence. A pricing recommendation above a financial threshold may require approval regardless of certainty.
The design system should encode patterns based on impact:
informational suggestion;
editable draft;
material recommendation;
externally visible action;
irreversible or regulated decision.
Each level can define evidence, review, authority and history. AI then helps within a responsibility model rather than presenting confidence as permission.
This is an area where product judgment cannot be outsourced to visual treatment. A pale warning and a disclaimer do not repair an unsafe authority model.
Judgment lives in what remains visible
Interface hierarchy is a product decision about attention.
AI can make a screen cleaner by hiding secondary information. Whether information is genuinely secondary depends on the task. In a charter quote, positioning cost may be visually small and commercially decisive. In a contract, one changed clause may deserve more attention than ten unchanged pages. In an integration failure, the technical error code may be secondary while the affected customer commitment is primary.
Progressive disclosure works when it respects these priorities. It fails when “clean” becomes a synonym for “concealed until somebody already knows to look”.
An AI-ready design system should document information requirements for recurring patterns. An approval summary always shows consequence and changed values. A failed synchronisation always shows affected work and current owner. A generated answer always provides accessible provenance. The layout can vary while the product refuses to hide what matters.
Resources such as Great UI, Interface Craft and Devouring Details provide valuable interaction references. Product judgment connects those patterns to the hierarchy of a specific domain.
A component cannot decide its own appropriateness
The growing quality of component libraries creates a subtle temptation: if a component is well designed, using it must be good design.
A beautifully implemented carousel remains a carousel. A sophisticated animated orb still needs a state to communicate. A recommendation card still needs a real recommendation process behind it. Motion and Anime.js make polished behaviour easier; they cannot decide whether motion clarifies the task or merely celebrates that state changed.
Design systems should document prohibited and questionable uses alongside ideal examples. For instance:
Do not use a modal for multi-step work that users must compare with the page.
Do not use colour alone to distinguish operational states.
Do not collapse evidence required for approval.
Do not stream text when fragments are unusable or destabilise reading.
Do not use a recommendation pattern without rationale and a route to disagree.
These rules capture judgment in a form both humans and agents can apply.
AI can improve the judgment process
Saying judgment remains human does not mean AI merely waits outside while serious people decide things.
AI can strengthen product reasoning by:
generating realistic scenarios and exceptions;
comparing alternatives against explicit criteria;
finding similar patterns in the existing product;
identifying missing states and permissions;
simulating different user roles;
checking whether evidence and recovery are present;
summarising research without replacing source material;
implementing prototypes that make trade-offs testable.
The important shift is from asking AI for “the best design” to asking it to support a decision process.
For the three opening alternatives, the agent might build each with representative data, then evaluate task time, scanability and exception handling. It can reveal that cards help occasional approvers understand individual cases while a table lets operational users compare many requests. The team may decide on a responsive pattern that moves between summary cards and a table based on task context – not because hybrid solutions are inherently sophisticated, but because evidence supports it.
Design systems record institutional judgment
The strongest design systems are repositories of decisions made through real work.
They contain components, but also reasons:
why a workflow uses a page instead of a modal;
why generated values remain visually distinct;
why a status requires an owner;
why a particular action cannot be combined with approval;
why dense tables are appropriate for one audience and not another.
This context is increasingly important when AI participates in product delivery. An agent can reuse a decision only if the decision is available in a form it can find and understand.
In my case-study work, the durable value rarely came from the final arrangement alone. It came from understanding the work well enough to create reusable patterns around decisions, exceptions and information. That understanding is what allows a design system to guide new features rather than merely style them.
Judgment needs ownership
AI can expose missing product thinking, but somebody still needs authority to resolve it.
When terminology conflicts, who defines the canonical state? When two patterns solve similar problems, who decides whether they should converge? When a generated feature introduces a novel risk, who determines the review requirement?
Design-system governance should include product, design, engineering and domain ownership. Not every decision needs a committee. Every important decision needs a clear owner and a route into the shared system.
Repeated uncertainty is useful evidence. If teams continually debate how to show partially synchronised data, the system is signalling a missing pattern. If agents repeatedly misuse a component, the usage guidance or API may be unclear. Product judgment includes recognising when a local problem deserves a systemic answer.
Better questions become the advantage
As generation improves, polished interfaces will become less differentiating. More teams will be able to produce competent screens quickly. The advantage will move towards the quality of the questions shaping those screens.
What decision is the user making? Which evidence matters? What can fail? Who owns the next action? Which state must remain durable? What is the consequence of being wrong? Which parts of this solution should become reusable product knowledge?
AI can help answer these questions. It cannot make them unnecessary.
The organisations that benefit most will not be those producing the largest number of alternatives. They will be those with clear criteria, strong domain understanding and design systems capable of carrying judgment into implementation.
Three excellent options are useful. Knowing why one supports the work is product design.
