Acho ótimo quando vejo outras pessoas dizendo ou fazendo as mesmas coisas que eu. Isso reforça a idéia de que estamos no caminho certo. E foi exatamente isso que vi hoje, vindo de um pesquisador de IHC da Stanford.
Com algumas semanas de atraso, resolvi assistir à aula extra, do curso de iPhone da Stanford, sobre “How to Build an iPhone App that Doesn’t Suck! (In 10 Easy Steps) “ do Steve Marmon (@marmon). Ele menciona 10 passos para se desenvolver aplicativos que não sejam “um lixo”. Porém, estes passos podem ser aplicados para quase qualquer projeto. Os passos comentados, estão a seguir:
1. Decide what to build (decida o que construir)
Encontre uma solução para um problema real. Muitas vezes pensamos em uma solução, mas sem entender direito, qual problema estamos nos propondo a resolver. Nestes casos, corremos o risco de não solucionar nenhum problema, ou de desenvolvermos uma solução que não será a melhor.
Para isto, saiba pra quem você está projetando e tenha-os em mente, ao desenvolver a solução. Focar em um grupo específico aumenta a chance de sucesso de um aplicativo, pois ele será bastante útil para um grupo e, com base no feedback desses usuários, você poderá melhorar seu produto e conquistar seus clientes. São as boas e velhas personas.
2. Visit the app store (visite a app store)
Não desenvolva seu aplicativo dentro de uma bolha! Veja se alguém já não teve a sua brilhante idéia. Observe como aplicativos similares resolveram os problemas que você está se propondo a resolver. Eles já devem ter obtido feedback de usuários e alterado o produto em função disso. Se você consultá-los, estará “recebendo” estes feedbacks, gratuitamente. Se existirem concorrentes, compare as vantagens e desvantagens em relação ao seu produto (benchmarking).
3. Explore possible solutions (explore as possibilidades de soluções)
Não se prenda à primeira solução. Ela SEMPRE será pior do que o que você pode conseguir com mais algumas tentativas. Trabalhe com as limitações e aproveite os padrões.
4. Sketch (rabisque)
Faça várias propostas de solução! Designs alternativos para o mesmo problema. Para ter uma boa idéia, tenha várias. Com 10 propostas, por exemplo, sua chance de ter algo realmente bom é muito maior. É assim que a Apple funciona. É assim que a IDEO funciona. Rabisque e comunique suas idéias.
5. Build a paper prototype (construa um protótipo de papel)
Não parta para o design gráfico ou programação, sem antes criar um protótipo de papel. Nesta fase, o custo de alteração é muito mais baixo. Pense, quanto tempo você gasta para alterar uma página no protótipo de papel? E para reprogramar uma tela? Aproveite para testar o protótipo com pessoas representativas e ver se o caminho que você está tomando é o correto. “Fail early to succeed sooner”.
6. Fire up omnigraffle (abra o omnigraffle)
Nesta parte, ele fala do omnigraffle para o caso específico do iPhone. O que ele quer dizer é para usar uma ferramenta que permita criar um protótipo de média resolução. Este protótipo vai ser esteticamente parecido com a versão final (layout), mas sem precisar gastar tempo programando. A idéia é a mesma da etapa anterior. Economizar recursos, alterando em estados que o custo da alteração é menor.
7. Do it all again (Faça tudo denovo)
Itere! Como todo design centrado no usuário, a parte mais importante do processo é iterar. Veja onde está com problemas e volte a questionar se a solução dada é a melhor para aquele caso. Pense em várias alternativas de correção para o problema encontrado. Prototipe antes de alterar. Teste e siga assim até que o produto esteja estável.
Lembre-se que nada é escrito em pedra. Tudo pode ser alterado. Até mesmo a idéia original. E, certamente, será…
8. Okay, you can code finally (Agora você pode programar)
Finalmente você pode partir para a programação do seu produto. Use padrões de programação como MVC, que possibilitem alterações futuras, sem muito trabalho, desvinculando o código da parte visual/apresentação.
9. Beta test your app (abra seu aplicativo para beta testers)
Use os testes para levantar os bugs que passaram desapercebidos pelos testes em protótipos e pelos programadores, como bugs relativos à satisfação dos usuários. Um exemplo, no iPhone, pode ser a rolagem da tela estar muito “lerda”. Os programadores vão achar que a tela está excelente, porque está rolando. Já os usuários, após algum tempo de uso, se sentirão incomodados com isso. O Tweetie foi o primeiro app de twitter a conseguir uma rolagem rápida, e teve grande destaque por conta disso.
10. Release (lance)
Se você fez tudo direito, este será um momento feliz. Senão, prepare-se para os problemas que virão (emails de bugs, reclamações, comentários negativos sobre o aplicativo etc.).
Tags: design de interação, inovação, iphone, iteração, mac, palestra, ux