Tornando o ERP navegável desde o primeiro acesso com uma camada de busca global
Information Architecture
Navigation
Discoverability
MVP
Platform UX
Contexto
O menu do ERP exibia tudo para todos, sem hierarquia adaptada ao momento do usuário. O resultado era sobrecarga cognitiva — especialmente para usuários de primeira viagem que precisavam encontrar ações específicas sem conhecer a estrutura do produto.
Problema
Descoberta de funcionalidades dependia inteiramente de exploração por tentativa e erro. Não havia camada de busca que permitisse ao usuário chegar diretamente ao que precisava — ação, feature ou entidade — sem navegar pela árvore de menu.
Abordagem
Design de uma camada de busca global como MVP: busca de ações, features e entidades dentro do produto, com resultados contextuais que respondem à intenção do usuário em vez de replicar a estrutura do menu.
Resultado
Efeito mensurável em descoberta de features críticas: +600% em acesso a Pix compensado, +233% em Pix emitido, +100% em link de pagamento — entre outros.
Resultados
+600%Pix compensadoBusca + navegação
+233%Pix emitidoBusca + navegação
+100%Link de pagamentoBusca + navegação
+41%ComprasBusca + navegação
+37%Relatórios de vendasBusca + navegação
Atuação
Fui o Product Designer responsável pelo design do componente de busca global e pela sua integração como camada de navegação independente do menu principal. O trabalho cobriu três frentes: decisões de arquitetura sobre o escopo inicial de indexação (rotas e URLs do produto no MVP), design dos estados do componente e coordenação com o DS Design para que o componente resultante pudesse ser incorporado ao Design System.
O time que executou o projeto: UX Lead Maicon Andre Zanette, PMs Luccas Trombetta e Gabriella Antunes de Oliveira, Tech Lead Lucas Alfredo Cercal, DS Design Thiago Xavier de Ataide. Atuei como PD do squad, responsável pelas decisões de interface e pela especificação de acessibilidade do componente.
Estratégia
Os dados de ativação documentavam o problema com precisão: 69% dos trials não voltavam no segundo dia. Menos de 10% realizavam ações essenciais — vendas, cobranças, integrações — no período de trial. Em fevereiro de 2025, a ferramenta Meetrox registrou 219 citações de falta de funcionalidades, 130 de dificuldade de uso e 70 de expectativas não atendidas.
Esses números apontavam para dois diagnósticos possíveis: o produto não entregava o que o usuário precisava, ou o produto entregava mas o usuário não conseguia encontrar. A segunda hipótese tinha suporte em fundamentos bem estabelecidos de UX: a Lei de Hick-Hyman estabelece que o tempo de decisão aumenta com o número de opções disponíveis simultaneamente; o Princípio de Miller descreve os limites de carga cognitiva em interfaces. Um menu lateral que exibe tudo para todos viola os dois.
A decisão estratégica foi tratar baixa encontrabilidade como causa primária — não falta de funcionalidade. O MVP foi desenhado como camada complementar ao menu, não substituta: mantém a estrutura existente para usuários que já conhecem o produto e cria um atalho direto para quem está aprendendo. Escopo mínimo deliberado: sem autocompletar, sem histórico, sem personalização — para validar o padrão de uso antes de investir em expansão.
Processo
O processo seguiu uma sequência deliberada: análise de dados de ativação → pesquisa qualitativa com novos clientes → desk research e benchmark → avaliação de alternativas de componente → especificação do componente isolado.
A pesquisa qualitativa com novos clientes foi determinante para transformar hipóteses em evidência. Os problemas relatados eram concretos: ícones do menu fechado sem nome — clientes tentavam decorar os ícones para navegar; termos divergentes entre a central de ajuda (“PDV”) e o sistema (“Frente de Caixa”); importação com limite de 500 registros sem mensagens de erro claras; chat de suporte com 30 minutos de espera médio.
O benchmark cobriu doze sistemas de busca isolada em SaaS: Spotlight Apple, Google Search, Sketch, Slack, Notion, Linear, GitHub, Superhuman, Airtable, Coda, Raycast e Alfred. Características convergentes observadas: busca em tempo real enquanto digita, categorização clara por tipo de resultado, acessibilidade por atalho de teclado (⌘+K como padrão de mercado), tolerância a erros de digitação e personalização contextual.
Diagnóstico
Pergunta: A baixa ativação reflete falta de funcionalidade ou falta de encontrabilidade?
O que foi feito: Análise de métricas de trial (retenção D2, realização de ações essenciais) e dados da ferramenta Meetrox (fev/25).
Achado principal: 69% dos trials não retornam no segundo dia. Menos de 10% realizam ações essenciais no período de trial. O Meetrox registrou 219 citações de falta de funcionalidades, 130 de dificuldade de uso — indicando que parte do que era percebido como “falta” era na verdade inacessibilidade.
Artefato: Análise quantitativa de funil de ativação e extrato de citações Meetrox.
Pergunta: Quais são os pontos concretos de bloqueio de navegação para usuários recém-chegados ao produto?
O que foi feito: Sessões com novos clientes (estudo de usuários minimamente ativados) observando navegação e coleta de relatos espontâneos.
Achado principal: Quatro padrões de bloqueio documentados: (1) ícones do menu fechado sem nome — usuários tentavam memorizar ícones; (2) terminologia divergente entre ajuda e sistema (PDV vs. Frente de Caixa); (3) importação com limite de 500 registros sem mensagem de erro clara; (4) suporte com 30 minutos de espera, forçando o usuário a buscar respostas dentro do produto sem encontrá-las.
Artefato: Relatos categorizados por tipo de bloqueio; mapeamento de divergências terminológicas.
Pergunta: Quais padrões de busca global resolvem o problema de encontrabilidade em produtos de complexidade comparável?
O que foi feito: Desk research estruturado cobrindo doze produtos: Spotlight Apple, Google Search, Sketch, Slack, Notion, Linear, GitHub, Superhuman, Airtable, Coda, Raycast e Alfred. Análise de comportamento de resultados, padrões de acessibilidade e lógica de personalização contextual.
Achado principal: Convergência em cinco características: busca em tempo real, categorização por tipo, atalho ⌘+K, tolerância a erros e personalização contextual. Nenhum produto de referência replicava a estrutura de menu nos resultados de busca.
Artefato: Tabela comparativa de padrões de busca por produto; princípios de design extraídos.
Pergunta: Algum componente existente no produto ou no Design System resolve o problema sem criar novo padrão?
O que foi feito: Avaliação de três alternativas: Search select, Search form e Autocomplete (PDV). Cada uma testada contra o critério de funcionar como ponto de entrada global desacoplado da página atual.
Achado principal: As três alternativas falharam no critério central: todas dependem de contexto de página e não conseguem funcionar como camada de navegação global. A decisão de criar um componente isolado foi tomada a partir dessa constatação, não como preferência estética.
Artefato: Comparativo de alternativas com critérios de avaliação; justificativa documentada para o componente novo.
Solução
Problema: Como permitir ao usuário acessar ações e features diretamente, sem depender de navegação pelo menu?
Decisão de design: Busca global acessível via atalho de teclado e campo fixo no topo do produto. Resultados organizados por tipo (ações, features, entidades) — não por ordem alfabética ou frequência global. Resultados contextuais: priorizados pelo perfil e pelo histórico de uso do usuário. A lista de resultados é limitada a 6 itens visíveis com scroll para mais; o item com maior correspondência é pré-selecionado. Escopo inicial de indexação restrito a rotas e URLs do produto — decisão de MVP para validar o padrão de uso antes de ampliar para entidades e conteúdo.
Visuais: componente de busca global com resultados categorizados · estados de resultado e vazio
Problema: Busca com resultados genéricos não resolve o problema de descoberta — o usuário ainda precisa filtrar e avaliar relevância.
Decisão de design: Três tipos de resultado distintos: resultado único com ação direta (o usuário vai direto para onde precisa), múltiplos resultados com contexto (o usuário escolhe com informação suficiente) e sem resultado com sugestão alternativa (o usuário não encontra um beco sem saída). O componente tem cinco estados especificados: inicial (ensina como usar na primeira interação), intermediário (skeleton enquanto os resultados carregam), resultado (lista limitada a 6 itens, item de maior match pré-selecionado, scroll para mais), vazio (orienta o usuário para próximo passo) e ideal (exibe pesquisas recentes para usuários que retornam).
Visuais: os 5 estados do componente — inicial, intermediário, resultado, vazio, ideal
Problema: Componente de busca global usado por base diversa de usuários, incluindo usuários que dependem de navegação por teclado ou tecnologia assistiva.
Decisão de design: Cinco critérios WCAG aplicados na especificação: contraste mínimo 4.5:1 (WCAG 1.4.3), alvo clicável de no mínimo 44px (WCAG 2.5.5), navegação completa por teclado (WCAG 2.1.1), foco visível em todos os estados (WCAG 2.4.7) e controle do usuário para fechar o modal (WCAG 2.2.4). Boas práticas documentadas para reuso: o componente deve existir em um único ponto do sistema; nomes de resultados devem ser curtos o suficiente para não ultrapassar uma linha; qualquer uso em outras áreas exige alinhamento prévio com o DS.
Visuais: especificação de acessibilidade · navegação por teclado · estados de foco
Reflexão
O que este projeto realmente foi
Uma investigação sobre demanda reprimida. Os dados de ativação mostravam baixo uso de features valiosas — a interpretação imediata seria que os usuários não precisavam delas. O que a busca revelou é que eles precisavam e não conseguiam encontrar. O +600% em Pix compensado não é resultado de uma feature nova: é o desbloqueio de comportamento que já existia como intenção mas não conseguia chegar ao destino.
O projeto foi, em termos mais precisos, uma prova de conceito para a hipótese de que arquitetura de informação tem efeito mensurável sobre comportamento de produto — não apenas sobre satisfação do usuário.
O que permaneceu depois
O componente JGD-Isolated Search foi incorporado ao Design System da Conta Azul com especificação completa de estados, critérios de acessibilidade e boas práticas de reuso. A visão de futuro documentada durante o projeto — integração com IA para sugestões inteligentes, navegação guiada por dados, ordenação por uso recente, integração de artigos de ajuda e treinamentos — ficou registrada como backlog estratégico. O componente existente é a fundação técnica e de design para essa expansão.
O que eu faria diferente
Instrumentaria o componente com rastreamento de eventos desde o lançamento do MVP. Os números de descoberta de features foram mensuráveis porque outros sistemas de tracking estavam ativos — mas não havia dados específicos de uso da busca em si: termos mais buscados, taxa de clique nos resultados, frequência de estado vazio. Esses dados teriam acelerado a decisão de expandir o escopo de indexação e teriam dado base para priorizar quais entidades adicionar primeiro.
Também conduziria pesquisa qualitativa dedicada especificamente ao comportamento de busca antes de definir os estados do componente — não apenas depois do rollout. A pesquisa com novos clientes documentou os bloqueios de navegação existentes, mas não testou padrões mentais de busca: o que os usuários esperam encontrar, como formulam as queries, qual o custo percebido de um resultado vazio.
Vamos trabalhar juntos?
Disponível para full-time · remote · freelancer
Aberto a novos projetos, oportunidades e conversas.