Fiuto: adding visual touches to working screens
The small touches that give a product its character, an illustration here, an animation there, are usually left for last. Each one is placed, sized and moved a few times before it sits right, and every adjustment passes through a designer's tool and a developer's ticket. With the asset in the repository and the agent adjusting it on the rendered page, the whole exercise takes minutes. The discipline is keeping the question small enough that placing a decoration never turns into a conversation about the screen.
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.
Scope/ux-lean takes one existing surface and one question about placement, size, treatment or order; a new pattern, a change to a shared primitive, a multi screen flow or a doubt about the surface itself goes to the full /ux process.
Provider checkBefore anything is drawn it checks whether a third party dictates the asset’s form, and when the form is fully dictated the exact asset goes straight to /lean with nothing to design.
BaselineOne screenshot of the live page, keeping its chrome while only the open axis changes.
IdeateTwo to three whole surface renders; I pick one, seed one more round, or stop, and two rounds without a pick move the question to the full /ux process.
HandoffThe pick reaches /lean as exact markup with its files, the provider constraints and one or two observable checks, since a prose summary loses the placement and the order.
Implement/lean makes the smallest edit on its own branch, checks the real page at the relevant viewport, and opens one pull request.
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.
The session. Four minutes: why this illustration set, then one Lottie animation sized and placed on the welcome screen, adjusted inline with the lean agent and never opened in an animation editor.
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.
Move it, make it bigger, put it above the heading: three requests to the agent on the rendered page, with the animation box visible until the last one, for a file from a set chosen for the audience and introduced on the landing page first.
Sources
- Session recording ↗Loom, 4 minutes
- Session transcriptClaude Code, the run in the recording