EMPRESA DE GRANDE PORTE · SETOR FLORESTAL E CELULOSE · 2026
Quando os dados existem mas decisões ainda não acontecem
Redesenho da experiência de people analytics de uma das maiores empresas florestais do mundo — do diagnóstico à arquitetura de um produto de decisão.
UX STRATEGY
PRODUCT DISCOVERY
PEOPLE ANALYTICS
ARQUITETURA DA INFORMAÇÃO
SISTEMAS COMPLEXOS
GESTÃO DE STAKEHOLDERS
CONTEXTO
Projeto interno de RH estratégico
USUÁRIOS PRIMÁRIOS
HRBPs e lideranças de negócio
ESCOPO
Discovery + arquitetura + direção de produto
MÉTODO
13 entrevistas em profundidade, 5 perfis
PONTO DE PARTIDA
Uma infraestrutura rica em dados com pouca influência sobre decisões reais
A organização já operava um ecossistema consolidado de dashboards de pessoas — indicadores de headcount, movimentação, orçamento, performance, sucessão. Tecnicamente, a infraestrutura analítica estava disponível. Na prática, o que eu encontrei ao chegar no projeto foi diferente.
Antes de reuniões estratégicas, lideranças e HR Business Partners exportavam tabelas, tiravam prints de dashboards e consolidavam tudo em planilhas paralelas. Os dados estavam acessíveis. A interpretação deles, não.
"Nenhum usuário entrevistado acessava os dashboards pelo portal oficial. Todos operavam por favoritos e links diretos — um sintoma de fragmentação que a interface não havia conseguido resolver."
Entrei no projeto com uma pergunta: por que uma estrutura rica em informação ainda não conseguia apoiar decisões com fluidez?
Ecossistema no início do projeto — múltiplos pontos de entrada, padrões de leitura inconsistentes e consolidações paralelas em planilhas e apresentações.
MÉTODO
Discovery antes de qualquer tela
A primeira decisão do projeto foi não abrir o Figma. Antes de qualquer proposta de interface, era necessário entender onde e como as decisões de negócio realmente aconteciam.
Conduzi 13 entrevistas em profundidade cobrindo cinco perfis distintos: analistas de escala, HRBPs ativos em modelo intermediário, gestores orientados a metas, gestores situacionais com equipes pequenas e gestores com alta complexidade orçamentária. Operações internacionais foram identificadas como contexto de exceção — sistemas diferentes, lacunas de infraestrutura e especificidades legais que demandariam escopo próprio.
Além das entrevistas, revisei dashboards existentes, analisei planilhas e apresentações que circulavam em reuniões executivas e mapeei os materiais que os próprios usuários produziam fora do sistema. O objetivo não era inventariar o que estava disponível, mas entender o que de fato era usado quando havia necessidade real de sustentar uma posição.
Síntese das entrevistas — clusters temáticos e mapeamento da jornada atual do HRBP antes de uma reunião estratégica.
DIAGNÓSTICO
Três inversões em relação às premissas internas
A pesquisa confrontou diretamente algumas hipóteses que orientavam a percepção interna sobre o problema. Documentar essas inversões foi parte essencial do trabalho de alinhamento com os stakeholders.
Síntese usada para alinhamento com stakeholders — inversões entre premissa interna e achado de pesquisa, com implicações estratégicas para o escopo da solução.
ACHADOS CENTRAIS
O problema não era acesso. Era o intervalo entre ver um número e saber o que fazer com ele.
A demanda inicial parecia ser uma evolução visual dos dashboards existentes. A pesquisa mostrou outra realidade. Perguntas como "isso piorou ou sempre foi assim?", "esse desvio está alto comparado com quem?" e "consigo sustentar essa leitura com a liderança?" apareciam com frequência nas entrevistas — e nenhuma delas era respondida pelo sistema.
Esse foi o ponto de inflexão do projeto. Em vez de melhorar relatórios isolados, a oportunidade passou a ser construir uma camada de decisão sobre a infraestrutura existente — capaz de organizar sinais, contextualizar indicadores e orientar aprofundamento sem depender de ferramentas externas.
A solução não precisava substituir o que existia. Precisava mudar a forma como uma análise começa — e termina — dentro do sistema.
ARQUITETURA
Navegação organizada por contexto de decisão, não por origem dos dados
Com o problema redefinido, a estrutura de navegação precisava refletir como os usuários pensavam sobre suas responsabilidades — não como os dados estavam organizados nos sistemas de origem.
A arquitetura passou a se organizar em cinco domínios principais: composição e estrutura do time, movimentações e admissões, jornada e custos operacionais, diversidade e inclusão, e talentos e performance. Cada domínio representa um tipo específico de decisão e serve como ponto de entrada para aprofundamento progressivo
Arquitetura da informação estruturada por contexto de decisão — cinco domínios com navegação progressiva entre visão executiva e análise detalhada.
Hipótese inicial — foco em performance e histórico.
Versão refinada — risco, sucessão e criticidade no centro.
Essa organização também criou uma base comum de vocabulário entre negócio, dados e produto — facilitando conversas sobre priorização sem depender de linguagem técnica de sistemas.
Um aprendizado relevante veio dos testes: na frente de talentos e performance, a hipótese inicial priorizava distribuição de performance e evolução histórica. Os usuários ignoraram esse caminho. As primeiras perguntas foram sobre risco de perda, sucessão e continuidade operacional. Risco e criticidade passaram a ocupar posições mais estratégicas na arquitetura — uma mudança que só foi possível porque o modelo foi validado antes de ser construído
ESCOPO E ESTRATÉGIA DE PRODUTO
MVP como camada incremental — sem substituir o que já existe
Havia uma restrição de partida importante: a organização não estava em busca de uma nova plataforma. Qualquer solução precisaria funcionar sobre a infraestrutura existente e ser percebida como adição, não como crítica ao que já havia sido construído.
Esse contexto político moldou diretamente a estratégia. O MVP foi definido como uma camada de experiência sobre os dashboards atuais, priorizando quatro capacidades: uma home executiva orientada por sinais, indicadores críticos de atenção imediata, navegação estruturada por contexto de decisão e aprofundamento progressivo para análises detalhadas.
A validação com stakeholders confirmou um recorte adicional: o perfil de Business Partners (HRBPs) teria tratamento prioritário, com lista de dados relevantes, sitemap e direção de interface específicos para esse público — que apresentou o maior gap entre dado disponível e dado necessário
Estratégia incremental do MVP — camada de experiência sobre a infraestrutura existente, com quatro capacidades priorizadas e perfil HRBP como recorte inicial.
MOVIMENTOS OBSERVADOS
O que mudou durante o projeto
O projeto ainda está em evolução. Os movimentos já perceptíveis são qualitativos: a conversa com stakeholders deixou de girar em torno de dashboards isolados e passou a incluir risco, priorização e contexto. A dependência de consolidações paralelas em planilhas começou a ser questionada internamente. Uma linguagem comum entre negócio, dados e produto começou a se formar.
Mais do que reorganizar interfaces, esse trabalho começou a reposicionar como dados de pessoas são tratados dentro da organização — de relatório operacional para insumo de decisão estratégica.
MINHA ATUAÇÃO
Atuei do diagnóstico à direção de produto — conduzindo pesquisa, sintetizando achados, construindo a arquitetura e comunicando decisões para stakeholders com diferentes interesses e graus de proximidade com o tema. O projeto envolveu navegação política relevante: equilibrar achados que confrontavam premissas internas com uma comunicação que posicionasse a pesquisa como direção, não como crítica.
UX Strategy
Product Discovery
Pesquisa qualitativa
Arquitetura da informação
Testes de usabilidade
Alinhamento com stakeholders
Estratégia de MVP
Data experience design