Dev, fique juntinho do seu designer
Batman e Robin, queijo com goiabada, dev com designer… Nesse artigo faço uma reflexão sobre uma das duplas mais importantes do mundo de tech.
Recentemente, dando uma pausa das minhas atividades como dev do iFood, fui à Califórnia participar do evento Altconf. É uma conferência sensacional de desenvolvedores totalmente organizada pela comunidade iOS. Ela rola todos os anos, em paralelo com o WWDC.
A ideia do evento é reunir pessoas do mundo todo para trocarem novidades sobre o que estão fazendo em desenvolvimento iOS. Lá eu pude assistir a uma palestra chamada Finding the implicit design, feita pelo Jay Clark, em que ele falava sobre como a falta de comunicação entre desenvolvedores e designers pode gerar problemas durante o desenvolvimento.
O conteúdo deste texto foi inspirado pelas ideias expostas na palestra, e guiado pela seguinte pergunta: por que devs e designers devem estar próximos?
Montando uma tela (não tão) simples
Vamos pegar um exemplo clássico: uma tela de onboarding.
Ela é usada para mostrar informações básicas do seu app a novos usuários e dar as boas vindas. Agora imagine que você está no papel do desenvolvedor que vai implementar essa tela.
É claro que, antes de começar a montar uma tela dessas, precisamos das dimensões e distâncias entre os elementos visuais. Os designers usam ferramentas como o Zeplin ou (como fazemos no iFood) o Figma para consolidar e passar essas especificações para nós desenvolvedores.
Ótimo! Agora temos as dimensões e margens de nossos componentes visuais.
Aí você, dev, começa a montar a tela conforme todas essas especificações. Algo muito usado numa tela desse tipo é a possibilidade de fazer scroll para o lado, o que aqui está representado pelos pontinhos do page controller na parte de baixo da tela.
Depois de um tempo codando, você termina a sua primeira versão de teste e manda para o seu designer dar uma olhada.
Logo na segunda tela, o designer nota que o título ficou cortado. E, claro, não queremos um título cortado no nosso app!
O designer vai, faz uma nova versão com títulos maiores, com duas linhas, e você volta para a implementação.
Tudo tranquilo: é uma correção simples. Apenas o tempo de uma modificação, uma build, um teste, um commit, de gerar mais um beta e você mandar uma nova versão para ser revisada.
Depois disso, tudo parece bem. Até que o designer marca uma reunião com você e te conta um novo problema:
"Seria visualmente melhor que as descrições estivessem alinhadas, ficou meio estranho durante a transição das páginas."
Certo… até aquele momento, alinhar as coisas havia sido muito fácil. Eram distâncias fixas, tudo com tamanho bem comportado. Já alinhar o centro das descrições exige prever qual será a base dos títulos, e fazer a mesma posição do topo de todas as descrições.
Mas tudo bem, não tema! Um pouco de auto-layout, de quebrar a cabeça com constraints e você consegue alinhar esses caras.
Mais o tempo de uma outra modificação, uma build, um teste, um commit, de gerar mais um beta e você mandar outra versão para revisão.
Aqui já podemos tirar um ponto bem importante: é preciso variar os cenários dos layouts e testá-los em diversos formatos de tela.
Quebras de linha, tamanho de conteúdos, imagens, interações… se tudo isso pode ser alterado de acordo com o contexto, é importante que esses cenários sejam pensados antes do desenvolvimento. Isso faz com que uma boa quantidade de retrabalho seja prevenida, para o desenvolvedor e para o designer (e todo mundo junto que espera a feature sair e testar).
Mas a vida é uma caixinha de surpresas e o seu QA decide testar o seu novo onboarding em um device pequeno, mas muuuito pequeno, aquele mesmo que todo mundo ignora durante o desenvolvimento, mas para o qual o seu app ainda dá suporte.
Não precisa nem esperar abrir os bugs: a imagem ficou muito grande em relação à tela, a descrição também e passou o limite do page indicator lá embaixo.
Caímos em mais um ponto importante e que frequentemente assombra os montadores de layout: é preciso fazer cenários para dispositivos diversos.
E, a essa altura do campeonato, morrendo de preguiça de sair do seu contexto, dar checkout pra branch do seu onboarding novamente a fim de tratar essas novas modificações, você parte para soluções alternativas:
- Podemos diminuir o texto das descrições?
- Remover as imagens em dispositivos menores?
- Para que ter um page controller embaixo da tela, não é mesmo?
E, sem sucesso nas soluções alternativas, o designer volta, cria novas versões para diversos tamanhos de dispositivos. Você espera as novas modificações e parte novamente para a implementação.
Ótimo, agora todo o seu layout já era e vai ter que ser refeito. É quase fim do expediente, e essa feature era pra estar no ar amanhã.
Respire fundo.
Você joga todas as suas constraints fora, rearranja todo o layout, coloca constraints novas, fixas, proporcionais, limites máximos e mínimos.
E, é claro, não podia faltar: é preciso o tempo de reajustar tudo, uma nova build, um novo teste, um novo commit, de gerar mais um beta e mandar outra versão para revisão pra ser lançado no dia seguinte…
O exemplo acima é um cenário relativamente comum, que traz um alerta para as equipes de desenvolvimento como um todo: envolvam os desenvolvedores nas discussões das novas features do seu projeto.
A barreira invisível Dev/Designer
Por que situações como essa ainda acontecem?
Existe uma separação clara entre o time de desenvolvimento e o de design. No cotidiano, as atividades dos dois grupos são distintas: as ferramentas, os insumos, os resultados… tudo é diferente.
Mas isso não quer dizer que deveria existir uma separação do trabalho dos dois times!
É muito comum imaginar um modelo onde tudo se desenvolve em cascata:
O projeto chega → é aprovado → ele é montado pelo time de design → implementado pelos desenvolvedores → testado por QA → lançado.
Mas todo esse processo vai contra o desenvolvimento ágil! Afinal, mudar alguma coisa que já está dada como pronta dá muito mais trabalho.
Você, desenvolvedor, ao pensar que um designer deveria terminar tudo e te entregar algo pronto para ser implementado, abre diversas brechas nesse processo de criação.
E você, designer, deve assumir que é muito importante que o desenvolvedor, independente da plataforma, faça parte do processo de criação. Que ele questione, dê opiniões e argumente quanto a viabilidade do que deve ser implementado.
Não adianta montar uma experiência sensacional que não pode ser alcançada, ou ainda, uma experiência que terá que ser toda repensada. Além disso, esse processo conjunto mantém a expectativa dos dois lados alinhada e o trabalho fluindo.
Quebrando barreiras invisíveis
No iFood, todo trabalho dos designers é sempre aberto para os desenvolvedores acompanharem. Tanto durante a ideação de novos projetos quanto durante a criação.
Acredito que esse processo funcione muito bem aqui porque existem reuniões de apresentação dos novos projetos, antes de qualquer um começar a atuar nele.
Além disso, temos canais de comunicação onde podemos expor os pontos que ainda estão em definição e, claro, abertura para falar com qualquer um que esteja no mesmo projeto que você e trocar uma ideia enquanto tudo acontece.
Já conseguimos antecipar diversos problemas. Por exemplo: eu participei do desenvolvimento do nosso novo módulo de pós-pedido e da tela de acompanhamento de pedidos.
Quando começamos a implementar essa tela, foi confuso entender como as coisas se alinhavam, se ordenavam, como deviam se movimentar pela tela quando o usuário fizesse scroll.
Fizemos algumas versões de teste que apresentavam um comportamento nas interações diferente do esperado pelos designers. Logo depois, sentamos com o time de design e alinhamos tudo antes que trabalhássemos na versão final da tela.
Isso fez com que pudéssemos expor diversos pontos em que tínhamos dúvida e que poderiam ficar errados. Dessa forma, a versão final foi um verdadeiro mix do trabalho dos designers e dos desenvolvedores.
Faça pontes para onde quer chegar
O cenário do onboarding foi só um exemplo de como as coisas podem escalar rápido. Mas já antecipamos diversos cenários de animações, layouts quebrados, interações que ficariam ruins participando das discussões de design.
Além disso, o crescimento profissional que tive trabalhando próximo com o time de design foi sensacional. A ponte entre os times é um dos aspectos mais importantes para a versatilidade que temos que ter durante o desenvolvimento.
Se você sentir que falta conexão, com qualquer time que seja, comece você mesmo a criar essa ponte. Mostre que essa ponte vai ajudar todo mundo, e logo não será só você que a estará construindo.
Quer receber conteúdos exclusivos criados pelos nossos times de tecnologia? Inscreva-se.
