
Guia de Sobrevivência para Designers
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.