In 2013, we put a prototype in front of a driver. It was part of an instrument cluster that read the driver's biometrics, tried to tell when they were stressed, and offered to adjust the cabin to help. The driver's answer stopped us. The car was the thing stressing them out. Why was it offering to fix that?
A large auto parts manufacturer had brought us in to find out how biometric technology could improve the driving experience. Our research kept saying the same thing: the drivers we studied described driving as something to get through. The client didn’t like hearing it. They’d come in with an experience worth enhancing, and we were telling them it needed rescuing first.
That prototype was one of four cycles we ran in three weeks, each one measured in days and tested with real drivers. By the end, the client had reframed what they expected biometrics to do in the car. The technology would support the experience instead of trying to lead it.
Those three weeks mattered because of what came next. New cabin technology goes through regulatory scrutiny, and the runway from an approved direction to a shipping product was five years, minimum. If nobody had caught the wrong assumption until year two of a formal program, the cost would have been years of engineering and momentum aimed at the wrong problem.
The prototypes were cheap. What they bought was a decision.
Making got cheap
I think about that project a lot now. For most of my career, even with a mature build stack and a UI library, a fully fleshed-out prototype took a week or two. Now it can take a day or two, as long as the hard thinking happens up front.
That thinking is still the slow part, even with AI. AI can create the artifacts. Deciding what doesn’t get to move forward still takes a lot of human effort and time: the cutting away, the saying no, the simplification.
For years, the brake on a bad idea was what it cost to build. When a feature took a quarter of engineering time, a weak idea had to survive a lot of meetings before anyone wrote code. That brake is mostly gone. A team can now make nearly anything it can describe, so the list of things it could build has no natural end.
The cost of building the wrong thing is still there. It shows up as attention, as features someone has to maintain, as an experience that makes a little less sense with every addition, and as trust. I wrote about that last one in the post on trust: early hallucinations spent the trust professionals had in AI tools, and better models didn’t buy it back on their own.
A good experiment on the wrong question
Speed doesn’t keep you from being fast at the wrong thing. I learned that at a large Christian publisher around 2010.
Gaming was growing, and the publisher’s audience was there, so the move looked like an opportunity. They explored a handful of games aimed at young readers, and I helped build early prototypes for one of them, a Nintendo DS title. Testing did its job. User research showed there was no market, none of the games got funded, and nothing shipped.
By most measures, that’s a story about learning early. But the time, the leadership attention, and the people building and testing all went toward something the publisher was never positioned to win. Its brand and its distribution couldn’t buy it a place in a market it had never competed in. Nobody asked first why this was the publisher’s opportunity at all.
We ran a good experiment on the wrong question. Give that team today’s tools and they’d have had more prototypes, sooner, and the same mistake.
Where design leadership sits now
For most of my career, a design team’s value was tied to what it could make. We hired for craft and capacity. The roadmap often got decided somewhere else, and design’s job was to make it real and make it good.
If AI makes the making cheap, a design org that measures itself by output is measuring the part that just got commoditized. The quality of its choices is what’s left to judge it by.
When anyone on the team can make the screen, the design leader’s job is deciding which screens deserve to exist.
I didn’t get here from design alone. In 2022 I moved into corporate strategy work at a large professional services firm, and I brought design thinking with me because it was what I knew. It didn’t translate the way I expected. Without a clear choice on the table, a workshop would swirl for hours and never land. Roger Martin’s questions gave those sessions somewhere to land: where will we play, how will we win there, and what capabilities and management systems does that choice require? More than once, a P&L owner told me they’d never had that kind of clarity about their priorities.
Those same questions work for a design org. Where to play is which users and problems the team takes on, and which ones it turns down. How to win is what the experience has to do better than the alternatives people already have. The capabilities are research and judgment that can tell a real need from a convincing demo. The management systems are the reviews and measures that test the choice before they test the craft.
My own AI work has the same shape. I moved one of our assistants from business model innovation to disruption once testing showed people didn’t have the vocabulary to start where I’d put them, which I wrote about in What 25 Years of UX Taught Me. That was a where-to-play call. Moving scoring out of the model and into scripts was a choice about what the model shouldn’t make at all.
Peter Drucker put it plainly in 1963, in a Harvard Business Review article called “Managing for Business Effectiveness”:
“There is surely nothing quite so useless as doing with great efficiency what should not be done at all.”
AI is making that kind of efficiency nearly free.
What I’d try on Monday
If you lead a design team, here are three places I’d start.
Critique the choice before the craft. Make “should this exist, and for whom?” the first question in design review, before anyone talks about the pixels. If the team can’t name the where-to-play choice a piece of work serves, the polish conversation can wait.
Keep a “not building” list where everyone can see it. Every where-to-play choice comes with things you’ve said no to. When building is cheap, those ideas come back, because now they’re easy. A written list makes it a decision to reopen them instead of a drift.
Put a review date on the big calls. The decision coach I described in the conversational design post ends every decision log with a review date about ninety days out. A design org can do the same with its own bets, and judge itself on how many of its calls held up.
Still the driver
That driver in 2013 didn’t care how fast we’d built the prototype. What mattered was that they gave us a reason to stop.
Today’s tools can get a team to that moment faster than we ever could. They can also let a team skip it entirely and ship. Choosing between those two is the work design leaders should be hired for.
