AI In The Product Design Loop, One Year In

A year ago, the question was whether AI tools would replace product designers. The question now, asked less loudly, is what changed in the workflow now that the tools have been around long enough to have a workflow position. The answer is more interesting than the original question, because the changes did not happen where the predictions said they would, and the parts of the work that look the same are not the parts that anyone expected to look the same.

The model accelerated the parts of the work that did not need accelerating, and made the parts that always mattered visible by contrast.

What got faster, in detail

The boring middle of the workflow is dramatically faster. A designer who used to spend three hours producing six layout variants for a stakeholder review now spends thirty minutes. A designer who used to draft placeholder copy by hand now generates several variants and picks the one that fits. A designer who used to write component documentation as a slow grind at the end of a sprint now generates a draft and edits it down. A designer who used to manually convert a desktop layout to mobile now does a first pass with a model and corrects from there. None of these are headline tasks. All of them are real time recovered.

The recovery is concentrated in tasks that share a property. Each of the accelerated tasks involves producing many versions of something the designer can already imagine. The model is unusually good at this. The designer’s mental image of what the result should look like exists clearly. The model interprets the brief, produces several plausible candidates, and the designer picks one. The pick-one step is fast because the designer’s evaluation criteria are clear before the candidates appear.

The time recovered adds up to roughly one to two hours per working day for a designer fully integrated with the tools. That recovery is real and would have been a major productivity story in any other context. In this context, it is the small part of the story.

What did not get faster, and why

The early thinking did not get faster. The decision about which problem the team is trying to solve, the framing of the user the work is for, the articulation of the trade-offs the design has to navigate, the choice of which approach to even consider exploring. None of this is faster with a model in the loop. The model can rephrase a problem statement, summarise research, or generate ten alternative framings. The work of deciding which framing fits the actual situation, in the actual organisation, with the actual constraints, remains a thinking task that requires the designer to hold the problem in mind.

The late polish did not get faster either. The work of taking a near-final design and making it ship-quality involves dozens of small decisions about spacing, alignment, hierarchy, motion timing, microcopy, edge case behaviour, and accessibility. Each of these decisions interacts with the others, and the interactions are subtle enough that a model’s suggestion is usually wrong in a way the designer can feel before they can articulate. The polish phase is where craft sits, and craft is where the model is weakest.

This produces a pattern. The middle compressed. The ends did not. The shape of the workflow is now hourglass-shaped rather than uniformly long, with the designer spending a greater proportion of total time at either end and a much smaller proportion in the middle. The implications of this shape are still working themselves out, and they are larger than the productivity gain in the middle suggests.

The anchoring problem nobody talks about

A real risk that has emerged in the year of integration is the anchoring problem. A designer who asks the model for layout ideas, sees the first batch, and starts thinking about the work in terms of the batch is letting the model define the design space. The model’s training distribution becomes the designer’s imagination. This is hard to notice from inside the workflow, because the model’s outputs are competent enough to feel like a useful starting point, and a useful starting point feels like an accelerator rather than a constraint.

The trap is most acute for less experienced designers, who have less of their own design vocabulary to bring to the brief. A senior designer typically has a clear mental image before opening the tool, generates variants of their own thinking, and uses the model as a fast renderer of ideas they would have arrived at anyway. A junior designer is more likely to outsource the early thinking to the model, accept the first plausible direction, and miss the better solution that would have emerged from doing the thinking themselves.

The fix is not technological. The fix is workflow discipline. A designer integrating the model usefully forces themselves to sketch their own ideas first, even crudely, before asking the model. The model becomes a faster way to render and test the designer’s ideas, not a generator of ideas the designer evaluates. This sequencing matters more than any feature the tools could ship.

Teams that have caught onto this pattern have started building it into their hiring rubrics. The interview question is no longer whether the candidate can use the model. The interview question is whether the candidate can describe what they would do without the model first, and then describe how they would use the model to go faster. Candidates who cannot answer the first half are flagged.

What the loop actually looks like now

The integrated loop, for a designer working at full speed, looks something like the following. The designer reads the brief and writes their own framing of the problem in plain prose. The designer sketches several directions on paper or in a note, without opening the design tool. The designer opens the design tool, picks the most promising direction, and asks the model to render two or three variants of it. The designer evaluates the variants against their own framing, picks the one that best fits, and refines it manually. The designer asks the model for help with the parts of the refinement that are mechanical, like generating placeholder copy or alternative icon options. The designer makes the final polish decisions by hand. The designer writes the documentation themselves, using the model as a draft surface they edit aggressively.

The loop is recognisable as the same workflow a designer was using two years ago. The model intervenes at three or four specific points to accelerate work that was always slow. The designer’s hand is on every load-bearing decision. The output is faster and at least as good as the pre-model output. The designer is, on average, less tired, because the boring middle is no longer the part that consumes the most attention.

The wrinkle about the parts that changed least

The most surprising thing about the year is that the parts of the workflow most affected by the model are not the parts the discourse has focused on. The discourse focused on whether the model could do the designer’s job. The model cannot. The discourse focused on whether designers would lose their craft. The craft moved more visibly into the parts of the work the model cannot touch, and the craft is now slightly more visible than it was, not less.

What the discourse missed is the structural shift in what designers spend their time on. A designer in 2024 spends a greater proportion of their day on framing, decision-making, and polish than a designer in 2022. The middle, which used to dominate the day, has shrunk. The designer who is good at the framing and the polish is now operating with more leverage than the same designer would have had two years ago. The designer who was good at the middle, and not as practiced at the framing or the polish, is in a more difficult position. The category did not disappear, but the shape of the work that pays its salary has changed.

Whether this is a net positive for the discipline depends on whether the discipline invests in teaching the framing and polish skills that the new shape of the work rewards. The teams that are doing this are pulling ahead. The teams that are still treating the model as a productivity tool layered onto the old workflow are seeing only the productivity gain, and missing the structural shift that is reshaping what their designers will be expected to do next.

The model in the loop is not the story. The loop did the changing.