Sistema de Conteúdo na Daki.
Como criar consistência de conteúdo em um produto internacional sem Design System.
A Daki era um app internacional de varejo de comida, com operação nos Estados Unidos, Peru, México e Colômbia. O produto crescia em vários países, idiomas e squads ao mesmo tempo, mas ainda não tinha um Design System estabelecido. Na prática, isso aparecia em conteúdos inconsistentes, variações de tom e, em alguns casos, idiomas diferentes dentro do mesmo fluxo. O problema não era só revisar textos inconsistentes. Faltava uma forma de transformar decisões de conteúdo em referência para o time.
Estados Unidos, Peru, México e Colômbia.
Idiomas diferentes aparecendo dentro do mesmo fluxo.
Sem base estabelecida para sustentar um sistema completo.
Padronizar conteúdo internacional sem uma base visual exigia adaptar a abordagem. Criar uma biblioteca como se o Design System já existisse poderia até parecer mais completo, mas dificilmente seria usada no dia a dia.
- T.01O produto precisava de consistência, mas a infraestrutura ainda não estava pronta para sustentar um sistema completo.
- T.02As squads tomavam decisões de conteúdo em ritmos diferentes, com critérios diferentes e pouca referência compartilhada.
- T.03O desafio não era apenas traduzir conteúdo entre países. Cada operação tinha diferenças reais de vocabulário, informalidade e expectativa cultural.
- T.04O sistema precisava equilibrar consistência global, adaptação local, facilidade de uso e velocidade de produção.
Sem Design System, o sistema de conteúdo precisava funcionar dentro da infraestrutura que o time já tinha.
Mapear padrões antes de criar componentes.
Antes de propor qualquer estrutura, analisei os fluxos existentes para entender onde as inconsistências apareciam com mais frequência. A ideia era identificar padrões reais de uso, não criar uma biblioteca idealizada.
Separar decisões globais e adaptações locais.
Nem tudo precisava ser igual em todos os países. Algumas decisões deveriam ser globais, como princípios de tom, estrutura de mensagens e critérios de consistência. Outras precisavam continuar abertas para adaptação local, principalmente vocabulário, expressões e nível de informalidade.
Criar referência sem depender do Figma.
Sem Design System, uma biblioteca no Figma não teria sustentação suficiente para escalar. Poderia funcionar bem como entrega visual, mas teria pouca chance de virar referência prática para o time.
Documentar o raciocínio por trás das escolhas.
O sistema precisava explicar não só qual texto usar, mas por que aquela decisão fazia sentido. Isso ajudava designers, PMs e pessoas de localização a tomar decisões melhores quando surgiam novos cenários.
Como criar um sistema útil dentro de uma estrutura ainda imatura.
Como criar um sistema útil dentro de uma estrutura ainda imatura.
Criar um sistema de decisão, não só uma biblioteca de textos
A entrega não poderia depender apenas de exemplos prontos. O time precisava de critérios para decidir como escrever títulos, CTAs, mensagens de erro, textos de apoio e comunicações em diferentes fluxos.
Assumir que a consistência não seria perfeita
Com países, idiomas e squads diferentes, consistência total não era um objetivo realista naquele momento. O objetivo era reduzir variações desnecessárias e criar uma base comum para decisões futuras.
Trabalhar com o limite da infraestrutura
Um sistema de conteúdo depende da infraestrutura em que ele vive. Sem um Design System estabelecido, a entrega precisava ser útil o bastante para orientar o time, mesmo sem virar uma camada técnica completa.
Evitar uma solução bonita, mas difícil de manter
A prioridade foi criar algo que pudesse ser consultado, aplicado e evoluído pelo time. Uma entrega muito sofisticada, mas desconectada da rotina das squads, teria pouca chance de sobreviver depois do projeto.
- 01Documento01
Princípios de Conteúdo
DocumentoDiretrizes para orientar a voz do produto, considerando consistência global, adaptação local e contexto de uso. - 02Documento02
Padrões de UX Writing
DocumentoOrientações para títulos, CTAs, mensagens de erro, textos de apoio, estados vazios, feedbacks e outras microcopies recorrentes. - 03Estrutura03
Critérios de Decisão
EstruturaRegras para ajudar o time a escolher entre opções de conteúdo, especialmente em cenários com diferenças entre países, idiomas e contextos culturais. - 04Operação04
Base de Referência para Squads
OperaçãoDocumentação criada para apoiar designers, PMs e pessoas envolvidas em localização, reduzindo decisões isoladas e retrabalho. - 05Continuidade05
Base para Evolução Futura
ContinuidadeA entrega não resolvia todos os problemas de infraestrutura, mas criava uma base para decisões mais consistentes enquanto o Design System ainda não existia.
Um sistema de conteúdo criado para funcionar dentro dos limites reais do produto.
- 01
Sistema de conteúdo operando em quatro países com três princípios compartilhados como base.
- 02
Múltiplas squads usando a mesma fundação de linguagem, reduzindo variações entre idiomas e fluxos.
- 03
Consistência entre mercados aumentada sem centralizar decisões nem criar dependência de um único time.
Como medimos — cobertura do sistema por mercado e número de squads operando com base no mesmo conjunto de princípios e componentes.