Info+News+Tech

Eu percorri um longo caminho como desenvolvedor web e trabalhei em equipes diferentes e com designers diferentes. Independentemente do número de pessoas e do tipo de projeto, sempre houve problemas semelhantes: desconfiança mútua ou até mesmo atitudes tendenciosas enfrentadas por desenvolvedores e designers de front-end, conceitos errôneos sobre o layout ou sistema de design, comunicação deficiente da equipe e outras coisas que trabalho impedido. Neste artigo, tentarei examinar alguns dos problemas e fornecer recomendações para resolvê-los.

Mitos sobre designers de UI / UX

Primeiro, gostaria de chamar sua atenção para o fato de que muitos desenvolvedores front-end são tendenciosos contra designers de UI / UX e não confiam neles. Mais adiante no texto, irei omitir o prefixo UI / UX e escrever simplesmente “designer”, significando designers de interface. Deixe-me destacar alguns mitos que impedem uma comunicação eficaz.

Meu designer nunca mudará seu layout

Este é um dos mitos mais comuns. Muitos desenvolvedores pensam que um layout para um designer é como uma pintura para um artista, ou seja, ele o terminou e nunca o mudará. Na realidade, não é tão ruim assim. À medida que os programadores continuam a trabalhar no código, eliminando o débito técnico e melhorando o código, os designers continuam a trabalhar em seus layouts. Se a equipe for grande, o layout pode até começar a viver sua própria vida. Na minha prática, quase todos os designers me encontravam no meio do caminho se eu pedisse para eles mudarem alguma coisa.

Mesmo no empreendimento mais profundo, onde os layouts passaram por vários estágios de aprovação, ainda encontramos uma oportunidade de fazer ajustes. Em qualquer caso, as mudanças nos layouts são inevitáveis ​​porque nem todas as hipóteses do designer podem ser testadas em usuários reais. Se você puder explicar claramente o motivo da mudança proposta (por exemplo, sua versão permite que você reduza o tempo de desenvolvimento pela metade ou se houver uma biblioteca pronta com o comportamento desejado, embora pareça um pouco diferente), você alcançará um compromisso com seu colega. Ele fará os ajustes necessários ou explicará por que sua versão é importante para o projeto.

Meu designer é o mais preguiçoso

Esse mito surge quando você pergunta a mesma coisa ao seu designer várias vezes, mas ele teimosamente ignora o seu pedido. Freqüentemente, há poucos designers em um projeto, e eles estão sempre sobrecarregados com trabalho e dívida técnica (como já mencionei acima, os designers também têm sua dívida técnica). Se você não pode continuar seu trabalho sem um designer, é melhor perguntar ao líder da equipe se há tarefas que você pode fazer enquanto espera pelo layout. Por exemplo, configure uma infraestrutura, um ambiente de teste ou qualquer outra coisa.

Se você não tem um líder de equipe, pergunte ao designer sobre seu trabalho atual e ajude-o a priorizar. Explique quais telas são necessárias primeiro e quais podem esperar. Talvez o seu designer esteja preparando um sistema de design para o projeto. Então é melhor não distraí-lo porque, como os programadores, eles sempre têm tarefas importantes enquanto trabalham nas quais é melhor não se distrair. Se você realmente precisa de algo, explique o porquê. Pergunte ao seu colega quando ele terá tempo para abordar o seu problema e tente não incomodá-lo até esse momento.

Meu designer apenas desenha layouts. Como ele sabe o que é melhor?

Esse mito é comum entre os desenvolvedores juniores. Especialmente para eles, explicarei que designers são pessoas que elaboram um layout não apenas para torná-lo bonito e moderno, mas também para torná-lo conveniente de usar. Eles conhecem muitos padrões de comportamento do usuário, combinações de cores e formas dos quais não temos conhecimento, então o melhor conselho neste momento é: confie mais em seu colega – ele certamente sabe o que está fazendo.

Meu designer é o mais teimoso.

Esse mito surge do fato de que todo desenvolvedor de front-end provavelmente ouviu “não” de seu designer. Com base nos mitos anteriores, minha primeira dica será acreditar em sua palavra. Se você não puder fazer isso, tente obter mais informações dele, pergunte por que ele diz “não” ou peça esclarecimentos ao colega menos ocupado (mas você pode ofender seu designer, esteja preparado para isso).

Falando francamente, existem muitos mais mitos, mas a ideia principal que quero transmitir é a seguinte: todos os designers também são pessoas. Portanto, é melhor se comunicar com eles e fazer perguntas. Muitos daqueles com quem eu costumava trabalhar me ensinaram algumas sutilezas de seu ofício, que foram úteis para mim na organização de páginas da web.

Problemas de layout

Vou começar simples. Os layouts não fornecem atenção suficiente ao estouro horizontal e vertical. Freqüentemente, tenho que descobrir o que acontecerá com um texto longo dentro do botão ou no subtítulo, ou onde adicionar uma barra de rolagem: na área de conteúdo ou na página inteira. O mais frustrante é quando um designer ou testador não gosta da sua decisão e você precisa reorganizá-la como um bug aberto, embora não haja nenhum bug.

Por exemplo, eu costumava truncar textos longos com reticências, mas meu designer então os substituiu por transparências nas bordas. Minhas recomendações são para discutir quaisquer pontos cegos com seu designer. Ele provavelmente pensou sobre esses casos, mas ainda não os exibiu em seus layouts.

O próximo problema está relacionado à altura dos blocos e ao espaçamento vertical entre eles. Às vezes acontece que você faz tudo de acordo com o layout e, ao verificar se há pixels perfeitos, você vê que as margens verticais são diferentes. No meu caso, isso se deveu a uma bagunça nos estilos que determinaram a altura do bloco. No layout, a altura da linha era especificada em pixels e era menor que o tamanho da fonte , e o tamanho do bloco era especificado em termos de altura .

Ao codificar, não localizei a altura do bloco. O fato é que geralmente não é definido, pois isso pode quebrar o elemento quando a linha quebra, dificultando a adaptação do bloco. O tamanho do bloco deve ser gerado automaticamente e consistir em preenchimento , altura da linha e largura da borda , enquanto a altura da linha deve ser maior ou igual ao tamanho da fonte .

As margens do bloco são o espaço da borda externa de sua borda. Portanto, para garantir que as margens e tamanhos do bloco correspondam ao layout, verifique cuidadosamente todas as propriedades. Se houver algum problema, tente explicar sua importância para o seu designer e peça a ele para limpar os estilos. Enquanto trabalhava em um dos projetos, meu designer e eu concordamos que todas as margens do projeto deveriam ser divisíveis por um determinado valor, por exemplo, quatro ou oito pixels.

Caso as margens do site não correspondam aos layouts, o múltiplo mais próximo é o preferido. Essa abordagem resolve muitos problemas, mas é importante transmitir sua eficácia ao testador, que pode encontrar bugs e apontar que as margens são diferentes dos layouts. Outra recomendação: sempre reveja sua codificação em pixels perfeitos para saber onde há lacunas óbvias, onde pode ter perdido algo e onde o layout não atende aos requisitos do sistema de design.

Um problema semelhante surge ao organizar blocos com uma borda. O fato é que no Figma o preenchimento é calculado sem levar em consideração. Isso é especialmente perceptível ao criar botões. Deixe-me lhe dar um exemplo. No layout, o preenchimento dentro do botão é de 8 px do texto até a borda superior do botão. Ao codificar, você deve reduzir o preenchimento pela largura da borda .

O problema é que no navegador, via de regra (se for box-sizing: border-box ), a borda é incluída na altura e na largura do elemento, e o preenchimento é calculado a partir de sua borda interna. Um problema semelhante ocorre quando um botão não tem um traço no layout, mas o traço aparece ao pairar.

Assim, se você seguir estritamente o layout, seu botão pode “pular”. Então, você precisa adicionar uma borda transparente. Há apenas uma recomendação: você deve sempre certificar-se de que seu elemento tenha a aparência que deveria.

O próximo problema está relacionado aos pré-carregadores. A teoria dos autômatos finitos nos ajudará a resolver esse problema. Os desenvolvedores de front-end geralmente erram ao definir uma variável booleana (isFetching ou isLoading) para exibir um pré-carregador, embora haja muitos mais estados. Por exemplo, se você voltar para uma página que já tem dados em cache, o conteúdo será exibido, e então tudo desaparecerá e o pré-carregador aparecerá, pois os dados serão atualizados. Você deve concordar que isso não é bom.

Este problema pode surgir porque misturamos o estado de carregamento inicial e atualização de dados, usando o mesmo pré-carregador em ambos os casos. Isso pode ser resolvido pedindo ao seu designer para pensar em todos os estados. Para isso, é melhor descrevê-los ou dar um exemplo. Nesse caso, no front-end, você precisará substituir uma variável booleana enumerando os estados e processar cada estado separadamente.

Falando sobre estados, gostaria de observar que frequentemente os layouts não incluem todos os estados dos elementos interativos. Via de regra, existem seis deles:

  • Normal – indica que o componente é interativo e habilitado.
  • Foco – relata que o usuário selecionou um item usando o teclado ou outro método de entrada.
  • Hover – relata quando o usuário passa o mouse sobre um elemento interativo.
  • Ativo – o estado ativo, ou pressionado, indica que o usuário pressionou o botão.
  • Progresso / Carregamento – é usado quando a ação não ocorre imediatamente e indica que o componente está em processo de conclusão da ação.
  • Desativado – indica que o componente não é interativo no momento, mas pode ser ativado no futuro.


Isso costuma ser esquecido e alguns estados se fundem. Os desenvolvedores de front-end às vezes combinam pairar e focar em um estilo, o que é um erro. Tente discutir isso com seu designer antes de começar a trabalhar, pois essas decisões afetam a acessibilidade do seu produto. O exemplo mais importante é quando você clica em um botão e, em seguida, remove o cursor dele, mas ele parece permanecer no estado de pairar.

Você pode escrever um artigo separado sobre acessibilidade, então aqui eu gostaria de destacar minha principal maldição. Em quase todos os projetos em que trabalhei, meu designer exigia remover “aquele traço azul feio”, que apenas desligamos sem adicionar nada para substituí-lo. É sobre o esboço. Ao desativá-lo e não dar nada em troca, interrompemos o suporte do teclado para o seu site, pois desativamos o estado de foco para todos os elementos interativos. É improvável que os visitantes que usam o seu site pelo teclado digam obrigado. E existem muitos deles.

A próxima complicação surge quando o guia de estilo é usado incorretamente. Por exemplo, existem fontes para a versão desktop, ou seja, Heading-1 , e a versão móvel, ou seja, MobileHeading-1 . No layout, o Título-1 do desktop repentinamente se torna o Título-3 na versão móvel. É muito difícil trabalhar com isso, pois todo o sistema que criei de acordo com o guia de estilo começa a desmoronar a partir deste lugar.

A mensagem principal: se houver um guia de estilo ou sistema de design, tente combiná-lo o máximo possível. Por exemplo, se um designer perguntar se um botão ligeiramente modificado precisa ser adicionado ao guia de estilo, diga “sim”.

Vamos falar separadamente sobre adaptabilidade. Como regra, o web design pode ser adaptativo e fluido. Os layouts adaptáveis ​​se ajustam a resoluções de tela específicas, enquanto os layouts fluidos mudam suavemente, ajustando-se a qualquer largura de tela. Na minha opinião, o web design fluido é mais moderno e versátil, e sua implementação não causa nenhuma dificuldade porque inclui flex-box , grade , vw / vh , funções matemáticas , etc.

No entanto, todos estão acostumados há muito tempo aos pontos de interrupção do Bootstrap, e a maioria dos layouts dependem deles. É bom se o layout tiver pelo menos três estados: desktop (geralmente 1440 px), tablet (geralmente 1024 px ou 768 px) e telefone celular (320 px ou 375 px). É aqui que os problemas geralmente começam. O cliente chega e diz que em sua barra de chocolate, que tem uma resolução de 2500px, o site está horrível. Então o analista chega e diz que o site fica ruim em seu laptop com resolução de 1380 px e assim por diante. Dois problemas são descritos aqui ao mesmo tempo.

A primeira é que o layout ou o princípio de exibição de um site em grandes monitores precisa ser mais desenvolvido. Não devemos nos esquecer disso. Sempre peça ao seu designer para exibir uma ou duas páginas em alta resolução para que o princípio de como o site se comportará nessas telas seja claro. Repito: não há necessidade de trazer todas as páginas para esta resolução – bastam um ou dois exemplos.

O segundo problema são os estados intermediários nos layouts. Se você pensar de forma adaptativa, não fluida, todas as versões exibidas no layout são usadas para os estados superiores ao especificado, ou seja, um layout de 1440px é adequado para telas de 1440px de largura e acima até o próximo ponto de interrupção (claro, se houver um ) Se a largura da tela for menor que a especificada no layout, a versão do breakpoint anterior deve ser exibida.

Por exemplo, você tem um estado para 1440px e 768px em seu layout. A versão de 768 px será exibida com uma largura de 1380 px, restringindo a largura da área de conteúdo para coincidir com o layout. Para dizer o mínimo, isso não parecerá bom o suficiente. O pior cenário é quando há uma grande lacuna entre os pontos de interrupção. Por exemplo, o designer renderiza o estado para 1920px e 768px.

Então, de acordo com a lógica direta, o estado 768px será escolhido para 1440px, mas não deveria ser assim. O cerne do problema é que, ao examinar layouts em três resoluções, o desenvolvedor front-end nem sempre entende qual estado será escolhido e quando. Se considerarmos um layout fluido, a largura de 1380 px exibirá a versão de 1440 px, e a largura de 1110 px exibirá a versão de 1024 px.

Algumas perguntas podem surgir: em que momento cada uma das versões será escolhida?

Até que largura de tela a versão de 1024 px será exibida?

Vamos considerar possíveis soluções. A primeira é ir ao seu designer e descrever o problema. Talvez ele já saiba como o site mudará à medida que a tela encolher e se expandir. Ele vai explicar para você pelo menos em palavras, mas isso nem sempre funciona. A segunda opção é desconectar sua mente dos pontos de interrupção do Bootstrap e tratar cada bloco como se fosse independente.

Nesse caso, começo a compactar e expandir cada bloco, observando seu comportamento, e determino a resolução ótima para a transição de estado. Muitos desenvolvedores não gostam dessa abordagem. Parece redundante para eles. O principal argumento é que muitos pontos de interrupção podem aparecer, mas, como mostra a prática, é improvável que esses estados sejam mais de seis, e todos eles serão encapsulados dentro de seus blocos e não afetarão nada. No entanto, seu layout será fluido e se adaptará a qualquer resolução de tela.

Como os designers podem ajudar os desenvolvedores front-end

Aqui estão alguns pontos cuja presença no projeto me ajudaria na codificação.

Comentários sobre layouts

É impossível exibir tudo no layout, e não há necessidade disso, mas algumas informações estão melhor descritas nos comentários. Claro, você pode passar informações oralmente, mas se houver muitos desenvolvedores front-end, esteja preparado para explicar sua ideia a cada um deles. O processo de integração de novas pessoas também se tornará mais complicado, pois você pode simplesmente esquecer por que uma determinada decisão foi tomada.

Histórico de mudança de layout

Ao trabalhar em um layout, os requisitos do produto são frequentemente atualizados de forma inesperada e são feitas alterações no layout. O desenvolvedor front-end recebe a tarefa de reorganizar alguns elementos, mas, à primeira vista, tudo parece o mesmo de antes. Apenas um estudo mais detalhado revela que a ordem dos ícones das redes sociais no rodapé, bem como alguns espaços na área de conteúdo ou mesmo alguns textos na página, foi alterada.

Para descobrir isso, você deve fazer uma captura de tela do layout e compará-lo com a versão atual do site. Figma atualmente não possui um sistema de controle de versão, então tudo recai sobre os ombros da equipe. E só a comunicação pode ajudar a resolver esse problema.

Guia de estilo de projeto

Páginas com todos os estados de elementos interativos, elementos tipográficos, formas e exemplos de seu preenchimento, etc. Isso permitirá a abordagem “atômica” dos blocos. Um guia de estilo de projeto bem desenvolvido é a chave para o sucesso. O principal é mantê-lo atualizado e não se desviar dele.

Acessibilidade da interface

Seu designer deve compreender o significado total da acessibilidade de sua interface e sua consideração ao projetar. Não é possível deixar como está e depois pensar em uma versão para deficientes visuais ou em um modo de leitura. Isso não vai funcionar. Nesse caso, implementar a acessibilidade será muito mais difícil, senão impossível.

Adaptabilidade detalhada

Compreensão total de como o layout se comportará quando compactado e expandido. Isso resolverá o problema de estados intermediários entre os pontos de interrupção e simplificará qualquer tipo de design da web.

Estrutura do projeto na Figma

Muitos desenvolvedores reclamaram comigo que é impossível abrir o Figma porque todas as páginas do projeto são exibidas em uma guia. A estrutura de armazenamento correta para o projeto tornará mais fácil para o designer e o desenvolvedor trabalhar com ela.

Nomes para cores e fontes

Quando todas as cores e tipos de fontes têm nomes, o desenvolvedor front-end não precisa inventá-los. É perfeito se os nomes contiverem apenas letras, números, “$” e “_”, e o primeiro caractere não for um dígito. Isso é opcional, mas permite que você use os nomes certos no código e os mantenha atualizados.

Consistência entre as versões

É mais como um pedido aos designers. Ao desenvolver um layout para a versão mobile do site, tente lembrar que este ainda é um site e não um aplicativo móvel. Você só quer ver a consistência entre as versões para desktop e móvel. Em alguns projetos, as versões para celular e desktop são tão diferentes que você precisa fazer novas versões do zero, o que leva o dobro do tempo de desenvolvimento.

O que os designers devem saber sobre o desenvolvimento de front-end

  • É impossível estudar codificação de sites sem experiência prática, mas seria ótimo saber pelo menos as regras básicas segundo as quais uma página da web é formada. Isso permitirá que o designer entenda onde a implementação não ficará clara para o desenvolvedor e onde é mais provável que ele cometa um erro.
  • tamanho da caixa  - determina como a largura e a altura totais do elemento são calculadas;
  • margem  - determina o espaço sideral;
  • preenchimento  - determina o espaço interno;
  • fronteira  - responsável por todas as propriedades pessoais de fronteira;
  • estouro  - funciona com estouro;
  • flex / grid  - os tipos de tela mais populares.
  • Uma das principais metodologias de CSS é o BEM . O designer precisa do BEM para entender a mentalidade do desenvolvedor front-end que montará a página. Além do mais, permite ao designer armazenar elementos do projeto da mesma forma que o desenvolvedor front-end faria.
  • Diferença entre elementos de bloco e elementos embutidos . Isso lhe dará uma compreensão mais profunda da composição de sua página da web.
  • As ferramentas de desenvolvedor baseadas em navegador simplificam o processo de supervisão de campo e ajudam a testar algumas hipóteses diretamente no ambiente de trabalho.

A maioria dos designers não sabe codificar, então é difícil para eles entender a dor do desenvolvedor front-end. Não hesite em compartilhar sua experiência. Tente explicar ao seu colega como certas propriedades funcionam no navegador, o que não exigirá nenhum esforço e o que será muito mais difícil.

O que os desenvolvedores de front-end devem saber sobre design e muito mais

  • Grade. Quase todos os layouts são baseados em uma grade. Se você sabe como usar grades, organizar as páginas da web fica mais fácil, e considerando que agora temos grades, torna-se até um prazer.
  • Noções básicas do Figma. Fale com o designer na mesma linguagem e entenda as características e diferenças entre os layouts Figma e WEB.
  • BEM. Não importa se você usa CSS-in-JS ou CSS-modules, a metodologia permite que você limpe sua cabeça e pense nas categorias certas.
  • Herança de estilo. Muitas propriedades CSS são herdadas do bloco pai, enquanto a Figma não fornece isso. Para não reescrever todos os estilos sem olhar, lembre-se de quais propriedades são tiradas do pai e quais são declaradas no elemento.

Máquinas de estados finitos. Entenda quantos estados um elemento pode ter em uma página.
Vou repetir meu pensamento das partes anteriores: se algo não está claro ou te deixa interessado, vá ao seu designer e tire suas dúvidas, ganhe experiência na construção de interfaces com profissionais.

Conclusão

Neste artigo, cobri apenas parte da ponte que existe entre os dois lados do desenvolvimento de front-end e do design de UI / UX. Espero que minha experiência ajude os desenvolvedores e designers de front-end a se entenderem um pouco melhor.

O principal que gostaria de dizer para concluir é que trabalhamos com pessoas, o que significa que podemos resolver qualquer problema através da comunicação e chegar a um compromisso. Respeite seus colegas e tente se colocar no lugar deles com mais frequência.

Artigo escrito por Alexey Shepelev, Desenvolvedor Ruby on Rails Sênior

Dica: Procurando por cursos em tecnologia? Clique aqui e encontre os melhores cursos com desconto.

Deixe um comentário

Info.CEVIU