Trabalho como front-end há mais de 5 anos e minhas interações com pessoas de produto sempre me trouxeram percepções muito ricas de como o planejamento e criação interagem com o desenvolvimento.
Nesse artigo eu trago 5 pontos cruciais do que aprendi nessas interações.
1º Dica - Entre um breakpoint e outro, sempre manipule os elementos proporcionalmente
Nos breakpoints desktop, tablet e mobile o quadrado no centro fica 20% menor, mas e numa tela 545 x 1017px de dimensão?
Se você teve que fazer uma regra de 3 pra descobrir, saiba que no front-end tem que fazer a mesma coisa pra manter a proporção nos breakpoints que você não declara.
Prefira diminuir ou aumentar valores sem usar números mágicos, isso torna possível calcular o aspecto do componente proporcionalmente com base em qualquer dimensão de tela.
No exemplo abaixo o padding (espaçamento interno) das variantes de tamanho dos botões abaixo aumenta em 4px entre si, isso faz com que possamos declarar algo como:
.btn {
padding: calc(
var(--btn-base-size) + (
var(--btn-increment) * var(--btn-size-index)
)
);
}
Essa expressão equivale à soma do tamanho base do padding do botão (8px) à 4 vezes o índice do tamanho do botão (0 - small, 1 - regular, 2 - large). Pensando em um botão do tipo large, seria 8 + (4 * 2) = 16.
Isso é útil pro desenvolvimento pois uma mudança na proporção geraria apenas uma alteração no código, incluir uma nova variante seria apenas incluir um novo índice. O mesmo layout pode ter por debaixo um código muito ou pouquíssimo resiliente, as decisões de layout que pessoas designers tomam são capazes de afetar nosso leque de opções.
2º Dica - Existem definições de acessibilidade pra textos, evite tomar essas decisões por estética
O tamanho mínimo indicado pra fontes de corpo de texto é 16px, o que pode parecer pequeno ao se desenvolver em frames maiores, levando designers menos experientes a criar componentes ou blocos de texto maiores do que o necessário.
Além do tamanho da fonte, temos padrões de altura de linha, largura de texto, contraste de figura e fundo e zoom. Esses padrões nos ajudam a criar layouts que funcionam pra todas as pessoas, não só as videntes neurotípicas.
No critério de sucesso 1.4.8 (Apresentação visual) da WCAG (em inglês) temos alguns exemplos de formatos que facilitam a legibilidade pra pessoas com deficiências cognitivas ou baixa visão, tradução livre:
- A largura total dos glifos não pode superar 80 caracteres (40 se caracteres CJK - Chinês, Japonês ou Coreano).
- O texto não pode estar no formato justificado (alinhado nas margens da direita e da esquerda).
- O espaçamento de linha (leading) é pelo menos "um espaço e meio" em parágrafos, e a distância entre parágrafos deve ser 1.5x maior que o espaçamento da linha.
Outro ponto é que pra web é melhor que as escalas de fontes sigam padrões compreensíveis. A escala de múltiplos de 4px por exemplo é útil pra adequação em dispositivos retina, mas também pra pessoas do front-end declararem rems sem números mágicos.
Abaixo, um artigo do Zack MacTavish sobre o grid system de 8px, em inglês.
Medium
Deixem o golden ratio pro design gráfico, por favor!
3º Dica - Não nomeiem seus tokens de forma arbitrária
Por exemplo, tokens de cor com nomes como deep-pink ou brand-grey não definem o contexto da aplicação (fill, background, border, etc), não indicam o estado que os utiliza (default, active, hover, pressed, etc).
Essas convenções permitem que criemos melhores tokens na aplicação sem precisar constantemente consultar o Figma ou zero-height pra saber pra que serve ou qual aplicação desses tokens.
Eles serem agnósticos de cor é importante pra possibilitar dark mode ou white label precisar "traduzi-los".
Um exemplo dessa tradução pra dark mode é a lib de CSS Open Props.
Supondo que a aplicação tem dark mode, se criássemos apenas tokens de cor como purple-200 ou orange-light, faria sentido substituir esses mesmos tokens por uma cor mais escura ou diferente?
Quando criamos tokens referentes a contexto e estado é pra evitar a perda de semântica de tokens específicos.
Design tokens cheatsheet, Oscar Gonzales - 2021, em inglês
4ª Dica - Evitem criar experiências de leitura diferentes do desktop pro mobile
A decisão de reorganizar ou sumir com elementos nos breakpoints menores não pode ser arbitrária. Sua hierarquia visual só é útil pra pessoas videntes, mais gente do que você imagina vai ler o site como texto ou navegar ele através do teclado.
Uma sequência de conteúdo com significado é um dos pilares mais básicos de uma boa acessibilidade e isso é problema seu também, designer. Critério de sucesso 1.3.2, Sequência com significado, da WCAG (em inglês).
A experiência mobile precisa mudar? Experimente ler seu layout como um texto corrido, esse copy ainda precisa fazer sentido!
5ª Dica - Texto alternativo e contraste é problema de designer também
Toda imagem que vem sem indicação de texto alternativo ou todo botão de ícone que vem sem label da ação é um momento que uma pessoa desenvolvedora precisa atuar como UX Writer.
Não esqueçam que todo problema de contraste começa no Figma primeiro!
Cês adicionariam alguma dica aqui? Tem algo que não faz sentido? Bora conversar!
Top comments (0)