Pair Design como estratégia de produtividade do time e a qualidade nas entregas de design

Pair Design

Um trabalho à quatro mãos. Com objetivos bem parecidos com Pair Programming, um método de programação no qual duas pessoas trabalham juntas em um único programa. Uma espécie de piloto e copiloto, e que também trocam seus papéis regularmente. Originalmente as duas técnicas foram pensadas dessa forma: Duas pessoas sentadas, lado a lado, no mesmo computador. Um tempo é estipulado — é definido de 10 a 15 minutos para cada rodada. Neste período, um dos profissionais “comanda” o projeto. O outro, dá feedbacks em tempo real. A pessoa que está no “comando” tem total liberdade para criar ou mudar o que havia sido feito nas rodadas anteriores: formas, textos, cores e tudo mais.

Mas para a nossa realidade, decidimos seguir apenas com o mindset dos modelos originais e adaptamos para a ideia de que: Pair Design, são dois profissionais que trabalham juntos para resolverem problemas relacionados ao mesmo produto. Ambos focados em soluções concretas, críticas e colaboração constante.

Por que envolver duas pessoas para fazer um trabalho que pode ser “tranquilamente” executado por uma?

E sim, depende. Optar pelo uso de pair design em um projeto também depende de alguns fatores. Um produto tem diversos problemas a serem resolvidos, o tempo todo. Com isso, após entender qual problema resolver primeiro, também é preciso avaliar o tamanho desse problema, os recursos do negócio, do time, prazos. Pair design não é aquela fórmula mágica que vai se aplicar para resolver todo e qualquer tipo de problema. Às vezes vai ser preciso apenas um designer para resolver um problema e tá tudo certo. A vida segue.

É preciso entender profundamente o problema que se quer resolver, distinguir o que é ruído do que é essencial e avaliar os recursos para saber utilizar as ferramentas mais adequadas de acordo com a realidade do problema e do negócio.

Afinal, UX Design também é sobre negócios. É um equilíbrio entre advogar pelos usuários de acordo com a realidade e os recursos do negócio. Imagine as seguintes situações: Ao passar meses em etapas de Discovery para projetar a melhor experiência possível e no fim desse ciclo não é possível passar para o Delivery por insuficiência de recursos. Ou no Kick-off, é percebido que o problema é grande demais e que para a o resultado da combinação de prazos e recursos ser positiva, seria necessário uso de pair de design e então, mesmo o negócio podendo dispor, foi preferível utilizar o mínimo de mão de obra realizando uma entrega mais ou menos ou até mesmo não entregar. É no mínimo frustrante, mal uso e desperdício de recursos.

Removendo obstáculos

Independente da estrutura em que você atua hoje, é possível aplicar a técnica de pair design e em diversos contextos. E bom, para entender como deu certo pra nós, um breve contexto: Atualmente, trabalhamos no modelo de Outsorcing em um sistema de cooperativas de crédito. A realidade atual do negócio exige viabilizar uma entrega rápida. Por isso, o nosso processo de trabalho atual é baseado em Discovery e Delivery. E também utilizamos a metodologia Scrum, com tribos e squads. Onde nós UX Designers, recebemos as demandas diretamente de um PO (Product Owner). Normalmente, cada tribo deve ter apenas um UX Designer, há excessões. Entretanto, a nossa squad realmente deveria ter apenas um profissional de UX.

O PO da nossa squad entendeu o tamanho do problema e após muitas argumentações e negociações, recebemos a notícia de que tínhamos um potencial problema para resolver e então, deveríamos unir forças e traçar o nosso processo de Design para a solução daquele problema.

Produtividade à quatro mãos

É importante destacar que Design também é subjetivo. O que parece óbvio para um pode não ser para o outro. O que funciona num contexto pode falhar em outro. As ferramentas que um está acostumado o outro pode não ter familiaridade ou apenas não gostar de usar. O nosso desafio era fazer o redesign de um portal de inscrições em eventos das cooperativas e o primeiro alinhamento foi iniciado por: “E aí como a gente vai fazer?” – Conversamos, conhecemos o background de cada uma, trocamos experiências. Enfim, nos conhecemos como designers pra entender como seguir e como resolver o problema da melhor forma possível não apenas para o negócio ou para o cooperado, mas também para nós.

Conversamos e entendemos que o cliente ainda está em processo de amadurecimento em relação a documentação. Então, combinamos o jogo. Todo o nosso trabalho seria documentado, não apenas no Figma, mas em uma apresentação executiva, documento que utilizamos bastante na ilegra. Compartilhei dois estudos de UX Reasearch que fizemos no início do ano para o mesmo cliente com a Anna (minha dupla) e decidimos levar como exemplo de boa prática de documentação. Contamos todo o nosso processo de design de uma forma em que todos os envolvidos ou até mesmo novos colegas que entrem pro time, possam entender o caminho percorrido até a potencial solução, continuar o trabalho, entender o que já foi ou está sendo feito na squad ou dentro da cooperativa.

Vamos contar bem resumidamente os nossos passos. Definimos um cronograma e dividimos as entregas em partes que seriam avaliadas entre os times de UX, tecnologia e negócio durante as sprints e validadas próximo do fim de cada sprint:

1 – Documentação

Após combinar o jogo e distribuir nossas tasks em um cronograma. Documentamos tudo o que sabíamos sobre o desafio naquele momento como: proporção da demanda, critérios de aceite, quais os benefícios para o negócio e o cooperado (usuário), métricas de avaliação de usabilidade, tipos de pesquisas possíveis, tipos de acesso, Matriz CSD, Mapa de Stakeholders, Avaliação heurística do produto atual;

2 – Pesquisa

Tivemos a sorte de encontrar dois estudos recentemente feitos pela ilegra, super completos que contém pesquisas com os cooperados e seus respectivos perfis, dados de suas dores, necessidades, preferências, motivações. E que serviram como referência para auxiliar na transformação digital e nos planejamentos estratégicos para futuras melhorias dentro do Sistema Ailos.

3 – Ideação

Com tantos dados reunidos, combinamos os principais dados extraídos dos estudos com a nossa avaliação heurística pra poder entender o que seria melhorado dentro da interface, não apenas pensando em UI, mas mudanças que gerassem impacto para os cooperados;

4 – Validação

Com o apoio dos times de negócio e de tecnologia, fizemos alinhamentos, atividades cocriativas, ajustamos aqui e ali. E então, chegamos à concepção de um de fluxo, wireframes, Service Blueprint, protótipo de alta fidelidade, avaliação heurística e jornada emocional do produto que estamos entregando, mapeando próximos passos e possíveis melhorias. Afinal, tudo na vida pode ser melhor. Por fim, mas não menos importante. Também entregamos a Apresentação Executiva. Que por sua vez, foi bastante aclamada por todos da nossa squad e também pelos coordenadores dos produtos.

 Assuma a mentalidade correta

Não se apegue ao viés de que talvez só tenha dado certo porque foi nesse contexto. Ou para os lobos solitários, “Isso nunca vai dar certo”. A força do trabalho colaborativo é real. E para o nosso contexto deu certo, não porque foram duas UX que atuaram no mesmo produto, ao mesmo tempo. E sim, porque acreditamos que daria certo, e envolvemos todos os interessados desde o início. Na verdade, quatro mãos colocaram em prática um desafio com o apoio de mais umas 20 mãos. A nossa realidade demandava que todo o processo de Discovery com um profissional de UX teria, uma duração de 6 meses. E passamos o bastão para a etapa de Delivery com 3 meses de trabalho.

Para ajudar a inspirar:

+++ Seja humilde;
+++ Peça ajuda;
+++ Não se sinta superior porque acha que sabe mais sobre determinado assunto e nem tenha vergonha de dizer: “Eu não sei. Me ensina?”;
+++ Compartilhe conhecimentos e troque experiências;
+++ Não ache que existe um mundo ideal: “Ah, mas no cliente x era melhor porque era assim”, “Ah porque esse é o jeito certo”. Será mesmo? Relaxe;
+++ Aprenda com os seus erros;
+++ Aceite a ideia dos outros e a lidar com opiniões contrárias;
+++ Dê espaço para o outro brilhar;
+++ Utilize a palavra “nós” quando estiver se comunicando;
+++ Estabeleça regras claras;
+++ Evite se prender apenas à sua parte;
+++ Monte um cronograma de tarefas;
+++ Trabalhe e dê o seu melhor.

Parece que foi fácil, certo? Mas não foi. Pra nós foi tudo muito difícil de ser aceito, tivemos ideias que foram cortadas por falta de recurso. Sim, tivemos várias. Não se apegue a usar ferramentas exatamente da forma que o exemplo indica, ou da forma em que elas foram concebidas. Desde que seja com bastante resiliência e humildade, não tenha medo de expor suas ideias de melhorias. Ouvimos muito durante as reuniões: “Fazemos dessa forma há 10 anos. Por que mudar?”, “Você tem certeza disso?”. Cada caso é um caso, cada organização tem a sua realidade.

Um grande abraço para os colegas de time e em especial para Anna Luisa Bengaly, foi muito bom aprender com todos. E você? Qual a sua realidade? Já trabalhou em dupla? Compartilhe suas experiências.