Eu sei, o título deste post é um pouco polêmico. Mas talvez seja apenas o fim do wireframe como o conhecemos hoje, ou apenas uma mudança na forma de produzi-lo.

O que me motivou a escrever sobre o assunto foi uma mudança na forma de trabalhar nos últimos projetos em que participei – e uma mudança de mentalidade que tenho observado em times de UX com os quais tenho maior contato.

Wireframes são uma ótima ferramenta na hora de demonstrar como uma interface deve funcionar e quais informações estão contidas nela, além de serem muito mais rápidos de serem produzidos (e alterados) do que os layouts em Photoshop.

Até aí, nenhuma novidade.

No entanto, existem outras ferramentas e métodos que conseguem cumprir o mesmo papel em muito menos tempo e com um pensamento mais ágil.

Até alguns anos atrás era muito comum que em um projeto fossem desenvolvidos wireframes, layouts e depois mockups clicáveis de uma determinada interface. Um processo de trabalho em cascata, onde cada entrega é validada com o cliente para que a etapa seguinte se inicie. Essa é uma forma segura de garantir que o visual designer só começará a trabalhar quando o wireframe tiver sido aprovado pelo cliente e pelo restante do time, evitando horas desperdiçadas em refação.

Acontece que no exemplo citado acima, o time acaba desenvolvendo 3 protótipos sequenciais. O wireframe nada mais é do que um protótipo, uma simulação de como a interface deve funcionar. O layout em jpg também é um protótipo, uma segunda simulação da mesma interface. E quando o UX utiliza uma ferramenta de criação de layouts clicáveis ou wireframes clicáveis, ele acaba criando um terceiro protótipo da mesma tela.

O pior: nada disso é aproveitado na hora dos desenvolvedores escreverem o código.

São três layers diferentes para se chegar ao mesmo resultado. Ou duas, em alguns casos onde a ferramenta de wireframing é a mesma de criação de mockup clicável (o Axure é um bom exemplo disso). O problema é que quase tudo é posto de lado na hora dos desenvolvedores começarem a trabalhar.

Em discussões recentes com o time de Experience Design da R/GA (NY e SP), começamos a listar outras alternativas para agilizar essa etapa do projeto. E também colocamos algumas delas em prática.

Algumas alternativas que testamos:

• Wireframes colaborativos entre todos do time. Semana passada montei uma sessão de wireframing com todos os membros da equipe (visual designer, producer, redator, front-end developer, back-end developer e planejamento), onde usamos papel, post-its e caneta para montar as telas juntos – cada um colocando seu ponto de vista em cada decisão que tomávamos. Funcionou muito bem, especialmente porque o projeto tinha poucas telas. Em duas sessões de duas horas conseguimos montar o fluxo principal do site. A parte boa é que, saindo da reunião, todos já sabiam o que o site deveria conter e já puderam começar a trabalhar no mesmo dia, sem precisar esperar um deck de wireframes de 50 páginas para isso.
• Sketches de UX + styleguides de Visual Design. Em alguns casos específicos, fica mais fácil desenhar em papel o conteúdo da tela e já partir para o Photoshop com o visual designer. A diferença é que, ao invés de layoutar tela a tela, o designer cria apenas os elementos-chave da interface, separadamente, como em um styleguide. O programador front-end junta as duas coisas (o sketch com o styleguide), direto no código. Isso torna a etapa de UX e arquitetura de informação muito mais curta, e também a de visual design. Mas talvez não funcione muito bem caso o site tenha um back-end muito complexo; algumas regras deveriam ser melhor documentadas para o desenvolvedor.
• Mockups clicáveis. Essa opção pode ser feita usando o clássico Axure ou então uma dessas ferramentas que cria links em jpgs. A parte boa é que fica muito mais fácil para o cliente entender como o produto irá funcionar, sem precisar percorrer extensas páginas de wireframes. A parte ruim é que isso não descarta o trabalho inicial de pensar na AI da página (e layoutar, caso você queira que o mockup tenha o visual final). Outro ponto negativo é que depois que o cliente aprova o mockup, o código não é reaproveitado pelo front-end developer.
• UX aprendendo a programar. Essa é uma ótima alternativa, para que o próprio UX designer monte o wireframe/protótipo usando HTML e CSS. Muita gente tem falado por aí sobre “desenhar no próprio browser“. A parte boa é que o protótipo fica muito mais realista (pode ser até mesmo responsive) e o desenvolvedor consegue aproveitar uma parte do código no futuro. A parte ruim é o risco do UX Designer ficar muito entretido nas linhas de código e ter pouco tempo para se afastar, ter uma visão geral da experiência e advogar pelo usuário mais do que pela interface – que convenhamos, é o que o UX faz de melhor.
• UX e front-end developer criando protótipos juntos. Esse me parece o melhor caminho até agora, ou pelo menos o caminho que tem funcionado para mais tipos de projetos. Cria-se uma dupla de UX designer e desenvolvedor e eles desenham e montam juntos o protótipo. Tudo é feito sem muita necessidade de documentação, já que eles sentam lado a lado. Como é o próprio desenvolvedor front-end que está escrevendo o código, 100% dele é reaproveitado no produto final – ele só precisa adicionar o estilo depois que o visual designer tiver definido o styleguide no Photoshop.

Acho que uma das principais motivações nesse processo de reinventar o fluxo de trabalho de um time de Design é a constatação de que wireframes de alta fidelidade não têm tido um bom desempenho em certos tipos de projeto. Entre os principais problemas desse tipo de entregável:

1. Wireframes estáticos não são muito bons em representar um design responsivo, a não ser que você desenhe umas 5 versões diferentes dele ou mais.
2. Wireframes muitas vezes tentam simular um comportamento que já é nativo do HTML e do CSS.
3. Alterações no wireframe de alta fidelidade levam mais tempo para serem feitas do que no código, por mais que você use elementos-mestres e outras táticas.

Antes de prosseguir, penso que seja importante diferenciar dois termos que, apesar de parecidos, são bem diferentes um do outro: protótipos e mockups. Pelo menos essa é uma diferenciação que sempre deixamos claro na agência.

Protótipo é uma primeira versão do produto, criado com a mesma linguagem de programação que será usada no produto final. Isso garante que o comportamento do protótipo seja mais próximo do comportamento final da interface – e também que o código possa ser reaproveitado na hora de construir a versão final. O Axure não gera protótipos, segundo essa definição; o que ele gera são mockups clicáveis.

Mockup é uma simulação de como a interface deve funcionar. Um wireframe em PDF é um mockup. Um layout em JPG é um mockup. Um wireframe clicável que não foi feito na linguagem de programação final que o produto usará também é um mockup.

Outro dia li um artigo que trazia uma lista das vantagens de protótipos em relação aos wireframes segundo Leisa Reichelt:

• You’re making, not documenting. You can feel the thing you’re making.
• You’ve got a thing you can start testing, in all kinds of ways, almost immediately. Prototyping is more like experimenting than describing your grand design.
• It doesn’t have to look good to be effective. It’s easier to keep it rough which helps people give better feedback early on.
• You start out with the barest structure of an idea and gradually build in the detail as you play with and test out the thing you have made.
• You’re learning useful things (like how to better translate your ideas into code).
• Stakeholders and clients get excited about prototypes in a way they never do about wireframes.
• Prototypes are concrete where wireframes are abstract.
• Prototypes create the impression of real progress—of something actually happening—in a way that wire framing never does.
• Prototyping is addictive—you have to pull yourself away from it (rather than forcing yourself to stay in your chair and finish annotating your wireframes).
• Prototyping encourages cross-disciplinary teams from the earliest stages of design. You get to work with smart people who can make your work better.
• If you’re on a project where you feel like you have to wireframe extensively, there’s probably a better way to be doing that project.

A essa altura já deu para entender melhor o motivo do título do post.

E se você chegou até o fim desse post pensando que encontraria a resposta definitiva para o método que “substituirá” os wireframes, essa resposta talvez nunca chegará. Existem várias “vertentes” diferentes: a que acredita que designing in the browser é a melhor opção, a que acredita em post-it e caneta, a que acredita em sketches e muitas outras.

Eu prefiro não enxergar como “vertentes”, e sim como diferentes opções, cada uma com seus prós e contras. Cabe ao UX designer entender a ferramenta que funciona melhor para aquele projeto, para aquele prazo, para aquele time e para aquele cliente. That’s where the magic happens.