Cassio Almeida
© Cassio Almeida

ContentOps no Senac

Consultoria de projeção, estrutura, tático e estratégia de ContentOps em um contexto educacional

— Nome do projeto

Estruturar Content Ops


— Time

Cassio Almeida — UX Writer

(consultor de UX)


Érica de Oliveira — UX Writer

(consultora de UX)


Julia Renó — UX Writer (time de Design do Senac)


Fábio  Braga — Product Designer (time de Design do Senac)


Juliana Romão — UX Writer

(time de Design do Senac)


Lívia Velasco — UX Writer

(time de Design do Senac)


— Período

Trabalho temporário de 3 meses

Desafio:


Fomos convidados para montar uma estrutura de ContentOps para o time de UX Writing do Senac. Além de Ops, precisávamos entregar o Content Design System, com conteúdos padronizados e úteis para todos os designers. 


O principal desafio: reestruturar o time, descrever as funções de uma pessoa UX Writing, estabelecer processos, implementar cultura de design (com ritos, Design Thinking e uma pitada de metodologia ágil) e fortalecer o pilar Pessoas no time, com possíveis reestruturações de cargos, sistema de aprendizagem para designers e onboardings úteis.


Ah, importante: todas as pessoas do time ajudaram no projeto. Por mais que eu e a Érica tenham sido a consultoria, o projeto não tomaria forma sem a participação de todas as pessoas. Nosso UX Roadmap foi montado para que o time inteiro participasse de forma ativa.

Sobre o Senac

O Senac é uma das principais instituições de educação do Brasil.

A empresa contempla cursos presenciais e a distância, em diversas áreas do conhecimento, que vão da Formação Inicial e Continuada à Pós-graduação e permitem ao aluno planejar sua carreira profissional em uma perspectiva de educação continuada.


Processo preparatório

1.

Primeiro papo com o time


Conhecer o time e a estrutura, a primeira coisa de tudo — e a mais importante do processo. Quem são os Designers? O que eles fazem no Senac? Como eles trabalham? Qual é o conhecimento tático deles? Como eles chegaram no Senac? O que eles entendem de problemas na estrutura de design? O que eles sentem falta? Do que eles gostam? 


Fizemos essas e muitas outras perguntas para, de fato, entender o time. Aqui, o objetivo é concentrar todas as informações em um documento para estruturar as próximas etapas do projeto, adaptando para o contexto Senac e time de Design. 


A linha tênue entre o acerto e o erro, nesta etapa, é bem pequena. Não podíamos reutilizar processos ou simplesmente pegar um pronto e aplicar. O importante é adaptar e flexibilizar nosso projeto. E essa etapa faz exatamente isso.


Ferramentas que utilizamos:

- Análise de Stakeholders (framework para pontuar todas as pessoas e quem são elas em uma estrutura de Design)

- Quê? (é uma atividade de Desk Research interno para compilar links, squads e pessoas importantes — além da análise de stakeholder)

- Squad X: é, não é, faz, não faz (frame para compilar todas as squads de Design e o que elas fazem, compilando produtos e entregáveis)


Ponto de atenção: quando o projeto estava sendo estruturado, nós montamos um UX Roadmap macro, com ideias grandes e conceitos pré-definidos. Este projeto, em específico, seguiria um caminho diferente: integraríamos o time de Design em todas as etapas. Além dos entregáveis (ContentOps e Content Design System), precisaríamos "capacitar" o time a utilizar tudo, quase como uma mentoria. Mais um desafio pra conta.



As ferramentas. Importante: os frames foram desenhados pela Júlia Scucuglia, Product Designer, e pela Carolina Koury, Design Manager.

2.

Introdução à ferramentas de Design


Tá! Conhecemos o time e entendemos a maioria das dores. Compilamos e filtramos todas as informações, além de entender todos os perfis de design. O próximo passo: apresentar o que vamos utilizar de ferramenta e software durante todo o projeto.


Por que isso? Porque o time vai participar de forma ativa, então é nosso trabalho mostrar e apresentar as ferramentas de Design, além de compartilhar links de artigos e vídeos para mais informações. Queremos que todos estejam na mesma página, mas sem pressa.


Aqui foi um bate papo rápido, sem dinâmica ou atividades. E outra coisa importante: definimos nossas formas de documentação para o projeto.


Ferramentas que utilizamos durante todo o projeto:

Figma (durante todo o projeto — para documentação de fluxos)

Figjam (durante todo o projeto — para dinâmicas e documentação de projeto)

Trello (durante todo o projeto — para marcar atividades e kanban)

Notion (durante todo o projeto — para atualizar Roadmap e documentações formais do projeto, como contrato e entregáveis)

Maze (final do projeto — para pesquisa de Content Design System)

3.

Definição de problema


Antes de entrarmos no UX Roadmap, nós definimos o que é problema, o que não é problema, o que está ao nosso alcance e como vamos resolver ou ampliar as questões — por meio de Ops — do time.


Sem reuniões ou dinâmicas pesadas. Aqui nós compilamos todas as informações da primeira reunião, estudamos todos os links, analisamos os arquivos de Design e filtramos as informações da estrutura de design.


O principal problema: falta de organização no cotidiano do time. Todos entendem bem design, alguns já trabalharam em outros times e a maioria é curiosa e atenta ao mercado de design. Mas todo esse lado tático/prático não era aplicado no contexto Senac, por falta de tempo, processo e estratégia, principalmente. E por mais que exista o lado tático, ele não era visado em decisões de design — ou seja, algumas questões eram decididas no feeling. 


A estrutura de ContentOps, então, chegou para organizar o time, com processos, frames, aprimorar lado tático, aplicar estratégia (separar o que é estratégia e tático) e aplicar cultura de design, com reuniões e ferramentas para elevar a maturidade do design a médio a longo prazo.


Outra coisa, que é importante mencionar: o time de design utilizava o Adobe XD, ao invés do Figma. TODOS os documentos estavam desatualizados e bagunçados. Para algumas pessoas do time, foi a primeira vez que usaram o Figma, então precisamos fazer um mini tutorial de uso.


Técnicas utilizadas:

-> Análise heurística

-> Auditoria de Conteúdo



4.

UX Roadmap


O tão esperado roadmap. Tínhamos o escopo — pelo menos macro da empresa — bem definido, além dos problemas centralizados e algumas possíveis soluções, mas sempre preparados para mudar a rota, caso algo saísse do controle.


Para organizar, fizemos uma reunião para pautar os entregáveis, tempo útil e como faríamos para entregar tudo. Mudanças lá e cá, mas chegamos em uma conclusão.


O importante do UX Roadmap é entender o quanto de valor eu vou entregar para a empresa, além, claro, dos projetos. Entretanto, nós pensamos: como podemos evoluir design com os nossos entregáveis? Outra: como vamos entregar, com inteligência, projetos que precisam ser utilizados? Ou melhor: como vamos fazer com que estes projetos sejam eficientes para o dia a dia do time?


Tudo isso (e mais um pouco) precisa ser contemplado, senão o projeto iria afundar e tudo iria para um porão do Notion.


Utilizamos o Notion para centralizar nosso UX Roadmap.


Beleza! Agora estávamos prontos para começar os trabalhos, de fato.



O UX Roadmap no Notion. Armazenamos a organização do projeto lá. O time inteiro tinha familiaridade e facilitou o andamento do ContentOps

Construção de ContentOps no Senac

Para facilitar, um resumo do processo:


  • -> MVPOps (definição de estrutura e conceito)
  • -> Definição de Ops (significado de Ops em um tweet)
  • -> Estrutura de ContentOps (momento para definir os pilares que vão sustentar a área no time de Design)
  • -> Maturidade de Design (dinâmica para definirmos a maturidade do time e como vamos estabelecer o que é prioridade ou não)


O processo completo, em detalhes, está logo abaixo (ocultamos informações sensíveis sobre pessoas, dados de negócio e que podem prejudicar a empresa e o time).

1.

Definindo MVPOps


O primeiro passo: estabelecer, na empresa, o que é Ops. Entendemos que Ops tem inúmeros significados no mercado, mas temos o conceito principal: DesignOps trabalha com Processos, Pessoas e Ferramentas. Ou seja, queremos resolver — e entender — essas estruturas para compor valor para o negócio e para o time.


Mas cada empresa trata — e lida com isso — de uma forma diferente. Então, o primeiro passo foi entender o que é DesignOps no Senac e qual é o conceito para o time.


Fizemos, inicialmente, uma dinâmica de MVPOps, que é estruturar Valores, Missões, Responsabilidades, Limites e Afazeres iniciais. Foi ótimo para entender como o time pensa e quais são os entregáveis mais importantes para eles — claro, visando o objetivo de Negócio do Senac.


Sim, aqui foi jogo rápido, mas a dinâmica foi complexa e extremamente reflexiva, ainda mais quando falamos de estruturas que precisam ser construídas do zero.


Dinâmica de MVPOps. É uma forma interessante de concentrar as informações de papel, funções e afazeres de Ops.

2.

Definindo de ContentOps


O próximo passo parece ser simples, mas foi difícil. Precisávamos responder a uma pergunta: o que é ContentOps no Senac?

 

Depois de entender missões e valores, estruturamos, em um board simples, alguns cards para cada um digitar o que significa Ops no Senac.

 

A segunda etapa da definição: ler cada post-it. Cada um tinha sua percepção, mas o interessante é que existia similaridades táticas (de entregáveis) e estratégicas (de roadmap).


Depois, e por último, precisávamos definir em um tweet — baseado no que lemos. Cada pessoa deu sua opinião e fechamos nessa definição: 


ContentOps, no Senac, quer solucionar problemas de UX, elevando maturidade do time de conteúdo, com processos técnicos, cultura e ferramentas que aprimorem a atuação com outros times.


Até então, nossa primeira definição.


Ah, um adendo: durante todas as dinâmicas, nós passávamos links de artigos e vídeos para o time ir entendendo o que é Ops. Como falei acima, é importante que todos estejam na mesma página.




Do lado esquerdo, o que o time escreveu sobre o que é ContentOps no Senac. Do lado direito, a definição, unificando todas as opiniões e o que faz sentido para o momento atual do time.

3.

Estrutura e Pilares de ContentOps


Para definir a estrutura e os pilares, seguimos esse processo:

1. Estudar a fundo os problemas de Design do Senac;

2. Aprofundar o MVPOps (especificamente os entregáveis);

3. Entender as possibilidades de entrega (o que podemos e o que não podemos);

4. Limitações técnicas do time;

5. Gerenciamento de tempo do projeto.


O trabalho, aqui, foi meu e da Érica (da consultoria), sem apoio do time. Definimos 4 pilares:

1. Consolidação da prática de conteúdo;

2. Infraestrutura de conteúdo;

3. Aprendizados e crescimento;

4. Onboarding.


E cada pilar tem os seus "subgrupos" (confira a imagem abaixo).


Por que definir pilares é importante?

Porque isso conduz o conceito de Ops em uma empresa. Ou seja, existe um motivo e um objetivo para melhorar e aprimorar Design. Além disso: norteia ContentOps a entender as prioridades de um time e a apresentar Ops para stakeholders e lideranças.


Importante: existem outras maneiras de definir pilares. O caminho, para este projeto, foi em formato de dinâmica, para tentar, aos poucos, incluir a empresa no processo — sendo um dos critérios para esta consultoria acontecer.




4.

Maturidade de Design


A base de Ops estava praticamente pronta. Para embasar ainda mais as nossas informações e definições, precisávamos entender o nível de maturidade de design do Senac. Ou melhor: onde estamos e para onde queremos ir no Senac — pensando em técnica, maturação de área e entregáveis-chaves.


Para realizar tudo isso, estudamos alguns frameworks de maturidade e esbarramos em um bem interessante da Level up frameworks, feito pela VC e consultoria, Designer Fund.


Designer Fund é uma venture capital dedicada em investir somente em startups que foram fundadas por designers (como Stripe, Gusto, Abstract, Omada Health, AltSchool e outras). Eles utilizam a experiência que adquiriram ajudando essas empresas a escalarem seus negócios para criar materiais e serviços de consultoria sobre processos e desenvolvimento em design.


Este framework avalia a maturidade do time de design em seis áreas principais: Processos, Comunicação, Feedback, Desenvolvimento de carreira, Recrutamento e Infraestrutura.


Vale um artigo a parte só sobre esta dinâmica. Deixo um artigo de referência, da Nathalia, que utiliza o mesmo frame. Neste artigo, ela conta como foi o processo de construção de maturidade com o time de design: https://medium.com/cobli/encontrando-o-n%C3%ADvel-de-maturidade-do-time-de-design-level-up-framework-e3d994b4d806


Como nós aplicamos:


  1. 1. Identificação do nível individualmente
  2. Cada um lê cada tópico e entende/marca em qual nível de design o Senac está de forma individual — sem interferência. É o Designer e o framework.

  4. 2. Co-criar e compilar

Agora, em conjunto, lemos os tópicos e filtramos os mais importantes. O objetivo foi entender o que temos de mais complexo. Queríamos que o time falasse situações difíceis e que ainda não tinham uma solução.

->Ponto crucial: durante todas as atividades, a gente validava os entregáveis. Em Ops, buscamos consistência em todas as estruturas.

  1. Foi um momento de discussão sobre problemas. Depois, compilamos e organizamos os tópicos.


  1. 3. Identificação do nível atual
  2. A parte mais esperada: qual é o nível de maturidade de design do Senac? O esquema é bem simples: a gente comparou o que cada um colocou, de forma individual, identifica a maturidade e define. Para embasar ainda mais, a gente releu os tópicos e os post-its da etapa anterior.

  4. 4. Identificação do nível-alvo
  5. Depois de identificarmos o nível de maturidade que nosso time se encontra, voltamos ao framework para identificar, com base na descrição de cada um dos quatro níveis, qual seria nosso objetivo de nível para os próximos dois anos. Com base na projeção de crescimento do time (plano de contratação) e no plano para desenvolvimento de área, identificamos que estaríamos ainda no nível 02, entrando no nível

  7. 5. Identificando as melhorias e as iniciativas
  8. Nós sabíamos onde estávamos e onde queríamos ir, foi hora de compilar todas as melhorias que eram necessárias e importantes para o time. Nós compilamos todas as melhorias e reescrevemos cada melhoria no formato de How Might We (design sprint) para facilitar a identificação do foco do problema.

6. Evoluindo com UX Roadmap

Para consolidar ainda mais os entregáveis do time, fizemos uma Matriz de Impacto x Esforço para criar um UX Roadmap. Além disso, criamos um papel de liderança dentro do time, para que consiga acompanhar os processos e continuar o trabalho.

5.

  • Entregáveis do projeto

  • Vou listar e dar um resumo de cada, mas sem entrar em detalhes. O portfólio vai ficar gigante. Acredito que cada um vale um artigo à parte. Qualquer coisa, me procure, porque eu posso dar mais detalhes.


  • -> Base teórica de Design Thinking para UX Writer
  • Adaptamos o Double Diamond para o time entender o conceito e aplicar metodologias


  • -> Processos para o cotidiano de UX Writer
  • Criamos 3 tipos de processo para demandas e complexidades diferentes, adaptando para cada situação no Senac. Processo P, para demandas curtas e fáceis, que duram horas ou até 3 dias; Processo M, para demandas de média complexidade e tempo, que podem durar de 1 a 2 semanas; e Processos G, para projetos longos e complexos, que podem durar meses.

  • -> Biblioteca de framework
  • Compilamos algumas ferramentas de trabalho, para que o time consiga criar e embasar conteúdo, além de conduzir dinâmicas com outros times.

  • ->Diagrama de pesquisa
  • Adaptamos um diagrama criado pela Elisa Volpato de pesquisa, mas adaptado para UX Writing. Separamos metodologias e como o time pode utilizar nas demandas.

  • ->Diagrama de templates
  • Com o mesmo objetivo de pesquisa, separamos metodologias de UX Writing focando nos processos de trabalho. Funciona assim: o UX Writer entende em qual fase do Double Diamond está e consulta o diagrama para utilizar o framework correto.


->Content Design System

Sistema de padronização de conteúdo, idealizado para o time inteiro de design. O entregável é longo: mapeamos as inconsistências de conteúdo, entendemos a estrutura, definimos o que é arquitetura de informação e definimos o que vamos padronizar durante o projeto.

6.

  • Documentação e acompanhamento da consultoria


Documentamos a base de ContentOps no zeroheight. Lá, estruturamos todos os conteúdos para serem consultados e atualizados pelo time de UX Writing e Design do Senac. 


Separamos uma área de onboarding, explicação de uso sobre processos, vínculo de links para acessar uma área de ferramentas de UX Writing e outras coisas úteis e importantes para o time. Ou seja, a sustentação de Ops.


E para finalizar, um detalhe importante: para manter o projeto ativo, entendemos que seria importante criarmos um papel de Staff no time de UX Writing. Esse papel teria funções misturadas entre Pessoas e Especialista, resumindo: ver ContentOps, atualizar a parte tática, entender dores do time e começar um trabalho de liderança. 


Para o Senac, é algo extremamente novo, mas, felizmente, os stakeholders entenderam que isso ajudaria a dar mais consistência para ContentOps.


A criação do papel consistiu em:

- Escolher, com o time, a pessoa responsável;

- Dinâmicas de Papel (limites, começar a fazer, investimento e gerenciamento de tempo);

- Definição de Staff (separação de atividades entre Pessoa e Especialista com o time);

- Mentoria, da consultoria, com essa pessoa (mostrar mercado, salários, carreira, portfólio e cursos).


Deu certo a consultoria?

Pergunta difícil, mas eu sempre gosto de colocá-la no meu portfólio para mostrar se tudo o que foi criado funcionou, ou não.


A consultoria durou 3 meses, que foram intensos, com muitas reuniões, apresentações e flexibilizações, porque precisávamos integrar o time no projeto. A questão de integrar era: mentorear e apresentar a área de Design para o time. Tínhamos, então, dois objetivos: entregar o projeto e fazer com que o time entendesse tudo o que foi criado. Passávamos horas em reunião e voltávamos vários passos durante o projeto.


Adaptamos o UX Roadmap muitas vezes, porque entramos em um período complicado de demandas para o time, e não podíamos seguir sem a parceria de todos, então pausava o progresso. Faz parte.


Depois de tudo isso: sim, a consultoria deu certo. A entrega foi realizada e o time conseguiu seguir consolidando a área de Ops. Tivemos problemas, claro, mas essa entrega foi muito boa.


O time e a consultoria ficaram contentes com o projeto.