Colaboração entre Product Designers e Developers

Como Product designers e seres perfeccionistas, o nosso objetivo é fazer com que o que construímos, seja implementado tal e qual como projetamos.

Por isso mesmo, é de extrema importância criar uma relação de confiança entre Design e Engenharia. Estas duas áreas são indissociáveis pelo que, quanto maior for a sinergia, menos desafiador será todo o processo.

A cooperação é crucial para que o processo seja rápido, coeso e fluído. Devemos discutir os requisitos de uma iniciativa antes de iniciar o projeto, por forma a identificar detalhes técnicos que podem afetar as nossas decisões.

Há uma energia muito especial quando duas mentes colaboram para resolver um problema. Designers e Developers contribuem com diferentes visões que são essenciais para o sucesso de um projeto.

| Porque é que isto é importante?

Um Designer pode criar um wireframe elementar, aparentemente intuitivo, mas cujo desenvolvimento não é viável. A simbiose entre Designers e Developers, evita retrocessos sucessivos no workflow.

Recentemente elaborei um estudo que averiguou a opinião de vários Developers face às vantagens da colaboração com Designers. Os principais pontos elencados foram:

#1 Melhor comunicação (os elementos da equipa sentem-se mais à vontade para fazerem questões e manifestarem preocupações);

#2 Melhor entendimento do processo de Design (Briefing / Research / Benchmarking / User testing / Critiques ); 

#3 Maior integração (participação do Designer em meetings de Engenharia, por ex.: Dailies, Planning, Refinement, Retrospective…);

#4 Menos design bugs (minimização de erros na implementação dos designs);

#5 As tasks são executadas de forma mais rápida (ausência de duplicação de tarefas e retrocessos);

#6 Trabalhamos como uma equipa multifacetada e unida.

| Mas engane-se se pensa que é um processo linear!

Para chegar a estes resultados, nem sempre é fácil. Designers e Developers pensam e trabalham de formas muito diferentes, pelo que é necessária transigência de ambas as áreas durante este processo. Face à divergência de ideologias, provavelmente já ouviu expressões como:

– “A feature funciona” → Nem sempre a equipa avalia corretamente a importância do design, a ponto de entender que um esforço acrescido na implementação do mesmo pode promover uma melhor experiência.

– “Está bem assim” → Maior proximidade ajuda a clarificar também as opções do Designer e a estimar cedências versus prioridades, de forma a atingir o melhor resultado possível.

– “Não temos tempo para isso” → Normalmente o foco das equipas de Engenharia é a velocidade de desenvolvimento e entrega do produto final, pelo que nem sempre é fácil “negociar” melhorias da feature.

| Consistência é o ponto chave

A consistência é um dos princípios basilares do design de produtos digitais. Face ao crescimento das empresas e decorrente formação de equipas cada vez maiores, é expectável que o volume de inconsistências aumente também.

Isto é o que acontece quando várias mudanças incrementais são coletadas ao longo do tempo e resultam numa experiência desconexa, incongruente e remendada. Embora possa ser um desafio resolver 100% das inconsistências, fazer o controlo de qualidade do produto é um grande passo no combate às mesmas.

Para isso, surge o Design QA.

| O que é o Design QA?

Classicamente, uma sprint de Engenharia, segue a estrutura ilustrada no esquema 1 abaixo. Assim, quando o desenvolvimento de um ticket está concluído, cabe ao Developer movê-lo para a fase de teste (QA tester).

Por outro lado, quando consideramos o controlo de qualidade de design obrigatório no processo, a estrutura da sprint de Engenharia, será semelhante ao Esquema 2 abaixo.

O Design QA (QA= Quality Assurance) consiste na revisão de specs, micro-interações e copywritting, etc., através da comparação entre developed design (o que o Developer desenvolveu) e handed-off design (o que foi entregue ao Developer pelo Designer), de forma a identificar inconsistências.  

Depois de aplicar este processo com as equipas de desenvolvimento com quem trabalho, denoto uma maior motivação para a execução dos designs entregues, assim como uma maior abertura para a discussão de experiência entre os vários elementos (Designers e Developers). Sinto que este é um primeiro passo para que hajam menos inconsistências e melhor trabalho de equipa entre estas duas grandes áreas.

Em suma, a fase de controlo de qualidade assume-se como uma oportunidade para o designer rever todo o trabalho desenvolvido, pelo que é fulcral que este processo faça parte da sprint de Engenharia e não seja omitido.

Experimentem!