Cassio Almeida
© Cassio Almeida

Sistema de Conteúdo

O desafio de padronizar conteúdos sem um Design System em um app internacional

— Nome do projeto

Content System


— Time

Cassio Almeida – UX Writer


— Período

2021 – 2022

Resumo:

Nem todo time de Design tem um Design System. Às vezes é pela falta de uma pessoa especialista ou pela falta de maturidade do time. Faz parte do trabalho. Então, como UX Writer, nesses casos, eu preciso pensar em maneiras de padronizar meus conteúdos sem a necessidade de criar bibliotecas no Figma (ou XD). Claro, não é a melhor forma, mas é importante se adaptar ao contexto.


Na Daki, um app internacional (Estados Unidos, Peru, México e Colômbia) de varejo de comida, eu tinha esse grande desafio: criar um sistema de conteúdo que fizesse sentido para as squads sem a necessidade do Figma. Montar uma documentação de conteúdos padronizados para que os Product Designers e Desenvolvedores conseguissem escrever em seus fluxos.

Problemas

Sem Design System. Conteúdos misturados e sem padrão, às vezes até escritos em outras línguas dentro do mesmo fluxo. Problema de documentação. Problema de estrutura de conteúdo. Tudo isso era um graaaaaaande problema para Design. Em CX, todo dia recebíamos muitas reclamações especificamente sobre textos, porque era bem confusos.


O que isso gerava? - Amontoado de reclamações em CX.

- Arquitetura de informação confusa

- Confusão com usuário

- Falta de padronização conteúdo entre squads e verticais.

Desafio

São inúmeros desafios, então vou contar o principal: dar valor pra UX Writing com o Sistema de Conteúdo. Além da padronização e procurar esses conteúdos, eu precisava mostrar que UX Writing é importante em todas as verticais, independente do cargo da pessoa. Dar um conteúdo fechado, metrificado e padronizado era de extrema importância para Daki.

Processo :)

Confira todas as etapas

Analisar

O primeiro passo: analisar. E analisar o que? A estrutura de conteúdo do app. Aqui, foi necessário entender quais são os tipos de conteúdo do aplicativo, ou seja, texto primário, CTAs, botão terciário, etc.


Como eu fiz?

Separei por partes do app. Exemplo: tipos de conteúdo no login, no cadastro e na home. Assim, eu conseguia visualizar de forma organizada todos os conteúdos.


O mais importante: classificar a arquitetura te dá um norte para saber o que, de fato, padronizar no app. Você consegue criar roadmaps e fasear a sua entrega.


Eu optei em colocar tudo no Miro, num formato de board.


Confira a foto abaixo:

Do lado esquerdo, os conteúdos com suas classificações. Do lado direito, a arquitetura completa.

Matriz de Tom

A Matriz de Tom é uma metodologia bem importante para filtrar a voz e o tom de um app ou serviço. Você separa por espectros de tom. Dentro dos espectros, você encaixa personalidades e alguns sentimentos.


Existem várias formas de se utilizar (vale um artigo a parte). Na Daki, eu lia a frase/palavra e pontuava a voz e o sentimento. Fiz isso com todos os conteúdos.


O importante aqui é: o que seu app está falando? O que ele está transmitindo para os usuários? Assim, você consegue entender todo o espectro de palavras e o seu significado final.


Além disso, você compara com o modelo de negócios e se questiona: é isso que o meu app quer passar? Essa voz, tom e sentimentos faz sentido para o meu usuário final?


Se não fizer sentido, você pode recriar a matriz, pontuando o que o conteúdo deve transmitir. É meio complexo, eu sei, mas faz MUITO sentido utilizar essa metodologia quando você está conhecendo o conteúdo.

Confira um exemplo abaixo:

A Matriz de Tom e as pontuações dos conteúdos.

“Content Persona”

Para consolidar ainda mais o meu conteúdo, eu criei uma Content Persona.


A criação é bem simples:

1. Faço um bench de conteúdo (O que Dizem e Como Dizem) em aplicativos parecidos e nas lojas de aplicativo.

2. Filtro os padrões no bench.

3. Tento filtrar informações de CX referentes ao meu usuário (se não tiver essas informações, você pode utilizar o bench em comentário de loja de aplicativo, Reclame Aqui ou redes sociais).

4. Crio um guia de vocabulário e verbosidade, separando por Gíria e Jargão, Verbosidade em número e Barreiras de conteúdo.


Assim, consigo entender o que o meu usuário fala.


Confira a imagem abaixo:


Uma Content Persona, beeeem simples mesmo.

Estabelecendo princípios de conteúdo

Agora, pra consolidar a minha pesquisa, eu precisei estabelecer os princípios do meu sistema de conteúdo. Eu precisava definir quais caminhos eu iria seguir pra padronizar os meus textos.


Ponto de atenção: esta etapa é opcional, tá bom? Eu optei em seguir pra dar ainda mais embasamento para as minhas pesquisas e análises.


E para estabelecer, eu utilizei a famosa UX Writing Voice Chart. Existem inúmeras formas de se utilizar essa ferramenta. Basicamente ela funciona assim:


1. O que você quer passar com o seu conteúdo?

2. O que ele significa? 3. E quais são as regras?


Você pode fazer em grupo, ou sozinho. Depende do momento e do seu tempo.


Confira a imagem abaixo:

Este é um modelo da UX Writing Voice Chart. Simples de fazer. E beeeem importante.

Sistema de conteúdo criado

É isso! Após a UX Writing Voice Chart, eu evoluo os meus conteúdo de baixa fidelidade para alta fidelidade, com padronização e mais consistência. Neste caso, por não ter um Desgin System e por não ter acesso ao Figma, eu construí no Notion, tentando deixar de uma forma clara e simples para o time.

Como o sistema funciona no Notion.

E deu certo?

Será?

Depende da perspectiva. Vou explicar.


Content Design System, ou Content System, só funciona quando a estrutura de Design de uma empresa é minimamente madura. Quando falamos em maturidade de Design, vai além do sentido técnico. Estamos falando de: processos, cultura (pessoas) e ferramentas – basicamente os pilares de Design Ops, que precisam sair do escopo de Produto e ir para a alta liderança, entende? Quando os três pilares estão rachados ou não alcançaram a galera lá de cima, nenhum projeto permanece e tudo vai para o “porão”. Na Daki, durante o meu período (2022 – 2023), o time de Design era régua alta. Lá em cima. Time forte e MUITO consistente. Entretanto, a alta liderança estava muito afastada do time. O que isso ocasionava: muitas ideias e poucas iniciativas práticas. E com isso, não conseguíamos criar um Design System, mesmo com um profissional de UI.


Então, o Content System que eu criei, na minha opinião, foi mal documentado. Utilizar o Notion como uma forma de padronização de conteúdo, longe do Figma (e das bibliotecas e dos componentes), gera um projeto incompleto. O processo dele é beeem interessante, mas a execução para uma pessoa Product Designer é complicada, porque o objetivo do Content Design System é facilitar o dia a dia do time.


Mas, mesmo com todos esses problemas, o time gostou do projeto e utilizou bastante.