Componentes de Conteúdo: como o time de Content Design se comunica no Figma
Ana Lais
Jessica NascimentoComo desenvolvemos componentes de suporte pra melhorar a comunicação entre times e fortalecer a presença de Content Design nos projetos.
Quem escreve pra produtos digitais sabe que a profissão de UX Writing ou Design de Conteúdo ainda está conquistando seu espaço. Mesmo aqui no iFood, onde temos um time de pessoas com essa especialidade, é comum que precisemos explicar bem qual é o nosso papel.
Boa parte do nosso trabalho é realizado em ferramentas de Design como Figma, FigJam, Miro e tantas outras. No entanto, não “desenhamos” telas. Usamos essas ferramentas pra esboçar e construir experiências únicas através de palavras.
Os momentos de cocriação e exploração de conteúdo podem (e devem) estar documentados nessas ferramentas. Assim, facilitamos a comunicação e damos mais visibilidade para o trabalho de Content. A boa notícia é que a maneira que encontramos pra fazer isso aqui no iFood tem dado super certo!
Por isso, as Content Designers Ana Lais e Jessica Nascimento, responsáveis pela criação dos componentes de suporte no Figma, vão compartilhar essa receitinha de bolo com você! ????
O que nos trouxe até aqui (spoiler alert: dores de cabeça)
Aqui, preciso contar sobre nossa realidade no início de 2021, quando esta ideia surgiu.
Nesse passado distante, as preocupações em garantir que a comunicação assíncrona funcionasse da melhor maneira já faziam parte do dia a dia. Ou melhor, estavam mais vivas do que nunca!
O time de Content Design era formado por 11 pessoas que acompanhavam diversas squads responsáveis pela experiência de quem compra, vende ou entrega pelo iFood. Muito desse trabalho era realizado em conjunto com Product Designers no Figma – seja colaborando na construção de jornadas, seja sugerindo ajustes e melhorias de conteúdo.
Ainda que cada projeto tivesse suas particularidades e, muitas vezes, formas de organizar o Figma de maneiras diferentes, o contexto de Content Design não mudava muito. Tínhamos dores e desafios que eram comuns.
Por exemplo, frequentemente me deparava com perguntinhas que me tiravam o sono:
- Como identificar os fluxos no Figma em que Content Designers já haviam trabalhado?
- Ou saber rapidamente qual é o status do trabalho (se ainda não foi iniciado, está sendo construído ou foi finalizado)?
- E garantir que o time de Tecnologia tenha acesso às telas corretas, com os textos validados?
Ao levar essas questões pra nossa liderança, percebi que não tínhamos meios eficazes de respondê-las. Além disso, quase todo legado de Content era guardado na memória de apenas algumas pessoas, em um time que crescia cada vez mais.
Precisávamos de uma maneira de registrar, padronizar e dar mais destaque para o nosso trabalho.
Fica, vai ter bolo: os primeiros Componentes de Conteúdo
A primeira ideia foi trabalhar com tags, que poderiam ser usadas pra indicar o andamento do nosso trabalho em cada tela ou fluxo criado na ferramenta. Como seriam usados apenas pelo nosso time, sugeri o nome de Content Status e criei 3 versões bem simples:
- Aguardando revisão;
- Em andamento;
- Revisado.
Mas, faltavam ainda alguns ingredientes…
Não demorou muito pra perceber que as necessidades do time eram um pouquinho mais complexas. Surgiram novas perguntas:
- Como ter certeza da data em que as alterações de texto foram feitas?
- Será que dá pra manter um histórico do trabalho de Content Design?
- Como sinalizar pequenos ajustes feitos em uma mesma versão do fluxo?
- Ou descobrir quem é a pessoa responsável pela parte textual do projeto?
Então, com a ajuda de designers maravilhosos como o Josias, nosso mago do Design System & Ops, percebemos que seria interessante incluir mais informações, como:
- Nome e foto da pessoa de Content responsável pelo trabalho;
- Data na tag “Revisado”, que passou a ser “Revisado em dd/mm/aa”.
E, aproveitando o engajamento, dar uma repaginada no visual.
Aplicação da 2ª versão das tags
Os primeiros resultados foram excelentes! O time não teve dificuldades em usar as tags e, pra nossa surpresa, recebemos muitos feedbacks positivos de todo o time de Design. Além disso, algumas squads passaram a adotar tags semelhantes por conta própria, pra acompanhar o trabalho de Product Designers ou do time de Desenvolvimento, por exemplo.
Dessa maneira, a comunicação assíncrona de todas as pessoas envolvidas no projeto ficou bem mais descomplicada.
Pré-aquecendo o forno pro refinamento dos Componentes
Sempre que começava um fluxo, eu cravava o componente no Figma, como uma bandeira que sinaliza um território conquistado por Content. Mas, mesmo nos projetos em que participava desde o início e tinha proximidade com os times, sentia que a atuação de Content era pouco vista por quem não fosse Product Designer…
E, como quase ninguém lia os comentários no Figma, às vezes tinha que explicar a mesma coisa pra várias pessoas que acessavam o fluxo. Então, além do componente com o status, comecei a usar caixas com informações importantes para o time. Ali eu colocava coisas como:
- Pesquisas consultadas
- Decisões de conteúdo mais detalhadas
- Dúvidas e pendências
- Explicações sobre alterações na jornada
- dentre outras coisas.
Essas caixinhas facilitavam a comunicação com o time de Desenvolvimento, pessoas novas e stakeholders, além de simplificar a validação assíncrona.
Depois de pesquisar fluxos de outras Content Designers do time, pra entender como se comunicavam no Figma, comecei a planejar a evolução do componente.
Após conversar com a Ana, fiz uma pequena apresentação e a ideia foi abraçada e enriquecida pelo time de Design de Conteúdo.
Mais uma vez, Josias entrou em cena. Expliquei o plano e deixei o homem trabalhar, trazendo seu conhecimento técnico e toque de mestre de Design System e Ops.
As cerejas do bolo: nossos Componentes de Conteúdo
1. Content status
Este componente manteve-se fiel ao que idealizamos na primeira versão, mas decidimos fazer uma alteração importante nas tags: não usaríamos mais a palavra “revisão”.
O toque final foi adotar um novo layout e adicionar um “estado neutro”, onde a tag é direcionada pra todo time de Content Design e não a uma pessoa, especificamente.
Quando alguém coloca o componente no arquivo do Figma, pode procurar o nome da pessoa responsável (e a foto dela irá aparecer) e selecionar um dos 4 status.
2. Content Box
Caixa de informações: incluímos observações e listas de forma personalizada.
Esta caixinha pode ser usada de diferentes formas: podemos manter apenas o título, ou título e observações, ou título e seleção de entregáveis, ou título e print… São muitas possibilidades!
Podemos usar setas pra direcionar a informação, ou incluir uma Content Box no final do fluxo pra listar o que for mais importante, por exemplo.
É um componente super versátil que facilita a documentação.
3. Content Header
Header: damos mais contexto sobre a tarefa, como datas e pessoas envolvidas.
Por fim, este componente serve pra destacar fluxos, telas ou wireframes.
Sua principal função é dar visibilidade dos prazos da tarefa. Assim, qualquer pessoa que acessar o arquivo poderá consultar rapidamente quando a demanda foi solicitada, quando começou a ser feita e quando deve ser entregue.
Também é possível personalizar detalhes, como adicionar apenas a data de solicitação, citar outras pessoas envolvidas na tarefa ou simplesmente destacar quem é a pessoa de Content responsável por várias telas.
Um bolinho com sabor de sucesso compartilhado
A aplicação desses e outros componentes é um processo oficial do time de Content do iFood. Toda pessoa nova recebe seus assets personalizados e já pode começar a usar!
Não consideramos o uso obrigatório de todos eles, pois sabemos que cada tarefa tem as suas próprias necessidades. Aliás, por isso mesmo, esses componentes estão em evolução constante!
Afinal, ao trabalhar com Design, aprendemos que (quase nunca) existe uma versão final. ????
Agradecimentos: ao time de Content Design, que abraçou a ideia e se comprometeu a “levar a palavra de Content” em todo projeto. E, em especial, ao Josias Cunha, hoje Design System Manager.
