Para designers com amor (uma carta de um desenvolvedor front-end)

Caros desenhistas,

Esta carta está se formando há anos. Partes dele foram entregues em discurso e por escrito a vários designers durante um longo período de tempo.

No entanto, sempre tive medo de publicá-lo por medo de que isso implicasse o designer ou cliente atual com quem estou trabalhando. Portanto, antes de prosseguir, gostaria de enfatizar que esta não é uma queixa específica, mas sim uma lista detalhada de 18 anos de divergências.

Trabalhamos juntos há quase duas décadas, e cada arquivo PSD que você me enviou teve (mais ou menos) os mesmos problemas. Perdoe-me então pela indecência de tentar ensinar-lhe o seu trabalho.

Não pretendo ensiná-lo sobre gráficos ou estética. Não vou me aprofundar em tipografia, legibilidade ou uso de espaços em branco.

Em vez disso, gostaria de explicar como os frutos do seu trabalho influenciam o meu.

Gostaria de lembrá-lo do que é necessário para reproduzir designs como páginas da Web com pixels perfeitos. Eu gostaria de dizer a você como seus arquivos de design serão usados ​​para documentação e como as imagens que você cria determinam as tecnologias usadas – até os níveis básicos de escalabilidade e desempenho.

Além disso, gostaria de demonstrar o que pode ser feito de maneira rápida e fácil e o que gerará uma sobrecarga que arrastará toda a produção para um rastejamento.

E acima de tudo, gostaria de lembrá-lo que a imagem que você está criando agora será transformada em um ser vivo que interage e responde, que se comunica com milhares de indivíduos diferentes, que precisa ensiná-los e aprender com eles. -los da maneira mais fácil possível. Tanto para ele quanto para eles.

Projetando para Documentação

Em primeiro lugar, gostaria de lembrá-lo que os arquivos PSD que você está produzindo não são apenas a fonte das imagens para o cliente aprovar, eles também são documentação técnica e materiais de origem para desenvolvedores. Portanto, mantenha suas camadas e grupos arrumados, organizados e nomeados .

Anote seu projeto. Crie um arquivo separado com as convenções que você usou ou anote-as em uma camada oculta separada.

Diga-me quais fontes você usou para quê. Deixe-me saber quais cores, espaçamentos e contextos usar. Eu preciso saber.

Também preciso saber o que extrapolar se nenhum design tiver sido feito para um recurso específico.

Acho que o que estou tentando dizer é: se possível, crie um breve guia de estilo para o produto que você está projetando.

Para o nosso bem, ao adicionar blocos de texto padrão – como títulos – adicione um retângulo atrás deles para indicar o espaçamento ao redor deles. Isso deve permitir que você os coloque consistentemente todas as vezes. Se isso for muito trabalho, pelo menos indique qual exemplo no documento é canônico.

Não posso dizer com que frequência acho que os títulos são colocados a olho nu para que se ajustem visualmente à única instância em que estão sendo colocados, mas quando medidos, revelam que cada um tem seu próprio espaçamento individual.

O mesmo vale para blocos de conteúdo. Se você tiver uma lista de blocos de conteúdo diferentes, espalhe-os de forma consistente.

Falarei mais na seção Designing for Content , mas não assuma que seus títulos sempre estarão em uma linha e use essa informação no arquivo.

Eu continuo me deparando com esses títulos que têm tamanho de fonte 22px e uma altura de linha de 92px (obviamente copie e cole do título da página principal). As configurações escolhidas são relevantes mesmo que não alterem visualmente o arquivo exportado.

Projetando para a Tecnologia

Há dois lados para isso: o que pode ser feito e o que é apropriado para o meio.

Embora estejamos chegando rapidamente ao ponto em que tudo será tecnicamente possível para o desenvolvimento de sites (se nada mais, ainda posso desenhá-lo pixel por pixel usando tela), muitas dessas soluções não estão prontas para produção.

O fato de você ter encontrado um exemplo em que alguém combinou com sucesso WebGL 3D com desfoque CSS mais máscaras de filtro para uma página de demonstração não significa que você pode usar isso como um painel de paralaxe de janela inteira em um aplicativo de página única.

E se você realmente quiser andar na vanguarda, consulte seu desenvolvedor antes de enviar o design para aprovação. Caso contrário, será difícil fazer o cliente se contentar com menos.

Se você realmente quiser testar as bordas, e se quiser experimentá-lo por diversão, entre em contato comigo em particular. Eu amo criar coisas assim tanto quanto você. Só não coloque essas coisas em um projeto de produção orçado.

Além dessas coisas – além de testar os limites do que pode ser feito, tente ser sensível e sensato em relação ao que deve ser feito .

Você não é um artista gráfico; Você é mais do que isso, você é um designer.

Você não está apenas projetando-o para parecer de uma determinada maneira, você também precisa projetá-lo para funcionar de uma determinada maneira, comunicar e se comportar de uma determinada maneira.

Para ir para o clichê familiar para designers em todos os lugares: de que adianta uma cadeira linda se ninguém pode sentar nela ?

Você deve incorporar velocidade de carregamento, velocidade de execução e facilidade de uso em seu design para que ele seja um design em vez de uma imagem.

Tente alcançar o máximo possível apenas com HTML e CSS. Evite usar recursos bonitos que estão disponíveis no Photoshop. Não use mistura! Não use negrito falso e itálico falso.

A menos que você pretenda que o elemento seja uma imagem, não use filtros – além das sombras mais simples.

Não me faça calcular ou escolher as cores porque você usou preenchimentos de cores misturadas. Por favor, não falsifique imagens transparentes usando overlay blending; Eu realmente preciso de uma imagem transparente no site.

Se estivermos usando um framework front-end, como o Bootstrap, muitos desses problemas já estarão resolvidos, então saiba como é feito e como pode ser modificado. Não vá simplesmente projetando algo não relacionado.

Se o seu design não estiver alinhado com o que o framework faz, implementá-lo não é implementar o design. Em vez disso, acabamos substituindo seletivamente o framework, para que ele não atrapalhe nosso design e, em seguida, implementando-o do zero. A carga de trabalho dobra em vez de reduzir pela metade.

E, finalmente, não use mais de três fontes – ou variantes de fonte – no site. Se você precisa de seis pesos diferentes, cada um com suas próprias variantes regulares e itálicas, você não está mais projetando para a web.

Projetando para Interatividade

Este é um enorme. E esta carta foi originalmente escrita exclusivamente para este tópico. Você realmente precisa conhecer e entender todas as maneiras pelas quais os usuários e as funcionalidades podem interagir.

Vamos começar com as coisas mais simples: links.

Os links não têm apenas dois estados.

Na navegação que recebo, você sempre fornece designs para links e um link ativo (página atual).

Em outros casos, você geralmente fornece os estados base e hover .

Se você quiser ser um pouco amigável ao usuário, você deve ter designs distintos para os estados de base, foco e foco ( visitado e ativo também são bons para UX). E para navegação, um link e um link ativo têm todos os estados acima .

Ah, e não se atreva a alterar um layout de link entre os estados (variando a largura da borda, preenchimento e similares).

Da mesma forma, se não se parece com um botão, não tem plano de fundo. Período. Preencher um elemento de texto embutido é uma bagunça, e fundos de texto não preenchidos nunca serão suficientes.

Como vamos usar isso em dispositivos móveis, certifique-se de que haja espaço em branco suficiente entre os elementos interativos separados e que cada hitbox seja suficientemente grande. Eu acho que um mínimo de 42px em cada eixo é a norma.

Desenhe um retângulo invisível ou uma camada oculta mostrando os hitboxes; certifique-se de que eles não se sobreponham e que as interações do usuário sejam inequívocas.

Elementos de forma são ainda piores.

O caso mais comum que vejo é com os botões de opção e caixas de seleção. Os normais são feios! Então, você projeta o seu próprio, e me dá um estado marcado e não verificado, e se considera feito.

No entanto, há uma tabela multidimensional inteira de estados para uma caixa de seleção, e cada uma deve ser indicada visualmente ao usuário.

Temos os seguintes estados:

• Marcado ou desmarcado
• Passe o mouse ou não
• Foco ou não
• Ativado ou desativado
• Erro ou não

Cada um deles pode combinar com os outros.

Desativado impede algumas combinações (o foco e o foco geralmente são irrelevantes quando desativados), mas não todas (o erro verificado-desativado é um estado perfeitamente válido e informativo para uma caixa de seleção). Então acabamos com 16 estados habilitados e quatro desabilitados, dando um total de pelo menos 20 estados distintos. Por exemplo, os estados que você costuma me dar são check-not-not-enabled-not e unchecked-not-not-enabled-not nessa configuração.

Outros elementos de formulário podem não ter um estado marcado-desmarcado, mas podem estar vazios ou não vazios (mostrando o texto do espaço reservado). Eles também podem ter um estado informacional mais complexo, de modo que o caso de erro ou não pode ser tão complexo quanto o sucesso de erro de aviso neutro.

Além disso, você deve ter indicadores obrigatórios ou opcionais, juntamente com um layout e design claramente definidos para rótulos, ajuda de entrada e texto de erro.

E, se você realmente quer ser amigável ao usuário, precisa de estados pristine-set-dirty, indicando que o usuário nunca forneceu os dados, ou os dados já estão armazenados ou foram alterados, mas ainda não armazenados.

O que estou dizendo é: projetar para interatividade é difícil. E se você quiser alterar a aparência dos botões de opção, não faça isso com dois estados.

Apenas um ponto final sobre o design para interatividade: decida como é a interação. Ou seja, decida quais convenções você usará para elementos interativos e não as use em mais nada.

Não, você não tem permissão para usar a cor principal da sua marca para indicar links, especialmente se você usar a mesma solução para acentuar conteúdo importante!

Projetando para conteúdo

O layout ideal de cada elemento preenchido com conteúdo lipsum é bom o suficiente para apresentar ao cliente uma imagem para obter uma aprovação no estilo visual. Mas o design de conteúdo não começa nem termina aí.

Depois de ter uma ideia aproximada do que deseja fazer com o layout do conteúdo, lembre-se de que está trabalhando com conteúdo dinâmico. Há dois casos que você deve verificar para cada parte do conteúdo:

• E se houver muito disso?
• E se houver muito pouco dele (ou estiver totalmente ausente)?

Verifique o que acontece se o título for ridiculamente curto ou incomumente longo. Como deve ser o bloco de conteúdo se faltarem elementos cruciais? E se não houver imagem?

Se não houver conteúdo para uma seção de página, removemos a seção inteira – título, contêiner e tudo – ou mantemos a seção e exibimos algo como: “Nenhum artigo ainda, verifique mais tarde?” Melhor ainda: “Gostaria de ser notificado quando este conteúdo chegar? Assine a nossa newsletter!"

Tome as decisões! Então projete essas coisas!

Se você estiver criando um feed ou conteúdo carregado de uma fonte externa ou dinâmica, não se esqueça de incluir todos os erros e notificações. Na verdade, projete o meta-conteúdo de notificação da página para mostrar como ele é globalmente e, em seguida, mantenha essas convenções de design para notificar o usuário caso algo dê errado.

Evite botões de largura fixa e blocos de texto de altura fixa. E, se eu não disse isso antes, se você acha que sempre será uma linha de texto, você está errado! Agora, vá verificar a melhor maneira de torná-lo multilinha.

Certifique-se de que o mesmo conteúdo tenha a mesma estrutura.

Se o mesmo título estiver visível em vários lugares, não coloque uma palavra em negrito em um caso e outra em outro lugar!

Na verdade, tente evitar completamente as estruturas de formatação dentro dos títulos. Da mesma forma, não quebre o texto manualmente em um lugar, mas quebre-o de forma diferente em outro. Na verdade, não quebre o texto manualmente!

Essas coisas podem melhorar seu design, mas lembre-se de que o conteúdo provavelmente será inserido por meio de um CMS, e a pessoa que o insere pode não ver como ele é até que seja publicado ou pode até não ter as ferramentas para quebrar manualmente ou formatar o texto.

Design com as mesmas restrições que o conteúdo final terá – contêineres de texto de largura fixa e quebra automática de palavras. Se parecer feio assim, o design não é bom.

Projetando para Responsividade

Isso tem progredido muito recentemente. Pelo menos nos casos em que o celular é realmente projetado. Cada vez mais, deixamos o bootstrap descobrir e colocar band-aids nas rachaduras.

Independentemente disso, existem alguns princípios simples que você deve conhecer.

Primeiro, as variantes mobile e desktop não são páginas separadas. Eu sei que você sabe disso. Eles são simplesmente reflows da mesma página.

Simplificando, é o mesmo que trabalhar com texto alinhado à esquerda. A frase não altera a ordem das palavras ou letras apenas porque você a colocou em um recipiente menor.

Além disso, os grupos de conteúdo devem ser compartilhados em todos os layouts. Ao adicionar colunas, certifique-se de que as quebras de coluna sejam consistentes.

Além disso, suas convenções devem seguir a mesma estrutura para diferentes versões da página. O que significa que, se dois elementos parecem idênticos em um desktop, eles também devem ser idênticos em dispositivos móveis.

Ah, e se você quiser paralaxe, forneça uma imagem grande o suficiente para se mover. Se você encaixar ou cortar a imagem para que fique bem no arquivo que você está mostrando ao cliente, então não tenho nada para mexer.

Projetando exceções

Claro, exceções são sempre possíveis. Além disso, eles são necessários para que o produto pareça atraente e eficaz. No entanto, não os adicione na primeira passagem caixa por caixa.

Se você resolver o mesmo problema de design repetidamente, isso não funcionará, especialmente se você optar por uma solução diferente em cada instância.

Depois de ter feito todos os itens acima, você deve obter um design eficiente, estável e consistente (embora um pouco monótono). Agora é a hora de apimentar as coisas. Olhando para uma página como um todo, converse com o cliente para identificar os moneyshots – os itens que lhe darão mais retorno.

Trabalhamos juntos há anos e nossos clientes sempre ficaram satisfeitos com o resultado final.

É claro que vou pular se você perder alguns desses pontos, e quando o uso de um design complexo for justificado, escreverei a lógica de renderização em JavaScript, se necessário.

Vou intervir e justificar o trabalho extra para o cliente, se necessário. Caramba, eu venho projetando formulários e interatividade em cima dos designs recebidos há muito tempo, então isso não será um problema.

Eu só espero que, depois de ler isso, você tenha algumas dessas dicas em mente na próxima vez que trabalharmos juntos. Espero que eles informem seu trabalho e forneçam orientação quando você não souber o que fazer. Gostaria que você entendesse que nosso relacionamento é importante para mim e que não escrevi isso para magoá-lo, mas para melhorar nosso relacionamento.

Com amor,

Seu desenvolvedor front-end