What Actually Works in an AI-Assisted Design Workflow

I’ve tested a lot of AI tools over the last two years, and most of them didn’t save me any time. They just moved the work around. Instead of designing, I was fixing what came back and explaining why the generated screen didn’t match our design system.

A few things did stick, though, and I wouldn’t go back.

Research synthesis is the big one. I give a model a stack of interview transcripts and ask for themes and anything that contradicts them. What used to take a couple of weeks takes a few days, because my job changes from finding the themes to checking them. And I do check them. Models will happily invent a pattern, or make the findings sound much tidier than the interviews were.

It’s also great when I need lots of options quickly, like ten layout directions or five versions of a microcopy line to test. A day of exploring turns into about twenty minutes. I rarely ship any of them. I just get to the choosing part faster.

First drafts of documentation help too. I edit them into my own voice, and the editing is often where I work out what I actually think.

Research synthesisSurface themes, contradictions and gaps across 20+ interviewsA couple of weeks → a few days

Generating quantityTen layout directions or five copy variants for early explorationA day → about 20 minutes

First draftsDocumentation, design principles, annotation copyBlank page → a draft to edit

I rarely ship any of it. The time saved is in exploring, and the first draft still needs me.My estimates, not measured.

Where it wastes my time is anything that needs precision early on. The model doesn’t know my users, my product or the endless conversations that shaped the brief. Its output looks informed, so it takes a while to notice it isn’t, and by then fixing it costs more than starting over would have.

Generated production UI is the other one. It drifts from the design system and leaves developers to reconcile the difference. I’ll use it to explore and then close the tab.

The trap is iterating on whatever the AI gives you, because you end up stuck with its assumptions. I look at the options, figure out why the good ones work, and build from that in my own tools.

My rough rule is that AI helps when the task is clear and I can hand over the context. It struggles when the problem is fuzzy or the important context is in someone’s head, which, in my experience, describes most of the interesting work.

AI works here

Well-defined taskClear scope, known constraints

Context is availableYou can give the model what it needs

Speed over precisionVolume and variation matter more

Goal is explorationA first pass to react to

Human work

Ambiguous taskProblem definition still in progress

Context lives in your headCan't be fully written into a prompt

Precision is criticalWrong specifics create real problems

Goal is the decisionThe work is the judgment

Defining the problem, making the call and pushing back on the brief all sit in the right column.

Would you hand this to AI?

1 of 6

The task

Theme 20 interview transcripts

0 of 6

We’d have a good argument in a design review. Have another look at the two checks on the ones we split on.

Illustrative example

Tamara Milakovic is a senior product designer specialising in B2B SaaS, design systems, and the decisions upstream of the brief.

What Actually Works in an AI-Assisted Design Workflow

When to Standardise and When to Leave It Alone

Clarity Was Never the Finish Line

The Brief Is Rarely the Whole Problem