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

DISCLAIMER: Perdão minha pessoa amiga leitora, o projeto é real, mas o texto ta escrito por IA e ele ta chatão de ler… Estou reescrevendo meus projetos com minhas próprias mões, eu só não posso deixar isso aqui vazio. Continua sendo um ótimo case, só tá meio chato de ler.

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.