Entre tapas e beijos
A relação Devs & Designers
Peço a devida licença poética para intitular este artigo falando sobre essa relação que me incomoda, mas me incomoda o fato de ela ser tão conturbada em alguns lugares, sendo que eu, particularmente, considero uma das melhores etapas do meu trabalho a conversa com o Front-end.
Acredito que o alinhamento na comunicação, entendimento do processo de desenvolvimento e os princípios de programação sejam a chave da resolução do conflito. Desenhar um banner, seja para impressão ou mesmo para web, é bem diferente de compor um elemento em html.
Vejamos esse banner que salvei no meu pinterest porque achei bonitinho:

Poderíamos usar essa arte exatamente assim no html e esteticamente ficaria perfeito. No entanto, os robôs do google não conseguiriam ler o que está escrito no texto e você perderia o SEO, e até mesmo se tornaria uma dor de cabeça no design responsivo, pois ficaria muito pequeno no mobile, ilegível.
A solução então seria colocar essa foto de background e escrever o texto em html. Nesse caso ai eu identifiquei uns 7 estilos no texto. Então, para escrever dessa forma no html teríamos uma nova dor de cabeça. Na verdade, a dor de cabeça não seria do Designer e sim do Front-end (brigaaaaaa). 7 estilos diferentes numa única tag (h1, h2, p, sei lá) ficaria algo mais ou menos assim:

Obs: deve ter forma melhor de fazer isso, meu html está em processo de evolução no momento :)
Mas é consenso que reproduzir esse layout é um tiro no pé. E olha que escrevi apenas o Html. Para cada classe “style_x” teríamos um bloco de código css para estilizar individualmente cada parte do texto. E eu não faço a menor idéia de como escrever o texto côncavo como na primeira linha e, ainda, têm os tracinhos e tal. Desenhar isso no illustrator é muito fácil, mas definitivamente no html não rola.
Vamos adequar nosso layout para a web?

Tudo bem, o primeiro está bem mais bonito mas quando falamos de layout web, precisamos pensar, acima de tudo, na função. Então deixamos a forma um pouquinho de lado ( Não que tenha ficado feio, né?)
Esse texto tem apenas um único estilo, está corrido dentro de uma tag, sem gambiarras. Podemos trabalhar com a sua responsividade sem problemas, com um código limpo e otimizado.

Demorou um pouco pra eu entender esse processo, mas foi revolucionário no meu “design”.
Uma vez que passei a desenhar as telas pensando nesse contexto, passei a ver um sorriso no rosto do Front.
Principalmente porque nos meus primeiros projetos nessa área, eu “tentei” aplicar regras de design editorial em um site. Hahaha, hoje dou risada mas a verdade é que corri um sério risco de sair voando pela janela do escritório.
Você pode até conseguir alinhar um texto num site como gostaria de vê-lo no layout de um livro ou revista, mas basta você mover o site para um outro dispositivo que a coisa vai quebrar todinha.
Ao projetar uma interface digital tenha em mente que ela precisa se adequar a vários formatos de tela e, também, a conteúdos dinâmicos.
#designResponsivo

Aqui eu reduzi a imagem e mantive o mesmo peso no texto. Ah, mas mudou a cor? Sim, não teria o menor problema mudar a cor e até o tamanho/peso da fonte quando movido pro mobile. Inclusive essa é a graça de um Designer desenhar o layout antes de o Front codificar. (Agora sei que preciso corrigir esse contraste e já passo o projeto com a cor especificada para o Front. )
Recomendo fortemente, ainda, começar pelo menor. Aqui onde trabalho levantamos pelo google analytics que temos um acesso muito significativo nos dispositivos de tela 320px, então a primeira coisa que faço no Sketch é criar uma artboard nesse tamanho, e desenhar o layout todinho nele. Depois levo para telas maiores.
#mobileFirst
Depois de começar a trabalhar dessa forma você passará a ser o Designer queridinho entre os Devs e pode ser até que eles te paguem uma coxinha na hora do café.
Mas se você quiser ganhar uma cerveja no HappyHour, recomendo alinhar o seu trabalho com o Front no modelo de design molecular.
#atomicDesign
Nessa metodologia, cada parte do sistema estará documentada em uma biblioteca. Por exemplo: Você terá na sua Library um botão com fonte e estilos já definidos, assim como as suas interações de mouse hover, mouse click, loading, feedback etc. Esse elemento estará presente em sua ferramenta, tanto a parte gráfica como o código. Assim que você utilizá-lo no seu layout, automaticamente já estará “programando” a tela. Então podemos demitir o Front? Não. Algumas empresas até exigem que o Designer também seja Front-end, mas aí é outra história. Nesse contexto, seu objetivo, no máximo, será entregar um protótipo de alta fidelidade navegável em html (vou falar disso no próximo artigo), e o programador até pode utilizar o seu código, mas o objetivo é que ele se preocupe com as melhores práticas de programação, uso de uma framework ,processadores de css, javaScrip e derivados etc. Você, como designer, não precisa se preocupar com isso. Entregando o protótipo em html em alta fidelidade já será o suficiente pra ganhar a sua cerveja no HappyHour, ok?
Outra grande vantagem do Atomic Design é que você monta o seu layout com peças já pré definidas, como montar um quebra-cabeça e, com isso, seu site ou sistema terá unidade visual, e você ganhará 1 pontinho com o Sr Nielsen.
Talvez eu escreva também sobre esse tema, veremos.
Inté mais!
