Building a Design-Driven Culture in the Age of AI

A few months ago a product lead dropped a screenshot into a team channel with a single line underneath it: can we just ship this? It was a dashboard, generated from a prompt in well under a minute. It had a tidy card grid, a sensible color palette, a chart in the top right, and a sidebar with icons that all matched. It looked finished, and that was the problem.

Nobody in that channel could say who the dashboard was for, what decision it was supposed to support, or why the chart in the top right deserved the most prominent spot on the screen. Those questions were never asked, because the artifact arrived looking like it had already answered them. It took forty seconds to make and it would have taken a quarter to undo.

I don't think that moment is unusual anymore. AI tools have made it nearly free to produce something that looks like design. I use them every day and I'm glad to have them. But the ease of generating has created a quiet confusion in a lot of organizations about what design actually is, and designers are not immune to it. If the job is producing screens, the job is being automated. If the job is deciding what is worth making and making it genuinely good, the job just got more important, and the culture around it needs to catch up.

Output is no longer the scarce thing

When the cost of something drops toward zero, its value moves to whatever stays scarce. For most of the history of software, making the interface was expensive. It took skilled people a long time to produce a credible screen, so a credible screen carried a lot of implied work. That signal is gone. A polished mockup now tells you almost nothing about whether anyone thought hard about it.

What stays scarce is judgment: the ability to frame the right problem, to know which of ten plausible directions is actually better, to notice what is missing, and to hold a standard when the deadline is pushing against it. That is where the value of design has moved, and the data on how designers experience these tools reflects it.

Figma's 2025 AI report, based on a survey of 2,500 of its users, found a clear gap between disciplines. Eighty-two percent of developers said they were satisfied with AI tools, compared with 69 percent of designers. Sixty-eight percent of developers said AI improves the quality of their work, against 54 percent of designers. And across everyone surveyed, only 32 percent said they can rely on AI output.

I read that gap as a description of the work rather than a complaint about the tools. Code that compiles and passes tests is at least partially verifiable. Design quality is not something a model can check for you, because it depends on context the model does not have: who the user is, what they are trying to accomplish, what the business is betting on, and what happened the last time the team tried something similar. The tools are excellent at producing a plausible answer. Deciding whether it is the right answer is still the designer's job.

Everything starts to look the same

In July 2024, Figma paused its new Make Designs feature after a designer showed that asking it for a weather app kept producing something strikingly close to Apple's Weather app. Dylan Field, Figma's CEO, took responsibility, saying "ultimately it is my fault for not insisting on a better QA process," and the feature came down while the team reviewed it.

It is easy to treat that as a one-off product misstep. I think it is a preview. Generative tools work by producing the most probable output for a prompt, and the most probable answer to a common design problem is the one everyone has already seen. That is useful when you want a sensible default. It is a liability when the whole point of the work is to be distinctive.

Research supports the concern. In a 2024 study published in Science Advances, Anil Doshi and Oliver Hauser gave some writers access to story ideas from a large language model. Evaluators rated the AI-assisted stories as more creative and better written, with the biggest lift for the least creative writers. But the AI-assisted stories were also more similar to one another. Each individual got better while the group as a whole produced a narrower range of ideas. The authors describe it as a social dilemma, and I think it maps almost perfectly onto product teams.

If your competitors are using the same tools, trained on the same patterns, answering the same prompts, then the default outcome is parity. Everyone's onboarding flow converges. Everyone's dashboard has the same card grid. And differentiation, which is one of the main things good design was supposed to buy a business in the first place, gets quietly traded away for speed.

Feeling faster is not the same as being better

There is another trap here, and it is harder to see from the inside. In 2025, the research group METR ran a randomized controlled trial with 16 experienced open-source developers working on 246 real tasks in codebases they knew well. When they were allowed to use AI tools, they took about 19 percent longer to finish. Before the study they predicted AI would make them 24 percent faster, and even after it was over they estimated it had sped them up by about 20 percent.

It is one study, it was about code rather than design, and the tools have improved since. But the perception gap is the part I keep thinking about, because I see the design version of it constantly. Generating forty variants of a landing page feels like progress. A review full of options feels productive. What often happens is that the team spends its time sorting through plausible output instead of doing the thinking that would have told them which single direction to pursue. Volume starts to stand in for rigor, and nobody notices because the activity looks so much like work.

What the tools don't do

The most useful way I have found to think about AI in a design practice comes from flying. In naval aviation, automation is there to manage the aircraft so the pilot can manage the flight. The autopilot holds altitude and heading beautifully. It does not decide whether to divert, it does not notice that the weather ahead is worse than the brief said, and it is not accountable for the outcome. The crews that get in trouble are often the ones who let the automation's competence at the easy part lull them out of attending to the hard part.

Design works the same way. Hand the tools the mechanics, gladly. First-pass layouts, copy variations, placeholder content, resizing assets, documenting components, turning a sketch into something clickable for a test. Every hour saved there is an hour returned to the work that actually requires a designer.

That work has not changed much. Framing the problem before solving it. Talking to the people who will use the thing, and watching what they do rather than only what they say. Deciding what not to build. Thinking through the edge cases the happy-path demo skips: the user with a screen reader, the account with no data yet, the error at the worst possible moment. Holding a point of view about what good looks like for this product and these users. And carrying the accountability for whether it worked.

None of that can be generated from a prompt, because the inputs are not in the prompt. They live in research, in context, in the history of the product, and in the judgment of the people doing the work. A generated design is best treated as a draft that raises questions. The trouble starts when a team treats it as the answer.

What a design-driven culture actually looks like

A design-driven culture is not one where the design team does everything, or where every decision waits for a designer's approval. It is an organization where quality has an owner, a shared vocabulary, and a protected place in the process. In my experience, that tends to show up in a few concrete habits.

Design is in the room before the roadmap is set, not after. The biggest gains come from shaping what gets built, and that only happens if designers are part of discovery and planning rather than receiving a finished brief.

Critique is a ritual, not an event. Teams that care about quality look at work together on a regular rhythm, and they talk about it in terms of the user and the problem rather than personal taste. That matters even more now, because generated work needs to go through the same critique as anything else. A component that came from a prompt is not exempt from asking whether it is clear, accessible, consistent, and right for this context.

The bar is written down. What does good mean for this product? Which principles hold even when they are inconvenient? What will we not ship? Teams that can answer those questions are much harder to talk into a forty-second dashboard.

Done is defined by the outcome, not the handoff. A feature is not finished when the file goes to engineering or when the code merges. It is finished when we know whether it solved the problem it was meant to solve, and someone is responsible for going back to find out.

And leaders protect the time it takes to do this well. Culture follows what gets rewarded. If an organization only celebrates speed, it will get speed, and it will get the same generic output as everyone else using the same tools. If it rewards the designer who caught the flawed assumption before launch, it will get more of that instead.

Making the case in the language of the business

None of this sticks unless the people funding the work understand what it returns. Designers have historically been weak at this, and AI makes it urgent, because a leader who sees a polished screen appear in forty seconds will reasonably wonder what the design team is for.

The most cited evidence is still McKinsey's The Business Value of Design, which tracked the design practices of 300 publicly listed companies over five years across medical technology, consumer goods, and retail banking, drawing on more than two million pieces of financial data and over 100,000 recorded design actions. Companies in the top quartile of its Design Index saw 32 percentage points higher revenue growth and 56 percentage points higher total returns to shareholders than their industry peers over the period.

Two other details in that report matter just as much to me. First, the differences between the second, third, and fourth quartiles were marginal. The market rewarded the companies that genuinely stood out, not the ones that were merely competent. That is exactly the advantage that homogenized, generated output erodes. Second, more than 40 percent of the companies surveyed were not talking to their end users during development, and just over half had no objective way to measure what their design teams produced. The value was available, and most organizations had no way to see it.

The McKinsey findings are correlational, and companies that invest in design may simply be better run in other ways too. But they line up with what more targeted studies have found. A Forrester Total Economic Impact study of IBM's design thinking practice, commissioned by IBM, modeled a 301 percent return over three years and estimated a 75 percent reduction in the time spent on initial design and alignment. It is a vendor-sponsored study with a small sample, so I treat the exact number loosely. The direction is consistent, though: the return from design comes mostly from getting the problem right earlier, which means building less of the wrong thing.

That is also how I would frame it inside any company. Not "good design is important," which every leader already agrees with in the abstract, but specific costs avoided and gains earned. The rework that did not happen because a prototype test caught the problem in week two. The support tickets that did not get filed. The conversion rate on the redesigned flow. The churn on the old one. Leaders fund what they can see, and it is our job to make the value visible in the terms they are already accountable for.

AI's ROI problem is partly a design problem

There is a final irony worth pointing out. The same companies asking whether design is still worth paying for are pouring money into AI and often struggling to get it back.

MIT's Project NANDA, in its 2025 report The GenAI Divide, found that only about 5 percent of integrated AI pilots were extracting meaningful value, while the large majority showed no measurable impact on profit and loss. Among the reasons it cited were brittle workflows and poor fit with how people actually do their work day to day. That is not a model problem. It is a design problem: tools built without a clear understanding of the user, the task, and the context they live in.

Klarna offered a public example in 2025. After a heavy push to replace customer service staff with AI, CEO Sebastian Siemiatkowski told Bloomberg that the focus on cost had led to lower-quality support, and the company began bringing human agents back. The automation worked fine. The experience it produced did not.

People building AI products seem to understand this. In the same Figma report, 52 percent of respondents working on AI products said design is more important for AI-powered products than for traditional ones, and 95 percent said it is at least as important. When the underlying technology is available to everyone, the experience built around it is what separates the products people trust from the ones they abandon.

Wrapping Up

AI has not made design less valuable. It has made the difference between design and output impossible to ignore. When anyone can generate something that looks finished, the organizations that win will be the ones that can still tell whether it is any good, and that have built a culture willing to hold out for the version that is.

For designers, that means using these tools without letting them set the standard. Let them carry the mechanics. Keep your attention on the problem, the people, and the quality of the outcome, because that is the part of the job no one else in the building is going to protect.

For the businesses that employ them, it means seeing design as a source of return rather than a cost center that can now be automated. The evidence has been there for years. What changed is that it has never been easier to settle for less, and the companies that refuse to will be the easiest ones to tell apart.