Como você aborda arquitetura de informação num produto com muitas funcionalidades?

Baseie a estrutura em como os usuários agrupam as coisas, não em como a empresa está organizada. Inventarie o que existe, depois rode card sorting ou tree testing para achar o modelo mental dos usuários, e valide com teste de primeiro clique em rótulos reais. Prefira rótulos claros a rótulos espertos, mantenha a navegação rasa onde der, e dê um caminho de migração quando você muda uma estrutura que as pessoas já conhecem.

Eu começo com um inventário, que é tedioso e sempre revela algo. Num produto B2B a gente achou quarenta e um destinos numa navegação que se apresentava como tendo nove, porque funcionalidades tinham sido enfiadas em configurações por anos. Depois eu vou achar o modelo dos usuários em vez de afirmar o meu. Um card sort aberto com quinze pessoas me diz o que anda junto e, mais útil ainda, quais palavras elas usam. Times adoram vocabulário interno e os usuários não têm ele. Aí eu monto uma árvore e testo antes de desenhar uma única tela. Tree testing é a pesquisa mais barata de alto valor que existe: sem visual, só onde você iria para fazer isso. Se uma tarefa fica abaixo de 60% de encontrabilidade, a estrutura está errada e nenhum design visual vai salvar. A parte que subestimam é a transição. Se você reorganiza um produto que as pessoas usam todo dia, você quebrou a memória muscular delas, então eu planejo redirecionamentos, uma explicação curta dentro do produto, e busca que ainda entenda os nomes antigos.