Do wireframe ao pixel perfeito: o nosso processo de design

O que fica entre as duas pontas

Um wireframe testa estrutura sem se distrair com cor ou tipografia. Chegar ao pixel perfeito cedo demais esconde problemas de hierarquia que so a estrutura nua revela.

Cada etapa entre as duas pontas existe para responder a uma pergunta especifica — e pular etapas so adia a pergunta para depois de o custo de mudar ser maior.

Antes de desenhar, perceber

A primeira versao de um ecra e quase sempre uma resposta a pergunta errada. Nao porque quem desenha se enganou, mas porque a pergunta certa so aparece depois de alguem tentar usar o que foi feito.

Por isso separamos duas conversas que costumam acontecer ao mesmo tempo: o que a pessoa esta a tentar fazer, e como o produto lhe responde. Misturar as duas leva a discutir o tamanho de um botao antes de saber se ele devia existir.

Na pratica isto e meia duzia de entrevistas curtas e um mapa do percurso actual, com os pontos onde as pessoas desistem marcados a cor. Costuma caber numa semana e poupa meses.

O que testamos e o que assumimos

Nem tudo se testa. Ha decisoes que custam mais a validar do que a desfazer, e essas assumem-se com consciencia em vez de bloquearem o trabalho a espera de dados.

A regra que usamos e simples: se desfazer for barato, decide-se e segue-se; se for caro, mede-se primeiro. Escrever essa distincao evita a discussao interminavel sobre se ha dados suficientes.

O que fica de fora tambem se escreve. Uma lista do que NAO vamos resolver nesta fase e o que impede o ambito de crescer sozinho enquanto ninguem olha.

Entregar sem partir o que ja funciona

Um redesenho que muda tudo de uma vez torna impossivel saber o que melhorou. Se as metricas subirem, nao se sabe porque; se descerem, tambem nao.

Preferimos entregar por partes, com o antes e o depois a conviver o tempo suficiente para comparar. E menos espectacular e muito mais util a segunda iteracao.