Fiuto: refining a feature after implementation

Context

The onboarding flow prototyped in the previous part, from a URL to a built study, gave the build agent an exact target. This part opens the last arc of the series, on reviewing what comes back after implementation. The flow in the recording works, I enter a URL, answer two questions and land in a populated, running study, and it is also not finished; the article is about how I tell the two apart and how the skills that designed the feature are used again to refine it. With agents doing the delivery this review carries more weight than before, since the iterations spent matching the prototype go on getting the flow to work before anyone looks at whether it works well, and this flow decides whether a new user activates.

Walking the flow as a new user

The review in the recording has four parts, and each one is a place where a fix can grow into a redesign if it is skipped.

1. Name the target the implementation was meant to match. Here it is the prototype from the previous part, which took a very long time to generate and several iterations to reproduce in the product, so the comparison is against something specific.
2. Walk the journey with the least informed account you support. I sign in with an email account, so the product does not know my name and the first step has to ask for it; an account with a full profile would have hidden that step and what it costs a new user.
3. Note every defect with its kind: the input available to the model at each step, every wait and its worst case, every element in the wrong place, every generated output that breaks a product rule. The kind decides the fix, and mixing them produces one large ticket where four small ones were needed.
4. Decide whether the approved journey is still correct. A slow step, a misplaced modal or a content defect keeps the flow; a user who cannot supply the context the flow needs, or who should not be in the journey at all, reopens the design.

01The pipeline

The /ux family on a surface that already ships

The refinements go through the same /ux orchestrator that designed the flow, and the run in part 2 shows it at length on an implemented component. On a shipped surface it starts from the live source, and the stages that follow hold each round to the one before it, so a refinement request cannot widen into a redesign on the way through.

The one decision the pipeline leaves to me is a question I put to each finding: does this refine the journey we approved, or does it reopen it? Which direction to lock in each round and which path each fix takes both follow from that answer.

02The session

What is in this video

A URL goes in, two answers follow, and a populated, running study comes back; the six minutes cover how that flow got here and where it falls short. The recap comes first: the weekly research agent from the previous arc had pointed at two ends of the product: sharing AI insights from the results pages with collaborators or publicly, built and running by this recording, and the entry point, where I had an onboarding screen that was enough at the start. With a strong sharing surface at the other end, the k factor was the next thing I planned to work on. The prototype that served as the template for delivery is on screen at 1:39: the list of blocks, then the study page with the study built, with an onboarding chat also in the prototypes repository.

From 2:27 I walk the implemented flow. Signed in with an email account, I enter my name. The next step did not exist in the prototype: I added it during implementation because the context available to the agent was not enough to generate a decent study plan, so the flow now generates recommended next steps and asks me to pick one, and that choice supplies what the plan was missing. The suggestion usually takes a few seconds and can take up to a couple of minutes, and I pause the recording while it completes. The screen that follows shows a goal modal I had added, placed by the agent where I think it should not be. The flow then lands me in a populated study with context, I can attach a file, and in preview it is a running study whose generated copy uses dashes the product’s copy rules exclude.

6 min Watch on Loom

The verdict comes at 4:10. There are several issues and they are all refinements: the flow captures what I would want from a test without my entering anything beyond the URL, the generation quality still needs work, and as an alpha experience it is almost there. I did not open Figma once or review any code to get here; the work was a series of iterations through skills that reproduce the processes a product team runs.

The review rounds that fixed the four defects happened off camera, and the recording gives no elapsed time for the iterations that reproduced the prototype, so the six minutes show the walk and the verdict and nothing of the cost of getting there. Three checks came out of the walk and now sit at the start of a review. When generation is weak, the context the model had at that step is checked before its prompt is rewritten, and missing context is collected in the journey. The waiting state is designed for the longest wait observed rather than the usual one. The product’s content rules run as explicit checks on every generated output.

Conclusion

The four defects each say something about a flow an agent built. The missing name says the agent implemented against the account it was given, so the least informed account is the one that walks the result. The wait of up to two minutes says a generated step is designed for its usual case, and the worst case only appears when someone times it. The misplaced modal says that where the prototype gives no position the agent picks one, and that pick is reviewed like any other. The copy with dashes says a generated output obeys the rules that are checked, and only those. Sorting the findings by kind kept each of them a small fix, and the question put to each one, refine or reopen, set the size of everything after it. The refinements then went back through the stages that produced the feature, each round held to the last and each fix routed by how much it touches.