A design handed to engineering is a promise that someone else has to keep.
James Touhey runs design at AnyTeam, and he said a version of that to us five different ways without being asked. Twenty years into design leadership, his full story is here; below are five short, unscripted moments from the same conversation. The mechanism, the craft it protects, the flow it unlocks, the thesis behind it, and why team size barely matters.
1. The mechanism: screenshot to shipped component
“It’s easier for me now to just go in. I can take a quick screenshot, I can easily locate the exact component that I’m wanting to change, and I can target that component. And then I start making the intended changes just through prompts. And if something is not getting done more efficiently through the prompts, I can switch over to design mode and I make those adjustments manually. And I know that it’s going into the codebase.”
What it means: That’s the whole pipeline: see it, target it, change it, and it lands in the codebase. No ticket describing the change, no queue, no translation layer between what the designer meant and what got built. Prompts carry most of the work, and design mode covers the last-mile adjustments with the tools a designer already knows.
2. The craft that usually gets cut
“The things that make the app special and fun and pleasant to use are often the things that get missed, and that’s where Autonomy really steps in for us to be able to add that polish and bring those moments to life.”
What it means: The examples he gives are “a lot of micro interactions and smaller prototypes,” which he calls “the moments that get skipped over by development teams,” especially at pace. Skipping them is rational triage; they’re never critical. They’re also the whole difference between a product that works and a product people love using. This is the work that survives when the designer can ship it.
3. When the tool suggests more than he asked for
“I’ll go in with a change in mind, of the original design, but then start seeing potential opportunities to further enhance that product or that feature. Autonomy is spitting back suggestions, like, hey, what if we try this, or would you want to do this? Which really gets you into a more creative flow.”
What it means: He goes in for one small fix and comes out having added more: “oh, well, let’s add some animation to it,” extra states, polish nobody scheduled. That’s the opposite of scope creep. The cost of acting on a good idea dropped so low that good ideas stopped dying in the backlog.
4. The thesis: why building first gets you approved
“If you can build something and deliver it to an engineer, and it’s already built, then you’re already 80% of the way to having that design approved. Whereas if you’re showing them a design and they’re the ones that has to build it, you’re less likely to see it all the way through. It’s going to be a lot longer road for you as a designer to get your design out into the world. So this is one of those tools that gets you that 80, even 90%. And now I’m trying to get that to 100%.”
What it means: When engineers say yes to a design, they’re agreeing to build it. That’s why the yes takes weeks. When the thing arrives already built, yes just means reviewing it. That’s James’s 80%: pushback on a design is mostly pushback on the work it creates, and here the work is already done.
5. It doesn’t care how big your team is
“I would imagine any size team could find this useful.”
What it means: He says it with credentials on both ends: a design team of one today, and years of “having led teams of much larger sizes” where he’d want the same tool “just because that would distribute the work” and let those teams ship as much as possible. Small teams get reach. Big teams get distribution. The constant is that design stops waiting.
Five moments, one pattern: the approval fight disappears when the thing is already built.
Your design team has its own version of this. Book 20 minutes and we’ll show you what it looks like at your scale: https://autonomyai.io/pre-meeting/schedule/
Discover what the future of product teams looks like!
