Você se lembra de quando ter um ótimo site era suficiente? Agora, as pessoas estão obtendo respostas da Siri, de trechos de pesquisa do Google e de aplicativos móveis, não apenas de nossos sites. Organizações com visão de futuro adotaram uma estratégia de conteúdo omnicanalcuja missão é atingir públicos em múltiplos canais e plataformas digitais.
Mas como configurar um sistema de gerenciamento de conteúdo (CMS) para atingir seu público agora e no futuro? Aprendi da maneira mais difícil que criar um modelo de conteúdo— uma definição de tipos de conteúdo, atributos e relacionamentos que permitem que pessoas e sistemas entendam o conteúdo — com meu pensamento de sistema de design mais familiar, viraria a estratégia de conteúdo omnicanal do meu cliente. Você pode evitar esse resultado criando modelos de conteúdo semânticos e que também conectem conteúdo relacionado.
Recentemente tive a oportunidade de liderar a implementação de CMS para uma empresa Fortune 500. O cliente ficou entusiasmado com os benefícios de uma estratégia de conteúdo omnicanal, incluindo reutilização de conteúdo, marketing multicanal e entrega de robôs – projetando conteúdo para ser inteligível para bots, painéis de conhecimento do Google, snippets e interfaces de usuário de voz.
Um modelo de conteúdo é uma base crítica para uma estratégia de conteúdo omnicanal e, para que nosso conteúdo seja compreendido por vários sistemas, o modelo necessário semântico tipos – tipos nomeados de acordo com seu significado em vez de sua apresentação. Nosso objetivo era permitir que os autores criassem conteúdo e o reutilizassem sempre que fosse relevante. Mas à medida que o projeto avançava, percebi que apoiar a reutilização de conteúdo na escala que meu cliente precisava exigia que toda a equipe reconhecesse um novo padrão.
Apesar de nossas melhores intenções, continuamos nos baseando naquilo com que estávamos mais familiarizados: sistemas de design. Ao contrário das estratégias de conteúdo focadas na web, uma estratégia de conteúdo omnicanal não pode contar com ferramentas WYSIWYG para design e layout. Nossa tendência de abordar o modelo de conteúdo com nosso pensamento familiar de sistema de design nos levou constantemente a nos afastar de um dos objetivos principais de um modelo de conteúdo: entregar conteúdo ao público em vários canais de marketing.
Dois princípios essenciais para um modelo de conteúdo eficaz
Precisávamos ajudar nossos designers, desenvolvedores e partes interessadas a entender que estávamos fazendo algo muito diferente de seus projetos web anteriores, onde era natural que todos pensassem no conteúdo como blocos de construção visuais que se encaixavam em layouts. A abordagem anterior não era apenas mais familiar, mas também mais intuitiva – pelo menos no início – porque fazia com que os designs parecessem mais tangíveis. Descobrimos dois princípios que ajudaram a equipe a entender como um modelo de conteúdo difere dos sistemas de design aos quais estávamos acostumados:
- Os modelos de conteúdo devem definir a semântica em vez do layout.
- E os modelos de conteúdo devem conectar conteúdos que pertencem um ao outro.
Modelos de conteúdo semântico
UM modelo de conteúdo semântico usa nomes de tipos e atributos que refletem o significado do conteúdo, não como ele será exibido. Por exemplo, em um modelo não semântico, as equipes podem criar tipos como provocações, blocos de mídiae cartões. Embora esses tipos possam facilitar o layout do conteúdo, eles não ajudam os canais de distribuição a compreender o significado do conteúdo, o que, por sua vez, abriria a porta para o conteúdo ser apresentado em cada canal de marketing. Em contraste, um modelo de conteúdo semântico usa nomes de tipo como produto, serviçoe depoimento para que cada canal de entrega possa entender o conteúdo e utilizá-lo como achar melhor.
Ao criar um modelo de conteúdo semântico, um ótimo lugar para começar é examinar os tipos e propriedades definidos pelo Schema.org, um recurso orientado pela comunidade para definições de tipos que são inteligíveis para plataformas como a pesquisa do Google.
Um modelo de conteúdo semântico tem vários benefícios:
- Mesmo que sua equipe não se importe com conteúdo omnicanal, um modelo de conteúdo semântico separa o conteúdo de sua apresentação para que as equipes possam evoluir o design do site sem a necessidade de refatorar seu conteúdo. Dessa forma, o conteúdo pode resistir a reformulações disruptivas do site.
- Um modelo de conteúdo semântico também oferece uma vantagem competitiva. Ao adicionar dados estruturados com base nos tipos e propriedades do Schema.org, um site pode fornecer dicas para ajudar o Google a entender o conteúdo, exibi-lo em snippets de pesquisa ou painéis de conhecimento e usá-lo para responder a perguntas dos usuários na interface de voz. Visitantes em potencial podem descobrir seu conteúdo sem nunca colocar os pés em seu site.
- Além desses benefícios práticos, você também precisará de um modelo de conteúdo semântico se quiser entregar conteúdo omnicanal. Para usar o mesmo conteúdo em vários canais de marketing, os canais de entrega precisam ser capazes de entendê-lo. Por exemplo, se o seu modelo de conteúdo fornecesse uma lista de perguntas e respostas, ele poderia ser facilmente renderizado em uma página de perguntas frequentes (FAQ), mas também poderia ser usado em uma interface de voz ou por um bot que responde a perguntas comuns.
Por exemplo, usar um modelo de conteúdo semântico para artigos, eventos, pessoas e locais permite Uma lista à parte fornecer dados estruturados de forma limpa para mecanismos de busca para que os usuários possam ler o conteúdo do site, nos painéis de conhecimento do Google e até mesmo com hipotéticas interfaces de voz no futuro.
Modelos de conteúdo que conectam
Depois de me esforçar para descrever o que constitui um bom modelo de conteúdo, percebi que os melhores modelos são aqueles que são semânticos e que também conectam componentes de conteúdo relacionados (como um par de perguntas e respostas de um item de FAQ), em vez de dividir conteúdo relacionado em componentes de conteúdo diferentes. Um bom modelo de conteúdo conecta o conteúdo que deve permanecer junto para que vários canais de entrega possam usá-lo sem a necessidade de primeiro juntar essas peças novamente.
Pense em escrever um artigo ou ensaio. O significado e a utilidade de um artigo dependem de suas partes serem mantidas juntas. Um dos títulos ou parágrafos seria significativo por si só, sem o contexto do artigo completo? Em nosso projeto, nosso pensamento familiar de sistema de design muitas vezes nos levou a querer criar modelos de conteúdo que dividiriam o conteúdo em partes distintas para se adequar ao layout centrado na web. Isso teve um impacto semelhante ao de um artigo que deveria ter sido separado do título. Como estávamos dividindo o conteúdo em partes independentes com base no layout, o conteúdo que pertencia um ao outro tornou-se difícil de gerenciar e quase impossível de ser compreendido por vários canais de entrega.
Para ilustrar, vejamos como a conexão de conteúdo relacionado se aplica a um cenário do mundo real. A equipe de design do nosso cliente apresentou um layout complexo para uma página de produto de software que incluía várias guias e seções. Nossos instintos foram seguir o exemplo do modelo de conteúdo. Não deveríamos tornar o mais fácil e flexível possível a adição de qualquer número de guias no futuro?
Como nossos instintos de sistema de design eram tão familiares, parecia que precisávamos de um tipo de conteúdo chamado “seção de guias” para que várias seções de guias pudessem ser adicionadas a uma página. Cada seção da guia exibiria vários tipos de conteúdo. Uma guia pode fornecer a visão geral do software ou suas especificações. Outra guia pode fornecer uma lista de recursos.
Nossa tendência de dividir o modelo de conteúdo em partes de “seções de abas” teria levado a um modelo desnecessariamente complexo e a uma experiência de edição complicada, e também teria criado conteúdo que não poderia ser compreendido por canais de entrega adicionais. Por exemplo, como outro sistema seria capaz de saber qual “seção de abas” se referia às especificações de um produto ou à sua lista de recursos – esse outro sistema teria que recorrer à contagem de seções de abas e blocos de conteúdo? Isso teria evitado que as guias fossem reordenadas e seria necessário adicionar lógica em todos os outros canais de entrega para interpretar o layout do sistema de design. Além disso, se o cliente não quisesse mais exibir esse conteúdo em um layout de aba, teria sido entediante migrar para um novo modelo de conteúdo para refletir o novo redesenho da página.
Tivemos um grande avanço quando descobrimos que nosso cliente tinha um propósito específico em mente para cada guia: ela revelaria informações específicas, como visão geral do produto de software, especificações, recursos relacionados e preços. Assim que a implementação começou, nossa tendência de focar no que é visual e familiar obscureceu a intenção dos designs. Com um pouco de pesquisa, não demorou muito para perceber que o conceito de guias não era relevante para o modelo de conteúdo. O significado do conteúdo que eles planejavam exibir nas guias era o que importava.
Na verdade, o cliente poderia ter decidido exibir esse conteúdo de uma maneira diferente – sem guias – em outro lugar. Essa constatação nos levou a definir tipos de conteúdo para o produto de software com base nos atributos significativos que o cliente desejava renderizar na web. Havia atributos semânticos óbvios como nome e descrição bem como atributos ricos como capturas de tela, requisitos de softwaree listas de recursos. As informações do produto do software permaneceram juntas porque não foram divididas em componentes separados, como “seções de guias”, derivadas da apresentação do conteúdo. Qualquer canal de distribuição – incluindo os futuros – poderia compreender e apresentar este conteúdo.
Conclusão
Neste projeto de marketing omnicanal, descobrimos que a melhor maneira de manter nosso modelo de conteúdo sob controle era garantir que ele fosse semântico (com nomes de tipos e atributos que refletissem o significado do conteúdo) e que manteve juntos o conteúdo que pertencia um ao outro (em vez de fragmentá-lo). Esses dois conceitos reduziram nossa tentação de moldar o modelo de conteúdo com base no design. Portanto, se você estiver trabalhando em um modelo de conteúdo para apoiar uma estratégia de conteúdo omnicanal – ou mesmo se quiser apenas ter certeza de que o Google e outras interfaces entendem seu conteúdo – lembre-se:
- Um sistema de design não é um modelo de conteúdo. Os membros da equipe podem ficar tentados a combiná-los e fazer com que seu modelo de conteúdo espelhe seu sistema de design, portanto, você deve proteger o valor semântico e a estrutura contextual da estratégia de conteúdo durante todo o processo de implementação. Isso permitirá que cada canal de entrega consuma o conteúdo sem a necessidade de um anel decodificador mágico.
- Se sua equipe está lutando para fazer essa transição, você ainda pode colher alguns dos benefícios usando dados estruturados baseados em Schema.org em seu site. Mesmo que canais de entrega adicionais não estejam no horizonte imediato, o benefício da otimização de mecanismos de busca é uma razão convincente por si só.
- Além disso, lembre à equipe que dissociar o modelo de conteúdo do design permitirá que eles atualizem os designs com mais facilidade, pois não serão prejudicados pelo custo das migrações de conteúdo. Eles serão capazes de criar novos designs sem o obstáculo da compatibilidade entre o design e o conteúdo, e estarão prontos para o próximo grande sucesso.
Ao defender rigorosamente esses princípios, você ajudará sua equipe a tratar o conteúdo da maneira que ele merece – como o ativo mais crítico na experiência do usuário e a melhor maneira de se conectar com seu público.
Credit Post By: by