There's a design principle underneath every high-stakes AI product: AI is the decision support. The human is the decision maker. Those are different jobs. The AI surfaces information, surfaces risk, surfaces patterns a person couldn’t find alone. The human takes that and decides what to do. That is the contract: the AI provides the evidence, but the human owns the decision.

Most AI products in legal, healthcare, and criminal justice contexts are violating that contract by design. Not maliciously. They just weren’t built around it. They were built around making AI output look good and feel fast, and then a human approval step was added. The result is a product that looks like decision support but functions like liability transfer. The AI gets the credit. The human gets the exposure.

The gap between those two things is where people get hurt, sanctioned, and sued.

What the Contract Actually Requires

When I say AI is decision support and the human is the decision maker, I mean something specific.

Decision support means the AI’s job is to make the human’s judgment better: surfacing what they couldn’t see alone, flagging what they might miss, organizing what would otherwise take days into something they can actually work with. The human’s job is to take all of that, add the context and judgment and experience the AI doesn’t have, and make a call they can stand behind.

For that to work, the human has to be in a real position to evaluate what they’re looking at. Not technically present. Not nominally responsible. Actually equipped to engage with the evidence, form a view, and own the outcome.

That’s not what most products are designed to produce. I’ve been watching how AI-assisted decision workflows get built, and the pattern is consistent: the product team builds a good model, the UX team builds a clean interface for the output, somewhere in the spec there’s a review step, usually a button, sometimes a confirmation modal. Legal signs off because a human is technically approving each action. The product ships.

What doesn’t get designed: what the human actually needs to evaluate what they’re looking at.

How the Contract Gets Broken

The research on what happens next is not ambiguous.

When an authoritative-looking recommendation is on the screen, people defer to it, especially under time pressure and mental strain. Kate Goddard and colleagues identified this in clinical decision support in 2012 and the finding has replicated across domains ever since. The phenomenon has a name: automation bias. It’s the tendency to accept a system’s output rather than interrogate it, not out of carelessness but because the design routes around judgment rather than engaging it.

The 2023 JAMA study put this directly to the test. Randomized, 457 clinicians across 13 states. Standard AI predictions improved diagnostic accuracy by 4.4 percentage points. Systematically biased AI predictions reduced it. And the explanations, image-based saliency maps (visual heatmaps) showing why the AI flagged what it flagged, didn’t help. When the model was wrong, showing clinicians the reasoning behind that wrong answer didn’t protect them from agreeing with it anyway.

The explanation failed because the human was no longer engaged in evaluating the case. They were evaluating whether to trust the system. Those are different cognitive tasks, and the design had already answered the second one by the time the explanation appeared.

A 2023 study titled “Putting a Human in the Loop: Increasing Uptake, but Decreasing Accuracy“ found something worse: introducing a human reviewer actually increased how often people followed the AI’s recommendation, because the presence of a human made participants feel the decision had already been vetted. The human wasn’t catching errors. The human was providing cover.

Zana Buçinca and Krzysztof Gajos at Harvard tested whether forcing users to form their own view before seeing the AI’s answer would change this. It did. Requiring a prior commitment reduced how often people followed the AI even when it was wrong. The participants hated those designs. They gave them worse ratings even as they made better decisions with them. People do not enjoy being made to think, particularly when the screen is offering them a shortcut. Frictionless feels like good UX. In high-stakes decisions, frictionless is often the failure mode.

Four Cases Where the Contract Broke

The broken contract isn’t theoretical. Each of the following cases involves a domain where someone was designated the decision maker. Each shows what it costs when the product wasn’t built around what that role actually required.

Legal. In 2023, a New York attorney named Steven Schwartz submitted a brief citing six cases that ChatGPT had fabricated. “Varghese v. China Southern Airlines, 925 F.3d 1339 (11th Cir. 2019)” does not exist. Schwartz later said he had been operating under the belief that the tool “could not possibly be fabricating cases on its own.” The court imposed $5,000 in sanctions and required him to mail copies of the order to every real judge whose name appeared on a fake opinion. That was the beginning. By late 2025, researcher Damien Charlotin had tracked 1,356 documented incidents of AI hallucinations in legal filings, with sanctions in individual cases reaching $30,000. In California, at least one court has begun suggesting that opposing counsel may have a duty to detect the other side’s AI-generated fakes. The lawyer was the decision maker. The design gave them no way to verify the input they were deciding on.

Healthcare. IBM’s Watson for Oncology spent three years and more than $62 million at MD Anderson before an internal audit revealed the product couldn’t sync with Epic, was running on outdated drug protocols, and was producing treatment recommendations that weren’t based on current evidence. A physician at Jupiter Hospital described the product to IBM leadership in terms that don’t belong in a published article. Watson Health was sold to private equity in 2022. Separately: Epic’s sepsis prediction tool was deployed across hundreds of US hospitals on vendor-claimed performance numbers that looked credible. When Michigan Medicine researchers ran their own external validation, they found the model missed 67% of sepsis cases at the recommended threshold, generated alerts on 18% of all hospitalized patients, and correctly flagged only 7% of the cases clinicians had missed. Hundreds of clinicians were nominally the decision makers on sepsis while relying on a tool whose real-world performance they had no way to interrogate.

Autonomous systems. In August 2025, a Florida jury found Tesla one-third liable for a fatal crash involving a Model S in Autopilot mode. The driver admitted fault. Tesla argued no system in existence could have prevented this crash. The jury disagreed, finding that the way Autopilot had been marketed and designed shaped how drivers actually used it, and that designing a system in a way that trains users to trust it more than the technology warrants is itself a contributing factor. For years the standard answer to “who is responsible when Autopilot is engaged?” was “the driver; the system requires constant supervision.” The jury pushed back. When a product’s design trains the human to hand over judgment they were supposed to keep, the product shares the outcome.

Criminal justice. Eric Loomis was sentenced in Wisconsin in 2013 partly on the basis of a high-risk score from COMPAS, a proprietary recidivism prediction tool. The algorithm’s inputs and logic were not disclosed. Loomis couldn’t examine what the model had used to produce the score or challenge it on those grounds. The Wisconsin Supreme Court ruled in State v. Loomis that judges could continue using COMPAS so long as it wasn’t the “sole basis” for sentencing. The problem with that standard is a well-documented bias called anchoring: once an authoritative-looking number is in the room, it shapes decisions even when the decision maker believes they’re reasoning independently of it. ProPublica’s 2016 investigation found COMPAS was nearly twice as likely to falsely flag Black defendants as future offenders compared to white defendants at the same risk level. The judge was the decision maker. The design put an unexaminable number on the page and then assumed the human could reason around it.

The domains are different. The pattern is the same: someone was designated the decision maker, and the product wasn’t designed around what that role actually required.

Why the Contract Keeps Breaking

Automation bias explains the immediate failure. There’s a slower one that compounds it.

In aviation, the FAA spent years documenting what happened to pilots who relied heavily on autopilot: their ability to fly manually deteriorated. The 2013 Asiana 214 crash at San Francisco International, where investigators found the crew overly reliant on automation and lacking proficiency in manual flight at low speed, led the FAA to issue guidance directing pilots to hand-fly more often during low-workload phases. The goal was to preserve the skills they would need precisely when the automation failed.

Medicine is running the same experiment now. A multicenter randomized trial of colonoscopy with AI polyp detection found that when endoscopists returned to non-AI procedures after sustained AI use, their adenoma detection rate dropped from 28.4% to 22.4%. The tool was making them better at colonoscopy while they used it and measurably worse when they didn’t. In radiology, giving radiologists incorrect AI suggestions increased their false-positive recalls by up to 12%, even when they were explicitly told the AI might be wrong.

A product that removes the hard parts of a job, the reading, the independent reasoning, the forming of a view before consulting any reference, is also removing the experience that builds the judgment the decision maker is supposed to bring. The contract assumes a human with the expertise to evaluate AI support. Over time, a badly designed product dulls the expertise it depends on. That’s not a side effect. It’s a design choice, made by default.

What the Regulation Is Encoding

Regulators have started writing the contract into law.

The EU AI Act’s Article 14 on human oversight requires that high-risk AI systems be designed so that overseeing humans can “remain aware of the possible tendency of automatically relying or over-relying on the output produced by a high-risk AI system.” The regulation uses the term “automation bias” explicitly. That’s a legislative acknowledgment that putting a human in front of an approval button is not the same as designing a product that enables a human to actually make a decision. High-risk system obligations under Article 14 take effect August 2, 2026, meaning both providers and deployers must demonstrate that oversight is substantive: that the human assigned to approve is actually in a position to decide, not just named on the audit trail.

The DoD Directive on autonomous weapons made a related move. The directive doesn’t require a human at every engagement decision. What it requires is “appropriate levels of human judgment,” phrasing chosen specifically to distinguish substantive decision-making from a person whose presence is technically logged.

In financial services, audit trail requirements from NIST, the federal standards body, the SEC, and banking regulators are moving toward the same standard: every AI-influenced decision must be reconstructable. Not just “a human approved this,” but what data the model used, what was missing, what the human considered, and what their stated rationale was. The record has to answer the question a regulator will ask in an enforcement action two years from now.

Most products aren’t built to produce that record. They’re built to produce a timestamp and a user ID. That’s not a decision trail. That’s evidence that someone was present.

What Honoring the Contract Actually Requires

Here’s the question that follows from the design principle. If AI is decision support and the human is the decision maker, what does the human actually need to do that job?

It’s not a confidence score. It’s not a saliency map. It’s not a summary paragraph the AI generated about the same analysis it just ran.

When I founded and built an AI-powered fintech platform for early-stage investment due diligence, this was the central design question. The product surfaced financials, risk signals, and thesis fit for investors making real capital allocation decisions. We had the technical capability to let the AI recommend whether to invest. We chose not to. The AI surfaced insights, showed investors what the numbers actually meant, flagged the risks, and gave them everything they needed to form a view. It never said “this is a good investment.” That was deliberate. In high-stakes financial decisions, if the investor doesn’t understand why they’re making a call, the tool has failed even if the answer is correct. I delayed certain AI features specifically to ensure outputs were explainable and trust-building before shipping, not because we couldn’t build them faster, but because the human’s judgment had to stay in the room.

That principle generalizes. Here’s what it actually looks like in product decisions.

The human needs the underlying evidence, not just the conclusion. The contract clause they can click into, the source document passage they can read, the comparable transaction they can verify. Harvey AI’s Vault, Kira Systems’ source-anchored smart fields, Spellbook’s redline review where every AI suggestion requires an explicit accept or reject: these products put the source one click from the finding. The summary is faster. The source is what lets the human actually stand behind the call.

The human needs to form a view before the AI shows its answer, at least in cases that warrant it. Committing to a position first is what preserves independent reasoning. That’s an uncomfortable design choice. It makes the workflow slower and the experience harder. It also produces better decisions, and for products in high-stakes domains, that tradeoff needs to be named explicitly rather than defaulted away because usability testing rewards frictionless.

The human needs uncertainty expressed in a form they can reason with. Most products display abstract confidence scores like "12% confidence" or "high reliability," which the brain often processes as a static grade to be ignored. However, research by Cao, Liu, and Huang found that calibrated uncertainty only improves reliance behavior when expressed as a frequency. Telling a clinician that "in 100 patients like this one, 12 would have this condition" forces a mental simulation of real-world outcomes. It transforms a percentage into a scenario that actually demands human judgment.

The human needs their reasoning on the record, not just their approval. “Approved” is not a decision trail. “Approved because the risk clause in section 4.2 is standard for this counterparty type, flagged for legal review” is. In domains where the decision will be reviewed later, the product needs to capture what the human actually thought at the moment of decision, as part of the UX itself, not as a compliance mechanism bolted on afterward.

The human needs to keep the underlying skill. If the workflow removes the work that builds judgment, the reading, the independent assessment, the forming of a view from evidence, it also removes what makes the decision maker’s role meaningful. The contract requires an expert. A product that deskills its users is quietly canceling the contract it depends on.

The fastest test for whether a product is built this way is simple. Find the approval step. Ask what the user would need to know if they had to explain that decision in a deposition a year from now. If the answer isn’t already on the screen, it’s not decision support. It’s a paper trail.

While courtroom sanctions and medical audits leave a visible trail of a broken contract, the highest stakes show up where there is no trail at all. Consider an offline navigation app used by hunters or search and rescue teams. You are deep in remote terrain with no signal, limited battery, and changing conditions, following a route the system suggested twenty minutes ago that you cannot verify. At that point, you are not clicking approve, you are betting your safety on it. There is no source document to inspect, no second system to cross check, no fallback. The product is not supporting the decision, it becomes the only evidence you have. That is where the contract is most fragile, because if the system is wrong, the user does not just lose confidence, they lose time, options, and in some cases their safety. Trust here is not a UX layer, it is a survival mechanism, and the design either acts as a lifeline or quietly becomes the trap.

The AI-Native Reframe

AI-augmented product design asks: how do we display the model’s output clearly?

AI-Native design asks: what does this specific human need, in this specific moment, to make this decision and defend it later?

Those aren’t the same question. The first produces good output display. The second produces something that actually honors the contract.

The products that have gotten this right share a few characteristics. They’re slower in ways that feel purposeful rather than broken. They put the source one click from every claim. They require the human to engage with the evidence before routing around them with a summary. They record what the human actually decided and why, not just whether they clicked. They were designed around the moment someone has to answer for a decision, not just the moment they make one.

The broken-contract pattern holds until it doesn’t. It breaks when a sanctions order names the lawyer who approved something they couldn’t verify. It breaks when a malpractice case establishes that a clinician who processed 200 AI alerts in an hour wasn’t meaningfully deciding anything. It breaks when a board inquiry asks for the decision trail and finds timestamps with no rationale attached.

The teams building in high-stakes domains right now are operating as if the appearance of oversight is enough, or as if the law will move slowly enough to allow a course correction later. The empirical record, the regulatory calendar, and the case law are all moving in the same direction. What they’re moving toward is a standard that asks a simple question: was the human actually in a position to decide?

Most current products aren’t designed to answer yes.

Leslie Sultani is a design leader and player-coach writing about the intersection of AI, design practice, and organizational change. Former CPO, UX engineer, and founder of a FinTech AI platform. Read the full AI-Native Design Series at LinkedIn, Substack or Medium.

Further Reading

• “To Trust or to Think: Cognitive Forcing Functions Can Reduce Overreliance on AI in AI-Assisted Decision-Making” — Zana Buçinca, Maja Barbara Malaya, and Krzysztof Z. Gajos, ACM CHI 2021. The foundational experiment on cognitive forcing functions and why people rate worst the designs that produce their best decisions.

• “Measuring the Impact of AI in the Diagnosis of Hospitalized Patients” — Sarah Jabbour et al., JAMA 2023. Randomized trial showing that AI explanations don’t protect clinicians from systematically biased models. The accompanying editorial by Khera, Simon, and Ross is worth reading alongside it.

• Mata v. Avianca, Inc., S.D.N.Y. 2023 — The sanctions order in the ChatGPT hallucination case that started a wave of legal AI scrutiny.

• “Article 14: Human Oversight” — EU Artificial Intelligence Act. The regulatory text that names automation bias explicitly and requires products to be designed against it.

• “Machine Bias” — Julia Angwin, Jeff Larson, Surya Mattu and Lauren Kirchner, ProPublica 2016. The COMPAS investigation. The question it raised about who a system is actually serving hasn’t been resolved.

• “Automation Bias: A Systematic Review of Frequency, Effect Mediators, and Mitigators” — Kate Goddard, Abdul Roudsari, and Jeremy Wyatt, JAMIA 2012. The foundational systematic review. Still the clearest account of how the phenomenon works and what design moves actually mitigate it.

• AI Hallucination Cases Database — Damien Charlotin. A live, continuously updated tracker of documented incidents where courts have found parties relied on AI-hallucinated content in legal filings. The most comprehensive public record of how the legal case count is growing.

• “External Validation of a Widely Implemented Proprietary Sepsis Prediction Model in Hospitalized Patients” — Andrew Wong, Karandeep Singh et al., JAMA Internal Medicine 2021. The Michigan Medicine external validation of Epic’s sepsis model. The source for the 67% miss rate, 18% alert burden, and 7% of clinician-missed cases flagged figures cited in this article.

Every few weeks, someone declares the design process dead.

The most visible recent version came from Jenny Wen, who head of design for Claude at Anthropic. She wrote that the classic discover, diverge, converge sequence cannot survive a world where engineers spin up multiple AI coding agents and ship working versions before designers finish exploring. A week later, Sarah Gibbons at NN/g published the counter: the process isn’t dead, it’s compressed. The same discovery, distillation, and refinement still happens, just in an afternoon instead of a month.

They’re both right. And they’re both missing something.

The design process didn’t die, and it didn’t just get faster. It got rebuilt around what AI is actually good at and what it isn’t. Three specific things have changed, and all three are happening at once in the teams that are moving fastest. Most teams aren’t noticing all three. That’s why their AI investment keeps producing output without producing progress.

The First Shift: Compression

The most obvious change is that the phases of the process have collapsed in time.

Processing a week of research used to take another week. It now takes an afternoon. Competitive analysis used to take two weeks. A well-constructed prompt can produce it in a morning. Wireframe exploration, first-draft copy, visual directions, information architecture: every phase that was primarily about generating or processing information has compressed by roughly an order of magnitude.

The temptation at this point is to run the old process faster. Do what you used to do, just compress the timeline. Most teams do this. It’s the first mistake.

What actually happens in organizations moving well is that the time compression gets reinvested. The hours you used to spend making sense of research become hours you spend on problem framing. The days you used to spend on prototyping become days you spend watching users interact with the prototype. The teams getting the most out of compression aren’t the ones running a two-week sprint in three days. They’re the ones running a two-week sprint in three days and using the other nine to do the parts that were always rushed.

That’s the thing most playbooks miss. Compression without reinvestment is just a speed-up. Teams that treat AI as a way to finish earlier end up producing the same quality of work in less time. Teams that treat AI as a way to spend more time on the parts that matter produce work of a different quality entirely.

The Second Shift: Inversion

In certain kinds of products, especially AI-heavy ones, the sequence itself has flipped.

Henry Modisett, VP of Design at Perplexity, has described this directly. His team starts with capability exploration, not with user research. They build rough prototypes first, sometimes just command-line implementations, to see what the underlying model can actually do. Only then do they start thinking about the experience layer.

This reverses something that’s been structural to product design for decades. The sequence used to be: understand the user, define the problem, generate solutions, prototype, test. Technology came last, as a constraint or an enabler for the solution the team had designed. In AI-heavy products, this order doesn’t work, because the capability space itself is changing faster than any user research can track. You can’t design an experience around what an AI can do without first knowing what an AI can do, and that knowledge is only available through prototyping.

Karri Saarinen at Linear has made the same argument from a different angle. In “Design for the AI Age,” he writes that designers have to work forward to understand capabilities rather than backwards from user needs. He calls it “design is search.” The whole process is exploratory, not a waterfall. You’re searching through capability space and user need space at the same time, looking for the overlap. The prototype isn’t the end of the process. It’s the instrument you use to explore the process.

The inversion doesn’t apply to every product. A team designing a checkout flow still starts with user needs. But any team building with AI at the core of the experience has to know what the AI can do before they can design how users will relate to it. Teams that don’t invert this sequence end up designing experiences for capabilities that don’t exist yet, or missing capabilities that would have changed the whole frame.

The Third Shift: Parallelization

The old process was a sequence. Research, then design, then build, then test, then ship. Each phase gated the next.

What’s happening now in the most advanced teams is that these phases are running concurrently, across different people and different AI agents. A designer is prototyping while research is still coming in. An engineer is building a working version while the designer is still iterating on direction. Testing is happening continuously, not at the end. The handoff between phases, which used to be the critical moment of coordination, is disappearing in teams that have gone furthest with AI adoption.

Intercom is the clearest public example of what this looks like at scale. Their senior design leader Thom Rimmer has said that every designer at Intercom now has a development environment and ships to production. There’s no designer-to-engineer handoff in the old sense, because the designer is doing the work that used to be handed off. Tom Scott’s reporting on AI-native product designers in 2026 describes the full stack: an AI-first editor like Cursor, an AI coding agent, a coded design system, Figma Code Connect mapping components to code, and a GitHub review workflow shared with engineering. The process isn’t sequential anymore. It’s one continuous workflow with AI agents and humans operating on the same artifact at the same time.

The organizational implication of parallelization is bigger than people realize. If the sequential process is gone, then the traditional team structure that was built around it is also gone. The separate design, product, and engineering functions, each with their own artifacts and handoffs, were a coordination mechanism for a sequential process. When the sequence collapses, the separation does too. That part of the conversation is the one that gets most emotional and most politically charged inside organizations, because it touches how people think about their roles. The operational evidence is clear in the teams that are furthest along.

What Hasn’t Changed

Three shifts get most of the attention. The things that haven’t changed deserve more than they usually get.

Problem framing hasn’t changed. The moment where a team looks at everything they know and says “this is the right question to solve” is still a human moment. AI can produce research, generate options, surface patterns, and compare hypotheses. It cannot tell a team which problem is worth their organizational attention. The framing question requires strategic judgment that isn’t in any prompt, and it’s the part of the process that compresses least of all. If anything, good framing has become more important, because the downstream process can now execute faster on the wrong problem.

Real user empathy hasn’t changed either. Watching a person struggle with something you thought was obvious, hearing the words they use to describe what they’re seeing, noticing the moment they hesitate: these are things AI cannot do for the team. It can distill what users said in a research session. It cannot replace the embodied experience of having been in the room. The teams that still put their designers in front of real users, not in front of AI summaries of real users, notice things the others miss.

Judgment about AI output is new enough that teams are still discovering how important it is. An AI-generated prototype can look polished and test poorly, because something about the interaction model is subtly wrong in a way that only a designer with deep product knowledge can catch. The skill of recognizing what looks right but isn’t is a human skill, and it gets harder as AI output gets more polished. Teams that over-trust AI output at this step are the ones producing what critics have started calling “AI slop”: work that looks fine at a glance and fails in use.

Responsibility for shipping hasn’t changed. Someone has to decide that the work is ready and own the consequences if it isn’t. No AI agent owns the consequences of a decision. The person shipping is still answerable for the quality of what ships, and in teams where the designer now ships directly to production, that responsibility has expanded rather than contracted.

The Pattern Underneath

The design process didn’t die. It didn’t just get compressed either. What happened is more interesting than either framing.

The work got redistributed. Phases that used to be sequential now run concurrently. Activities that were once rare have become routine. The judgment calls designers made quietly in the past are now the central, visible work of the practice. The teams that have internalized this are structuring their practice around it. The teams that haven’t are running an old process faster and wondering why the speed isn’t turning into better outcomes.

Here’s the diagnostic question for any team that wants to know where they actually stand. Look at what your team spent time on last quarter. If the distribution looks similar to what it would have looked like three years ago, just with fewer hours in each bucket, you’re running the old process compressed. If it looks different, if more time has shifted toward problem framing and user observation and judgment on AI output, and less toward the production work that AI now does well, you’ve started the rebuild.

Most teams are still running the old process compressed. A smaller number have started rebuilding. An even smaller number have rebuilt enough that the shape of their work would be unrecognizable to someone from the pre-AI era.

The design process didn’t die. Jenny Wen was right about that. It didn’t just get compressed, either. Sarah Gibbons was right about that. What happened is that the process stopped being a sequence of steps and became something closer to a set of simultaneous practices, distributed across humans and AI agents, with the weight of the work concentrated in the moments that actually require human judgment.

That’s the rebuild. Most organizations haven’t finished it yet. The ones that do will have a different kind of design practice than the one the industry inherited.

Leslie Sultani is a design leader and player-coach writing about the intersection of AI, design practice, and organizational change. Former CPO, UX engineer, and founder of a FinTech AI platform. Read the full AI-Native Design Series at LinkedIn, Substack or Medium.

Further Reading

• The Design Process Is Dead. Here’s What’s Replacing It. — Lenny Rachitsky interviewing Jenny Wen, head of design for Claude at Anthropic. The most widely-shared argument for why the traditional discover-diverge-converge process can’t survive in AI-native product teams. The starting point for this article.

• Design Process Isn’t Dead, It’s Compressed — Sarah Gibbons and Huei-Hsin Wang, NN/g. The definitive response to the “throw out the design process” crowd. What looks like skipping steps is experienced designers running compressed versions. The compression argument in this article.

• Design for the AI Age — Karri Saarinen, Linear. Saarinen’s case for why designers need to reinvent their processes by working forward from capability rather than backward from user needs. Source for the “design is search” framing.

• Henry Modisett on Quality — Linear’s Conversations on Quality series featuring Henry Modisett, VP of Design at Perplexity, on fast iteration and the capability-first approach at Perplexity.

• Good from Afar, But Far from Good: AI Prototyping in Real Design Contexts — Huei-Hsin Wang and Megan Brown, NN/g. Rigorous evaluation of what AI prototyping tools actually produce when they meet real design scenarios.

• Operating as an AI-Native Product Designer in 2026 — Tom Scott, Verified Insider. The practitioner account behind the parallelization section, with specific details on the AI-native product designer’s toolkit and workflow.

• Design at Intercom — Tom Scott interviewing Thom Rimmer, Verified Insider. Intercom’s senior design leader on why every designer at the company now ships to production, and how the handoff collapsed.

• Generative UI and Outcome-Oriented Design — Kate Moran and Sarah Gibbons, NN/g. The bigger shift behind this article: from designing interfaces to designing adaptive systems that respond to user goals.

Partway through building the design system for my own portfolio site, I noticed something I hadn’t expected. The choices I kept making were shifting based on a question I wasn’t consciously asking: who’s going to read this?

When I pictured a designer opening the Figma file, I wanted tokens named for legibility, specimen pages showing components in context, usage notes written in plain language with visual examples. When I pictured an AI agent reading the same system to generate a chart or a deck slide in my voice, something different happened. I went heavier on the naming structure, added aliases that encoded intent rather than value, wrote descriptions on every component, and built a separate rules document for the things that must never change.

The two sets of choices didn’t just feel different. They pulled in opposite directions. And sitting with that long enough made something visible: AI agents and human designers don’t just have different preferences for how a system is organized. They have different cognitive modes entirely, and optimizing a design system for one doesn’t give you the other for free.

Two Readers, Two Cognitive Modes

A human designer reading a design system brings context. Years of pattern recognition, product knowledge, the ability to look at a component and infer from experience when to use it and when not to. They skim. They interpret. They work from examples and fill gaps from what they already know about design conventions and your specific product.

An AI agent does none of that. It queries against what’s explicitly in the system. If a token is named gray-900, the agent knows it’s a dark gray. What it doesn’t know is that gray-900 is your foreground color for primary text, that you never use it for disabled states, that your visual identity depends on using it only at full opacity and never tinted. That context lives in the heads of the designers who built the system, in decisions made two product cycles ago, in the implicit rules everyone follows without ever writing down. The agent doesn’t have access to any of it.

This is the actual problem. Not that AI can’t use a design system. It’s that most design systems were built for readers who could infer. AI can’t infer. It queries. And when it queries against sparse, implicit documentation, it fills the gaps from general training data, which doesn’t know your product, your voice, or the specific token your team deprecated last quarter.

What Changes When You Build for Both

Building my own system with both audiences in mind, I made four choices I wouldn’t have made if I were only designing for a human team.

Token aliasing - Instead of a flat list of presentational values, the system has two layers: primitives that hold the raw numbers, and semantic tokens that encode the intent. color/semantic/foreground. color/semantic/border. motion/duration/slow. The semantic layer is what components consume and what the agent reads. The name carries the meaning. An agent parsing color/semantic/foreground knows something about where that token belongs that it couldn’t infer from a hex value alone. The rule in the system is explicit: components consume semantic tokens, never primitives. If something needs a color the semantic set doesn’t cover, you add a semantic token. You don’t reach for a primitive and hope the agent figures it out.

Component descriptions - Every component in the library has a written description in plain text. Not a visual example, not a usage diagram, a sentence that makes the intent explicit. Designers read these as intent documentation. Agents treat them as decision rules. The same text serves both readers, but I wouldn’t have written it at all if I weren’t building for an audience that can’t rely on visual context to fill in what I didn’t say.

Flat component tree - Deep nesting hides structure from agents that parse by traversal. I kept the tree shallow, which also turned out to make the system easier for human designers to navigate. That pattern kept showing up: the discipline that makes a system legible to AI tends to make it more legible to people too. The gaps agents can’t bridge are usually the same gaps that junior designers quietly paper over by asking someone who’s been on the team longer.

There’s something the four choices above don’t say: during active iteration, the file looked nothing like any of this. Layers unnamed. Components nested three and four levels deep because that’s how the thinking happened, in stages, one decision stacked on the last. That’s not sloppiness. That’s design work. You’re moving fast, testing ideas, and the file structure reflects the mess of actually figuring something out. The problem is that mess is exactly what breaks AI consumption. An agent parsing a deeply nested, unnamed component tree isn’t going to infer your intent from the chaos. It’s going to produce outputs that drift from the system in ways that are hard to trace back to anything specific. What I hadn’t expected is that AI is also what solves this. You can ask it to do the cleanup pass: rename the layers, flatten the nesting, surface the implicit decisions and make them explicit. The extra step is real, but it doesn’t have to be a human step.

Rules file - A separate Markdown document at the root of the repository, labeled explicitly as an AI consumption file. It encodes the system’s invariants: what never changes, what’s forbidden without justification, what each semantic token means and why. For a designer, it’s a reference for edge cases and onboarding. For an agent, it’s the operating context that makes everything else parseable. The first line reads: “Read this before generating any visual, component, page, or marketing artifact in Leslie’s voice.”

The Discipline That Transfers

Semantic aliases, written descriptions, shallow trees, and a companion rules file: none of these turned out to be concessions to AI. They’re just good systems practice that most teams skip because human designers can compensate for the gaps. When someone who built the system is always nearby to answer questions, you don’t feel the cost of leaving things implicit. The cost only becomes visible when the reader can’t ask.

AI doesn’t ask. It works from what’s there. And the teams finding this out the hard way are the ones whose AI-generated output keeps drifting from the system: right colors, wrong token. Close component, wrong variant. Technically not broken, but obviously off to anyone who knows the product.

The discipline of building for a reader that can’t infer is also the discipline of building for anyone who wasn’t in the room when the decisions were made. That’s not a new design systems problem. It’s been invisible until now because the readers who could compensate for it were always humans.

The Gap Most Systems Have

Most design systems I’ve encountered will fail AI consumption not because they’re poorly designed but because they were never designed with this reader in mind. The documentation is sparse because everyone assumed the reader could infer. Token names are presentational rather than semantic because the team was moving fast and everyone already knew what the tokens meant. Component descriptions are visual rather than verbal because designers communicate in images.

None of that is negligence. It’s rational given the original audience. The problem is the audience has changed, and most systems haven’t caught up.

Teams at Atlassian and Figma are building this layer intentionally now, and if you read Your Design System Has a New Job earlier in this series, this is the structural change that makes that argument possible in practice.This is the structural change that makes that possible. Not a different system for AI, the same system, built with more explicit intention about what it’s actually communicating and to whom.

A design system that only talks to humans is doing half the job. The half that’s missing is becoming more expensive every month as more of what ships gets generated rather than drawn.

The system I built is live at library.lesliesultani.com, and the rules file that governs AI consumption is at the root of the repository. You can see the Figma design system here.

When I wrote the first line of that rules file, I was talking to Claude. But I was also clarifying something for myself. Making a system legible to an agent that can’t infer forces you to be explicit about things you’ve been leaving implicit for years. The token names have to carry meaning. The component descriptions have to be verbal, not just visual. The invariants have to be written down somewhere a reader can actually find them.

That clarity, it turns out, helps everyone who reads the system. Not just the agents. The humans too.

Leslie Sultani is a design leader writing about the intersection of AI, design practice, and organizational change.

Further Reading

• Design Systems and AI: Why MCP Servers Are the Unlock — Ana Boyer, Figma. The technical foundation for making design system context available to AI agents at generation time — the infrastructure argument that pairs with this article’s structural one.

• Turning Handoffs into Handshakes: Integrating Design Systems for AI Prototyping at Scale — Lewis-Ethan Healey & Kylor Hall, Atlassian. How Atlassian built agentic content and structured documentation for AI-generated code — the enterprise version of the approach described here.

• Why Your Design System Is the Most Important Asset in the AI Era — Romina Kavcic, The Design System Guide. The economics: 41% of new code in 2025 was AI-generated. When code is cheap and understanding is expensive, the design system is the architecture that matters.

• Agentic AI, Design Systems & Figma: A Practical Guide — Christine Vallaure, UX Collective. Practical implementation of agentic design system thinking — semantic tokens, consistent naming, and complete component states as AI infrastructure.

When design leaders talk about building AI fluency on their teams, the conversation almost always ends up in the same place: training.

Build a curriculum, run workshops, bring in an expert, send people to a course, create a certification path and measure completion rates.

What if the training isn’t failing because it’s bad? What if training is just the wrong solution to the actual problem?

The actual problem isn’t that designers don’t know how to use AI. The State of AI in Design report found that 96% of designers using AI today are self-taught. They figured it out on their own, without a curriculum, without a certification, without anyone measuring their completion rate. The knowledge exists. It’s spreading on its own.

What isn’t spreading on its own is the confidence to use what you know. The organizational permission to experiment without penalty. The safety to try something in front of your team and have it not work and not have that mean something bad about you.

That’s not a training problem. That’s a culture problem. And it requires a different intervention.

What Actually Gets in the Way

When you ask designers why they aren’t using AI more in their work, the answers cluster around a few things.

They don’t know if it’s allowed. Not in a policy sense, but in an unspoken cultural sense. Will using AI on this project be seen as cutting corners? Will my manager wonder if the work is really mine? Is there an official tool, and am I supposed to wait for it? What is the right process?

They don’t want to look like they don’t know what they’re doing. AI tools are unfamiliar. Prompting is a skill that takes time to develop. In an environment where competence is visible and mistakes are noticed, the rational move is to stick with what you know.

The moment that changes everything hasn’t happened yet. Most designers who become enthusiastic AI users can point to a specific moment: the first time a prompt generated something that actually surprised them, the first time synthesis that would have taken two days took two hours. Before that moment, AI is abstract. After it, it’s a tool they reach for. The problem is that without the right conditions, that moment never happens.

Training doesn’t fix any of these things. A workshop teaches you how the tool works, but it doesn’t give you permission, restore psychological safety, or create the first genuine “aha” moment. Those come from culture.

What Works Instead

The organizations making the fastest progress have figured out three things.

Grant Permission Publicly

Not a policy document. A signal from leadership that experimentation is valued over polish in early-stage work, that trying AI and failing is more useful than not trying at all, that the goal right now is learning and the team’s job is to generate that learning as fast as possible. This sounds simple. It is rarely done. Most design cultures are implicitly oriented toward demonstrating competence, not demonstrating curiosity. Changing that orientation requires explicit intervention from whoever leads the team.

Design Practice As Play

Figma ran something called the Great Figma Bake Off: a company-wide competition where teams built projects using AI tools, with live jam sessions across time zones and public showcasing of what people made. Nobody was evaluated on the quality of the output. The whole point was to get hands on the tools in a context where failure was interesting rather than consequential. Atlassian ran their AI Product Builders Week on a similar premise: a week of building, sharing, and learning together, with the outputs shared publicly inside the company. Over a thousand designers participated. The tool was never the point. The shared experience of trying together was.

Cultivate Champions

In every organization that has built genuine AI fluency at scale, there’s a small group of people who went deeper earlier. Not because they were assigned to. Because they were curious, or stumbled into the right project, or had a manager who gave them room to explore. These people become the informal infrastructure for fluency-building: the ones colleagues come to when they’re stuck, the ones who share what they’re learning in Slack channels or design crits, the ones who help others find their first “aha” moment. Organizations that identify these people and support them intentionally, rather than accidentally, accelerate the whole team’s development. Six to ten percent of the team with genuine depth is enough to change the culture.

The Mandate Trap

It’s worth being direct about what doesn’t work, because it’s the most common approach.

Mandating AI tool adoption doesn’t build fluency. It builds compliance. Designers who are required to use AI will find the path of least resistance: they’ll use it in ways that are easy to demonstrate, that check the box, that don’t require them to actually change how they work. The learning that comes from genuine experimentation, from trying something because you’re curious and then following where it leads, doesn’t happen under mandate.

Measuring adoption doesn’t build fluency either. If the metric is “what percentage of the team used an AI tool this week,” you’ll get the metric. You won’t get the change in practice that makes the metric meaningful.

The organizations that measure fluency well are measuring different things: the quality of outputs over time, the rate at which AI-assisted work is replacing lower-value manual work, the diversity of use cases the team is exploring. Those are lagging indicators, but they’re the right ones.

The Deeper Thing

There’s something underneath all of this that’s worth naming.

Design teams that build genuine AI fluency do it because their leaders are curious about AI themselves. Not performing curiosity. Not requiring it of others while remaining personally detached. Actually using the tools, sharing what they found, showing the team that the leader is also in the middle of figuring this out.

The signal that matters most isn’t the training budget or the completion certificate. It’s whether the person at the top of the design org treats AI as a live question they’re figuring out alongside the team, or as a mandate they’re delivering from a distance.

Teams follow what leaders do, not what they ask for. No certification path substitutes for that. That’s not specific to AI. It’s just how culture works.

Leslie Sultani is a design leader writing about the intersection of AI, design practice, and organizational change.

Further Reading

• State of AI in Design 2025 — Foundation Capital & Designer Fund. The source for the finding that 96% of designers using AI today are self-taught, and the data on where adoption is and isn’t happening.

• AI’s Blind Spot: The Human Judgment Reckoning — Workday. Survey data that makes the culture-not-curriculum argument concrete: 66% of leaders believe they are prioritizing skills training; only 36% of employees agree. The perception gap is the problem, not the training content.

• How Do Workers Develop Good Judgment in the AI Era? — David S. Duncan, Harvard Business Review. The finding that AI helped experienced practitioners more than less-experienced ones because judgment is the bottleneck, not information access. Directly explains why training programs solve the wrong problem and what organizations need to do instead.

• AI Product Builders Week: How Hands-On Experimentation Is Shaping Atlassian’s Future — Atlassian’s account of the week-long program where over a thousand employees built with AI tools together. The model behind the structured experimentation approach in this article.

• A Design Technologist’s Take on AI Builders Week — Atlassian. A practitioner’s perspective from inside the program, on what actually changes when teams build together with AI rather than train in isolation.

• Strategy Summit 2026: Why AI Means Radical Change — Tsedal Neeley, HBR IdeaCast. Introduces the “30% rule”: every worker needs baseline AI fluency, not just technical teams. Treats fluency as a culture and organizational change problem, not a skills gap.

• Strategy Summit 2026: Inventive Strategy and the ‘Unbossed’ Organization — Rita McGrath, HBR IdeaCast. The electricity analogy: you wouldn’t create an “electricity strategy,” you’d give people tools to experiment. Directly parallels the permission argument in this article.

• 5 Design Skills to Sharpen in the AI Era — Figma. What skills teams should be building fluency in, based on research across the design industry.

So far this has led me to eight articles deep and it will continue to unfold as I uncover more. Each one started with something I noticed in real organizations, followed the thread, and tried to make it useful for other design leaders sitting with the same questions.

This page is the home base. The full table of contents for the series, updated as new articles publish, plus the annotated reading list of every source that shaped my thinking along the way. Bookmark it if you want one URL for all of it.

The AI-Native Design Series

Article 0: What Does Design Look Like When AI Changes Everything? The question most designers aren’t asking out loud. When AI handles execution, what are designers actually for? The answer is clearer than the anxiety around it suggests.

Article 1: What “AI-Native Design” Actually Means (And Why Most Teams Are Getting It Wrong). Three stages: AI-aware, AI-augmented, AI-native. Most teams think they’re at stage three because they bought the right licenses. The distance between buying a camera and knowing how to see.

Article 2: Your Design System Has a New Job. Design systems used to talk to humans. Now their most important audience is AI agents generating code at scale. If your system isn’t legible to machines, the machines are making it up. Atlassian and Figma are already building for this.

Article 3: The Framework for Where Human Judgment Still Lives. A Stakes × Novelty matrix that maps any piece of design work into four zones, each with a different relationship between human judgment and AI. Plus four checkpoints that don’t move regardless of how the work is categorized.

Article 4: Why AI Fluency Isn’t a Training Problem. 96% of designers using AI today taught themselves. No curriculum, no certification, no one measuring their completion rate. So why does every organization default to training when teams aren't adopting AI? The problem isn't what most design leaders think it is.

Article 5: The Design System Is the Same for Humans and AI. Until It Isn’t. The idea sounds clean: one system for humans and machines. In practice, it doesn’t hold the way you expect. I tested this by building my own portfolio using the same principles.

Article 6: What AI Did to the Design Process. AI didn't kill the design process. It didn't just compress it either. It redistributed it. Three specific shifts are happening at once in the teams moving fastest, and most teams are only seeing one of them. That's why their AI investment keeps producing output without producing progress.

Article 7: When AI Decides and Humans Sign Off. There's a design principle underneath every high-stakes AI product: AI is the decision support. The human is the decision maker. Most products violate that contract by design. Four documented cases across law, healthcare, autonomous systems, and criminal justice show what it costs when the design didn't account for that. The gap between "human in the loop" and human judgment is a design problem. Most AI companies aren't treating it as one.

[Coming Soon] AI-Native Design at Every Stage: What Changes and What Goes Wrong Where do you start with AI? The answer depends almost entirely on the size and shape of the organization asking. A four-person startup and a two-thousand-person enterprise aren’t solving the same problem when they say they want to be AI-native. What actually changes across startups, mid-size companies, and large enterprises, and what’s the specific failure mode at each stage?

[Coming Soon] The Trust Problem AI Creates That Nobody in Design Is Talking About. What happens to users when AI is inside the product making decisions about what they see, what they're offered, and what they can do? Is trust architecture becoming the most consequential design challenge of this moment, and why aren't more teams treating it that way?

[Coming Soon] What a Design Sprint Looks Like Now. The five-day design sprint was designed in 2016. What does it look like when AI is embedded in the process, and how does the process change?

[Coming Soon] What AI Does to the Cost of a Pivot. Pivots have always been the right strategic move made at the wrong time. What happens to that calculus when AI changes the economics underneath the decision?

… more unfolding

The Reading List

These are the sources that kept showing up in my research. Not a generic collection. Every one of these shaped how I think about AI-native design, and most of them informed specific arguments in the series. I’ve organized them by theme and added my notes on what each one actually says and why it matters.

The Research

State of AI in Design 2025 — Foundation Capital & Designer Fund. The closest thing to a census of where design teams actually stand with AI. The finding that 96% of designers using AI are self-taught reframed my entire thinking about the fluency problem. The 84%/39% gap between exploration and delivery adoption shaped the argument.

State of the Designer 2026 — Figma. Figma's annual survey of 906 designers across five regions. The headline numbers: 72% now use generative AI tools, 98% increased their usage in the past year, and 91% say AI improves the quality of their outputs. But the finding I keep coming back to is this: designers who are increasing their AI usage are 25% more likely to report rising job satisfaction than those who aren't. The flip side is just as telling: 40% of designers whose AI usage stayed flat say their job is getting worse. The craft data is equally important. Companies that increased their emphasis on craft saw 67% of designers report higher satisfaction, and leadership attention to design work drove that number to 60%. If you're making the argument that judgment and craft become more valuable when AI handles execution, this is your evidence.

State of UX 2026: Design Deeper to Differentiate — Nielsen Norman Group. NNg’s annual assessment calls 2025 the year of “post-hype AI” and names trust as the defining design challenge of 2026. If you read one industry report this year for strategic planning, this is the one.

2025 Design in Tech Report: Autodesigners on Autopilot — John Maeda. The eleventh annual report identifies the shift from UX to AX (Agent Experience). Maeda’s argument that designers must now design for AI agents, not just human users, runs parallel to the design systems argument.

Four Shifts Designers Can’t Ignore in the Age of AI — Ben Blumenrose, Designer Fund. Companion piece to the State of AI in Design report, distilling four operational and cultural shifts design leaders are facing right now. Written from an investor and design-leader lens.

Design Systems as AI Infrastructure

Agents, Meet the Figma Canvas — Matt Colyer, Figma. Figma opens its canvas to AI agents via MCP server beta, letting agents create and modify real design assets using existing components, variables, and tokens. Introduces "Skills," which are Markdown files that encode team design decisions so agents produce on-brand outputs consistently. Works with Claude Code, Codex, Cursor, and Copilot. The most significant design systems infrastructure announcement since MCP servers launched.

Agentic Design Systems in 2026 — Brad Frost, bradfrost.com. Brad Frost, creator of Atomic Design, coins “DS+AI” and argues agents should assemble UIs using the same components human teams use. Defines two dimensions every agentic design system needs: coverage (clear examples, states, and constraints for agents) and validation (tests and human sign-off before anything ships). Foundational piece from the person who defined modern design system thinking.

Agentic AI, Design Systems & Figma: A Practical Guide — Christine Vallaure, UX Collective. Practical implementation guide following Brad Frost’s Agentic Design Systems demo. Makes a useful distinction: “This is the opposite of vibe coding. The agent is not inventing; it is following.” Covers what design system basics like semantic tokens, consistent naming, and complete states actually require to function as agentic infrastructure.

AI Design Systems Conference 2026 — Into Design Systems. Sold-out conference with 1,000-plus attendees and 21 experts from WhatsApp, GitHub, Figma, Adobe, Miro, and Atlassian. Sessions covered agentic design systems, machine-readable systems for MCP and LLMs, design systems as AI infrastructure, and encoding governance in agentic systems. Recordings are available and represent the most concentrated body of thinking on this topic from a single event.

Uber Automates Design Documentation with Agentic Systems — InfoQ. Case study of Uber’s uSpec system, which uses AI agents and the Figma Console MCP to automate component design specifications at scale. The agent crawls Figma component trees, extracts tokens and variants, and auto-generates platform-specific accessibility specs across seven stacks and three accessibility frameworks. The strongest enterprise-scale case study available for design systems combined with AI agents in production.

Vibe Design Is Real: Inside Google Stitch’s March 2026 Update — Tommaso Nervegna, Sorted Pixels. Deep analysis of Google Stitch’s introduction of DESIGN.md, a Markdown-based design system format built to be readable by AI agents. The core argument: “The design system of 2026 isn’t a Figma library with documentation. It’s a DESIGN.md file that travels between your design agent, your coding agent, and your prototyping environment. If your system can’t be read by a machine, it’s already legacy.” Also covers MCP integration and what agent-interoperability looks like in practice.

Storybook MCP for React — Kyle Gach, Storybook. Storybook’s MCP addon gives AI coding agents structured component metadata, so they build with your system instead of inventing their own version of it. The benchmarks tell the story: 12.8% better code quality, 2.76x faster generation, 27% fewer tokens. If you want to see what “design systems as AI infrastructure” looks like in production, start here.

Towards an Agentic Design System — Cristian Morales Achiardi, Design Systems Collective. Benchmarked six agent configurations and proved that structured, machine-readable design system infrastructure delivers 2x speed and 54% more accuracy at the same token cost. The most rigorous evidence I’ve seen that this investment pays off.

Why Your Design System Is the Most Important Asset in the AI Era — Cristian Morales Achiardi, The Design System Guide. Covers MCP versus CLI approaches, practical server setup, and the five context layers agents need to reason about components. His core point is hard to argue with: a design system is infrastructure, not a side project.

Design Systems and AI: Why MCP Servers Are the Unlock — Ana Boyer, Figma. The technical foundation for making design system context available to AI agents at generation time. Boyer’s argument shaped how I think about the difference between access and context.

Turning Handoffs into Handshakes — Lewis-Ethan Healey & Kylor Hall, Atlassian. How Atlassian’s design system team built agentic content and MCP infrastructure so AI-generated code actually reflects design intent.

Schema 2025: Design Systems for a New Era — Figma. Figma’s recap of the conference where they announced the Dev Mode MCP server.

Designers’ Workflow for Shipping Code — Eduardo Sonnino, Atlassian. A practitioner’s account of how the designer-to-engineer workflow changes when AI is generating the code. Useful for anyone trying to understand what the day-to-day actually looks like.

From Products to Systems: The Agentic AI Shift — John Moriarty, UX Collective. A design leader at DataRobot on designing for AI agents as a new user type alongside humans. Discusses agent-aware design system documentation in production and the tension between agent autonomy and user control.

The Role Shift

The Design Process Is Dead. Here’s What’s Replacing It. — Jenny Wen, Lenny’s Newsletter. Jenny Wen, Head of Design for Claude at Anthropic, argues the classic discover, diverge, converge design process has broken down. When engineers spin up AI coding agents and ship working versions before designers finish exploring, traditional workflows can’t keep pace. Design has split into two modes: supporting rapid implementation and upstream direction-setting on what to build. One of the most-discussed design and AI pieces of early 2026.

Operating as an AI-Native Product Designer in 2026 — Tom Scott & Vitor Amaral, Verified Insider. First-person account of AI-native design practice at Intercom. The designer’s role shifts from making to deciding: AI produces solid starting points, so the value moves to evaluation and judgment. Details a concrete daily workflow including a coded design system as the vocabulary for AI agents, Figma Code Connect mapping components to code, and a dedicated route for prototyping in the real app. One of the more grounded accounts of what this actually looks like day to day.

Outcome-Oriented Design: Designing in the Era of AI — Kate Moran & Sarah Gibbons, Nielsen Norman Group. Introduces outcome-oriented design as a structural replacement for traditional single-interface design. Designers now define adaptive frameworks that respond to individual user goals rather than optimizing for the average user. The shift moves design from prescribing a fixed UI to building systems that flex based on user context and desired outcome.

The Evolution of UX Design in the Age of AI Platforms: From Creator to Choreographer — Ken Olewiler, UXmatters. The source behind the creator-to-choreographer framing I reference in Article 0: What Does Design Look Like When AI Changes Everything. Olewiler’s argument that editorial judgment and taste are the skills that survive automation has held up well.

How Figma Integrates AI to Transform Design and Empower Creatives — David Kossnick, via OpenAI. Where the “vision carriers” concept comes from. Kossnick describes designers who understand where the product needs to go and can hold the long arc of user experience while everyone else is deep in the immediate problem.

5 Design Skills to Sharpen in the AI Era — Figma. Research-backed breakdown of which design skills compound in value as AI handles more execution. Based on the State of the Designer 2026 research.

The Death of Product Development as We Know It — Julie Zhuo. Co-written with Henry Modisett, head of design at Perplexity. Zhuo argues the traditional engineering/product/design team structure is dying. When building is cheap, everyone becomes a "builder" and role boundaries dissolve. Taste becomes the differentiator. I think she's right that the lines are blurring, but a designer, a PM, and an engineer will always look at the same problem through different lenses. That friction is what keeps teams from shipping the wrong thing faster. Remove the distinct perspectives and you just get a room full of people who think the same way. Worth reading and arguing with.

Shifting from Craft to Judgment in the Age of AI — Ravi Mehta, Atlassian. Captures the ratio shift better than almost anything else I’ve read. It used to be fifty-fifty between building well and deciding what to build. Now it’s closer to ninety-ten. The building got easier. The deciding didn’t.

The Future-Proof Designer — Nielsen Norman Group. Seven experts, 150-plus years of combined experience, all converging on the same theme: designers offer judgment built on expertise that AI can’t replicate. If you’re trying to articulate your value to a skeptical executive, the framing here will help.

Taste Is the New Bottleneck — Ivan Googol Medeiros, Designative. Goes beyond individual skill to explore taste as governance: who trains the systems that shape what good looks like? The most intellectually ambitious piece I’ve found on why taste and judgment are organizational concerns, not just personal ones.

Navigating the Next Decade as a Product Designer in Tech — Siva Sabaretnam, Atlassian. A practitioner’s perspective on how design’s advocacy role for users becomes more important, not less, as AI gets embedded in products.

How Service Design Will Evolve with AI Agents — Nielsen Norman Group. AI agents become new actors in service ecosystems. Previews “outcome-oriented design” where users specify results rather than performing steps. Forward-looking on how design practice must structurally evolve.

Trust Architecture

Identifying Necessary Transparency Moments in Agentic AI (Part 1) — Victor Yocco, Smashing Magazine. Introduces the Decision Node Audit, a structured method for mapping backend AI logic to the user interface. Uses an insurance company case study to identify which moments in an agent workflow require active transparency versus a simple log entry. The design challenge it names is finding the balance between the black box and the data dump. A companion to Yocco’s two earlier pieces, and the most methodologically specific of the three.

How to Design for Trust in the Age of AI Agents — World Economic Forum. Proposes a layered trust stack for AI agent autonomy: legible reasoning paths, bounded agency, goal transparency, contestability and override, and governance by design. Argues trust should be earned rather than engineered, through cognitive resonance rather than emotional persuasion. One of the cleaner frameworks available for thinking about trust as a designed architecture rather than a communication problem.

How to Get Your Customers to Trust AI — Ashley Reichheld, Sebastian Goodwin & Courtney Sherman, Harvard Business Review. Addresses the tension at the center of most AI product decisions: transparency is supposed to build trust, but companies regularly say too much and too little at the same time. Proposes embedding transparency within a broader trust framework, customizing disclosures for different audiences, and treating transparency as an ongoing process rather than a one-time disclosure.

The Trust Problem: Why Designing for AI Agents Is the Hardest UX Challenge of 2026 — Pedro del Rio, Medium. Traditional UX was built for passive systems; AI agents are proactive. They anticipate, decide, and act. Argues every agentic system needs a credible stop button and that designers must define clear thresholds between “act and report” and “ask before acting.” Makes the case that trust is a design decision, not a product or engineering one.

Dark Patterns in AI: How 2026 Made Them Harder to See — Stuti Mazumdar, Think Design. Documents the shift from static UI dark patterns to AI-systemic manipulation: sycophantic assistants, endless “helpful” loops, and AI subtly altering user intent during rewriting. Key point: “Two people could look at what seems like the same interface and be experiencing very different levels of persuasion” because of AI personalization. Useful for understanding the newer category of trust harm that isn’t visible in traditional dark pattern audits.

Dark Patterns UX: Manipulation Psychology 2026 — AgileSoftLabs. Covers the regulatory enforcement context: EU Digital Services Act Article 25 enforcement began in Q1 2026, Amazon’s $2.5 billion dark pattern settlement, and the finding that 97% of popular EU apps contain at least one dark pattern. Identifies AI-powered dark patterns as “an entirely new enforcement challenge, personalizing manipulation at machine speed and scale.”

Trust by Design: UX, AI, and Transparency Politics — Critical Playground. Theoretical treatment of trust as a design problem, not a branding or disclosure problem. References Google PAIR’s work and argues transparency is relational: what counts as clear varies across cultural contexts. “The politics of AI are increasingly negotiated at the UX layer.”

The Psychology of Trust in AI: A Guide to Measuring and Designing for User Confidence — Victor Yocco, Smashing Magazine. The most actionable trust framework I’ve found for practitioners. Defines the calibrated trust spectrum (from Active Distrust to Automation Bias) and gives you concrete measurement methods organized around four pillars: Ability, Benevolence, Integrity, and Predictability.

Beyond the Black Box: Practical XAI for UX Practitioners — Victor Yocco, Smashing Magazine. The companion piece, with mockup-level design patterns for explainability: “Because” statements, interactive factor sliders, source attribution, confidence visualizations. Introduces AI journey mapping for identifying where trust is most at risk.

When Should We Trust AI? Magic-8-Ball Thinking and AI Hallucinations — Nielsen Norman Group. Coins “magic-8-ball thinking,” the tendency to accept AI outputs without questioning them. Cites research showing AI legal tools report inaccurate information 17-33% of the time. Good ammunition for the conversation about why trust architecture isn’t optional.

Designing for Autonomy: UX Principles for Agentic AI — UXmatters. Reframes UX responsibility for agentic systems from “Is this usable?” to “Is this system behaving in alignment with human goals even when no one is watching?” Provides concrete questions for when to act versus wait, intervene versus observe.

Building AI Fluency

How Do Workers Develop Good Judgment in the AI Era? — David S. Duncan, Harvard Business Review. Research finding: AI helped experienced practitioners more than less-experienced ones, because judgment is the bottleneck, not information access. Building judgment requires clarifying who makes decisions, exposing people to consequences, restoring stretch experiences, and using simulations and case-based learning. Directly relevant to why training programs fail to build fluency and what to do instead.

AI’s Blind Spot: The Human Judgment Reckoning — Workday. Survey data on the gap between what leaders think is happening and what employees experience: 66% of leaders believe they are prioritizing skills training; only 36% of employees agree. Only 1 in 6 leaders is ready to use AI as a partner for complex decisions rather than a content generator. Useful data for making the case that the fluency problem is a culture problem, not a curriculum problem.

AI Product Builders Week: How hands-on experimentation is shaping Atlassian’s future — Atlassian. Over a thousand employees building with AI tools together for a week. The tool was never the point. The shared experience of trying together was. This shaped how I think about fluency-building.

A Design Technologist’s Take on AI Builders Week — Atlassian. The practitioner view from inside Atlassian’s program. What actually changes when teams build together with AI rather than train in isolation.

From Memo to Movement: Shopify’s Cultural Adoption of AI — First Round Capital. Goes past Tobi Lütke’s viral memo to show what actually happened inside the company. Three things that surprised me: they gave everyone access to the best AI tools (not just technical teams), they removed friction and cost barriers before expecting adoption, and they started with legal as a partner rather than a blocker. The biggest surprise: support and revenue teams adopted AI faster than engineering.

Creating Psychological Safety in the AI Era — MIT Technology Review × Infosys. 83% of business leaders say psychological safety directly impacts the success of AI initiatives. 22% of leaders have hesitated to lead AI projects because they’re afraid of being blamed if things go wrong. If you’re wondering why your team isn’t experimenting, this might be why.

AI Fluency: The New Product Superpower — Atlassian. Five frameworks for raising AI fluency across teams, plus named anti-patterns to avoid: tool tourism, automation theater, and prompt gatekeeping. Practical and specific.

Process Compression and Strategic Agility

Design Process Isn’t Dead, It’s Compressed — Sarah Gibbons, Nielsen Norman Group. The definitive response to the “throw out the design process” crowd. What looks like skipping steps is experienced designers running compressed versions. Exploring, making, learning, and refining can happen in a single afternoon now. The process is still there. It just moves faster.

Good from Afar, But Far from Good: AI Prototyping in Real Design Contexts — Nielsen Norman Group. Rigorous evaluation of AI prototyping tools using real design scenarios. The key finding: AI gets you to about 60% fast. The last 40%, the part that requires judgment, remains human. Essential reading for setting realistic expectations about AI-accelerated workflows.

How to Get Your Entire Team Prototyping with AI — Colin Matthews, Lenny’s Newsletter. Practical playbook for making AI prototyping work across a team, not just for the one person who figured out the tools. Covers component libraries, team workflows, and handoff processes.

Why Your AI Product Needs a Different Development Lifecycle — Aishwarya Reganti & Kiriti Badam, Lenny’s Newsletter. Based on 50-plus AI implementations at OpenAI, Google, Amazon, and Databricks. Argues that AI products fundamentally break the assumptions of traditional sprint cadences. If you’re a design leader wondering why your team’s planning process feels off, this might explain it.

Why Product Judgment Matters More Than Velocity in the AI Era — Productboard Captures the central paradox: as the cost of building drops, the responsibility to choose well increases. Velocity stops being the differentiator. Judgment is.

You Don’t Have an AI Strategy Problem. You Have 6 Design Decisions to Make. — MC Dean. Reframes AI strategy as a design problem: agency boundaries, failure tolerance, human overrides, feedback loops, what to refuse to automate. Sharp and specific.

Organizational Transformation (Beyond Design)

Building Next-Horizon AI-Native Experiences — McKinsey & Company. McKinsey argues the AI adoption problem is experiential, not technical. Proposes AI-native design patterns for embedding human judgment into AI interaction models. Organizations need to create with clarity, bring depth to workflows, and build for cocreation. References McKinsey’s 2018 Business Value of Design report and argues those principles have to evolve for the AI era.

The Design of AI in 2026: Strategy, Power Shifts, and the Cost of Pretending You Understand AI — Arpy Dragffy Guerrero & Brittany Hobbs, Product Impact Pod. Synthesis of 49 podcast episodes on AI and design strategy. The central observation: the gap in 2026 is between organizations that restructured how they create value and those that simply layered AI onto existing products. Includes a warning worth sitting with: organizations are “deleting the pipeline that produces senior judgment” in their pursuit of short-term efficiency.

Strategy Summit 2026: Why AI Means Radical Change — Tsedal Neeley, HBR IdeaCast. Harvard Business School professor Tsedal Neeley presents the “30% rule”: every worker needs baseline AI fluency, not just technical teams, and not expertise but baseline capability. AI requires radical organizational change, not just tool adoption. Covers three vectors of AI value and treats fluency as a culture problem requiring minimum technology and change capability thresholds.

Strategy Summit 2026: Inventive Strategy and the ‘Unbossed’ Organization — Rita McGrath, HBR IdeaCast. Columbia Business School professor Rita McGrath argues organizational design is increasingly enmeshed with strategy. Hierarchical structures built for mass production are becoming obsolete. Advocates for “unbossed” organizations where people experiment freely with AI, using the electricity analogy: you’d give people tools to experiment with electricity, not create an “electricity strategy.”

Strategy Summit 2026: Why AI Transformation Needs a Human Touch — Nigel Vaz, HBR IdeaCast. Publicis Sapient CEO Nigel Vaz on why enterprise AI initiatives fail: incentives, talent strategies, and trust aren’t factored in. The argument: the very processes organizations optimized for past success are what limit their ability to get value from AI, particularly around people, context, and how goals are set.

Is the Org Chart Dead in the Age of AI? — Fortune. LinkedIn’s Aneesh Raman argues org charts are holding back innovation and that companies need worker-led AI experimentation cutting across departments. LinkedIn replaced its Associate PM program with an “Associate Product Builder” role that merges coding, design, and PM skills. A concrete case study of role boundaries dissolving in practice at scale.

Top Leadership Experts Sound the Alarm: Bosses Are Choosing Tech Over People — Fortune. Deloitte data: 93% of AI budgets go to IT, only 7% to designing how humans and AI work together. Lara Abrash, Chair of Deloitte U.S., says that ratio “is not the right level of effort.” Harvard’s Linda Hill argues AI demands a whole new style of leadership. Strong data point for making the case that the human side of AI transformation is structurally underfunded.

The Last Mile Problem Slowing AI Transformation — Karim R. Lakhani, Jared Spataro & Jen Stave, Harvard Business Review. Identifies seven organizational frictions slowing AI ROI: proliferation of pilots, productivity gaps, process debt, identity and tribal knowledge problems, agentic governance, architectural complexity, and the efficiency trap. Frames this as the point where technical capability has to meet organizational design. The seven frictions map directly to challenges design organizations face during AI transformation.

Six Shifts to Build the Agentic Organization of the Future — McKinsey Not design-specific, but directly transferable. Maps the organizational shifts needed for AI-native transformation: leaner structures, human-plus-agent teams, new roles. If you’re a design leader making the case for restructuring, McKinsey’s framing gives you executive-level language.

Rebuilding Intercom for the AI Era — Des Traynor, Pigment Perspectives Podcast. Intercom scrapped their roadmap within 72 hours of ChatGPT launching and completely rebuilt their product. Traynor’s framework of “delay versus dilution” names the two failure modes companies fall into during a pivot. A masterclass in strategic agility.

The Capability Maturity Model for AI in Design — Jakob Nielsen, UX Tigers. Six levels of AI design maturity, from basic tool use to autonomous UI generation. Level 6 envisions designers as architects of systems, defining constraints and guardrails while AI generates interfaces. A useful diagnostic for figuring out where your organization actually stands.

From Managing People to Managing AI — Julie Zhuo, Lenny’s Podcast. Zhuo argues the three core skills of managing people translate directly to managing AI agents. Key listening for any design leader thinking about what their role becomes as AI takes on more of the team’s execution.

Applying This in Practice

[Coming soon]. The sources above are mostly about what’s changing and why. This section will focus on the what-to-do-about-it: practical resources for IC designers and design leaders looking to apply AI-native thinking in their day-to-day work.

How I Use This List

I don’t expect anyone to read all of this. If you’re a design leader trying to figure out where to start, here’s how I’d prioritize:

For the big picture, read the NNg State of UX 2026 and the State of AI in Design 2025. Those two together give you the full picture.

If your immediate problem is design systems, start with the Storybook MCP piece and the Morales Achiardi benchmarks. They’ll give you the evidence you need to make the investment case.

If your immediate problem is team adoption, read the Shopify piece from First Round and the MIT Technology Review research on psychological safety. Culture first, tools second.

If you’re trying to articulate why design matters more (not less) in this moment, the NNg Future-Proof Designer piece and Mehta’s craft-to-judgment argument are the strongest ammunition I’ve found.

This list will grow as the series continues. I’ll update it with each new article.

Leslie Sultani is a design leader writing about the intersection of AI, design practice, and organizational change. Former CPO, UX engineer, and founder of a FinTech AI platform. The AI-Native Design Series is published on Substack, LinkedIn, and Medium.

One of the hardest things about working with AI in a design practice isn’t the tools. It’s the decisions that don’t come with instructions.

Should a designer review every screen an AI generates, or just the ones that feel risky? Who signs off when AI suggests a pattern the design system doesn’t cover yet? When a product team wants to move fast and let AI handle a component, how do you know if that’s fine or if it’s the kind of shortcut that surfaces three months later as a trust problem?

Most teams wrestle with these questions ad hoc. Someone pushes back, or nobody does, and over time the team develops an informal sense of where AI is trusted and where it isn’t. The problem with informal is that it’s inconsistent. Different designers make different calls. Different product managers have different risk tolerances. And the accumulated effect of hundreds of small decisions made without a shared framework is a design practice that doesn’t actually know what it believes about AI.

There’s a better starting point. Two questions, asked about any piece of work, sort out most of it.

The Two Variables That Actually Matter

The first question: how high are the stakes if this goes wrong?

Stakes here means the real cost of a bad outcome. Not just a design critique. Not “the PM won’t like it.” Stakes means: could this make users feel like you’re lying to them? Could it expose the company to legal or regulatory risk? Could it put a dent in the brand that takes years to fix? Could it fail someone who’s already frustrated and just needs the “Cancel” button to work?

High-stakes work includes anything involving how users make important decisions, anything that touches personal data or sensitive information, anything where the experience of failure is significant for the person going through it.

Low-stakes work includes visual exploration, copy variations, early component builds, annotation, first-draft documentation. The cost of AI getting it wrong is iteration time, not user harm.

The second question: how novel is this problem?

Novelty means how much established pattern or precedent exists for what you’re designing. A standard notification component for a well-understood interaction is low novelty. A new feature that asks users to trust AI with a consequential decision is high novelty. There’s no precedent in your system, no established pattern to reference, no historical data about how your users will respond.

When you map these two variables against each other, four zones emerge, and each one calls for a different relationship between human judgment and AI.

The Four Zones

High stakes, high novelty. This is where human judgment is not optional. New product directions. Features that touch how users understand what AI is doing on their behalf. Experiences that carry legal or ethical exposure. Trust-critical moments where the wrong design decision isn’t just a UX failure but a breach. AI can do useful work here, mostly pulling together research and generating options for the team to react to. But a human decides, and that decision is documented and owned.

High stakes, low novelty. This is the zone that looks clean on paper and gets messy in practice. The pattern exists and the interaction is well understood, but the consequences of getting it wrong are real. In theory, AI handles execution and a human gatekeeps the output before it ships. Not a quick glance. A real review, with the stakes explicitly in mind.

In practice, this is where most teams trip up. I’ve watched it happen. The work feels like a slog, so the review becomes a slog. Someone skims the output, it looks close enough, and it ships. The problem is that “close enough” in a high-stakes context is how you end up with an accessibility failure in a payment flow or a disclosure screen that technically meets the legal requirement but confuses every real person who reads it. The pattern being familiar is exactly what makes the risk easy to underestimate. Teams that get this zone right treat the review as a deliberate act, not a formality.

Low stakes, high novelty. This is where you let AI throw things at the wall. The problem is new enough that exploring widely is valuable, and the consequences of a wrong direction are low enough that you can afford to generate, react, and toss quickly. A designer’s job here is picking what’s actually worth keeping, and being able to say why. That judgment is still human. The generation is not.

Low stakes, low novelty. Let AI do it. Established patterns, understood interactions, low consequence if the first draft isn’t perfect. Offloading this work to AI and protecting human attention for the other three zones is how a design team actually scales without sacrificing quality where quality matters.

Four Checkpoints That Don’t Move

The zones sort out most decisions. But underneath them, there are four moments in any design process where you can’t hand the wheel to AI, no matter how low-stakes or routine the work seems.

The first is framing the problem. AI is good at answering questions. It is not good at deciding which question is worth asking. The moment where a team steps back and says “are we solving the right thing” is a human moment. Not because AI can’t generate options, but because the answer depends on things that aren’t in the prompt: what the organization actually needs right now, what users have been struggling with, what the team already tried and abandoned.

The second is evaluating fit for real humans. AI doesn’t know your users. It knows patterns across training data. The designer who has sat in research sessions, who has watched people struggle with a flow, who carries the memory of actual human reactions: that designer notices things in an AI-generated interface that a generalized model cannot. Whether something actually works for the specific humans who will use this specific product, that’s a human judgment call.

The third is making ethical and trust calls. Anything that touches how users feel about the product’s honesty, anything that involves tradeoffs between business goals and user interests, anything where the design encodes a value: those decisions need a person behind them. Not because AI will always get them wrong, but because someone has to be willing to stand behind the call. That’s not a job you can delegate to a model.

The fourth is communicating decisions to stakeholders. The “why” behind a design choice requires someone who understands what the room actually cares about, not just what was decided but which tradeoffs were weighed and why the team landed where it did. AI can draft the summary. The judgment call about what matters to the people listening, and how to say it so they can accept it, is human.

What to Do With This

Take your team’s current work and map it against these zones. Not every project. Pick three or four recurring work types and ask: where do we consistently treat this as low-stakes when it’s actually high-stakes? Where are we burning human review on low-novelty execution work when we could be moving faster?

The distribution you find will tell you something about where your practice is over-indexed on human involvement and where it’s under-indexed. Both cost you. The teams that get AI-native right aren’t the ones that use AI for everything. They’re the ones that know where it belongs and keep it out of where it doesn’t.

I don’t think most teams will get this right on the first pass. The zones will bleed into each other, and someone will argue that everything is high-stakes, or nothing is. But even a rough version of this framework is better than what most teams are running on now, which is gut feel and whoever pushes back the loudest. Most of those decisions still don’t come with instructions. At least now they can come with a starting point.

Leslie Sultani is a design leader writing about the intersection of AI, design practice, and organizational change.

Further Reading

• State of AI in Design 2025 — Foundation Capital & Designer Fund. Data on where designers are actually using AI and where they’re not, which maps closely to the high-stakes/low-novelty zones in this framework.

• The Evolution of UX Design in the Age of AI Platforms: From Creator to Choreographer — Ken Olewiler, UXmatters. The case for why curation and judgment are the skills that survive automation.

• 5 Design Skills to Sharpen in the AI Era — Figma. Research-backed breakdown of which design skills compound in value as AI handles more execution.

Most design teams will tell you they’re doing AI-native design. What they usually mean is that their designers have some sort of AI copilot license and someone on the team figured out how to generate wireframes with a prompt.

That’s not AI-native. That’s AI-aware. And the distance between those two things is roughly the distance between buying a camera and knowing how to see.

I started seeing these patterns firsthand. Now I’m mapping the framework so other organizations can see them too. This article captures the first set of findings from that ongoing work.

The focus is not on tools, but on the practice itself. How work gets structured. How decisions get made. How teams organize around a fundamentally different way of building. What’s becoming clear is that most organizations are solving for the wrong problem. The ones that identify the right problem first will gain a significant competitive advantage.

Here’s the distinction that clarified everything for me.

Three Stages, One Question

Design organizations are currently at one of three stages in their relationship with AI.

In the first stage is AI-aware, this is when the team knows the tools exist and some individuals use them on their own. There’s no shared organizational posture. The gains are individual and a hit or miss.

Then there is AI-augmented, this means the team has identified specific phases of work where AI can accelerate output, things like research synthesis, visual exploration, and first draft copy. The gains are more consistent, but they are gains in speed, not capability. The underlying practice has not changed; the organization is simply running the same race faster. This is exactly where I found myself, and it became the catalyst for my research into what lies beyond just ‘faster’.

Lastly, there is the AI-native stage. This is something different. It means the organization has rebuilt around a different question entirely: where does human judgment create irreplaceable value (human-led value), and where is AI faster, more consistent, and better (AI-led execution)?

This isn’t a question about tools. It’s a structural question about the organization. And answering it honestly takes more courage than most teams are prepared for, because the honest answer often reveals that a significant portion of what designers spend their time on falls into the second category of AI-led execution.

What Actually Changes

When you take this question seriously, five things shift.

The Design System

In most organizations, the design system is documentation. A Figma file and a Storybook that engineers sometimes look at. In an AI native organization, the design system becomes the instruction set that governs everything AI produces. It does not just tell human designers what to do. It tells AI coding agents which components to use, what the tokens mean, which patterns are on brand, and which are hallucinated approximations.

Teams at Atlassian and Figma have already started building this layer. The MCP server that Figma announced at Schema 2025 brings design system context directly into developer workflows so AI agents can generate code that actually reflects the design system, including component names, spacing, and accessibility properties, without manual reinterpretation at every handoff.

If you build this infrastructure now, you have quality governance at scale. If you do not, AI output slowly erodes product consistency from the inside creating both technical and design debt.

Research Practice

Research practice is shifting too. AI does not replace user research, but it does change how the work happens. Synthesis that once took a week can now take hours. The bottleneck moves from processing the research to making sense of it. The real work becomes deciding which patterns actually matter and what they mean for the product. That kind of decision still requires context, empathy, and a deep understanding of the problem space. An AI native research practice is not just about moving faster. It is about using that time to focus on the moments where human judgment matters most.

Human Judgment

Another shift is how human judgment is now applied. In a traditional design process, human judgment is present at every stage simply because humans are the ones doing the work at every stage. In an AI native process, AI is doing significant portions of the work. Human judgment does not disappear. It concentrates into specific checkpoints. The design leader’s job becomes identifying exactly where those moments exist in the workflow and making sure the right people are present for them. In these moments, the goal isn’t to review AI output passively. The goal is to make real decisions.

Team Fluency

Equally important is team fluency. The organizations moving fastest are not the ones that mandated AI training. They are the ones that built cultures of hands-on experimentation, created safe spaces to try and fail, and established internal champions who help others find their first real “aha” moment with the tools. Figma ran something called the Great Figma Bake Off, a company-wide competition to build projects with live jam sessions in every time zone. Atlassian trained more than a thousand designers through their AI Product Builders Week. In both cases, the tool was never the point; it was giving people the permission to “play”.

Trust

And finally there is trust. As AI becomes more embedded in product experiences, designing how users understand what AI is doing, when to trust it, how to correct it, and what it can and cannot do becomes its own discipline. Trust architecture. This is not a feature or a UX pattern. It is a fundamental product strategy question that touches retention, conversion, legal exposure, and brand. Design leaders who understand this can speak credibly to a C suite about AI risk in terms the C suite actually cares about. Right now, most leaders are still struggling to bridge that gap.

Why Most Teams Are Getting This Wrong

The mistake most organizations make is treating AI-native as an upgrade to the tools layer: Buy the right licenses, train the team on prompting, integrate AI into a few workflows, and declare victory.

What this misses is that the practices and structures underneath the tools haven’t changed. The handoff process still produces the same bottlenecks. The design system is still documentation that humans wrote for other humans. Yes, the tools are faster, but the organization is still running on a pre-AI operating system.

This is why the companies seeing the strongest results are not necessarily the ones with the most sophisticated AI tools. They are the ones who got the organizational model right first. Then they let the tools serve that model.

The Opportunity This Creates

If you are a design leader who understands this, you have an advantage most don’t yet have. Not because you know more about AI than anyone else. Because you understand that this is fundamentally an organizational design problem. And organizational design is a design problem.

The same instincts that make a great designer are the ones required to build a practice that can use AI well: systems thinking, empathy for the people in the system, and the ability to see what is actually happening instead of what the org chart says is happening. The goal is not just speed. It is better decisions, stronger strategy, and work that scales over time.

The organizations that treat AI native design as a practice rather than just another purchase are already setting themselves apart. The gap is no longer just about speed. It is about which teams are still buying cameras and which ones have learned how to see.

Leslie Sultani is a design leader writing about AI, design practice, and organizational change.

Further Reading

• State of AI in Design 2025 — Foundation Capital & Designer Fund. Primary research on where design teams are in their AI adoption and where the practice gaps are.

• AI Product Builders Week: How Hands-On Experimentation Is Shaping Atlassian’s Future — Atlassian’s account of their week-long internal program where over a thousand employees built with AI tools together.

• Schema 2025: Design Systems for a New Era — Figma’s recap of Schema 2025, including the MCP server announcement and how design systems are being rebuilt for AI-native workflows.

There’s a question most designers are sitting with right now that they’re not saying out loud.

Not “which AI tools should I learn?” That one gets asked constantly, loudly, in every design community and conference. The quieter question underneath it is: what happens to me? To my judgment, my craft, my career. To the part of the work that I was told I was good at. When AI can do in seconds what used to take days, what am I actually for?

I’ve been thinking about this question for the better part of a year, and I’ve stopped believing it has a simple answer. But I’ve started believing there’s a more honest one.

When AI changes everything about design, the most human parts of the work become more valuable. Not less.

The catch is knowing which parts those are.

I noticed this in my own work recently. An engineer generated five interface variations with an AI tool in under a minute. Two years ago that would have taken a designer most of a day. The interesting part wasn’t the speed. It was that everyone still turned to the designer in the room to decide which one was actually right. Most teams haven’t fully realized what that shift means yet.

The Execution Trap

Most designers, if asked them to describe their job, will describe it in terms of what they make. Wireframes, flows, components, prototypes. The artifacts. Even senior designers often reach for the artifacts first.

This is understandable. For most of design’s history as a profession, the making was the expertise. The ability to take an ambiguous problem and translate it into something visible and testable. That was the skill. It required judgment, yes, but it was expressed through execution.

AI hasn’t changed the judgment part. It has changed the execution part dramatically.

This is the distinction that matters. When a designer can generate ten visual explorations in the time it used to take to make one, the value doesn’t disappear. It relocates. The question is no longer “can you produce this?” It’s “of these ten, which one is actually right, and why?”

That second question requires something AI doesn’t have. Context. History with the product. Empathy with the specific humans who are going to use it. Knowledge of what the team tried six months ago and why it didn’t work. Understanding of what the business needs to communicate and why this particular version of the message fits this particular moment.

Execution got faster. What it really exposed was the judgment.

What Gets Left Behind

There’s a version of this shift that’s uncomfortable to sit with: a significant amount of design work across the industry today falls into the category of execution that AI can accelerate substantially.

The State of AI in Design report found that 84% of designers are already using AI in exploration, but only 39% in delivery. Which means the early, generative, divergent work is largely being handed off, and the later, convergent, high-stakes work is still human. For now.

The honest implication: design roles that are primarily execution-focused are going to change faster and more dramatically than roles where judgment is the core product.

This isn’t a comfortable thing to write. But it’s more useful than pretending the shift is only additive, that AI just makes everyone more productive and nothing else changes. Something does change. The question is whether designers see it coming and position accordingly.

What Gets More Valuable

Ken Olewiler, writing in UXmatters, describes the shift this way: designers are moving from creator to choreographer. From making the work to directing the collaboration between human judgment and AI capability. The most valuable designer on a team is no longer the one who can produce the most. It’s the one who knows what the right output should look like, can direct the process toward it, and can tell, with confidence, when something is wrong even when it looks right.

David Kossnick, Figma’s Head of AI Products, calls these people “vision carriers.” The designers who understand where the product needs to go. Who can hold the long arc of the user experience in their head while everyone else is deep in the immediate problem. Who can look at an AI-generated interface and say: this is technically correct and completely wrong for our users.

This is not a new kind of intelligence. It’s an old kind of intelligence that the pace of execution used to obscure. When making was slow, the making consumed most of the professional attention. When making is fast, everything that was underneath the making becomes visible.

What’s underneath is taste, systems thinking, empathy at scale. The ability to read what an organization actually needs versus what it says it wants. To hold a user’s experience across dozens of touchpoints and notice when something breaks the coherence.

These are, not coincidentally, exactly the things that are hardest to learn and hardest to teach. They are also the things AI cannot replicate.

The Designers Who Will Thrive

The designers who will navigate this well are not necessarily the ones with the most technical AI fluency, though that matters. They’re the ones who can answer a different question clearly.

The question is: what is the irreplaceable thing I bring to this problem?

Not in general. For this problem. In this organization. With this team and this product and these constraints.

The designers who can answer that question quickly, specifically, and confidently are the ones who have always been doing the highest-value version of the work. AI hasn’t changed their value. It’s just made it more legible.

For designers who have been hiding behind execution, behind the tools and the deliverables and the process, this moment is a reckoning. The hiding place is going away. What’s left is the judgment.

That’s not a bad thing. It’s clarifying. It’s also what sent me into the research that became this article.

What This Means Right Now

This shift is not coming eventually. It’s happening now, unevenly, across organizations that are at very different stages of figuring it out. Some teams are already reorganizing around this reality. Many more are still treating AI as a productivity tool and wondering why the results aren’t compounding.

The designers who see this clearly have an unusual advantage: they’re not just more valuable individually. They can help their organizations make the transition well. Because the question of where human judgment is irreplaceable and where AI is faster and better is not just a career question. It’s an organizational design question. And designers are the people best equipped to answer it.

This is the part I find genuinely interesting. Design has always been about understanding systems, people, and the messy relationship between them. That’s exactly what the AI transition requires.

The profession isn’t threatened by AI. It’s being redefined by it, toward the work it was always most suited to do.

Leslie Sultani is a design leader writing about AI, design practice, and organizational change.

Design systems have always mattered, but they have rarely felt urgent. Everyone knows they need one and it is worth the effort in the long run. But there’s always a product deadline, a launch, or something more immediate that has to ship before anyone gets back to the foundational design system that actually keeps everything together.

That tradeoff used to make sense. It doesn’t anymore.

Not because someone finally made the case to prioritize it but because AI changed everything. If your design system only talks to humans, it’s only doing half the job. You’re ignoring its new power users: the AI agents that can spit out more code in a minute than your entire engineering team could write in a month.

If the AI doesn’t have your design system to guide it, it’s just going to make it up. On the surface, everything looks fine. But underneath, it’s gradually breaking apart everything your team spent years building.

What the Design System Actually Does Now

For years, design systems were basically just instruction manuals for people. We used them to make sure everyone was using the same buttons and didn’t mess up the spacing. It was mostly about keeping designers on the same page. The audience was designers and the occasional engineers who actually bothered to check what we intended.

Back then, the whole point was just writing things down. It was about documentation, nothing more.

Today, the job has changed. These AI coding agents look at your existing context to figure out which components to use and how things should actually work. If the design system is available for the agent to find, it uses it. If not? The agent just fills in the blanks based on general training data. It’s a fast track back to 2013, where every site looks like a generic Bootstrap clone because the tools are all pulling from the same basic bucket. Please lets NOT go back to that.

AI doesn’t know about your product. It doesn’t know which component you deprecated last quarter, or that your button radius is 6px not 8px, or that you never use that particular pattern because it failed user testing eighteen months ago. To a stranger, the code it spits out looks fine. But to you, it’s obviously wrong. It’s ‘off’ in that annoying way that’s hard to put into words, and it creates a mountain of technical debt that you’ll be stuck cleaning up later.

The design system’s job has changed: not just telling humans what to do, but giving AI enough context to do it better.

The Teams Building This Now

Atlassian is one of the clearest examples of what it looks like to actually solve this problem rather than talk about solving it.

When their design system team started watching AI coding tools generate interfaces, they noticed the quality gap immediately. The AI had access to their component library, technically. But access isn’t context. It could see that a component called Button existed. It couldn’t understand the full design intent behind it: when to use the primary variant versus the subtle one, what patterns the design system team had deliberately excluded, what accessibility requirements were baked into the component’s behavior.

Their solution was to build what they call “agentic content”: structured documentation written specifically for AI to read and reason from, not for humans to skim. Not a README. Instructions, with enough specificity that an AI agent could make the right decision without escalating to a designer.

They also built a direct connection between their design system and the AI coding tools their engineers use. (In technical terms, this is an MCP server.) The idea is straightforward: when an engineer’s AI agent generates code, it can see the design system the same way it sees the codebase. Component names, token values, usage rules, anti-patterns: all of it available at the moment code gets generated, not discovered later in a design review.

What came out of that work was fewer hallucinated components, fewer design review cycles spent catching AI-generated inconsistencies, and engineers who could move faster without constantly checking in with design.

Figma is tackling this from a platform perspective. Their MCP server, announced at Schema 2025, brings design file context directly into developer environments. The design system stops being a static document that someone has to translate, it becomes something the AI can read directly.

Three Things That Have to Change

Building this layer isn’t just a technical project. It requires a different way of thinking about what the design system is for.

The first thing is writing documentation for AI, not just for humans. This means going back through your component library and asking a different question for each entry: if an AI agent only had this documentation to work from, would it make the right decision? Not a reasonable decision; the right one. The one your design team would make. Most design systems fail this test badly, not because the documentation is poor, but because it was never written with this reader in mind.

Docs alone won’t get you there, though. You need a shared prompt library: a set of pre-built prompts that designers and engineers can use to interact with your design system through AI. These aren’t general prompts, they’re specific to your product, your patterns, and your conventions. “Create a notification component following our design system guidelines” is a different prompt than “create a notification component.” The first gets you something reviewable. The second gets you a guess. A prompt library means you don’t have to reinvent the wheel every time you want the AI to behave. It makes the interaction repeatable and teachable, which saves you from having to fix the same mistakes every other day.

But prompts still depend on a human remembering to use them. The harder problem is the technical bridge that gives AI direct, automatic access to your design system’s context, without anyone having to copy-paste a prompt or point the agent to the right doc. That’s what Atlassian built. The technical side might look different depending on your tools, but the core idea doesn’t change: put the design system in the room where the code actually gets generated, rather than having it show up after the fact in a design review.

The Strategic Shift This Creates

Look, you could frame this as a technical project. Build some tools, clean up the docs, the AI works better. Fine.

But here’s what’s actually happening. The design team that owns this infrastructure is writing the rules that every AI coding tool in the organization has to follow. Not guidelines that engineers might read. Rules that get enforced automatically, every time code gets generated.

Think about what that means. Engineering teams running AI tools are operating inside the design system’s constraints whether they realize it or not. Product managers who only care about shipping speed are getting outputs shaped by decisions the design team already made. For years, designers had to fight for a seat at the table, beg people to follow the specs, chase down inconsistencies after they’d already shipped. This is different. The influence moves upstream. It’s baked into the generation layer, not applied after the damage is already done.

This is the reframe that took me a while to see clearly. Design systems have always been how we help our teams do more with less. That was true when the audience was fifty designers who needed to stay in sync. Once every AI tool in the company starts pulling from your design system, you’re not helping fifty people stay consistent. You’re shaping every piece of UI the organization produces.

The Window Is Open Right Now

Not every team is going to see this coming. Building this now isn’t just about being “first,” it’s about writing the AI playbook for your company before a generic model writes a bad one for you.

Designers already know how to build playbooks. We’ve been doing it for years to keep humans in sync. Instead of a PDF that a human might glance at once, you’re building a living set of rules that an AI actually follows at scale, automatically, every single time an engineer hits ‘generate.’ And unlike your human colleagues, the AI will actually read it.

Remember the tradeoff from the top of this article? The one where the design system kept getting pushed to the bottom of the list because there was always something more urgent to ship? That tradeoff used to make sense because the cost was slow. A little drift here, a few inconsistencies there. You could catch up later. Now the AI is generating that drift at a speed no team can clean up after. The tradeoff doesn’t work anymore. It hasn’t for a while.

Leslie Sultani is a design leader writing about AI, design practice, and organizational change.

Further Reading

• Turning Handoffs into Handshakes: Integrating Design Systems for AI Prototyping at Scale — Lewis-Ethan Healey & Kylor Hall, Atlassian. The source behind the Atlassian case study in this article: how their design system team built agentic content and MCP infrastructure for AI-generated code.

• Design Systems and AI: Why MCP Servers Are the Unlock — Ana Boyer, Figma. The case for MCP servers as the technical bridge that makes design system context available to AI coding agents at generation time.

• Schema 2025: Design Systems for a New Era — Figma’s recap of Schema 2025, including the Dev Mode MCP server announcement.

• Designers’ Workflow for Shipping Code — Eduardo Sonnino, Atlassian. A practitioner’s account of how the designer-to-engineer workflow changes when AI is generating the code.

• Storybook MCP for React — Kyle Gach, Storybook. Storybook’s MCP server gives AI agents direct access to component metadata, usage patterns, and test guardrails, the same bridge Atlassian and Figma built, from the component documentation side.