Fiuto: designing new features with AI
When creating a new feature from scratch, product teams will first ground its direction in research and their product tech stack: at a minimum, they will need to look into practices and patterns their product audience will be familiar with, and make sure their tech and dev team can deliver the agreed solution as planned. Using coding agents, it is much easier and faster now to do that sort of ground research, but agents need to have appropriate context to properly inform decisions.
Before and after. The studies list at two desktop widths and on a phone, with and without the sharing context the session designed. Three rows, rendered from the Ladle story the session produced, chosen so the indicator’s whole range is on screen at once: private with nobody else, private and shared past the point the avatars run out, and public.
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.
- 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.
- 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.
- The roadmap: whether the capability belongs to the current stage at all.
- 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.
Grounding scoutMaps the sharing model in the code: what the feature can display, in which context, at what backend cost.
Render verifyCaptures the target surface as it is, so every later stage measures against the real studies list.
ReviewTwo reviewers, visual craft and market patterns; the orchestrator synthesises them into the directions worth drawing.
IdeateWhole-screen mockups per round; my pick plus one named change goes into the next.
TranslateThe agreed mockup becomes real components in Ladle.
FidelityThe Ladle render is checked against the approved mockup before handoff.
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.
The session. Thirteen minutes, from the product question to a mockup ready for translate. The run took about an hour because I fixed the skill mid-run; without that, this task takes me 20 to 30 minutes.
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.
The grounding pass took twenty minutes across the code, the roadmap and the market. The iteration rounds held to it only after a fix to the skill.
Sources
- Session recording ↗Loom, 13 minutes
- Session transcriptClaude Code, the run in the recording