UI / UX Design
Dashboard Redesign
O que acontece quando o painel de controle mais importante da plataforma não é mais confiável para seus usuários? Este caso explora o redesign de um painel de administração que enfrentava baixa adoção, informações fragmentadas e dependência operacional. Como parte de uma iniciativa mais ampla de rebranding do produto, o desafio não era apenas modernizar a experiência, mas também reconstruir a confiança nos dados, melhorar a tomada de decisões e criar uma base escalável para o crescimento futuro. Do descobrimento à implementação, este projeto demonstra como o design estratégico pode transformar um painel de controle de um recurso negligenciado em uma ferramenta de negócios valiosa.
Ano:
2024
Indústria:
Tecnologia
Cliente:
Alloyal
Duração do Projeto:
2 Anos
Contexto e Meu Papel
Onde me encaixo
A Alloyal é uma plataforma de fidelidade B2B que gerencia assinaturas, programas de pontos ou cashback para clientes corporativos em todo o Brasil. O painel do administrador é a interface principal para as empresas clientes acompanharem o desempenho de seu programa, sendo efetivamente o principal ponto de contato do produto para os tomadores de decisão do lado do cliente.
MEU PAPEL
Lead Product Designer, único designer na frente do dashboard, trabalhando diretamente com o PM e dois engenheiros.
Colaboradores
Product Manager · 2 Engenheiros · Equipe de Customer Success (5 CSMs) · Equipe de dados (para validação de métricas)
Meu Escopo
Discovery · Arquitetura de Informação · Design de Interface (UI) · Design System · Handoff & QA
O redesign foi parte de uma iniciativa mais ampla de rebranding do painel administrativo. Fui responsável pelo processo de design de ponta a ponta, desde a condução de sessões de pesquisa até a entrega de componentes prontos para produção por meio de um Design System que criei do zero.
Problema
Um painel em que ninguém confiava
A análise inicial revelou cinco pontos de falha críticos e interconectados. Os problemas não eram isolados, eles formaram uma cascata: erros de métricas desgastaram a confiança, o que afastou os usuários, o que empurrou o volume para o Sucesso do Cliente, que se apoiou em ferramentas externas para compensar.
A INTUIÇÃO CENTRAL:
Os clientes não eram preguiçosos, eles eram racionais. Quando não se pode confiar em uma ferramenta, as pessoas encontram um caminho alternativo. Cada ticket para o CS era evidência de uma falha de design, não de uma falha do usuário.
Objetivo
Reposicione o painel como um ativo do produto
O redesign teve uma clara intenção estratégica: tornar o painel algo que os clientes escolhessem usar porque os tornava melhores em seus trabalhos, e não um recurso que eles apenas toleravam.
Única fonte da verdade
Elimine as discrepâncias de dados entre o painel e os relatórios de CS
Ferramenta de autoatendimento
Os clientes devem ser capazes de responder às suas próprias dúvidas sobre dados sem precisar ligar para o CS
Reduza a carga de CS
Liberte o Customer Success do suporte reativo de dados para conversas estratégicas
Fundação escalável
Design System como infraestrutura para apoiar a futura expansão de analytics
Única fonte da verdade
Elimine as discrepâncias de dados entre o painel e os relatórios de CS
Reduza a carga de CS
Liberte o Customer Success do suporte reativo de dados para conversas estratégicas
Ferramenta de autoatendimento
Os clientes devem ser capazes de responder às suas próprias dúvidas sobre dados sem precisar ligar para o CS
Fundação escalável
Design System como infraestrutura para apoiar a futura expansão de analytics
Painel Versão antiga
Descoberta
Entendendo onde a confiança foi quebrada
Antes de tocar em qualquer layout ou componente, eu precisava entender exatamente onde o pipeline de dados estava falhando e como isso moldava o comportamento do usuário. Conduzi uma descoberta em três frentes ao longo de três semanas.
Método 01 · Entrevistas com stakeholders
Mergulho profundo da equipe de CS
Entrevistei 4 Gerentes de Sucesso do Cliente (CSMs) individualmente. Pedi que me guiassem por uma solicitação típica de dados de clientes: o que foi solicitado, o que eles tiveram que pesquisar, por que não puderam direcionar o cliente para o painel.
"Primeiro abro o Looker porque sei que os números lá estão certos. Depois abro o dashboard para mostrar ao cliente onde encontrar as coisas mais tarde, mas sei que os números não vão bater."
— CSM, entrevistado na descoberta
Método 02 · Sessões de clientes
5 entrevistas com clientes
Recrutei 5 clientes B2B ativos (gerentes de RH em médias e grandes empresas) para sessões de 45 minutos. Observei-os tentando responder a perguntas reais de negócios usando o painel existente. Acompanhei onde eles ficaram travados, o que esperavam encontrar e quando desistiram.
"Eu queria saber quantos pontos estavam para expirar este mês. Não consegui encontrar, então enviei um WhatsApp para o nosso gerente de conta."
— Cliente, Gerente de RH em uma empresa de varejo
Método 03 · Cruzamento de dados
Auditoria de métricas com a equipe de dados
Junto com um analista de dados, mapeei cada métrica exibida no painel em relação à sua lógica de cálculo e comparei com o equivalente no Looker. Encontrei 7 discrepâncias — 3 eram críticas (taxa de churn, contagem de assinantes ativos, taxa de utilização de cashback).
Descoberta Principal
A maior discrepância estava em como o "assinante ativo" era definido. O painel contava qualquer assinatura criada no período; o Looker contava apenas aquelas com pelo menos uma transação. Uma diferença de ~30% no mesmo número.
Método 04 · Análise de chamados
Categorização de tíquetes de suporte
Analisei 3 meses de chamados de suporte (CS) marcados como "dashboard" ou "dúvida de dados". Categorizei-os por tópico e os mapeei para telas específicas. Isso me deu um mapa de priorização: quais lacunas ou erros de dados causaram o maior atrito.
Os 3 principais motivos de chamados foram
Interpretação de churn (34%), visibilidade da expiração de pontos (28%), reconciliação de cashback (21%).
Resultado do discovery:
Uma lista priorizada de inconsistências de métricas, um mapa dos dados mais solicitados não disponíveis no painel e uma imagem clara das duas principais jornadas do usuário (o cliente revisando a saúde do programa versus o CS preparando um relatório do cliente). Esses se tornaram a espinha dorsal do redesign da arquitetura de informação.
Abordagem
Cinco apostas que fizemos
1
Validação de dados com stakeholders reais
Cruzei todas as métricas com a equipe de CS e a equipe de dados antes de redesenhar qualquer coisa. Redefini a lógica de cálculo para as 3 métricas críticas em colaboração com a engenharia.
→ Resultado: definições claras de métricas acordadas entre as equipes de CS, Produto e Engenharia
2
Redesenho da arquitetura de informação por domínio de produto
Reorganizei o painel em torno de três domínios de produtos (Assinaturas, Pontos, Cashback) com uma separação clara entre KPIs estratégicos e dados operacionais. Apliquei divulgação progressiva: visão geral → detalhes.
→ Resultado: os clientes podiam navegar para sua área específica sem escanear a tela toda
3
Cobertura de dados expandida por domínio
Adicionados painéis dedicados para cada domínio abordando os principais motivadores de chamados: cancelamento (churn) relativo à base ativa (não absoluto), cronograma de expiração de pontos, visualização de reconciliação de cashback.
→ Resultado: as três principais categorias de chamados agora contam com respostas de autoatendimento no produto
4
Recursos de autonomia do cliente
Adicionamos exportação para CSV, controles de comparação de períodos e dicas de ferramentas contextuais explicando as definições das métricas. O objetivo era reduzir a necessidade de entrar em contato com o CS (Sucesso do Cliente), mesmo para casos específicos.
→ Resultado: os clientes agora podem executar suas próprias análises ad-hoc sem o envolvimento de CS
5
Design System como a espinha dorsal do rebranding
Criei um Design System dedicado para garantir a consistência em todos os três domínios do dashboard e no ambiente white-label. Padronizei componentes, estilos de gráficos, tipografia e todos os estados (erro, vazio, carregamento).
→ Resultado: os novos módulos do painel agora levam cerca de 40% menos tempo de design devido às bases reutilizáveis
Principais Decisões de Design
Três decisões que moldaram o resultado
Essas não foram decisões óbvias, cada uma envolveu um trade-off e uma escolha que poderia ter tomado um rumo diferente. Aqui está o raciocínio por trás daquelas que mais importaram.
DECISÃO 01
Mostrar o churn como % da base ativa, não como um número absoluto
ALTERNATIVAS CONSIDERADAS
DESCARTADO
Número absoluto de cancelamentos
DESCARTADO
Apenas delta período sobre período
POR QUE ESCOLHEMOS ISSO
Clientes com 500 assinantes e 50 cancelamentos interpretam isso de forma diferente daqueles com 5.000 e 50 cancelamentos. A abordagem em % tornou o mesmo número acionável, independentemente do tamanho do programa, e correspondeu à forma como os clientes realmente falavam sobre seus negócios nas entrevistas.
DECISÃO 02
Navegação focada em domínios (Assinaturas · Pontos · Cashback) sobre uma visão unificada
ALTERNATIVAS CONSIDERADAS
DESCARTADO
Visão geral única com rolagem
DESCARTADO
Visualização de todas as métricas baseada em guias
POR QUE ESCOLHEMOS ISSO
A fase de descoberta mostrou que os clientes eram focados em produtos específicos: um gerente de RH que gerenciava um programa de pontos não se importava com métricas de cashback. Uma visualização unificada os forçava a filtrar visualmente tudo o que viam, todas as vezes. Uma abordagem focada no domínio (domain-first) reduziu a carga cognitiva e fez com que a página parecesse relevante para cada persona desde o primeiro clique.
DECISÃO 03
Construa o Design System antes de lançar o dashboard, não depois
ALTERNATIVAS CONSIDERADAS
DESCARTADO
Envie o dashboard primeiro, DS depois
DESCARTADO
Adote um sistema de código aberto existente
POR QUE ESCOLHEMOS ISSO
Três domínios sendo lançados sem uma base compartilhada inevitavelmente se distanciariam, prejudicando a percepção consistente e confiável que precisávamos reconstruir. Fazer o DS primeiro também trouxe resultados imediatos: o domínio Cashback foi lançado cerca de 40% mais rápido. Mapeei esse ganho em relação ao investimento de 3 semanas e o PM concordou.
SOLUÇÃO
Uma experiência redesenhada em três pilares
Uma experiência de painel reformulada com base em três pilares:
DESIGN SYSTEM
Os argumentos para construir o DS antes de lançar o dashboard
O redesign não era apenas uma tela — eram três domínios de painéis interconectados (Assinaturas, Pontos, Cashback), todos parte de um rebranding mais amplo do painel administrativo. Sem uma base compartilhada, cada domínio inevitavelmente se fragmentaria: estilos de gráficos diferentes, layouts de cartões inconsistentes, estados vazios variados. Essa fragmentação prejudicaria diretamente a percepção de "confiável e seguro" que estávamos tentando reconstruir.
O DS também foi a espinha dorsal do próprio reposicionamento de marca. A Alloyal precisava que o painel administrativo transmitisse modernidade e confiança — não apenas o dashboard, mas toda a superfície do produto com a qual os clientes interagem. Um sistema compartilhado tornou essa atualização consistente possível sem a necessidade de redesenhar cada tela do zero.
Os argumentos para construir o DS antes de lançar o dashboard
0
0
Componentes criados e documentados
0
0
Tipos de gráficos padronizados em todos os domínios
0
0
Estados do sistema definidos: erro, vazio, carregando, dados parciais
-0%
-0%
Redução no tempo de design para o domínio de Cashback (segundo a ser lançado)
0
0
Domínios de dashboard compartilhando uma única biblioteca de componentes
1
1
Biblioteca do Figma como a fonte única de verdade compartilhada com a Engenharia
O sistema padronizou a tipografia, o espaçamento, o uso de cores, os padrões de gráficos e todos os estados de interface. A engenharia passou a ter um ponto de referência único, eliminando a categoria de problemas em que o mesmo componente tem aparências diferentes em telas distintas. O DS evoluiu de uma entrega de UI para a base estrutural de um produto mais maduro e coerente.
RESULTADOS
Resultados em três públicos-públicos alvo
PARA CLIENTES
Chamadas de CS
Os clientes relataram responder às perguntas do programa de forma independente
Confiança
Maior confiança nos dados da plataforma, menos escalonamentos
PARA EQUIPES INTERNAS
Ingressos
Redução significativa nas solicitações de correção de dados relacionadas ao painel
Looke r
O CS não precisa mais de ferramentas externas para a maioria das consultas de dados de clientes
PARA O PRODUTO
Estratégico
Dashboard reposicionado de ferramenta de suporte para recurso do produto
Escalável
A base do DS apoia a expansão para novos módulos de análise
Feedback
Nas palavras deles
• “Reduzimos significativamente o número de tickets relacionados a inconsistências de dados.” • “Os clientes estão fazendo menos perguntas sobre métricas básicas — as conversas agora são mais estratégicas.” • “Não precisamos mais depender do Looker para a maioria das solicitações de clientes, o que economiza tempo e reduz a alternância de contexto.”
Equipe de CS
• “Esta é a primeira vez que o dashboard está sendo usado como um recurso do produto, e não apenas como uma ferramenta de suporte.” • “O Design System nos ajudou a avançar mais rápido e a manter a consistência entre os novos módulos do dashboard.” • “Agora temos uma base escalável para expandir o analytics em outros produtos.”
Equipe de Produto
Principais Aprendizados
O que este projeto reforçou
,1
Dados confiáveis importam mais do que recursos visuais
O maior problema de design aqui não era a interface do usuário — era a qualidade dos dados subjacentes. Nenhuma quantidade de refinamento visual teria corrigido um painel que estava mostrando números errados aos usuários. A descoberta precisa incluir a camada de dados, não apenas a interface.
,2
Dashboards são ferramentas de tomada de decisão, não visualizações
A pergunta não é "esse gráfico está bonito?", mas sim "isso ajuda alguém a tomar uma atitude?". Cada decisão de design foi avaliada com base em ajudar o cliente a decidir algo sobre seu programa de fidelidade, e não em ser esteticamente interessante.
,3
Um Design System é infraestrutura de produto, não um kit de UI
O DS liberou velocidade e consistência, mas o seu real valor foi permitir que o ambiente white-label escalasse sem fragmentação. Trate-o como um investimento de engenharia com uma face de design — e defenda esse argumento com os stakeholders usando números concretos.
,4
A centralização de dados reduz o custo operacional
Cada tíquete que o CS recebia representava um custo — em tempo, fragmentação de contexto e desgaste na confiança do cliente. Um design que viabiliza o autoatendimento gera um impacto de negócios mensurável. Estruturar o redesign dessa maneira ajudou a alinhar o PM, a liderança de CS e a engenharia em torno da mesma prioridade.
Retrospectiva
O que eu faria de diferente
Olhando para trás, após o lançamento e os primeiros meses de adoção, algumas coisas se destacam como áreas onde eu tomaria decisões diferentes hoje.
O que funcionou bem
Executar a auditoria de métricas antes de desenhar qualquer coisa. Foi tentador começar com wireframes, mas passar um tempo primeiro na camada de dados nos salvou de lançar uma versão mais bonita do mesmo design que já estava quebrado.
Construir o DS em paralelo com o dashboard. O investimento inicial se pagou imediatamente no segundo domínio (Cashback), que foi lançado na metade do tempo esperado.
Usar o CS como um parceiro de pesquisa, não apenas como um stakeholder. O conhecimento institucional deles sobre as dores dos clientes foi o insumo mais valioso na descoberta.
O que eu mudaria
Envolver a engenharia mais cedo na definição das métricas. As mudanças na lógica de cálculo surgiram tarde no desenvolvimento, adiando o lançamento em dois sprints. Eu realizaria uma sessão de viabilidade técnica na fase de descoberta.
Estabelecer métricas quantitativas de baseline antes do lançamento. Não tínhamos uma contagem clara de chamados pré-lançamento ou baseline de uso do Looker, o que tornou mais difícil quantificar o impacto depois. Eu instrumentaria isso desde o início.
Testar com mais arquétipos de clientes. Tivemos 5 clientes na pesquisa — todos gerentes de RH em médias e grandes empresas. Eu teria recrutado pelo menos uma empresa de pequeno porte e uma de um setor diferente para testar sob estresse as suposições de IA.
Mais Projetos
Mais Projetos
UI / UX Design
Dashboard Redesign
O que acontece quando o painel de controle mais importante da plataforma não é mais confiável para seus usuários? Este caso explora o redesign de um painel de administração que enfrentava baixa adoção, informações fragmentadas e dependência operacional. Como parte de uma iniciativa mais ampla de rebranding do produto, o desafio não era apenas modernizar a experiência, mas também reconstruir a confiança nos dados, melhorar a tomada de decisões e criar uma base escalável para o crescimento futuro. Do descobrimento à implementação, este projeto demonstra como o design estratégico pode transformar um painel de controle de um recurso negligenciado em uma ferramenta de negócios valiosa.
Ano:
2024
Indústria:
Tecnologia
Cliente:
Alloyal
Duração do Projeto:
2 Anos
Contexto e Meu Papel
Onde me encaixo
A Alloyal é uma plataforma de fidelidade B2B que gerencia assinaturas, programas de pontos ou cashback para clientes corporativos em todo o Brasil. O painel do administrador é a interface principal para as empresas clientes acompanharem o desempenho de seu programa, sendo efetivamente o principal ponto de contato do produto para os tomadores de decisão do lado do cliente.
MEU PAPEL
Lead Product Designer, único designer na frente do dashboard, trabalhando diretamente com o PM e dois engenheiros.
Colaboradores
Product Manager · 2 Engenheiros · Equipe de Customer Success (5 CSMs) · Equipe de dados (para validação de métricas)
Meu Escopo
Discovery · Arquitetura de Informação · Design de Interface (UI) · Design System · Handoff & QA
O redesign foi parte de uma iniciativa mais ampla de rebranding do painel administrativo. Fui responsável pelo processo de design de ponta a ponta, desde a condução de sessões de pesquisa até a entrega de componentes prontos para produção por meio de um Design System que criei do zero.
Problema
Um painel em que ninguém confiava
A análise inicial revelou cinco pontos de falha críticos e interconectados. Os problemas não eram isolados, eles formaram uma cascata: erros de métricas desgastaram a confiança, o que afastou os usuários, o que empurrou o volume para o Sucesso do Cliente, que se apoiou em ferramentas externas para compensar.
A INTUIÇÃO CENTRAL:
Os clientes não eram preguiçosos, eles eram racionais. Quando não se pode confiar em uma ferramenta, as pessoas encontram um caminho alternativo. Cada ticket para o CS era evidência de uma falha de design, não de uma falha do usuário.
Objetivo
Reposicione o painel como um ativo do produto
O redesign teve uma clara intenção estratégica: tornar o painel algo que os clientes escolhessem usar porque os tornava melhores em seus trabalhos, e não um recurso que eles apenas toleravam.
Única fonte da verdade
Elimine as discrepâncias de dados entre o painel e os relatórios de CS
Ferramenta de autoatendimento
Os clientes devem ser capazes de responder às suas próprias dúvidas sobre dados sem precisar ligar para o CS
Reduza a carga de CS
Liberte o Customer Success do suporte reativo de dados para conversas estratégicas
Fundação escalável
Design System como infraestrutura para apoiar a futura expansão de analytics
Única fonte da verdade
Elimine as discrepâncias de dados entre o painel e os relatórios de CS
Reduza a carga de CS
Liberte o Customer Success do suporte reativo de dados para conversas estratégicas
Ferramenta de autoatendimento
Os clientes devem ser capazes de responder às suas próprias dúvidas sobre dados sem precisar ligar para o CS
Fundação escalável
Design System como infraestrutura para apoiar a futura expansão de analytics
Painel Versão antiga
Descoberta
Entendendo onde a confiança foi quebrada
Antes de tocar em qualquer layout ou componente, eu precisava entender exatamente onde o pipeline de dados estava falhando e como isso moldava o comportamento do usuário. Conduzi uma descoberta em três frentes ao longo de três semanas.
Método 01 · Entrevistas com stakeholders
Mergulho profundo da equipe de CS
Entrevistei 4 Gerentes de Sucesso do Cliente (CSMs) individualmente. Pedi que me guiassem por uma solicitação típica de dados de clientes: o que foi solicitado, o que eles tiveram que pesquisar, por que não puderam direcionar o cliente para o painel.
"Primeiro abro o Looker porque sei que os números lá estão certos. Depois abro o dashboard para mostrar ao cliente onde encontrar as coisas mais tarde, mas sei que os números não vão bater."
— CSM, entrevistado na descoberta
Método 02 · Sessões de clientes
5 entrevistas com clientes
Recrutei 5 clientes B2B ativos (gerentes de RH em médias e grandes empresas) para sessões de 45 minutos. Observei-os tentando responder a perguntas reais de negócios usando o painel existente. Acompanhei onde eles ficaram travados, o que esperavam encontrar e quando desistiram.
"Eu queria saber quantos pontos estavam para expirar este mês. Não consegui encontrar, então enviei um WhatsApp para o nosso gerente de conta."
— Cliente, Gerente de RH em uma empresa de varejo
Método 03 · Cruzamento de dados
Auditoria de métricas com a equipe de dados
Junto com um analista de dados, mapeei cada métrica exibida no painel em relação à sua lógica de cálculo e comparei com o equivalente no Looker. Encontrei 7 discrepâncias — 3 eram críticas (taxa de churn, contagem de assinantes ativos, taxa de utilização de cashback).
Descoberta Principal
A maior discrepância estava em como o "assinante ativo" era definido. O painel contava qualquer assinatura criada no período; o Looker contava apenas aquelas com pelo menos uma transação. Uma diferença de ~30% no mesmo número.
Método 04 · Análise de chamados
Categorização de tíquetes de suporte
Analisei 3 meses de chamados de suporte (CS) marcados como "dashboard" ou "dúvida de dados". Categorizei-os por tópico e os mapeei para telas específicas. Isso me deu um mapa de priorização: quais lacunas ou erros de dados causaram o maior atrito.
Os 3 principais motivos de chamados foram
Interpretação de churn (34%), visibilidade da expiração de pontos (28%), reconciliação de cashback (21%).
Resultado do discovery:
Uma lista priorizada de inconsistências de métricas, um mapa dos dados mais solicitados não disponíveis no painel e uma imagem clara das duas principais jornadas do usuário (o cliente revisando a saúde do programa versus o CS preparando um relatório do cliente). Esses se tornaram a espinha dorsal do redesign da arquitetura de informação.
Abordagem
Cinco apostas que fizemos
1
Validação de dados com stakeholders reais
Cruzei todas as métricas com a equipe de CS e a equipe de dados antes de redesenhar qualquer coisa. Redefini a lógica de cálculo para as 3 métricas críticas em colaboração com a engenharia.
→ Resultado: definições claras de métricas acordadas entre as equipes de CS, Produto e Engenharia
2
Redesenho da arquitetura de informação por domínio de produto
Reorganizei o painel em torno de três domínios de produtos (Assinaturas, Pontos, Cashback) com uma separação clara entre KPIs estratégicos e dados operacionais. Apliquei divulgação progressiva: visão geral → detalhes.
→ Resultado: os clientes podiam navegar para sua área específica sem escanear a tela toda
3
Cobertura de dados expandida por domínio
Adicionados painéis dedicados para cada domínio abordando os principais motivadores de chamados: cancelamento (churn) relativo à base ativa (não absoluto), cronograma de expiração de pontos, visualização de reconciliação de cashback.
→ Resultado: as três principais categorias de chamados agora contam com respostas de autoatendimento no produto
4
Recursos de autonomia do cliente
Adicionamos exportação para CSV, controles de comparação de períodos e dicas de ferramentas contextuais explicando as definições das métricas. O objetivo era reduzir a necessidade de entrar em contato com o CS (Sucesso do Cliente), mesmo para casos específicos.
→ Resultado: os clientes agora podem executar suas próprias análises ad-hoc sem o envolvimento de CS
5
Design System como a espinha dorsal do rebranding
Criei um Design System dedicado para garantir a consistência em todos os três domínios do dashboard e no ambiente white-label. Padronizei componentes, estilos de gráficos, tipografia e todos os estados (erro, vazio, carregamento).
→ Resultado: os novos módulos do painel agora levam cerca de 40% menos tempo de design devido às bases reutilizáveis
Principais Decisões de Design
Três decisões que moldaram o resultado
Essas não foram decisões óbvias, cada uma envolveu um trade-off e uma escolha que poderia ter tomado um rumo diferente. Aqui está o raciocínio por trás daquelas que mais importaram.
DECISÃO 01
Mostrar o churn como % da base ativa, não como um número absoluto
ALTERNATIVAS CONSIDERADAS
DESCARTADO
Número absoluto de cancelamentos
DESCARTADO
Apenas delta período sobre período
POR QUE ESCOLHEMOS ISSO
Clientes com 500 assinantes e 50 cancelamentos interpretam isso de forma diferente daqueles com 5.000 e 50 cancelamentos. A abordagem em % tornou o mesmo número acionável, independentemente do tamanho do programa, e correspondeu à forma como os clientes realmente falavam sobre seus negócios nas entrevistas.
DECISÃO 02
Navegação focada em domínios (Assinaturas · Pontos · Cashback) sobre uma visão unificada
ALTERNATIVAS CONSIDERADAS
DESCARTADO
Visão geral única com rolagem
DESCARTADO
Visualização de todas as métricas baseada em guias
POR QUE ESCOLHEMOS ISSO
A fase de descoberta mostrou que os clientes eram focados em produtos específicos: um gerente de RH que gerenciava um programa de pontos não se importava com métricas de cashback. Uma visualização unificada os forçava a filtrar visualmente tudo o que viam, todas as vezes. Uma abordagem focada no domínio (domain-first) reduziu a carga cognitiva e fez com que a página parecesse relevante para cada persona desde o primeiro clique.
DECISÃO 03
Construa o Design System antes de lançar o dashboard, não depois
ALTERNATIVAS CONSIDERADAS
DESCARTADO
Envie o dashboard primeiro, DS depois
DESCARTADO
Adote um sistema de código aberto existente
POR QUE ESCOLHEMOS ISSO
Três domínios sendo lançados sem uma base compartilhada inevitavelmente se distanciariam, prejudicando a percepção consistente e confiável que precisávamos reconstruir. Fazer o DS primeiro também trouxe resultados imediatos: o domínio Cashback foi lançado cerca de 40% mais rápido. Mapeei esse ganho em relação ao investimento de 3 semanas e o PM concordou.
SOLUÇÃO
Uma experiência redesenhada em três pilares
Uma experiência de painel reformulada com base em três pilares:
DESIGN SYSTEM
Os argumentos para construir o DS antes de lançar o dashboard
O redesign não era apenas uma tela — eram três domínios de painéis interconectados (Assinaturas, Pontos, Cashback), todos parte de um rebranding mais amplo do painel administrativo. Sem uma base compartilhada, cada domínio inevitavelmente se fragmentaria: estilos de gráficos diferentes, layouts de cartões inconsistentes, estados vazios variados. Essa fragmentação prejudicaria diretamente a percepção de "confiável e seguro" que estávamos tentando reconstruir.
O DS também foi a espinha dorsal do próprio reposicionamento de marca. A Alloyal precisava que o painel administrativo transmitisse modernidade e confiança — não apenas o dashboard, mas toda a superfície do produto com a qual os clientes interagem. Um sistema compartilhado tornou essa atualização consistente possível sem a necessidade de redesenhar cada tela do zero.
Os argumentos para construir o DS antes de lançar o dashboard
0
0
Componentes criados e documentados
0
0
Tipos de gráficos padronizados em todos os domínios
0
0
Estados do sistema definidos: erro, vazio, carregando, dados parciais
-0%
-0%
Redução no tempo de design para o domínio de Cashback (segundo a ser lançado)
0
0
Domínios de dashboard compartilhando uma única biblioteca de componentes
1
1
Biblioteca do Figma como a fonte única de verdade compartilhada com a Engenharia
O sistema padronizou a tipografia, o espaçamento, o uso de cores, os padrões de gráficos e todos os estados de interface. A engenharia passou a ter um ponto de referência único, eliminando a categoria de problemas em que o mesmo componente tem aparências diferentes em telas distintas. O DS evoluiu de uma entrega de UI para a base estrutural de um produto mais maduro e coerente.
RESULTADOS
Resultados em três públicos-públicos alvo
PARA CLIENTES
Chamadas de CS
Os clientes relataram responder às perguntas do programa de forma independente
Confiança
Maior confiança nos dados da plataforma, menos escalonamentos
PARA EQUIPES INTERNAS
Ingressos
Redução significativa nas solicitações de correção de dados relacionadas ao painel
Looke r
O CS não precisa mais de ferramentas externas para a maioria das consultas de dados de clientes
PARA O PRODUTO
Estratégico
Dashboard reposicionado de ferramenta de suporte para recurso do produto
Escalável
A base do DS apoia a expansão para novos módulos de análise
Feedback
Nas palavras deles
• “Reduzimos significativamente o número de tickets relacionados a inconsistências de dados.” • “Os clientes estão fazendo menos perguntas sobre métricas básicas — as conversas agora são mais estratégicas.” • “Não precisamos mais depender do Looker para a maioria das solicitações de clientes, o que economiza tempo e reduz a alternância de contexto.”
Equipe de CS
• “Esta é a primeira vez que o dashboard está sendo usado como um recurso do produto, e não apenas como uma ferramenta de suporte.” • “O Design System nos ajudou a avançar mais rápido e a manter a consistência entre os novos módulos do dashboard.” • “Agora temos uma base escalável para expandir o analytics em outros produtos.”
Equipe de Produto
Principais Aprendizados
O que este projeto reforçou
,1
Dados confiáveis importam mais do que recursos visuais
O maior problema de design aqui não era a interface do usuário — era a qualidade dos dados subjacentes. Nenhuma quantidade de refinamento visual teria corrigido um painel que estava mostrando números errados aos usuários. A descoberta precisa incluir a camada de dados, não apenas a interface.
,2
Dashboards são ferramentas de tomada de decisão, não visualizações
A pergunta não é "esse gráfico está bonito?", mas sim "isso ajuda alguém a tomar uma atitude?". Cada decisão de design foi avaliada com base em ajudar o cliente a decidir algo sobre seu programa de fidelidade, e não em ser esteticamente interessante.
,3
Um Design System é infraestrutura de produto, não um kit de UI
O DS liberou velocidade e consistência, mas o seu real valor foi permitir que o ambiente white-label escalasse sem fragmentação. Trate-o como um investimento de engenharia com uma face de design — e defenda esse argumento com os stakeholders usando números concretos.
,4
A centralização de dados reduz o custo operacional
Cada tíquete que o CS recebia representava um custo — em tempo, fragmentação de contexto e desgaste na confiança do cliente. Um design que viabiliza o autoatendimento gera um impacto de negócios mensurável. Estruturar o redesign dessa maneira ajudou a alinhar o PM, a liderança de CS e a engenharia em torno da mesma prioridade.
Retrospectiva
O que eu faria de diferente
Olhando para trás, após o lançamento e os primeiros meses de adoção, algumas coisas se destacam como áreas onde eu tomaria decisões diferentes hoje.
O que funcionou bem
Executar a auditoria de métricas antes de desenhar qualquer coisa. Foi tentador começar com wireframes, mas passar um tempo primeiro na camada de dados nos salvou de lançar uma versão mais bonita do mesmo design que já estava quebrado.
Construir o DS em paralelo com o dashboard. O investimento inicial se pagou imediatamente no segundo domínio (Cashback), que foi lançado na metade do tempo esperado.
Usar o CS como um parceiro de pesquisa, não apenas como um stakeholder. O conhecimento institucional deles sobre as dores dos clientes foi o insumo mais valioso na descoberta.
O que eu mudaria
Envolver a engenharia mais cedo na definição das métricas. As mudanças na lógica de cálculo surgiram tarde no desenvolvimento, adiando o lançamento em dois sprints. Eu realizaria uma sessão de viabilidade técnica na fase de descoberta.
Estabelecer métricas quantitativas de baseline antes do lançamento. Não tínhamos uma contagem clara de chamados pré-lançamento ou baseline de uso do Looker, o que tornou mais difícil quantificar o impacto depois. Eu instrumentaria isso desde o início.
Testar com mais arquétipos de clientes. Tivemos 5 clientes na pesquisa — todos gerentes de RH em médias e grandes empresas. Eu teria recrutado pelo menos uma empresa de pequeno porte e uma de um setor diferente para testar sob estresse as suposições de IA.
Mais Projetos
Mais Projetos
UI / UX Design
Dashboard Redesign
O que acontece quando o painel de controle mais importante da plataforma não é mais confiável para seus usuários? Este caso explora o redesign de um painel de administração que enfrentava baixa adoção, informações fragmentadas e dependência operacional. Como parte de uma iniciativa mais ampla de rebranding do produto, o desafio não era apenas modernizar a experiência, mas também reconstruir a confiança nos dados, melhorar a tomada de decisões e criar uma base escalável para o crescimento futuro. Do descobrimento à implementação, este projeto demonstra como o design estratégico pode transformar um painel de controle de um recurso negligenciado em uma ferramenta de negócios valiosa.
Ano:
2024
Indústria:
Tecnologia
Cliente:
Alloyal
Duração do Projeto:
2 Anos
Contexto e Meu Papel
Onde me encaixo
A Alloyal é uma plataforma de fidelidade B2B que gerencia assinaturas, programas de pontos ou cashback para clientes corporativos em todo o Brasil. O painel do administrador é a interface principal para as empresas clientes acompanharem o desempenho de seu programa, sendo efetivamente o principal ponto de contato do produto para os tomadores de decisão do lado do cliente.
MEU PAPEL
Lead Product Designer, único designer na frente do dashboard, trabalhando diretamente com o PM e dois engenheiros.
Colaboradores
Product Manager · 2 Engenheiros · Equipe de Customer Success (5 CSMs) · Equipe de dados (para validação de métricas)
Meu Escopo
Discovery · Arquitetura de Informação · Design de Interface (UI) · Design System · Handoff & QA
O redesign foi parte de uma iniciativa mais ampla de rebranding do painel administrativo. Fui responsável pelo processo de design de ponta a ponta, desde a condução de sessões de pesquisa até a entrega de componentes prontos para produção por meio de um Design System que criei do zero.
Problema
Um painel em que ninguém confiava
A análise inicial revelou cinco pontos de falha críticos e interconectados. Os problemas não eram isolados, eles formaram uma cascata: erros de métricas desgastaram a confiança, o que afastou os usuários, o que empurrou o volume para o Sucesso do Cliente, que se apoiou em ferramentas externas para compensar.
A INTUIÇÃO CENTRAL:
Os clientes não eram preguiçosos, eles eram racionais. Quando não se pode confiar em uma ferramenta, as pessoas encontram um caminho alternativo. Cada ticket para o CS era evidência de uma falha de design, não de uma falha do usuário.
Objetivo
Reposicione o painel como um ativo do produto
O redesign teve uma clara intenção estratégica: tornar o painel algo que os clientes escolhessem usar porque os tornava melhores em seus trabalhos, e não um recurso que eles apenas toleravam.
Única fonte da verdade
Elimine as discrepâncias de dados entre o painel e os relatórios de CS
Ferramenta de autoatendimento
Os clientes devem ser capazes de responder às suas próprias dúvidas sobre dados sem precisar ligar para o CS
Reduza a carga de CS
Liberte o Customer Success do suporte reativo de dados para conversas estratégicas
Fundação escalável
Design System como infraestrutura para apoiar a futura expansão de analytics
Única fonte da verdade
Elimine as discrepâncias de dados entre o painel e os relatórios de CS
Reduza a carga de CS
Liberte o Customer Success do suporte reativo de dados para conversas estratégicas
Ferramenta de autoatendimento
Os clientes devem ser capazes de responder às suas próprias dúvidas sobre dados sem precisar ligar para o CS
Fundação escalável
Design System como infraestrutura para apoiar a futura expansão de analytics
Painel Versão antiga
Descoberta
Entendendo onde a confiança foi quebrada
Antes de tocar em qualquer layout ou componente, eu precisava entender exatamente onde o pipeline de dados estava falhando e como isso moldava o comportamento do usuário. Conduzi uma descoberta em três frentes ao longo de três semanas.
Método 01 · Entrevistas com stakeholders
Mergulho profundo da equipe de CS
Entrevistei 4 Gerentes de Sucesso do Cliente (CSMs) individualmente. Pedi que me guiassem por uma solicitação típica de dados de clientes: o que foi solicitado, o que eles tiveram que pesquisar, por que não puderam direcionar o cliente para o painel.
"Primeiro abro o Looker porque sei que os números lá estão certos. Depois abro o dashboard para mostrar ao cliente onde encontrar as coisas mais tarde, mas sei que os números não vão bater."
— CSM, entrevistado na descoberta
Método 02 · Sessões de clientes
5 entrevistas com clientes
Recrutei 5 clientes B2B ativos (gerentes de RH em médias e grandes empresas) para sessões de 45 minutos. Observei-os tentando responder a perguntas reais de negócios usando o painel existente. Acompanhei onde eles ficaram travados, o que esperavam encontrar e quando desistiram.
"Eu queria saber quantos pontos estavam para expirar este mês. Não consegui encontrar, então enviei um WhatsApp para o nosso gerente de conta."
— Cliente, Gerente de RH em uma empresa de varejo
Método 03 · Cruzamento de dados
Auditoria de métricas com a equipe de dados
Junto com um analista de dados, mapeei cada métrica exibida no painel em relação à sua lógica de cálculo e comparei com o equivalente no Looker. Encontrei 7 discrepâncias — 3 eram críticas (taxa de churn, contagem de assinantes ativos, taxa de utilização de cashback).
Descoberta Principal
A maior discrepância estava em como o "assinante ativo" era definido. O painel contava qualquer assinatura criada no período; o Looker contava apenas aquelas com pelo menos uma transação. Uma diferença de ~30% no mesmo número.
Método 04 · Análise de chamados
Categorização de tíquetes de suporte
Analisei 3 meses de chamados de suporte (CS) marcados como "dashboard" ou "dúvida de dados". Categorizei-os por tópico e os mapeei para telas específicas. Isso me deu um mapa de priorização: quais lacunas ou erros de dados causaram o maior atrito.
Os 3 principais motivos de chamados foram
Interpretação de churn (34%), visibilidade da expiração de pontos (28%), reconciliação de cashback (21%).
Resultado do discovery:
Uma lista priorizada de inconsistências de métricas, um mapa dos dados mais solicitados não disponíveis no painel e uma imagem clara das duas principais jornadas do usuário (o cliente revisando a saúde do programa versus o CS preparando um relatório do cliente). Esses se tornaram a espinha dorsal do redesign da arquitetura de informação.
Abordagem
Cinco apostas que fizemos
1
Validação de dados com stakeholders reais
Cruzei todas as métricas com a equipe de CS e a equipe de dados antes de redesenhar qualquer coisa. Redefini a lógica de cálculo para as 3 métricas críticas em colaboração com a engenharia.
→ Resultado: definições claras de métricas acordadas entre as equipes de CS, Produto e Engenharia
2
Redesenho da arquitetura de informação por domínio de produto
Reorganizei o painel em torno de três domínios de produtos (Assinaturas, Pontos, Cashback) com uma separação clara entre KPIs estratégicos e dados operacionais. Apliquei divulgação progressiva: visão geral → detalhes.
→ Resultado: os clientes podiam navegar para sua área específica sem escanear a tela toda
3
Cobertura de dados expandida por domínio
Adicionados painéis dedicados para cada domínio abordando os principais motivadores de chamados: cancelamento (churn) relativo à base ativa (não absoluto), cronograma de expiração de pontos, visualização de reconciliação de cashback.
→ Resultado: as três principais categorias de chamados agora contam com respostas de autoatendimento no produto
4
Recursos de autonomia do cliente
Adicionamos exportação para CSV, controles de comparação de períodos e dicas de ferramentas contextuais explicando as definições das métricas. O objetivo era reduzir a necessidade de entrar em contato com o CS (Sucesso do Cliente), mesmo para casos específicos.
→ Resultado: os clientes agora podem executar suas próprias análises ad-hoc sem o envolvimento de CS
5
Design System como a espinha dorsal do rebranding
Criei um Design System dedicado para garantir a consistência em todos os três domínios do dashboard e no ambiente white-label. Padronizei componentes, estilos de gráficos, tipografia e todos os estados (erro, vazio, carregamento).
→ Resultado: os novos módulos do painel agora levam cerca de 40% menos tempo de design devido às bases reutilizáveis
Principais Decisões de Design
Três decisões que moldaram o resultado
Essas não foram decisões óbvias, cada uma envolveu um trade-off e uma escolha que poderia ter tomado um rumo diferente. Aqui está o raciocínio por trás daquelas que mais importaram.
DECISÃO 01
Mostrar o churn como % da base ativa, não como um número absoluto
ALTERNATIVAS CONSIDERADAS
DESCARTADO
Número absoluto de cancelamentos
DESCARTADO
Apenas delta período sobre período
POR QUE ESCOLHEMOS ISSO
Clientes com 500 assinantes e 50 cancelamentos interpretam isso de forma diferente daqueles com 5.000 e 50 cancelamentos. A abordagem em % tornou o mesmo número acionável, independentemente do tamanho do programa, e correspondeu à forma como os clientes realmente falavam sobre seus negócios nas entrevistas.
DECISÃO 02
Navegação focada em domínios (Assinaturas · Pontos · Cashback) sobre uma visão unificada
ALTERNATIVAS CONSIDERADAS
DESCARTADO
Visão geral única com rolagem
DESCARTADO
Visualização de todas as métricas baseada em guias
POR QUE ESCOLHEMOS ISSO
A fase de descoberta mostrou que os clientes eram focados em produtos específicos: um gerente de RH que gerenciava um programa de pontos não se importava com métricas de cashback. Uma visualização unificada os forçava a filtrar visualmente tudo o que viam, todas as vezes. Uma abordagem focada no domínio (domain-first) reduziu a carga cognitiva e fez com que a página parecesse relevante para cada persona desde o primeiro clique.
DECISÃO 03
Construa o Design System antes de lançar o dashboard, não depois
ALTERNATIVAS CONSIDERADAS
DESCARTADO
Envie o dashboard primeiro, DS depois
DESCARTADO
Adote um sistema de código aberto existente
POR QUE ESCOLHEMOS ISSO
Três domínios sendo lançados sem uma base compartilhada inevitavelmente se distanciariam, prejudicando a percepção consistente e confiável que precisávamos reconstruir. Fazer o DS primeiro também trouxe resultados imediatos: o domínio Cashback foi lançado cerca de 40% mais rápido. Mapeei esse ganho em relação ao investimento de 3 semanas e o PM concordou.
SOLUÇÃO
Uma experiência redesenhada em três pilares
Uma experiência de painel reformulada com base em três pilares:
DESIGN SYSTEM
Os argumentos para construir o DS antes de lançar o dashboard
O redesign não era apenas uma tela — eram três domínios de painéis interconectados (Assinaturas, Pontos, Cashback), todos parte de um rebranding mais amplo do painel administrativo. Sem uma base compartilhada, cada domínio inevitavelmente se fragmentaria: estilos de gráficos diferentes, layouts de cartões inconsistentes, estados vazios variados. Essa fragmentação prejudicaria diretamente a percepção de "confiável e seguro" que estávamos tentando reconstruir.
O DS também foi a espinha dorsal do próprio reposicionamento de marca. A Alloyal precisava que o painel administrativo transmitisse modernidade e confiança — não apenas o dashboard, mas toda a superfície do produto com a qual os clientes interagem. Um sistema compartilhado tornou essa atualização consistente possível sem a necessidade de redesenhar cada tela do zero.
Os argumentos para construir o DS antes de lançar o dashboard
0
0
Componentes criados e documentados
0
0
Tipos de gráficos padronizados em todos os domínios
0
0
Estados do sistema definidos: erro, vazio, carregando, dados parciais
-0%
-0%
Redução no tempo de design para o domínio de Cashback (segundo a ser lançado)
0
0
Domínios de dashboard compartilhando uma única biblioteca de componentes
1
1
Biblioteca do Figma como a fonte única de verdade compartilhada com a Engenharia
O sistema padronizou a tipografia, o espaçamento, o uso de cores, os padrões de gráficos e todos os estados de interface. A engenharia passou a ter um ponto de referência único, eliminando a categoria de problemas em que o mesmo componente tem aparências diferentes em telas distintas. O DS evoluiu de uma entrega de UI para a base estrutural de um produto mais maduro e coerente.
RESULTADOS
Resultados em três públicos-públicos alvo
PARA CLIENTES
Chamadas de CS
Os clientes relataram responder às perguntas do programa de forma independente
Confiança
Maior confiança nos dados da plataforma, menos escalonamentos
PARA EQUIPES INTERNAS
Ingressos
Redução significativa nas solicitações de correção de dados relacionadas ao painel
Looke r
O CS não precisa mais de ferramentas externas para a maioria das consultas de dados de clientes
PARA O PRODUTO
Estratégico
Dashboard reposicionado de ferramenta de suporte para recurso do produto
Escalável
A base do DS apoia a expansão para novos módulos de análise
Feedback
Nas palavras deles
• “Reduzimos significativamente o número de tickets relacionados a inconsistências de dados.” • “Os clientes estão fazendo menos perguntas sobre métricas básicas — as conversas agora são mais estratégicas.” • “Não precisamos mais depender do Looker para a maioria das solicitações de clientes, o que economiza tempo e reduz a alternância de contexto.”
Equipe de CS
• “Esta é a primeira vez que o dashboard está sendo usado como um recurso do produto, e não apenas como uma ferramenta de suporte.” • “O Design System nos ajudou a avançar mais rápido e a manter a consistência entre os novos módulos do dashboard.” • “Agora temos uma base escalável para expandir o analytics em outros produtos.”
Equipe de Produto
Principais Aprendizados
O que este projeto reforçou
,1
Dados confiáveis importam mais do que recursos visuais
O maior problema de design aqui não era a interface do usuário — era a qualidade dos dados subjacentes. Nenhuma quantidade de refinamento visual teria corrigido um painel que estava mostrando números errados aos usuários. A descoberta precisa incluir a camada de dados, não apenas a interface.
,2
Dashboards são ferramentas de tomada de decisão, não visualizações
A pergunta não é "esse gráfico está bonito?", mas sim "isso ajuda alguém a tomar uma atitude?". Cada decisão de design foi avaliada com base em ajudar o cliente a decidir algo sobre seu programa de fidelidade, e não em ser esteticamente interessante.
,3
Um Design System é infraestrutura de produto, não um kit de UI
O DS liberou velocidade e consistência, mas o seu real valor foi permitir que o ambiente white-label escalasse sem fragmentação. Trate-o como um investimento de engenharia com uma face de design — e defenda esse argumento com os stakeholders usando números concretos.
,4
A centralização de dados reduz o custo operacional
Cada tíquete que o CS recebia representava um custo — em tempo, fragmentação de contexto e desgaste na confiança do cliente. Um design que viabiliza o autoatendimento gera um impacto de negócios mensurável. Estruturar o redesign dessa maneira ajudou a alinhar o PM, a liderança de CS e a engenharia em torno da mesma prioridade.
Retrospectiva
O que eu faria de diferente
Olhando para trás, após o lançamento e os primeiros meses de adoção, algumas coisas se destacam como áreas onde eu tomaria decisões diferentes hoje.
O que funcionou bem
Executar a auditoria de métricas antes de desenhar qualquer coisa. Foi tentador começar com wireframes, mas passar um tempo primeiro na camada de dados nos salvou de lançar uma versão mais bonita do mesmo design que já estava quebrado.
Construir o DS em paralelo com o dashboard. O investimento inicial se pagou imediatamente no segundo domínio (Cashback), que foi lançado na metade do tempo esperado.
Usar o CS como um parceiro de pesquisa, não apenas como um stakeholder. O conhecimento institucional deles sobre as dores dos clientes foi o insumo mais valioso na descoberta.
O que eu mudaria
Envolver a engenharia mais cedo na definição das métricas. As mudanças na lógica de cálculo surgiram tarde no desenvolvimento, adiando o lançamento em dois sprints. Eu realizaria uma sessão de viabilidade técnica na fase de descoberta.
Estabelecer métricas quantitativas de baseline antes do lançamento. Não tínhamos uma contagem clara de chamados pré-lançamento ou baseline de uso do Looker, o que tornou mais difícil quantificar o impacto depois. Eu instrumentaria isso desde o início.
Testar com mais arquétipos de clientes. Tivemos 5 clientes na pesquisa — todos gerentes de RH em médias e grandes empresas. Eu teria recrutado pelo menos uma empresa de pequeno porte e uma de um setor diferente para testar sob estresse as suposições de IA.