Arezzo&Co · Sistema de Anúncios

Um sistema, três jornadas: como a arquitetura por papel desbloqueou o gerenciamento de anúncios do grupo Arezzo&Co

Resumo — Product Designer, atuando na UX e UI da solução, 3 meses. Desenvolvimento de UX e UI de um app white-label — em parceria com uma empresa de tecnologia parceira — vinculado ao Gerenciador de Negócios do Facebook, para envio e acompanhamento de anúncios de lojas do grupo Arezzo&Co veiculados no Instagram, substituindo a ferramenta usada anteriormente pelo grupo. Três perfis com necessidades radicalmente diferentes — Marketing, Gestores de Tráfego e Lojistas — atendidos em uma única plataforma com arquitetura de informação adaptada por papel.

Contexto & Problema

O grupo Arezzo&Co operava múltiplas marcas (Arezzo, Schutz e outras) com centenas de lojas físicas, cada uma com autonomia para criar e submeter anúncios em redes sociais. A cadeia envolvia três atores com objetivos distintos: o Lojista que criava e acompanhava seus próprios anúncios, o Gestor de Tráfego que supervisionava um conjunto de lojas e aprovava as peças, e o time de Marketing que monitorava a performance consolidada de toda a marca e gerenciava o orçamento.

Entrei como Product Designer, atuando na UX e UI da solução, responsável pelo projeto completo — conduzindo entrevistas com cada perfil de usuário, mapeando as jornadas e a arquitetura de informação por papel, e desenvolvendo todas as interfaces (web e mobile) em Figma ao longo de 3 meses. O projeto foi feito em parceria com uma empresa de tecnologia parceira, e consistia em desenvolver um terceiro app — com proposta white-label, direcionado às marcas do grupo (Arezzo, Schutz e Anacapri) — vinculado ao Gerenciador de Negócios do Facebook, substituindo a ferramenta de gestão de anúncios usada anteriormente pelo grupo.

O escopo tinha três restrições fixas: a solução precisava ser uma plataforma coerente com rotas diferenciadas por papel, não três produtos separados; o mesmo sistema atendia Arezzo, Schutz e outras marcas do grupo, exigindo consistência visual sem perder a identidade de cada marca nos contextos relevantes; e 3 meses de prazo cobriram pesquisa, arquitetura, design e prototipação de web + mobile para todos os perfis.

Estado anterior: a ferramenta usada anteriormente pelo grupo não diferenciava por papel — Lojista, Gestor de Tráfego e Marketing acessavam essencialmente as mesmas telas, independentemente do que precisavam fazer, e o Lojista se perdia em métricas corporativas enquanto o Marketing não conseguia visão consolidada sem navegar por lojas individualmente.

Descoberta & Insight

As entrevistas revelaram que o problema não era de funcionalidade ausente — era de audiência errada. O sistema tinha as informações certas, mas as direcionava para quem não precisava delas. Um Lojista não queria saber o ROAS consolidado das 350 lojas do grupo; queria saber se o anúncio tinha sido aprovado e quanto do orçamento ainda sobrava. Um Gestor de Tráfego gerenciava aprovações de um portfólio inteiro de lojas — a pergunta dele era “o que estava pendente e de onde”, não como criar uma submissão. O Marketing era o único perfil que precisava do funil completo, de impressões a vendas, para a marca inteira.

Consolidar 2 entrevistas com stakeholders internos e a leitura de 2 painéis existentes num único board revelou que “orçamento” era o fio condutor entre todas as fontes — só que com rótulos diferentes em cada uma:

A virada: isso transformou o redesenho em um problema de arquitetura de informação, não de interface. Cada perfil precisava de um produto diferente dentro do mesmo sistema.

Desenhei um Canvas de Proposta de Valor pra cada um dos três perfis — o exemplo abaixo é o do Marketing:

Cada tarefa do Marketing virou um Job to be Done — a estrutura “quando eu vou / eu quero / para que eu possa” tirou a ambiguidade de tarefas genéricas como “acompanhar métricas” e forçou nomear o motivo real por trás de cada uma:

Processo & Decisões

A decisão que mais me custou foi a dos três fluxos distintos — a dúvida era se criar experiências separadas por papel ia dificultar a vida de quem, na prática, às vezes ocupava mais de um papel. Um gestor regional que também acompanhava os próprios anúncios não ia se sentir em casa em nenhum dos fluxos.

1. Arquitetura de informação por papel — problema: uma única arquitetura de informação para três perfis obrigava cada usuário a ignorar a maior parte do sistema. Opções: personalização por preferência (usuário escolhe o que ver — mais flexível, mais complexo de manter) vs. arquitetura fixa por papel (rotas e telas definidas no login — mais simples, mais adequada ao contexto corporativo). Escolha: arquitetura de informação diferenciada por papel, com navegação lateral distinta para cada perfil — Marketing (Home, Aprovações, Painel, Métricas, Orçamento, Cadastro, Notificações), Gestores de Tráfego (Home, Relatórios, Feed, Novo, Envios, Notificações) e Lojistas (Home, Novo, Meus Envios, Feed, Notificações). Porquê: o contexto de cada perfil é mutuamente exclusivo — misturá-los numa tela única prejudica todos.

2. Home como painel de controle contextual — problema: a home precisava responder perguntas diferentes para cada perfil sem virar uma tela genérica inútil. Opções: home única com filtros por papel (complexo, confuso) vs. três fluxos distintos otimizados para a tarefa primária de cada papel. Escolha: fluxos diferenciados — Marketing via orçamento consolidado, distribuição de investimento (Investido/Provisionado/Restante), métricas de performance das lojas ativas e Receita Impactada; Gestores de Tráfego viam as lojas sob sua responsabilidade com foco em decisões táticas; Lojistas viam seu valor disponível, seus anúncios ativos com resultados inline e um banner de alerta quando havia orçamento não utilizado. Porquê: a home era a primeira tela de cada sessão — ela precisava responder imediatamente à pergunta mais frequente de cada papel, sem exigir navegação.

3. Fluxo de aprovação com filtros compostos — problema: o Gestor de Tráfego recebia anúncios de múltiplas lojas simultaneamente; sem filtragem eficiente, a fila de aprovações virava ruído. Opções: lista linear com busca simples vs. grid visual com filtros compostos (Loja, Status, Orçamento, Posicionamento, Arquivo) e chips de acesso rápido. Escolha: grid de anúncios com filtros em cascata — ao selecionar “Status”, os sub-status apareciam com contagem (Novo: 5, Aprovado: 10, Reprovado: 2); chips de data, status ativo e ordenação sempre visíveis no topo. Porquê: o Gestor precisava priorizar a fila, não apenas percorrê-la — ver a contagem por status antes de filtrar permitia uma decisão de onde começar.

4. Métricas em funil para o Marketing — os primeiros wireframes tinham cards de KPIs isolados. Receita Impactada. ROAS. Ticket Médio. Cada número numa caixa separada. Fiz uma apresentação interna e o feedback foi educado demais para ser sincero — as pessoas concordavam que estava “claro” mas não conseguiam dizer o que o dashboard dizia sobre a saúde dos anúncios.

O problema era que cards isolados mostravam estado, não relação. O que o Marketing precisava entender era: em que ponto a cadeia perdia eficiência? “Conversas: 20” não respondia isso. “Impressões 3.538 → Conversas 20” respondia. Substituí os cards por um funil visual (Impressões → Engajamento → Cliques → Conversas → Vendas) — os KPIs ficaram como complemento, não como protagonistas.

Pipeline de pesquisa e design: entrevistas por perfil → mapeamento de jornadas + benchmarking → arquitetura de informação por papel → wireframes Figma → validações internas → interfaces web + mobile → prototipação → handoff para empresa parceira. A etapa de arquitetura de informação por papel foi feita antes de qualquer tela — definir quais rotas e módulos existiam para cada perfil foi o que tornou possível desenvolver as interfaces sem retrabalho.

O blueprint de serviço deixou visível o que nenhuma tela sozinha mostrava: o anúncio criado pelo Lojista passava por aprovação do Admin, integração com a API da empresa parceira e o Business Manager antes de voltar como métrica na tela do próprio Lojista — um ciclo que atravessava 4 camadas diferentes de visibilidade.

O handoff em si era documentado tela a tela: cada fluxo saía com o Job to be Done que o originou, os wireframes anotados com comportamentos especiais (validações, regras de campo, mensagens de erro específicas por tipo de arquivo) e os modais de sucesso/erro especificados à parte — pra reduzir dúvida de implementação sem exigir alinhamento síncrono pra cada detalhe.

Solução & Craft

Uma plataforma multi-perfil de gerenciamento de anúncios com três experiências distintas dentro do mesmo sistema:

• Lojistas criavam e acompanhavam seus próprios anúncios, visualizavam seus resultados (engajamento, cliques, receita gerada, ROAS) e eram alertados quando tinham orçamento disponível não utilizado.
• Gestores de Tráfego aprovavam ou reprovavam anúncios via fila filtrada, monitoravam as lojas sob sua responsabilidade e acompanhavam relatórios táticos de performance.
• Marketing acessava o painel consolidado com funil de conversão, gerenciava o orçamento mensal por loja com edição inline, e monitorava a saúde do portfólio de anúncios de toda a marca.

Todas as telas foram entregues em versão web e mobile, mas o quanto de polimento cada perfil recebia no mobile variava — e isso vinha direto de como cada um realmente ia usar o app: Lojistas usavam o app quase inteiramente no celular, então o fluxo precisava ser tão simples quanto tirar uma foto do produto na loja e criar o anúncio ali mesmo. Gestores de Tráfego dividiam o uso quase igualmente entre mobile e desktop. Marketing operava majoritariamente no desktop, com o mobile como apoio pontual em deslocamento.

A tela de Lojas do Gestor de Tráfego é um bom exemplo de como a mesma informação se adaptava aos dois formatos, sem virar uma versão reduzida um do outro:

Já no Lojista, a mudança mais visível foi de fundo: o app anterior era genérico (mesmo conteúdo pra qualquer perfil); o novo já nasce mostrando o que o Lojista mais queria ver no primeiro segundo — o próprio saldo:

• O banner de alerta de orçamento disponível no Lojista usava cor âmbar (não vermelho — não era urgência, era oportunidade) e oferecia ação imediata “Saiba mais” sem forçar interação.
• Os cards de anúncio na aprovação exibiam status com badge colorido (laranja “Novo”, verde “Ativo”) + data de veiculação + orçamento no topo, permitindo leitura do contexto antes de abrir o anúncio.
• O orçamento editável usava edição inline ativada por ícone de lápis — o campo abria com o valor atual pré-preenchido e um botão “Confirmar” sem saída da tabela.
• A navegação mobile foi redesenhada por perfil: Lojistas tinham “Novo” com destaque central na bottom nav (sua ação primária); Gestores tinham “Relatórios” como primeiro item.
• Os badges de status (laranja “Novo”, verde “Ativo”) combinavam cor e rótulo textual — o estado era legível sem depender de cor isolada, atendendo WCAG 1.4.1 para usuários com daltonismo.

Aprendizados

Entreguei interfaces web e mobile para os três perfis, cobrindo todas as jornadas mapeadas na pesquisa. Antes do handoff, testei o protótipo navegável com usuários reais do perfil Marketing pelo Maze — a rodada de teste revelou gaps pontuais na home contextual, que corrigi antes da entrega final.

O aprendizado que fica pra próximos projetos é sobre o custo real de arquitetura por papel: três fluxos significam três superfícies pra manter consistentes conforme o produto evolui, três lugares pra replicar qualquer ajuste de identidade visual ou regra de negócio. Compensa quando os papéis são genuinamente mutuamente exclusivos — e essa confirmação veio de entrevista real com cada perfil, não de suposição de quem desenha.

Entrar via parceria de tecnologia trouxe uma disciplina de handoff que vale registrar: documentar cada fluxo com o Job to be Done que o originou, os wireframes anotados e os modais de erro especificados à parte garantiu que a equipe da empresa parceira desse sequência ao projeto de forma autônoma — a marca de um handoff bem-feito é o projeto continuar de pé sem o designer por perto.