Problemas entre Designers e Programadores e possíveis soluções
Publicado originalmente em Codesigners.cc por Brunão.
Problemas na relação entre Designers e Programadores são comuns e acredito que sempre existirão em algum nível. Designers acusando o programador de ser preguiçoso e não prestar atenção no alinhamento ou cores exatas, e programadores acusando designers de falta de padrão ou de não saberem o tanto de trabalho que dá pra fazer certos tipos de coisas.
Como alguém que já atuou nos dois times, posso dizer que ambos têm razão mas também ambos estão errados. Se você só jogou em um único time você deve estar achando que eu estou apenas querendo ser simpático com ambos os lados, mas não… não é isso… tanto designers quanto programadores estão certos e errados!
Sendo assim, vou citar abaixo três situações onde pude presenciar esse tipo de problema, e como acredito que eles possam ser resolvidos!
1 — Inconsistência no Layout
Problema: Falta de padrão em elementos de interface (botões, formulários, tipografia, etc)
Causa: Designer que não manja de UI Design
Solução: Aprenda a desenvolver UI Design System
Quando eu era apenas um girino no design e não entendia muito bem esse negócio de UI design, eu fazia layouts no Photoshop. Os layouts não tinham medida, pois o Photoshop não é uma ferramenta para isso… e o que acontecia? Alguns elementos saíam com tamanhos diferentes visualmente.
Eu precisava enviar um documento extra ao programador com todas as medidas de cada elemento, cores, espaçamento entre um elemento e outro, etc… dava um trabalhão e eu sempre recebia elogios dos programadores por este trabalho técnico. A maioria dos programadores que trabalhei dizia que os designers geralmente mandavam apenas o arquivo .psd do photoshop e um grande “se vira“.
Hoje temos softwares bastante otimizados para que esse tipo de coisa não aconteça, tais como o Sketch, o Adobe XD, ou até mesmo qualquer outro software de desenho vetorial que lhe permita colocar medidas nos elementos.
O pulo do gato está em saber fazer UI Design. Abordarei em artigos futuros este tema, mas apenas para que você possa ter uma noção do que estou falando, vou usar o elemento “botão” como exemplo.
Se você fizer uma interface com 15 botões diferentes sem prever uma maneira lógica para isso, você vai fuder com a vida do programador. Masssss… se você fizer um botão pensando de forma “sistemática”, você pode ter o seguinte:
Elemento: Botão
Tamanhos: small | medium | large
Cores: blue | red | green | yellow | white
No exemplo acima, cada característica teria sua medida ou cor, e poderiam ser mescladas entre si (tamanho x cor), gerando uma nova variação do botão. Para o programador, é muito mais fácil ele realizar o trabalho dele pensando dessa forma sistemática, do que fazer 15 botões diferentes, cada um de um jeito, sem um sistema por trás.
Como referência, recomendo ao designer dar uma olhada nos seguintes Design Systems:
Carbon Design System (Mantido pela IBM)
Atlassian Design System
Muitos designers que não têm familiaridade com Sistemas de Interface (Design Systems) ou mesmo com código CSS acabam esbarrando neste problema, e fazendo layouts “à esmo”. Fazer interfaces sem um sistema de design atrapalha muito o tempo de desenvolvimento da programação, causa problemas futuros de manutenção de código e possivelmente diminui a performance do aplicativo ou website.
2 — Transições e Animações
Problema: Programador não executa as animações e transições de acordo com as especificações do designer, prejudicando a UX pensada pela equipe de design
Causa: Programador não sabe trabalhar muito bem com CSS ou mesmo não domina Javascript o suficiente para realizar efeitos de animação mais complexos
Solução: Programador deve se empenhar mais em entender animações com CSS, Javascript e SVG
No começo da minha carreira como designer de interfaces existia um software chamado Macromedia Flash, que posteriormente foi comprado pela Adobe. Ele era uma ferramenta híbrida entre animação e programação. Dava pra fazer uma série de animação inteira no Flash, como também dava pra programar um website.
Uma coisa que eu achava muito legal no Flash era quando se misturava as duas coisas. Existiam sites que eram verdadeiras obras de arte visuais, com interações muito criativas, e principalmente, bastante animação e transição.
Só deixando claro que quando digo animação em websites, me refiro aos elementos de interface e transições de uma sessão para outra.
Com a morte do Flash e os novos conceitos de Web 2.0 vindo a tona, a galera começou a se preocupar muito mais com usabilidade do que com aparência, e isso foi muito positivo. Contudo, em algum momento a preocupação com animações e transições criativas e, de certa forma complexas do ponto de vista de programação se perderam, e o que vimos por aí foi um monte de aplicativo e site “duros”.
Designers ficaram um pouco perdidos sem saber o que era possível se fazer com javascript, java e objective C, que são as linguagens de programação que passaram a ser mais utilizadas para desenvolver aplicativos nativos e híbridos. Arrisco dizer que apenas nos últimos 5 anos é que animações voltaram a ser introduzidas de uma maneira próxima ao que víamos nos sites feitos com Flash, mas dessa vez usando Swift ou Javascript.
UX Motion Concept Por Sergey Valiukh
Nos últimos dois anos os aplicativos de Prototipagem de UI/UX ganharam força, e junto com eles também vieram ferramentas de animação. Dessa forma, designers voltaram a projetar com mais frequência layouts que tenham esses recursos, e isso fudeu a vida de muito programador Front End.
Outro termo que que tenho visto recente é o tal do UX Motion. Confesso que não me aprofundei neste assunto, mas até onde entendi, trata-se dos designers que pensam e projeto exclusivamente essas transições para melhora da usabilidade de uma interface.
UX Motion Concept Por André Mion
Mas enfim, falei muito do lado do designer e não falei do programador. No meu entendimento, o que pude aprender convivendo com programadores é que a maioria deles estão preocupados em “fazer funcionar“, o famoso “BACK End“.
Para muitos programadores que conheci, a interface é apenas um receptáculo de informações que vem do banco de dados, e a função dele é fazer o código que faz a coisa toda funcionar. Ou seja, quando o usuário clicar em um botão X, o código dele irá resolver toda a burocracia de lógica de programação e banco de dados, e no final devolverá a informação correta para o browser, que irá se virar para mostrar isso na interface de acordo com o que o programador FRONT End tiver definido!
Quando partimos para o “como essa informação será mostrada na tela” o programador logo pensa: “ah, isso é coisa de designer…. só me manda o layout aí que eu dou um jeito”. E muuuuuuuitas vezes esse “dou um jeito” passa loooooonge do que a equipe de design projetou, e isso é um grande problema.
Este tipo de programador geralmente não gosta de fazer CSS ou simplesmente não quer se aprofundar neste tópico. Ele é o clássico programador Back End, capaz de configurar um servidor super complexo em 15 minutos, mas não consegue e nem gosta de fazer CSS, quiçá uma animação com JS e SVG.
Neste caso, para solucionar esta lacuna surgiram os programadores Front End… estes caras só trabalham com a parte da interface, mas também fazem bastante código de lógica para interagir com o Back End.
No mais, para resolver este problema acredito que é necessário o programador ser apaixonado por Front End e ter uma quedinha por UI Design… Não é um requisito, mas quando isso existe, o programador vibra tanto quando o desiger quando o resultado sai conforme o projetado.
Aprender a desenvolver animações e transições com CSS e Javascript não é uma tarefa muito árdua, apenas requer sair um pouco da zona de conforto e aprender um pouco mais sobre o assunto.
Recomendo aos programadores (e também designers) que queiram saber mais sobre animações para UI/UX, o trabalho da Sarah Drasner.
Alinhamentos e Sistema de Grid
Problema: O Designer não usa um sistema de Grid para desenvolver seu projeto de UI, ou quando usa o Programador não presta atenção ou não faz questão de alinhar os elementos precisamente
Causa: Designer que não conhece Sistemas de Grid, e programador desleixado que acha que alinhamento “pixel perfect” é frescura (não é!)
Solução: Melhoria na comunicação entre Designer e Programador. Equipes de design e dev mais integradas
Em ambiente de trabalho sempre rola muita provocação e zueira. Eu já trabalhei em uma software house onde eu era o único designer, então, muitas vezes o bullying era comigo.
Já ouvi todo tipo de brincadeira, mas uma que sempre me lembro é que, quando chegava minha hora de botar a mão na massa, o pessoal falava que era a hora de “passar o batom”. Eu entendo muito bem que era brincadeira, mas havia uma aura de atribuição de “inferioridade” ou “irrelevância”.
Demorou para o pessoal lá entender que design vende, que design faz toda a diferença, que design não é só “passar o batom”. Nessa hora, o programador precisa entender que se o software não vende ele perde o emprego dele… e que para o software vender, muitas vezes é mais uma questão de boa UX/UI do que de programação. Por essas e outras é que o programador deve sim implementar o layout à risca, pixel perfect!
Assim, toda vez que o designer cobrar um programador para que ele refaça o alinhamento do ícone; ou que o espaçamento era 20px e não 32px; ou que a animação deveria ter um easing-out de 200ms e não uma animação linear sem graça de 1s…. e muitas outras correções de interface, o Designer estará correto.
Felizmente esse pensamento de que design é dispensável mudou completamente ao longo dos últimos 7 ou 8 anos.
No mais, também temos que ver as dores do coleguinha programador e sermos solidários. Existem designers que simplesmente não têm conhecimento específico de UI design como já citei no primeiro tópico. Um erro recorrente em iniciantes é não utilizar um Sistema de Grid na hora de projetar uma interface.
O sistema de grid divide o layout em colunas (geralmente 12, mas também é possível ter mais colunas). Essa divisão ajuda a padronizar o alinhamento de elementos na tela, e facilita a vida do programador.
Só para contar um “causo”, uma vez peguei um projeto de website para realizar apenas a parte de programação. O designer da agência (que na verdade era um publicitário) me enviou o layout em um arquivo de Photoshop. O arquivo dele não tinha grid, nem linhas guias, nem tamanhos de elementos nem nada. Como muitas vezes a gente tenta ser legal e acaba sendo burro, eu “arrumei” o layout do cara encaixando em um sistema de grid de 12 colunas, padronizando os espaçamentos entre elementos, e melhorei vários outros aspectos que são tidos como padrões de um bom projeto de UI. Não alterei nada visualmente grande, apenas alinhamento e espaçamento. Na minha opinião ficou muito melhor.
Um dia depois que mostrei as modificações (e expliquei os motivos), recebo uma mensagem da pessoa dizendo que estava “tudo errado”. Tentei novamente explicar as melhorias que fiz e os porquês. Não teve jeito, o cara queria o layout torto e desalinhado mesmo, sem sistema algum de grid. E assim, eu desmanchei meu trabalho de melhoramento e refiz os espaçamentos e alinhamentos todos tortos e sem grid system. Foi a primeira vez na vida que fiz um projeto “pixel perfect torto”.
Um detalhe importante neste causo é que, o projeto do site não era de um site completamente orgânico e conceitual, com elementos de layout posicionados randomicamente. Era um projeto de site de empresa, dividido entre seções com 3 blocos horizontais, 2 e 1. Deu muito mais trabalho alinhar os elementos sem um grid system… alinhar torto dá mais trabalho.
Então, se você é designer e quer tudo muito bem alinhado, pense primeiro se seu projeto cabe em um sistema de grid, se sim, faça e ajude ao programador.
Conclusão
A relação entre designers e programadores pode ser um pouco difícil no começo, e acredito que quanto mais integrados trabalharem, e mais tentarem entender o lado um do outro, mais rápido e mais conciso será o resultado do projeto.
O Google apostou nisso e criou um processo de desenvolvimento interno chamado Google Design Sprint, vale a pena dar uma olhada.
Mas pense, se até o Google se preocupou com esse tipo de problema em integrar equipes distintas em prol de um melhor resultado final, porquê você não deveria? O melhor jeito pra resolver todo problema, como sempre, é conversar.
#paz
