O wireframe enquanto método, não entregável

Protótipos são o assunto do momento no mundo de UX, enquanto wireframes estáticos são aos poucos deixados de lado. Mas e se passarmos a olhar os wireframes como parte do processo, não apenas como um entregável?

Image for post
Image for post

Novas ferramentas surgem a cada dia para permitir que UX Designer criem protótipos de seus wireframes ou layouts em poucos cliques. Wireframe estático, do jeito que se usava há alguns anos, realmente parece ter ficado no passado.

Nós mesmos já falamos por aqui do “começo do fim dos wireframes” — e sobre algumas alternativas como wireframes colaborativos, sketches, ou co-criação entre designer e desenvolvedor na hora de pensar e planejar interfaces dos produtos digitais que criamos todos os dias.

Mas nesse artigo vamos olhar um pouco para o outro lado da moeda: será que os wireframes não possuem vantagens em relação a outros métodos e entregáveis de UX?

“Mas espera, não foram vocês mesmos que disseram que wireframe era um monstro cruel e sujo e que estava atrofiando aceleradamente o cérebro dos designers?”

Não.

Mas entendemos que as redes sociais tenham deixado o pensamento das pessoas um pouco binário demais: ou algo é um vilão, ou é um herói — e não existe meio termo aí (vide posts sobre política no Facebook). Então para deixar esse pessoal do “sim” e do “não” de cabelo em pé, a pergunta retórica do dia: e se você passasse a olhar o wireframe como parte da jornada, e não necessariamente como o destino final?

Os wireframes e o pensamento solitário do designer

Uma das belezas de como os wireframes (de média e alta fidelidade) são construídos, é que eles requerem um certo tempo do designer sentado em sua mesa pensando em como a interface irá funcionar.

Normalmente tudo começa com sessões colaborativas de whiteboard, ou com rabiscos em papel: vários designers, desenvolvedores e criativos trabalham juntos em uma sala/mesa para definir em linhas gerais como o produto (ou como uma tela desse produto) deverá funcionar. Mas acontece que, passada essa etapa inicial, alguém precisa coletar o que foi discutido em grupo e “passar tudo a limpo” — e é justamente nessa hora que as decisões mais aprofundadas sobre o produto são tomadas.

Pois é. Apesar de saírmos dessas sessões colaborativas com a impressão de que tomamos todas as decisões necessárias para definir o produto, ainda tem muita, mas muita coisa a ser definida. Obviamente, são pequenos problemas e decisões que só vão aparecer quando alguém começar a olhar com mais atenção para a interface:

  • Como fica essa interface em dispositivos menores?
  • Qual o conteúdo real que devo colocar em cada um desses cards?
  • Qual a melhor ordem para mostrar as informações na página de produto?
  • O que acontece se o usuário estiver deslogado nesse momento?
  • E assim por diante…

Geralmente essas pequenas decisões são tomadas “solitariamente” pelo designer, já quando ele está sentado em sua mesa documentando tudo em wireframes. E não é porque são “pequenas” que essas decisões são menos importantes: muitas vezes são elas vão determinar o bom (ou mau) funcionamento de uma interface, e consequentemente a experiência que os usuários terão com ela.

Por mais que os wireframes em si não sejam oficialmente um dos entregáveis de determinado projeto, o processo de se chegar até eles já é vantajoso por si só. Passar por essas pequenas decisões é um processo que não pode ser negligenciado — e o risco de não fazer wireframes e ir direto para o layout é deixar algumas pontas soltas no produto, que só irão explodir lá no momento do desenvolvimento. E aí já pode ser tarde demais.

Wireframes anotados: se você entregar, pouca gente vai ler

O designer então passa horas refinando a interface, tomando essas pequenas decisões de design que são importantíssimas para o produto, documentando tudo em um grande deck de wireframes anotados — então é natural que ele também queira “entregar” tudo em um grande e pesado PDF para todos os membros do time.

O problema é que pouquíssima gente estará interessada em ler essas extensas anotações. Até mesmo os desenvolvedores, que teoricamente são a principal audiência para wireframes anotados em detalhes, não têm muita paciência para ler o documento que você passou longos dias construindo. Pois é, os designers e os desenvolvedores também são millennials e talvez não tenham paciência para leitures muito longas ou complicadas :)

Minha sugestão:

  • Desenhe os wireframes completos. É importante passar por esse processo, tomar todas as grandes e pequenas decisões e saber como o produto deve funcionar, sem furos.
  • Documente apenas as 2–3 principais telas e anote somente o necessário. Uma versão mais “leve” das anotações tem mais chance de ser lida pelo gerente de projetos, desenvolvedor, designer visual — e principalmente pelo cliente. Trate isso menos como uma documentação que eles devem seguir à risca, e mais como um suporte para o time.
  • Apresente ao invés de mandar por email. Uma conversa com os envolvidos pode ser muito mais produtiva (e rápida) do que cada um lendo os wireframes em isolamento e tirando conclusões diferentes. Nem é preciso falar que ouvir uma apresentação é muito menos maçante do que ler um documento de wireframes de 50 páginas.

No geral, tente tratar os wireframes menos como um destino final. Aceite o fato de a interface vai mudar bastante, e que ninguém no time está realmente interessado em jogar o jogo seguindo as regras que você definiu.

O importante foi o processo de se chegar até lá: no meio do caminho você pensou em cenários e variações que, depois de aprendidos, ninguém consegue tirar de você. Por um processo de design livre de formalidades, mas não isento de pensamento em profundidade.

Written by

Designer at Work & Co, Founder of UX Collective — http://twitter.com/fabriciot

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store