The onboarding journey from the prototype is implemented. I put a URL in one field and land in a study that is already populated and running. A study is what a researcher assembles in Fiuto and sends out to respondents, so landing in a built one is the activation moment I was after. The URL is the only thing I tell it about the subject, and I write none of the study myself. The flow asks me for a few other things along the way, and walking it there are several issues, but they are all refinements.
This opens arc four, on reviewing and improving. The arc before it put research in front of the pipeline so that the right thing gets built, and this one is about what comes back after implementation, when the thing works and is not good yet.
What the entry point had to do
The research pointed at two ends of the product. One was sharing on the insight pages, where a user gets AI insights from their study results and can pass them to collaborators or publish them. That half was built and running by the time of this recording, and it is what the delivery article in the previous arc covers. The other end is the entry point, and that is this one.
I already had an onboarding screen. It was enough at first and it was not great. At the time of this recording I did not have users and I was building towards the launch, and I wanted the entry point to capture as many people as it could and activate them. The app has soft launched since. With the sharing surface already at the other end, the thing I said I would work on next was the k factor, how many new users each user brings with them.
The prototype is the target
The prototype from the previous step was the template for the delivery. Generating it took a very long time. It runs from the list of blocks, the individual questions and tasks a study is made of, through to the study page with the study already built. The prototypes repo, which sits separately from the product, also has an onboarding chat in it.
That set the bar for the implementation. The goal was the prototype exactly. I would love to say that was easy, and it was not. It took several iterations to get there, and the result kind of works.
Walking the flow
This is the flow as it stood on the day I recorded it.
I am signed in with an email account, so the product does not know my name. The first thing it asks me for is my name.
The step after that is one I added during implementation. The agent did not have enough context to generate decent plans for the study, so I put another stage in the flow: a set of recommended next steps that the agent suggests, and I pick the one I want to do next. The plan comes out of that.
It takes a few seconds most of the time. It could take up to a couple of minutes, and on the run I recorded I had to stop and wait for it.
Then a goal modal, which I think the AI has placed in the wrong position. I have to fix that.
After that I land in a populated study with context, and I can preview it. It is a running study. The generated copy has em dashes in it. The product does not use em dashes, so I think that is a problem I need to fix as well.
The issues I found
This worked quite well. It captured what I would want from a test without me entering anything. I only had to enter the URL.
None of what I found sent me back to the flow. The name step was the flow working. The suggestion step was a number to bring down. The goal modal was in the wrong position and needed moving. The em dashes were a bug in generated copy. I was still working on the quality of the generation, so it was not perfect. As an alpha experience, the release I was building towards at the time, it was almost there.
What I did not do
I did not open Figma once, and I did not review any code. What I did was go through a series of iterations using skills. A skill is a named set of instructions I hand to a fresh agent, so it starts with the process already in its head, and the ones I use replicate processes that exist in real life, in product teams. Replicating those processes is what got me a result good enough for an initial delivery, I think.
Running this with your own agent
None of this needs my repo.
- Hold the implementation to the approved prototype exactly, not to its general shape. Budget for several iterations before the build matches it.
- Walk the flow yourself with the least informed account you support, such as an email signup with no name attached. That is where the missing data shows up.
- When an agent generates something poor inside your product, check whether it has the context to do better before you rewrite the prompt. If it does not, add a step to the flow that collects it. That is why there is a recommended next steps stage in mine, added during implementation rather than planned.
- Time every AI step in the flow. Mine takes a few seconds most of the time and can take up to a couple of minutes, and the couple of minutes is the number the step has to be designed around.
- Write down every issue as you walk it, then sort the list into what you fix on this surface and what means the surface is wrong. While everything stays in the first pile, what is left is a quality pass.
- Treat your own content rules as testable. If your product does not use a character, generated copy that contains it goes on the list as a defect.
- Check where the agent put things, not only that it built them.
- Judge the result against the release you are aiming at, and name that release when you write the verdict down.
The next article covers visual refinements on working surfaces.
