Dark Mode: Design de Sistema de Tokens para Melhoria de Satisfação

Papel: Product Designer Lead
Responsabilidades: Liderança estratégica, design de sistema, alinhamento com Dev e PM
Impacto: +11pp CSAT geral | +14pp CSAT Enterprise | 33% de adoção e retenção
Período: 2 semanas de implementação | Validação Q1 2025
Time: Michel (Product Design Lead) + Product Manager + Engenheiros
Contexto: Projeto identificado via pesquisa CSAT reformulada, priorizado por impacto mensurável

O Problema: Dados que Geraram uma Oportunidade

Insight da Pesquisa CSAT Reformulada

Entre dezembro de 2024 e janeiro de 2025, a pesquisa de satisfação (que havíamos redimensionado para maior granularidade) mostrou:

Dentro de "Design da tela", o subtópico mais crítico:

O Contexto que Explicava os Dados

A interface era majoritariamente branca (#FFF), o que poderia ser aceitável para um produto de uso ocasional. Mas estávamos falando da ferramenta principal de trabalho dos atendentes:

• ⏰ 7+ horas por dia de uso contínuo
• 🌑 Ambientes de baixa luminosidade (centrais de atendimento)
• 🎯 Contraste intenso causando desconforto visual
• 🚨 Cores de eventos fora da paleta padrão (ex: fundo verde + texto branco = inacessível)

Validação Qualitativa

Feedbacks espontâneos dos usuários confirmavam o problema:

• "Cansa muito à vista"
• "Interface muito branca"
• "Dor de cabeça depois de usar por muito tempo"
• Clientes Enterprise relatavam o mesmo incômodo

Conclusão: Não era um problema pontual. Era uma dor compartilhada que afetava múltiplos segmentos de usuários e era mensurável nos dados.

A Estratégia: Além do Dark Mode

Alinhamento de Stakeholders

Antes de desenhar qualquer coisa, o trabalho foi alinhamento:

Com PM:

• "Temos 17 votos em 'cores da tela' — é o 2º problema mais mencionado"
• "Se implementarmos, esperamos ver essa métrica cair significativamente no próximo CSAT"
• "Isso também melhora a percepção de qualidade do produto"

Com Engenharia:

• "Podemos fazer isso em 2 semanas?"
• "Qual a melhor estratégia — tokens ou refator de componentes?"
• "Precisamos manter compatibilidade com Light Mode enquanto desenvolvemos"

Resultado: Consenso de que design tokens era o caminho certo — permite lançamento rápido + escalabilidade futura.

O Desafio Não Era Apenas Criar um Tema Escuro

1. ✅ Lançar o Dark Mode rapidamente (2 semanas)
2. ✅ Manter consistência visual em ambos os temas
3. ✅ Permitir personalizações futuras (mudanças de cor corporativa)
4. ✅ Melhorar as cores do Light Mode também
5. ✅ Sincronizar código (Figma) com desenvolvimento (Nebular/Angular)

Abordagem: Design Tokens (Inspirado em Atlassian)

Adotamos a arquitetura de tokens de design baseada na estrutura do Atlassian Design System:

Antes:

• 31 tokens de cor (sistema limitado e sem flexibilidade)
• Cores codificadas diretamente nos componentes
• Impossível mudar tema sem refatoração completa

Depois:

• 470+ tokens totais
• 192 tokens primitivos (cores base)
• Estrutura hierárquica: Primitivos → Semânticos → Componentes
• Temas dinâmicos (Light/Dark com switching em tempo real)

Implementação Técnica

Stack: Nebular (UI Kit Angular) com customização por temas

Colaboração Design ↔ Engineering:

A chave foi synced decision-making. Ao invés de Design entregar specs e Engineering implementar, fizemos:

1. Design definiu o modelo de tokens (inspirado em Atlassian)
2. Engineering validou viabilidade (possível em 2 semanas? sim, com a estratégia certa)
3. Design + Engineering definiram o mapeamento (qual cor antiga vira qual token novo)

Estratégia de Lançamento Rápido: Para viabilizar em 2 semanas, não refatoramos tudo de uma vez. Ao invés disso:

• Mapeamos tokens antigos → novos (HEX por HEX)
• Biblioteca traduzia automaticamente para Dark Mode
• Isso permitiu lançamento rápido enquanto consolidávamos o sistema
• Refatoração completa viria depois, sem pressão

Cor Antiga (#FFF) → Token Novo (color-background-neutral-100-light) 
                 → Token Dark Mode (color-background-neutral-900-dark)

Resultados: Validação Clara

Métrica 1: Adoção & Retenção

• ✅ 33% de adoção entre todos os usuários
• ✅ Retenção alta — continuam usando após lançamento
• ✅ Não é um "nice to have", é um recurso que as pessoas querem manter

Métrica 2: CSAT (Antes vs Depois)

Antes do Dark Mode (01 dez - 01 jan):

Depois do Dark Mode (01 mar - 01 abr):

Métrica 3: Mudança nas Prioridades de Feedback

O verdadeiro teste: "Design da tela" (o problema que motivou o projeto) caiu drasticamente:

Antes (top 6 subtópicos):

Depois (top 6 subtópicos):

Macro assuntos (Antes → Depois):

Interpretação: O problema foi resolvido. A pesquisa agora identifica os próximos problemas.

Impactos Secundários (Não Planejados, Mas Valiosos)

1. Melhoria Colateral no Light Mode

Com a nova estrutura de tokens, as cores do Light Mode também melhoraram:

• Melhor contraste
• Paleta mais consistente
• Benefício para todos os usuários, não apenas quem usa Dark Mode

2. Escalabilidade do Design System

"Se amanhã a cor corporativa mudar para azul, alteramos a plataforma inteira mudando apenas 1 HEX"

• Sistema totalmente parametrizável
• Futuro-proof para mudanças de branding

3. Sincronização Código-Design

A precisão no desenvolvimento de novas funcionalidades aumentou porque:

• Código pareado com Figma
• Tokens consistentes entre design e implementação
• Menos divergências e bugs visuais

Learnings Principais

Para Product Designer em Posição de Liderança:

1. Pesquisa bem estruturada gera roadmap clara e defensável
   • O CSAT reformulado identificou "cores da tela" com precisão
   • PM e engenharia puderam confiar nos dados para priorizar
   • Sem dados, a conversa seria "acho que seria bom ter dark mode"
2. Alinhamento early é crítico
   • Conversa com PM: "Qual é o impacto esperado?"
   • Conversa com Eng: "O que é tecnicamente viável?"
   • Resultado: decisão de design tokens (não era óbvia no início)
3. Tradeoffs precisam ser explícitos
   • "Podemos fazer refator completo em 4 semanas OU lançar em 2 semanas com mapeamento"
   • Escolhemos a segunda. Refator virá depois com menos pressão
   • Isso é produto thinking, não só design thinking
4. Design tokens são ativos de liderança
   • Não é "apenas design". É infraestrutura que habilita:
     • Futuras mudanças de branding
     • Consistência entre temas
     • Autonomia de engenharia em novas features
   • Como Product Lead, você cria ativos que multiplicam o impacto da equipe

Para Colaboração Design + PM + Engineering:

1. Dados quantificáveis são ponte entre disciplinas
   • PM entende: "17 votos significam prioridade"
   • Eng entende: "2 semanas é viável com essa abordagem"
   • Design entende: "Isso resolve um problema real"
2. Decisões design-tech precisam ser colaborativas desde o início
   • Se design disser "queremos 500 tokens" e eng disser "não dá em 2 semanas", é problema
   • Se eng disser "mapeamento HEX" e design disser "não funciona visualmente", é problema
   • Decisão de "mapeamento + refator depois" saiu de conversa, não de um lado impondo ao outro
3. Métricas compartilhadas alinham o time
   • Antes: Design quer melhorar, PM quer CSAT, Eng quer código limpo (conflitos)
   • Depois: Time inteiro quer ver "cores da tela" cair de 2º para 6º lugar
   • Métrica unificada alinha incentivos
4. Lançamento rápido com qualidade é possível
   • Requer clareza (tokens, não gambi)
   • Requer colaboração (design ↔ eng iterando)
   • Requer tradeoffs conscientes (mapeamento agora, refator depois)

Para Produto (Direcionamento de Features):

1. Insights quantificáveis são defensáveis
   • "17 votos em 'cores da tela'" justifica 2 semanas melhor que "achamos que seria bom"
2. Dados estruturados permitem iteração rápida
   • Com a pesquisa antiga, teria demorado meses
   • Com granularidade, foi claro em 30 dias
3. Features podem ser validadas por feedback
   • 33% adoção + queda de 82% no problema = validação completa
   • Não é suposto — é medido

Estrutura Técnica de Tokens (Para Contexto)

Tier 1: Primitivos (base)
├── color-neutral-50 (#FFFFFF - Light)
├── color-neutral-900 (#1a1a1a - Dark)
├── color-primary-500 (#667eea)
└── ... (+192 tokens primitivos)

Tier 2: Semânticos (significado)
├── color-background-default (usa color-neutral-50 em Light, color-neutral-900 em Dark)
├── color-text-primary (usa color-neutral-900 em Light, color-neutral-50 em Dark)
├── color-border-subtle
└── ...

Com apenas Primitivos + Semânticos, conseguimos transformar a aparência inteira da interface sem mudar nenhum componente Angular.

Conclusão

O Dark Mode foi muito mais que um "nice to have" visual. Foi a validação prática de que uma pesquisa bem estruturada gera insights acionáveis.

A pesquisa identificou o problema (cores), prototipamos a solução (Dark Mode), e os dados confirmaram que funcionou (CSAT +11pp, problema caiu 82%).

Ciclo completo de data-driven product design.