OBS: Artigo criado por João Victor Santos (Consultor e responsável pelo DesignOps Lab), originalmente publicado aqui.
Será que DesignOps é apenas sobre design?
O que vou trazer aqui é uma visão, ou mais precisamente, um mindset e algumas práticas sobre como ter uma base sustentável que possibilite não somente escalar design, mas todas as partes envolvidas do produto.
Você pode baixar o canvas aqui.
https://www.designbetter.co/designops-handbook
Desde que iniciei no mundo do DesignOps, meu mindset e foco sempre foram voltados para gestão de produto (inicialmente o design system), processos, liderança e comunicação eficaz entre equipes de design e engenharia.
Em 2018 tive oportunidade de responder algumas perguntas sobre o tema, foi quando eu mencionei sobre os pilares do DesignOps, que na minha opinião, eram sobre pessoas, processos e ferramentas.
Porém, hoje acredito que ferramentas podem entrar em processos e então o pilar de prioridades assumiria essa posição. Claudia Love explora muito bem também essa questão sobre pilares no artigo dela sobre Operations na Cisco.
Dave Malouf em https://www.designbetter.co/designops-handbook
DesignOps nada mais é que um ciclo constante de aprendizado e melhoria contínua. Isso tudo pra atingirmos o principal objetivo que é escalar produtos de forma mais eficiente, criando um conjunto de práticas que envolvem pessoas, processos, prioridades e ferramentas para tornar isso possível.
O principal ganho disso é fazer com que cada vez mais o mercado se adapte, e principalmente entenda que essas práticas são essenciais para o futuro e manutenção da empresa.
Lembrando também, que DesignOps pode operar em escala empresa, quanto a nível de projeto ou produto. Tudo vai depender da maturidade e das responsabilidades desse time ou cargo.
The focus of this role has shifted more toward project management. The role manages our project-intake process, works with team leadership across our locations to allocate design resources, and tracks project delivery. — Tobias Komischke Director User Experience at Honeywell
Mas no dia a dia como podemos aplicar os conceitos de DesignOps, então?
Quando falamos sobre Pessoas, estamos basicamente citando: Liderança, empatia, diversidade, carreira, engajamento, mentoria, ambiente de trabalho saudável… e uma série de outras coisas, a lista é extensa.
Quando aplico ao meu dia a dia, a empatia é uma das mais importantes que auxiliam nesse pilar.
DesignOps: Mas o que empatia tem a ver com isso?
Eu já tive experiência com desenvolvimento front end e outras áreas da tecnologia, e foi este background que me deu os conhecimentos necessários para dialogar com os times de design e engenharia.
Mas foi somente praticando a empatia, comunicação e o interesse genuíno por pessoas que fui percebendo as dores cada mundo.
Protótipo vs Código
Esse foi um dos desafios que encontrei como DesignOps👆
Mas não pense que foi “apontando dedos” ou dizendo quem estava “errado” que nós conseguimos melhorar a situação acima.
Para deixar claro como se deu esse processo de empatia e comunicação, os 3 passos a seguir me ajudaram a melhorar a integração dos times e aumentar a produtividade:
1. DesignOps: Esqueça o “EU” e comece a pensar em “NÓS”
Pessoas, lembra? No plural, ou seja, é o coletivo!
Todos são peças fundamentais para o produto ser entregue com qualidade. Não adianta apenas uma equipe/área fazer um bom trabalho sem que as demais estejam na mesma sintonia.
A comunicação neste ponto é muito importante, saia um pouco do seu computador e interaja com pessoas de outras áreas.
Esse papel não é só do design, mas de qualquer um que queira melhorar a comunicação e o engajamento entre equipes.
2. DesignOps: Procure entender os dois mundos
Entenda o fluxo de trabalho de cada equipe: isso vai ajudar, e muito, a encontrar possíveis melhorias.
Identifique barreiras ou impeditivos.
Existe alguma dificuldade ou limitação técnica que justifique não entregar o que é proposto?
Desde ferramentas de design à stack de desenvolvimento.
É importante saber se existem barreiras. E se ninguém expor essas dores ou dificuldades, sempre será mais fácil acharmos justificativas ao invés de nos colocarmos no lugar do outro para tentar ajudar.
3. DesignOps: Garanta que todos falem a mesma língua
É sobre ter uma comunicação compartilhada entre as equipes de design e engenharia. No nosso caso, a linguagem compartilhada tem como base o Atomic Design.
Quando ambos os times começaram a discutir eficientemente sobre esse tema, as coisas começaram a melhorar.
Por exemplo, discussões do tipo: “Isso é um novo componente? Ou é apenas uma variação?”
Perguntas como essas eram facilmente respondidas quando olhávamos para os nossos componentes e identificávamos que na verdade eram apenas composições de elementos já existentes, ou seja, não eram novos componentes ou variações.
Outra ponto positivo em nossa comunicação foi o uso de Design Tokens.
Hoje quem tem controle sobre esses valores é o time de design e não o time de desenvolvimento. Por quê? Para que os desenvolvedores não tenham a necessidade de mexer no código se caso a gente quiser alterar uma cor por exemplo.
Levando em consideração os exemplos que citei até aqui, resumindo o pilar de pessoas no DesignOps seria mais ou menos isso:
O pilar de Pessoas vai muito além disso, os exemplos que coloquei no post foram apenas sobre desafios de comunicação.
Se for para listar outros aspectos, os seguintes itens entrariam na lista:
- Recrutamento (match de cultura)
- Suporte e apoio (trabalho em equipe)
- Carreira (desenvolver habilidades e proporcionar oportunidade para todos)
- Liderança (feedback, mentoria, ambiente saudável…)
- Capacitação (eventos, treinamentos — interno e externo)
- Headcount e budgets
E a lista segue… tente aplicar ao seu contexto 😉
DesignOps: tá tudo muito lindo mas como fazer isso na prática?
Quando o assunto é processos eu gosto de pensar nos seguintes itens: Produtividade, performance, autonomia, governança, organização e agilidade.
Foi a partir desse pilar que o nosso Design System nasceu.
Identificamos que os nossos processos precisavam ter uma escala maior para aumentar a performance dos times.
Foi pensando nesses processos e na forma de operacionalizar o Design System de forma eficiente e escalável que chegamos nos seguintes passos:
1. DesignOps: Defina os papeis e suas responsabilidades
Processos que envolvem governança ajudam bastante na organização das equipes. Para esse exemplo eu trouxe uma parte da nossa matriz RACI de responsabilidades.
Responsável (DS Team): O time ou a pessoa responsável pela manutenção do Design System é o encarregado dessa demanda.
Irá avaliar, priorizar e julgar o que for necessário para cumprir a tarefa.
Consultado (UX e Framework): Os principais stakeholders no caso do Design System é próprio time de UX e o time de componentização (Framework). Responsáveis por validar o uso do componente.
Informado (P.O): Quando surgem demandas dos times de produto e há necessidade de validar um novo padrão, ao final o P.O que será afetado por essa feature obrigatoriamente precisa ser informado das decisões. Na RACI esse pode ser um caso de “consultado”, porém o “informado” funciona nesse caso porque os requisitos solicitados por ele(a) já foram validados visual e tecnicamente pelos times responsáveis.
Aprovador (DesignOps): Essa posição fica responsável por aprovar a solução final, organizar o backlog necessário de tarefas para documentar e tornar oficial essa alteração no Design System (release notes, design tokens, tabela de status, etc…)
Isso não precisa ser algo burocrático, geralmente essas responsabilidades já fazem parte do dia a dia de trabalho e se torna algo natural.
2. DesignOps: Tenha fluxos de trabalhos bem estruturados
Essa parte vai variar muito dependendo de como é a organização das equipes na sua empresa, e vai depender do quanto você está disposto a mapear o fluxo de trabalho de cada uma delas.
A princípio, minha dica seria identificar os caminhos possíveis que uma demanda ou tarefa passa até chegar no time de design ou da squad que você trabalha. A ideia é que fazendo isso você irá perceber até que ponto você realmente tem conhecimento dos processos, e a partir disso ter alguns insights de como poderia obter as peças que estão faltando, e posteriormente montar o quebra-cabeça completo.
Mas calma, não estou falando para você desenhar um fluxograma completo de trabalho de toda a empresa.
No nosso caso, para o time de design, identificamos que seria interessante desenharmos tanto o fluxo de trabalho de UX quanto o do time de componentização (FRAM).
UX e FRAM
Desenhando cada etapa e cada ponto de controle, conseguimos ver com clareza quais eram os gaps que precisavam ser melhorados para minimizar retrabalhos. As imagens são apenas um esboço, tente validar e desenhar seu próprio workflow para ter essa visão mais ampla e conseguir identificar melhorias.
O resumo dos dois fluxogramas trabalhando em conjunto fica da seguinte forma:
PG = Design System
A demanda só vai para o time de desenvolvimento (círculo azul) depois que passa pelo review e todos aprovadores. A partir daí o ciclo só finaliza depois que UX e UI são validados.
3. DesignOps: Mantenha a consistência e os padrões
Para esse item, se estamos falando de Design System, é importante criar um diagrama de decisões.
Assim, o time pode ter uma visão mais clara de quando realmente é necessário validar um novo componente ou variação.
Além do diagrama de decisões é importante deixar claro quais as principais etapas que essa alteração precisa passar, até porque novos integrantes irão precisar rapidamente dessa informação. Por exemplo, nessa situação nós seguimos o seguinte:
- Research (benchmark para validar todos os casos de uso)
- Prototype (protótipos e variações)
- Review (UX/FRAM)
- Documentation (guia de uso)
Levando em consideração os exemplos que citei até agora, resumindo o pilar de processos no DesignOps seria mais ou menos isso:
Os itens que estão na imagem acima são apenas um parte bem pequena do que poderia entrar no pilar de processos. Porém no caso de design systems, estes são itens extremamente importantes, por isso fiz questão de trazer os exemplos nesse sentido.
Tudo que está nesse post independe de um DS… esse é um dos pontos que o mercado ainda precisa entender quando o assunto é DesignOps. O trabalho não começa e muito menos termina com um Design System💭
O pilar de Processos é muito amplo, e o Design System é apenas um dos artefatos que podem estar dentro desse pilar.
Se for para listar outros aspectos, os seguintes itens entrariam na lista:
- Onboarding
- Meetings & event planning
- Documents, design assets
- Wikis & playbooks
- Tools
E a lista segue… tente aplicar ao seu contexto 😉
Quando o assunto é prioridades, me refiro ao seguinte: Foco em resultados, objetivos claros e bem definidos, estratégia e visão.
É sobre o business, fazer as coisas certas e com os recursos disponíveis mantendo a sanidade das equipes.
For example, DesignOps can help a product manager operationalize a roadmap, make sure that the team has proper kick-offs on projects, and ensure a design QA is scheduled prior to a major product launch. — Meredith Black.
Mas já que citei vários exemplos nesse artigo usando Design Systems como base, vamos analisar esse pilar em relação á esse tema então…
DesignOps: Eu realmente preciso de um Design System?
Você já parou para pensar se isso realmente vai resolver os seus problemas? Provavelmente sim, mas de tudo que já conversamos até aqui… é só um Design System que vai trazer o impacto que você quer?
Estamos falando aqui de um produto que vai gerar trabalho e vai impactar várias áreas da organização, e é por isso que estes questionamentos são importantes para você avaliar bem os impactos de suas decisões.
Estou sendo “chato” para que você não caia nessa situação 👇
Quem quer um Design System aí?
Se uma das prioridades da empresa for realmente criar um Design System, então você vai precisar ter o conhecimento sobre o assunto e principalmente falar a língua de outras áreas do business para vender esse produto internamente.
Nesse ponto é importante alinhar as expectativas com as principais partes interessadas, para que assim, todos estejam cientes do impacto, do esforço e dos recursos que serão necessários para tocar essa iniciativa a diante.
O que irá definir o pilar de prioridades será o contexto que você vive, e principalmente sobe o seu próprio entendimento do que pode ser prioridade ou não. Mas uma coisa eu garanto, o mindset que envolve esse pilar é sobre big picture thinking, strategic management, é sobre ter uma visão ampla do negócio, projeto, equipes… para que as prioridades sejam relevantes e coerentes à estratégia da empresa.
Acredito que o resumo disso no DesignOps seria mais ou menos o seguinte:
De forma genérica se for para listar outros aspectos, os seguintes itens poderiam ser citados:
- Alinhamento entre lideranças e equipes
- Roadmaps
- Gestão de prioridades
E a lista segue… tente aplicar ao seu contexto 😉
Tente medir o impacto das ações para que a priorização seja eficiente.
DesignOps: Têm receita de bolo?
Não… Se tivesse não teria graça 😆
Tudo é contexto.
A cultura de onde você trabalha é diferente da cultura de outras empresas, organização, pessoas, quantidade de colaboradores… e por aí vai.
O meu contexto é diferente do seu, e isso impacta diretamente como será o trabalho do time ou cargo de DesignOps dentro da organização.
Para complementar o texto gostaria de indicar a talk do Brennan Hartich — Communicating and Establishing DesignOps as a New Function, aonde ele comenta sobre os 3Ps aplicado na Intuit. Basicamente foi dividido cada pilar em funções, por exemplo Design Manager responsável por Pessoas, o DesignOps responsável pelos Processos e o Design Director responsável pelas Prioridades. Vale a pena assistir para ter uma visão mais abrangente. Essa referência não é a única que menciona sobre pilares, mas dá uma boa perspectiva das possibilidades 🙂
E para finalizar gostaria de compartilhar o 3P Canvas! 🚀 📝🎯
Isso vai ajudar você a mapear os itens que irão fazer parte de cada pilar.
Assim você pode focar no que realmente é relevante para o seu contexto e ter os resultados que deseja.
Como esse post ficou extenso, irei escrever um outro explicando detalhadamente sobre o por quê, como e quando aplicar o canvas.
Mas você já pode baixar e usar =)
João Victor Santos é consultor e responsável pela marca DesignOps Lab e facilitador do Bootcamp Design Ops na How.
