Como os desenvolvedores de front-end podem ajudar a preencher a lacuna entre designers e desenvolvedores

Publicados: 2022-03-10
Resumo rápido ↬ Sabe -se que os desenvolvedores geralmente são os últimos que deixam suas impressões digitais antes que um site ou qualquer tipo de produto da web seja enviado. Obviamente, muita responsabilidade está envolvida e a qualidade de seu trabalho pode fazer um projeto se destacar ou ir por água abaixo. Este artigo dá sugestões sobre o que os desenvolvedores front-end podem fazer para preencher melhor a lacuna entre designers e desenvolvedores.

Nos últimos nove anos, quase todos os designers com quem trabalhei expressaram sua frustração sobre eles frequentemente terem que passar dias dando feedback aos desenvolvedores para corrigir espaçamentos, tamanhos de fonte, aspectos visuais e de layout que simplesmente não foram implementados corretamente . Isso muitas vezes leva ao enfraquecimento da confiança entre designers e desenvolvedores e causa designers desmotivados, juntamente com uma atmosfera ruim entre as duas disciplinas.

Muitas vezes, os desenvolvedores ainda parecem ter a má reputação de serem excessivamente técnicos e ignorantes quando se trata de considerar os detalhes que a equipe de design criou. De acordo com um artigo de Andy Budd, “[…] muitos desenvolvedores estão na mesma posição sobre design – eles simplesmente não percebem isso”. Na realidade, porém (como Paul Boag aponta), “os desenvolvedores [precisam] tomar decisões de design o tempo todo”.

Neste artigo, fornecerei dicas práticas para desenvolvedores de front-end para evitar a frustração e aumentar a produtividade ao trabalhar com sua contraparte criativa.

Olhando pelos olhos de um designer

Vamos por um momento imaginar que você é um designer e passou as últimas semanas - se não meses - para elaborar um design para um site. Você e seus colegas de equipe passaram por várias revisões internas, bem como apresentações de clientes, e se esforçaram bastante para ajustar detalhes visuais, como espaço em branco, estilos de fonte e tamanhos. (Em uma era responsiva – para vários tamanhos de tela, é claro.) Os designs foram aprovados pelo cliente e entregues aos desenvolvedores. Você se sente aliviado e feliz.

Algumas semanas depois, você recebe um e-mail de seu desenvolvedor que diz:

“O local de teste está configurado. Aqui está o link. Você pode fazer o controle de qualidade?”

Em uma emoção de antecipação, você abre o link de teste e depois de rolar por algumas das páginas, percebe que o site parece um pouco fora do ar. Os espaçamentos não estão nem perto do que seu design sugeriu e você percebe algumas torções no layout: faces e cores de fonte erradas, bem como interações incorretas e estados de foco. Sua excitação começa a desaparecer lentamente e se transformar em um sentimento de frustração. Você não pode deixar de se perguntar: “Como isso pode ter acontecido?”

Mais depois do salto! Continue lendo abaixo ↓

A busca de razões

Talvez tenha havido muitos mal-entendidos infelizes na comunicação entre os designers e os desenvolvedores. No entanto, você continua se perguntando:

  • Como foi a entrega dos designs? Houve apenas alguns PDFs, arquivos Photoshop ou Sketch compartilhados por e-mail com alguns comentários, ou houve uma reunião real de entrega em que vários aspectos como um possível sistema de design, tipografia, comportamento responsivo, interações e animações foram discutidos?
  • Existiam protótipos interativos ou de movimento que ajudam a visualizar certas interações?
  • Foi criada uma lista de aspectos importantes com níveis de prioridade definidos?
  • Quantas conversas ocorreram — com designers e desenvolvedores na mesma sala juntos?

Como a comunicação e a transferência são dois pontos-chave muito importantes, vamos dar uma olhada em cada um deles.

Comunicação é a chave

Designers e desenvolvedores, por favor, conversem entre si. Fale muito . Quanto mais cedo no projeto e quanto mais vezes, melhor. Se possível, revise o trabalho de design em andamento juntos no início do projeto (e regularmente) para avaliar constantemente a viabilidade e obter informações interdisciplinares. Designers e desenvolvedores naturalmente se concentram em diferentes aspectos da mesma peça e, portanto, veem as coisas de diferentes ângulos e perspectivas .

O check-in antecipado permite que os desenvolvedores se familiarizem com o projeto para que possam começar a pesquisar e planejar com antecedência os termos técnicos e trazer suas ideias sobre como otimizar os recursos. Fazer check-ins frequentes também une a equipe em um nível pessoal e social , e você aprende a se aproximar para se comunicar de maneira eficaz.

A transferência do design para o desenvolvimento

A menos que uma organização siga um fluxo de trabalho verdadeiramente ágil, uma transferência inicial de componentes e ativos de design (da equipe de design para os desenvolvedores) provavelmente acontecerá em algum momento de um projeto. Essa transferência — se feita minuciosamente — pode ser uma base sólida de conhecimento e acordos entre os dois lados. Portanto, é essencial não se apressar e planejar um tempo extra.

Faça muitas perguntas e fale sobre cada requisito, página, componente, recurso, interação, animação, qualquer coisa – e faça anotações. Se as coisas não estiverem claras, peça esclarecimentos . Por exemplo, ao trabalhar com equipes externas ou baseadas em contrato, designers e desenvolvedores podem assinar as anotações feitas como um documento de acordo mútuo para referência futura.

As composições de design plano e estático são boas para mostrar aspectos gráficos e de layout de um site, mas obviamente não têm a representação adequada de interações e animações. Pedir protótipos ou demonstrações de trabalho de animações complexas criará uma visão mais clara do que precisa ser construído para todos os envolvidos.

Hoje em dia, há uma ampla gama de ferramentas de prototipagem disponíveis que os designers podem utilizar para criar fluxos e interações em diferentes níveis de fidelidade. Javier Cuello explica como escolher a ferramenta de prototipagem certa para o seu projeto em um de seus artigos abrangentes.

Cada projeto é único, assim como seus requisitos. Devido a esses requisitos, nem todos os recursos conceituados podem sempre ser construídos. Muitas vezes o tempo e os recursos disponíveis para construir algo podem ser um fator limitante. Além disso, as restrições podem vir de requisitos técnicos , como viabilidade, acessibilidade, desempenho, usabilidade e suporte entre navegadores, requisitos econômicos, como orçamento e taxas de licença, ou restrições pessoais, como nível de habilidade e disponibilidade dos desenvolvedores.

Então, e se essas restrições causarem conflitos entre designers e desenvolvedores?

Encontrando compromissos e construindo conhecimento compartilhado

Para enviar com sucesso um projeto no prazo e atender a todos os requisitos definidos, é inevitável encontrar compromissos entre as duas disciplinas. Os desenvolvedores precisam aprender a falar com designers em termos não técnicos quando eles explicam as razões pelas quais as coisas precisam de mudanças ou não podem ser construídas em uma situação específica.

Em vez de apenas dizer: "Desculpe, não podemos construir isso", os desenvolvedores devem tentar dar uma explicação que seja compreensível para os designers e - na melhor das hipóteses - preparar sugestões para uma solução alternativa que funcione dentro das restrições conhecidas. Apoiar seu ponto de vista com estatísticas, pesquisas ou artigos pode ajudar a enfatizar seu argumento. Além disso, se o tempo for um problema, talvez a implementação de algumas partes demoradas possa ser movida para uma fase posterior do projeto?

Mesmo que nem sempre seja possível, ter designers e desenvolvedores sentados um ao lado do outro pode encurtar os ciclos de feedback e facilitar a elaboração de uma solução comprometida. A adaptação e a prototipagem podem ser feitas diretamente através da codificação e otimização com o DevTools aberto.

Mostre aos seus colegas designers como usar o DevTools em um navegador para que eles possam alterar informações básicas e visualizar pequenas alterações em seus navegadores (por exemplo, preenchimentos, margens, tamanhos de fonte, nomes de classes) em tempo real.

Se a estrutura do projeto e da equipe permitir, construir e prototipar no navegador o mais rápido possível pode dar a todos os envolvidos uma melhor compreensão do comportamento responsivo e pode ajudar a eliminar bugs e erros no estágio inicial do projeto.

Quanto mais tempo designers e desenvolvedores trabalharem juntos, melhor os designers entenderão o que é mais fácil e o que é mais difícil para os desenvolvedores construirem. Com o tempo, eles podem eventualmente se referir a soluções que funcionaram para ambos os lados no passado:

“Usamos essa solução para encontrar um compromisso no Projeto A. Podemos usá-la para este projeto também?”

Isso também ajuda os desenvolvedores a ter uma noção melhor de quais detalhes os designers são muito específicos e quais aspectos visuais são importantes para eles.

Os designers esperam que o frontend pareça (e funcione) como seu design

O arquivo de design vs. Comparação do navegador

Uma técnica útil para evitar que os designers fiquem frustrados é fazer uma simples comparação esquerda-direita entre o arquivo de design que você recebeu e como está seu estado atual de desenvolvimento. Isso pode parecer trivial, mas como desenvolvedor, você precisa cuidar de tantas coisas que precisam funcionar nos bastidores que você pode ter perdido alguns detalhes visuais. Se você vir algumas discrepâncias perceptíveis, simplesmente corrija-as.

Pense desta forma: cada detalhe em sua implementação que se pareça exatamente como foi projetado economiza tempo e dores de cabeça valiosos tanto para você quanto para o designer e incentiva a confiança. Nem todo mundo pode ter o mesmo nível de atenção aos detalhes, mas para treinar seu olho para notar diferenças visuais, uma rodada rápida de Can't Unsee pode ser uma boa ajuda.

“Can’t Unsee” é um jogo onde você precisa escolher o design mais correto entre duas opções.
(Créditos da imagem: Can't Unsee) (Visualização grande)

Isso me lembra nostalgicamente um jogo que costumávamos jogar há muito tempo chamado “Find it”. Você tinha que encontrar discrepâncias comparando duas imagens aparentemente semelhantes para marcar pontos.

Em “Find it”, os jogadores precisam encontrar erros ao comparar duas imagens
(Créditos da imagem: Mordillo encontrá-los) (Visualização grande)

Ainda assim, você pode estar pensando:

“E se simplesmente não houver um sistema perceptível de tamanhos de fonte e espaçamentos no design?”

Bem, bom ponto! A experiência mostrou-me que pode ajudar a iniciar uma conversa com o(s) designer(s) pedindo esclarecimentos em vez de começar radicalmente a mudar as coisas por conta própria e criar surpresas indesejadas para o(s) designer(s) mais tarde.

Aprenda regras básicas de tipografia e design

Como Oliver Reichenstein afirma em um de seus artigos, 95% da informação na web é escrita. Portanto, a tipografia desempenha um papel vital não apenas no design da web, mas também no desenvolvimento. Compreender termos e conceitos básicos de tipografia pode ajudá-lo a se comunicar de forma mais eficaz com designers e também o tornará mais versátil como desenvolvedor. Recomendo a leitura do artigo de Oliver, pois ele explica a importância da tipografia na web e explica termos como micro e macro tipografia .

No “Guia de referência para tipografia em web design móvel”, Suzanne Scacca cobre completamente a terminologia tipográfica, como tipo de letra, fonte, tamanho, peso, kerning, entrelinha e rastreamento, bem como o papel da tipografia no web design moderno.

Se você quiser expandir ainda mais seu horizonte tipográfico, vale a pena ler o livro de Matthew Butterick, “Butterick's Practical Typography”. Ele também fornece um resumo das principais regras de tipografia.

Uma coisa que achei particularmente útil no web design responsivo é que se deve apontar para um comprimento médio de linha (caracteres por linha) de 45 a 90 caracteres, pois linhas mais curtas são mais confortáveis ​​de ler do que linhas mais longas.

Comparando dois parágrafos de texto com diferentes comprimentos de linha
Comparando diferentes comprimentos de linha (visualização grande)

Os desenvolvedores devem projetar?

Tem havido muita discussão se os designers devem aprender a codificar, e você pode estar se perguntando a mesma coisa ao contrário. Eu acredito que dificilmente alguém pode se destacar em ambas as disciplinas, e isso é totalmente bom.

Rachel Andrew descreve muito bem em seu artigo “Trabalhando juntos: como designers e desenvolvedores podem se comunicar para criar projetos melhores” que, para colaborar de forma mais eficaz , todos nós precisamos aprender algo sobre a linguagem, as habilidades e as prioridades de nossos colegas de equipe para que possamos podem criar uma linguagem compartilhada e áreas de especialização sobrepostas.

Uma forma de se tornar mais conhecedor na área de design é um curso online conhecido como “Design for Developers” que é oferecido por Sarah Drasner no qual ela fala sobre princípios básicos de layout e teoria das cores – duas áreas fundamentais em web design.

“Quanto mais você aprende fora de sua própria disciplina, é melhor para você [...] como desenvolvedor.”

— Sarah Drasner

O Centro Visual

Ao colaborar com designers, aprendi a diferença entre o centro matemático e o visual. Quando queremos chamar a atenção do leitor para um determinado elemento, o ponto focal natural do nosso olho fica um pouco acima do centro matemático da página.

Podemos aplicar este conceito, por exemplo, para posicionar modais ou qualquer tipo de sobreposição. Essa técnica nos ajuda a atrair naturalmente a atenção do usuário e faz com que o design pareça mais equilibrado:

Comparando dois layouts de página onde um mostra um texto alinhado ao matemático e o outro um texto alinhado ao centro visual
(Visualização grande)

Estamos juntos nessa

Em ambientes de agência de ritmo acelerado e não tão ágeis com prazos apertados, os desenvolvedores geralmente são solicitados a implementar frontends responsivos totalmente funcionais com base em uma maquete móvel e de desktop. Isso inevitavelmente força o desenvolvedor a tomar decisões de design ao longo do processo. Perguntas como: "Com que largura diminuiremos o tamanho da fonte dos títulos?" ou "Quando devemos mudar nosso layout de três colunas para uma única coluna?" pode surgir.

Além disso, no calor do momento, pode acontecer que detalhes como estados de erro, notificações, estados de carregamento, modais ou estilos de páginas 404 simplesmente caiam no esquecimento. Em tais situações, é fácil começar a apontar o dedo e culpar as pessoas que deveriam ter pensado nisso antes. Idealmente, os desenvolvedores nunca deveriam ser colocados em tal situação, mas e se for esse o caso?

Quando ouvi o fundador e CEO da Ueno, Haraldur Thorleifsson, falar em uma conferência em São Francisco em 2018, ele apresentou dois de seus valores fundamentais:

“Nada aqui é problema de outra pessoa.”
“Recolhemos o lixo que não colocamos no chão.”

E se mais desenvolvedores começarem proativamente a criar maquetes das partes ausentes mencionadas acima da melhor maneira possível e depois refinarem junto com o designer sentado ao lado deles? Os sites ficam no navegador, então por que não utilizá-lo para construir e refinar?

Embora a remoção de peças ausentes ou esquecidas nem sempre seja ideal, aprendi em minhas experiências anteriores que sempre nos ajudou a avançar mais rapidamente e eliminar erros em tempo real — como uma equipe .

Claro, isso não significa que os designers devam ser anulados no processo. Isso significa que os desenvolvedores devem tentar respeitar os designers no meio do caminho, mostrando iniciativa na resolução de problemas. Além disso, eu como desenvolvedor era muito mais valorizado pela equipe simplesmente por cuidar e assumir responsabilidades.

Construindo confiança entre designers e desenvolvedores

Ter uma relação de confiança e positiva entre a equipe criativa e de tecnologia pode aumentar fortemente a produtividade e o resultado do trabalho. Então, o que nós, como desenvolvedores, podemos fazer para aumentar a confiança entre as duas disciplinas? Aqui estão algumas sugestões:

  1. Mostre um olho para os detalhes .
    Construir as coisas exatamente como foram projetadas mostrará aos designers que você se importa e colocará um grande sorriso em seus rostos.
  2. Comunique-se com respeito .
    Somos todos seres humanos em um ambiente profissional buscando o melhor resultado possível. Mostrar respeito pela disciplina de cada um deve ser a base de toda comunicação.
  3. Faça check-in antecipado e regularmente .
    Envolver os desenvolvedores desde o início pode ajudar a eliminar erros logo no início. Por meio da comunicação frequente, os membros da equipe podem desenvolver uma linguagem compartilhada e uma melhor compreensão das posições uns dos outros.
  4. Faça-se disponível .
    Ter pelo menos uma janela opcional de 30 minutos por dia, quando os designers podem discutir ideias com os desenvolvedores, pode dar aos designers uma sensação de apoio. Isso também dá aos desenvolvedores a oportunidade de explicar coisas técnicas complexas em palavras que pessoas não tão técnicas podem entender melhor.

O resultado: uma situação ganha-ganha

Ter que gastar menos tempo no controle de qualidade por meio de uma comunicação eficaz e uma entrega adequada de projetos dá à equipe criativa e de desenvolvimento mais tempo para se concentrar na construção de coisas reais e menos dores de cabeça. Em última análise, cria uma atmosfera melhor e cria confiança entre designers e desenvolvedores. A voz dos desenvolvedores frontend que demonstram interesse e conhecimento em algumas áreas relacionadas ao design será mais ouvida nas reuniões de design.

Contribuir proativamente para encontrar um compromisso entre designers e desenvolvedores e a solução de problemas como desenvolvedor pode dar a você um senso mais amplo de propriedade e envolvimento com todo o projeto. Mesmo na crescente indústria criativa de hoje, não é fácil encontrar desenvolvedores que - além de suas habilidades técnicas - se preocupem e estejam atentos aos detalhes visuais. Esta pode ser sua oportunidade de ajudar a preencher a lacuna em sua equipe.

Recursos Relacionados

  • “Como escolher a ferramenta de prototipagem certa”, Javier Cuello
  • “Um guia de referência para tipografia em web design móvel”, Suzanne Scacca
  • “A tipografia prática de Butterick”, Matthew Butterick
  • “Trabalhando juntos: como designers e desenvolvedores podem se comunicar para criar projetos melhores”, Rachel Andrew
  • “Design para desenvolvedores”, Sarah Drasner, mestres de front-end
  • “Web design é 95% tipografia”, Oliver Reichenstein
  • "Can't Unsee", um teste de navegador para treinar seu senso de reconhecimento de detalhes visuais.