Should designers write prompts with ML engineers? Yes, where the output is the product

Yes, for the parts of an AI feature where the quality of the generated output is what the user experiences. What the designer adds is not better wording. It is a written picture of a good and a bad output for the user, with examples, and the judgement to score each attempt against it, while the ML engineer owns the model, the context and the evaluation harness.

The answer changes when the failures sit outside the prompt: in data, tools, permissions or state, in actions that are costly to get wrong, or in outputs a script can grade.

What a designer adds is a target, not wording

Tools already help with the wording. Anthropic publishes a prompt generator for teams without a first draft, and its prompt engineering guide assumes three things exist before anyone engineers a prompt: a clear definition of the success criteria, some way to test against them empirically, and a first draft. OpenAI's prompt optimiser, which OpenAI is retiring with its Evals platform by 30 November 2026, rewrote prompts from a dataset of outputs, and asked for "a Good/Bad rating and detailed, specific critiques" on them. A tool can revise the wording. Someone still has to say which outputs are good, and why.

That judgement is a product decision. It depends on who the user is, what they will do with the output, and what would make them stop trusting it. At Tcules, we think a designer who has done the research is well placed to hold that picture for the team.

Figma's AI team worked this way on Figma Make. Its Head of Product, AI, David Kossnick, told First Round Review in 2025 that "a designer wrote the first system prompt", and that the contractors who evaluated new versions every night used a Figma-created brand guide with examples of a good and a bad form of a feature. His stated problem was how to explain "what good looks like" to people other than himself. One caution about the example: Figma's team identified designers as the core users of Figma Make, so the designers' own taste was close to the users'. Where the users are not designers, the designer has to reach the user's view through research.

What we saw when a designer sat with an ML engineer

At Tcules, we tried this in an internal AI lab. Our co-founder and CEO, Jatin Leuva, described it in a conversation with Samy Melaine, founder and CPTO of Eden AI, published on 26 February 2025 and recorded in late 2024. The account below is the lab as it was then.

Alongside our design work, we had built our own separate AI lab, where a couple of ML engineers worked closely with a couple of UX designers, as an experiment. One designer sat with an ML engineer on a problem involving Indic languages. The starting point, in Jatin's words: "we knew what output we want for the user." What we found very interesting, he said, was that "the UX person was able to collaborate at the technical level", helping write better prompts with the engineer, and that "it somehow reduced the number of iterations that were going into the R&D". He described the loop each attempt goes through: try a change, look at the output, compare it, evaluate it, and go again.

This is one internal experiment, reported by our co-founder. It is not a study. The episode gives no count of the iterations, so we cannot say how many fewer there were. Our reading of why it helped, which is an inference: someone at the table could say quickly whether an attempt was closer to what the user needed, so fewer attempts were spent finding out.

Samy described a similar pattern from Eden AI's side. Eden AI is our client. Developers integrate its API, he said, and then share their workflows with product or business colleagues, who "recheck the prompt" and give feedback "to make sure the AI is doing exactly what the product needs it to do". That is a second observation from a different company. It corroborates ours; it does not prove it.

Why a designer should not prompt alone

The best evidence against designers writing prompts is about people prompting without a method. In Why Johnny Can't Prompt (CHI 2023), J.D. Zamfirescu-Pereira, Richmond Wong, Bjoern Hartmann and Qian Yang watched ten people without substantial prompt-design experience try to improve a chatbot. Participants explored opportunistically, not systematically. They made little use of the tool's error labelling and so did not find its systematic testing useful. Most declared success after a single instance of the behaviour they wanted, and participants often gave up after a first or second failed attempt, assuming the model could not do it. The sample was skewed towards STEM professionals and graduate students; two of the ten were designers. So this describes people new to prompting in general rather than designers in particular.

A designer with a strong picture of the user can still make every one of those mistakes. Judging a prompt on one conversation is judging it on taste. The engineer's harness is the correction: each change runs against the whole set of cases, and failures are kept as tests so they cannot quietly return.

The second caution is cost. Anthropic's guide to building evaluations describes human grading as "slow and expensive" and says to avoid it if possible, preferring more automatically graded cases to fewer hand-graded ones. So the designer's judgement should not become a queue in which every output waits for a person to read it. It should become examples and a rubric that automated graders apply, with the designer checking a sample. That check is not optional: Shreya Shankar and colleagues (UIST 2024) argue that model-based graders "inherit all the problems" of the models they evaluate and need human validation, and OpenAI's evaluation guide says to use human feedback to calibrate automated scoring.

The target moves once you see outputs

It is tempting to say the designer sets the target before iteration starts and the engineer iterates against it. Two studies of practitioners suggest the target cannot be fully set in advance.

Shankar and colleagues name the effect criteria drift: people need criteria to grade outputs, but grading outputs helps them define the criteria. In their study of nine industry practitioners, even those who graded outputs before writing criteria kept refining the criteria as they graded more. Some criteria only appeared once particular outputs had been seen.

A CHI 2025 study by Hari Subramonyam and colleagues at Stanford and Google points the same way. In 13 sessions with 39 practitioners in the United States and India, a UX designer, an engineer and a product manager prototyped a generative AI feature together. Teams struggled at first to define concrete goals, a cold-start problem, and in most sessions the product manager took charge of that early discussion. The authors also flag overfitting to examples: teams built prompts from examples of existing campaigns, which risked outputs tailored too closely to those examples, and in one session the generated examples were all very similar to the first. The authors describe the designer's question shifting from which design choices make a product easier to use, to "What model behavior will be most useful for users?"

Three practical consequences follow:

• Write a first target before the first prompt, with several varied examples of good and bad outputs, and expect it to change.
• Change it deliberately. Keep it in writing, versioned next to the prompt, so the engineer is iterating against a target that moves on purpose rather than against whoever looked at the output last.
• The owner of the target is whoever knows the user's expectations best. That may be the designer or researcher, the product manager, or a domain expert where the judgement needs one.

Who does what

A workable division of labour for prompt work on a feature where output quality is the product:

The last row is not prompt work at all, and no amount of prompt revision settles it.

When the answer is no, or not mainly

At Tcules, we have argued that many production AI failures show up in representation, authority, provenance and recovery, not in the prompt, and that model quality and prompt design often dominate in bounded, low-risk tasks. This article sits inside that view. A designer at the prompt helps less in these cases:

• The failures sit in data, tools, permissions or state. If the feature is wrong because it read stale records or could act on the wrong object, better wording will not fix it. The designer's effort belongs in how the product represents state and authority.
• The action is costly or hard to undo. A prompt is not a control. Permission checks, previews and undo have to live outside the model, and the designer's job shifts to the moment a person reviews or approves, covered in human-in-the-loop UX patterns.
• A script can grade the output. Where correctness is an exact match, a valid schema or a passing test, Anthropic's evaluation guide calls code-based grading the fastest and most reliable method. The designer defines what the output is for once; the engineer iterates against the check.
• The designer is not closest to the user's judgement. For an internal developer tool the engineers may be the users. For clinical, legal or financial output a domain expert should sit with the engineer. This is our judgement, not a finding from the research above.

How to run the first session

1. Before any prompt, the designer writes a short target: who the user is, what they will do with the output, what would make them distrust it, and several varied examples of good and bad outputs drawn from research.
2. The ML engineer sets up the model, context and parameters, turns the examples into an evaluation set and logs every prompt version against it.
3. Both sit together and revise the prompt while watching results across the whole set, not one conversation at a time.
4. When outputs reveal a criterion nobody wrote down, add it to the target and note the change.
5. Turn the designer's labelled examples into automated graders, and have the designer review a sample after each significant change.
6. Agree separately, with the right owners, what the system may read, act on and undo.

At Tcules, our AI Product Engineering work starts from product scenarios rather than a provider list. A scenario defines more than a user prompt: it names the person and the decision, the context and data the feature may use, the evidence the interface must show, the difficult and failed conditions, and the criteria for accepting the behaviour. That last part is the target this article argues a designer should help write.