I had three concept validation studies sitting in my own product and I could not tell which one I had shared with which people. A study is a set of questions and tasks I put in front of respondents, and a concept validation study is the type where I check an idea before building it. The users screen told me who had an account and that one person had not accepted the invitation yet. The studies list told me nothing about who each study went to.
Arc one covered redesigning components that already existed in the code. This article opens arc two, which builds one feature end to end, and this is the design leg. The feature did not exist yet. The list it lands on did, and that is what the design had to fit.
Everything that worked in this run came from grounding, and the one thing that went wrong was the grounding decaying between iteration rounds.
What the agent gets before it designs anything
I was about to run this with Sonnet 5, but I had not tested it yet, so I went back to Opus 4.8.
I attached reference screenshots of what the product looked like at the time. I did not need to, the agent would have found it on its own. It just simplifies the job.
Then the grounding instruction. I run this through /ux, my design skill. A skill is a written instruction file that Claude Code loads and follows. I asked for the ideation to be grounded on good research. Left generic, that can mean anything. Here it means competitive analysis, market research, and the specific audience we have. Not Nielsen advice, not general UX advice.
It follows a review and build doc, which informs the agent how to orchestrate the task, then goes through the same pass the build agent goes through, the one that plans and implements: the repo, how the app works. Good product knowledge before it acts.
The scout goes into the code first
The orchestrator is the /ux session itself, and the first thing it launched was the grounding scout. That is a sub-agent with one job: read the code and map the full sharing model. Before the research and the design start, it knows what the features are and what can be displayed in the app and in what context.
It came back with grounding on the code, questions already answered, and two things flagged. Private versus public can be shown on the list with no extra backend work. The collaborator avatars cannot, not without a small backend ask. I knew the cost of each direction before design started.
While that ran, an alert came up. At the time of this recording, collaboration sat post alpha on the roadmap. A couple of days earlier I had decided to release it before launch, because it was valuable to me as a k-factor feature, one that brings new people in through the people already using the product. The decision was fresh and not in the roadmap yet, so I had to update that too. The app has since soft launched.
Two reviewers, then three directions
Next is the render verify, which confirms what the screen looked like at that point, then the review of it.
Both reviews came back. The first was visual craft, and its headline point was not to add the sharing state to the row as its own column. Keep the private versus public lock beside the title, and show the avatars if the study has been shared. It is obvious once you have looked at the market.
The second was the market pattern one, and it returned its own list. I had not been through it in detail. The orchestrator synthesised both, settled on three directions, and dispatched them to the ideate agent, the step that generates whole-screen mockups I could look at.
Judging the round against the question I started with
The first round landed about 20 minutes in. It was already much better than what we had, and very close to the list design already in the app, which is what made the decisions fast.
I could tell one of them was not good enough, and so could the agent. The locks were identical, so it did not fit.
The real test is the requirement I started with: which concept validation did I share with my second account? In option B that account’s avatar is on one row and not the other, so I know immediately. In another option I could work it out, but not clearly.
The agent also said B was probably the better one, then recommended a hybrid of B and C. I was happy with B as it stood, so I took B.
What the agent had not noticed was truncation. When the title is long the text crops at the end and the sharing block goes with it. I always need to see that block, so the priority is the block, not the title length. That went into the next round.
The grounding decays as the rounds go on
The further you go with iterations, the more the agent loses fidelity. The early mockups are very close to the real design. Studies, create new, the search box, the table, even the priority dot matches what is in the app. A few rounds on, the detail goes. It forgets about the grounding.
When I had the agent review its own artifacts, it noticed the same things I had. It had completely changed the structure of the page, plus a few more items, none of them requirements passed in the prompt. It is drift the agent introduced by making things up. The agent went off to investigate why.
The translate agent, which turns a picked mockup into real components, cannot tell a requirement from an artifact.
So I stopped instead of iterating through it. I wrote the requirement down for the next round: option B, the one with the middle ellipsis, so the title cuts in the middle and the sharing block stays visible. Mobile was decent. Then I fixed the skill inline with the agent, so the drift would not happen on the next round either. Then I ran the round again from fresh, specific requirements, instead of continuing the chain.
This is still something I need to work on.
Where it ended
It took two more rounds after that, because of an alignment issue on the avatar, sender and admin group on the right hand side, caused by a flex container.
Apart from that, I thought this was good enough. The agent recommended going straight to handoff. I decided to go through the translate agent instead, so it would generate real components, and hand it to a build agent in a separate session. I expected translate to work well from there, because what was left was very targeted.
Beginning to end this took about one hour, but I had to edit the skill in the middle. Normally it is about 20 to 30 minutes.
Running this with your own agent
- Start from a question you cannot answer in your own product today, and write it down first. Every mockup gets judged against it.
- Say what the design is grounded on and what it is not. Competitors, your market, your audience, rather than general usability advice.
- Send a scout into the code before design starts. One agent, one job: map the model this feature touches, and report what can be shown for free and what needs backend work.
- Get a render of the screen as it is today, even when the feature does not exist. It constrains the design and it is your baseline for every round after.
- Review with two lenses. Visual craft and market pattern find different things, and the orchestrator synthesises both, not you.
- Ask for three whole directions, not three refinements of one.
- Judge each one against your original question, at a glance. If you have to work the answer out, it fails, whatever the agent recommends.
- Compare each round against that baseline, not the previous round. When detail starts leaking, stop the chain, fix the instruction that let it leak, and restart from written requirements.
- Do not hand mockups to implementation. Put a translation step in between that maps every element to a real component.
The next article covers the design-to-dev handoff.
