Quando eu explico para as pessoas que um bom Wireframe é mais que o suficiente para o desenvolvedor front-end – vulgo HTMLer ou implementador – começar a codificar, muitos webdesigners até entendem o fluxo, mas simplesmente NUNCA o praticam. Depois de algumas observações, percebi os motivos óbvios:

Pessoas metódicas

Eu sou uma pessoa metódica e sei como isso é. Pessoas metódicas (dependendo do grau) até conseguem sair da caixa, mas não gostam, nem se sentem a vontade; por isso, preferem esperar o design completo para então começar o seu trabalho.

Desorganização

Pessoas desorganizadas com o seu CSS não conseguem pensar em como estruturá-lo, de forma que depois tenham que mexer novamente e adaptarem a qualquer mudança. Assim sendo, precisam do layout finalizado para minimizar a chance de refazer a implementação de algo.

Preguiça

O pior aliado de um desenvolvedor qualquer profissão é a preguiça. A ideia de deixar tudo até os 47 do segundo tempo é um câncer que cada vez mais corrói sua produtividade e qualidade profissional e pessoal. Muitas vezes, o desenvolvedor acredita veementemente que é melhor ganhar uns dias, enquanto o designer prepara o layout, para só depois começar a trabalhar. Com um pouco mais de visão, o mesmo aprontaria o que desse antes para enquanto o designer estivesse preparando o layout final, ele poderia pensar em formas de melhorar o código, experimentar algo novo, propor uma funcionalidade diferente para a equipe e etc.

Surpresa!

O mais interessante disso tudo é que esse não é o principal motivo para o não desenvolvimento estrutural do HTML e CSS. O principal motivo é que quase em sua totalidade, o design da interface só é pensado ou levado a sério no momento que o designer faz o layout final. Muito se fala sobre wireframes, softwares, artigos, blogs, livros sobre AI, mas na prática, o mercado em sua maioria (me refiro mais à agências web) ainda continua com o seu fluxo medroso e antigo.

 

Modelo tradicional

O modelo é bem simples: cada etapa finalizada dá origem ao começo da etapa seguinte. Processo demorado e um profissional depende do término do outro.

Modelo avançado

O modelo necessita de uma documentação bastante definida no protótipo para que a etapa de codificação possa ser iniciada. Mais de um profissional pode atuar ao mesmo tempo no projeto. Com a interação e arquitetura definida, ainda pode ser iniciada uma terceira etapa simultânea que é a do desenvolvimento do sistema, ou programação.

Funcionamento em SCRUM

Muitas empresas aqui no Brasil e no exterior já trabalham com metodologias ágeis; a mais famosa atualmente é o SCRUM. O projeto é dividido em sprints, assim sendo, temos que aproveitar a sprint 1 para prever, mapear e arquitetar o que será feito na sprint 2. Paralelo a isso, temos que codificar o que será trabalhado na sprint atual e corrigir erros e melhorias da sprint atual e sprint anterior. Com um número de designers para atender esse fluxo, ele seria excelente, porém não é a realidade da maioria das empresas de desenvolvimento web, muitas vezes prejudicando o trabalho do design ou sobrecarregando o mesmo.

Crítica pessoal: Pelos livros que eu li, cursos e treinamentos em Scrum que participei pela Petrobras, além da prática, tenho certeza que quem inventou Scrum e divulgou para empresas de desenvolvimento, em nenhum momento parou para estudar o processo de esign de interfaces e sua importância para o produto e empresa.

O outro lado da moeda, o design centrado no desenvolvedor

Quando buscamos informações sobre design, achamos muitas informações sobre design centrado no usuário, caso você não esteja ainda totalmente confiante que faça isso, leia esses artigos de grandes nomes da web:

• Robson Santos – A necessidade do design centrado no usuário
• Amy Hillman – Pioneering a User Experience (UX) Process
• Frederick Van Amstel – Design centrado no usuário da web

O problema disso tudo é a grande difusão desse conceito em que o designer se concentra apenas no usuário e esquece que alguém terá que transformar isso em algo usável. De que adianta fazer um produto magnífico para o usuário se ele fará a empresa comprar uma máquina do Japão por 2 milhões, que não cabe na área da fábrica atual e precisará treinar seus mais de 800 empregados? O designer tem que levar isso em conta, mas quando o produto é online, poucos se concentram nisso.

Uma dica para ajudar o front-end na parte técnica é preparar o PSD de forma profissional, seguindo algumas regras como:

• Dar nomes intuitivos as layers;
• Organizar conceitualmente as layers em pastas;
• Colorir conceitualmente pastas também é interessante;
• Dê flattern nas layers que foram utilizados efeitos em mascaras, isso facilita e muito na hora do desenvolvedor cortar
• Todo ícone utilizado deve ser guardado numa pasta e ser enviado no mesmo zip que o PSD, assim o desenvolvedor não precisa pegar ícone por ícone e ir cortando;
• Padronize o espaçamento, isso não só é bom para o conforto da tela e aproximação de objetos baseados em Gestalt, como também facilita a medição para o CSS;
• Se utilizar fontes que não são do sistema, enviá-las junto com o zip;
• Crie uma pasta ou um outro PSD com o hover (interações), isso ajuda muito na hora do usuário criar o CSS e até mesmo influencia no HTML (dependendo do caso);
• Caso tenha um background grande bem trabalhado ou que se repita, envie junto com o zip;
• Crie um pdf ou qualquer outro tipo de documento, informando as cores usadas (hexadecimal), fontes usadas nos elementos h1, h2, h3, hn, p, li, etc., espaçamentos padronizados, largura de colunas.

Existem outras dicas na apresentação que fiz junto com o Victor Montalvão, no 15 EDTED, com o título Oficina de Planejamento de corte, o seu layout virando código.

Na prática

Entendemos que a baixa fidelidade é a melhor forma de começar o seu wireframe, pois é nela que você trabalhará e contraporá suas ideias. Porém acredito que após isso, ainda antes do layout, você pode tratar esse wireframe detalhado, e esse sim apresentar para a equipe e para o seu cliente. Um wireframe de alta fidelidade ou até mesmo um Interface Design antes do Context Design permitem o trabalho simultâneo de desenvolvimento front-end e back-end. Um exemplo disso:

Com uma interface definida, você consegue captar a semântica de cada item, além de estruturar da melhor forma o seu HTML para que seja flexível e limpo ao mesmo tempo, com classes genéricas e reaproveitáveis. O programador, por sua vez, já saberá os campos que serão utilizados e preenchidos pelo cliente. Tudo bem mais ágil e econômico não?

Seu HTML fica facilmente definido, inclusive o CSS estrutural pode ser feito, deixando os estilos de cores e fontes para uma segunda etapa.

Conclusão

É evidente que não é da noite pro dia que uma equipe chega a essa maturidade, mas é algo a ser sempre perseguido, inclusive inovado. Se criar algo novo na sua equipe ou empresa, me conte por aqui ou por e-mail ok?