Como criar uma arquitetura de informação que aguenta crescer

Nenhum produto começa confuso. Ele fica. E o processo é tão gradual que dificilmente alguém consegue apontar o momento exato em que aconteceu. Um dia o menu tinha cinco itens e parecia óbvio. Dois anos depois tem dezenove, três significam quase a mesma coisa, uma funcionalidade importante está escondida em Configurações e o time de vendas criou um documento explicando onde encontrar cada coisa.

A interface não ficou assim porque alguém decidiu criar uma arquitetura ruim. Ficou assim porque cada nova funcionalidade resolveu o problema de onde entrar no produto sem reconsiderar o sistema inteiro que já existia. Arquitetura de informação costuma quebrar por acúmulo.

O menu vira o histórico do roadmap

O padrão é fácil de reconhecer. O time entrega uma funcionalidade nova. Ela precisa aparecer em algum lugar. Criar um item no menu é barato, rápido e não exige mexer no que já funciona. Isoladamente, a decisão parece razoável. Depois outra squad faz a mesma coisa. E outra. Até que a navegação deixa de representar o modelo mental de quem usa e começa a representar a ordem em que o produto foi construído.

Esse custo raramente aparece no ticket que criou o problema. Aparece depois:

• no tempo de treinamento de novos clientes;

• em chamados perguntando onde alguma coisa fica;

• em funcionalidades pouco descobertas;

• em vendas precisando demonstrar caminhos básicos;

• em usuários criando atalhos próprios para sobreviver à estrutura;

• em times diferentes dando nomes diferentes para conceitos parecidos.

Uma funcionalidade que ninguém encontra pode parecer uma funcionalidade que ninguém quer. E essas duas coisas levam a decisões de roadmap completamente diferentes.

Quem conhece o produto demais deixa de enxergar a estrutura

Uma das heurísticas clássicas de usabilidade da Nielsen Norman Group é recognition rather than recall: a interface deveria tornar informações, ações e opções visíveis ou facilmente recuperáveis, em vez de depender da memória do usuário. Isso tem uma consequência especialmente importante para arquitetura de informação: quem usa o produto todos os dias aprende a navegar apesar da arquitetura.

Depois de algum tempo, você não lê mais o menu. Você sabe onde clicar. Configurações → Avançado → Integrações → Webhooks. Não parece difícil porque você decorou. O problema aparece com alguém que ainda precisa inferir esse caminho.

É por isso que pessoas do próprio time são referências ruins para responder:

isso está fácil de encontrar?

Elas podem ajudar a explicar o domínio. Mas conhecem nomes internos, histórico de decisões, atalhos e localização das funcionalidades. Quando alguém da equipe diz “isso está óbvio”, muitas vezes o que está dizendo é “eu sei onde fica”. São coisas diferentes. No painel operacional, o mesmo problema aparece quando conhecimento acumulado do sistema é confundido com clareza da interface.

Antes de organizar, descubra qual lógica o produto está usando

Produtos podem ser organizados por vários eixos. Três aparecem com frequência em SaaS B2B.

Por objeto

Clientes, cobranças, pedidos, produtos, faturas, transações. A navegação representa as entidades principais do domínio. É uma estrutura que pode envelhecer bem porque objetos centrais tendem a mudar menos que funcionalidades. Mas pode ficar ruim quando uma tarefa atravessa vários deles. Para responder “por que este cliente não recebeu?”, talvez a pessoa precise passar por Cliente, Cobrança, Transação e Repasse.

Por tarefa

Cobrar, conciliar, importar, analisar, emitir relatório. Aqui, a navegação começa pelo que a pessoa quer fazer. Funciona bem quando existem tarefas claras e relativamente estáveis. O problema aparece quando o número de workflows cresce e cada nova capacidade vira mais uma ação na navegação principal.

Por papel ou área

Financeiro, administrador, operações, comercial. Essa organização pode fazer sentido quando as responsabilidades são realmente separadas. Mas papéis reais raramente são perfeitamente estanques. Uma pessoa pode administrar a conta e também operar cobranças. Uma empresa pequena pode ter alguém fazendo quatro funções. E permissões não precisam necessariamente determinar arquitetura de informação.

Esses três eixos não são as únicas formas possíveis. O ponto é identificar qual lógica está organizando cada nível.

O problema começa quando cada item responde a uma lógica diferente

Leia este menu:

Clientes
Conciliar
Área financeira
Relatórios
Criar cobrança
Transações

Ele mistura objeto, tarefa, perfil, objeto, tarefa, objeto. Nenhum item isoladamente é absurdo. O conjunto exige que o usuário descubra qual lógica aplicar para cada intenção. Onde altero uma cobrança? Em Cobranças? Em Clientes? Em Conciliar? Na Área financeira?

Essa ambiguidade é mais importante que a quantidade bruta de itens. Um menu com dez opções claramente distintas pode ser mais fácil de usar que um com cinco categorias vagas. Por isso eu evitaria começar uma reorganização com:

precisamos reduzir o número de itens.

A pergunta melhor é: que modelo o usuário deveria conseguir inferir a partir desta estrutura?

Em muitos SaaS B2B, objeto em cima e tarefa dentro funciona bem

Não é uma regra universal, mas é uma combinação útil em produtos complexos. A navegação principal pode representar entidades relativamente estáveis:

Clientes
Cobranças
Transações
Relatórios

E, dentro de Cobranças, aparecem tarefas como:

Criar cobrança
Cancelar
Contestar
Exportar
Conciliar

Isso evita transformar toda capacidade nova em item de primeiro nível. A estrutura principal muda pouco. A complexidade cresce dentro do contexto ao qual pertence. Também cria uma pergunta boa para qualquer feature nova: isso criou uma nova parte fundamental do domínio ou apenas uma nova ação sobre alguma coisa que já existe? Se for a segunda opção, talvez ela não precise disputar espaço na navegação principal.

Banco de dados não é arquitetura de informação

Outro caminho comum é deixar a estrutura técnica vazar para a interface. Se existem tabelas de customers, payments, subscriptions, settlements e disputes, o menu vira Clientes, Pagamentos, Assinaturas, Liquidações e Disputas. Às vezes isso funciona. Às vezes não.

A estrutura interna do sistema descreve como o software armazena informação. A arquitetura da interface precisa descrever como alguém procura, entende e trabalha com ela. Os dois modelos podem coincidir. Não precisam. Esse é um dos motivos pelos quais nomes escolhidos pelo time técnico às vezes parecem perfeitamente claros internamente e estranhos para o cliente.

Card sorting ajuda a descobrir como as pessoas agrupam

Uma vantagem de arquitetura de informação é que parte importante dela pode ser investigada antes de existir interface final. O card sorting é uma das técnicas usadas para isso. Você transforma conteúdos, objetos ou funcionalidades em cartões e observa como pessoas representativas do público os agrupam. Em um card sorting aberto, elas também podem nomear os grupos.

Esses nomes são especialmente interessantes porque revelam o vocabulário que aparece espontaneamente. Talvez o produto use:

Gestão de recebíveis

e clientes chamem aquilo de:

Dinheiro a receber.

Ou o sistema tenha:

Credenciais de integração

enquanto desenvolvedores procuram:

Chaves da API.

Isso não significa aceitar automaticamente o termo mais popular. Domínio, precisão e regulamentação podem exigir vocabulário específico. Mas mostra a distância entre a linguagem interna e o modelo mental do usuário.

E aqui existe um cuidado com amostra. A famosa recomendação de “cinco usuários” não é regra para qualquer pesquisa de UX. Para card sorting, principalmente quando o objetivo é encontrar padrões de agrupamento, são necessários grupos maiores. O tamanho depende da abordagem e do nível de confiança que você precisa.

Depois, teste se alguém consegue encontrar

Card sorting ajuda a formar hipóteses de estrutura. Ele não prova que a estrutura final funciona. Para isso existe outra técnica muito útil: tree testing. Você apresenta apenas a hierarquia textual da navegação, sem layout final, e então dá tarefas. Por exemplo:

Você precisa cancelar uma cobrança recorrente. Onde procuraria?

A pessoa percorre a árvore. Cobranças → Assinaturas → Detalhes → Cancelamento. Ou talvez escolha outro caminho completamente diferente.

O valor desse teste é remover boa parte do efeito visual. Você não está avaliando cor, posição de botão ou componente. Está testando o sistema de categorias e labels. Se muita gente vai para o lugar errado, você pode descobrir isso antes de construir cinquenta telas em cima daquela estrutura.

Card sorting pergunta mais “como você organizaria isso?”. Tree testing pergunta “você encontra isso nesta organização?”. São problemas diferentes.

Primeiro clique errado é um sinal, não uma sentença

Imagine que a tarefa seja:

alterar os dados bancários usados para receber seus repasses.

Metade procura em Configurações. A outra metade em Financeiro → Repasses. Isso não significa automaticamente que uma das opções está errada. Pode significar que existem dois modelos plausíveis para a mesma tarefa.

A solução talvez seja mudar o agrupamento, ajustar o nome, permitir dois caminhos ou adicionar referência cruzada. Arquitetura de informação não precisa obrigar cada coisa a existir em um único lugar conceitual quando o modelo mental legítimo dos usuários permite mais de uma entrada. O objetivo é reduzir o custo de encontrar, não defender a pureza da árvore.

Busca não corrige arquitetura, mas também não é fracasso

Produtos grandes precisam de busca. Isso não significa necessariamente que a navegação falhou. Em sistemas com centenas de clientes, transações, documentos ou configurações, buscar pode ser simplesmente o caminho mais eficiente para quem já sabe o que quer. O problema aparece quando a busca passa a ser necessária para descobrir as próprias capacidades do produto.

Existe diferença entre:

buscar a transação #847239.

e:

buscar onde fica a funcionalidade de exportar relatório.

No primeiro caso, search é ferramenta operacional. No segundo, talvez esteja compensando uma estrutura difícil de compreender. Busca pode complementar arquitetura. Não deveria ser desculpa para não ter uma.

O suporte já sabe onde a arquitetura está quebrando

Uma das melhores fontes para revisar IA não está no Figma. Está no atendimento. Procure mensagens como “onde encontro...”, “como chego em...”, “não achei...”, “isso fica em qual menu?”, “onde mudou...”, “pensei que estaria em...”. Essas frases são quase tree tests acontecendo espontaneamente em produção.

Também procure tutoriais internos. Se o suporte precisa enviar frequentemente:

Vá em Configurações → Avançado → Financeiro → Integrações → Gerenciar

existe informação importante ali. O problema pode ser estrutura, nomenclatura, permissão ou falta de acesso contextual. Mas o caminho merece investigação.

Funcionalidade pouco usada pode estar apenas mal localizada

Essa é uma consequência importante para roadmap. Imagine que uma feature criada seis meses atrás tem adoção baixa. O time conclui:

clientes não querem isso.

Talvez. Mas antes vale descobrir: eles encontraram? Entenderam pelo nome? Viram no contexto em que precisavam? Sabiam que existia? Analytics consegue mostrar quem abriu uma tela. É muito mais difícil observar quem precisava dela e nunca a encontrou. Por isso descoberta também precisa entrar na análise de adoção. Construir mais funcionalidades em cima de uma arquitetura que esconde as existentes aumenta o problema.

Reorganizar machuca justamente quem mais usa

Existe um motivo legítimo para times evitarem mudanças grandes de navegação. Usuários experientes criaram memória. Eles sabem que determinada coisa fica no terceiro item, depois no segundo submenu. Uma arquitetura nova pode ser objetivamente melhor para novos usuários e inicialmente pior para quem já domina a antiga. Esse custo precisa ser tratado como parte do redesign. Não como argumento para nunca mudar.

Não existe regra de que tudo precisa mudar de uma vez

Uma migração grande pode fazer sentido quando a estrutura inteira está sendo substituída. Uma mudança incremental pode fazer mais sentido quando existe risco operacional alto. O importante é evitar um estado híbrido sem lógica clara. Se parte do produto segue o modelo antigo e parte o novo, o usuário precisa aprender duas arquiteturas ao mesmo tempo.

Quando a transição for necessária, trate-a como migração:

• mantenha URLs antigas redirecionando quando possível;

• atualize documentação;

• preserve links salvos;

• prepare suporte e Customer Success;

• comunique mudanças importantes;

• destaque onde funções muito usadas passaram a ficar;

• monitore busca, erros de navegação e chamados após a alteração.

A melhor arquitetura do mundo ainda pode produzir uma experiência ruim se for lançada sem considerar memória existente.

Não transforme a mudança em campanha

Usuário não precisa assistir a um tour de quinze telas porque você reorganizou o menu. Normalmente ele quer responder uma pergunta:

onde está aquilo que eu usava?

Uma comunicação útil pode ser simples:

Relatórios agora ficam em Análises → Relatórios.

ou:

Integrações foram movidas para Configurações → Desenvolvedores.

Explique mudanças concretas. Não celebre a reorganização como se o usuário tivesse pedido uma nova arquitetura de informação. Ele provavelmente não pediu. Pediu para encontrar as coisas.

Alguns sinais de que vale investigar a arquitetura

Nenhum deles prova sozinho que a IA está quebrada. Mas juntos formam um padrão.

• O suporte frequentemente explica caminhos. Pessoas perguntam onde funções importantes estão.

• Features semelhantes existem em áreas diferentes. A estrutura cresceu por ownership interno.

• Dois nomes parecem intercambiáveis. “Analytics” e “Relatórios”. “Configurações” e “Preferências”. “Pagamentos” e “Transações”.

• Treinamento ensina principalmente navegação. Parte relevante do onboarding é decorar onde as coisas ficam.

• Features importantes têm descoberta muito baixa. Usuários que claramente têm aquele job nunca chegam à tela.

• A arquitetura replica organograma ou squads. A interface está organizada por quem construiu, não por quem usa.

• Cada lançamento pede mais um item principal. Não existe hierarquia capaz de absorver novas capacidades sem expandir a primeira camada.

Esses são sinais melhores do que simplesmente contar quantos itens existem no menu.

Arquitetura que aguenta crescer não é arquitetura que nunca muda

Produto muda. O domínio muda. Clientes mudam. Novos casos aparecem. Uma arquitetura boa não congela isso. Ela cria uma lógica suficientemente clara para absorver crescimento sem transformar cada lançamento numa nova categoria de primeiro nível.

Antes de adicionar uma feature ao menu, vale perguntar: a que conceito existente isso pertence? O usuário procura por objeto ou por tarefa neste contexto? O nome vem do domínio dele ou do nosso sistema interno? Existe outro lugar em que ele esperaria encontrar isso? Estamos criando um novo conceito ou apenas outra ação sobre um conceito antigo? Como saberemos se alguém conseguiu encontrar?

Essa discussão custa menos enquanto a funcionalidade ainda é um card no roadmap. Depois de dois anos, ela vira migração, documentação, suporte, treinamento e resistência de usuários experientes.

Nenhum produto começa confuso. Ele fica. E a maneira de evitar isso não é desenhar um menu perfeito uma vez. É tratar onde uma funcionalidade entra no produto como uma decisão de arquitetura toda vez que o produto cresce.

Vale olhar também para a camada seguinte. Uma estrutura coerente com componentes inconsistentes ainda obriga o usuário a reaprender comportamento de tela em tela: 5 princípios de UI que todo produto digital precisa.

Fontes

Nielsen Norman Group. 10 Usability Heuristics for User Interface Design, Jakob Nielsen. Referência para a heurística “Recognition Rather Than Recall”, segundo a qual interfaces devem minimizar a carga de memória do usuário tornando elementos, ações e opções visíveis ou facilmente recuperáveis.

Nielsen Norman Group. Information Architecture: Study Guide. Referência para métodos de pesquisa aplicados a arquitetura de informação, incluindo card sorting e tree testing.

Nielsen Norman Group. Card Sorting: Uncover Users' Mental Models for Better Information Architecture. Card sorting como método para entender como usuários agrupam e categorizam conteúdos. A orientação atual diferencia estudos qualitativos e quantitativos e recomenda amostras maiores que as usadas em pequenos testes qualitativos de usabilidade.

Nielsen Norman Group. Card Sorting: How Many Users to Test. Referência para tamanho de amostra em card sorting. A recomendação histórica é testar pelo menos 15 participantes, com amostras maiores quando o objetivo exige estabilidade quantitativa.

Nielsen Norman Group. Why You Only Need to Test with 5 Users. Jakob Nielsen, 18 de março de 2000. A heurística dos cinco participantes refere-se a ciclos pequenos de testes qualitativos de usabilidade e não deve ser aplicada como regra universal para qualquer método de pesquisa.