Há algum tempo compartilhei por aqui o RIMG+.
Naquele momento, ele já resolvia o problema que havia motivado sua criação: eu precisava renomear grandes volumes de imagens de forma rápida, previsível e sem transformar uma tarefa simples em um processo manual repetitivo.
O software funcionava.
Mas, olhando para o que aconteceu depois, percebi que aquela talvez tenha sido apenas a primeira parte do trabalho.
Porque existe uma diferença importante entre construir uma solução que resolve um problema e descobrir o que essa solução precisa se tornar quando começa a ser usada.
A primeira versão responde uma pergunta muito específica
Todo produto começa carregando algum nível de hipótese.
No caso do RIMG+, a hipótese era bastante concreta.
Eu tinha uma fricção recorrente no meu próprio fluxo de trabalho. Recebia ou organizava muitos arquivos de imagem e precisava padronizar seus nomes. Fazer isso manualmente consumia tempo demais para uma operação essencialmente mecânica.
A primeira decisão, portanto, não envolveu uma grande visão de produto.
Era mais simples:
como remover essa fricção?
A renomeação em lote respondeu bem a essa pergunta.
E provavelmente seria possível considerar o problema encerrado ali.
Mas usar uma ferramenta repetidamente muda a maneira como você enxerga o próprio problema.
Você deixa de perceber apenas aquilo que motivou a construção e começa a notar tudo que existe ao redor.
O uso começa a revelar coisas que o planejamento não revelou
Depois que o fluxo principal estava funcionando, algumas necessidades começaram a ficar mais evidentes.
Renomear todos os arquivos de uma vez era útil.
Mas e quando apenas um deles precisava de um nome diferente?
Preparar as imagens resolvia uma parte do trabalho.
Mas, muitas vezes, o próximo passo era reduzir o peso desses arquivos antes da utilização.
Ter as funcionalidades disponíveis era importante.
Mas a forma como elas apareciam na interface começava a influenciar cada vez mais a experiência.
Isoladamente, nenhuma dessas questões parecia transformar o projeto.
No conjunto, porém, elas começaram a mudar sua natureza.
O RIMG+ passou a permitir edição individual dos nomes dentro do próprio fluxo. Depois ganhou processamento de vários arquivos, compressão para reduzir o peso em KB preservando as dimensões originais, preparação e exportação, comportamento responsivo e possibilidade de utilização como PWA.
O processamento local também permaneceu como uma decisão importante, principalmente pela privacidade e pela própria natureza dos arquivos manipulados.
Só que a mudança mais interessante não estava necessariamente na quantidade de funcionalidades.
Estava na forma como eu começava a avaliar cada nova decisão.
Antes, a pergunta era “isso funciona?”
No início, meu critério era predominantemente funcional.
Consigo selecionar as imagens?
Consigo aplicar o padrão?
Os arquivos são processados corretamente?
Consigo exportar o resultado?
São perguntas necessárias.
Mas, conforme o produto amadurece, elas deixam de ser suficientes.
A pergunta passa a ser:
o fluxo faz sentido sem eu precisar explicá-lo?
O usuário entende o que acabou de acontecer?
Existe feedback suficiente durante o processamento?
As ações principais têm a hierarquia correta?
É fácil corrigir uma exceção sem abandonar o fluxo?
A interface transmite a mesma maturidade que a funcionalidade já possui?
Essa mudança de pergunta afeta bastante a forma de construir.
Porque código funcionando deixa de ser o único critério.
É nesse momento que UX deixa de ser acabamento
Uma ferramenta interna pode sobreviver por bastante tempo com uma interface apenas funcional.
Você conhece o sistema.
Sabe onde clicar.
Entende as limitações.
Conhece inclusive os comportamentos estranhos, porque foi você quem os implementou.
Para outra pessoa, nada disso existe.
Ela recebe apenas o que a interface consegue comunicar.
Foi por isso que, em determinado momento da evolução do RIMG+, comecei a dedicar mais atenção não apenas às funcionalidades, mas também aos detalhes de experiência.
Hierarquia.
Estados.
Feedback.
Microinterações.
Responsividade.
Consistência visual.
E, recentemente, à própria landing page.
Não porque uma ferramenta utilitária precise parecer mais sofisticada do que é.
Mas porque existe uma relação entre percepção e confiança.
Se estou pedindo para alguém selecionar vários arquivos e executar uma sequência de operações sobre eles, a interface precisa deixar claro o que está acontecendo.
Precisa parecer previsível.
Precisa reduzir dúvida.
Nesse ponto, UX não é decoração colocada depois do produto.
Ela passa a fazer parte do funcionamento dele.
O uso real também muda o roadmap
Outra consequência interessante é que fica mais difícil enxergar roadmap como uma lista linear de funcionalidades.
Quando estamos longe do uso, é fácil imaginar evolução como:
feature A → feature B → feature C.
Na prática, muitas vezes acontece algo diferente.
Você implementa A.
Usando A, percebe uma fricção no fluxo.
Corrige a fricção.
Isso revela um problema de feedback.
Você melhora o feedback.
A mudança cria uma oportunidade de simplificar outra etapa.
E só então percebe que B talvez nem seja mais tão importante quanto parecia antes.
A evolução começa a ser menos sobre executar uma lista e mais sobre responder ao comportamento do próprio sistema.
Isso não significa desenvolver sem direção.
Significa aceitar que uma parte da direção só aparece depois do uso.
Construir e usar cria um ciclo diferente
Projetos pessoais têm uma característica interessante nesse sentido.
Você consegue reduzir bastante a distância entre quem percebe o problema, quem constrói a solução e quem utiliza o resultado.
No RIMG+, muitas das decisões que vieram depois da primeira versão surgiram justamente desse ciclo.
Eu construía.
Usava.
Encontrava uma fricção.
Voltava para o produto.
Algumas vezes isso resultava em uma nova funcionalidade.
Em outras, em uma alteração de interface.
Em outras, simplesmente em revisar algo que tecnicamente já estava “pronto”.
É um processo menos organizado do que um roadmap idealizado em uma ferramenta de gestão.
Mas, muitas vezes, mais informativo.
Porque o produto começa a responder.
Software pronto é uma ideia confortável
Existe algo tentador em imaginar que o software está pronto quando todos os requisitos iniciais foram implementados.
É uma definição clara.
Mensurável.
E útil até certo ponto.
Mas requisitos descrevem aquilo que conseguimos prever antes do uso.
Produtos precisam sobreviver ao que descobrimos depois.
Continuando a evolução do RIMG+, tenho percebido que boa parte do trabalho mais interessante começou justamente quando a necessidade inicial já estava resolvida.
Não porque o projeto precisava acumular funcionalidades.
Mas porque o uso tornou visíveis perguntas que a primeira versão ainda não precisava responder.
Talvez essa seja uma das diferenças mais importantes entre construir uma ferramenta e continuar construindo um produto.
A ferramenta nasce quando o problema deixa de existir.
O produto começa a aparecer quando você passa a observar tudo que acontece depois disso.
Compartilhar em:
Sem spam. Só conteúdo que vale abrir.