Users didn’t need more generations. They needed a way to keep what already worked
A few weeks ago I noticed a paying user doing something I hadn't designed for very well.
They kept working on the same tattoo idea, but they were not really looking for completely new generations.
They were changing one thing at a time.
A color.
A supporting element.
The proportion.
Sometimes the main subject.
That made me think I probably needed a better history / continuation system.
I had already built a lightweight generation history page, but that mostly helps users find old results. It doesn't really help them continue from one.
The obvious next step looked like versioning, branches, restoring settings, grouping related generations, etc.
I didn't build any of that.
Instead I added one small Modify action to AIMakeTattoo.
You generate a result, open Modify, and type what you want changed.
That's basically it.
No mask editor, no layers, no version tree.
Recently a user generated a Roman numeral tattoo with flowers around it.
Then they typed:
Remove the flowers.
The next version kept the lettering direction and removed the flowers.
Then they stopped generating.
I obviously don't know if that means they were fully satisfied, but I found the behavior interesting.
They didn't want another idea.
They already had something close enough. They just wanted to remove the part they didn't like.
That made me realize I may have been thinking about generation the wrong way.
When the result is bad, "generate again" is fine.
But when the result is already 80% right, a completely new generation can actually be worse UX.
At that point the useful interaction is closer to:
Keep this. Change that.
I'm still keeping the lightweight history page, but I'm less convinced that a bigger history system is the next thing I need.
A very small edit flow may solve more of the actual problem.
Curious if anyone building generative products has seen the same thing.
Do users keep asking for more generations, or do they mostly want to preserve what already works?
I think the “80% right” part is the real product insight here.
When something is completely wrong, users want another attempt.
But once they're emotionally attached to parts of the result, “generate again” starts throwing away progress they've already made.
So the user's mental model changes from “make me something” to “help me finish this.”
That seems like a much more important distinction than generation history itself.
I'd actually be curious to watch the language users naturally use around Modify. If they increasingly say things like “remove,” “change,” “keep,” “make this,” etc., that’s pretty strong evidence that the product is shifting from a generator into an editor—even if the UI still looks like a generator.
Sometimes the best feature discovery is hiding in the verbs users use.
I like that framing. “Generate again” and “help me finish this” are very different user intents. I’ve been watching whether people modify once or continue iterating, but tracking the verbs they naturally use may be an even better signal.
Exactly. And I think there's a useful second layer to that signal: the verbs aren't just telling you what feature to build—they can tell you what the user believes the product is for.
If people increasingly say “remove,” “keep,” “change,” and “preserve,” the product may be moving away from a mental model of “AI that generates tattoos” toward “AI that helps me refine a tattoo I already like.”
That distinction could eventually affect more than the Modify flow. It could influence the onboarding, feature hierarchy, homepage language, and even what outcome you emphasize in acquisition.
The interesting thing is that you don't necessarily have to ask users, “What should we call this product?” Their behavior may answer it for you.
I'd definitely keep watching those verbs as the feature matures.
The “keep this, change that” interaction is a good example of letting observed behavior beat an attractive feature roadmap. Version trees and branches would preserve more state, but they also make the user manage a system they never asked for. I’d instrument the Modify flow around three events: how often a result is modified, whether the next version is accepted or modified again, and whether users return to the original later. That distinguishes a one-off rescue from a real continuation loop. The useful product boundary may be “preserve the intent and the parts that already work,” not “preserve every generation.” What signal would convince you the lightweight action has reached its ceiling?
That’s exactly the distinction I’m trying to understand now.
I’m especially interested in whether Modify is mostly a one-off “rescue” for an almost-good result, or whether users start building real continuation loops around it.
I haven’t added branches/version trees yet because I want to see that behavior first. The three events you mentioned are a good way to measure it.