Dois sistemas podem ter a mesma tela bonita. Os mesmos botões arredondados, a mesma cor da marca, o mesmo painel com gráfico. Num deles, a equipe lança tudo na hora. No outro, três meses depois, o caderno voltou pro balcão. A diferença entre os dois quase nunca está na cor. Está numa parte que não aparece no print: se o sistema foi desenhado em volta do trabalho de quem usa.
Essa parte tem nome. É a diferença entre UX e UI, duas siglas que aparecem em toda proposta de software e quase nunca são explicadas. Este texto explica com exemplos de balcão, sem jargão, e termina com um jeito de avaliar qualquer sistema em quinze minutos.
O que é UX
UX vem do inglês user experience: a experiência de quem usa. É tudo o que acontece entre a pessoa querer fazer uma coisa e conseguir fazer. Inclui perguntas que não têm nada a ver com aparência:
- A tarefa que a pessoa precisa fazer existe no sistema?
- Quantos passos leva, e algum deles é inútil?
- A pessoa entende o que aconteceu depois que tocou no botão?
- Se errar, consegue voltar sem pedir ajuda?
Um sistema com boa UX é aquele em que a equipe não precisa pensar no sistema. Pensa no cliente, no carro, no pedido. O sistema só acompanha.
O que é UI
UI vem de user interface: a interface, a parte que se vê e se toca. Botão, letra, cor, espaço entre as coisas, ícone. É a camada que aparece no print e na apresentação de vendas.
UI importa muito. Botão pequeno demais erra o toque, cor fraca some no sol, letra miúda cansa. Mas UI é a última camada. Ela só funciona se as de baixo estiverem certas.
UX e UI, de baixo pra cima
A tela bonita é só a última camada
Pesquisa
Resolve o problema certo?
Ver o balcão de verdade antes de desenhar.
Fluxo
Dá pra fazer sem pensar?
Do orçamento ao recebido, sem voltar tela.
Estrutura
Acha onde está?
Etapas com o nome que a equipe fala.
Interface
Lê e toca bem?
Letra, cor, botão de 44 pontos, contraste no sol.
Um exemplo de balcão: lançar uma venda
Imagine lançar uma venda no caixa. É a tarefa mais repetida do dia em muita empresa pequena.
Num sistema com UI ruim, o botão de salvar é pequeno, o campo de valor tem letra clara demais e a forma de pagamento se escolhe numa bolinha minúscula. Dá raiva, mas dá pra usar.
Num sistema com UX ruim, a tela pode até ser bonita, mas pra lançar a venda você precisa abrir o cadastro do cliente, depois a ordem de serviço, depois o caixa. O campo da placa fica no fim do formulário, embora seja a primeira coisa que o balcão sabe. E depois de salvar, nada diz se deu certo. A equipe aprende a contornar: anota no papel e lança tudo no fim do dia. Aí o sistema vira cópia atrasada do caderno.
Consertar a UI costuma ser rápido: troca a cor, aumenta o botão. Consertar a UX quase sempre pede refazer o caminho. Por isso ela tem que vir primeiro.
Por que tanto sistema erra na UX
Porque quem compra o sistema não é quem usa. Na demonstração de vendas, o dono vê o painel, os gráficos, o relatório do mês. É isso que ele avalia. Quem vai usar o sistema o dia inteiro é o balcão, o técnico, o caixa, e eles não estavam na reunião.
O resultado é previsível: sistemas ótimos de mostrar e cansativos de usar. Todo o capricho foi pra tela que o dono vê uma vez por semana, e a tela que a equipe usa o dia inteiro ficou com três cliques a mais.
Como a Apol trabalha cada camada
O jeito da Apol de fazer sistema, o SaY, segue as camadas de baixo pra cima.
- Pesquisa. Antes de desenhar, a gente vai até a empresa e fica olhando o trabalho acontecer. Na Grande São Paulo, ao vivo; fora, por vídeo. O que a equipe faz, onde anota, quem pergunta o quê pra quem. Isso tem um texto só dele: por que a Apol começa pelo balcão.
- Fluxo. A tarefa mais repetida ganha o caminho mais curto. Se o balcão sabe a placa primeiro, a placa é o primeiro campo.
- Estrutura. As etapas e os menus usam as palavras da casa. Se a equipe fala "pronto pra retirada", a coluna se chama "pronto pra retirada".
- Interface. Só então a tela ganha cara: componentes de um design system, área de toque de 44 pontos no celular, como a Apple recomenda, contraste conferido.

No quadro acima, nada é invenção de designer. "Orçamento", "Aprovado / Execução", "Pronto pra retirada" e "Cliente avisado" são os nomes que a loja já usava. Arrastar o cartão de uma coluna pra outra é o gesto mais natural pra quem pensa no carro andando pelo pátio.
Como avaliar qualquer sistema em quinze minutos
Antes de assinar, peça pra testar sozinho, sem o vendedor do lado. Se tiver uma tarde, faça um teste de usabilidade com cinco pessoas. Pegue a tarefa mais comum da sua empresa e faça as perguntas de cada camada.
- Pesquisa: a tarefa existe do jeito que você faz, ou você vai ter que mudar o seu jeito?
- Fluxo: conte os toques do começo ao fim. Algum passo pede uma informação que você ainda não tem naquele momento?
- Estrutura: você achou onde estava cada coisa sem perguntar? Os nomes fazem sentido pra sua equipe?
- Interface: dá pra fazer no celular, de pé, com uma mão? Dá pra ler no sol?
Se a resposta da primeira camada for "vou ter que mudar o meu jeito", pare aí. A beleza das outras não compensa.
Faça hoje: escolha a tarefa que a sua equipe mais repete, como lançar uma venda, abrir um pedido ou agendar um cliente. Peça pra alguém fazer na sua frente e conte os toques, ou os passos no papel. Anote cada momento em que a pessoa parou pra pensar. Essa lista é a UX da sua empresa hoje, e é o que qualquer sistema novo precisa melhorar.
Se quiser saber em que área a sua empresa mais perde tempo hoje, a Apol tem um diagnóstico grátis: você marca o que já acontece e recebe o relatório na hora, com as áreas que pesam mais e por onde começar.