Globo
2021
Do feed à curadoria: redesenho da plataforma de publicação de conteúdos Globo.
Conduzi o trabalho de UX de uma nova plataforma para publicar e organizar conteúdos com mais agilidade e flexibilidade. A solução entrou em produção com sucesso junto com a nova Globo.com, reduzindo o esforço operacional de publicação e aumentando a flexibilidade na distribuição dos conteúdos.
Contexto
O ecossistema digital da Globo usava dois sistemas CMS para publicar e distribuir conteúdos. O Feed, adotado por produtos como G1, GE e GShow, organizava as publicações em uma sequência contínua, com as mais recentes no topo. Alguns conteúdos podiam ser fixados em posições de destaque.Já o Pages, utilizado por produtos da Editora Globo, como o Valor Econômico, permitia montar layouts com mais flexibilidade por meio de templates. Em contrapartida, o editor precisava preparar as versões desktop e mobile em paralelo, o que tornava a operação mais trabalhosa.
Cada ferramenta fazia sentido para os produtos e contextos para os quais havia sido criada. Mas a nova versão da Globo.com trazia uma necessidade diferente: o portal teria um formato próprio em relação aos demais produtos da Família G. Para atendê-lo, o novo sistema precisaria combinar a agilidade do Feed com a flexibilidade de composição do Pages.
Desafio
Equilibrando as necessidades de tecnologia, produto e usuários.
Nenhum dos dois sistemas atendia plenamente às necessidades da Globo.com. Manter uma terceira ferramenta independente também significaria assumir custos de desenvolvimento, manutenção e operação para sistemas com a mesma finalidade.
A solução precisava atender às definições do produto Globo.com e, ao mesmo tempo, ter flexibilidade para ser adotada futuramente por outros produtos do ecossistema. Também precisava apoiar uma publicação mais ágil para os editores.
O que é um CMS e o que muda no modelo Headless
Um CMS permite criar, editar e publicar conteúdos em um site sem que seja necessário programar tudo do zero. Nele, é possível gerenciar textos, inserir imagens e vídeos, escolher temas e layouts e aplicar configurações automáticas.
No modelo tradicional, o CMS publica páginas completas. Em um Headless CMS, a interface usada pelo editor e a experiência final do produto funcionam de maneira independente. Assim, a atualização de um conteúdo isolado não exige a republicação da página inteira.
Nesse cenário, a experiência precisava conciliar três perspectivas: a solução proposta pela tecnologia, as definições do time de produto da Globo.com e as necessidades operacionais e os desejos dos editores.
Integração de soluções
A solução de UX deveria se adequar ao modelo Headless e pronta para operar até a data de lançamento da nova Globo.com.
Aderência aos Produtos
Deveria atender ao conceito e modelo operacional da Globo.com, podendo absorver os demais produtos do ecossistema.
Agilidade editorial
Deveria atender as necessidades operacionais dos editores e alavancar a agilidade do processo de publicação.
A pergunta que orientou o trabalho
O desafio era adaptar um modelo de publicação independente da composição visual da página à realidade editorial da Globo.
Como tornar um modelo de publicação linear, sem relação direta com a composição da interface, em uma ferramenta que permita ao editor compreender e antever como suas decisões serão representadas na experiência final?
Para responder a essa pergunta, o trabalho tinha três objetivos: integrar o sistema ao projeto Globo.com até a data prevista para o lançamento, permitir sua adoção por outros produtos do ecossistema e aumentar a agilidade dos editores na publicação.
Investigação
Unindo agilidade e flexibilidade na publicação de conteúdo
Começamos conversando com o time responsável pelo desenho da Globo.com para entender a experiência que o sistema precisaria alimentar. A página deveria funcionar como uma vitrine de curadoria, reunindo conteúdos relevantes de diferentes produtos.
A home seria organizada em áreas com funções editoriais próprias — como os destaques de notícias do G1, de esportes do GE e de entretenimento do GShow, além de trilhos de conteúdos especiais. Cada área teria uma capacidade definida de publicações.
O produto também deveria funcionar em diferentes dispositivos — mobile, desktop, smartwatches e smart TVs — e permitir que vários editores publicassem simultaneamente em diferentes áreas da home. Além disso, os editores precisariam fazer ajustes pontuais nos textos das chamadas e nas thumbnails.
Os principais usuários eram os editores, responsáveis pela curadoria e pela publicação. Eles trabalhavam com grandes volumes de informação e precisavam decidir rapidamente o que publicar, onde posicionar cada conteúdo, o que manter ou substituir e como organizar a página.
Para conhecer essa rotina, observamos editores trabalhando com o Feed e o Pages e conversamos com eles sobre seus fluxos de publicação, suas lógicas de trabalho e suas dificuldades.
O que aprendemos sobre as ferramentas existentes
O Feed organizava os posts de forma linear, em uma sequência que correspondia à apresentação dos conteúdos nos produtos atendidos. Como cada produto tinha sua própria linha editorial e um layout padronizado, o modelo funcionava bem para G1, GE e GShow. O feed era infinito, e os editores podiam gerenciar publicações até o terceiro grupo de posts revelado pelo botão ver mais.
O Pages funcionava como um construtor de páginas: o conteúdo estava ligado à forma como seria exibido. O editor escolhia um template e posicionava os conteúdos em áreas e componentes definidos. Esse modelo oferecia mais controle sobre a composição, mas também transferia para o editor tarefas de diagramação e ajustes de linhas órfãs e viúvas. Além disso, o resultado publicado nem sempre correspondia exatamente ao que havia sido montado no sistema, pois podia variar conforme o dispositivo usado pelo público.
O modelo Headless exigia uma gestão de conteúdo independente do visual do produto, em uma organização mais próxima de uma lista, como no Feed. Isso representava uma mudança para editores acostumados a trabalhar diretamente sobre a interface e atentos ao tratamento estético do layout. A nova Globo.com teria uma composição diferente dos demais produtos, mas o modelo Headless não previa um recurso de visualização prévia da página antes da publicação.
Essa combinação gerava inseguranças sobre a mudança na rotina, a publicação automática de cada novo conteúdo — em vez da republicação de páginas inteiras —, possíveis quebras de layout e a falta de preview da renderização.
Solução
Organizar a complexidade para apoiar decisões
A investigação mostrou que diferentes linhas editoriais precisariam coexistir na mesma experiência. Para trabalhar com elas, os editores precisavam localizar conteúdos de diferentes produtos, identificar rapidamente a área em que estavam, definir ou alterar posições, editar títulos, subtítulos, thumbnails e chamadas, além de excluir, substituir ou fixar publicações.
Também precisavam reconhecer o tipo de matéria e o estado da publicação, enquanto organizavam grandes volumes de informação e decidiam o que merecia destaque.
Uma linguagem visual para orientar a operação
Cada conteúdo precisava deixar claro o que era, onde estava e como se relacionava com os demais. Por isso, definimos formas de tornar reconhecíveis a área editorial, a posição do conteúdo, sua hierarquia, as ações disponíveis e seu estado de publicação.
A organização visual se apoiou em três recursos:
Cor: blocos contrastantes identificavam grupos de informação, como áreas, produtos e conjuntos de posts.
Números: indicavam a ordem e a posição dos posts dentro de cada área.
Tamanho e indentação: ajudavam a perceber a hierarquia entre conteúdos principais e conteúdos relacionados ou aninhados.
Três estruturas de conteúdos
Cada metatipo reunia os dados necessários para representar um conteúdo sem depender do produto que o consumiria. A estrutura precisava comportar diferentes combinações de dados e permitir que cada produto a utilizasse e personalizasse conforme suas necessidades.
Foram definidos três modelos principais que também podiam ser combinados dentro de uma mesma área:
Principal: um post simples e único.
Agregado: um post principal acompanhado por um ou mais posts relacionados, aninhados abaixo dele e com menor destaque.
Grupo: um contêiner que reunia posts sem diferenciá-los hierarquicamente, como em um carrossel.
Ajustes feitos a partir dos testes com editores
Inserir conteúdo no lugar certo
Na primeira versão testada, o editor adicionava conteúdo por meio de um botão flutuante lateral e, depois, escolhia o tipo de componente. Nos testes, percebemos que a posição do botão exigia esforço extra dos usuários, predominantemente destros, e não deixava claro onde o conteúdo seria inserido.
Ajustamos a interação para posicionar os controles entre os conteúdos. Assim, o local da ação também indicava onde o novo item entraria. Separamos ainda o componente individual, mais utilizado, dos demais tipos de componente.
Identificar áreas, tipos e estados
As cores ocupavam inicialmente uma área mais discreta. Os testes indicaram que torná-las mais visíveis ajudaria os editores a localizar e percorrer as áreas com mais facilidade. Elas também passaram a diferenciar estados de publicação, como rascunho e publicado, e tipos de conteúdo, como ao vivo e urgente.
Encontrar e reorganizar publicações
À medida que a lista crescia, encontrar e reorganizar uma publicação específica se tornava trabalhoso, uma dificuldade relatada pelos editores. Como eles precisavam localizar conteúdos para editar, substituir ou excluir, incorporamos busca e filtros, que reduziam as informações exibidas de acordo com a tarefa.
Os editores também relataram que mudar um conteúdo de área podia exigir muitos cliques ou ser difícil por meio de arrastar e soltar, especialmente em listas extensas. Por isso, além do recurso de drag and drop, incluímos a possibilidade de mudar rapidamente a área pela tag colorida com seu nome. A posição também podia ser alterada pelo número correspondente.
A área chamada “rascunho” permitia manter o post despublicado enquanto o editor trabalhava nele. Isso era útil para edições mais drásticas, pois permitia tomar decisões pontuais com mais tranquilidade, sem que o conteúdo fosse republicado automaticamente durante a manipulação.
Para reduzir o espaço ocupado pela lista e o tamanho da rolagem, adicionamos a opção de recolher as áreas por meio de um botão ao lado da busca.
Uma oportunidade que se tornou uma iniciativa própria
Durante o projeto e as conversas com os editores, identificamos uma oportunidade de funcionalidade que teve boa recepção da gestão e dos próprios editores. Implementada após o primeiro lançamento, ela se tornou uma iniciativa independente, com um time dedicado a estender seu conceito a outros sistemas da plataforma.
O Smart Publishing | CMS Analytics apresentava, de forma simplificada e em tempo real, dados importantes para apoiar as decisões dos editores sobre o ciclo de vida do conteúdo: sua permanência no portal, movimentação ou substituição.
Resultados
Uma solução em produção
O novo sistema e a nova Globo.com entraram em produção com sucesso na noite de 13 de agosto de 2021. A solução ofereceu a flexibilidade necessária para diferentes produtos e contextos de consumo e deu aos editores mais agilidade na publicação, com menos esforço.
Como se tratava de uma ferramenta de trabalho complexa e proprietária, já esperávamos uma curva de aprendizado e a necessidade de adaptação e treinamento. O objetivo dos testes não era eliminar a necessidade de onboarding, mas identificar complexidades que a interface pudesse evitar. Esse objetivo também foi alcançado.
O principal limite identificado
A impossibilidade técnica de oferecer um preview foi o aspecto menos satisfatório do projeto. Sem essa visualização, os editores sentiram frustração diante de suas preocupações com o layout e a estética da página.
Nossa principal hipótese era que o desconforto com a falta de controle sobre a apresentação final estava ligado a hábitos construídos ao longo dos anos, em contato com ferramentas e modelos de trabalho que exigiam esse cuidado. Também reconhecemos o senso estético dos profissionais, sua afeição pelos produtos com que trabalham e o desejo genuíno de realizar cada tarefa com atenção aos detalhes.
Como designer, considero essas características positivas. Ainda assim, o modelo Headless tinha uma limitação técnica e conceitual que impedia atender a esse desejo específico dos editores. Essa foi a única insatisfação identificada no projeto como um todo.
A plataforma continuou evoluindo, incorporando melhorias e desenvolvendo os potenciais do sistema.
Papel
Minha contribuição e o que levo do projeto
Comecei o projeto como Senior UX Designer e assumi a posição de Lead ao final. As decisões foram construídas em conjunto com um time formado por um PO, aproximadamente sete desenvolvedores e três UX Designers.
O PO era responsável pelas decisões de gestão e plataforma; o tech lead, pelas decisões de desenvolvimento; e eu, pelas decisões de UX. Além de projetar, coordenei e orientei as demais designers ao longo do projeto.
Minha atuação incluiu:
definir e evoluir o modelo de interação;
tomar decisões de UX de maior impacto;
trabalhar na arquitetura da informação, nos fluxos, nas jornadas e na prototipação;
planejar e acompanhar os testes;
analisar aprendizados e refinar a solução;
orientar e apoiar o time de Design;
trabalhar em parceria com o PO e iterar com o time de desenvolvimento;
apoiar negociações, estratégia e comunicação entre áreas.
Este projeto não foi sobre encontrar uma solução perfeita para uma ferramenta complexa. Foi sobre lidar com restrições inerentes ao sistema e com obstáculos que só aparecem durante o processo. Mesmo diante de decisões de negócio e dos limites de compreensão das abordagens e técnicas de desenvolvimento, conseguimos superar dúvidas e entregar uma solução alinhada às necessidades e aos processos de trabalho dos editores.
O principal aprendizado foi que era possível absorver parte da complexidade e transformá-la em uma experiência de operação previsível. A solução atingiu as expectativas e metas propostas e se mostrou um terreno fértil para novas iniciativas e caminhos de evolução da plataforma.