
Outro dia li um artigo que defendia que designers não devem mais programar. Bons argumentos, ele começa argumentando que programar é diferente de “saber programar” (isto sim o designer deve saber), mas questão é, quem escreve o código do front-end?
Pelo artigo, e pelo meu instinto, se o designer está escrevendo código, talvez esteja fazendo a coisa errada. Queria dar uma olhada melhor neste assunto.
O artigo traça um pequeno histórico da relação entre designers e programação (web). Nos últimos anos apareceram alguns facilitadores de programação (JQuery é um exemplo), e cada vez mais os designers passaram a meter a mão na graxa e programar a interface. Mas então ele diz que as interfaces tem ficado mais complexas, e conclui dizendo que o designer de UI está virando um designer de produto.
Concordo com o grosso do artigo, mas queria estender ele um pouco em três tópicos:
- ao enfrentar a programação o designer se distancia de questões mais estratégicas e gasta mais tempo (muito mais tempo) com os detalhes do operacional do que com a visão geral;
- se você programa, você fica especialista em uma linguagem, e para mim o que o designer faz de melhor é agnóstico, ele projeta, independente do suporte;
- o mais complicado deles, quando o designer diz como deve ser e implementa como é, vai ter que brigar consigo mesmo quando tiver que implementar algo que é difícil pacas.
Design e estratégia
O primeiro ponto é, o que faz um designer? O assunto é bem complexo e longe de ter um consenso, mas posso ao menos trazer algumas opiniões bem fundadas. O grande Bill Moggridge nos diz que as cinco competências essenciais do design são:
- To synthesize a solution from all of the relevant constraints, understanding everything that will make a difference to the result
- To frame, or reframe, the problem and objective
- To create and envision alternatives
- To select from those alternatives, knowing intuitively how to choose the best approach
- To visualize and prototype the intended solution
Interessante, não fala de programação ou implementação. No máximo especificação, e mesmo assim que ele diz “visualizar e prototipar”, não especificar.
Completando, trago aqui o Nigel Cross, que em um artigo de 1990 também busca elencar as habilidade centrais do design e lista:
- resolve ill-defined problems
- adopt solution-focussing strategies
- employ abductive/productive/appositional thinking
- use non-verbal, graphic/spatial modelling media
Parecidos né? E olhe que legal, o Moggridge fala especificamente de design de interação, já o Cross está falando de design como um todo. Design de interação nem existia como disciplina de design quando o artigo foi escrito.
O que quero dizer com isto? Que designer é designer, que faz uma série de coisas, e que estas coisas estão ligadas à compreender necessidades e gerar alternativas. O núcleo da atividade não é dependente de uma tecnologia.
Acho que a responsabilidade essencial do designer é dizer como algo deve funcionar não fazer com que funcione desta forma. Enquanto o designer está programando, quem está cuidando destas coisas? Ou elas simplesmente vão ter menos tempo?
Design e plataforma
OK, já projetei muito website e a tecnologia padrão é a mesma: HTML, CSS, JS, um pouco de PHP e MySQL no servidor. Aprendeu uma vez tá aprendido, certo? E nem é tão difícil.
Bom, mas e se você for projetar uma interface para TV digital? Ou um caixa de auto-atendimento de banco, uma pulseira, um óculos, um painel de carro ou uma porta automática? Ou pior, uma interface de voz tipo URA (estas de telefone, “disque 1 para…”)?
Cada vez mais, espero, vamos projetar coisas em suportes distintos, com tecnologias distintas, e portanto com linguagens de programação distintas. É a tal da “internet das coisas” ou “computação ubíqua” que se fala há bastante tempo.
Novamente bato na mesma tecla, o que o designer é bom em fazer é entender como algo deve funcionar. Botar para funcionar é parte deste problema, mas não vem depois e pode contar com outros profissionais, que são especializados nisto.
Além do mais, mesmo no arroz-com-feijão de HTML/CSS/JS hoje em dia já não é mais o mesmo, não no código final. Temos a minimização, a browserização, os “otimizadores de processo” (Less e Jade para citar alguns), que são essenciais para se fazer o código final, e que não são mais o HTML básico.
E veja bem, um bom programador tem que pensar em eficiência, em manutenção do código, em escalabilidade, em segurança, em testar o código que escreveu (o debugging). Isto acaba ficando bem complicado no final. E acho natural que fique assim, programação é complicado pacas mesmo, principalmente quando é bem feito.
Dois chapéus e uma cabeça
Aqui acho que o ponto mais ardiloso da história. Quanto mais o designer conhece uma tecnologia, mais à vontade ele fica com ela, mas também mais força ele tem que fazer para se distanciar dela. É uma faca de dois legumes.
Ao conhecer uma linguagem de programação, ou uma biblioteca JS, ou um ambiente de desenvolvimento, o designer implicitamente começa a saber o que é mais fácil de fazer naquela plataforma. Isto é muito bom, queremos soluções que sejam fáceis de serem executadas.
Mas antes de ser fácil de fazer, ela tem que ser a coisa certa a ser feita. Quando um designer escolhe uma alternativa por ela ser mais fácil de implementar, será que está fazendo a escolha certa? Será que ele está pensando no uso que vai ser feito, ou aqui ele está deixando de lado a sua responsabilidade principal e deixando que a tecnologia guie o projeto?
Não acho que o designer deve projetar coisas impossíveis, mas acho que deve partir dos designers a provocação para fazer coisas de formas diferentes. Acredito que a tecnologia deva responder à uma demanda, não o contrário.
Programação nunca mais?
Eu sei programar (e programo), mas o que defendo aqui é que esta não a competência essencial do designer de interação. Não deve ser este o diferencial que ele traz para um time. Senão ele vai ser um programador de front-end, e não um designer. Nada contra, um bom programador front-end é extremamente importante, mas daí quem é responsável pelo design? O designer vai ter tempo de fazer a programação e cuidar do que deveria estar cuidando? Ou um deles vai ficar para segundo plano?
E lembre, não existe projeto sem design. O design sempre vai existir, ele pode ser melhor ou pior, e deve ser responsabilidade do designer fazer força para ele ficar mais próximo do primeiro que do segundo. A responsabilidade da implementação não deveria cair nas costas do designer, ao meu ver.
E veja bem, no início do artigo eu disse “talvez esteja fazendo a coisa errada”. Acho que em algumas situações ele deve programar sim, mas isto fica para outro post.
Nota: Obrigado Guilhermo e Marcus, com quem eu troquei algumas ideias antes de escrever este post.









































































