CategoryProduct design

AI in the design workflow: where it helps and hurts

7 min read

AI cuts the cost of production in a design workflow and leaves the cost of decision where it was. The step that produces volume gets faster. The step that chooses what to ship still needs a person who answers for the choice. The common mistake runs the other way: using AI where judgment is required and doing by hand what was mechanical.

What changes when AI enters the flow

Two things get cheaper, and one doesn’t change.

The first is the cost of a first draft. Options for a name, a layout direction, a paragraph of help text or a spec outline arrive in seconds. That raises the number of options a team can look at in one sitting.

The second is the cost of review. Every draft has to be read by someone who can tell a correct claim from a fluent one. That review becomes the bottleneck, so it needs its own line in the estimate.

What stays is the shape of the flow. Discovery still needs a question a person chose to ask. Prioritization still needs an owner of the trade-off. Visual judgment still needs an eye that knows this product.

Which steps are production and which are decision

Sort the flow into two columns before you open a tool.

Production turns a decision already made into an artifact:

  • Name options for a component or a screen
  • First draft of a spec, a release note or a help article
  • Copy rewritten to a fixed length for another channel
  • Format conversion, table filling, translation draft
  • Boilerplate code, test data, sample content

Decision chooses what should exist:

  • Which user problem is worth solving now
  • Which of two designs is better, and why
  • Which research finding is real and which is noise
  • What the product will refuse to do
  • Who pays when the thing breaks

There is also a third group where it hardly matters: scheduling, file hygiene, status reporting. Automating it is cheap and dull, and it says nothing about your judgment.

AI is strong in the first column and weak in the second. Most of this post follows from that gap.

Where AI actually speeds things up

The gain is real in five places, and each one has a mechanism behind it.

A draft to react to. A blank page costs more than a bad draft. A model gets you past the blank page, and the team goes straight to arguing about content.

Volume of variants. Ten headline options in a minute are useful only if you have a way to choose. The tool supplies volume and you supply the filter.

Rigid format. Nielsen Norman Group describes its own editorial use of AI for clarity, formatting and critique, with humans holding editorial judgment.

A first pass on translation. A draft you then edit beats an empty file, and it never replaces a native reader.

Explanation on demand. A dense spec becomes a summary for another team, which shortens the meeting.

The pattern is the same in all five. AI shortens the distance between a decision you already made and the artifact that carries it.

Where AI gets in the way

The biggest risk isn’t a wrong answer. It is a well-written one.

A model produces a well-shaped paragraph about a user need it never observed. It sounds confident, and a tired reviewer accepts whatever sounds confident.

Four failures are worth naming.

Synthesis of qualitative research. A model summarizes what you paste. The summary keeps the average and drops the contradiction, the pause and the subject the participant avoided. That is usually the finding.

Priority decisions. A model can rank options by a criterion you gave it. It can’t answer for the consequence of the ranking.

Aesthetic judgment. A model can describe a style and generate variations of it. It can’t tell whether the screen feels like this product or like a template.

Numbers. A model produces a plausible figure with no source behind it. A percentage without a declared source is decoration, so this text explains mechanism instead of quoting a rate.

There is a second trap. Nielsen Norman Group records that one output is an example, not an evaluation, because the system is nondeterministic. The same prompt can give a better answer and a worse one. A test of one run only tells you about that run. Evaluating AI output shows how to set up that evaluation, and AI in research synthesis applies the same care to research.

What can’t leave human control

Some steps stay with a person. Not because the tool lacks skill, but because someone has to answer for them.

  • Data that identifies a user, and anything derived from it.
  • Sensitive information: health, money, legal position, credentials, minors.
  • Any decision that changes a person’s outcome, such as an approval, a rejection, a price or a ban.
  • Publication under a name. Nielsen Norman Group states the position plainly: AI can help write an article, but it can’t stand behind it.
  • The disclosure line. Where a rule requires a label, applying the label is human work.

Anthropic’s Usage Policy draws the same border from the vendor side. It separates universal standards from high-risk consumer use cases that carry an elevated risk of harm.

Google’s AI Principles add a public commitment to the same border. The page names human oversight, safety, privacy and fairness as obligations, not features.

The Google PAIR guidebook adds the product view. The chapter on errors and graceful failure asks the team to define what counts as failure and to offer the user a path forward.

How to review what AI produced

  • Ask for the source of every factual claim. No source, no claim.
  • Check each number against a primary document, never against the model’s own earlier answer.
  • Run the same prompt three times and compare the outputs. The differences show where the system is unsure.
  • Read the text as an argument. Note what it asserts and what would prove it wrong.
  • Test the output on the edge case you know best. That is where the failure shows first.
  • Budget review as its own task. A glance isn’t a review.
  • Record who approved the final version.

How to decide what to automate without losing the criterion

  • Automate the step whose acceptance test you can write in one sentence. If you can’t write that sentence, the step still needs a person.
  • Automate the step that repeats with the same input shape. Variation in the input is the signal to keep a human in the loop.
  • Never automate the step that decides what the other steps are for.
  • Keep the decision visible after automation. When a choice disappears into a tool, you lost the criterion, not the work.
  • Recheck when the model changes. A new version shifts the output distribution, and the old test may no longer measure it.
  • Treat every reversal as data. The moment you undo an automated decision is the moment the boundary sat in the wrong place.

Nielsen Norman Group documents researchers who automated recruiting, scheduling and data preparation. Their rule is to run in small batches, so a person still reviews the mix of participants.

Where the sources disagree

Two NN/g articles pull in different directions on who sets the method. The research-ops article puts the ops team in charge: analyze the workflow, pilot a tool with a small group, then support adoption across the team. The editorial article refuses that move, because NN/G doesn’t prescribe how authors write or think.

They agree on the boundary that matters. The tool may contribute words, and a named person holds the responsibility for what ships. The evaluation article adds the same rule from the measurement side: one run shows the system can do the task once, not that it does it reliably.

A week of work on this

  • Pick one production step and one decision step in your own flow, and label them.
  • Give the production step to a tool, with a written acceptance test.
  • Keep the decision step in a room with a named owner.
  • Add the review hours to the estimate before the work starts.

Then write the boundary down. A written rule outlasts the next tool and the next hire.

Sources

More articles

See all articles