Prototipagem

Em algumas fases do processo, tanto para se proporem soluções como para as ir avaliando, são criados protótipos. Primeiramente podem ser usados para partilhar ideias entre os vários membros da equipa (designers, utilizadores, programadores, etc.), facilitando a comunicação e contribuindo para a evolução das soluções. Nomeadamente a prototipagem de baixa-fidelidade que é barata e rápida de preparar, é ideal para materializar alguns pensamentos sem grandes investimentos, tanto de tempo como de outra ordem. Permitem detetar falhas atempadamente, impedindo que se arrastem ao longo do projeto e facilitando processos iterativos na busca de melhores soluções (Santos, Beça, Figueiredo, & Raposo, 2011).

Os vários tipos de protótipos podem ser divididos em 3 categorias, dependendo da sua fidelidade em relação ao resultado final ( Farnum, 2002):

Baixa-Fidelidade - Podem ser feitos em papel, cartão ou outros materiais e usar desenhos muito simples ou diagramas. Teoricamente, são bastante rápidos de construir e permitem incluir o utilizador nesse processo, possibilitando-lhe contribuir ativamente e materializar as suas sugestões.

Alta-Fidelidade - Consistem em modelos bastante próximos do que se pressupõe que seja o produto final. No caso de aplicações digitais, pode-se tratar de uma plataforma em html, com a parte gráfica já bastante cuidada e interação, faltando ainda resolver grande parte da programação, mas permitindo ter uma ideia bastante concreta do seu funcionamento. No entanto, o seu desenvolvimento demora muito mais tempo que o anterior, sendo também mais difícil alterar, principalmente pelos utilizadores.

Média- Fidelidade - Está entre os dois anteriores. Têm um aspeto visual mais cuidado que os de baixa fidelidade e podem já ter alguma interação.

Poderão também variar em interatividade e no médium utilizado. Em termos de interatividade, podem ser estáticos, em que é pedido à pessoa para interpretar o interface em vez de interagir com ele; ou automáticos, por utilização de computador ou técnicas como o “Wizard of Oz”5. No que respeita ao médium,

tanto se podem usar simples folhas e recortes de papel como plataformas digitais. O protótipo deverá combinar a fidelidade, interatividade e médium consoante o que se pretende testar e com os recursos disponíveis ( Farnum, 2002).

Um protótipo é bastante útil durante a tomada de decisões ao longo do projeto, possibilitando experimentar e partilhar ideias com a equipa. Para além disso, apresenta uma importante mais-valia, permitindo chamar mais os utilizadores para avaliar as nossas soluções, durante testes de usabilidade. Dar-lhes a possibilidade de interagir com um protótipo e de o usar para transmitir as suas ideias é bastante vantajoso, na medida em que sentem que é dada mais importância à sua

5 Wizard of Oz é uma técnica de prototipagem que permite testar soluções em protótipos ainda incompletos. O funcionamento é simulado por alguém “atrás da cortina”, que faz corresponder a cada ação do utilizador, a resposta que o sistema daria, se estivesse completo (Davis, Saponas, Shilman, & Landay, 2007).

Figura 17 – Utilizadores a usarem e contribuírem para o desenvolvimento de um protótipo ( Naranjo- Bock, n.d.).

Figura 16 – Exemplos de prototipagem de baixa fidelidade do designer Helder Santos (Universidade de Aveiro) (Santos, n.d.) À esquerda, iPrototype; à direita, iPrototype Android

participação e às suas opiniões do que em cenários de testes mais tradicionais. É-lhes mais simples desta forma exporem os seus problemas e sugestões e o tom informal que se consegue deixa-os mais descontraídos, sendo a sua participação mais fácil. Muitas vezes, o termo “testes de usabilidade” remete-nos para cenários algo intimidantes, em que “o sujeito” está numa sala com cartões de tarefas e ligado a sensores enquanto “o investigador” está outra sala, observando-o e registando tudo o que faz. Embora esta metodologia possa ser usada, principalmente numa fase final do projeto, não tem que ser sempre assim. Há formas mais interessantes de o fazer e mais vantajosas em etapas anteriores do projeto (Chisnell, 2009).

Na metodologia que Jeffrey Rubin e Dana Chisnell (Rubin & Chisnell, 2008) propõem começa-se por desenvolver um plano para o teste, constituído pelos objetivos, perguntas e tipologia de participantes. As pessoas escolhidas para os testes deverão encaixar-se num perfil que muito próximo do utilizador final, ou seja, deverão ser alguém que realmente possa vir a usar o produto que estamos a tentar testar. É também bastante importante escolher um local e cenário para as sessões que possa deixar os participantes o mais à vontade possível, e se elas serão ou não gravadas.

O teste deverá simular o mais possível uma situação real de uso. Como tal, deverá ser preparada uma lista de questões, transformada em tarefas lógicas, que traduzam objetivos reais que o utilizador possa ter. Durante o teste, o moderador usá-la-á para conduzir a sessão e encaminhar o participante da melhor forma. No final, poderá haver uma segunda lista de perguntas para, nomeadamente, recolher a opinião do utilizador sobre o que acabou de testar e até fazer o levantamento de algumas sugestões que possa ter para o melhorar. Este “inquérito” final poderá também ser feito através de uma conversa informal entre o participante e alguns elementos da equipa que tenham assistido ao teste.

Após a realização dos testes, analisam-se os dados recolhidos. Reflete-se sobre os comportamentos registados e procuram-se causas para os problemas detetados. A partir desta informação, a equipa pode tomar novas decisões mais informadas e fazer alterações se necessário. Se possível essas alterações deverão ser novamente testadas até se atingirem resultados satisfatórios.

Embora haja a necessidade de algum rigor e metodologia num teste de usabilidade, nem sempre é necessário passar por todas estas fases de preparação. Na realidade, desde que tenhamos um utilizador, “algo” para testar (algum protótipo ou ideia, independentemente de estar acabado ou não), e um qualquer lugar em que a interação possa acontecer e a possamos observar, será suficiente para retirar informação válida para o projeto (Chisnell, 2009).