Um briefing costuma chegar misturando objetivos, referências visuais, serviços, dúvidas e urgências. Há informações valiosas ali, mas elas ainda não formam um site. Meu trabalho começa justamente nesse intervalo: entender o que o negócio precisa comunicar e transformar esse material em caminhos que uma pessoa consiga percorrer sem conhecer os bastidores da empresa.
Arquitetura de informação pode parecer um termo distante, porém ela aparece em decisões muito concretas. É o que define quais páginas existem, como recebem nomes, que conteúdo vem primeiro e onde cada ação faz sentido. Na Base de Ártemis, eu não começo desenhando blocos. Primeiro organizo o problema, as prioridades e as perguntas que o site precisa responder.
O briefing não é um formulário que decide tudo
Eu uso o briefing como ponto de partida, não como um documento intocável. Uma resposta curta pode esconder uma decisão importante, enquanto uma lista extensa pode reunir assuntos que não precisam aparecer na mesma página. Por isso, releio o material procurando relações, lacunas e conflitos antes de pensar no menu.
Quero compreender o que motivou o projeto, qual oferta tem prioridade e quem precisa agir depois de visitar o site. Também observo o que a empresa já tentou, de onde virá o tráfego e quais dúvidas chegam ao atendimento. Essas informações ajudam a separar preferência pessoal de necessidade real.
Quando ainda não existe clareza sobre a oferta, eu não tento compensar com uma navegação cheia de páginas. Primeiro identifico o que precisa ser definido pela empresa. Esse cuidado evita transformar incertezas internas em um site que obriga o visitante a descobrir sozinho o que está sendo vendido.
Eu organizo decisões, não apenas assuntos
Uma lista de serviços não revela como as pessoas pensam. Alguém pode chegar querendo comparar soluções, entender um processo, verificar experiência ou descobrir se a empresa atende ao seu contexto. A arquitetura precisa acompanhar essas decisões, e não repetir a estrutura do organograma da empresa.
Eu costumo agrupar o conteúdo por intenção. O que ajuda a reconhecer um problema? O que explica a solução? O que reduz risco? O que permite comparar alternativas? O que prepara a pessoa para entrar em contato? A partir dessas perguntas, fica mais fácil perceber quais informações pertencem à mesma página e quais precisam de espaço próprio.
Essa etapa também mostra quando uma landing page é suficiente e quando o negócio precisa de um conjunto maior de páginas. A diferença não depende apenas do tamanho da empresa. Ela depende da variedade de intenções e do caminho necessário até a decisão, como explico na comparação entre landing page e site institucional.
O inventário mostra o que existe de verdade
Antes de prometer uma estrutura, eu verifico os materiais disponíveis. Textos antigos, apresentações, propostas comerciais, perguntas frequentes, fotos, documentos e mensagens do atendimento podem conter informações importantes. Também revelam repetições, contradições e promessas que precisam ser confirmadas.
O inventário não serve para aproveitar tudo. Ele ajuda a distinguir conteúdo útil de acúmulo. Uma página antiga pode ter um bom argumento escondido em um parágrafo longo, enquanto uma apresentação bonita pode depender de contexto que não funciona no site. Eu separo o que será mantido, reescrito, produzido ou removido.
Esse diagnóstico deixa responsabilidades mais claras. Se faltam fotos, dados ou regras comerciais, o cronograma precisa considerar quem fornecerá cada item. Arquitetura não é apenas o desenho das páginas. Ela depende da qualidade e da disponibilidade do conteúdo que dará sentido a essas páginas.
Os nomes do menu precisam funcionar fora da empresa
Uma navegação pode parecer óbvia para quem convive com o negócio e ainda assim confundir quem chega pela primeira vez. Siglas, nomes internos e conceitos criativos demais exigem interpretação. Eu prefiro rótulos que antecipem o que será encontrado, principalmente nas áreas responsáveis por serviços, contato e informações institucionais.
Isso não significa deixar todo site igual. A personalidade pode aparecer na escrita, no ritmo visual e na maneira de apresentar as ideias. O menu, porém, precisa cumprir sua função antes de tentar surpreender. Quando cada item disputa atenção ou esconde o destino do clique, a identidade vira obstáculo.
Também penso na navegação como um conjunto de rotas. O menu principal é uma delas, mas existem links dentro do conteúdo, chamadas relacionadas, busca e caminhos vindos do Google ou de anúncios. Uma pessoa não precisa entrar pela home para compreender onde está e qual pode ser o próximo passo.
A hierarquia começa pelo que a pessoa precisa entender
Depois de definir páginas e relações, organizo a prioridade dentro de cada uma. A primeira tela precisa situar a pessoa, mas não precisa carregar todas as respostas. O restante da página desenvolve contexto, explica a oferta, apresenta critérios e conduz para uma ação coerente.
Eu evito montar essa sequência como uma fórmula fixa de copy. Cada projeto pede provas e explicações diferentes. Um serviço novo pode precisar detalhar o método. Uma empresa conhecida pode precisar facilitar o acesso a áreas específicas. Uma campanha pode exigir correspondência muito direta entre anúncio, promessa e conteúdo.
A hierarquia também aparece nos títulos. Eles precisam descrever os assuntos e mostrar a relação entre as seções. A orientação oficial da W3C sobre estrutura de páginas reforça que títulos organizados logicamente ajudam pessoas a navegar, especialmente quem usa leitores de tela, teclado ou modos de leitura. Uma boa estrutura visual precisa continuar fazendo sentido quando o estilo é removido.
O wireframe vem depois das prioridades
O wireframe é a primeira representação espacial dessa lógica. Ele mostra blocos, ordem, relações e ações sem depender do acabamento visual. Eu uso essa etapa para testar se a página sustenta a leitura antes que cores, fotografias e animações tornem tudo mais convincente.
Nesse momento, verifico se uma seção responde à anterior, se o botão aparece quando a pessoa tem informação suficiente para agir e se há trechos que repetem a mesma ideia. Também avalio onde um exemplo, uma prova ou uma pergunta frequente reduz uma dúvida real, em vez de preencher espaço.
Quando a arquitetura está fraca, o wireframe denuncia o problema. Surgem áreas sem função, chamadas desconectadas e páginas que tentam explicar serviços demais. É melhor corrigir isso nessa fase do que aperfeiçoar um layout cuja lógica ainda não foi resolvida.
O mobile não é uma versão encolhida
Eu testo a arquitetura pensando em uma tela estreita desde cedo. No celular, a pessoa enxerga menos contexto de uma vez, os elementos ficam empilhados e cada toque precisa ter espaço suficiente. Uma ordem que parecia clara no desktop pode perder sentido quando os blocos são reorganizados.
Menus extensos, tabelas largas e formulários longos precisam de decisões específicas. Em vez de esconder conteúdo importante, procuro reduzir complexidade, priorizar campos e preservar a sequência. A leitura deve continuar compreensível sem depender de colunas lado a lado.
Esse cuidado se conecta à conversão. Se o formulário trava, o botão é difícil de tocar ou a página demora a carregar, a arquitetura não chegou inteira até a experiência. O artigo sobre 15 erros que fazem um site perder clientes aprofunda a relação entre clareza, confiança e ação.
Eu valido a estrutura com a linguagem do cliente
Uma arquitetura não deveria ser aprovada apenas porque o mapa parece organizado. Eu volto às conversas, aos materiais e às perguntas do público para verificar se a estrutura usa palavras reconhecíveis. Quando possível, comparo os títulos com termos que aparecem no atendimento e nas buscas, sem forçar palavras-chave em todos os espaços.
Também apresento a lógica, não apenas o resultado. Explico por que uma página foi separada, por que outra foi incorporada e qual ação cada caminho pretende facilitar. Isso permite que o cliente questione decisões com contexto e evita aprovações baseadas somente em gosto.
As orientações de conteúdo do GOV.UK sobre necessidades dos usuários tratam conteúdo a partir de ações e tarefas. Eu considero esse princípio especialmente útil porque impede que a estrutura seja construída apenas para acomodar tudo o que a organização deseja dizer.
O que muda quando essa etapa é bem feita
Uma arquitetura clara não garante sozinha o resultado comercial, mas reduz atritos que o layout não consegue resolver. A equipe entende onde cada informação entra, a produção de conteúdo ganha direção e o desenvolvimento deixa de depender de decisões improvisadas em cada tela.
Ela também melhora a manutenção. Quando páginas têm papéis definidos, fica mais fácil saber onde atualizar uma oferta, publicar um conteúdo relacionado ou criar uma campanha sem duplicar explicações. O site passa a funcionar como uma estrutura viva, e não como uma coleção de blocos montados para o lançamento.
É por isso que eu não trato o briefing como uma etapa burocrática. Ele inicia uma investigação que passa por conteúdo, intenção, navegação, hierarquia e validação. O layout começa depois que essas peças conseguem contar a mesma história.
Fontes consultadas
- W3C Web Accessibility Initiative: Page Structure Tutorial, consultado em 3 de agosto de 2026.
- W3C Web Accessibility Initiative: Content Structure, consultado em 3 de agosto de 2026.
- GOV.UK: Identify user needs, consultado em 3 de agosto de 2026.
