Olá! Esse vai ser um artigo bem diferente: o público-alvo são os designers.

Disclaimers:

• Meus textos sempre contém um tom de brincadeira. Se você se ofende fácil, é melhor não lê-lo.
• Nenhum designer ou programador foi ferido durante a escrita (não há garantias após a publicação).
• Eu sei que você xinga o front-end que bagunça as margens que você estipulou…
• O foco aqui são sistemas e sites para web, mas alguns conceitos podem se encaixar para outros produtos.

Como assim?

Quem me conhece, sabe que passo é longe da disciplina design. Apesar de me considerar um desenvolvedor de bastante bom senso nessa área, o designer da família é meu irmão. Mas, pelo menos, sei a diferença entre design e designer… hahaha

Por outro lado, nesses meus (quase) 10 anos de profissão (sendo pelo menos metade sofrendo na mão de trabalhando com designers), sei bastante sobre como desenvolvedores (principalmente os front-ends) desejam 5 minutos sem perder a amizade uma maior sinergia com os coleguinhas.

Por isso, finalmente temos um “guia de sobrevivência” para designers (e que minha senhora, que é designer, me perdoe).

01 – Documente a arquitetura

Até hoje, nunca encontrei um Arquiteto da Informação na vida real. Então geralmente essa peleja fica com a equipe de design. Principalmente quando é um site novo ou quando há uma reestruturação das informações.

Motivo: provavelmente o desenvolvedor não foi convidado para a reunião de design thinking e mesmo que tenha sido, não foi ele quem criou os menus e a navegação no layout novo, então, ou ele adivinha durante a implementação ou vai passar 1 mês te perturbando no Slack.

02 – Crie um guia de estilo consistente

A gente sabe que não se usam medidas fixas, afinal tudo é responsivo (e se não for, tá errado). Todavia, cada projeto tem suas particularidades como paleta de cores, maiores ou menores espaçamentos, tamanhos de font, etc…

Motivo 1: um documento do Google com a paleta de cores, grid e espaçamentos pode aumentar a produtividade do seu front-end. Quando criamos interfaces, costumamos ter um arquivo apenas para a lista de cores, por exemplo. Então vamos saber qual a color-primary, color-active, a cor das bordas, o tom de cinza nos separadores, etc…

Motivo 2: 50 tons de cinza pode até ser legal no meme, mas é um tanto frustante implementar uma cor de cinza para cada borda/separador do site… Provavelmente o desenvolvedor vai escolher uma por você (até porque ele não vai ficar conferindo cada uma).

03 – Use um grid

Já que estamos falando de produtividade, use um grid. A menos que seja um projeto bastante disruptivo (eu sei que adoram essa palavra) um grid padrão vai ajudar todo mundo.

Motivo: a maioria dos frameworks (código pronto) que vamos utilizar já possui grids para facilitar a responsividade do layout. Também ajuda a manter a consistência no tamanho dos espaçamentos e tudo o que o seu guia de estilo demandou.

04 – Use conteúdo real

Lembra que falei para documentar a arquitetura? Então… não faça um menu longe da realidade, ou seu desenvolvedor vai ter que se virar para fazer um dropdown, que você pensou que teria 3 itens de uma palavra, mostrar 40 itens de 3 linhas.

O mesmo serve para conteúdo de páginas. Por exemplo, está criando um site que terá conteúdo dinâmico? Faça o layout com todos os componentes: cabeçalhos de 1 a 6, lista numerada e não numerada, citação, itálico, negrito, links, parágrafos, imagens (todas as variações), e quaisquer outros elementos que você ache que vai ter.

E as imagens… nem todo mundo vai cortar as imagens como você quer. Então pense nisso… Confira se o seu CMS ou seu cliente dá suporte a tamanhos de imagens e se a proporção das imagens que existem “cabe” no seu layout.

Motivo 1: você quer o layout como você pensou, certo?

Motivo 2: a guerra entre responsividade e proporção das imagens é contínua. Sem falar de dificilmente haver garantia da escolha e criação proporcional das imagens. Então provavelmente seu desenvolvedor vai “forçar” o tamanho do elemento e colocar a imagem como “capa de fundo”. Isso garante que a imagem vai caber da melhor forma possível, mas uma parte dela pode ser perdida. Então mapeie e pense nas imagens que precisam ser mostradas em sua totalidade e nas imagens que servem como “fundo” (essa dica serve para a galera de conteúdo também).

05 – Exporte seus assets

Sabe as imagens? Exporte todas e entregue um ZIP para o coleguinha. Ele com certeza vai te oferecer um café/cerveja/suco de abacaxi com hortelã…

Fontes também. Ou então indique-as no guia de estilo, que eu falei mais acima. Se está na dúvida, faz uma busca no Google Fonts e aproveita e já manda o nome para o desenvolvedor.

E já que estamos falando de imagens e fontes, sabia que podemos transformar SVG em fontes de ícones? Então, a menos que você já esteja usando um pacote de ícones como FontAwesome ou criando um você mesmo, junte todos os SVGs e envie também.

Ah! Sabia que no Fontastic você pode criar um pacote com ícones de diversas fontes, ou enviar seus próprios SVGs?

Motivo 1: facilita a vida do front-end. Nem todos os sistemas online (Invision e Zeplin, por exemplo) conseguem identificar todas as imagens e permitir o download de todas. A maioria até vai, mas sempre falta aquele iconesinho do menu…

Motivo 2: Fontes de ícone ajudam na performance. São mais leves e responsivas do que imagens. Sem falar que você pode mudar a cor muito fácil, via CSS, sem precisar de um arquivo novo. Então, que tal começar a criar os pacotes de ícones com o compilado do que o seu projeto pede, ou quem sabe até criar novos pacotes com os SVGs que você criou? Seu desenvolvedor vai agradecer muito não ter que cuidar dessa parte e você ainda garante uma metodologia de manutenção, afinal é mais fácil para a equipe de design manter uma conta no Fontastic/Icomoon do que cada front-end.

06 – Pense em componentes

Geralmente o layout é uma série de componentes (e suas variações), certo? Botões são sempre botões, modais são sempre modais, alertas são sempre alertas… Acho que deu para entender, né?

Motivo: a gente pensa assim também. Então se houver uma página com todos os componentes, podemos criar um por um e depois só montar o layout de cada página do site. Isso facilita a manutenção, organização e reutilização do código.

07 – Responsivo é para todo mundo

Esqueça breakpoints. Ou não… mais saiba que há vida entre eles.

E essa é para os desenvolvedores também. Então cobrem deles.

Motivo: se não fica bom em todas as telas, não é responsivo. Lembra do grid? Então… ele se adapta à tela. Sendo assim, se você criar versões para dispositivo móveis, leve em consideração que a versão maior (ou menor) vai ter que se apertar ou expandir até chegar no breakpoint.

08 – Pense nas telas pequenas

Já que estamos falando de responsividade: nem todo mundo tem esse seu monitor lindo da LG de 40 polegadas. Então não exagere…

Motivo: em uma tela padrão de 1366 por 768, pode ser que não fique legal essas colunas com 5 blocos de imagens e texto… talvez só “caibam” 3. Então o seu desenvolvedor vai ter que apertar ou mudar o seu layout…

09 – Converse

Chame o seu desenvolvedor para conversar. Geralmente o cliente não tem 100% de certeza do que vai precisar e, as vezes, nem você (e nem o front-end também).

Motivo: além de ajudar um programador a se tornar mais sociável, você ainda consegue mapear tudo o que vai precisar fazer, afinal ele deve saber de uma ou duas páginas obscuras que vão precisar de layout. Também vai conseguir opinar sobre a viabilidade de algum recurso pensado.

10 – Explique todos os comportamentos

Lembra que falei que o front-end vai ter que adivinhar os elementos de navegação e as páginas que o site vai ter, se você não documentar a arquitetura? A mesma coisa aqui…

Motivo: um botão azul gigante com “Faça seu Pedido” pode ser um link, um modal ou até fazer o site dar duas voltar no próprio eixo, mas se você não disser como imaginou, o front-end dificilmente vai implementar como você quer. A mesma coisa para a busca, que pode se expandir, ficar no lugar do cabeçalho ou até tomar a tela toda. Nem se fala do menu, né? E esses são elementos mais óbvios: o coleguinha até pode propor algo ou descobrir como fazer pelos outros layouts, mas componentes menos triviais vão fazer o coitado chorar de noite (principalmente se tiver que refazer).

Chegamos ao fim!

Espero que tenham gostado e que esse guia ajude a aumentar a performance do seu time. Se você for desenvolvedor, não esqueça de mandar esse link para o seu designer preferido.

Sugestões e críticas? Basta deixar nos comentários.