Design ou código, o que vem antes?

Os defensores de fazer o design primeiro têm algumas boas razões para isso. A programação é a fase mais pesada da construção de um aplicativo web. Isso quer dizer que é também a mais cara e onde a mudança é mais custosa.

A fase de design, ao contrário, é relativamente menos custosa, e esse é o motivo pelo qual algumas pessoas defendem que o melhor é projetar todas as telas antes de partir para o código. Nesse caso, só se codifica o que não vai mais mudar.

Mas quem defende que a programação deve preceder o design também tem ótimos argumentos. Quem desenha as páginas antes corre o risco de acabar com lindas telas que nunca serão codificadas. Isso acontece porque o Photoshop aceita qualquer solução, mas você nunca tem certeza do que vai realmente conseguir desenvolver. A natureza da atividade de design tende a ignorar limitações técnicas e de prazo.

Você deve estar pensando, assim como na anedota do ovo e da galinha, que nosso caso não tem solução. Mas tem. É simples: faça tudo ao mesmo tempo. Ponha o designer sentado ao lado do programador e chame-os de ‘time’. Estabeleça uma tarefa para os dois. Não uma grande tarefa, como ‘redesenhar o site todo’ ou ‘criar uma área nova’. Peça uma pequena unidade de tarefa como ‘deixar o usuário fazer upload de uma foto’ ou ‘permitir que o editor publique uma notícia’.

Você vai perceber que a colaboração entre designer e programador vai reduzir a frustração de ambos por perceber que algo não cabe no prazo. Também vai sentir que o re-trabalho vai diminuir, pois estamos falando de uma pequena tarefa sendo realizada por duas pessoas com formações complementares se comunicando. É muito rico.

O efeito telefone-sem-fio já me deixou perplexo em vários projetos que pareciam organizados. O briefing da equipe de produto chega até o arquiteto da informação, que faz um mapa de arquitetura e manda para o designer de interface, que desenha o wireframe e manda para o designer gráfico, que envia uma tela de Photoshop para implementação do html, que finalmente chega até os programadores.

É enorme a chance de informações acabarem perdidas ou distorcidas durante esse processo e é certo que se perde um tempo excessivo documentando o que ainda não precisa ser documentado. Isso é o que acontece quando os membros de um time de desenvolvimento estão distantes, isolados em suas equipes técnicas.

Trabalhar em times multidisciplinares é um dos fundamentos das ‘agile methodologies’. Elas também indicam que diminuir a documentação para o mínimo necessário melhora a velocidade do projeto.

Em vez de criar documentos para que o projeto circule entre áreas da empresa, é melhor juntar essas pessoas e deixar que elas se comuniquem. Vai deixar os designers felizes com suas criações funcionando 100% num curto espaço de tempo.

Vai melhorar o astral dos desenvolvedores, que poderão participar das soluções em vez de receber um pacote pré-determinado. E vai economizar preciosas horas de trabalho no seu balanço mensal.

Por Marcelo Gluz [Webinsider]