Sistema de Conteúdo Daki.
Como criar consistência de conteúdo sem Design System num app internacional.
A Daki era um app internacional de varejo de comida operando nos Estados Unidos, Peru, México e Colômbia. Produto multi-país, multi-idioma, com múltiplas squads e um problema visível desde o primeiro dia: conteúdo inconsistente, às vezes escrito em línguas erradas dentro do mesmo fluxo. E não havia Design System.
Estados Unidos, Peru, México e Colômbia.
Sem Design System estabelecido.
Textos misturados, linguagens trocadas dentro do mesmo fluxo.
Além da inconsistência entre países, faltava infraestrutura mínima para transformar decisões de conteúdo em padrão.
- T.01Padronizar conteúdo internacional sem qualquer infraestrutura visual significava abrir mão da abordagem convencional.
- T.02Inicialmente tentamos pensar numa biblioteca de Figma — não fazia sentido sem componentes para ancorar.
- T.03Criar algo que o time usasse no dia a dia, sem depender de ferramentas que não existiam, virou a restrição central.
- T.04Aceitar os limites estruturais sem deixar de entregar valor real foi uma decisão difícil, e teve custo.
Quando o Design System não existe, o sistema de conteúdo aprende a viver sem ele.
Arquitetura de conteúdo.
Mapeei o app inteiro classificando por tipo — texto primário, CTAs, botões, modais, formulários — com roadmap de prioridades documentado no Miro.
Matriz de Tom.
Apliquei em todos os conteúdos, lendo cada frase e pontuando voz e sentimento. O objetivo era responder uma pergunta simples mas raramente feita: o que esse app está transmitindo?
Content Persona.
Benchmark de apps similares, análise de lojas de aplicativo e dados de CX — mapeando jargões, verbosidade, barreiras de conteúdo e vocabulário real do usuário.
Princípios do sistema.
Usando o UX Writing Voice Chart, defini os três princípios: Agilidade, Otimismo e Genuinidade.
Documentação no Notion.
Organizada por temas acessíveis para todo o time, incluindo designers e desenvolvedores.
Adaptar é o trabalho. Reconhecer o limite também.
Três decisões que assumiram a maturidade real da operação — sem fingir que ela era outra.
Adaptar a abordagem à infraestrutura real
Sem Design System, biblioteca no Figma não escalaria. Notion virou a opção viável — com os limites assumidos abertamente.
Tom como diagnóstico
Antes de definir voz, ler o que já existia. Sem isso, o novo sistema seria mais uma camada desconectada do que o time realmente usava.
Reconhecer o teto estrutural
Sistema sólido em infraestrutura imatura tem alcance limitado. Reconhecer isso é parte do trabalho sênior — não fraqueza, e não desculpa para entregar menos.
- 01
Arquitetura de Conteúdo
MapaApp inteiro classificado por tipo, no Miro. - 02
Matriz de Tom aplicada
DiagnósticoVoz e sentimento pontuados em todos os conteúdos. - 03
Content Persona
DocumentoVocabulário real do usuário, jargões e barreiras. - 04
Princípios do sistema
Voice ChartAgilidade, Otimismo e Genuinidade. - 05
Sistema no Notion
Knowledge baseOrganizado para uso de designers e desenvolvedores.
Sistema sólido em infraestrutura imatura — entrega parcial assumida.
- 01
Sistema de conteúdo criado do zero sem Design System, adaptado à realidade operacional do time.
- 02
Conteúdo padronizado para um app que operava em 4 países e múltiplos idiomas.
- 03
Time passou a ter uma referência única de vocabulário, tom e arquitetura de informação.
- 04
Aprendizado honesto documentado: processo sólido em estrutura imatura gera resultado parcial — e reconhecer isso é parte do trabalho sênior.