Concrete Logo
Hamburger button

A importância dos protótipos para a agilidade

  • Blog
  • 20 de Fevereiro de 2015
Share
O desenvolvimento lean, assunto sobre o qual já falamos bastante aqui no blog, é 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 nos ajuda bastante é a prototipagem, que consiste em criar modelos reais do produto para testes de usabilidade, de conceitos e de otimização do produto. 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 apenas mentalmente 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 e já comece 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.
failfast
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.
Aqui 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 pode ser que você subestime 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.
cavalos mais rápidos

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). O uso de dados falsos ou reais também influenciam no protótipo e no resultado final do produto. Quando trabalhamos com “live-data” (dados reais), 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 você não pensaria nela com mock data.
tirinha1245

Conclusão

Normalmente, arrisco dizer que em 99,9% dos casos, quando pensamos o produto ou o projeto nós 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!