Design Talks: Melhor colaboração de designer e desenvolvedor com Aaron Walter da InVision

Bem-vindo à nossa série Design Talks dedicada a compartilhar as ideias de líderes de pensamento e das principais pessoas envolvidas no design de todo o mundo. Entrevistamos especialistas que trabalham com design em diferentes contextos, com diferentes objetivos e por meio de diferentes abordagens. Nestas séries, esperamos fornecer inspiração intelectual e criativa a todos os nossos leitores.

Designers muitas vezes lutam para trabalhar com desenvolvedores e vice-versa. As equipes de ambos os lados podem aprender muito umas com as outras, mas ainda existem camadas de resistência. O convidado desta semana é Aaron Walter, VP of Design Education da InVision e vamos falar sobre a colaboração entre designers e desenvolvedores.

Aarron baseia-se em 15 anos de experiência gerenciando equipes de produtos e ensinando design para ajudar as empresas a adotar as melhores práticas de design. Ele fundou a prática de UX no MailChimp e ajudou a aumentar o produto de alguns milhares de usuários para mais de 10 milhões.

Sua orientação de design ajudou a Casa Branca, o Departamento de Estado dos EUA e dezenas de grandes corporações, startups e empresas de capital de risco. Ele é o autor do livro best-seller Designing for Emotion from A Book Apart. Você encontrará @aarron no Twitter compartilhando ideias sobre design e poderá aprender mais sobre Aaron em aarronwalter.com.

No Design Better Podcast, os apresentadores Aaron Walter e Eli Woolery entrevistam líderes de design e influenciadores que compartilham histórias de como eles resolvem problemas e sua carreira. Os convidados incluem David Kelley (cofundador da IDEO e fundador da Stanford d.school), Julie Zhuo (VP de Produto e Design no Facebook) e Jake Knapp (autor do best-seller Sprint), entre outros.

Olá Aaron, é um prazer tê-lo no Toptal Design Blog. Os desenvolvedores são de Marte e designers de Vênus?

Na minha experiência, designers e desenvolvedores provavelmente têm mais em comum do que imaginam, mas definitivamente existem algumas diferenças distintas na maneira como pensamos sobre as coisas. Os designers adoram pensar em sistemas de design e os desenvolvedores pensam em código modular que é fácil de manter. Mas a maneira como fazemos isso pode ser um pouco diferente.

Os desenvolvedores encontraram maneiras de dividir seu trabalho em partes menores, e os designers tendem a pensar na coisa toda como o “bolo inteiro” e como comemos o bolo inteiro.

Este é um ponto em que eles começam a bater de frente. Os engenheiros querem ser capazes de enviar código em pequenas etapas e fazer algo muito rapidamente como parte da metodologia Agile. Os designers tendem a querer dar um grande passo à frente de maneira holística – eles querem oferecer uma experiência consistente. Isso pode ser um ponto de discórdia para esses dois grupos.

O que os designers podem fazer para trazer os desenvolvedores um pouco à nossa perspectiva? Como os designers fazem os desenvolvedores entenderem que cada pequeno recurso enviado também é sobre a experiência?

Há uma oportunidade para ambos os lados se dobrarem aqui. Às vezes, os designers tentam convencer um desenvolvedor de que precisamos esperar e construir a coisa toda, e depois colocá-la para fora como essa experiência bonita e completa.

Mas se o ciclo de criação for muito longo, os produtos correm o risco de serem mortos. As pessoas começam a perder o interesse. Eles podem dizer: “Isso está realmente criando valor para o negócio? Estamos gastando muito tempo, energia e recursos nisso, por que está demorando tanto?” Os designers precisam pensar mais sobre o ciclo de negócios.

Se a Apple enviar um telefone – uma peça de hardware com um problema – isso pode custar bilhões de dólares, mas se o software for enviado e houver um problema, podemos apenas corrigi-lo, consertá-lo e enviá-lo novamente. Abordar o processo dessa maneira nos permite conectar de volta ao ciclo de trabalho de desenvolvimento de forma mais elegante.

Os designers também podem tentar preencher a lacuna entre os dois grupos, envolvendo os engenheiros no processo de design desde o início, para que eles se sintam incluídos na fase inicial de idealização, não apenas no final. Os designers podem dizer: “Tivemos essa ideia brilhante, faça para nós!” e isso faz com que os desenvolvedores sintam que não fazem parte do processo de idealização. Eles são apenas as mãos e outra pessoa é o cérebro.

A relação mais disfuncional entre designers e desenvolvedores acontece quando há uma divisão de trabalho distinta. Quanto mais isso começar a se misturar e essas equipes trabalharem juntas, melhor. Como resultado, haveria múltiplas perspectivas e propriedade compartilhada, o que é realmente fundamental para designers e desenvolvedores trabalharem juntos de forma eficaz.

Sobre entender melhor o espaço de cada um…

O que as equipes podem fazer para entender melhor o espaço umas das outras? Os designers devem se familiarizar com o desenvolvimento e vice-versa?

Primeiro, designers e desenvolvedores podem conversar mais com os clientes e aprender juntos sobre o espaço do problema . Eles podiam conversar com três a quatro clientes pela manhã durante o café; todos poderiam aprender muito rapidamente e chegar a um entendimento compartilhado de quais são as preocupações.

Em segundo lugar, em termos de processo de trabalho, é importante que designers e desenvolvedores tenham – talvez não fluência – mas alguma compreensão da linguagem um do outro. Não quero dizer que um designer precise saber codificar ou que os desenvolvedores precisem dominar a tipografia, mas pelo menos há um entendimento compartilhado.

Se os designers pudessem enquadrar as coisas em uma linguagem que os desenvolvedores entendessem – “tal e aquilo não está funcionando e isso é ruim para os negócios” – então os desenvolvedores rapidamente entenderiam o problema. Não é algo que vem naturalmente para os designers, mas eles precisam ser melhores em comunicar o valor de seu trabalho quantitativamente , não apenas qualitativamente . A equipe de vendas, a equipe de marketing, engenharia, produto, executivos, todas essas pessoas estão falando em números, estão falando quantitativamente .

Dito isso, acredito que o design traz algo muito valioso, que existem algumas coisas que contam e que não podem ser contadas. A experiência do cliente, a alegria, o amor pelo produto são muito valiosos, e isso é difícil de quantificar.

No entanto, pode ser quantificável, mais adiante esse componente de qualidade trará um ROI que é quantificável.

Sim, podemos reduzir os custos de suporte ao cliente com design, podemos reduzir o churn, podemos aumentar a velocidade de integração. Ter métricas como essa para definir ajuda o design a alinhar seus esforços às metas de negócios. Quanto mais os designers puderem fazer isso, mais eles serão compreendidos. Quanto mais o design for valorizado na empresa como uma vantagem competitiva, mais crescerá o potencial para investimentos mais pesados.

Sobre as armadilhas da colaboração entre designers e desenvolvedores…

Quais são algumas das maiores armadilhas que designers e desenvolvedores que trabalham juntos se deparam?

Uma das maiores armadilhas é não ter uma linguagem compartilhada, não ter objetivos compartilhados e as proporções serem muito desproporcionais. Às vezes, há equipes multifuncionais com um designer e 75 engenheiros. Parece loucura, mas é bem comum.

A grande maioria dessas situações não são boas. Aquele designer solitário é um expatriado. Eles são um estranho em uma terra estranha onde nunca se encaixam na cultura... e seu sistema de valores é diferente do sistema de valores de todos os seus colegas.

Nesse ambiente, defender um recurso de UX é extremamente desafiador para um designer: “Devemos ter essa animação no produto porque vai criar uma experiência mais atraente…” quando há 75 engenheiros que dizem: “São 250 a mais linhas de código e dois dias extras de trabalho. Isso realmente vale a pena?" E provavelmente não é. Para eles, parecerá “geada”. Mas essas micro-interações animadas com um designer de UX realmente moldam a experiência do cliente. Eles não são a única coisa, mas são importantes.

Quando você tem essas proporções desiguais entre designers e desenvolvedores, isso se torna realmente problemático. No entanto, existem soluções. Empresas como o Slack resolvem esse problema com “design pareado”. Se houver um designer para 10 engenheiros em uma equipe e a mesma proporção em outra equipe, esses designers individuais passam cerca de oito horas por semana trabalhando juntos, apresentando soluções uns aos outros: “Eis como estou resolvendo esse problema, isso faz sentido para você? Existe uma maneira melhor de fazer isso?" Eles podem ajudar uns aos outros a se soltarem e não se sentirem como se estivessem em uma ilha.

Sobre designers que transmitem a importância do UX…

Como os designers podem enfatizar a importância do design centrado no ser humano com desenvolvedores que realmente não entendem de HCD? Por exemplo, como os designers transmitem que adicionar recursos não necessariamente atende ao cliente, que a experiência de usar o produto é mais importante do que seus recursos?

Existem algumas maneiras eficazes de fazer isso. A maioria dos designers provavelmente fez isso de maneira ineficaz, dizendo diretamente aos desenvolvedores: “Ei, adicionar mais recursos não melhora a experiência. As pessoas dizem que querem, mas na verdade isso só torna o produto mais complicado”, e os desenvolvedores provavelmente responderão: “Acho que você não está certo, isso é uma opinião. Ouvimos isso de nossos clientes, então devemos segui-los.”

É melhor não enfrentá-lo de frente, mas fazê-lo de forma lateral e dizer: “Vamos entender melhor o espaço do problema juntos”. Comprei o almoço para nós amanhã e combinei de mostrar a você cinco de nossos clientes usando nosso produto.

Já vi engenheiros se contorcendo em seus assentos quando observam um cliente realmente usando o produto e percebem: “Fizemos algo que é muito difícil de usar, e as pessoas ficam frustradas com isso”. Os engenheiros querem fazer um ótimo trabalho, assim como os designers. Muitas vezes, eles simplesmente não têm a oportunidade de ver o resultado de seu trabalho.

Você provavelmente já ouviu falar de Jeff Gothelf pregar que devemos nos concentrar em “resultados, não resultados”. Essa é outra maneira de reformular nosso pensamento, de que uma saída é: “enviamos mais cinco recursos” versus um resultado: “reduzimos o churn em 10%”.

Sobre o futuro da colaboração entre designers e desenvolvedores…

Você conversa com muitas empresas e vê muitas equipes de design e desenvolvedores trabalhando juntas. As ferramentas, ambientes e metodologias estão mudando. O que o futuro reserva para o relacionamento designer/desenvolvedor?

Há água salobra se desenvolvendo – quando água salgada e água doce se misturam – há uma coalescência de ferramentas de engenharia e design. Em vez de um processo que parece uma transferência onde tudo que é design está aqui e tudo que é engenharia está lá, eles começam a se misturar.

Nessa medida, estamos vendo designers gastando muito tempo no Jira, pensando em histórias de usuários e começando a pensar também com uma mentalidade de engenharia. E vice-versa, estamos vendo engenheiros usando ferramentas como o InVision Inspect, onde eles veem as especificações e o detalhamento de um sistema de design e entendem os componentes de como tudo se encaixa. Devido a essas ferramentas e uma mistura de disciplinas, um entendimento compartilhado está se desenvolvendo.

Seja um desenvolvedor ou um designer, você pode começar a entender a perspectiva de seu parceiro-chave. Isso não significa que você precisa ser um programador especialista como designer. Mas não vai matar um designer se ele souber um pouco sobre como usar o Git e como escrever HTML e CSS, talvez um pouco de JavaScript. Isso vai realmente ajudar os designers a entender como as coisas são construídas e promover uma melhor colaboração entre designers e desenvolvedores.

Leia mais no Blog Toptal Design:

• Como abordar o design para desenvolvedores
• Design Talks: Pesquisa em Ação com a pesquisadora de UX Caitria O'Neill
• Design Talks: Design Emocionalmente Inteligente com Pamela Pavliscak
• Design Talks: A busca do design baseado em valor com Nick Disabato
• Como fazer a transição de UX Designer para UX Consultant