Desenvolvedores “possuem” o código, então os designers não deveriam “possuir” a experiência?

Todos nós já estivemos lá. Você passou meses reunindo requisitos de negócios, elaborando jornadas de usuário complexas, criando elementos de interface de precisão e testando-os em uma amostra representativa de usuários, apenas para ver um produto final que tem pouca semelhança com a experiência desejada .

Talvez você devesse ter sido mais enérgico e insistido em uma abordagem ágil, apesar de acreditar que a organização não estava pronta? Talvez você devesse ter feito um trabalho melhor com seus portfólios de padrões, garantindo que os desenvolvedores usassem sua biblioteca de código modular em vez de criar cinco variações diferentes de um carrossel. Ou talvez você devesse ter se sentado ao lado da equipe de desenvolvimento todos os dias, certificando-se de que o que você projetou realmente aconteceu.

Leitura adicional no SmashingMag:

• Por que você deve incluir seu desenvolvedor no processo de design
• Colaboração em equipe e fechamento de lacunas de eficiência no design responsivo
• Designers e desenvolvedores jogando bem
• Como se comunicar efetivamente com os desenvolvedores

Em vez disso, você fica com uma confusão de elementos de interface do usuário, com toda a sutileza eliminada. Eles não podiam ver que você trabalhou por dias para acertar as transições, apenas para que eles caíssem em uma biblioteca de animação padrão? E de onde veio essa etapa extra de check-out. Aposto que o marketing jogou isso no último minuto. Você sabia que a integração seria difícil e que compromissos precisariam ser feitos, mas deveríamos facilitar a vida dos usuários aqui, não a equipe de tecnologia.

Claro, existem muitas boas razões pelas quais o site é assim. Diferentes equipes com diferentes níveis de habilidade trabalhando em diferentes partes do projeto, um monte de mudanças de última hora encurtando o ciclo de desenvolvimento e uma série de desafios técnicos. Ainda assim, por que a equipe de desenvolvimento não veio pedir sua opinião sobre as mudanças na interface do usuário? Você não mexe com o código deles, então por que eles têm que mudar seus designs? Especialmente quando o impacto nos negócios pode ser enorme! Você está ao virar da esquina e ficaria feliz em ajudar se eles tivessem pedido.

Embora a história acima possa ser fictícia, é um sentimento que ouço de todos os cantos do mundo do design, seja internamente ou do lado da agência. Uma experiência cuidadosamente trabalhada arruinada por uma equipe de desenvolvimento pesada.

Essa experiência me lembra uma notícia que vi em um canal de notícias local dos EUA há vários anos. Uma feira do condado estava realizando uma competição de resistência onde a última pessoa que permanecesse com a mão em uma caminhonete ganhava o prêmio. Costumo pensar que o design é como um jogo massivo de “toque no caminhão” , com a equipe de desenvolvimento sempre saindo com as chaves no final do concurso. Como a última palavra em uma discussão, a última pessoa a entrar em contato com o site detém todo o poder e pode ditar como ele funciona ou como ele se parece. Especialmente se eles alegarem que a experiência de destino específica não é “tecnicamente possível”, o que geralmente é uma abreviação de “realmente difícil”, “não posso me incomodar em fazer dessa maneira” ou “acho que há uma maneira melhor de fazer isso então vou puxar o cartão dev”.

Agora eu sei que estou sendo injustamente duro com os desenvolvedores aqui e não quero ser. Existem alguns tecnólogos incrivelmente talentosos por aí que realmente se preocupam com a usabilidade e querem fazer o melhor para o usuário. No entanto, muitas vezes parece que há um nível assimétrico de respeito entre as disciplinas devido à crença de que o design é fácil e, portanto, algo sobre o qual todos podem opinar, enquanto o desenvolvimento é difícil e apenas para os especialmente iniciados. Assim, embora os designers sejam incentivados (às vezes esperado) a envolver todos no processo de design, eles geralmente não têm o mesmo luxo.

Para ser honesto, não os culpo. Afinal, eu conheço o desenvolvimento suficiente para ser perigoso, então você seria um idiota se quisesse minha opinião sobre a estrutura do banco de dados e o desempenho do código (além do que eu acho que desempenho é uma coisa boa). Então, novamente, eu sei o suficiente para dizer quando os desenvolvedores estão falsificando as coisas e é sempre divertido voltar para eles com um protótipo funcional de algo que eles disseram ser impossível ou levar meses para implementar - mas eu discordo.

O problema é que eu acho que muitos desenvolvedores estão na mesma posição sobre design – eles simplesmente não percebem isso. Portanto, quando eles fazem uma alteração em um elemento de interface com base em algo que ouviram em uma conferência alguns anos atrás, podem estar faltando um contexto importante. Talvez isso tenha sido algo que você já tenha testado e descontado porque teve um desempenho ruim. Talvez você tenha escolhido esse elemento em detrimento de outro por um motivo específico, como acessibilidade? Ou talvez as opiniões dos desenvolvedores estivessem erradas, com base em como eles experimentam a web como superusuários em vez de um Jo comum.

Agora vamos esclarecer uma coisa aqui. Não estou dizendo que os desenvolvedores não devam mostrar interesse em design ou contribuir com o processo de design. Acredito firmemente no emparelhamento multifuncional e acho que algumas das melhores soluções de usabilidade emanam da equipe de tecnologia . Há também muitas pessoas talentosas por aí que abrangem uma infinidade de disciplinas. No entanto, em algum momento a experiência precisa ser de propriedade, e não acho que deve ser de propriedade da última pessoa a abrir o arquivo HTML e “tocar no caminhão”.

Então, se bons designers respeitam a habilidade e a experiência que os grandes desenvolvedores trazem para a mesa, que tal um pouco de paridade? Se os designers estão felizes que os desenvolvedores “possuam o código”, por que não mostrar uma quantidade semelhante de respeito e deixar os designers “dominarem a experiência” ?

Fazer isso é bastante simples. Se você se encontrar em uma situação em que não tem certeza de por que algo foi projetado de uma maneira específica e acha que poderia ser feito melhor, não se aprofunde e comece a fazer alterações . Da mesma forma, se você encontrar um obstáculo técnico e achar que tornaria sua vida mais fácil projetar algo de uma maneira diferente, converse com seu designer. Eles podem estar absolutamente bem com as alterações sugeridas ou podem querer ir embora e pensar em outras maneiras de resolver o mesmo problema.

Afinal, a colaboração vai nos dois sentidos. Portanto, se você não quiser que os designers comecem a “otimizar” seu código no servidor ativo, fora de seus processos de controle de versão, por favor, pare de fazer o mesmo com o design deles.