UX designers aprendendo a código ajuda, mas exige contexto

A resposta é: depende

O artigo de Kasturika, publicado pela Interaction Design Foundation (IxDF), argumenta que a pergunta sobre se designers de UX devem aprender a programar não tem resposta única: como em toda decisão de design, "depende". Trabalhar com produtos digitais pode não exigir escrever código, mas conhecer como construir o produto projetado é uma vantagem.

O texto contextualiza a evolução da profissão: nos primórdios da web, designers gráficos aprendiam HTML e CSS para se tornarem web designers. Após o lançamento do iPhone e do App Store em 2007, a demanda por experiências interativas ricas exigiu uma abordagem mais holística da experiência do usuário. Os primeiros designers de UX vieram do design gráfico e web, o que gerou expectativas amplas sobre a profissão, que hoje reúne disciplinas como design industrial, interação humano-computador, etnografia, psicologia e design visual.

Argumentos a favor de aprender a programar

Conhecer os materiais do produto: assim como um estilista conhece tecidos ou um arquiteto entende as possibilidades construtivas de um projeto, o designer de UX precisa saber como funcionam as tecnologias que dão vida ao produto digital.

Fluxos de trabalho mais rápidos: entender tecnologia permite ao designer identificar e implementar soluções sem ir e volta constante com a equipe de desenvolvimento, economizando tempo e reduzindo iterações.

Essencial em organizações enxutas: empresas que buscam maximizar valor com poucos recursos - seja por metodologia enxuta ou por restrições de financiamento, como startups bootstrapped - preferem contratar profissionais com múltiplas habilidades.

Argumentos contra

Scope creep: código não é o único "material" de um produto digital. A jornada do usuário inclui mensagem da marca, microcopy, termos de serviço, política de dados e atendimento. Exigir que o designer domine todos esses processos expandiria indefinidamente o escopo do trabalho.

Visão tunelada: conhecer as restrições técnicas pode limitar o pensamento do designer, que se prende a detalhes técnicos em vez de pensar primeiro nas pessoas - o oposto do design centrado no usuário.

Má utilização de recursos: linguagens e frameworks se tornam obsoletos rapidamente, e é mais fácil para um desenvolvedor se adaptar. O designer pode dedicar seu tempo a atividades de design. Além disso, ferramentas low-code e de arrastar e soltar podem eliminar a necessidade de escrever código.

I-persona versus T-persona

O artigo introduz os conceitos de I-persona (profundidade em um único campo) e T-persona (profundidade em um domínio mais conhecimento amplo de outras áreas). Times com mais T-personas se comunicam melhor e entregam produtos mais rapidamente, com menos iterações. Tim Brown, então CEO da IDEO, defende a contratação de pessoas em formato T: quando todos são I-shaped, a colaboração vira negociação entre pontos de vista, e o resultado é um "menor denominador comum", nunca espetacular.

Um exemplo hipotético ilustra o problema: um designer propõe reestruturar a navegação de um app, o desenvolvedor diz que a arquitetura atual não suporta, e o time perde tempo em propostas e argumentos. Se o designer entendesse os desafios técnicos, poderia sugerir alternativas.

Conclusão

Mais relevante que saber programar é entender as diferentes partes que compõem a solução - distinguir a capacidade de compreender uma tecnologia da capacidade de implementá-la. Em times pequenos e bootstrapped, o designer pode precisar construir o produto; em times maiores, conhecer a fundo linguagens de programação pode não ser necessário. O conhecimento de como as peças se encaixam melhora a comunicação e a eficiência do desenvolvimento. O ônus de entender o trabalho dos outros, conclui o artigo, é de todos os membros do time, não apenas dos designers.