Como os desenvolvedores de front-end podem capacitar o trabalho do designer

Este artigo é principalmente direcionado a você, caro Desenvolvedor Frontend, que gosta de implementar interfaces de usuário, mas tem dificuldade em alinhar as expectativas com os designers com quem trabalha. Talvez você seja chamado de “Desenvolvedor de UI” ou “Engenheiro de UX”. Independentemente do título que você carrega, seu trabalho (assim como o meu) consiste em mais do que dar vida aos arquivos de design. Também somos responsáveis ​​por preencher a lacuna entre os fluxos de trabalho de design e desenvolvimento . No entanto, ao atravessar essa ponte, nos deparamos com vários desafios.

Hoje, gostaria de compartilhar com vocês dicas práticas que me ajudaram a colaborar de forma mais eficiente com designers nos últimos anos.

Acredito que é nosso trabalho, como UI Developers, não apenas ajudar os designers em sua jornada para aprender como a web funciona, mas também conhecer sua realidade e aprender sua linguagem.

Entendendo o histórico dos designers de UX

A maioria dos designers de UX (também chamados de Web Designers ou Designers de Produto) deu seus primeiros passos no mundo do design por meio de ferramentas como Photoshop e Illustrator. Talvez fossem Designers Gráficos : seu principal objetivo era criar logotipos e identidades de marca e projetar layouts para revistas. Eles também poderiam ter sido Designers de Marketing : imprimindo outdoors, desenhando banners e criando infográficos.

Isso significa que a maioria dos designers de UX passou seus primeiros dias projetando para impressão, que é um paradigma totalmente diferente de seu meio atual, a tela. Esse foi o primeiro grande desafio deles. Ao lidar com a impressão, os designers se preocupavam com o alinhamento de pixels, mas em uma área fixa (papel). Eles não tiveram que lidar com um layout dinâmico (telas). Pensar em quebra de texto ou estados de interação simplesmente não fazia parte de seu trabalho. Os designers também tinham total liberdade sobre cores, imagens e tipografia sem restrições de desempenho.

Felizmente, tem havido muitos esforços da comunidade de designers de UX autodidata para ensinar os fundamentos do desenvolvimento, discutir se os designers devem aprender a codificar e entender como melhor executar a transferência para os desenvolvedores. O mesmo vale para o lado do desenvolvimento (mais sobre isso em um minuto). No entanto, ainda há atrito acontecendo entre os dois campos.

Por um lado, designers reclamam cada vez que uma implementação não combina com seus projetos ou se sentem incompreendidos quando estes são rejeitados pelos desenvolvedores sem uma explicação clara. Por outro lado, os desenvolvedores podem ter certeza de que os designers sabem algo técnico quando isso pode não ser verdade. Acredito que todos podemos fazer melhor do que isso.

Abraçando uma nova maneira de pensar

Os sites e aplicativos que estamos criando serão exibidos em uma ampla variedade de tamanhos de tela. Cada pessoa irá usá-los em vários dispositivos. Nosso objetivo comum é criar uma experiência familiar em suas jornadas.

Quando nós, como desenvolvedores, pensamos que os designers estão sendo exigentes quanto aos alinhamentos de pixels, precisamos entender por que isso acontece. Precisamos reconhecer que está além da fidelidade e consistência. É sobre a soma de todas as partes trabalhando juntas. É coesão. Temos que abraçá-lo e fazer o nosso melhor para realizá-lo. Aprender os fundamentos dos princípios de design é um bom ponto de partida . Entenda a importância de selecionar as cores certas, como a hierarquia funciona e por que o espaço em branco é importante.

Nota : Há um curso online conhecido como “Design for Developers” e um livro chamado “Refactoring UI” – ambos são ótimos para você começar. Com eles, você poderá implementar interfaces de usuário com um olho afiado para detalhes e obter uma vantagem significativa ao se comunicar com designers.

Ampliando a consciência de seus designers

Você pode assumir que os designers conhecem a web tanto quanto você. Bem, eles podem não. Na verdade, eles não precisam! É nossa responsabilidade, como desenvolvedores, mantê-los atualizados com o estado atual da web.

Trabalhei com os dois lados desse espectro: Designers que pensam que qualquer coisa pode ser construída (como filtros complexos, novos comportamentos de rolagem ou entradas de formulários personalizados) sem pensar na compatibilidade do navegador. Então, há designers com suposições sobre as “baixas limitações da web” e apenas assumem por si mesmos que algo é impossível de implementar. Precisamos mostrar a eles as verdadeiras possibilidades do web design e não deixar que as limitações atrapalhem suas habilidades.

Ensine-os a codificar, não a codificar

Isso parece contraditório, mas tenha paciência comigo: saber codificar está no centro do trabalho de um desenvolvedor. Trabalhamos em uma indústria de ritmo acelerado, com novidades surgindo todos os dias. Seria um pedido hipócrita de nós exigir que os designers aprendessem a codificar. No entanto, podemos ajudá-los a entender o código.

Sente-se ao lado do designer com quem você trabalha por 15 minutos e ensine-os como eles podem ver por si mesmos se as especificações de um elemento estão corretas e como alterá-las. Acho o Firefox Page Inspector notavelmente fácil de usar para isso.

Hoje em dia, é uma alegria visualizar layouts, depurar animações CSS e ajustar tipografia. Mostre a eles um playground de código pronto para usar, como o Codepen, para eles explorarem. Eles não precisam conhecer todas as especificações de CSS para entender como o paradigma de layout funciona. No entanto, eles precisam saber como os elementos são criados e se comportam para potencializar seu trabalho diário.

Incluir designers no processo de desenvolvimento

Convide designers para acompanhá-lo na reunião stand-up, para fazer parte do processo de controle de qualidade e sentar com você enquanto você refina os detalhes visuais em suas implementações. Isso fará com que eles entendam as restrições da web e, em breve, eles reconhecerão por que um recurso leva tempo para ser implementado.

Peça aos designers para incluí-lo em seu processo de design

Você perceberá que eles fazem muito mais do que “tornar as coisas bonitas”. Você aprenderá mais sobre o processo de pesquisa e como o teste do usuário é feito. Você descobrirá que para cada proposta de design que eles mostram a você, vários outros estudos foram descartados anteriormente. Quando os designers solicitarem uma mudança, pergunte o motivo por trás dela, para que você possa aprender mais sobre as decisões que estão sendo tomadas . Por fim, você começará a entender por que eles são exigentes com relação a espaços em branco e alinhamentos, e esperamos que em breve você também seja!

Acho crucial tratar o desenvolvimento frontend como uma parte central do processo de design e o design como uma parte central do processo de desenvolvimento. Defender uma mentalidade em que todos tenham a chance de se envolver no ciclo de design e desenvolvimento nos ajudará a entender melhor os desafios uns dos outros e também a criar ótimas experiências.

Podemos usar ferramentas diferentes, mas devemos falar a mesma língua

Agora que estamos começando a entender um pouco melhor o fluxo de trabalho um do outro, é hora do próximo passo: falar a mesma língua.

Olhando além do editor de código

Uma vez que você comece a prestar atenção ao seu entorno, você estará mais bem equipado para lidar com os problemas. Conheça melhor o negócio e esteja disposto a ouvir o que os designers têm a dizer. Isso fará de você um membro da equipe com contribuições mais ricas para o projeto. Colaborar em áreas além de nossa especialização é a chave para criar conversas significativas e confiança mútua.

Usando sistemas de interface do usuário como um contrato

Peça aos designers para compartilhar seu sistema de design com você (e se eles não usarem um, nunca é tarde para começar). Isso evitará o incômodo de escolher as cores usadas, descobrir margens ou adivinhar um estilo de texto. Certifique-se de estar familiarizado com o sistema de interface do usuário tanto quanto eles.

Você já deve estar familiarizado com o conceito baseado em componentes. No entanto, alguns designers podem não perceber isso da mesma maneira que você. Mostre a eles como os componentes podem ajudá-lo a construir interfaces de usuário com mais eficiência. Espalhe essa mentalidade e também diga adeus a nomes semelhantes, mas não iguais: cabeçalho versus herói, informações de preço versus seletor de preço . Quando uma parte da interface do usuário (também conhecida como 'um componente') é construída, tente usar os mesmos nomes para que eles possam ser refletidos tanto no design quanto nos arquivos de código. Então, quando alguém diz: “Precisamos ajustar o widget de convite de proposta”, todos sabem exatamente sobre o que está sendo falado.

Reconhecendo a verdadeira fonte da verdade

Apesar do fato de que a interface do usuário é criada primeiro nos arquivos de design, a verdadeira fonte da verdade está no lado do desenvolvimento. No final das contas, é o que as pessoas realmente veem, certo? Quando um design é atualizado, é uma boa ideia deixar uma nota lateral sobre seu status de desenvolvimento, especialmente em projetos em que um grande número de pessoas está envolvido. Esse truque ajuda a manter a comunicação suave, então ninguém (incluindo você) se pergunta: “ Isso é diferente da versão ao vivo. É um bug ou ainda não foi implementado? ”

Mantendo a dívida sob controle

Então, você sabe tudo sobre dívida técnica — acontece quando o custo para implementar algo novo é alto por causa de um atalho que tomamos no passado para cumprir um prazo. O mesmo pode acontecer no lado do design e chamamos isso de dívida de design .

Você pode pensar assim: quanto maior a inconsistência de UX e UI, maior a dívida (técnica e design). Uma das inconsistências mais comuns é ter elementos diferentes para representar a mesma ação. É por isso que um design ruim geralmente se reflete em um código ruim . Cabe a todos nós, designers e desenvolvedores, tratar nossa dívida de design com seriedade.

Ser acessível não significa que tem que ser feio

Estou muito feliz em ver que nós, como desenvolvedores e designers, estamos finalmente começando a trazer acessibilidade ao nosso trabalho. No entanto, muitos de nós ainda pensam que projetar produtos acessíveis é difícil ou limita nossas habilidades e criatividade.

Deixe-me lembrá-lo de que não estamos criando um produto apenas para nós mesmos. Estamos criando um produto para ser usado por todas as pessoas , inclusive aquelas que usam o produto de formas diferentes de você. Leve em consideração como os elementos individuais podem ser mais acessíveis, mantendo os fluxos de usuários atuais claros e coerentes.

Por exemplo, se um designer realmente acredita que é necessário criar uma entrada de seleção aprimorada, fique ao seu lado e trabalhe em conjunto para projetar e implementá-la de maneira acessível para ser usada por uma ampla gama de pessoas com habilidades diversas.

Dando feedback valioso aos designers

É inevitável que surjam perguntas ao passar pelos designs. No entanto, isso não é motivo para você começar a reclamar dos erros dos designers ou de suas ideias ambiciosas. Os designers não estão lá para levá-lo mentalmente, eles simplesmente nem sempre sabem intuitivamente o que você precisa para fazer seu trabalho. A verdade é que, no passado, você também não sabia dessas coisas, então seja paciente e abrace a colaboração como forma de aprendizado.

Quanto mais cedo o feedback, melhor

O momento para o feedback é crucial. O fluxo de trabalho de feedback depende muito da estrutura do projeto, portanto, não há uma solução única para ele. No entanto, quando possível, acredito que devemos buscar um fluxo de trabalho de feedback periódico – começando nos estágios iniciais. Ter essa mentalidade de colaboração aberta é a maneira de reduzir a possibilidade de grandes reiterações inesperadas no futuro. Tenha em mente que quanto mais tarde você der ao designer seu primeiro feedback, maior será o custo para eles explorarem uma nova abordagem, se necessário.

Explicar ideias abstratas em termos simples

Lembra quando eu disse que o desempenho não era uma preocupação dos trabalhos anteriores dos designers? Não se assuste quando eles não souberem como criar SVGs otimizados para a web. Quando se deparar com um design que exige que muitas fontes diferentes sejam carregadas, explique a eles por que devemos minimizar o número de solicitações, talvez até aproveitar as fontes variáveis. Além de carregar mais rápido, também oferece uma experiência de usuário mais consistente. A menos que os designers estejam interessados ​​em aprender, evite usar muitos termos técnicos ao explicar algo. Você pode ver isso como uma oportunidade de melhorar suas habilidades de comunicação e esclarecer seus pensamentos.

Não deixe que suposições se transformem em decisões

Algumas perguntas sobre uma especificação de design só aparecem quando colocamos a mão na massa no código. Para acelerar as coisas, podemos nos sentir tentados a tomar decisões com base em nossas suposições. Por favor, não. Cada vez que você transforma uma suposição em uma decisão, você está arriscando a confiança que a equipe de design deposita em você para implementar a interface do usuário. Sempre que tiver dúvidas, entre em contato e esclareça suas dúvidas . Isso mostrará a eles que você se preocupa com o resultado final tanto quanto eles.

Não faça soluções sozinho

Quando você for solicitado a implementar um projeto que é muito difícil, não diga “É impossível” ou comece a implementar uma versão alternativa barata dele por conta própria. Isso imediatamente causa atrito com a equipe de design quando eles veem que seus projetos não foram implementados conforme o esperado. Eles podem reagir com raiva ou não dizer nada, mas se sentir derrotados ou frustrados. Tudo isso pode ser evitado se explicarmos a eles por que algo não é possível, em termos simples e sugerirmos abordagens alternativas. Evite comportamentos dogmáticos e esteja aberto a colaborar em uma nova solução .

Informe-os sobre as técnicas de Degradação Graciosa e Aprimoramento Progressivo e construam juntos uma solução ideal e uma solução de reserva. Por exemplo, podemos aprimorar um layout de flexbox para CSS Grid. Isso nos permite respeitar o propósito central de um recurso e, ao mesmo tempo, fazer o melhor uso das tecnologias da web.

Quando se trata de animações, sejamos realistas: no fundo, você está tão empolgado em implementar a próxima animação quanto os designers estão em criá-la. A diferença entre nós e eles é que estamos mais conscientes das restrições da web. No entanto, não deixe que isso limite suas próprias habilidades! A web evolui rápido, então devemos usar isso a nosso favor.

Da próxima vez que você for solicitado a dar vida a um protótipo, tente não rejeitá-lo antecipadamente ou fazer tudo sozinho. Veja isso como uma oportunidade de se esforçar. As animações são uma das partes mais exigentes do desenvolvimento da Web, portanto, certifique-se de refinar cada quadro-chave com seu designer - pessoalmente ou compartilhando um link sincronizado privado.

Pense Além do Estado Ideal — Juntos

Aqui está a coisa: não é tudo sobre você. Um dos desafios dos designers é realmente entender seus usuários e apresentar os designs da forma mais atrativa para vender ao Gerente de Produto. Às vezes, eles esquecem o que está além do estado ideal e os desenvolvedores também esquecem.

Para ajudar a evitar que essas lacunas aconteçam, alinhe com os designers os requisitos do cenário:

• O pior cenário
  Um cenário onde as piores possibilidades estão acontecendo. Isso ajuda os designers a dizer não ao conteúdo fixo e deixá-lo fluido. O que acontece se o título tiver mais de 60 caracteres ou se a lista for muito longa? O mesmo se aplica ao oposto, o cenário vazio. O que o usuário deve fazer quando a lista estiver vazia?
• Estados de interação
  O navegador é mais do que pairar e clicar ao redor. Existem vários estados: padrão, foco, foco, ativo, desabilitado, erro… e alguns deles podem acontecer ao mesmo tempo. Vamos dar-lhes a devida atenção.
• O estado de carregamento
  Ao construir coisas localmente, podemos usar mocks e esquecer que as coisas realmente demoram para carregar. Deixe os designers saberem dessa possibilidade também e mostre a eles que são formas de fazer as pessoas perceberem que as coisas não demoram tanto para carregar.

Levando em consideração todos esses cenários, você economizará muito tempo indo e voltando durante a fase de desenvolvimento.

Nota : Há um ótimo artigo de Scott Hurff sobre como corrigir interfaces de usuário ruins que nos levarão um passo mais perto de um produto acessível.

Aceitar solicitações de mudança

Os desenvolvedores são conhecidos por não ficarem muito felizes com alguém encontrando um bug em seu código - especialmente quando é um bug de design relatado por um designer. Existem muitos memes em torno disso, mas você já refletiu como esses bugs podem apodrecer tanto a qualidade da experiência quanto o seu relacionamento quando esses bugs de design são descartados casualmente? Acontece lentamente, quase como adormecer. Pouco a pouco, depois tudo de uma vez. Os designers podem começar dizendo: “É apenas um pequeno detalhe”, até que a indiferença e o ressentimento se acumulem e nada seja dito. O estrago então já foi feito.

Essa situação é dupla: tanto para seus colegas quanto para seu trabalho. Não deixe isso acontecer. Trabalhe no que está colorindo sua reação. Um designer sendo 'exigente' pode ser inconveniente, mas também pode ser uma interpretação superficial de atenção e entusiasmo de um engenheiro. Quando alguém lhe disser que sua implementação não está perfeita (ainda), deixe seu ego de lado e mostre a eles como você reconhece seu trabalho duro para refinar o resultado final.

Saia do registro de vez em quando

Todos nós temos tarefas para entregar e roteiros para terminar. No entanto, alguns dos melhores trabalhos acontecem fora do registro. Ele não será logado no quadro TO DO e tudo bem. Se você encontrar um designer com quem tenha um relacionamento, entre no espaço de trabalho dele e explore juntos novos experimentos. Você nunca sabe o que pode vir de lá!

Conclusão

Quando você está disposto a aprender com a equipe de design, também está aprendendo diferentes maneiras de pensar. Você desenvolverá sua mentalidade de colaboração com outras áreas a partir de sua experiência enquanto aprimora seu olhar para criar novas experiências. Esteja presente para ajudar e esteja aberto ao aprendizado, porque compartilhar é o que nos torna melhores.

Este artigo não seria possível sem o feedback de muitas pessoas excelentes. Quero agradecer aos designers Jasmine Meijer e Margarida Botelho por me ajudarem a compartilhar uma perspectiva equilibrada sobre os mal-entendidos entre designers e desenvolvedores.

Leitura relacionada no SmashingMag:

• “Design para desenvolvedores” por Mason Gentry
• “Trabalhando juntos: como designers e desenvolvedores podem se comunicar para criar projetos melhores” por Rachel Andrew
• “Como os desenvolvedores de front-end podem ajudar a preencher a lacuna entre designers e desenvolvedores” por Stefan Kaltenegger
• “Quais podcasts os web designers e desenvolvedores devem ouvir?” por Ricky Onsman