Fiuto: prototyping a whole user journey

Context

Not every research finding is the size of the one the previous part delivered. This one asked for a whole journey: users need an end-to-end flow that takes them into the app and to the activation point quickly, and onboarding is that flow. A change of that size is planned as a project with many issues, and a project cannot be reviewed the way a single screen can. This part covers the tool that generates a clickable prototype of the whole journey from the project the build agent had already planned, which I used to check the plan against what I had in mind and then to turn the agreed journey into tickets for the design agent.

Where one or two screens stop being enough

For a contained feature, one or two screens are enough for the agent to develop the whole thing, and that is what the /ux skill from the earlier articles produces: directions to pick from, then iteration on the pick. It does not generate a journey. I had built an onboarding screen earlier in a couple of hours, enough to collect some memory of the user for the agent to start from, and it was not a full cycle. The research finding asked for the full cycle, so I had the build agent map onboarding as a complete project and opened a separate session to work through it. By the time of the recording most of the issues were done, the agent was still working and the project was about halfway through.

At that size a plan stops being reviewable as text. The agent reports a great deal about each issue, and none of it shows the flow from beginning to end, so I could not tell whether what it described matched what I was visualising, and some of the remaining issues were blocked on that judgement. This is the point where someone builds a clickable prototype; skip it and the mismatch is found after the screens are implemented.

01The pipeline

The prototype skill

In the recording I describe the tool as a clone of Lovable built inside Claude Code: a way to create a prototype and iterate on it quickly, with one difference that matters for review. It uses Fiuto’s design system, it has the product knowledge the build agent has, it knows what the repository looks like and it draws its screens from my components, so the prototype of a journey looks like the product the journey will join. Prototypes live in a separate repository and deploy to prototypes.fiuto.ai, so each journey has a URL I can open and click through.

I confirm two things, one at either end of the prototype: before it is built, that the journey it is about to show is the one I want; after it is reviewed, which tickets survive the screen by screen pass.

02The session

What is in this video

The plan, at the start, is a wall of text: issue descriptions and agent reports that cannot be judged as a flow. I introduce the tool against that, then why I needed it. The research feedback from the routine agent appears at 1:48, with the point that mattered: users need a full end-to-end flow that takes them to activation quickly, with or without assistance. By 2:37 the project the build agent mapped from that finding is on screen, with most issues done and the agent still working, and explain that part of it was blocked until I could see the journey.

At 4:11 the prototype is open. It shows what the end flow will look like in use, and that view was what I needed in order to decide with the agent whether to keep going. I move through the onboarding screens and arrive at the final point, the study page, which looks exactly like the study page in the app. From there I go back and forth with the agent on preferences, then to the UX definition: at 4:56 I show the tickets it generated for the design agent, which I review screen by screen before agreeing the final set, to be delivered as a pull request the build agent picks up.

8 min Watch on Loom

By 5:38 the agent has hit an error on a very long task and I pick it up again. I close by placing the work: onboarding has to be right from the very start, and it completes the loop I showed in the previous part, a researcher getting into the app, straight into a study, getting it done and sharing it. I hope the loop will lift activation and sharing in the app, and I say that I do not know whether it will. The last minute names another use of the same tool, running user tests on a deployed prototype directly from the coding agent, which I leave for a later part.

Two things went wrong in the run. The agent hit an error on a very long task and I restarted it by hand. And the prototype’s look came from the real components and tokens without any dependence on the app repository, a looser link than the recording claims; generated straight from the project and reviewed by eye, nothing held it to the plan on one side or the tickets to it on the other. The skill’s current sequence closes both gaps: it writes a journey map first, ordered screens, states, transitions and sample data, which I confirm before any prototype file is written. Once the direction is agreed, prototype-translate writes a build-handoff.md beside the prototype that maps each screen, state and transition to an existing component, a change to a shared one, something new, something that stays in the prototype, or a decision for me. A fidelity review then checks that handoff against the prototype before the build agent receives it.

Conclusion

A prototype can prove that a journey holds when walked from entry to end, and that everyone reviewing it is looking at the same flow. It cannot prove that the journey is the one the plan describes, or that the tickets written afterwards are the ones it shows; those joins are checked separately, and in this run I checked them by eye. It earns its cost when the decision spans several screens and their transitions and the plan for them is already written: generated from that plan in the product’s own components, it gives the review something to walk, and the tickets that follow are agreed against something seen.