Ask More Questions, Build More Prototypes: How AI Changed the Way I Design

I've been working in product for a little over ten years now. I started out in coffee roasting, of all things, and somehow ended up here, designing AI products alongside a team of developers. It's been a weird and wonderful path, and honestly nothing along the way has changed my day-to-day as much as coding agents have. Night and day doesn't even really cover it.

But here's the funny thing. The most useful lesson I've learned about working with AI didn't come from AI at all. It came from standing behind a coffee counter.

What coffee taught me (and keeps teaching me)

When you work in coffee, you figure out pretty quickly that people almost never tell you what they actually want. Someone walks up and says, "I'll have a coffee." Okay, great. Sweet or not sweet? Iced or hot? Milk? Oh, lots of milk. And a few questions later it turns out this person has wanted a caramel frappuccino with extra whip the entire time. They just didn't have the words for it yet, or maybe didn't know it themselves until you asked.

I think about that constantly, because it's the whole job. Stakeholders and clients come to you with "I want a coffee." They want a landing page, a dashboard, a login flow. The job then becomes asking enough good questions, gently, to find the frappuccino hiding underneath.

Coding agents haven't changed that part at all. People are still people. What's changed is that now, instead of just asking questions, I can build six or seven different frappuccinos in an afternoon, line them up, and ask, "Is it one of these?" And it almost always is. Or it's close enough that someone points at one and says, "That, but with the caramel from the other one." Which is perfect!

Before and after: our marketing website

Let me give you a real example, because the difference is hard to comprehend until you see it in action.

Designing something like our marketing website used to go roughly like this. I'd spend several days going from stakeholder to stakeholder, sitting down with each one, interviewing them, sketching ideas together. Then I'd go away and turn all those sketches into something cleaner in Figma, hold another meeting to walk everyone through them, take notes, go back, do one or two more rounds of that. Once we'd finally landed on a direction, I'd pair up with a developer to actually code one of the options, and then we'd iterate on that a few more times. Start to finish, we're talking weeks. Sometimes longer, if calendars didn't cooperate (they never cooperate).

Now? I can code up six or seven working prototypes in an afternoon. Actual clickable things you can poke at and break. I bring them to stakeholders, and we react to real things instead of imagining them. The ideas that hold up can move into development—or ship directly when they meet our team's coding standards. The research, and the work of asking good questions, matter as much as ever. What's changed is the loop between a question and something you can actually click: it has collapsed from weeks to hours.

To me, this isn't just about doing more with a smaller team. It's about creating the capacity for more: a team of five can take on work that might once have required twenty, and a larger team can use that leverage to serve more clients, tackle more projects, and create room for new opportunities. The goal isn't simply to shrink the team around the same workload. It's to help teams grow their impact and take on work they couldn't have reached before.

For tools, I lean on a lot of what we've built in-house: Nexus, our open source LLM gateway, Vortex code (coming soon, watch this space), and a handful of other internal tools. There's something fitting about designing AI products with the AI products.

My first merge request

For most of my career, I've been product-facing, not developer-facing. I made the designs, developers made the software, and there was a nice tidy handoff in between. Then at some point I started vibe coding little apps at home, just for fun, nothing serious. When I joined 10x, I was encouraged to put that skill to the test by reworking the UX of a login page—and opening my first real merge request at work.

Tiny feature. Huge deal for me. Up until that moment, "designer who codes" was something I did on my couch, not something I did in the actual codebase with actual reviewers. Now opening MRs and reviewing designs-turned-code is just... part of my week. The handoff has turned into a conversation. I'm still upskilling constantly, and I lean hard on teammates who have years of experience building this kind of software securely. In turn, they lean on me for the design side: which of these options will feel intuitive, which will make users squint. Neither of us could move this fast alone.

The artist's studio

I won't pretend the blurring of roles is all smooth sailing.

For developers, stepping into the design space can be genuinely uncomfortable. Design is messy. Things are less defined. You have to hold multiple different approaches in your head at once, pivot quickly, and adapt to new requirements on the fly. That's a tough shift if your craft is built around structure and precision, and I really admire the ability to build deeply solid, well-engineered software. Those instincts are critically important now more than ever; they’re just being stretched in new directions.

The way I think about it: our workspace now feels a bit like an artist's studio. There are half-finished canvases everywhere, lots of paint on the floor, and the goal is the painting at the end. For us, those canvases are early prototypes—ways to explore ideas, learn what works, and spot what doesn't before a product is ready to ship. The finished painting is solid, well-engineered software; that's the real measure of success. Getting to it takes communication, iteration, and the freedom to test imperfect ideas early. We learn from those experiments, then refine, review, and bring the strongest ideas up to our team's standards before they reach users. That gives us more room to explore and helps make the final product better.

Straightening the roads

Here's the thing nobody warns you about with all this speed: it shines a very bright light on every inefficient process you've been quietly tolerating for years.

It feels like a winding road down a mountain. The processes we built in the past are the roads, and they were fine at the old speed. Take those same hairpin turns at ten times the speed and suddenly it feels overwhelming, even dangerous. So the question isn't "how do we drive faster?" It's "what if we straightened the roads?"

So that's what we've been doing. Concretely, that's meant cutting way down on the number of docs and approvals it takes to create and ship a prototype. It meant killing our daily standups entirely and replacing them with a water cooler channel, a place where you can drop ideas as they happen, bring your work to the forefront when it's ready to show, and celebrate wins without waiting for a meeting slot. Less ceremony, more momentum. It turns out a lot of our process existed to manage slowness, and once the slowness was gone, the process didn't need to exist either.

Plug and play

Our strategy in this new way of working is honestly pretty simple. Start with the goal. Get clear on the mission we're trying to accomplish. Then find the most user-friendly, straightforward path to get there. Plug and play, so to speak.

There are speed bumps, and there are plenty of challenges ahead. The roles will keep blurring, the roads will keep needing straightening, and we'll keep getting things wrong on the way to getting them right. But working alongside a team of genuinely smart people who are all willing to step outside their old job descriptions, I believe we can make great things happen here.

And if you come to me saying you want a coffee? Fair warning: I'm going to ask you a few questions first.