The design process is changing. Here's how our product design process adapted.

We've been designing products and brands for over 15 years at UntilNow, a digital product design studio in Sydney. We've watched tools come and go. We've survived the Sketch-to-Figma migration, the rise of design systems, the componentisation of everything. None of that changed what design fundamentally was.

AI is different.

Not because it replaces designers. It doesn't. But because it collapses the cost of exploration so dramatically that our product design sprints have shifted in sequence entirely. The order matters now. The tools matter less.

Here's what our process actually looks like today.

Start with chaos

Every project begins the same way it always has: with too much information and not enough clarity. Client calls, stakeholder interviews, product briefs, competitive research, half-formed ideas scribbled in Notion. The difference now is that we don't spend days trying to organise all of that before we start working.

We dump it. Transcripts, notes, voice memos, raw documentation. Straight into Claude. Unstructured, unfiltered, uncontextualized. We let the AI parse the mess while we focus on asking better questions.

This isn't laziness. It's how we move from "information gathering" to "problem definition" faster, and get to decisions that matter sooner. Lowest friction wins.

Scope with an AI research partner

This is where things get properly useful. We go back and forth with AI as a research assistant — not to get answers, but to sharpen the questions. It asks things we hadn't considered. We describe the problem and in doing so, understand it better. Classic rubber duck debugging, except the duck talks back and can run web searches.

We kick off subtasks: pull in competitor analysis, generate comparison tables, draft preliminary information architecture, surface related documentation from elsewhere in the project. The AI is finding haystacks that might contain needles.

At this stage, we're not designing. We're scoping. And scoping well is half the battle.

Build it badly on purpose

This is the part that took us a while to embrace.

AI is terrible at design.

Not UI in the superficial sense — it can generate something that looks like an app. We mean real design: application structure, affordances, microcopy, the relationship between information and interaction, integration with existing products. The stuff that makes something feel intuitive rather than just look complete.

But here's the thing: a terrible build is a better starting point than no build.

Rather than beginning from a blank canvas, we start from a functionally sound but poorly designed prototype. Something that works, sort of, but makes every wrong decision about hierarchy, density, and flow. Three months ago, this would have been a dead end. The cost to rework bad decisions used to be prohibitive.

Not anymore. We can tear it down and rebuild ten times in a day. That badly built scaffold is raw material. Our job is to find what's trying to emerge from it.

Creative direct the hell out of it

Now we put on the creative director hat and start shooting holes. No gentle feedback. No constructive sandwich. Just: "This is wrong. This is cluttered. This shouldn't exist. Why is this here?"

We find every edge case. Every missing screen. Every error state, every hover affordance, every piece of information that's being shown when it should be hidden. We cut everything down to its absolute minimum.

AI is a maximalist. It'll throw colours, chips, icons, headings, categorisations, and cards everywhere — like it's vomiting UI components across the page. To an untrained eye, it looks like a product. To a designer, it's noise.

The difference is that now, stripping it back to signal costs almost nothing. We can be ruthless because rebuilding is cheap. The garbage prototype becomes the foundation for something genuinely considered.

Refine without Figma

We push the prototype as far as we can without touching traditional design tools. We refine the information architecture, get the data presentation right, nail the interaction patterns, make it feel functionally real.

But there's a ceiling here, and we've learned not to pretend otherwise.

Text and voice as design mediums are too imprecise. You can't polish iconography through conversation. You can't create uniform componentry by describing it. Every time you introduce new functionality, AI adds new button styles, forgets elements that already exist, and starts bloating the prototype with inconsistencies.

It's tempting to stay in this phase forever. The progress feels fast. But the ceiling will never be high enough for the standard we hold ourselves to. Continuing indefinitely here is folly.

What this phase is excellent for: stakeholder feedback. Getting other eyes on functionality, interaction patterns, and information flow before investing in high-fidelity craft. Once the team can see where you're heading, it's time to move on.

Gut it. Save the context.

Everything we've built up to this point is useful, but it's also full of dead code, poorly articulated decisions, and structural debt. So we do something counterintuitive: we throw away the code and keep only the thinking.

We generate a clean set of markdown files — context, constraints, history, architectural decisions — that will inform the next build. No code. Just knowledge.

At the same time, we screenshot every state we can think of: every permutation, every edge case, every flow we want to refine at a higher level. This becomes our design brief for the next phase.

Figma and craft

This is where we used to start. Just a few months ago, this was step one.

Now it's step seven. And it's still indispensable.

We take our screenshots, our context documents, our user flow diagrams, and we go into Figma. Auto layout. Design tokens. Typography scales. Colour systems. Component reuse. All the rigour that 15 years of product design has taught us matters.

After all the AI-assisted progress, this feels slow. But it's where the real craft happens.

In Figma, we explore affordances, microcopy variations, layout orientations — all the things that were high-friction in the AI prototyping phase become low-friction here. We find novel solutions we didn't think of before, because our medium is now visual, not conversational.

We still hit flow state here. We still come up with our best ideas here. That hasn't changed.

What has changed: we need far fewer screens than we used to. The ideation has already happened. But the output is higher polish than anything AI can generate on its own.

Build it again, properly

Now we take the design files and context documents and start a clean build. This time, with precision. We reconcile the Figma mockups against our earlier context — catching conflicts, resolving edge cases, tightening the spec.

There's a significant tooling gap here. The Figma-to-AI translation layer is still underpowered. Screenshots alone aren't enough. Ideally, we'd pass through component names, structure, text content, colour tokens, prototype flows — the full picture. We're not there yet. But we're getting closer.

This phase mirrors how we've always worked with developers: review the spec, ask questions, identify gaps, align on implementation. The AI just moves faster through the first few iterations.

Hand off to a real developer

We're a design studio, not a shipping platform. And we're honest about where AI stops being sufficient.

Performance optimisation. API integration. Production-grade code structure. Understanding what else is in flight across a product. Knowing what happens when something breaks and how to fix it without taking down the rest. All of this requires a developer with real context and real accountability.

Our prototypes are better than they've ever been — stateful, interactive, testable on any device. But they're still prototypes. The handoff to production engineering is as critical as it's always been.

For marketing sites and lightweight builds? Designers should be shipping code. We do, regularly. But for products handling serious users and serious money, we want an engineer we trust on the other side.

What's actually changed about design sprints?

The process is still design. It's still a cycle of exploring solutions, making decisions, refining craft, and shipping something that works for real people.

The difference is the order of operations and the cost of exploration. We compress weeks of early-stage ideation into days. We arrive at Figma with dramatically more context and conviction. We hand off to developers with prototypes that are closer to the real thing than static mocks ever were.

The tools will keep changing. The process will keep evolving. But the work is still the work: understanding problems deeply, solving them with clarity, and crafting experiences that people actually want to use. That's how product design sprints work at our digital product design studio — and that part hasn't changed at all.

‍