Fiuto: designing new features with AI

Context

In the previous article I showed how I redesign complex components that are already implemented. This article opens a new arc: taking one new feature from design through to production. To deliver effective features it is key to ground the design process in research. Ideally this would include user research, but in constrained instances where time or budget would not allow it, it is still essential to review the market for references targeting your product audience, so that the features land right with them, to avoid confusion and increase your chances that the new feature will be usable for them. In this article I show how I use research skills within a coding agent to do that grounding work much faster than I could on my own, and how that can quickly inform design decisions.

What grounding a new feature involves

Without user research, the grounding available before design starts comes from four sources.

1. The product itself: which surface the feature joins and what it already shows, since that page sets the hierarchy, density and conventions the new element has to follow.
2. The data model and the tech stack: what the backend already exposes and what needs new work, so that agreed directions do not stall in delivery.
3. The roadmap: whether the capability belongs to the current stage at all.
4. The market: how comparable products expose the same job to the same audience, as the reference for patterns that audience already knows.

Each of these is normally a separate conversation with a different role. In the run below the agent covers all four from the repository, the roadmap and the market in the first twenty minutes of the session.

01The pipeline

The /ux family on a feature that does not exist yet

The same /ux orchestrator from the previous two articles handles a feature with no surface to review. The difference is the starting point: before any review or design it builds the product knowledge the build agent has, the repository, the data model, the roadmap, so the brief is written against the real product rather than my description of it, and the research is asked for in terms of my audience and competitive landscape instead of general UX advice.

The agent settles on its own what the code can show, what the page dictates and which reviewer findings become directions; it brings me four things: which direction answers the product question, what the next round may change, whether a round is still faithful to the page, and whether to hand off directly or go through translate first.

02The session

What is in this video

Which of my three concept validation studies had I shared, and with whom? The studies list could not tell me, so I give /ux that question with screenshots of the current product and run it on Opus 4.8.

The grounding scout separates a visual decision from a data requirement: private versus public can be shown with no backend work, collaborator avatars need a small backend change. It also flags that collaboration was still recorded on the roadmap as post alpha, while I had decided days earlier to release it before launch. The roadmap had not caught up, and the run caught the mismatch before any mockup existed.

The visual review makes one main point: no header chip and no sortable column, keep the lock beside the title and show avatars inline when the study is shared. The market review adds its list, and three directions arrive about twenty minutes in, rendered in the live app’s style. Option B puts my second account’s avatar on the one shared study and nowhere else, which answers the original question. I keep B and add the condition the agent had missed: long titles truncate at the end and push the sharing block out of view, so the next round truncates in the middle.

13 min Watch on Loom

The later rounds drift: the first mockups reproduced the page exactly, the next ones change its structure and drop details unrelated to my request, which would carry through translate as if they were requirements. I have the orchestrator record the current state (option B, middle ellipsis) as the requirement and review its own rounds for the drift, then fix the skill inline and restart from that state. Two more rounds settle a misaligned flex container. I then send the pick through translate instead of accepting the direct handoff the agent proposes, so that the build session starts from real components.

Drift entered this run in the second round, and the repair to the skill happened in the same session, between rounds, which is where most of the hour went and why the video is thirteen minutes while the run was not. The skill now hands every follow-up round the full markup of the picked direction, allows a change on the one axis I name, and has the orchestrator check each round for unrequested changes before it reaches me.

Conclusion

The screen, the data model, the roadmap and the market are four sources a team gathers by hand through four conversations with four roles, usually over days; here they arrived in twenty minutes from the repository, the roadmap and a description of the audience, and the roadmap mismatch surfaced with them. What I watch is the iteration: each round has to be held to the previous one, or the grounding established at the start is lost.