Mini guia honesto para designers solitários.
Muito se associa à aplicação ou à existência de DesignOps apenas em grandes equipes. Porém, se você leu meus artigos, talvez tenha uma ideia de que não é bem assim que a banda toca. Você pode ter 10 designers em um time e ainda sim não exercer nada em DesignOps.
Mas sejamos realistas, não é difícil encontrar pelo mercado as queridas euquipes: “times de design” de uma pessoa só — e este artigo é dedicado a elas.
Como aplicar DesignOps como única pessoa designer da equipe?
Contexto
Eu mesma voltei a ser uma euquipe recentemente, mais uma vez experimentando exercer a complexidade da disciplina como única Product Designer de um produto. Está sendo muito interessante e ao mesmo tempo caótico; e essa frase, por si só, resume a essência de DesignOps.
Ideal? Convenhamos que não é mesmo. É trabalhoso. Gerir uma operação e ao mesmo tempo operar não é o cenário ideal. Dá para trabalhar DesignOps, dá, mas não vai dar sempre. Seu squad quer que você entregue o que precisa entregar e paciência. O maior desafio é equilibrar esses pratos entre a pessoa gestora da operação e a operadora. Por isso, em grande parte das vezes, é caótico mesmo.
“Mas não sou liderança…” — Se você é a única pessoa designer do time, é você quem protagoniza esse tema no squad. Você é a referência, a responsabilidade é sua.
O papel de liderança não necessariamente tem títulos por premissa (vulgo ter Lead no nome do seu cargo). Também existe pelo contexto, como liderar um projeto específico, uma frente específica. É importante termos isso em mente. Combinado?
Vamos ao que interessa.
1. Configure o ambiente
Por enquanto, não venda DesignOps; mostre DesignOps.
As pessoas ainda resumem a área de design de produto em fazer tela. É tela pra cá, tela pra lá… Então se você vem com um termo bonito desses sem estruturar nada, tem chance das pessoas verem como uma sopa de letrinha, fingir que entendeu e ignorar. Então tenha calma.
Dito isso, crie a sustentação da sua operação de design no seu cantinho.
Isso envolve definir coisas que provavelmente você já faz e outras mais:
- Usarei Figma? Quais outras ferramentas usarei no trabalho? Quais ferramentas a empresa usa?Onde ficará a documentação? Como será a manutenção disso? Quem terá acesso?Como será a estrutura dos arquivos? Páginas, seções? Defino templates? Tenho modelos prontos ou preciso criar?Como será o meu processo? A empresa já tem um? Quais as expectativas? Opto por um framework, desenho um eu mesma?
No final do artigo deixarei alguns materiais para auxiliar nessas definições também.
E por que isso é importante? Primeiramente porque você precisa, rs. São coisas que possuem uso imediato na sua atuação. E não deixam de ser coisas de Ops.
Mas você não pode simplesmente organizar tudo para uso de muito curto prazo. Um dos princípios é pensar em escala.
Se você define suas coisas para uso só imediato, você sempre estará configurando o ambiente em vez de focar mais em operar ou ampliar o que mais é preciso. E aí você não está otimizando seu trabalho. Isso significa que a qualidade em Ops está baixa.
Porém você também não pode querer resolver o mundo de uma vez. E isso tem tudo a ver com o próximo tópico.
2. Não linear é mandatório
Configurar o ambiente de vez, logo de cara, é improvável. Tampouco será feito em uma ordem específica. Você pode até tentar fazer em uma sequência, mas, como eu disse, você é gestora & operadora. Ambas as posições estão interligadas, mas nem sempre evoluem lado a lado.
E operar é importante — é seu trabalho também, afinal — e é disso que saem os insumos para fundamentar seus pontos de evolução em Ops. Quando as pessoas começam a ver seu trabalho baseado nesses princípios, isso demonstra a estrutura do seu craft, mostra a sua maturidade como profissional. E pode ser que você não citou o termo DesignOps em nenhum momento para isso.
Crie uma rotina no seu trabalho para olhar pro tema
Defina uma recorrência: uma vez na semana, a cada quinze dias, para olhar para sua operação de cima, para sair da posição de operadora. Revise suas tarefas voltadas a Ops — e se não tiver, crie um board/quadro focado nisso, popule esse backlog, comece a se organizar.
Eu particularmente possuo uma tarefa diária na minha agenda de olhar tanto o board do time quanto o meu próprio board. Há vezes que só vou olhar mesmo e não fazer nada. Mas ao menos relembro que tem questões ali que quero trabalhar e reflito como intercalar nas demandas sem causar atrito com o que já me comprometi.
Nesses momentos com o olhar ao horizonte, analise se é possível retomar ou adiantar algo, inclusive até se alguma demanda faz sentido incluir na esteira oficial do time. Nem sempre DesignOps pode ocorrer em paralelo. Algumas coisas de fato precisarão de maior esforço para serem resolvidas, demanda tempo, então mostre isso, deixe seus colegas a par da importância.
Mas é importante ter em mente que talvez você só volte a uma tarefa específica de Ops depois de dias, talvez meses. E paciência, acontece. Portanto, anote e documente bem enquanto estiver focada nisso, pois ajudará a retomar futuramente.
3. Jogo rápido, ganho rápido
Tenha um olhar crítico para o momento atual da sua operação. Existe algo que está pegando fogo, gerando muito atrito? É algo que precisa mapear para estudar ou pode focar em resolver imediatamente? Esteja atenta ao timing das coisas.
Não adianta mapear N questões para trabalhar em Ops, seja estudar melhor seu público, mapear testes paralelos, ampliar o UI Kit ou cacetadas, se o pessoal de desenvolvimento está tendo muitas dúvidas sobre as suas entregas, por exemplo. O que grita ali? Talvez uma reestruturação na documentação de handoff, talvez interagir mais com esses colegas.
Talvez seu time, ou cliente por exemplo, esteja muito aflito com algum ponto das jornadas que você ia trabalhar em um momento posterior. Será que não é melhor adiantar isso? Será que o formato da apresentação não precisa ser aprimorado? Será que faz sentido um alinhamento só para isso, torná-lo talvez recorrente? O que você consegue propor de imediato?
Resolver questões do tipo tendem a trazer os melhores insumos para mostrar a relevância de aplicar DesignOps. Você está resolvendo problemas existentes. O horizonte não pode ser só ao futuro, precisa ser amplo e atual também. Soluções rápidas podem trazer mais impacto do que algo robusto.
4. Acompanhe e reflita como medir
Diria este tópico ser o mais gigantesco elefante da sala. Como saber se a minha sustentação de DesignOps está fazendo sentido?
1º: Olhar às suas entregas
- Em quanto tempo você conclui suas tarefas?Quais entregáveis possuem mais dificuldade para realizar?Quantas tarefas ainda estão em backlog? Você está estruturando seu backlog de fato?Quais tarefas tendem a ultrapassar prazos de entrega? Por quê? Isso te envolve ou envolve terceiros?Suas tarefas estão claras tanto para você quanto para o time?Quais entregas tem voltado com mais iterações, ajustes, solicitações?
Isso tudo reflete em processos que talvez você precise melhorar ou ampliar. Ou talvez tópicos ou temas que precise se aprofundar do ponto de vista técnico de design, até do produto, do negócio, do contexto, da estrutura da empresa, etc.
2º: Acompanhar a própria evolução do produto
- Como está sendo a experiência? Temos indicadores? Podemos definir indicadores? Quais ferramentas podem ser utilizadas?Que indicadores e/ou métricas posso acompanhar para medir a qualidade da UX?Como está o histórico disso? Se fiz novas entregas em soluções já existentes, qual o comparativo entre o que estava antes e o agora?Quais são os feedbacks que temos? Espontâneos, solicitados? O que eles dizem?
3º: Você.
- Como está sua carga de trabalho? Ideal, alta, baixa?Você é peça chave nas decisões ou apenas segue solicitações?Quais são seus objetivos profissionais no time? Promoção, desafio? O que você quer fazer e pra onde você vai?Como você é vista? Como está sua relação com seu time?Como é o ambiente? Como você se sente com os desafios atuais? O que faz sentido e o que não faz?
DesignOps é também para facilitar a nossa vida como designers. O trabalho fica mais fácil, mais respiro, mais segurança e confiança para trabalhar no que faz sentido.
DesignOps reflete na Ops geral do time
Diria isso ser a coisa mais legal de ver acontecendo. Às vezes as suas atitudes voltadas a melhor operacionalização de design também afetam a operação geral do squad (pessoas de produto, desenvolvedoras, etc.) de uma forma boa.
As habilidades para atuar em DesignOps — adaptação, flexibilidade, sistêmica… — são comportamentos preciosos e podem vir a ser espelhados pelos demais. Definições de processos, artefatos e tudo mais também podem vir a ser referências a outras coisas na operação geral.
Cuidado com a mistureba
Afinal a sua operação de design é mini em uma operação de produto. Isso quer dizer que pode haver uma linha tênue entre o que é de responsabilidade do escopo de design propriamente e o que é do time no geral. Então é sempre importante ter combinados quando tem este cruzamento.
Exemplo: crio um glossário pensando no melhor para a minha DesignOps. Mas este glossário é ou pode vir a ser útil ao time também, pois envolve coisas de outras áreas. Faz sentido então só eu popular esse glossário?
Tome iniciativas, mas não as torne peças pertencentes a DesignOps só porque você fez pensando nela. Analise se faz sentido mesmo e evite se sobrecarregar desnecessariamente. Conselho sincero, visse?
E chame a galera. Frise que você não é dono daquilo, e sim o time. O time é responsável por aquela manutenção. Faça-os fazerem parte disso. Ops é sobre gestão operacional, independentemente do prefixo que vem antes. É boa pra todo mundo.
5. Seja protagonista
Como comentei lá no início, a bola já está com você, o design do produto depende de você. Então assuma o protagonismo. Não tenha receio ou timidez de estar nessa posição.
Não digo isso para você se tornar influencer em DesignOps, tampouco ser um problema ter uma personalidade mais tímida, mais na sua — inclusive sou assim! Apesar de não parecer, às vezes isso é reflexo do que direi a seguir:
Não tenha medo de se portar como uma profissional que busca excelência na sua atuação, independentemente da sua senioridade.
Estão falando de design, fale também, se imponha, mostre que este tópico é seu. Estão dizendo algo que reflete no escopo de design, pontue, mostre que está atenta, que esta responsabilidade é sua.
A pessoa designer ainda é vista com viés puramente artístico. Mas temos processos, organização, escopo, estrutura — e isso não significa ter rigidez! Isso é DesignOps.
Precisamos nos posicionar como uma frente para funcionar, trazer essa ótica para a nossa área, tornar visível, concreta, clara tanto para você quanto a outras pessoas da empresa. É mostrar excelência além dos artefatos comuns esperados e sair da tela, tela, tela. E isso requer protagonismo.
Seja guardião da sua operação.
Continue a nadar
Este artigo é um facilitador. Os pontos levantados podem ser só a ponta do Ice Berg — cada operação tem a sua particularidade. Aprofunde no seu contexto e entenda o que trabalhar nele. De fato não há receita de bolo. Crie e vá testando.
Inclusive não tenha receio de referenciar DesignOps. Eu incentivo a mostrar antes de vender porque, na minha experiência, isso sempre deu mais frutos.
Também penso que se preciso pensar muito em exemplos em vez de só falar que Ops é o que fiz na entrega X, Y e Z, prefiro não falar. Referências de mercado pode ter de monte, mas não é minha prioridade mostrar essas referências ao time. Porque quero ser a referência deles nesse tema.
E há momentos em momentos. No meu PDI, 1:1's, eu cito. Em cerimônias com o squad ou empresa, sim. Em outros momentos que forem pertinentes, também. É sobre entender onde realizar a venda do assunto.
Outro ponto para se ter em mente é que ser a única pessoa designer atual não quer dizer ser para sempre. Criar essa sustentação pode facilitar o onboarding de outras pessoas designers. Defina essa cultura e amplie com essas novas pessoas.
É muito mais fácil fazer sinergia quando já há direcionamentos definidos. Olhe ao horizonte. Pense em escala.
Meu LinkedIn.
Referências
- Porque você deveria entender sobre DesignOps — Beatriz MirandaCompetências-chave para atuar em DesignOps — Beatriz Miranda3 formas de atuar com DesignOps — João Victor Santos | DesignOps LabThe DesignOps Starter Kit — 10 essentials for starting a DesignOps practice — Michelle Chin3P do DesignOps — João Victor SantosFacilitando o processo de diagnóstico do DesignOps — João Victor SantosProcess — DOCTécnicas e metodologias para gestão e priorização de backlog — Marcio ZocatelliFormação em DesignOps Essencial — Design Ops Lab: use o cupom BEAINDICA para obter 15% de descontoDesignOps Handbook — InVision
DesignOps Solo: aplicando como única pessoa designer da equipe was originally published in UX Collective 🇧🇷 on Medium, where people are continuing the conversation by highlighting and responding to this story.
