← Back to LabDebora’s Lab / Publication

Same brief, same agent, three people. Did it build the same screen?

I gave one screen-design agent the same brief as a designer, an engineer and a PM, then added a design system and a pattern file to see what actually makes the result converge.

Written from practice↓ Read the field note

If a team shares one design agent, does it matter who writes the prompt? I gave the same agent the same brief three times: once as a designer, once as an engineer, once as a PM. Then I kept adding layers until the screens matched.

The setup

One agent in Claude, one brief: a workspace access screen where an admin approves or rejects member requests, with a reason when rejecting. Same model, same brief, three prompts written from three roles.

I ran it in rounds. Round A had only the brief. Round B added the TAP design system (tokens and twenty components) and a short rules file. Round C added one pattern file. Then I ran the designer prompt a second time to see how much changes by chance.

A design system fixes how it looks

Without a system, I got three different products: three fonts, three palettes, no shared components, and each screen covered different states.

With the design system, the visual drift went to zero: no hard-coded colours or sizes, the same type, 11 to 17 real components per screen, and empty, loading and error states in all three.

But the layouts still split. The PM version added a member view nobody asked for, in both rounds. And the button said “Reject” in one screen and “Decline” in another.

0Hard-coded values with the design system
3 / 3Same layout and copy with the pattern
3Token bugs the agents caught

A pattern fixes what gets built

Round C added a single “Review queue” pattern: layout, list, detail, the five states with their exact copy, what is out of scope, and a short copy glossary.

All three screens converged: two panes from 1024px, no extra views, Approve and Reject, the same five states. The error message reads “Couldn’t load requests.” word for word in every screen.

  1. Tokens and components: how it looks.
  2. Patterns: how it is structured and what it says.
  3. The brief: only what is new in this feature.

Repeating a run shows what is still open

Running the designer prompt twice kept everything the pattern fixed. What changed were the details it didn’t: the selected-row style, whether the request sat in a card, the avatar colour.

Those were the same kind of differences I had seen between roles. So they came from chance, not from who was asking. I moved them into the pattern. Running a prompt more than once turned out to be a cheap way to find the decisions a system still leaves open.

Along the way, the agents also caught real bugs in the tokens: values with no units, a tablet body size of 64 and a blue foreground identical to its background.

What this doesn’t prove

One model, one screen, three prompts I wrote myself, one run each plus one repeat. It is a signal, not a study. A real team would write prompts I wouldn’t, and a harder screen would leave more decisions open.

[ The screens ]

Three rounds, three roles.

Every screen as the agent delivered it, in its default state at desktop width. Click any screen to enlarge it.

Round A

Brief only

Three fonts, three palettes, no shared components. Each screen covered different states.

Round A screen from the Designer promptDesigner
Round A screen from the Engineer promptEngineer
Round A screen from the PM promptPM
Round B

+ Design system

Visuals converged. Layout, scope and wording still depended on who asked.

Round B screen from the Designer promptDesigner
Round B screen from the Engineer promptEngineer
Round B screen from the PM promptPM
Round C

+ Pattern

Same layout, same scope, same states, same words.

Round C screen from the Designer promptDesigner
Round C screen from the Engineer promptEngineer
Round C screen from the PM promptPM
Noise check

Same prompt, run twice

Structure held. Small visual choices the pattern didn’t fix changed between runs.

Round C screen from the Designer, run 1Designer, run 1
Round C screen from the Designer, run 2Designer, run 2