Por que toda equipe de software precisa de um antropólogo?

Resposta curta: Entender as pessoas, os usuários, é a chave para construir um produto melhor

Esta é uma tradução livre e eu não sou o autor. O texto original é: Why Every Software Team Needs an Anthropologist, de Charles Pearson. Se quiser ler o original clique aqui.

Sem título, Sydney Cohen. Nem todas as imagens foram quibadas do original. Mas esta foi, hehe.

Há alguns meses, tive a honra de aparecer no podcast Design Details, apresentado por Bryn Jackson e Brian Lovin. Eu fui, eles disseram, o primeiro antropólogo e primeiro pesquisador a estar no podcast. Uhul, obrigado pela oportunidade! Mas, galera, sério, 159 episódios SEM um só pesquisador? Como eu disse no ar, se você acha que é difícil para o design conseguir um lugar à mesa, é ainda pior para nós, pesquisadores. (Amo vocês, caras!).

Finalmente, depois de tirar esse peso das costas e de um certo tempo atacando alguns petiscos, surgiu algo semelhante a uma conversa coerente sobre design e pesquisa. Em parte, tentei argumentar que toda equipe de start-up e de produto voltada para o cliente precisa de um antropólogo a bordo. Há muitos motivos para isso, que vou desdobrar a seguir, mas se você quiser entender seus usuários e usuárias, antropólogos e pesquisadores de design e de outras disciplinas podem ajudá-lo a fazer isso. Os antropólogos estudam as pessoas e como elas pensam, agem, sentem e vivem no mundo real. Fazemos isso por meio de pesquisa de campo etnográfica e passamos tempo observando e participando de seus mundos. Não sequestramos pessoas para um laboratório nem dependemos principalmente de pesquisas e dados quantitativos. O que as pessoas dizem que fazem pode ser muito diferente do que realmente fazem. Os dados são excelentes na identificação de tendências, mas a etnografia é adequada para entender POR QUE essas tendências estão acontecendo.

A Antropologia Cultural tem uma rica história no desenvolvimento de softwares e hardwares. A Xerox PARC talvez tenha sido a empresa que mais ficou famosa por ter incluído antropólogos nos seus quadros. Ainda assim, especialmente devido às tendências atuais no desenvolvimento de produtos que priorizam o usuário, há uma grande e crescente necessidade de antropólogos e pesquisadores de design. Humanos são criaturas complicadas, e a cultura e o contexto informam como alguém se relacionará com um determinado design ou tecnologia. Se você deseja criar produtos e experiências eficazes, conectar-se com os usuários e trabalhar a partir de insights empáticos e concretos é crucial. Os antropólogos podem construir essa base e ajudar sua equipe a ter sucesso nesse sentido.

Pied Piper [O Flautista] tem uma Flauta Quebrada

Vamos pegar a start-up favorita de todos agora [no caso em 2016] — Pied Piper. Pied Piper, para vocês que não viram o programa, é uma start-up fictícia apresentada no Vale do Silício, uma comédia que satiriza a tecnologia e o estilo de vida de uma start-up de maneira inteligente. Por três temporadas, vimos o CEO Richard Hendrix e sua equipe lutarem para construir e lançar sua plataforma com seu inovador “algoritmo de compressão intermediária”. Tem sido uma jornada tensa, mas hilária. Eles sempre parecem a um passo do sucesso, mas sempre acontece um revés. No final da 3ª temporada eles finalmente lançam o Pied Piper e tudo parece bem sucedido. Como espectador, relaxei. Jack Barker estava fora de cena. As taxas de download eram enormes. E pela primeira vez Gilfoyle e Dinesh estavam reconhecendo seu “bromance”. Tudo andava certo. Eles conseguiram, eu pensei.

Personagem Gavin Belson, CEO da Hooli em Silicon Valley. Quibado do original.

Mas eles não conseguiram. Por conta da atração exercida pela poderosa promessa de Pied Piper, as taxas de download iniciais foram respeitáveis, já que um grande número de pessoas foi atraído para experimentar a plataforma. Mas muito poucos acabaram usando o app de forma consistente. Aqui fomos mais uma vez confrontados com a perspectiva de fracasso. O que, hey!, acho que tá tudo bem. “Sucesso = Fracasso”, certo? Nem sempre! Fracasso pode ser só fracasso mesmo. Até mesmo Gavin Belson teve que se confrontar com isso na Hooli.

Sem qualquer compreensão da disparidade entre as taxas de download e os usuários médios diários, eles procuraram uma empresa de pesquisa de mercado para obter alguns insights rápidos. Por meio de um punhado de grupos focais superficiais, eles descobriram que havia uma grande confusão e frustração com a plataforma. Os usuários não sabiam dizer o que o Pied Piper fazia, muito menos usá-lo. O algoritmo e a arquitetura podiam estar ótimos, mas a experiência era terrível, deixando a promessa da “tecnologia de compressão intermediária” não cumprida. Em suma, Pied Piper não entregou.

Nosso amado CEO, espiando do outro lado do espelho bidirecional do laboratório durante os grupos focais, não conseguia acreditar, lamentando defensivamente: “Claramente, nenhuma dessas pessoas entendeu o ponto”. Já ouvi isso antes e tive que lutar contra isso na vida real. Realmente não há nada pior do que ter seus pressupostos básicos e trabalho árduo rejeitados, mas o problema aqui não é com os usuários. O problema foi justamente com o processo de desenvolvimento da Pied Piper, que levou a equipe de Belson a construir uma plataforma sem qualquer pesquisa real ou feedback loops dos usuários. Os usuários estavam okay, foi a equipe que não entendeu.

Recuperando-se da reação negativa do grupo focal no laboratório, Richard e Monica continuaram a discutir:

Richard: Ok! Bom, todos pra quem mostrei o beta adoraram.

Monica: Pra quem você deu o beta? Seus amigos, os engenheiros?

Richard: Bom, sim, Monica! Eu queria dar a pessoas que entenderiam o que estou tentando fazer, pra que pudesse obter um feedback útil. E com todo o respeito, eu dei a você, a única pessoa sem experiência em computação, e você disse que parecia projetado [engineered]… Ah, merda!

Monica: Sim! Você tá tentando vender a plataforma pra pessoas comuns, mas nunca realmente a colocou nas mãos de pessoas comuns.

Os erros cometidos pela equipe aqui são óbvios. A equipe do Pied Piper não saiu de sua “câmara de eco” e, no final das contas, falhou completamente em entender os valores e expectativas de seus usuários em potencial. Eles não projetaram o app com eles em mente. Consequentemente, os valores e suposições da equipe de engenharia, explícitos na plataforma, eram completamente irrelevantes para todos os outros.

Esta é uma anedota fictícia, mas não está muito longe dos problemas (autoinfligidos) que tantos enfrentaram e enfrentam no desenvolvimento de softwares. Tipo, eu imaginei qualquer outro pesquisador que estivesse por aí assistindo ao show, e pensei comigo mesmo, “cara, se eles tivessem um pesquisador a bordo isso tudo poderia ter sido evitado…”. E se eles tivessem um pesquisador? E se eles tivessem um/a antropólogo/a?

Apelando para compreensão e contexto aprofundados, um/a antropólogo/a poderia ter explorado não apenas os problemas com os quais os usuários lutam ao conectar seus dispositivos e conteúdos, mas também suas esperanças e desejos nessa busca. O que as pessoas querem compartilhar? Porque? Com quem? Como? Quais são seus pontos de referência para fazer isso? Em última análise, você está perguntando sobre pessoas, comunicação e relacionamentos. Responder a essas perguntas e gerar empatia e conexões emocionais simplesmente não é algo possível de acessar em um laboratório, através de um survey ou de grupos focais de pesquisa de marketing. Você precisa de um/a pesquisador/a que possa se conectar com as pessoas, passar tempo com elas em seus contextos, entender o que é significativo e, em seguida, trabalhar com a equipe para construir empatia, implementar insights de pesquisa e criar ciclos de feedback sustentáveis. Caso contrário, há um perigo real de que a promessa atraente de seu “algoritmo de compressão intermediária” caia por terra. Se sua flauta [pipe] quebrar, você ficará sem seguidores.

Isso nos leva a um ponto que pode não ser enfatizado com a devida frequência — Tecnologia é cultural e todo software é feito baseado em certos valores e premissas. A questão, então, se torna: você quer construir um software que reflita a visão de mundo de sua start-up ou equipe e se alinhe com suas expectativas (especialmente se sua equipe for fraca em diversidade)? Às vezes, raramente, essa resposta pode ser sim. Ou você prefere criar softwares e produtos baseados nos valores de seus/suas usuário/as finais?

Crie softwares e produtos baseados nos valores e expectativas de seus usuários finais — e não nos seus.

Então agora, enquanto eu pessoalmente espero ansiosamente pela 4ª temporada, a equipe está tendo que lidar com um problema muito caro e difícil. Se ao menos eles tivessem investido em um/a antropólogo/a... É sempre muito mais fácil e barato construir um produto consistente a partir dos valiosos conhecimento e feedback dos usuários do que lançar uma encrenca e iterar a partir daí. Mesmo se você tiver a chance de um redesenho [re-design], pode não haver mais recursos (ou mesmo vida).

Misturando Lean e Design Thinking

Pied Piper é uma ficção muito divertida, mas e na vida real? Como parte do meu trabalho atual com a InVision, passo muito tempo com equipes de design e produto. Percebi que algumas estão lutando com metodologias Lean. Lean favorece experimentação e iteração ágeis, favorecendo o lançamento do software mais cedo e a iteração com feedback. Lançando outputs cedo e frequentemente, os processos envolvem a elaboração de hipótese, teste, aprendizado e iteração. Velocidade é a chave, falhas ocasionais são esperadas e a abertura para novas direções e pivôs é fundamental.

Lean, na forma de processos ágeis e focados na metodologias scrum, é a forma dominante de desenvolvimento de software. No entanto, existem alguns problemas-chave com os quais as equipes estão lutando. Primeiro, não há foco substancial na descoberta e aprendizagem antes da engenharia de software (veja o artigo recente de Mike Davidson sobre Aprendizagem). Muitos/as estão começando a sentir que precisam de mais espaço inicial para definir problemas e experimentar soluções potenciais antes de passar para a engenharia. Segundo, há um desejo de fundamentar o desenvolvimento do produto, especialmente no que diz respeito ao trabalho de descoberta e definição, no usuário, nas pessoas. Isso envolve uma forma diferente de pesquisa.

Em teoria, o feedback do usuário é fundamental para as metodologias Lean. Impulsionando a iteração, os conceitos devem ser testados e validados (ou invalidados). Ainda assim, em primeiro lugar, na prática — talvez dada a ênfase na velocidade, iteração e lançamento— o feedback do usuário geralmente parece ficar em segundo plano. Quantas start-ups você conhece que contratam um/a pesquisador/a no dia 1? Dia 300? Quantos designers por aí acham que têm tempo suficiente para fazer suas próprias pesquisas? Em vez disso, com todos correndo a toda velocidade em um “vamos zarpar!” pique roda-na-gaiola-do-hamster, parece que o feedback é muitas vezes relegado às avaliações das reações de usuários/as no lançamento. Portanto, muitas vezes é construção » lançamento » avaliação de reação » repetição e enxágue [rinse]. Essa pode ser uma maneira perigosa de projetar e construir software, como Pied Piper aprendeu.

Em segundo lugar, e mais importante, há uma diferença fundamental entre a pesquisa UX que acompanha os modelos Lean e o tipo de abordagem centrada no usuário que muitos estão empreendendo ou desejando. A pesquisa não é o ponto de partida no Lean e não gera um entendimento profundo e contextual do espaço do problema e das pessoas envolvidas que se busca abordar. O usuário, em suma, não é o ponto de partida. Contexto e empatia não fundamentam projetos nem impulsionam o desenvolvimento de produtos — deixando uma abertura, ou um vazio, para equipes como a Pied Piper construirem produtos embebidos em seus próprios valores e premissas.

Consequentemente, estou notando times ávidos por descobertas e desenvolvimentos centrados no usuário, combinando Lean com métodos de Design Thinking (de empresas como Optimizely e IBM, passando pela InVision, onde estamos gastando tempo e energia construindo processos focados em descobertas). O Design Thinking é frequentemente descrito como uma “abordagem centrada no ser humano” para resolver problemas e criar novas ideias. Elevando pesquisa e design, o Design Thinking privilegia a compreensão, o contexto e a empatia aprofundados no problema e na experiência dos/as envolvidos/as. Conceitualmente, tudo flui e se fundamenta no usuário. É uma abordagem que prioriza o usuário, em vez de priorizar os recursos.

“Quando nós, designers, não sabemos quais problemas resolver, nós giramos nossas rodas. Tornamos os produtos mais bonitos quando podíamos estar atendendo às necessidades dos clientes e gerando valor real. Portanto, qualquer empresa que leve o design a sério deve levar a sério escutar os clientes”, Braden Kowitz. Mais uma tirada do original.

Como mostrado por uma pesquisa recente da Gartner, esse quadro é indubitavelmente alimentado em parte pela competição entre mais e mais empresas baseada na experiência do cliente. Uma galera acha que as abordagens centradas no usuário permitirão “substanciar tudo com a voz do usuário, 100% do tempo, para construir a coisa certa”, como me disse um gerente de design em uma icônica start-up de tecnologia. Sinalizando o desconforto que é comum com as metodologias Lean, parece que muitos/as não têm confiança em seus processos para construir “a coisa certa” e produzir os resultados desejados.

Ainda assim, é importante observar que as equipes não estão se afastando inteiramente do Lean, mas misturando abordagens centradas no usuário para criar estágios de descoberta e entrega de desenvolvimento de produto (veja, por exemplo, modelos de design em Duplo Diamante e o Scrum Dual-Track de Marty Cagan). Essa mudança, no entanto, afeta profundamente as funções e expectativas da pesquisa. A pesquisa de validação continua a ter um papel importante, mas há uma necessidade emergente de pesquisadores qualificados para lidar com as nuances das pessoas e dos espaços problemáticos. Concentrando-se mais na pesquisa de descoberta, na construção de conexões com os usuários e na geração de perguntas e conhecimentos aprofundados, as equipes precisam de pessoas fluentes em projetar e conduzir pesquisas centradas no ser humano. Os antropólogos, com sua caixa de ferramentas de teorias culturais e métodos etnográficos, são especialmente adequados para essa tarefa. Eis aqui os porquês:

1. Problemas são problemas de pessoas. [Problems are people problems.] Antropólogos culturais são excelentes para se conectar com as pessoas e desvendar as estruturas íntimas e complexas de nossas vidas. Essas habilidades podem ser (e têm sido) prontamente aplicadas para compreender os espaços de problemas, para decifrar o que os usuários valorizam e adivinhar se as soluções potenciais podem ressoar.
2. Antropólogos culturais inventaram e foram os pioneiros em métodos etnográficos e metodologias de pesquisa de campo. A condução de pesquisas onde as pessoas vivem, trabalham, comem e respiram produz uma visão inestimável que o trabalho focado em laboratório é incapaz de produzir. Apoiados em processos de descoberta, os antropólogos no campo podem aprender muito sobre pessoas, contextos e fazer conexões que eles próprios não conhecem ou compreendem totalmente.
3. O conhecimento concreto e detalhado de pessoas reais que os antropólogos produzem é muito mais valioso do que as personas. Personas são vagas, abstratas e, como John Maeda argumentou em uma entrevista a ser lançada em breve para a InVision, são um desserviço que cria uma distância entre times e usuários. Personas (como “Tom Soccer Dad”) são obras de ficção carregadas de suposições imaginativas (provavelmente estereotipadas). Somente entrando no mundo dos paizões do futebol você pode realmente entender o que os motiva.
4. Métodos etnográficos são flexíveis e podem utilizar qualquer combinação de métodos qualitativos e quantitativos, dependendo do problema em questão. A etnografia, embora baseada no trabalho de campo, nunca é rígida em sua abordagem. Em vez disso, deve sempre ser informada pelas perspectivas, experiências e habilidades únicas de todos os envolvidos. E quero enfatizar o todos — pesquisadores e participantes. Uma boa etnografia é inerentemente colaborativa. É um empreendimento criativo, que utiliza os recursos, habilidades e personalidades envolvidas para criar algo único. Você está sempre construindo pesquisas (e, em última análise, soluções) sob medida para o problema em questão.
5. Antropólogos/as têm um compromisso de longa data em desenvolver e trabalhar por meio & através da empatia, um princípio fundamental das abordagens que priorizam o usuário. Conexões emocionais e empáticas com os usuários são fundamentais para a construção de experiências que ressoam e importam, e os/as antropólogos/as são especialistas nisso.
6. Antropólogos culturais são treinados para focar na diferença, ao invés de universais ou generalizações. Ou seja, o valor está em compreender o que é único, especial e relevante em uma comunidade ou grupo de pessoas. O que o Facebook significa para as avós estadunidenses brancas de classe média? O que ele significa para seus netos? O que significa para jovens de 14 anos na Bielorrússia? Esses diferentes micro-universos terão ideias totalmente diferentes sobre o valor e a experiência da plataforma. Compreender as qualidades únicas dos usuários é extremamente valioso para as equipes de produto.
7. Antropólogos/as são treinados/as para deixar de lado suposições e noções pré-concebidas sobre um tópico de pesquisa e “ver de fora” [estranhar] um determinado problema, por assim dizer. Em outras palavras, temos a habilidade de descentrar nosso pensamento para explorar os fenômenos em questão partindo do ponto de vista do usuário, tanto quanto possível. Essa forma de perceber e pensar o mundo pode ajudar qualquer equipe a desafiar seus pressupostos e entendimentos.
8. Oferecemos não apenas observação, mas interpretação. Antropólogos/as possuem um background [cache] de estudos de caso e teoria cultural que ajuda a produzir percepções importantes. Nosso treinamento conceitual e kit de ferramentas também podem ampliar e aprofundar questões, abordagens e ideias em torno dos problemas em questão.
9. Com uma prática de pesquisa impregnada de etnografia, flexibilidade, empatia e diferença, antropólogos/as são adequados para trabalhar com as abordagens intuitivas e emocionais de muitos designers. Isso, em minha opinião, é um aspecto-chave. (Já vi muitos pesquisadores de UX lutando para afirmar rigidamente “sua ciência” em oposição diametral aos processos de design intuitivos e fluidos.)
10. Antropólogos trabalharam por muito tempo para dar voz e representação aos seus temas etnográficos. Essas habilidades são centrais para representar os usuários para os times e, em última análise, elevar a importância e a influência dos usuários no desenvolvimento do produto.

Cheguei aqui e VOILÁ! Quibei todas as imagens do original, não resisti. :)

Conclusão

Muitas vezes, as decisões são tomadas no desenvolvimento de software antes que os problemas sejam devidamente compreendidos. Frequentemente, como as equipes não conseguem envolver os usuários, o trabalho do produto é um trabalho de adivinhação. Há uma ansiedade crescente em torno de algumas das deficiências do Lean, mas também há ansiedade em se mover em direção a processos conduzidos pela descoberta. Alguns temem que o foco na descoberta diminua o ritmo da equipe. Alguns vêem isso como um desperdício de recursos por gastar muito tempo e energia em soluções de prototipagem — tipo “jogar código fora”?! Alguns vêem a pesquisa como acadêmica, obtusa e rígida — uma ameaça a um desenvolvimento de produtos flexível e dinâmico.

Porém, os modelos voltados para o usuário ou para o cliente podem não apenas gerar experiências e produtos bem-sucedidos, mas também eficientes. O compromisso com uma base sólida de pesquisa é fundamental. O tipo certo de pesquisa e pesquisador/a pode ajudar a construir um processo não apenas eficaz, mas também iterativo e ligeiro. Como argumentei aqui e em outros posts, a pesquisa pode e deve alcançar coisas objetivas. O conhecimento profundo de uma problemática é fundamental e ajudará a estabelecer empatia e os princípios orientadores necessários para fundamentar o design e a experiência do usuário. De igual importância, a etnografia pode estabelecer conexões com os usuários e alimentar ciclos de feedback iterativos e ricos.

Não há razão para pensar que o processo ficará lento. Na verdade, se uma equipe estiver disposta a envolver os pesquisadores certos e tornar os usuários parceiros significativos no desenvolvimento de produtos, eles podem tomar decisões ainda mais rapidamente, com mais confiança, e avançar com agilidade sem ter que voltar e repensar as principais suposições. Não é de admirar, então, que Phil Gilbert, gerente geral de design da IBM, declarou recentemente que: “O pesquisador de design foi a mais perturbadora das disciplinas de design que introduzimos — e de longe a mais transformadora”. De fato. Abrace um antropólogo hoje!

Okay! Esta definitivamente é a minha predileta, e eu não quibei do original, hehe. Preciso usar ela de novo em algum outro momento. Fonte.

[Nota do autor: argumentei aqui que os Antropólogos culturais são especialmente adequados para atender às necessidades de tendência de desenvolvimento de produtos que priorizam o usuário. Isso pode soar um pouco polêmico (e talvez egoísta), mas eu queria usar a Antropologia cultural para descobrir o que considero ser os critérios-chave para uma pesquisa que prioriza o usuário. Existem várias outras disciplinas proeminentes na pesquisa em design. Por exemplo, os programas de interação humano-computador, a Sociologia e a Stanford D-school adotam princípios antropológicos importantes como etnografia e empatia, e são centrais para a pesquisa de design contemporâneo. De forma alguma a pesquisa qualitativa é o único componente de um projeto de pesquisa que prioriza o usuário. Um programa de pesquisa em design abrangente deve envolver pesquisadores qualitativos e quantitativos trabalhando juntos para compreender qualquer problema ou fenômeno específico de diferentes ângulos.]

(Agradeço a Lea Hickman, Josh Aleksanyan, Sarah Hunt e Eli Woolery pelos comentários sobre os rascunhos. E meu muito obrigado a meu bom amigo e pintor Sydney Cohen, por me permitir usar seu trabalho artístico no texto.)

Charles Pearson é atualmente [2016] Principal Researcher da InVision.

Nota de edição/tradução: Mantive, como pude, o sentido da maioria das expressões idiomáticas. Também mantive algumas palavras grafadas em inglês (pra dar mais precisão aos conceitos) e todos os grifos — embora tenha adicionado mais alguns. Google Tradutor fez a maior parte do trabalho, btw, haha! Acho que essa discussão é muito importante e tem que ser cada vez mais levada adiante.