Criando um time de DesignOps
Sempre fui muito curioso e interessado nos processos pelos quais os times de design e produto em que trabalhei utilizavam. No C6 Bank, tive a oportunidade de experimentar um momento de grande crescimento do produto e dos times e era notável que por consequência disso, rotinas, cerimônias, a interação entre os times e até algumas entregas estavam começando a enfrentar problemas.
No dia a dia do time de design havia uma série de problemas de consistência, comunicação e uma sensação de que poderíamos estar fazendo mais e melhor.
EMPRESA
C6 Bank
PERÍODO
2019 - 2020
Problema
O time de design do C6 Bank estava crescendo e estruturalmente ficando mais complexo. Os processos criados para mantê-lo eficiente já não funcionavam como antes. Alguns dos nossos principais problemas eram:
Processo de design burocrático
Havia sido desenhado para garantir a qualidade das entregas, mas dificilmente era possível seguí-lo completamente sem atrasar a entrega da squad. Desenvolvedores e PM’s não viam valor no processo e a pressão por tempo obrigava o designer a pular etapas e muitas vezes isso gerava problemas na entrega.
Linguagem de design inexistente
Não havia muito bem definido e documentado qual era a forma do C6 Bank de criar seus produtos. Com isso, questões como espaçamentos, uso de cores, tipografia e até padrões de fluxos eram definidos pelo gosto do designer e isso resultava em:
-
Inconsistências de design;
-
Fluxos diferentes para ações semelhantes;
-
Extensa curva de aprendizado dos usuários com os aplicativos;
-
Design Critiques repetitivos e com pouco valor;
-
Enorme gasto de tempo de desenvolvimento;
-
Grande quantidade de bugs e refações;
-
Falta de alinhamento entre os times de Produto e Marketing.
Falta de acompanhamento de métricas
O time de design funcionava praticamente sobre demanda da empresa e os designers entendiam como finalizado, um trabalho entregue para squad. Não existia um acompanhamento dos projetos que estavam em produção e os designers não conheciam o impacto de seu trabalho. Com isso, o time não tinha visibilidade se o que vinha sendo feito estava na direção certa ou não e assim não tinham argumentos para defender suas ideias para os stakeholders.
Planejamento
Comecei a mapear e estudar os problemas e pesquisar sobre como outras empresas estavam lidando com eles. Criar um time com pessoas dedicadas a cuidar desse crescimento de forma sustentável a médio e longo prazo parecia ser um movimento natural. Times de design no Brasil estavam começando a explorar essa ideia enquanto empresas estrangeiras já estavam criando uma certa maturidade com relação aos times de DesignOps.
Na definição da Nielsen Norman Group:
Aos poucos fui trabalhando para difundir a ideia da criação de um time de DesignOps para a liderança de design e todos os benefícios que poderia trazer para o futuro do time e da empresa.
O primeiro passo foi compreender a dimensão e extensão do que a comunidade de design vem refletindo ser esse time. Mesmo considerando um contexto global, DesignOps ainda é um assunto novo e conforme as empresas aplicam esse conceito na prática, muito vem se descobrindo sobre boas práticas e aprendizados.
O segundo passo foi refletir sobre os problemas e necessidades do time e da empresa. Com isso foi possível começar a rascunhar o escopo desse time. No C6 Bank, definimos que o time de DesignOps seria responsável por escalar design na empresa e maximizar seu impacto, se baseando em 3 pilares:
Linguagem de design
Colaboração
Impacto
O escopo do time foi validado com a liderança da área e passou por sessões com os times de Design, Produto e Desenvolvimento para apresentar o que seria DesignOps na empresa e captar outros pontos de dores e oportunidades que poderíamos atuar. Conseguimos demonstrar o valor da ideia a ponto de termos uma squad composta por 1 designer, 1 PM e pessoas desenvolvedoras para Android, iOS e web.
1. Linguagem de design
Desde que comecei a trabalhar no C6 Bank, ainda na função de product designer, sempre me incomodei com o que chamávamos de design system. Basicamente tínhamos uma biblioteca no Figma em que todos os designers podiam contribuir e não havia nenhum responsável por sua organização. De início, servia para que o time não precisasse recriar componentes já utilizados e fornecia o mínimo de consistência.
Contudo, no dia a dia tínhamos alguns problemas:
-
A biblioteca considerava quase que exclusivamente componentes para os aplicativos, ignorando o site e a plataforma de web banking;
-
Com o tempo, a seção da biblioteca com mais elementos era "🚧 To be reviewed" já que ninguém tinha tempo para avaliar os novos componentes;
-
Muitos padrões do produto não eram documentados. Isso fazia com que cada designer projetasse suas interfaces de uma forma, aumentando o risco de gerar inconsistências;
-
Muitas interfaces não estavam componentizadas e não refletiam as atualizações da biblioteca;
-
Uma série de componentes foram criados fora da biblioteca e portanto, com pouca visibilidade para o time, gerando refações e componentes duplicados;
-
Os times de design de Marketing e Produto não consumiam da mesma biblioteca.
O que mais me preocupava era a falta de alinhamento com o time de Desenvolvimento, porque esse problema em particular tinha efeitos que iam além do time de design e afetava a usabilidade, acessibilidade, a experiência dos clientes com o banco, além do enorme gasto de recursos para desenvolver novas features.
Solução
Começamos a trabalhar em uma linguagem única de design do C6 Bank e partimos para criação dos nossos princípios de design. A ideia foi criar a base de tudo que viria em seguida e ajudaria no alinhamento entre os times de design de Marketing e Produto, além de contribuir com o aumento da maturidade de design da empresa.
Com os princípios de design definidos partimos para o que chamamos de V2 do design system, com uma arquitetura de bibliotecas de componentes espelhadas no código e disponíveis para designers e pessoas desenvolvedoras.
Outra novidade foi a gestão centralizada de estilos, feita através da inclusão dos Design Tokens. Além de ser uma ferramenta dos designers, a intenção era que o design system fosse um produto interno do C6 Bank com a documentação da linguagem de design para que qualquer colaborador da empresa tivesse acesso.
Resultados
Os princípios de design ajudaram na aproximação dos times de Marketing e Produto, além de ajudar os designers a criarem seus projetos com mais unidade e consistência. Outras áreas do banco passaram a compreender em mais detalhes a forma que o time design trabalha e o que é levado em consideração em tomadas de decisões.
A organização das bibliotecas fez com que os time de Marketing e Produto usassem os componentes adequados para suas plataformas, ajudando a unificar a linguagem de design. Também contribuiu para maior velocidade no trabalho dos designers, além de facilitar a comunicação entre designers e pessoas desenvolvedoras.
De maio a dezembro de 2020, o SUS (System Usability Scale) dos aplicativos do C6 Bank tiveram um crescimento de 6,25%.
2. Colaboração
Uma das ferramentas que utilizamos para melhorar a colaboração entre os designers e até com pessoas de fora, como PM's, pessoas desenvolvedoras e time de negócios foi o processo de trabalho.
Quando a primeira versão do processo de design do C6 Bank foi desenhada, considerou-se exclusivamente as necessidades do time de design em um estágio inicial do banco. Com o crescimento dos times e o natural aumento da complexidade de suas estruturas, foi percebido que este processo já não atendia mais às necessidades tanto dos designers quanto dos seus stakeholders.
Para entender os principais pontos de dor, elaboramos algumas rodadas de entrevistas com todos os envolvidos em qualquer etapa do nosso processo e descobrimos que:
-
Existia uma distância entre researchers e product designers;
-
Os researchers gostariam de acompanhar o desenvolvimento de suas descobertas;
-
Nem todos as tarefas precisavam passar por todas as etapas do processo;
-
O processo de design não se conectava com os processos de outras áreas do banco;
-
Tinham muitas pessoas de diferentes áreas nos Design Critiques e consequentemente, havia um baixo aproveitamento dessa etapa.
-
A curva de aprendizado de novos integrantes do time com nosso processo era muito longa;
-
Havia pouca colaboração durante a execução das tarefas.
Solução
Começamos a fazer pequenas iterações no nosso processo para tentar resolver os problemas identificados. Baseado em 5 etapas, adotamos uma abordagem que incluísse os times no desenho das soluções e que fosse cíclica, ou seja, estaríamos sempre monitorando os resultados do nosso processo para iterar sempre que necessário.
1. Identificação dos problemas
2. Priorização e análise de riscos
3. Desenho da solução e rodada de feedback
4. Teste em prática
5. Acompanhamento
Criamos um fluxo para tomada de decisão para sempre que o time de design começasse um projeto novo. A ideia era que fosse analisada a complexidade do projeto para definir se seria necessário uma etapa de pesquisa com mais profundidade ou não.
Adaptamos o início do nosso processo de downstream para torná-lo um momento de co-criação entre designers e suas squads. Dividimos o design critique em 2 momentos: o critique com stakeholders para analisar se a solução atende objetivos de produto e negócio; design critique para designers discutirem tecnicamente a solução, baseado em heurísticas, boas práticas e os princípios de design.
Análise de Fatos
Ao final do processo, também foi adicionado uma cerimônia chamada Análise de Fatos. O objetivo era criar um momento para a squad se reunir e analisar métricas dos seus produtos. Além de dar visibilidade para todo o time, poderiam surgir ideias de iterações baseadas na análise dos dados.
Documentação do processo
Todo o processo de design do C6 Bank foi documentado para auxiliar os times durante o desenvolvimento dos projetos. Algumas etapas como design critique, design review e design QA ganharam documentações específicas com maior profundidade. Alguns workshops foram realizados para estimular o uso do processo, esclarecer dúvidas e trocar boas práticas de design.
Resultados
Product designers e researchers passaram a trabalhar mais próximos, ampliando o escopo do product designer e aumentando a visibilidade dos projetos pelos researchers.
Houve um aumento da performance do time de design que foi capaz de participar de mais projetos sem perder qualidade das entregas.
A divisão do design critique possibilitou que houvesse tempo para discussões de Produto e Negócio, sem afetar o momento necessário para discussões de design. Foi notável o aumento da maturidade e nível das discussões dos times com maior foco nos problemas do usuário.