Sistema de gestão de conteúdo - Ideação

Depois do Coda Bootcamp, fiz a minha inscrição para o Coda Doctorate, que é a fase com conteúdo mais avançado sobre o Coda. Mas, a melhor parte, é que ele é muito focado em resolução de problemas. Pensar no objetivo do documento é mais importante do que a construção do documento em si e isso muitas vezes é subestimado.

Neste post, vou falar sobre as fases de ideação do projeto final do curso e comentar sobre alguns exercícios propostos.

Caso esteja interessado em entender como o documento funciona, mas não quer ver sobre todo o processo de construção, recomendo que você vá direto para o guia do documento.

Etapas do curso

Assim como na fase anterior, o Coda Doctorate finalizava com um projeto de conclusão de curso. A diferença é que ele foi sendo construído conforme o curso avançava. A cada aula, era preciso fazer uma ideação, que seguiu as seguintes fases:

• Proposta e premissa
• Banco de dados e organização
• Design e funcionalidade
• Operacionalização do negócio
• Revisão

Proposta e premissa

Para definir a proposta do documento, foi necessário responder algumas perguntas que serviram como guia para essa fase. As principais eram sobre quem o usaria e porquê.

Quando pensei nesse documento, quis fazer algo que resolvesse um problema meu. Assim, teria certeza que pelo menos uma pessoa estaria usando o material. Por isso, a minha intenção foi criar um sistema que ajude pessoas que precisam se organizar no momento de produzir conteúdo para múltiplas plataformas. Além disso, também defini que o público-alvo é o de pessoas que produzem conteúdo em texto.

Foi preciso definir nesse momento quais seriam as 3 principais funcionalidades do documento. Eis as que defini:

1. Calendário de publicação
2. Fluxo para escrita e revisão de texto
3. Status e lembretes para a produção de conteúdo

Acredito que, dos pontos listados, apenas o terceiro não foi atendido na totalidade. E, avaliando de forma geral o que eu estava propondo, cheguei à conclusão de que estava construindo um sistema de gestão de conteúdo.

Banco de dados e organização

Para o banco de dados, a estratégia foi criar uma tabela principal com os conteúdos, que são os itens principais do documento. E, a partir da tabela principal, criei algumas auxiliares para conseguir fazer a estrutura mais enxuta possível.

Na versão final, o documento ficou com 5 tabelas:

1. Conteúdos: principal dado do documento, praticamente todas as outras tabelas são relacionadas com ela
2. Status: tabela utilizada como uma lookup column dentro da coluna “Status” da tabela “Conteúdos”
3. Tipos: também utilizada como uma lookup column em “Conteúdos”, essa tabela permite selecionar um tipo de conteúdo e cadastrar um template para esse tipo
4. Categorias: mais uma lookup column de “Conteúdos”, que possui as categorias dos conteúdos
5. Referências: a única tabela que não possui ligação com a tabela “Conteúdos”. Ela reúne todas as referências armazenadas para apoio na produção de conteúdos

Lookup columns são colunas preenchidas com valores vindos de outras tabelas. No exemplo do documento, caso eu queira ter um novo status para o conteúdo, basta eu adicioná-lo na tabela “Status” que ele estará disponível para seleção dentro de “Conteúdos”. Outra vantagem é a possibilidade de incluir mais informações para o item selecionado, ou seja, o meu status pode ter um nome e um resumo, por exemplo. Mais informações sobre como usar esse tipo de coluna podem ser encontradas na documentação oficial.

Da forma que o banco de dados está desenhado, é esperado que apenas as tabelas “Conteúdos” e “Referências” cresçam indefinidamente. Porque a partir do momento em que se configuram os status, tipos e categorias dos conteúdos é normal que eles permaneçam com os mesmos dados ao longo do tempo.

Design e funcionalidade

Nesta etapa, foi preciso definir o que eu gostaria de comunicar para o usuário com esse documento. Foi usado um framework chamado “Know, Feel, Do, WhatDo” para guiar essa parte:

• Know: o que eu quero que o usuário saiba?
• Feel: o que eu quero que o usuário sinta?
• Do: o que eu quero que o usuário faça?
• WhatDo: quando o usuário abrir o documento, ele saberá o que fazer?

Pensando no documento que gostaria de construir, essas foram as minhas respostas:

• Know: eu quero que o usuário saiba que o conteúdo estará bem organizado
• Feel: eu quero que o usuário se sinta seguro com o cronograma de publicação de conteúdo
• Do: eu quero que o usuário planeje e escreva todo o conteúdo em um único documento
• WhatDo: eu vou criar um guia para ensiná-lo a utilizar o documento

Além dessas perguntas, também foi preciso preencher um checklist em que eu deveria marcar algumas atividades como revisar as cores, fontes e organização do documento. Porque não basta um documento ser útil se ninguém entende a sua real utilidade.

Nessa etapa, também foi o momento de pensar se eu deixaria claro como eu resolveria o problema do usuário. Particularmente, foi uma etapa bem importante para o meu planejamento. Costumo ser um pouco prolixa explicando algo que criei e essa é uma característica que prejudica o entendimento.

Operacionalização do negócio

A última etapa do curso serviu para explicar como os documentos no Coda podem ser monetizados e qual é a hierarquia de um workspace.

Também foi feita a introdução do Pack Studio, que é o ambiente do Coda para construir packs. Combinar a criação de documentos com a implementação de packs amplia e muito o leque de possibilidades dentro do Coda. Por isso, essa etapa foi uma das que eu considerei as mais importantes no aprendizado de tópicos avançados.

Depois de ter feito os exercícios sobre packs, decidi que iria criar o meu próprio pack para poder commitar os conteúdos produzidos no documento dentro de um repositório com um projeto do Jekyll no GitLab. Super específico, mas que resolve uma dor que eu sentia a cada publicação aqui no blog.

No futuro, pretendo escrever sobre como criar packs no Coda e vou dedicar um post exclusivo para o funcionamento e implementação do pack que criei para o documento do Coda Doctorate.

Revisão

Na última semana do curso, o foco foi em revisar o documento. Mas, assim como nas semanas anteriores, essa revisão também foi guiada.

A ideia aqui era entender se existe uma forma mais simples de resolver o problema apresentado, verificar se o banco de dados está usando os relacionamentos de forma correta e, principalmente, se está entregando a proposta inicial.

Outra preocupação era a velocidade do documento. Criar estruturas complexas dentro do Coda faz com que a experiência do usuário seja muito prejudicada na performance. Por isso, também foram apresentadas soluções de design e ferramentas que apoiam na otimização de documentos lentos.

Por mais que o documento do Coda Doctorate tenha sido bem mais complexo de se construir do que o documento do Coda Bootcamp, o formato guiado a cada semana facilitou muito. Apesar de iniciar com soluções complexas, os frameworks e ferramentas apresentados foram refinando o documento e transformaram o sistema de gestão de conteúdos em um produto muito mais simples do que o pensado inicialmente.

Pretendo escrever mais um ou dois posts sobre a construção do documento em si, mostrando quais componentes e soluções foram utilizadas. Mas espero que mostrar as etapas de ideação já tenha sido esclarecedor o suficiente a respeito da lógica que segui para construir o documento que estou utilizando atualmente para gerenciar a produção de conteúdo do blog e da newsletter.

Até a próxima!

Copiar link