Fiuto: adding visual touches to working screens

Context

After the onboarding review of the previous part, this one covers the smallest change I make to the product: placing an illustration or an animation on a screen that already works, where the only decisions left are the asset, its size and where it sits. Fiuto is a working tool, and I wanted it to feel light, warm and a bit fun; the illustration set I chose carries most of that, a deliberate risk with the audience that I add to gradually. The choice of the set comes first here, then one Lottie animation placed on the onboarding welcome screen by talking to the lean agent, then what I set up afterwards so that a request to move a decoration stays a request to move a decoration.

Why decoration is left for last

The set is chosen once and the choice sets the register of the whole product. For Fiuto that meant a family of cats, dogs and other pets from Creattie, in their Lumo style, and the reason for choosing it is also the reason to hesitate: a lighter register separates the product from the serious tools it competes with, and it might put off part of the audience. PostHog and a few other software products had already taken that risk, which told me it could work for the customers I have.

The characters then have to be introduced in context, or the first one a user meets inside a working screen reads as a mistake. My plan at the time of the recording was to introduce them on the landing page, where illustration is expected, so that by the time someone reaches the welcome screen they already know the style and do not ask why there is a rabbit and a dog on it.

Each placement after that is a small job with a long path. The asset is sized and positioned in a Lottie editor before it goes anywhere near the code, then again on the page once a developer has wired it in. On most boards that is a ticket at the bottom of the list, and the cost of skipping it is a product that works and has no character. The cost of doing it without a boundary is the other one: a request to move an animation becomes a review of the screen it sits on.

01The pipeline

The lean agent, and the boundary I set afterwards

In the recording I use /lean directly, the small change skill from earlier articles, because the placement was the whole job and there was nothing to design. After the run I set up /ux-lean as its design side, for the case where an existing surface has one open visual question and I want to compare treatments before implementing one. The recording shows /lean at work and none of the stages that now precede it.

The decision I keep is the boundary itself: a request may change the asset, its size and its position on the one surface it sits on, and it may not touch a shared primitive, a second surface or the structure of the screen, and the moment it wants to, it leaves the speed lane for the larger process.

02The session

What is in this video

The dog is a Lottie file from Creattie, one animation out of a family of cats, dogs and other pets in their Lumo style, and the first minute is about that family. I explain why I settled on it, show the sign out screen where one of the characters already lives, and mention the welcome screens where I am adding more, hoping there is not too much for certain customers. At 0:59 I name PostHog as the precedent for a lighter register in a software tool, accept that it is a risk, and explain the plan to introduce the characters from the landing page so that they are familiar by the time a user reaches a working screen.

How I actually edit a Lottie animation comes at 1:47. The example is a small dog for the onboarding welcome screen. I add the file to the repository and talk to the lean agent: move it, increase the size until I am happy with it, then position it where I want it, in this case as a small decoration above the welcome heading. The state before the last adjustment is on screen at 2:29, where the Lottie box itself is visible on the page, and point out that this is exactly what I ask the agent to move. Normally this positioning happens in a Lottie editor. I cannot be bothered with one, so everything is done inline with the agent, on the rendered page.

4 min Watch on Loom

I close at 3:21 on the set itself: the Lumo animations are the ones I prefer, there are several other styles in the same family I could use, and they are good value.

The recording does not show a comparison of placements, and it does not show a verification pass. I adjust the dog by request until I am happy, which is fine for one decoration and does not scale to a screen with three of them. /ux-lean is that boundary written down afterwards: two or three rendered placements to pick from, and only then /lean on the page. Two other limits remain: inline placement does not replace an animation editor when the timing, the keyframes, the internal artwork or the canvas of the animation is wrong, and my liking the set does not prove that the audience does, which is a question for the full review, one surface at a time.

Conclusion

Most of the method consists in keeping the question small. One surface, one asset, one axis to settle, and the asset in the repository before anyone asks where it goes, so that the adjustment happens on the rendered page by asking. The question grows in two ways: when there is more than one placement worth seeing, the comparison belongs in a short design pass with the asset locked. When a placement raises a doubt about the screen it sits on, the decoration is no longer the job, and it goes to the full review.