Skip to main content

Forty options by lunch: leading a design team when output is cheap

AI made drafts almost free. A clear, shared bar for what good looks like is now the scarce part, and setting it is a leadership job.

Updated 6 min readMarkdown
Forty options by lunch: leading a design team when output is cheap

Picture a design lead at a mid-sized fintech team. She asks a designer for a few directions on the onboarding flow of a savings app. By lunch, the designer has forty. Some were sketched by hand, most were generated and refined with AI tools, and all of them look finished.

The review that afternoon runs for ninety minutes. The product manager likes the playful one. The engineer likes the one with fewer screens. Someone from compliance asks which version explains the lock-in period most clearly, and the room goes quiet, because nobody had written down that this was the thing to get right. The meeting ends with "let's sit with these," which usually means the decision will be made later by whoever has the most energy left.

Nobody did anything wrong in that story. The designer was fast and generous. The team was engaged. What was missing was a shared answer to a simple question: better at what?

I have led design and product teams for more than twenty years, and this is the leadership problem I find most interesting right now. AI has made output cheap. It has not made judgment cheap. A leader's job is shifting from producing and polishing to defining what good looks like, before the forty options arrive.

Speed is felt, trust is still catching up

The research points in a consistent direction. In Figma's 2025 AI report, based on a survey of 2,500 Figma users, 78% agreed that AI significantly enhances the efficiency of their work, but only 32% said they can rely on its output. The 2025 Stack Overflow Developer Survey found that 84% of respondents are using or planning to use AI tools, while more of them distrust the accuracy of those tools (46%) than trust it (33%). The most common frustration, cited by 66%, was "AI solutions that are almost right, but not quite."

Speed is felt. Trust lags.

"Almost right" is exactly what a design review has to catch, and it is harder to catch when every option looks polished. A rough sketch invites critique. A finished-looking screen invites approval.

There is also a gap between how fast work feels and how fast it is. In a randomised trial by METR with 16 experienced open-source developers in early 2025, tasks took 19% longer when AI tools were allowed, even though the developers had expected a 24% speed-up and still believed afterwards that they had been sped up by 20%. To be fair to the tools, METR's February 2026 update says developers are likely more sped up now than in early 2025, while cautioning that its newer data is only weak evidence of how much. I do not read either study as a verdict on AI. I read them as a reminder that a team's sense of momentum is not the same as progress, and that leaders need a better signal than "we made a lot."

AI amplifies the system it lands in

The finding I return to most often comes from the 2025 DORA report, drawn from nearly 5,000 technology professionals. Ninety percent use AI at work and more than 80% believe it has increased their productivity, yet 30% report little or no trust in AI-generated code. DORA's central conclusion is that AI does not fix a team; it amplifies what is already there. It also found that a user-centric focus strengthens AI's positive effect on team performance.

For design teams, I take that literally. If the brief was vague before AI, it is now vague forty times over. If the team already had a clear problem statement, real user evidence and a shared quality bar, AI gives them more good options to choose from.

Figma's report has a useful nuance here. Among teams whose AI projects met or exceeded expectations, 60% said they explored multiple design or technical approaches, compared with 39% of teams whose projects fell short. So the answer is not to generate less. Exploration still pays. The discipline has to move to how we choose.

How I run reviews now

Over the past year I have changed how I run design critiques, and the changes are small enough that any team can try them.

The review, rebuilt for cheap drafts

Write the bar before anyone generates. Every brief now ends with three to five lines that describe what good means for this problem. For the savings app, that might be: a first-time saver understands the lock-in period without scrolling, the flow works on a low-end phone, and the tone feels calm, not salesy. The forty options are then judged against those lines, not against each other.

Ask for the shortlist and the reasoning, not the gallery. I still want to know that the designer explored widely. But in the review I ask to see two or three options and a sentence on why each one survived. The craft I am looking for has moved from the file into the reasoning.

Keep a short log of what was rejected. One line per discarded direction, with the reason. It takes minutes, it stops the same debate from returning a month later, and it is one of the best coaching tools I have found for junior designers.

Let evidence break ties. When two options both meet the bar, a quick test with five real users or a look at existing data is now cheap enough to be the default. It also takes the pressure off seniority as the deciding vote, which I think is healthy for any team.

What this changes for hiring and growth

When I interview designers today, I still look at portfolios, but I spend more time on the decisions behind them. Which option did you drop, and why? What did you check before trusting a generated screen? How did you know it was done? These questions tell me more about how someone will lead a review in two years than the polish of any single screen.

I also try to protect time for craft. Generated work is a starting point, and the team needs people who can tell when spacing, wording or hierarchy is almost right but not quite. That eye is built by doing the work, and leaders should make room for it rather than treat it as optional.

The leader's job, restated

The designer in my opening story did not need to slow down. She needed a bar to aim at. When output is cheap, the most valuable thing a design leader can produce is clarity about what good looks like, written down before the work begins and used consistently when it ends. The tools will keep getting faster. The quality of our choices is still ours to own.

Naresh Pentapati is a design and product leader with more than 20 years in UX, product management and AI-enabled design. He writes about design, product, leadership and AI.

No comments yet. Be the first to comment.