PDV Fecchio
Transformando inconsistências dispersas em um plano claro de evolução do produto
Conduzi uma auditoria completa de UX/UI em um aplicativo mobile de ponto de venda desenvolvido com forte apoio de IA, identificando problemas de usabilidade, consistência, comportamento e conteúdo antes do lançamento. Em uma semana, transformei a análise de ponta a ponta do produto em 253 achados documentados e priorizados, com recomendações acionáveis para implementação.
- UX Audit
- UI Review
- Usability
- Heuristic Analysis
- AI-assisted Products
- Meu papel
- UX/UI Specialist — Auditoria independente
- Contexto
- PDV Fecchio · Cliente independente
- Escopo
- 1 semana · Auditoria completa + relatório + handoff
Auditoria em números
101 melhorias · 30 sugestões · 47 pontos positivos · 6 ajustes de texto
Contexto
O PDV Fecchio é um aplicativo mobile de ponto de venda voltado a restaurantes e estabelecimentos de alimentação.
O produto havia sido desenvolvido por um desenvolvedor independente com forte uso de IA durante a construção, e já estava funcionalmente próximo do lançamento.
O cliente percebia que a experiência ainda precisava amadurecer, mas, por estar profundamente envolvido na construção, tinha dificuldade para identificar onde estavam os principais problemas e o que deveria ser corrigido primeiro.
Foi nesse momento que entrei como uma perspectiva externa. O escopo: uma semana para auditar o produto completo, organizar os achados e transformar diagnóstico em direção de melhoria.
O desafio
O produto já funcionava.
O problema estava na soma de pequenas decisões que, isoladamente, pareciam aceitáveis, mas juntas afetavam a qualidade da experiência: inconsistências entre telas, comportamentos pouco previsíveis, problemas de hierarquia, textos inadequados e alguns erros funcionais.
Por isso, a auditoria precisava responder a três perguntas: o que realmente está errado, qual a gravidade de cada problema, e o que precisa ser corrigido primeiro para o produto evoluir com segurança.
Como conduzi a auditoria
Percorri o produto de ponta a ponta, tela por tela e fluxo por fluxo, simulando diferentes momentos da operação — desde criação de conta até fechamento de eventos.
A análise cobriu menus e modificadores, comandas e pedidos, cozinha, entregas, analytics, navegação e estados de interface, conteúdo e terminologia.
Para cada achado, registrei: contexto → problema → nível de severidade → recomendação de correção.
O objetivo não era simplesmente apontar inconsistências, mas tornar cada problema compreensível e acionável para quem faria a implementação.
Tornando 253 achados priorizáveis
Nem todo problema tem o mesmo peso. Por isso organizei os achados em seis categorias, para ajudar o cliente a entender o que precisava de atenção imediata, o que deveria evoluir depois, e o que já funcionava bem.
Registrar o que funciona bem também faz parte da auditoria. O cliente não precisava apenas saber o que mudar — precisava saber o que não deveria quebrar durante as correções.
Alguns padrões que encontrei
Nem todo achado é uma lista de bullets. Alguns exemplos mostram o tipo de raciocínio por trás dos 253 pontos documentados.
Tela: Formulário de item do Cardápio
🔴 Máscara de preço quebrada em múltiplos formulários
Problema: ao digitar "23" no campo de preço, o valor exibido era "R$ 0,0023" em vez de "R$ 0,23". O mesmo padrão se repetia no preço de variantes e na taxa de entrega.
Por que importa: um erro de máscara em campo de preço não é só estético — afeta diretamente a operação financeira do restaurante, e por se repetir em vários formulários, sugeria uma causa raiz compartilhada, não um erro isolado.
Recomendação: correção centralizada na lógica de máscara, aplicada a todos os campos de valor monetário do app.
Tela: Detalhe de mesa — histórico de visitas
🔴 Histórico de visitas vinculado à mesa, não ao cliente
Problema: o contador de visitas e o histórico de comandas eram associados ao número da mesa, não a um identificador do cliente. A cada nova comanda na mesma mesa, o histórico acumulava dados de clientes diferentes.
Por que importa: além de comprometer a utilidade do recurso, o comportamento expunha dados de um cliente para outro.
Recomendação: vincular o histórico ao nome/identificador informado na abertura da comanda, não à localização física da mesa.
Tela: Nome do Operador (onboarding)
🟠 Botão de ação principal habilitado sem validação do campo obrigatório
Problema: o botão "Continuar" aparecia habilitado mesmo com o campo de nome vazio. Ao tocar sem preencher, nada acontecia — nenhuma ação, nenhuma mensagem de erro.
Por que importa: em uma etapa de onboarding, esse tipo de silêncio é onde o usuário mais hesita e mais abandona.
Recomendação: manter o botão desabilitado até um valor válido, ou exibir validação inline ao tentar avançar.
Tela: Gestão de mesas — swipe lateral
🟠 Rótulo da ação não corresponde ao comportamento real
Problema: o rótulo da ação de deslizar sobre uma mesa dizia "Excluir", mas o comportamento real era arquivar (reversível).
Por que importa: para um operador em plena correria de atendimento, achar que apagou uma mesa permanentemente pode gerar pânico e desconfiança no app — mesmo o dado estando seguro.
Recomendação: corrigir o rótulo para "Arquivar", alinhando linguagem e comportamento real.
Tela: Login
🟢 Prevenção de erro bem resolvida — vale preservar
O que funciona: o botão "Iniciar sessão com a Apple" permanece desabilitado até o aceite dos termos ser marcado.
Por que vale registrar: é um padrão de prevenção de erro correto, que deveria servir de referência para outros formulários do app — nem todo achado da auditoria é problema; parte do valor é apontar o que já está certo.
O papel da IA neste projeto
A IA permitiu que um desenvolvedor independente avançasse rapidamente na construção de um produto funcional e relativamente complexo.
Ao mesmo tempo, neste projeto, a auditoria revelou que velocidade de implementação e qualidade da experiência são problemas diferentes. Muitos dos achados não estavam relacionados à ausência de funcionalidade, mas à coerência entre decisões tomadas ao longo da construção: estados, terminologia, hierarquia, padrões de interação e comportamento entre fluxos.
Para mim, o aprendizado não foi que "IA produz experiências ruins". Foi que acelerar a implementação aumenta a importância de mecanismos de revisão, critérios de experiência e validação do produto como um todo.
Do diagnóstico para a execução
Ao final da semana, entreguei o relatório completo com os 253 achados classificados e recomendações de correção.
A entrega foi acompanhada por uma reunião de handoff de aproximadamente 45 minutos, em que percorremos os principais problemas, prioridades e o racional por trás das recomendações.
Desde então, o cliente utiliza o relatório como referência para a evolução contínua do produto.
Resultado
De "sei que algo está errado" para um plano acionável
Antes da auditoria, o cliente percebia problemas na experiência, mas não conseguia localizar nem priorizar as causas.
Depois da entrega, tinha 253 pontos documentados, severidade definida, recomendação para cada achado, e uma referência clara para orientar as próximas correções.
O principal resultado não foi a quantidade de problemas encontrados. Foi transformar uma percepção difusa de qualidade em um plano estruturado para evolução do produto.
O que esse projeto me ensinou
Velocidade de construção não elimina a necessidade de revisão
Ferramentas podem acelerar muito a implementação. A experiência ainda precisa ser analisada como sistema, considerando consistência, comportamento e uso real.
Diagnóstico também é uma entrega de Design
Nem todo trabalho de Product Design precisa resultar em novas telas. Às vezes, o maior valor está em transformar sinais dispersos em problemas claramente definidos e priorizados.
Saber o que preservar importa tanto quanto saber o que corrigir
Os 47 pontos positivos deram ao cliente referências do que já funcionava e poderia ser replicado durante a evolução do produto.
Bons produtos também precisam de uma perspectiva externa.
Gosto de trabalhar em problemas onde é preciso identificar padrões, estruturar complexidade e transformar diagnóstico em decisões acionáveis.