A empresa investiu meses e um orçamento considerável num sistema novo. Na entrega, tudo funcionava. Os dados estavam certos, os relatórios geravam, as integrações rodavam.

Três meses depois, metade da equipe ainda usava a planilha antiga.

Esse cenário é mais comum do que parece. E o motivo quase sempre é o mesmo: o sistema foi construído para funcionar, não para ser usado.

O que UX realmente significa

UX — User Experience, ou Experiência do Usuário — é como uma pessoa se sente ao interagir com um sistema. Não é sobre cores ou animações. É sobre se a interface responde às expectativas de quem usa.

Um sistema com bom UX faz o usuário pensar menos. As ações são onde ele espera que estejam. O fluxo segue a lógica do trabalho real, não a lógica do banco de dados. Erros têm mensagens que fazem sentido. Tarefas repetitivas são rápidas.

Um sistema com UX ruim faz o contrário: cria fricção em cada etapa, exige treinamento extenso para tarefas básicas, e gera aquela sensação difusa de que "o sistema é complicado".

O custo invisível de UX ruim

Adoção baixa

Pessoas evitam o que é difícil de usar. Se o sistema novo é mais trabalhoso do que o processo antigo (mesmo que o processo antigo fosse uma planilha), a equipe vai resistir, contornar, ou abandonar.

Adoção baixa significa que os dados no sistema são incompletos. Relatórios ficam imprecisos. Decisões são tomadas com base em informação parcial. O ROI do sistema cai — não porque ele não funciona, mas porque ninguém usa.

Custo de treinamento e suporte

Quando a interface não é intuitiva, treinamento se torna indispensável e contínuo. Cada novo colaborador precisa de horas aprendendo o sistema. Erros de uso geram tickets para o suporte. Gestores respondem as mesmas perguntas sobre o sistema semanas após a implantação.

Esse custo não aparece na planilha do projeto, mas ele existe e cresce com o tempo.

Erro operacional

Interfaces confusas provocam erros. Campos que parecem iguais mas têm funções diferentes. Botões em lugares inesperados. Fluxos que não confirmam ações críticas. Cada erro de UX tem um correspondente em erro humano — e alguns desses erros têm consequências reais.

Resistência à mudança amplificada

Toda mudança de sistema gera resistência. É normal. Mas um sistema com UX ruim valida essa resistência. O usuário que resistia por hábito passa a resistir por argumento: "o sistema novo é pior." Quando ele está certo, a implantação vira uma batalha.

Por que UX costuma ser ignorado em sistemas internos

Existe uma crença implícita no desenvolvimento de sistemas corporativos: usuários internos não têm escolha. Diferente de um app de consumidor, onde o usuário vai embora se a experiência for ruim, o colaborador é obrigado a usar o sistema da empresa.

Isso é verdade — e é exatamente o problema. A ausência de consequência imediata remove o incentivo para investir em UX. O resultado são anos de interfaces ruins que ninguém gosta mas todos toleram, acumulando dívida de experiência que eventualmente vira produtividade perdida.

"Usuário cativo não é usuário satisfeito. É usuário que suporta — e que vai embora assim que surgir uma alternativa melhor."

O que bom UX exige na prática

Entender o usuário real antes de projetar

Quem vai usar o sistema, em qual contexto, com qual objetivo, com que frequência? Essas perguntas parecem óbvias, mas raramente são respondidas com profundidade antes do design começar.

Um sistema para atendentes que usam o mouse com uma mão e anotam no papel com a outra tem necessidades completamente diferentes de um sistema para analistas que ficam horas em tela. Projetar sem saber isso é adivinhar.

Seguir a lógica do trabalho, não do dado

Desenvolvedores tendem a organizar interfaces refletindo a estrutura do banco de dados ou do código. Usuários pensam em termos de tarefas e objetivos.

"Registrar um pedido" envolve dados de várias tabelas, mas o usuário não quer navegar por tabelas — ele quer fazer o pedido. Bom UX traduz complexidade técnica em fluxos que fazem sentido humano.

Testar antes de entregar

A única forma de saber se a interface funciona é observar pessoas reais usando ela. Não o desenvolvedor, não o gerente de produto, não o cliente — os usuários finais.

Teste de usabilidade não precisa ser caro ou complexo. Cinco usuários executando tarefas reais revelam a maioria dos problemas críticos. O custo de corrigir antes da entrega é uma fração do custo de corrigir depois.

Iterar baseado em uso real

Depois que o sistema entra em produção, o UX não para. As primeiras semanas de uso revelam padrões que nenhum teste consegue prever completamente. Monitorar onde os usuários travam, onde pedem ajuda, onde cometem erros — e usar isso para evoluir a interface — é a diferença entre um sistema que melhora com o tempo e um que envelhece.

UX em sistemas sob medida vs. sistemas prontos

Sistemas prontos (SaaS, ERP genérico) têm UX projetado para a média de todos os seus usuários. Para muitas empresas, isso é suficiente.

A vantagem de um sistema sob medida é poder ter UX otimizado para o fluxo específico da empresa. Isso não é luxo — é uma das principais justificativas para o investimento em desenvolvimento custom.

Um sistema sob medida com UX ruim desperdiça essa vantagem. Você pagou pelo custom e entregou uma experiência genérica — ou pior.

O que acontece quando UX é levado a sério

A diferença entre um sistema adotado e um sistema tolerado raramente é a funcionalidade — é a experiência. Quando a interface respeita o tempo do usuário, segue a lógica do trabalho dele e reduz fricção, a resistência cai, o treinamento fica mais curto, os erros diminuem e o ROI aparece.

Isso não exige interface espetacular. Exige interface honesta: que saiba quem vai usá-la e que se importe com isso.

Como tratamos UX na Nooma

UX não é uma fase do projeto — é uma perspectiva presente desde o levantamento de requisitos. Antes de qualquer tela, entendemos quem são os usuários reais, quais são as tarefas mais frequentes e quais são os pontos de maior fricção no processo atual.

Durante o desenvolvimento, prototipamos fluxos antes de implementar. Ajustes de interface são mais baratos no protótipo do que no código. Após a entrega, monitoramos os primeiros ciclos de uso para identificar o que pode ser melhorado.

O objetivo não é um sistema bonito. É um sistema que a equipe usa — porque usar é fácil.