O app e o problema de comportamento
O Enjoei é um marketplace brasileiro de moda circular com mais de 370 mil vendedores ativos. Funciona como uma rede social de compra e venda: qualquer pessoa cria sua "lojinha", anuncia peças usadas e negocia diretamente com compradores. A proposta de valor é clara: desapego fácil, linguagem descontraída, consumo consciente.
Este projeto foi desenvolvido como trabalho final da pós-graduação em UX Design. Não é um projeto interno da empresa. O que existia era um app real, usuários reais e um problema de comportamento documentado em fontes públicas.
O problema declarado
A análise de avaliações na Play Store e no Reclame Aqui, no período de junho a setembro de 2025, revelou um padrão consistente de reclamações concentrado em quatro áreas: pagamento e estorno (30%), atrasos na entrega (25%), suporte inacessível (20%) e falta de clareza sobre taxas e repasses (15%).
O dado mais importante não era o volume de reclamações, era o que causava a frustração. Em quase todos os casos os usuários não relatavam falhas técnicas, relatavam não saber o que estava acontecendo. O app comunicava bem na fase de descoberta, o feed, os produtos, a navegação por categorias. Falhava sistematicamente nos momentos em que o dinheiro entrava na equação.
Como redesenhar o fluxo de publicação para que o vendedor entendesse o que iria acontecer, e quando, antes de pressionar "publicar"?
A hipótese
O Enjoei já tinha a informação: sabia o preço do produto, sabia a taxa cobrada, sabia quando o repasse seria feito. Nada disso estava escondido em algum servidor inacessível.
O problema era que essa informação aparecia no lugar errado, no momento errado, ou não aparecia durante o fluxo de criação do anúncio. Se o vendedor visse o valor que iria receber antes de publicar, e soubesse onde buscar ajuda se algo desse errado, a percepção de confiança aumentaria sem exigir mudanças na arquitetura de dados ou na lógica de negócio do produto.
Discovery
Desk research em fontes públicas
O ponto de partida foi o que os usuários já tinham dito publicamente. Foram analisadas avaliações na Play Store e no Reclame Aqui de um período de quatro meses. A categorização das reclamações não foi feita por intuição, os temas emergiram do próprio volume: pagamento, entrega, suporte e taxas representavam juntos 90% das insatisfações documentadas.
Teste de usabilidade com o app real
Três participantes com perfis distintos (compradora recorrente, vendedor ocasional, usuário interessado em moda sustentável) executaram uma tarefa específica: comprar uma peça de até R$50 e explorar as telas de acompanhamento do pedido. Os três navegaram com fluência na busca e seleção de produtos. Os três expressaram insegurança quando o fluxo entrou em território financeiro.
O dado mais revelador não foi onde os usuários travavam, foi o que diziam em voz alta: "não sei se o pagamento foi confirmado", "onde vejo se o pedido foi enviado?". Não eram dúvidas sobre como usar o app, eram dúvidas sobre o que estava acontecendo com o dinheiro deles.
Proto-persona como síntese
Renata, dona de brechó online, 38 anos, vendedora recorrente no Enjoei, foi construída a partir dos padrões observados na pesquisa. O insight que ela representa: para quem vende com frequência, o problema não é criar o anúncio, é não saber nada sobre o que acontece depois que o anúncio vai ao ar.
Análise e priorização
A análise de concorrência comparou o fluxo de criação de anúncio do Enjoei com Shopee, Mercado Livre e OLX em oito dimensões: indicação de etapas, ajuda contextual, preview antes de publicar, clareza sobre taxas, valor estimado a receber, opção de salvar rascunho, comunicação de segurança financeira e suporte acessível durante a venda.
O Enjoei ficou abaixo da média dos concorrentes em cinco das oito dimensões. O Mercado Livre resolvia todas as oito. Nenhuma das lacunas identificadas exigia mudança na infraestrutura do produto, eram majoritariamente decisões de comunicação e arquitetura de informação.
A priorização via Matriz GUT ranqueou os problemas por gravidade, urgência e tendência: falta de clareza sobre o valor a receber (prioridade 100), ausência de ajuda contextual (64), insegurança ao sair do fluxo sem saber se o anúncio seria salvo (48), fluxo longo sem indicação de progresso (27).
Decisões de design
A estratégia foi deliberadamente conservadora: melhorar a comunicação do que já existia, não adicionar complexidade. Quatro intervenções, nenhuma tela nova do zero.
Barra de progresso no topo.
O fluxo de criação de anúncio tem múltiplas etapas, nenhuma delas indica quantas faltam. A barra resolve o problema de previsibilidade sem mudar nenhuma etapa, apenas torna o fluxo inteiro visível de uma vez. Princípio aplicado: visibilidade do status do sistema, heurística 1 de Nielsen.
Valor aproximado a receber na tela de revisão.
Antes de publicar, o vendedor vê o preço definido, a taxa do Enjoei em percentual e em reais, e o valor que vai receber. Essa informação já existe no sistema. A decisão de design foi mostrá-la antes de publicar, não depois de vender.
Ajuda contextual por etapa.
O botão "Precisa de ajuda com essa venda?" aparece em todas as etapas, mas direciona para conteúdo específico de cada momento. A ajuda não interrompe o fluxo.
Tela de confirmação ao sair.
Clicar em "sair" durante a criação do anúncio passou a exibir uma tela com três opções: voltar para o anúncio, salvar como rascunho, ou sair e descartar. A ausência dessa tela gerava o comportamento documentado no teste: usuários evitavam clicar em "sair" com medo de perder o que já tinham preenchido.
Validação
Os wireframes de baixa fidelidade foram testados com cinco participantes, vendedores ocasionais entre 29 e 42 anos. Três hipóteses foram confirmadas: a barra de progresso reduziu a sensação de fluxo infinito, a transparência financeira ajudou na tomada de decisão, e a opção de salvar rascunho foi percebida como alívio por quem usa o app de forma fragmentada.
Dois ajustes derivaram do teste. O botão de ajuda precisava de destino claro, no primeiro wireframe o clique não deixava óbvio o que aconteceria. E a taxa do Enjoei precisava aparecer em percentual e em valor absoluto, mostrar apenas a regra percentual não era suficiente.
O teste A/B que eu desenharia
Este é um projeto acadêmico, testado em protótipo de baixa fidelidade, sem implementação em produção. Se o redesign fosse para produção, o primeiro teste A/B seria na tela de revisão pré-publicação: variante de controle sem o valor a receber explícito (fluxo atual) contra variante com o cálculo visível antes do botão "publicar", medindo taxa de conclusão do fluxo de criação de anúncio e volume de tickets de suporte sobre taxas no pós-publicação. A hipótese: tornar o valor visível antes da decisão reduz tanto o abandono no fluxo quanto a necessidade de suporte reativo depois.
Conclusão
O que não foi medido e o que seria medido
Este é um projeto acadêmico. Os wireframes foram testados em protótipo de baixa fidelidade. Não há dados de implementação, conversão ou variação de NPS antes e depois.
O que existe é um processo completo de discovery documentado, hipóteses testadas com usuários reais em duas rodadas de teste, e decisões de design fundamentadas e revisadas.
Os KPIs que eu instrumentaria para medir o impacto real em produção:
Taxa de conclusão do fluxo de criação de anúncio;
Taxa de abandono por etapa;
Volume de tickets de suporte sobre taxas e repasse;
NPS segmentado por vendedores recorrentes, o segmento que o problema afetava com mais intensidade.
Aprendizados
Interface divertida e transação financeira não usam a mesma linguagem. O Enjoei construiu uma das identidades mais coerentes do e-commerce brasileiro: descontraída, próxima, social. Isso funciona na descoberta, cria problema no checkout. A resposta não é abandonar a linguagem da marca, é reconhecer que existe uma hierarquia de contextos, e que pagamento e repasse financeiro pedem precisão, não leveza.
Desk research em fonte pública é dado de verdade. Avaliações na Play Store e no Reclame Aqui são sinais de comportamento real de usuários reais. Não substituem entrevistas, mas orientam onde buscar.
A confiança é construída antes da transação. Nenhum dos problemas identificados era tecnicamente complexo, todos eram decisões de quando mostrar qual informação.