I recently shipped a lightweight generation history feature for my AI product.
The first version was straightforward: save successful outputs for signed-in users and show the most recent ones in a grid.
It was familiar, useful, and relatively easy to build.
But once it was working, I realized it solved a much narrower problem than the name “history” suggested.
It was really a gallery.
A user could find an old result, but they could not necessarily continue the work that produced it.
That distinction matters in a generative product.
When people say they want history, they may actually be asking for several different things.
Retrieval means finding an old result.
Reproduction means running the same input and settings again.
Continuation means reopening an earlier idea and carrying on from where you stopped.
Variation means keeping most of a result while changing one specific part.
A grid of old outputs only solves retrieval.
Even reproduction is harder than it first appears. Saving the visible prompt may not be enough. The output can also depend on selected controls, hidden instructions, model version, provider behavior, uploaded files, and generation settings.
A saved prompt can make a result look reproducible even when it is not.
Continuation is a different problem.
If a user opens an old result, should the product restore the original form values? Should the next generation become a new branch? Should related results stay grouped together? Should the old result remain untouched?
Then there is variation, which may be the thing users actually want.
They often do not want to recreate the exact same output. They want to say:
“Keep the composition, but remove this element.”
“Use the same idea, but make it narrower.”
“Keep everything except the colors.”
A gallery cannot do that.
This made me realize that generation history is often treated as one feature even though it contains several different product problems.
The easiest version to ship is to save outputs and display them again.
That still has value. Users can recover something they forgot to download, revisit an earlier direction, or compare results.
But it can also create the appearance of continuity without providing any real continuity.
I am keeping the lightweight history page because retrieval is useful on its own.
I just no longer see it as the solution to an iterative workflow.
A gallery, reproducibility, continuation, and controlled variation are separate capabilities. Calling all of them “history” makes it too easy to build the simplest one and assume the problem is solved.
How does history work in your generative product?
Can users only find old results, or can they actually continue from them?
The distinction between retrieval, reproduction, continuation and variation is useful.
Have users actually shown you which of those they’re trying to do after returning to an old generation, or is that still something you’re inferring from the workflow?
What I enjoyed most about this was watching one feature request split into several different user intentions.
It reminded me that users usually describe problems using the language they have, not the language the product eventually needs. "History" sounds like one capability until you start asking what someone is actually trying to do with it.
I think that's one of the easiest traps in product design: building exactly what users asked for, instead of uncovering the different jobs hidden inside the request.