Como você tem escolhido a fidelidade dos seus protótipos?
O que podemos considerar na escolha da fidelidade dos protótipos e o como isso pode afetar no seu trabalho.
Uma das principais finalidades da prototipação é validar uma ideia ou conceito, e dentre os principais ganhos em relação a um projeto, estão o investimento baixo e o de se falhar de forma mais rápida e barata.
“Estima-se que seja 100 vezes mais barato fazer mudanças antes de escrever qualquer código, do que aplicá-las após a implementação.”
— Jakob Nielsen
Estas não são informações novas, porém, mais do que falar do benefício da validação propriamente, considero que o primeiro ganho no desenrolar da prototipação é a melhora na comunicação entre as partes.
Isso porque nos tira do campo das ideias, levando da comunicação verbal para a comunicação visual. A comunicação visual, reduz a subjetividade e interpretação significativamente — inclusive, percebo que cada vez mais paredes “rabiscáveis” são comuns nas salas de reunião.
Bom, mas falando de prototipação, atualmente vejo um grande volume de discussões sobre a ferramentas e a efetividade de cada uma delas. Porém muito além do “Fla x Flu” entre a turma de Sketch, XD e Figma, a questão da escolha da fidelidade é uma pauta muito menos recorrente, o que me fez pensar em o quanto estamos menosprezando os impactos que esta escolha pode ter no projeto e nas habilidades do UX designer.
Quando pesquiso por portfólios, observo que na maioria das vezes o pobre do wireframe fica escondido ou aparentemente foi extinto do processo.
Quando sugiro a um PO (Product Owner) ou PM (Product Manager) esboçarmos as primeiras ideias através de wireframes vejo muito insegurança no olhar, afinal, será que o time ou o usuário vão saber abstrair a interface “feia” e monocromática? Será que vou conseguir validar algo?
Como escolher a fidelidade de um protótipo?
Tenho uma percepção de que em geral a escolha das ferramentas de prototipação se baseia muito mais pelo conforto em pilotar esse ou aquele software que se está habituado do que o objetivo a ser validado.
Isso é compreensível afinal todas eles contam com interfaces incríveis, incorporam cada vez mais efeitos, bibliotecas e possibilidade de chegar a um resultado super fiel ao sistema final em pouquíssimo tempo, mas será que é o bom chegar lá tão rápido?
Geralmente, gosto de escolher a fidelidade de um protótipo considerando três critérios de reflexão:
- A solução que será prototipada é algo novo ou existente?
O quanto daquela solução ainda é uma hipótese ou de alguma forma já acontece. Por exemplo eu estou criando um processo novo ou apenas mudando a interface de uma experiência que já existe porém em um formato ruim ex: Bons relatórios em uma planilha de Excel. - O Protótipo fará parte de um ecossistema de UI?
O quanto está prototipação é algo incremental dentro de um universo de interfaces e padrões bem definidos Ex compartilhar de um comprovante dentro de um banco digital. - O Protótipo servirá para validar com o time ou com o usuário final?
Se a validação ainda for com o seu time, vocês ainda estarão saindo da comunicação verbal para a visual, não vejo problema alguma interações ainda esteja totalmente representadas ou alguns links não estarem funcionais. Já no caso de apresentar o protótipo em um teste de usabilidade, por exemplo, que o ideal é explicar o mínimo possível sobre o fluxo esperado e não interferir na execução da tarefa, porém se alguma falha acontecer não é o fim do mundo, e é indicado perguntar ao usuário o que ele imaginaria que iria acontecer.
Em complemento, vale a pena dar um olhada no artigo da NN/g sobre Protótipos de baixa vs alta fidelidade, que trata desde os benefícios obtidos em cada um dos casos, além de propor sete questões podem ajudar a decidir entre estáticos e navegáveis.
Acredito que quanto mais hipotética a ideia e menos inserida em um contexto de elementos de interface bem estruturados, é muito melhor fazer uso de um protótipo de baixa fidelidade, papel ou wireframe.
Isto porque o será muito mais rápido de ser construído, refeito e alterado, existem muito mais possibilidades de desdobramentos, mudanças de fluxo e principalmente o desapego. Sua equipe não está acostumada com um padrão visual, existem muitas questões estratégicas e de construção a serem discutidas.
Usar um protótipo lindão cheio de detalhes em alta fidelidade provavelmente fará as pessoas dividirem o foco entre estratégia e estética, por exemplo ao invés de discutirem a lógica por trás das opções de frete a serem oferecidas será discutido se o canto do campo de formulário deve ser quadrado ou redondo e aquela foto é a mais agradável ou seria melhor outra opção.
Um outro erro comum é criar apego aquele bebê protótipo lindo, ninguém terá coragem de pedir para repensar, despertará uma vontade enorme de fazer um puxadinho, colocar um “botãozinho”, “uma droplinstizinha” que jogará um monte de regra de negócio para debaixo do tapete e tenha certeza vai isso vai dar problema no futuro.
Em contrapartida quanto mais incremental a ideia, ou seja você quer prototipar uma nova funcionalidade e não o seu principal seu serviço, e quanto mais inserida em um contexto onde já existe um grande volume de elementos de interface bem estruturados, o melhor é fazer uso de um protótipo de alta fidelidade, isso porque sua equipe já terá um repertório visual bem estruturado, boa parte dos elementos já estão validados e poucas regras estéticas devem entrar em pauta.
Cada vez mais precisamos ter cuidado com as boas práticas compartilhadas, nem sempre o que funciona na grama do vizinho vai funcionar na sua.
No final a prototipação sempre vai ser funcionar de alguma forma, porém a escolha certa de acordo com as variáveis do projeto poderão contribuir para ampliar ou reduzir tanto velocidade de construção, quanto a maturidade e chance de êxito da solução.
