ERP Desktop (Arquitetura da informação)

Nesta página: Case aborda como reestruturei a arquitetura da informação de um ERP legado atuando na semântica e na estrutura — não na UI — para reduzir entropia, preservar estabilidade e criar uma base sustentável de evolução.

* Arquitetura da Informação

Introdução

Este case aborda um problema recorrente — e frequentemente subestimado — em produtos complexos e maduros: o momento em que a evolução contínua começa a comprometer a própria capacidade de evolução do sistema.

O projeto trata da reestruturação da arquitetura da informação de um ERP Desktop, desenvolvido e expandido ao longo de muitos anos. Nesse período, decisões legítimas em seus contextos originais acumularam-se sem uma revisão estrutural consistente, criando um produto funcional, porém cada vez mais difícil de compreender, sustentar e escalar.

O risco não estava apenas na experiência do usuário, mas na sustentabilidade do produto como sistema. A cada nova funcionalidade, a complexidade crescia de forma não controlada, aumentando o custo de mudança, a dependência de conhecimento tácito e a chance de reincidência de problemas já existentes.

Tipo de produto: ERP Desktop.

Contexto: produto maduro, com múltiplos módulos, regras de negócio extensas e base ativa de usuários.

Meu papel: Designer responsável pelo discovery e pela definição da arquitetura da informação.

O objetivo deste trabalho não foi reorganizar telas, mas interromper um ciclo de entropia estrutural antes que ele se tornasse irreversível.

O problema

O problema central não estava apenas na quantidade de funcionalidades, mas na estrutura semântica fragmentada que sustentava o sistema.

A análise das planilhas que mapeavam menus, funcionalidades e ações revelou um padrão consistente de entropia informacional¹:

• Funcionalidades com o mesmo propósito apareciam registradas com nomes diferentes;
• Um mesmo termo era utilizado para ações distintas, dependendo do módulo;
• Categorias misturavam dados, processos e configurações sem um critério claro;
• Decisões históricas permaneciam registradas por herança, não por relevância atual.

Na prática, isso gerava um sistema que só era plenamente utilizável por quem já possuía conhecimento prévio acumulado, aumentando a curva de aprendizado, a dependência de treinamento e a carga cognitiva para tarefas simples.

O impacto não era apenas para usuários finais:

• Times internos tinham dificuldade de discutir o produto usando uma linguagem comum;
• Novas funcionalidades eram adicionadas replicando problemas existentes;
• A arquitetura deixava de escalar de forma sustentável.

Restrições do contexto:

• Produto em produção, com base ativa de usuários;
• Arquitetura técnica legada;
• Impossibilidade de grandes rupturas estruturais;
• Necessidade de preservar fluxos críticos já consolidados.

Abordagem

A abordagem partiu do entendimento de que o problema não seria resolvido com ajustes visuais ou reorganizações superficiais de menu. O risco real estava na base semântica que sustentava o produto, e qualquer intervenção que ignorasse isso apenas redistribuiria a complexidade existente.

Diante desse cenário, a estratégia foi atuar deliberadamente na camada estrutural e conceitual, tratando a arquitetura da informação como um mecanismo de alinhamento entre usuários, negócio e tecnologia.

Estratégia adotada

• Foco na causa raiz, não nos sintomas: em vez de reorganizar telas ou fluxos, a abordagem concentrou-se em compreender o significado real das funcionalidades, suas sobreposições e responsabilidades.
• Leitura do sistema a partir do domínio, não da interface: as planilhas foram utilizadas como fonte primária para mapear o produto como um sistema de conceitos, permitindo identificar redundâncias invisíveis na UI.
• Intervenção de baixo risco em produto em produção: ao evitar mudanças visuais, foi possível reduzir impacto operacional e garantir continuidade para usuários experientes, enquanto a base estrutural era reorganizada.
• Arquitetura como fundação para decisões futuras: a reorganização não foi pensada como entrega pontual, mas como criação de um modelo capaz de orientar evolução, governança e inclusão de novas funcionalidades.

Métodos e princípios utilizados

• Arquitetura da Informação orientada por significado
• Consolidação semântica baseada em responsabilidade
• Hierarquização por contexto de uso e complexidade
• Princípios de acessibilidade cognitiva, priorizando previsibilidade e consistência

Essa abordagem permitiu atuar em um sistema complexo de forma estratégica, progressiva e sustentável, preparando o terreno para decisões de produto de médio e longo prazo.

Decisões-chave de arquitetura

As decisões partiram da leitura crítica do material mapeado nas planilhas, tratando a arquitetura como um problema de significado, não de interface.

A decisão mais importante foi não reorganizar a navegação visualmente, mas atacar a causa raiz: a inconsistência semântica que sustentava o crescimento desordenado do sistema.

Decisões tomadas

1. Normalização semântica antes da estrutura: antes de qualquer reorganização, os termos foram analisados e consolidados a partir do significado real das funcionalidades, reduzindo variações criadas por contexto histórico.
2. Consolidação de funcionalidades equivalentes: funcionalidades registradas separadamente nas planilhas, mas que representavam a mesma ação ou responsabilidade, foram agrupadas conceitualmente, mesmo quando tecnicamente distintas.
3. Separação explícita por responsabilidade: a arquitetura passou a distinguir claramente:
   • Dados (cadastros e entidades);
   • Processos (ações e fluxos);
   • Configurações (regras, parâmetros e comportamento do sistema).
4. Hierarquização por complexidade e contexto de uso: funcionalidades mais operacionais foram separadas de configurações avançadas, reduzindo exposição desnecessária e carga cognitiva.
5. Redução consciente, não eliminação agressiva: mesmo diante de redundâncias claras, optou-se por não remover funcionalidades críticas sem um plano de transição, priorizando estabilidade e confiança do usuário.

Decisões não tomadas

• Não redesenhar a UI para evitar ruído visual e retrabalho desnecessário
• Não reorganizar menus com base apenas em frequência de uso
• Não introduzir novos conceitos sem antes consolidar os existentes

Essas decisões criaram uma base arquitetural mais coerente, capaz de sustentar evolução futura sem reproduzir a entropia original.

Solução

A solução foi a construção de uma arquitetura da informação orientada por significado, diretamente derivada das decisões semânticas e estruturais tomadas a partir do mapeamento das planilhas. Em vez de partir da interface, a arquitetura passou a refletir responsabilidades claras, reduzindo ambiguidade e criando uma base sustentável para evolução do produto.

Como as decisões se materializaram na solução

• Normalização semântica aplicada: os termos consolidados passaram a orientar toda a estrutura do sistema, eliminando variações históricas e criando uma linguagem comum entre usuários, produto e tecnologia.
• Funcionalidades equivalentes reorganizadas conceitualmente: a consolidação identificada nas planilhas resultou em uma estrutura mais enxuta, onde ações com o mesmo propósito passaram a ocupar um único contexto lógico, mesmo quando mantidas tecnicamente separadas.
• Separação clara entre dados, processos e configurações: essa distinção passou a guiar a navegação e a organização dos módulos, reduzindo confusão e facilitando a compreensão do papel de cada funcionalidade.
• Hierarquia baseada em complexidade e contexto de uso: funcionalidades operacionais ficaram mais acessíveis, enquanto configurações avançadas foram posicionadas em níveis apropriados, diminuindo exposição desnecessária e carga cognitiva.
• Estabilidade preservada durante a transição: a solução respeitou fluxos críticos existentes, evitando rupturas bruscas e garantindo continuidade para usuários experientes.

O que foi entregue

• Estrutura de navegação conceitualmente reorganizada;
• Redução significativa de redundâncias semânticas;
• Base arquitetural consistente para novos módulos;
• Referência clara para documentação, onboarding e tomada de decisão futura.

Limitações conhecidas

• Algumas redundâncias técnicas foram mantidas por restrições de legado;
• A solução não elimina completamente a complexidade inerente a um ERP, mas a torna mais compreensível e previsível.

Todo o trabalho foi realizado atuando exclusivamente na camada estrutural e semântica, sem alterações visuais na interface.

Todo o trabalho foi realizado sem alterações visuais, atuando exclusivamente na camada estrutural e semântica.

Impactos e aprendizados

Os impactos observados estão diretamente ligados às decisões semânticas e estruturais adotadas, mesmo sem mudanças visuais na interface.

Impacto para usuários

• Redução da carga cognitiva ao encontrar funcionalidades organizadas por significado e responsabilidade;
• Maior previsibilidade na navegação, resultado da normalização de nomenclaturas;
• Menor dependência de conhecimento prévio do sistema para executar tarefas comuns.

Esses efeitos são consequência direta da consolidação semântica e da separação clara entre dados, processos e configurações.

Impacto para o negócio

• Base arquitetural mais sustentável, reduzindo risco de crescimento desordenado;
• Inclusão de novas funcionalidades sem necessidade de criar novas categorias ad hoc;
• Menor custo cognitivo e operacional para evolução do produto.

A decisão de preservar fluxos críticos garantiu estabilidade durante a transição, evitando impacto negativo na operação.

Impacto para times internos

• Linguagem comum para discutir produto, funcionalidades e evolução;
• Facilitação do onboarding de novos membros de produto e tecnologia;
• Arquitetura utilizada como referência para documentação e tomada de decisão.

Aprendizados

• Decisões semânticas têm impacto direto na experiência, mesmo sem alterações visuais;
• Atacar a causa estrutural da complexidade gera efeitos mais duradouros do que reorganizações superficiais;
• Em sistemas complexos, reduzir ambiguidade é tão importante quanto adicionar funcionalidade.

O principal aprendizado foi que arquitetura da informação, quando tratada como estratégia, se torna um ativo de longo prazo para o produto.

Passos futuros

Os próximos passos foram definidos como hipóteses estratégicas, diretamente derivadas da nova base arquitetural criada.

Esses próximos passos reforçam a arquitetura da informação como um ativo estratégico contínuo, e não como uma entrega pontual.

1. Para a área de Teoria da Informação, a entropia é definida como sendo uma forma de medir o grau médio de incerteza a respeito de fontes de informação, o que consequentemente permite a quantificação da informação presente que flui no sistema. ↩︎