Definition
Designing with AI covers two distinct activities that are often confused. The first is using machine-learning tools as instruments inside the design process: generating image variations, drafting copy, summarizing research transcripts, producing alternative layouts, writing component code. The second, and the more consequential, is designing products whose behavior is itself produced by a model — a search result ranked by a recommender, a reply written by a language model, a photograph altered by computational processing. The two demand different skills. The first is a question of craft and judgment about tools. The second is a question of interface design under uncertainty: the system's output is probabilistic rather than deterministic, so it may be fluent and wrong, and the interface has to make that possible wrongness legible without making the product unusable. Most of the genuinely new design problems sit in the second category.
Why It Exists
The practice exists because a class of capability crossed a usability threshold rather than because designers sought it. Statistical and machine-learning systems have shaped consumer software for decades — spam filters, spell check, recommendation feeds, autocorrect, camera autofocus — but they were mostly invisible, and users did not address them directly. From roughly 2022 onward, generative models made the capability conversational and open-ended: a person could ask for something arbitrary in plain language and receive a plausible artifact. That changed the design problem from tuning an invisible assist to shaping an open-ended exchange with a system that has no fixed feature set, no reliable error message, and no guarantee that the same input produces the same output twice. Product teams needed patterns for that situation quickly, and designers were asked to invent conventions in public, at commercial scale, before the research had settled.
Examples
- →Inline assistive patterns: autocomplete suggestions in email or code editors rendered as dimmed, tab-to-accept text, so the default action is to ignore rather than accept.
- →Generative image tools used for early exploration — mood, composition, lighting — where the output is a prompt for the designer's judgment rather than a deliverable.
- →Summarization surfaces such as AI-generated answers above search results, where the design question is how prominently to show a synthesis that may be unsupported by the sources beneath it.
- →Research assistance: clustering hundreds of open-text survey responses into candidate themes that a researcher then verifies against the raw quotes, rather than accepting as findings.
History
The design lineage is older than the current wave. Douglas Engelbart framed computing as augmenting human intellect in the 1960s, and J. C. R. Licklider had written about human-computer symbiosis in 1960; both imagined partnership rather than replacement. Statistical machine learning entered mainstream interfaces through the 1990s and 2000s in forms users rarely named as intelligence. Microsoft's Clippy, released in 1996, became the standard cautionary example of an assistant that interrupted confidently and read intent badly. Research groups published interaction guidance well before generative tools arrived: Microsoft's Guidelines for Human-AI Interaction appeared in 2019, and Google's People + AI Guidebook in the same period. The public release of large language and diffusion models from 2022 onward did not create this field so much as move it from specialist research into everyday product work, where the older guidance is still largely applicable and still largely unread.
In Modern Design
Established practice is narrower than the discourse suggests. What is broadly agreed: disclose when output is machine-generated; design for graceful failure because the system will be confidently wrong; keep the human in control of consequential actions rather than automating them silently; make correction cheap, since users will need to edit rather than accept; set expectations early about what the system can and cannot do; and show provenance where output rests on sources. What remains genuinely unsettled: how much agency to grant an assistant before people stop reading its output; whether confidence should be expressed numerically, linguistically, or not at all; how to evaluate an interface whose outputs differ on every run, which breaks the assumptions behind conventional usability testing; and how to design for the case where the model is right most of the time, because that is precisely when people stop checking.
Real-World Example
Consider an AI answer placed above a list of search results. The interface decisions are small and their consequences are not. Placing the synthesis first makes it the default read, which suppresses clicks to the underlying sources and shifts traffic away from the publishers whose material the answer depends on. Citing sources inline supports verification in principle, but research on comparable patterns suggests few users follow references; a citation can therefore function as a credibility signal rather than a check. Rendering the answer in the same typographic voice as verified content erases the distinction between retrieval and generation. Each choice is defensible in isolation. Together they determine whether the feature informs a person or replaces their judgment, and they redistribute attention and revenue across an entire ecosystem of sites. This is why AI interface work is not decoration on top of a model: the framing is much of the product.
Key Principles
- →Distinguish tool use from product behavior — using a model to draft a layout and shipping a model to users are different disciplines with different risks.
- →Design for the wrong answer first. Fluency is not accuracy, and a system that fails plausibly is harder to catch than one that fails obviously.
- →Make correction cheaper than acceptance: editable output, visible undo, and no irreversible action taken on the model's initiative.
- →Disclose generation clearly and consistently, and do not style generated content to look like verified content.
- →Treat evaluation as a design problem — non-deterministic output means testing sampled distributions of behavior, not a single golden path.
- →Keep human judgment in the loop where the cost of error is borne by someone other than the user: health, finance, employment, housing, justice.
- →Interrogate the training data and the licensing behind any tool you adopt, because your work inherits its provenance and its liabilities.
Why it matters
The open questions are live, and designers are among the people deciding them in practice rather than in theory. Training data and consent: many image and text models were trained on material scraped without the explicit permission of its creators, and litigation and legislation in several jurisdictions remain unresolved. Authorship and copyright: the legal status of purely machine-generated output varies by jurisdiction, and the US Copyright Office has stated that work lacking human authorship is not registrable. Homogenization: models reproduce the statistical center of their training distribution, which pushes output toward an average look and risks narrowing visual culture. Deskilling: if juniors never draw the first twenty options themselves, it is unclear where the judgment to evaluate option twenty-one is acquired. None of these has a settled answer. Pretending otherwise, in either direction, is the main failure mode in current writing about the subject.
Then vs Now
Then
Machine learning sat invisibly beneath features with narrow, well-defined jobs — filtering spam, correcting spelling, ranking a feed. Users did not address the system directly, its scope was fixed, and a wrong result was usually cheap to notice and cheap to undo.
Now
Users address the model in open-ended language and receive artifacts rather than adjustments. The feature set is unbounded, the output is fluent enough to be trusted without checking, and the design work is largely about framing, disclosure and correction rather than about the capability itself.
Try it yourself
Run a small, honest test rather than a demo. Pick a task you already do well — writing microcopy for an error state, or producing three layout options for a known screen. Do it yourself first, timed, and keep the result. Then do the same task with a generative tool, timed, keeping the prompts and every intermediate output. Compare on four axes: time spent, quality of the best option, quality of the worst option you might have shipped if rushed, and how much of your own judgment the process actually required. Then do the harder half of the exercise. Take the model output and try to establish where any factual claim came from. Note what you cannot verify. Write a paragraph on what you would have to tell a user about this output for them to trust it appropriately — neither too much nor too little. That paragraph is the design work.