Modernizar a interface de um sistema antigo: quando vale

O sistema de pedidos funciona há anos. Calcula imposto certo, conversa com o financeiro, nunca perdeu uma venda. Mas para lançar um pedido o vendedor passa por cinco telas, decora que o desconto fica numa aba escondida e precisa apertar F8 duas vezes porque, se apertar só uma, o pedido fica pendente sem avisar. Toda pessoa nova leva semanas para pegar o jeito, e a frase mais ouvida no setor é "esse sistema é horrível".

A tentação é concluir que o sistema inteiro precisa ser trocado. Às vezes precisa. Mas muitas vezes o problema está concentrado numa camada só: a forma como as pessoas interagem com um núcleo que ainda faz bem o seu trabalho. Nesse caso, refazer a interface resolve a maior parte da dor com uma fração do risco de uma reconstrução.

Este texto mostra quando modernizar a interface de um sistema antigo, renovando só as telas, é a decisão certa, quando é maquiagem, como fazer a troca sem parar a operação e como medir, com números da própria empresa, se a mudança valeu.

A resposta curta: quando refazer só a interface vale

Renovar apenas a interface, mantendo regras de negócio e banco de dados, costuma valer quando todas estas condições aparecem juntas:

• As regras estão corretas. Os cálculos, os fluxos de aprovação e as integrações funcionam. As reclamações são sobre "como fazer", não sobre "o sistema faz errado".
• O núcleo tem como ser acessado de fora. Existe banco de dados documentável, rotinas que podem ser chamadas ou dá para construir uma camada de acesso sem reescrever a lógica.
• A plataforma de base ainda tem suporte. Banco, linguagem e servidor recebem atualização de segurança, ou existe um plano viável para isso.
• A dor está em poucas telas muito usadas. Em quase todo sistema, um punhado de telas concentra o uso diário. Melhorar essas telas muda o dia de muita gente.

Quando falta alguma dessas condições, trocar só a tela tende a virar maquiagem, assunto de uma seção adiante.

Quando a reclamação é a tela, e não o sistema

"O sistema é ruim" é uma frase que mistura problemas diferentes. Antes de decidir, vale separar as reclamações em dois grupos.

Problemas de interface são os que somem se a mesma regra for apresentada de outro jeito:

• campos em ordem diferente da que a pessoa preenche no papel ou ao telefone;
• informação necessária espalhada em várias abas;
• mensagens de erro como "registro inválido" sem dizer qual campo;
• atalhos obscuros que só os veteranos conhecem;
• nenhuma busca: é preciso saber o código do cliente de cabeça;
• telas que não funcionam fora do computador da mesa, quando o trabalho acontece no balcão, no armazém ou na rua.

Problemas de núcleo continuam mesmo com a tela mais bonita do mundo:

• cálculo de imposto ou comissão errado;
• dados duplicados ou inconsistentes entre módulos;
• processo noturno que trava e atrasa o faturamento;
• impossibilidade de integrar com loja virtual, banco ou transportadora;
• lentidão causada por consultas pesadas no banco, e não pela tela.

Na prática: pegue as dez reclamações mais frequentes do suporte interno e pergunte, para cada uma, "se a regra fosse a mesma, mas a tela fosse outra, o problema acabaria?". Se a maioria das respostas for sim, a interface é o gargalo.

Os custos de uma interface ruim

O custo de uma tela confusa raramente aparece em relatório, porque está diluído na rotina. Ele se manifesta em três lugares.

Erros operacionais

Interface ruim induz erro. Um campo de quantidade que aceita vírgula e ponto com significados diferentes, um botão "excluir" ao lado do "salvar", um desconto que o sistema aplica em percentual quando a pessoa digitou em valor. Cada erro vira retrabalho: nota cancelada, pedido refeito, estoque ajustado, cliente ligando.

Treinamento e dependência de pessoas

Quando o sistema só é usável com macetes, o conhecimento fica na cabeça dos veteranos. A empresa paga isso em semanas de adaptação para cada contratação, em gente experiente parando para ensinar e em risco quando essa pessoa sai de férias ou deixa a empresa.

Lentidão no atendimento

Cinco telas para um pedido, três consultas para responder "tem em estoque?", cópia manual entre janelas. Segundos por operação, multiplicados pelo volume diário, viram horas de equipe por semana e espera do cliente do outro lado da linha.

Nova interface sobre o núcleo existente

A ideia técnica é simples: manter o que funciona (banco de dados, regras, integrações) e construir uma camada nova de apresentação por cima. Na prática, existem três caminhos, e a escolha depende de como o sistema antigo foi feito.

O primeiro caminho tem uma vantagem que vai além da tela: a mesma camada de serviço que alimenta a interface nova pode servir, mais tarde, para integrar loja virtual, aplicativo ou parceiros. O assunto aparece com mais detalhe em API para parceiros e clientes.

Também é comum que a nova interface seja web, acessada pelo navegador. Isso resolve de uma vez a instalação em cada máquina, o acesso fora do escritório e o uso em tablet no armazém. A escolha do framework está em Next.js ou React puro. Se o sistema atual é desktop, a discussão completa sobre essa mudança está em migrar sistema desktop para web.

O cuidado que não pode faltar

O maior risco de uma interface nova sobre núcleo antigo é pular regras que estavam escondidas na tela antiga. Em muitos sistemas legados, parte da validação mora na própria tela: o campo que não aceita data futura, o botão que só habilita se o cliente estiver sem pendência. Se a tela nova grava direto no banco sem replicar essas regras, os dados se corrompem silenciosamente.

Por isso, antes de redesenhar qualquer tela, é preciso inventariar o que ela valida e decidir onde essa validação vai morar: de preferência na camada de serviço, para valer para qualquer interface que venha depois.

Quando trocar só a tela é maquiagem

Uma interface nova pode esconder por um tempo problemas que continuam crescendo por baixo. Desconfie de um projeto só de interface quando:

• As regras de negócio estão erradas ou desatualizadas. Uma tela bonita que calcula errado continua calculando errado, só que mais rápido.
• A plataforma de base está sem suporte. Banco ou sistema operacional sem atualização de segurança é risco que nenhuma tela resolve.
• A lentidão vem do banco ou do processamento. Se cada consulta demora, a tela nova vai esperar o mesmo tempo.
• O sistema não consegue mais acompanhar o negócio. A empresa abriu filiais, passou a vender em marketplace ou mudou o modelo de cobrança, e o núcleo não comporta isso.
• Ninguém consegue mais alterar o núcleo. Se cada mudança de regra é demorada e arriscada, a interface nova vai depender de um núcleo que não evolui.

Nesses casos, a interface pode até ser o primeiro passo de uma modernização maior, desde que todos saibam que é o primeiro passo, e não a solução. A decisão sobre o núcleo, entre refatorar por partes ou reconstruir, é discutida em reescrever ou refatorar um sistema legado.

Pesquisa com usuários antes de redesenhar

O erro mais comum em projetos de interface é redesenhar a partir da opinião de quem decide, e não do trabalho de quem usa. O diretor imagina como o pedido deveria ser lançado; o vendedor sabe como ele realmente é lançado, com as exceções do dia a dia.

Uma pesquisa enxuta, feita antes de desenhar qualquer tela, inclui:

1. Observar o trabalho real. Sentar ao lado de quem usa o sistema por algumas horas, em dias normais e em dias de pico. Anotar cada desvio: planilha paralela, papel colado no monitor, consulta em outra janela.
2. Levantar os dados de uso. Quais telas são mais abertas, quais operações mais repetidas, onde o suporte interno recebe mais chamados.
3. Entrevistar perfis diferentes. O veterano que sabe todos os atalhos, a pessoa contratada há pouco tempo, quem usa o sistema só uma vez por semana. Cada um mostra um problema diferente.
4. Listar as tarefas críticas. As poucas operações que, se ficarem mais rápidas e seguras, mudam o dia da equipe. Elas definem a ordem do trabalho.
5. Testar protótipos antes de programar. Telas navegáveis, ainda sem sistema por trás, mostradas para quem vai usar. Ajustar protótipo custa menos que ajustar software pronto.

Um cuidado: veteranos dominam a tela antiga e vão perder velocidade nos primeiros dias. Isso não torna a mudança errada; pede atalhos de teclado, um período de convivência e atenção a quem mais usa. É também a hora de cuidar da acessibilidade em sistemas web: contraste, navegação por teclado e leitores de tela.

Migrar tela a tela com o sistema rodando

Trocar todas as telas de uma vez repete o principal risco de uma reescrita: um dia de virada em que tudo pode dar errado. O caminho mais seguro é incremental.

1. Comece pela tarefa de maior impacto e menor risco. Uma consulta (de estoque, de cliente, de pedido) costuma ser um bom início: entrega valor rápido e não grava nada.
2. Depois, a operação mais usada. Com a camada de serviço testada, passe para o lançamento que mais consome tempo, como o pedido de venda.
3. Mantenha as duas telas disponíveis por um período. Quem quiser pode voltar à tela antiga enquanto se adapta. Quando o uso da antiga cair a quase nada, ela é desligada.
4. Libere por grupo. Uma filial, um turno ou uma equipe primeiro, depois o restante. Problemas aparecem em escala pequena.
5. Registre o que foi descoberto. Cada tela migrada revela regras escondidas no sistema antigo. Documente para as próximas.

O prazo depende muito do número de telas, de como o núcleo pode ser acessado e da disponibilidade da equipe para validar. Em geral, as primeiras telas chegam em semanas e a migração completa se estende por meses, sempre com o sistema funcionando. Só depois de um diagnóstico dá para estimar com responsabilidade.

Medindo o ganho depois da mudança

Se ninguém medir antes, ninguém vai saber se valeu. A medição começa antes da primeira tela nova, para haver com o que comparar.

Dois cuidados ao interpretar os números:

• A primeira semana engana. Quem usava a tela antiga há anos vai ficar mais lento no início. Compare depois do período de adaptação, não no primeiro dia.
• Meça por tarefa, não pelo sistema inteiro. "O sistema ficou melhor" não ajuda a decidir. "Lançar pedido ficou mais rápido e gera menos estorno" ajuda a priorizar a próxima tela.

Checklist antes de aprovar um projeto de interface

• As reclamações principais são sobre como fazer, e não sobre o que o sistema faz?
• As regras de negócio atuais estão corretas e atualizadas?
• O banco e a plataforma de base têm suporte e atualização de segurança?
• Existe forma de acessar o núcleo sem reescrever a lógica?
• Sabemos quais telas concentram o uso diário?
• Já observamos quem usa o sistema no trabalho real?
• Medimos tempo, erros e chamados antes da mudança?
• O plano prevê migração tela a tela, com as duas versões convivendo?

Se a maior parte das respostas for "sim", modernizar só a interface é um caminho sólido. Se várias forem "não" ou "não sei", o primeiro passo é um diagnóstico do núcleo antes de desenhar qualquer tela.

Perguntas frequentes

Quanto tempo leva para modernizar a interface de um sistema antigo?

Depende do número de telas, de como o núcleo pode ser acessado e da disponibilidade da equipe para validar. Em geral, as primeiras telas novas chegam em semanas e a modernização completa da interface se estende por meses, com o sistema funcionando. Só um diagnóstico permite estimar o prazo com responsabilidade.

Modernizar só a interface resolve a lentidão do sistema?

Só quando a lentidão vem da tela, como excesso de passos, cliques e janelas. Se cada consulta demora porque o banco de dados está sobrecarregado ou mal indexado, a interface nova vai esperar o mesmo tempo. Nesse caso, um diagnóstico de performance do núcleo deve vir antes ou junto do redesenho das telas.

A nova interface do sistema antigo precisa ser web?

Não obrigatoriamente, mas costuma ser a melhor escolha. Uma interface web, acessada pelo navegador, elimina a instalação em cada máquina, permite acesso fora do escritório e funciona em tablet no armazém ou no balcão. A mesma camada de serviço que alimenta a interface web também pode servir a integrações futuras.

Os usuários antigos vão perder produtividade com a interface nova?

No começo, é comum. Quem domina a tela antiga há anos fica mais lento nos primeiros dias, mesmo que a interface nova seja melhor. Atalhos de teclado, um período com as duas telas disponíveis e atenção a quem mais usa reduzem essa queda. Por isso o ganho da interface nova deve ser medido depois da adaptação.

Qual a diferença entre modernizar a interface e reescrever o sistema?

Modernizar a interface mantém banco de dados, regras de negócio e integrações e troca só as telas, com uma fração do risco. Reescrever o sistema reconstrói também o núcleo, o que se justifica quando as regras estão erradas, a plataforma está sem suporte ou o núcleo não consegue mais acompanhar o negócio.

Como a Pervian Tech trabalha modernização de interface

Na Pervian Tech, começamos pelo diagnóstico: olhamos o sistema atual, o banco, as integrações e, principalmente, o trabalho de quem usa. Separamos o que é problema de tela do que é problema de núcleo e mostramos, em linguagem de negócio, se renovar só a interface resolve ou se é preciso mexer mais fundo. Quando o núcleo está saudável, construímos a camada de serviço e as novas telas web com nosso trabalho de desenvolvimento web, migrando tela a tela com o sistema rodando.

Quando o problema é maior, o trabalho vira um projeto de modernização de sistemas legados, e a interface nova passa a ser uma das etapas. Outros textos sobre o tema estão na categoria modernização.

Tudo é sob medida, com investimento sob consulta, definido depois de um diagnóstico inicial gratuito. Se a sua equipe trabalha apesar do sistema, e não com ele, conte como é o dia a dia com ele.