I've shared here for a while the RIMG+ project.
At the time, it already solved the problem that motivated its creation: I needed to quickly, predictably, and without turning a simple task into a repetitive manual process, rename large volumes of images.
The software worked.
But, looking at what happened afterwards, I realized that perhaps that was only the first part of the work.
Because there's an important difference between building a solution that solves a problem and discovering what that solution needs to become when it starts being used.
The first version answers a very specific question
Every product starts carrying some level of hypothesis.
In the case of RIMG+, the hypothesis was quite concrete.
I had a recurring friction in my own workflow. I received or organized many image files and needed to standardize their names. Doing this manually consumed too much time for a mechanically essential operation.
The first decision, therefore, didn't involve a large product vision.
It was simpler:
how do I remove this friction?
The batch renaming answered this question well.
And probably it would have been possible to consider the problem closed there.
But using a tool repeatedly changes the way you look at the problem itself.
You stop noticing only what motivated the construction and start noticing everything that exists around it.
Real use starts revealing things that planning didn't reveal
After the main flow was working, some needs began to become more evident.
Rename all files at once was useful.
But what about when only one of them needed a different name?
Preparing the images solved part of the work.
But often, the next step was to reduce the weight of these files before use.
Having the features available was important.
But the way they appeared in the interface began to influence the experience more and more.
Individually, none of these issues seemed to transform the project.
Together, however, they began to change its nature.
RIMG+ started allowing individual name editing within the flow itself. Then it gained batch processing, compression to reduce weight in KB while preserving original dimensions, preparation and export, responsive behavior, and the possibility of using it as a PWA.
Local processing also remained an important decision, mainly due to privacy and the nature of the manipulated files themselves.
But the most interesting change wasn't necessarily in the number of features.
It was in the way I began to evaluate each new decision.
Before, the question was 'does it work?'
At first, my criterion was predominantly functional.
Can I select the images?
Can I apply the pattern?
Are the files processed correctly?
Can I export the result?
These are necessary questions.
But as the product matures, they are no longer enough.
The question becomes:
Does the flow make sense without me needing to explain it?
Does the user understand what just happened?
Is there sufficient feedback during processing?
Do the main actions have the correct hierarchy?
Is it easy to correct an exception without leaving the flow?
Does the interface convey the same maturity as the functionality already has?
This change in question affects how we build.
Because working code is no longer the only criterion.
It's at this moment that UX stops being decoration
An internal tool can survive for a long time with a functional interface.
You know the system.
You know where to click.
You understand the limitations.
You even know the strange behaviors, because you implemented them.
For someone else, none of this exists.
They only receive what the interface can communicate.
That's why, at a certain point in the RIMG+ evolution, I started dedicating more attention not only to features, but also to experience details.
Hierarchy.
States.
Feedback.
Microinteractions.
Responsiveness.
Visual consistency.
And, recently, the landing page itself.
Not because a utility tool needs to look more sophisticated than it is.
But because there's a relationship between perception and trust.
If I'm asking someone to select multiple files and execute a sequence of operations on them, the interface needs to make it clear what's happening.
It needs to look predictable.
It needs to reduce doubt.
At this point, UX is no longer just decoration added after the product.
It becomes part of its functioning.
Real use also changes the roadmap
Another interesting consequence is that it becomes harder to see the roadmap as a linear list of features.
When we're far from use, it's easy to imagine evolution as:
feature A → feature B → feature C.
In practice, something different often happens.
You implement A.
Using A reveals a friction in the flow.
You correct the friction.
This reveals a problem with feedback.
You improve the feedback.
The change creates an opportunity to simplify another step.
And only then do you realize that B may not be as important as it seemed before.
Evolvement starts to be less about executing a list and more about responding to the behavior of the system itself.
This doesn't mean developing without direction.
It means accepting that part of the direction only appears after use.
Building and using creates a different cycle
Personal projects have an interesting characteristic in this sense.
You can reduce the distance between who perceives the problem, who builds the solution, and who uses the result.
In RIMG+, many of the decisions that came after the first version emerged just from this cycle.
I built.
I used.
I found a friction.
I went back to the product.
Sometimes this resulted in a new feature.
Other times, in an interface change.
Other times, simply in reviewing something that was technically 'done'.
This is a less organized process than an idealized roadmap in a management tool.
But, often, more informative.
Because the product starts to respond.
Software ready is a comforting idea
There's something tempting in imagining that the software is ready when all initial requirements have been implemented.
It's a clear definition.
Mesurable.
And useful up to a point.
But requirements describe what we can predict before use.
Products need to survive what we discover afterwards.
Continuing the RIMG+ evolution, I've noticed that much of the most interesting work began just when the initial need was already solved.
Not because the project needed to accumulate features.
But because use made visible questions that the first version still didn't need to answer.
Perhaps this is one of the most important differences between building a tool and continuing to build a product.
The tool is born when the problem no longer exists.
The product starts to emerge when you begin to observe everything that happens after that.
Share on:
No spam. Only content worth opening.