Content Design System.
Como criamos uma biblioteca de conteúdo padronizado para mais de 10 verticais.
Com o processo de UX Writing estruturado, um problema diferente ficou evidente: o conteúdo genérico do PicPay — mensagens de erro, estados vazios, loading, preenchimento de campo — era escrito de formas diferentes em cada squad. Em um caso específico, o mesmo erro de conexão tinha quatro versões distintas no app.
Mais de 10 verticais com dezenas de designers em paralelo.
Quatro versões distintas da mesma mensagem de erro.
Sem fonte única de verdade, cada squad reinventava a roda.
Inconsistência de conteúdo não acontecia por acaso — era consequência de como o time era estruturado.
- T.01Usuários encontravam versões contraditórias da mesma mensagem dentro do mesmo app.
- T.02UX Writers perdiam tempo revisando variações do mesmo padrão — semana após semana.
- T.03Conteúdo era tratado como camada separada — quase sempre aplicada depois que o componente já existia.
- 01Etapa 1 / 5
Mapeamento
Squad por squad, vertical por vertical, identifiquei todas as mensagens genéricas que afetam o produto inteiro. Levei mais tempo do que esperava só para ter clareza do escopo.
- 02Etapa 2 / 5
Priorização
Fase 1: erros de conexão, erros de sistema, estados vazios, loading e preenchimento de campo. Contextuais ficaram para depois — uma escolha consciente para não travar o projeto.
- 03Etapa 3 / 5
Metodologia
Teoria de Jakob para não criar rupturas com o conhecido. 48 Emoções de Plutchik para mapear sentimento. Canvas de UX Writing por mensagem. Análise de 'O que dizem e Como dizem' nos concorrentes.
- 04Etapa 4 / 5
Padronização
Feita no Figma — focando primeiro em conteúdo, sentimento e usuário, sem pensar em UI.
- 05Etapa 5 / 5
UX Writing Critique
Ciclo de revisão coletiva com todo o time antes da documentação final. Várias decisões mudaram nessa etapa.
Onde começar quando não dá para padronizar tudo.
Priorização explícita: o que entra na fase 1, o que fica fora e por quê.
Integrar ao Design System
Aproximar UX Writing das decisões de UI. Garantir que conteúdo não fosse camada separada, mas parte estrutural do componente — algo que exigiu negociação com o time de DS.
Não tentar padronizar tudo
Mensagens contextuais — como erros específicos de empréstimo PF, irrelevantes para PJ — ficaram fora da fase 1. Escopo viável vence ambição.
Conteúdo antes de UI
No Figma, comecei pelo sentimento e pela voz. UI veio depois, encaixando-se no conteúdo — inverso do que o time costumava fazer.
- 01
Biblioteca de Conteúdo
Figma LibraryOrganizada por categoria, acessível para UX Writers e Product Designers. - 02
Mensagens de erro de conexão
PatternPadronização única para todo o app. - 03
Mensagens de erro de sistema
PatternTom calibrado por criticidade. - 04
Estados vazios
PatternVoz, sentimento e CTA padronizados. - 05
Preenchimento de campo
PatternMicrocopy de formulário consistente.
Conteúdo virou parte do componente.
- 01
Primeira biblioteca de conteúdo padronizado integrada ao Design System do PicPay.
- 02
Mais de 10 verticais passaram a usar os mesmos padrões de mensagem, eliminando versões duplicadas.
- 03
Product Designers ganharam autonomia para aplicar conteúdo diretamente no fluxo de design — sem precisar abrir ticket para UX Writing.
- 04
Conteúdo deixou de ser camada aplicada depois — passou a fazer parte da infraestrutura do produto.