2. USABILIDADE
2.7 Engenharia de Usabilidade
2.7.3 Atividades da Engenharia de Usabilidade
2.7.3.4 Construção de Versões Interativas dos Designs
Segundo Preece, Rogers e Sharp (2005), existem dois tipos de designs: o
conceitual, que se preocupa em transformar os requisitos e as necessidades do
usuário em um modelo conceitual e o físico, cuja preocupação está em detalhes do
design, tais como a tela, as estruturas dos menus, os ícones e os gráficos.
A preocupação do design conceitual é transformar os requisitos e as
necessidades dos usuários em um modelo conceitual. Preece, Rogers e Sharp
(2005, p. 268) definem o modelo conceitual como:
“...uma descrição do sistema proposto - no que diz respeito a um
conjunto de idéias integradas e de conceitos sobre o que ele deveria
fazer, como se comportar e com o que se parecer - que seria
compreensível pelos usuários da maneira pretendida”.
Para o desenvolvimento de um modelo conceitual é preciso visualizar o
sistema proposto, baseando-se nas necessidades dos usuários e nos requisitos
identificados. A verificação se o modelo será entendido da forma pretendida é
realizada a partir de testes interativos ainda na fase de desenvolvimento do produto
(PREECE, ROGERS e SHARP, 2005).
Segundo Mayhew (1999), o design do modelo conceitual define um processo
coerente que possibilita a unificação da identificação e análise dos dados coletados
com todas as decisões de detalhes do design, sendo o primeiro passo real na
concepção da interface do usuário.
Preece, Rogers e Sharp (2005) alertam para a dificuldade da atividade de
transformar um conjunto de requisitos em um modelo conceitual “melhor” ou mesmo
um modelo “bom o suficiente” e sugerem que uma das melhores maneiras de se
proceder é mergulhar nos dados e tentar criar uma empatia com os usuários.
Após a coleta e o estabelecimento do conjunto de requisitos, iniciam-se as
atividades de design, que devem evoluir de forma iterativa, em ciclos de
design-avaliação-redesign (Figura 16, p. 61) envolvendo os usuários. Nos primeiros
estágios do desenvolvimento, os protótipos são as primeiras versões interativas do
sistema e podem ser feitas de papel e cartolina; com o progresso dos designs e o
detalhamento das idéias, os protótipos vão se tornando partes do software, pois
passam a se parecer com o produto final (PREECE, ROGERS e SHARP, 2005).
Os protótipos são artefatos que possibilitam visualizações do futuro sistema e
podem se constituir em um esboço de uma tela ou um conjunto de telas desenhado
em uma folha de papel, num conjunto de imagens de telas em um vídeo, enfim,
qualquer representação que possibilite aos usuários, desenvolvedores e
interessados interagirem com o produto desejado (PREECE, ROGERS e SHARP,
2005).
A utilização de protótipos é muito útil nas discussões entre os interessados no
sistema, facilita a comunicação pela demonstração de idéias e são eficazes para o
teste de soluções. Preece Rogers e Sharp (2005) citam que os protótipos
esclarecem requisitos vagos, possibilitam a realização de testes com usuários e
verificam se o design é compatível com o restante do sistema.
Além da utilidade e dos benefícios, Nielsen (1994) complementa que o uso de
protótipos pode economizar tempo e dinheiro no desenvolvimento de algo, pois a
longa experiência em engenharia de software indica que é muito mais barato mudar
alguma coisa no início do projeto do que no final.
A prototipação pode ser de baixa ou de alta fidelidade. Os protótipos de baixa
fidelidade não se assemelham muito ao produto final, são simples, baratos e de
rápida produção. Por serem facilmente modificáveis, oferecem excelente suporte à
exploração de designs e idéias alternativas e são particularmente indicados nos
primeiros estágios do desenvolvimento (PREECE, ROGERS e SHARP, 2005).
Os storyboards (Figura 18) ou narrativas gráficas são protótipos de baixa
fidelidade e são utilizados para representar as interações entre o usuário e o
sistema. A representação é feita por uma seqüência de desenhos de esboços de
tela e elementos do contexto de uso (CYBIS, BETIOL e FAUST, 2007).
A seqüência de desenhos pode ser feita em folhas grandes, coladas em uma
parede para serem validadas pelos usuários e especialistas com base nos requisitos
de usabilidade coletados.
Figura 18 - Exemplo de Storyboard
Fonte: Adaptado de Cybis, Betiol e Faust (2007, p. 152)
As maquetes (protótipos de papel) são esboços do sistema, utilizadas para o
esclarecimento e desenvolvimento de requisitos específicos da interface. Favorecem
a simulação e o teste da interação de maneira bastante rápida, necessitam de
mínimos recursos e proporcionam a identificação precoce de problemas de
usabilidade (CYBIS, BETIOL e FAUST, 2007).
Preece, Rogers e Sharp (2005) atentam para que as pessoas não se sintam
inibidas em razão da qualidade de seus desenhos, e que podem usar bonequinhos
de palito, quadradinhos para ícones, procurando desenvolver seus próprios
símbolos.
Segundo Cybis, Betiol e Faust (2007), a construção de maquetes é
organizada em quatro etapas:
requisitos ou especificações do sistema em modelos conceituais de
interface. A partir de uma reunião, buscando a geração de idéias, são
definidas as telas com os componentes essenciais e o mapa de
navegação com o fluxo principal do sistema.
• Projeto da interação: em reunião com usuários e projetistas,
definem-se os nomes de cada tela sugerida, criam-definem-se cartões com os nomes de
cada tela. Os cartões são dispostos em uma parede, o grupo de
usuários e projetistas verifica a seqüência em que as telas são
acessadas durante a realização da tarefa. A seqüência pode ser
reorganizada, cartões de telas podem ser suprimidos ou adicionados.
• Projeto e teste das telas: nesta etapa, as telas identificadas na etapa
anterior são criadas e para o teste, o projetista deve organizar uma
reunião com os usuários. Para o teste, as maquetes deverão ser
coladas na parede, dispostas na mesma seqüência que foi verificada
na etapa anterior, os usuários deverão interagir com as telas de modo
a simular a tarefa. A cada interação do usuário, o projetista explicará a
reação da interface e indicará a próxima tela, se for o caso.
Os protótipos de alta fidelidade utilizam materiais que são esperados no
produto final e por essa razão, estes se parecem muito com o produto já acabado
(PREECE, ROGERS e SHARP, 2005).
Protótipos de alta fidelidade oferecem componentes de interface, aparência e
comportamento bem parecidos com o futuro sistema, pois são desenvolvidos por
meio da utilização de ferramentas de software. O conteúdo de informação é
normalmente mais elaborado e possibilita a obtenção de medidas de usabilidade
(CYBIS, BETIOL e FAUST, 2007).
Cybis, Betiol e Faust (2007) alertam para não gastar muito tempo de
desenvolvimento na construção desse tipo de protótipo, pois prejudicaria o tempo
previsto para desenvolvimento. Para os autores, uma alternativa aos protótipos de
alta fidelidade é a construção de versões evolutivas do sistema, construídas na
própria plataforma definitiva do futuro sistema.
versões intermediárias aos usuários que, ao utilizá-las vão se adaptando ao sistema
e podem realizar uma validação mais fidedigna.
Ao construir protótipos, o projetista deve sempre ter em mente que há um
limite para o número de questões que este artefato pode responder. A intenção é a
produção rápida de algo que possa testar algum aspecto do futuro sistema
(PREECE, ROGERS e SHARP, 2005).
O Quadro 6 informa as vantagens e desvantagens da utilização dos
protótipos de alta fidelidade e dos protótipos de baixa fidelidade.
Quadro 6 - Vantagens e desvantagens dos protótipos de alta e baixa fidelidade
Tipo Vantagens Desvantagens
Baixa fidelidade
• Custo mais baixo de desenvolvimento
• Avalia múltiplos conceitos de design
• Instrumento de comunicação útil
• Útil para identificação de requisitos de mercado
• Demonstra que o conceito funciona
• Verificação limitada de erros
• Especificação pobre em detalhes para codificação
• “Uso” conduzido pelo facilitador
• Utilidade limitada após estabelecimento dos requisitos
• Utilidade limitada para testes de usabilidade
• Limitações de fluxo e navegação Alta
fidelidade
• Funcionalidade completa
• Totalmente interativo
• Uso conduzido pelo usuário
• Define claramente o esquema de navegação
• Uso para exploração e teste
• Mesma aparência do sistema final
• Serve como uma especificação viva
• Ferramenta de venda e marketing
• Desenvolvimento mais caro
• Sua criação demanda tempo
• Não serve para coleta de requisito
Fonte: Adaptado de Preece, Rogers e Sharp (2005, p. 266)