() translation by (you can also view the original English article)
Nessa série, discutiremos como navegar pelos caminhos que designers tem de passar ao lidar com desenvolvedores em projetos criativos.
Há muito tempo quero escrever essa série. Sendo alguém que passou pelos dois lados–designer e desenvolvedor–senti a frustração que vários designers e desenvolvedores profissionais sentem no dia-a-dia. Já que decidi ser um melhor desenvolvedor, além de ter ensinado vários curso em experiência do usuário e desenvolvimento web, acredito ser meu dever falar sobre algumas das barreiras que ambos enfrentam no ambiente de trabalho.
Nos artigos futuros, guiarei desenvolvedores e designers por um caminho que, espero, permita trabalharem juntos e com mais eficiência.
Há uma relação de amor-e-ódio muito forte e tangível entre designers de UI/UX e desenvolvedores.
— π (@pi_alize), 21 de Outubro de 2016
A relação entre os dois é tão interligada que, se um dos dois não prestar atenção ao outro, o produto final não terá o resultado esperado.
O Que Vem Por Aí
Na primeira parte da série, planejo esboçar os problemas enfretados, assim como acabar com essas barreiras. Seja projetando com código ou entendendo que código é necessário para levar a UX de um design para um ambiente real.
A segunda parte proverá designers um conhecimento básico do desenvolvimento front-end já que esse, mais que o back-end, imita a estética geral do design. Acredito que seja uma das maiores barreiras. Veremos o que a DOM é, o que HTML e CSS podem fazer, onde o JavaScript se encaixa e veremos rapidamente como SEO e semântica devem ser parte do fluxo do design.
Na parte final da série, veremos o backend. Não ensinaremos como programar, contudo, introduziremos as mentalidade e metodologias que desenvolvedores usam para reproduzir não só o desing mas, também, a lógica envolvida. Finalizarei com um último pensamento e alguns recursos úteis para ajudá-los a trabalhar melhor e juntos.
Nota para Desenvolvedores
Essa série é voltada para pessoas que tem um passado muito forte no design. Qualquer conceito explicado aqui, embora rudimentar, não entrará em detalhes e bastarão como conhecimento básico sobre programação de computadores.
Projetando Com Código ou Codificando com Design
Um debate que tenho tido muito é em relação ao processo de design de um website. Equipes deveriam começar com um produto "finalizado" e codificá-lo passo-a-passo ou é melhor projetar enquanto desenvolve alguma funcionalidade. Existem prós e contras em ambos, então os destrinchemos mais.
Funcionalidade é Parte Inerente do Design
A maioria não acharia isso, mas ao construir um feed de blog ou widget de Twitter, o design tem papel fundamental em como o código funcionará. Vejamos um cenário comum: Fazer o widget de Twitter obter novos tweet ao recarregar a página ou assíncronamente, via Ajax, sem recarregar a página. AJAX é a forma mais limpa e sofisticada de resolver o problema que se beneficiaria de uma UI limpa e de efeito de transição suave. Mas um designer pode estar totalmente a parte disso. Eles podem não ter ideia alguma que tal funcionalidade existia ou poderia ser programada. É por isso que, ao projetar um site ou UX sofisticada, é fundamentalmente importante discutir a funcionalidade com o desenvolvedor.
Mais Que Simples Estética
A web é acessa de várias formas, formatos, orientações, ambientes e até percepções (imagine leitor de tela ou assistência via áudio). Como designer, é preciso garantir uma experiência de usuário de qualidade presente e consistente entre todas essas variáveis, com usuários podendo decidir o que é necessário ou não. Muitos designers não levam isso em consideração, logo é difícil desenvolver uma experiência consistente.
Novamente, é apenas outro motivo para designers e desenvolvedores trabalharem juntos. Indo além, o desenvolvedor deveria ser uma extensão do designer e vice-versa. Esse é um esforço combinado para produzir a experiência de usuário mais viável possível.
"Quando designers e desenvolvedores trabalham juntos, eles podem fazer mágica" – John Botica
Design Deveria Ser Traduzível
Ao dizer "design deveria ser traduzível" não se refere a vários idiomas (embora haja casos como de tradução de experiências web para textos bidirecionais, afetarem dramaticamente o design principal). Refere-se ao fato que o design deveria ser claro e bem estraturuado o bastante para uma transição fácil de estático para dinâmico. Isso vem com a experiência e entendimento de como navegadores renderizam elementos e formas.
"É preciso saber traduzir nossos processos uns pros outros de modo que estimule cratividade e estrutura" – Airrick Dunfield
O mundo precisa de designers que dobrem os limites dos layouts e estética, e precisa de desenvolvedores bravos o suficiente para irem além das restrições dos motores web, mas ambos precisa começar a trabalhar juntos.
Na Próxima Vez
Na próxima parte da série, discutiremos soluções para as barreiras que falamos acima. Enquanto isso, fique com alguns materiais de leitura relevantes. Vemo-nos no próximo artigo!
