O desenvolvimento lean é todo baseado em validar, ou não, hipóteses. O objetivo é testar cada funcionalidade de nosso produto antes de colocá-lo em produção e, assim, aumentar consideravelmente nossas chances de sucesso. Neste sentido, uma das ferramentas que ajuda bastante é a prototipagem, que consiste em criar modelos reais do produto para testes de usabilidade, de conceitos e de otimização. O conceito se apoia na simples ideia de que aprendemos muito mais analisando modelos reais, do que imaginários. Até porque o tempo e o esforço gastos pensando no produto muitas vezes são desperdiçados, pois não nos levam aos problemas, e consequentemente, aos insights, do seu uso real.

“Fail fast”

O primeiro mandamento ágil é falhar rápido, ou “fail fast”. A ideia que esta expressão traz é a de que o ciclo entre o pensar o e desenvolver seja o mais curto e mais barato possível, para que se o seu produto não for o certo a ser construído, você falhe logo e sem gastar muito. Assim, você já começa a pensar na próxima ideia. Para isso, é importante usar um método que gere o maior valor e o maior aprendizado para a evolução de seu produto, e é aí que chegamos aos protótipos.

Quando falamos de aplicativos mobile, o método mais utilizado é a geração de layouts estáticos, ou seja, “fotos” de telas do aplicativo. Normalmente, essas telas podem animar os usuários mais leigos, mas não são suficientes para comunicar tudo o que pode acontecer no aplicativo. Isso porque temos transições, toques, swipes, “pinch to zoom” e uma infinidade de interações que temos que mostrar aos stakeholders e desenvolvedores, e poder mostrar a ação acontecendo gera bastante valor nessa hora.

Na Concrete Solutions, temos refletido sobre três caminhos. O primeiro deles é usar a ferramenta Invision, que permite mesclar layouts estáticos com uma navegação bem similar a de um app real. É excelente para testar o fluxo de telas e você pode apresentar alterações e contar com colaborações em tempo real. A segunda opção é desenvolver um app híbrido com HTML/CSS e uma Webview (Android – iOS). Caso o designer tenha algum conhecimento de desenvolvimento front-end (vários de nós temos), esse método permite uma maior liberdade de criação, ainda mais se usarmos frameworks que ajudem a simular interações dos sistemas, como o Polymer para o Material Design do Google, por exemplo. Por fim, a última opção é aprender mais sobre as ferramentas de cada sistema, como o XCode para iOS e o Android Studio para Android. Essa terceira via é a mais “close to the metal” possível, uma vez que usufrui de todas as facilidades de integração com componentes nativos.

Seja qual for o caminho escolhido, é importante ter em mente que protótipos são experiências, tanto no sentido material (estamos testando algo físico) quanto no sentido de vivência pessoal, afinal é testando que se aprende e conseguimos pôr em prática alguma ideia. Além disso, é legal lembrar também que protótipos são apenas testes para saber se algo que pensamos vai funcionar ou não, e não o “algo” em si. Os protótipos devem ser feitos da forma mais rápida e barata possível, apenas para eliminar o tempo e o esforço gastos em produtos que não farão sucesso algum.

E a inovação?

Algumas dúvidas surgem acerca da prototipagem e a principal delas está relacionada à inovação que o produto pode trazer. Como disse certa vez Henry Ford, se as pessoas fossem perguntadas sobre o que queriam em relação a transporte, elas diriam “cavalos mais rápidos”, e não um automóvel. Isso significa que, ao se prender apenas aos feedbacks do usuário, você pode subestimar a inovação e as ideias novas. É preciso saber lidar com o “deixar ser levado apenas pelo que as pessoas dizem que querem” e focar na melhor forma de resolver os problemas que elas possuem.

Usar os dados que ganhamos com os testes é muito importante para guiar decisões, mas é preciso tomar cuidado com o espaço que deixamos para a inovação. Steve Jobs, por exemplo, era um pouco arrogante em pensar que ele sabia o jeito certo de fazer todas as coisas, mas foi assim que ele gerou algumas grandes ideias.

Alta fidelidade

Quando falamos de protótipos, na maioria das vezes evidenciamos o processo que envolve “cada vez mais fidelidade”. Isso significa que a cada passo vamos aumentando a interação do usuário até que essa interação seja a mais natural possível. A ideia é que o usuário nem pense que está usando um protótipo, mas acredite que está no app de verdade. É quando você menos pensa sobre a ferramenta que ela pode ser percebida mais naturalmente. Ou seja, quanto menos o usuário se prender ao fato de que o protótipo é um wireframe ou está “rodando no browser”, melhor será o feedback dele sobre o que realmente queremos.

Entretanto, a alta e a baixa fidelidade dos protótipos têm seus pontos positivos e os negativos. Os protótipos de baixa fidelidade são mais rápidos de serem desenvolvidos e iterados, o que é essencial. Entretanto, pode gerar certo “ruído”, por ter o aspecto de inacabado. Muitas vezes, os protótipos de baixa fidelidade são apenas um wireframe, e o feedback do usuário pode ser afetado com isso. Por sua vez, os protótipos de alta fidelidade levam mais tempo para serem construídos, mas permitem uma “ilusão” de app pronto, o que traz feedbacks mais concretos.

Lembrando que todos os métodos de construção de protótipos que citamos acima, como o Invision, o app híbrido e o XCode/Android Studio podem oferecer tanto um protótipo de baixa quanto um protótipo de alta fidelidade, depende do tempo em que é desenvolvido e do aspecto final. Por exemplo, podemos fazer no XCode um protótipo bem rápido, de baixa fidelidade, usando apenas assets desenhados rapidamente ou só componentes “prontos”, que não estão muito ligados à identidade do app, assim como podemos usar no Invision telas “perfeitas”, geradas no Photoshop ou no Sketch. Tudo depende do objetivo do protótipo e da hipótese que queremos testar, bem como do estágio em que o produto/projeto se encontra.

Também temos que levar em conta os dados que estamos utilizando para incrementar nosso protótipo. Assim como podemos trabalhar com alta ou baixa fidelidade, também trabalhamos com dados falsos (mock data) ou verdadeiros (live-data). A escolha de que tipos de dados usar também influencia no protótipo e no resultado final do produto. Quando trabalhamos com “live-data”, temos a chance de esbarrar em situações imprevisíveis enquanto estamos apenas desenhando. Quando a Alemanha venceu o Brasil por 7×1 na Copa, por exemplo, o placar teve de ganhar uma barra de rolagem para conseguir mostrar tantos gols, e provavelmente, se você estivesse usando mock data, não pensaria na possibilidade desse resultado (logo, não teria necessidade de uma barra de rolagem).

Conclusão

Normalmente, arrisco dizer que em 99,9% dos casos, quando pensamos o produto ou o projeto, não somos capazes de prever todas as interações necessárias para uma usabilidade “perfeita”. É só depois de iniciar o processo de construção e uso que nos damos conta dos furos que ocorrem no fluxo que pensamos inicialmente. Neste sentido, protótipos são necessários para trazer mais agilidade e assertividade nos processos de desenvolvimento. A questão que fica é qual o melhor método para passar aos desenvolvedores e stakeholders as interações e fluxos do app. Dentre as opções, podemos escolher entre prototipagem rápida (wireframes) ou de alta fidelidade (telas pixel perfect) por meio de mockups em HTML/CSS + Webview, Invision ou diretamente no XCode ou Android Studio. O importante é prototipar!

Ficou alguma dúvida, tem alguma sugestão ou crítica? Deixe seu comentário abaixo!