Introdução ao DesignOps — Ampliando o valor do design

11 min readOct 5, 2022

por Dave Malouf, DesignOps Summit and IxDA

Eu sempre estive perto de pessoas que gostam mais de como o design funciona do que projetar. Ao longo da minha carreira como designer, aprendi mais sobre o processo do que a prática e, em algumas ocasiões, eu me sentia um pouco excluído por causa da minha preferência por processos.

Esse interesse nos processos me levou até o Queens, Nova York, em novembro de 2017, onde juntei cerca de 300 pessoas para aprender, compartilhar e trabalhar na formalização de um novo tipo de gerenciamento de design, o DesignOps. O DesignOps Summit marcou um ponto de virada, pois as operações de Design começaram a surgir em toda essa indústria de design. Mas para mim foi também o auge de uma longa jornada pessoal através do design.

O que faz o Design ter valor

Vamos começar do início. Em 2005 tive aulas em uma escola de design pela primeira vez. Eles davam cursos de formação em desenho industrial e, através deles, entendi o que o design realmente é e quais os princípios fazem a prática de design tão valiosa: descobertas acidentais, uma cultura de interrupção e criatividade desconstrutiva.

As descobertas acidentais são o núcleo cultural de um estúdio de design. Em um estúdio pré-digital, o trabalho de todo mundo é externalizado, visível e transparente. Isso significa que as ideias são justapostas intencionalmente, passivamente, acidentalmente e por acaso. Essas interações forçadas que dão luz a novas ideias são os fundamentos de como o design funciona. Já a cultura da interrupção é vital para que o design alcance todo o seu potencial. Essas interrupções vêm na forma de instrução, crítica e comparação, para citar alguns exemplos. E, por fim, quando os designers imaginam uma ideia próxima do que é um sistema completo, ao desconstruí-lo e reconstruí-lo, eles se envolvem em uma criatividade desconstrutiva.

Essas três propriedades contribuem para que um time de design tenha alta performance e resultados de qualidade. Além disso, com o surgimento do Design Centrado no Usuário e dos profissionais de design, eles se tornam os principais fatores da compreensão humana e da empatia dentro de uma organização.

Da escola de design, mudei para um estúdio de design industrial e depois para um cargo de professor de design no departamento de Design Industrial na Savannah College of Art and Design. Essa experiência me levou ao Design Thinking em Design de Serviços e Design para Sustentabilidade.

O que eu não percebi foi que, enquanto estava no campus imerso nos princípios que tornam o Design tão valioso e único, a abordagem ágil para o desenvolvimento de software estava englobando essas mesmas práticas. Eu conhecia o método ágil mas não estava preparado para seu impacto no mundo do Design.

Anti-ágil, pro-design

Agile é uma abordagem iterativa de desenvolvimento de software em que times multidisciplinares colaboram para definir requisitos e soluções para um determinado projeto. Conforme explicado no Manifesto para Desenvolvimento Ágil de Software:

Estamos descobrindo maneiras melhores de desenvolver software fazendo e ajudando os outros a fazê-lo. Através deste trabalho passamos a valorizar:

• Indivíduos e interações ao invés processos e ferramentas;

• Um software funcional ao invés de uma documentação completa;

• Colaboração do cliente ao invés negociação de contratos;

• Responder às mudanças ao invés de seguir um plano.

Ou seja, e embora haja valor nos itens da direita, valorizamos mais os itens da esquerda.

Nesses cinco anos em que estive no campus, o método ágil se tornou a norma no desenvolvimento de produtos, em oposição aos interesses dos designers. O que eu vi foi a prática de design dando grandes passos para trás — visão, exploração, desconstrução, pensamento associativo e interrupções foram suprimidos em favor de trabalhar da maneira que os desenvolvedores queriam.

Subjugar o design em relação à engenharia ágil faz sentido para os engenheiros, pois o ágil se encaixa na sua cultura. Além disso, os métodos ágeis os levaram a ótimos resultados, tornando difícil refutar seu valor. Empresas como Amazon, Google, Netflix e Facebook tiveram muito sucesso com o método ágil. Assim, os designers estavam em uma posição desfavorável de aculturação na mentalidade ágil para que suas posições não se tornassem irrelevantes. Aqui está o que eu vi nessa cultura otimizada para engenheiros:

Designers isolados de outros designers e não trabalhando como devem;
O Design como um papel de produção em vez de um papel estratégico, com designers frequentemente solicitados a realizar um ajuste visual e superficial;
Contratação de designers com base nos modelos de contratação de engenheiros;
As carreiras de designers iguais as carreiras de engenheiros;
Ferramentas de design desalinhadas com as necessidades, bem como priorização de ferramentas de design que tenham integração com as ferramentas de desenvolvimento em vez de funcionalidades de design específicas.

No meu primeiro emprego, depois de deixar o SCAD, eu estava em um cargo com o título de “chefe de Design de Interação” da Rackspace. Esse foi meu primeiro cargo de “operações de design”, onde meu trabalho era tornar o design — ou seja, meu time de design e nossos resultados — melhores. Descobri que as métricas de sucesso do nosso time de desenvolvimento e de gerenciamento de produtos eram diferentes daquelas usadas no Design, resultando em produtos muito abaixo da média. E aí estava o problema: desenvolvedores e gerentes de produto mediam o sucesso pelo fato de um produto ser entregue no prazo e não se o produto satisfazia as necessidades do usuário.

Na Rackspace, aprendi sobre DevOps e Lean Startup. O DevOps é a prática de alinhar desenvolvimento de software, operações de sistema, automação e algumas outras coisas para permitir integração e implantação com o objetivo de aprendizado contínuo. Já a Lean Startup reduz o risco do negócio concentrando-se em pequenos objetivos bem definidos, chamados de experimentos, que determinam se um produto está indo para um caminho válido ou não.

A combinação das metodologias DevOps e Lean Startup fez as pessoas enxergarem o ágil sob uma nova luz e os ciclos de desenvolvimento de produtos ágeis passaram a incorporar o aprendizado e qualidade. A velocidade não era mais o objetivo, mas sim um subproduto da automação. O aprendizado de maneira iterativa e rápida se uniram.

Tudo mudou em 2014, quando fui apresentado pela primeira vez ao dual-track agile. Foi adicionado ao método ágil a descoberta; enquanto uma trilha se concentra em entregar o valor de uma ideia aos usuários, uma outra trilha é dedicada a ações baseadas no aprendizado. O dual-track apresentou algumas questões sobre o papel do designer: como exatamente eles trabalham com seus pares nesse ambiente e como essa nova estrutura pode permitir que os designers incorporem seus próprios métodos de descoberta e de exploração?

A resposta: adicione mais uma trilha. Eu criei o tri-track: paralelo e integrado com a descoberta e a entrega, é uma terceira trilha, o entendimento. Nesse caminho, alinhamos uma estratégia para construir a “coisa certa” com base nas necessidades do usuário e nas percepções do time.

Devido ao meu contato com o DevOps e minha familiaridade com as operações de TI, foi um passo natural para mim batizar o tri-track como uma nova “coisa” chamada operações de design. Embora ainda fosse uma ideia muito vaga quando a desenvolvi em 2014, senti que estava no caminho certo.

Desde 2014 estive pensando sobre operações de design para validar a prática de DesignOps. Ao longo dessa jornada, descobri colegas que compartilhavam da mesma ideia que eu e que histórias eram parecidas com a minha. Essa jornada culminou com o DesignOps Summit.

Por que DesignOps agora?

Minha missão no DesignOps é ampliar o valor do design. O design como prática requer uma atenção especial nas operações que mantêm os interesses do design e dos negócios de uma organização.

Nas minhas conversas e observações pelas organizações ao redor do mundo, cheguei a quatro fatores principais que contribuem para as funções e práticas de liderança orientadas ao DesignOps à medida que as equipes de design amadurecem: escala, pessoas, expectativas e inclusão.

As organizações estão escalando a cada vez mais:

Os times estão crescendo;
As empresas estão abrindo novos escritórios (e distribuindo os times);
Os times de Design dão suporte à várias áreas da organização;
As empresas continuam criando novas unidades de negócios;
As soluções de design estão ficando mais complexas;
As organizações estão integrando mais e diferentes tipos de práticas de design;
As ferramentas utilizadas para um projeto tornam-se mais complexas de acordo com os sistemas que estão sendo projetados.

Pessoas são prioridades

Bons designers são raros e eles sabem disso. Isso torna o recrutamento mais difícil do que era antes;
As organizações estão ficando mais complexas, o que dificulta a estruturação dos times;
O design não é um trabalho que você simplesmente vai lá e faz. Os designers precisam ser desenvolvidos, promovidos, recompensados e reconhecidos.

As expectativas são altas:

Queremos carros voadores, o que significa que esperamos que nossa experiência seja a melhor de todas quando isso acontecer. Nós queremos os melhores projetos e os melhores resultados.

Diversidade e inclusão dão trabalho

Times diversos são ótimos para o design, mas chegar nesse nível não é tão fácil assim, “Vamos ser um time diversificado e inclusivo”. As pessoas precisam de treinamento e prática para trabalhar em times diversos e inclusivos e isso requer novas abordagens, bem diferente das gerações anteriores.

Então, o que é DesignOps?

“Basicamente, as operações de design são responsáveis por fazer o design acontecer.” Josh Ulm — ORACLE

Cada organização tem seus objetivos e há atividades necessárias para atingi-los. Se o objetivo da minha empresa é construir paredes de tijolos, a produção de tijolos é a atividade principal. Em um trabalho como taxista, meu objetivo que é transportar passageiros de um lugar para o outro é alcançado dirigindo o táxi.

As operações são os elementos que facilitam essas atividades com o mínimo de atrito. As operações incluem as ferramentas e a infraestrutura necessárias para concluir a atividade. Usando o exemplo do táxi, um serviço de táxi requer um automóvel, combustível e estradas. O taxímetro, o GPS e o despachante compõem o ecossistema dessa experiência.

Como um serviço de táxi, a prática do design requer um conjunto de atividades que dão suporte.

Muito se fala sobre habilidades em design — desenho, tipografia, cores etc. Mas, de maneira geral, essas habilidades são como planejamos modelos e formas que podem resolver problemas para criar mudanças positivas.

Essas habilidades geralmente estão dentro dos métodos. Cada método pode usar habilidades diferentes para atingir o mesmo objetivo.

Portanto, os métodos moldam processos específicos. Os processos mostram o caminho para alcançar o sucesso. Os clássicos “quatro Ds do design” são um exemplo de processo: descobrir (discover), definir (define), projetar (design) e entrega (deliver).

O DesignOps, então, é tudo que dá suporte às habilidades, métodos e processos

Para ilustrar, vamos imaginar que você tenha que desenhar wireframes à mão. O que você precisa para realizar esta tarefa?

Bem, você precisa de ferramentas como, por exemplo, uma coleção de instrumentos de desenho. Talvez este seja um lápis nº 2, ou talvez uma lapiseira Staedtler de 0,5 mm. Você pode usar cores diferentes e até espessuras diferentes. Uma régua ou um conjunto de stencils também podem te ajudar. Você também vai precisar de um lugar para desenhar– um bloco de desenho e talvez um com um grid já impresso. Você tem muitas opções, mas vai precisar de várias ferramentas.

Você também vai precisar de uma infraestrutura para desenhar. Uma mesa e uma cadeira ajustável podem facilitar. Se você desenha com frequência, uma mesa inclinada vai ser melhor ainda. E onde você guarda seus desenhos e como eles são organizados?

Podemos ainda nos perguntar: como você decide o que desenhar primeiro? Quem decide seu fluxo de trabalho? Quando você terminar, para onde você envia seus desenhos e quem decide se eles são bons o suficiente? Como se define o que é “ser bom o suficiente”? E se seus desenhos exigirem correções: quem decide isso e quem faz essas correções? As perguntas não tem fim.

Quantas pessoas precisam trabalhar nesses wireframes e como eles são organizados? Em que momento você decide contratar mais pessoas e como elas são contratadas para fazer parte da organização?

Como você é pago por seus desenhos e quando você pode tirar férias (e por quanto tempo)? Que tipo de governança está em vigor para controlar o tempo, para se relacionar com clientes ou ainda para reclamações quando há divergências?

Juntos, ferramentas, infraestrutura, fluxo de trabalho, pessoas e governança são as operações.

Por fim, a maneira como gerenciamos nossas operações é a nossa cultura. Estes são os valores, princípios e missão que impulsionam uma organização.

Como o DesignOps funciona

O DesignOps é composto por três elementos sobrepostos, ou áreas de foco. Essas áreas se sobrepõem, mas essas sobreposições e práticas específicas são frequentemente influenciadas pela liderança no momento em que as práticas de DesignOps são implementadas.

Meu primeiro contato com o DesignOps foi por meio de Operações de Negócios. Meu líder executivo na Rackspace sabia da importância das operações de negócios para o sucesso do seu time. Eu o vi em tantas reuniões com finanças, TI e compras quanto com marketing, produto e engenharia. Ele levou a gestão de mudanças muito a sério e isso se traduziu em um canal de comunicação muito forte como o time.

Essa visão de negócios trouxe uma vantagem para o nosso time em relação aos outros. Tínhamos Macs quando ninguém mais tinha, vários quadros brancos e salas reservadas, uma atenção especial com a nossa carreira por parte do RH e muitas outras coisas. O foco nas operações de negócios permite que o capital orçamentário e político facilite os processos de design. Em uma organização que possui a área DesignOps, um chefe de equipe geralmente é responsável pelas operações de negócios.

Outra área com foco em DesignOps é a de Operações de Pessoas. Na minha carreira vi a diferença que pode fazer para uma equipe de Design ter uma trajetória de carreira bem definida e transparente. Por outro lado, vi como organizações com uma única abordagem de desenvolvimento de carreira podem diminuir a moral dos times. Os times de design precisam de suporte, ritos e expectativas bem definidas que só as operações de pessoas podem fornecer. Community leaders ou practice leaders geralmente executam as operações de pessoas em uma organização com DesignOps

Por fim, o Workflow Operations (Operações de Fluxo de Trabalho) está dentro do que às vezes chamo de “Operações de Gerenciamento do Ciclo de Vida do Produto”. Um Program Manager normalmente é encarregado dessa área, que foca no fluxo de produção dentro dos times de design e pesquisa e na integração da prática de design com as outras áreas do ciclo de vida do produto (desenvolvimento e produto). Os sistemas que integram a inclusão de projetos, critérios de avaliação e gerenciamento de projetos, ferramentas e infraestrutura se enquadram nessas operações.

— — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — —

Este texto é a tradução do capítulo Introducing DesignOps — Amplify the value of design do e-book DesignOps Handbook da DesignBetter. Você pode baixar a versão original aqui.