O documento discute a criação de tarefas para testes de usabilidade, destacando a importância de: 1) Definir tarefas baseadas nos objetivos dos usuários e questões importantes sobre o produto; 2) Criar um conjunto finito e previsível de soluções para as tarefas; 3) Garantir que as tarefas tenham um ponto final claro para o usuário.

1. Taynara Jaegger da Silva – PUC Gávea

4. Escopo apropriado As tarefas devem ter possibilidades grandes para que o usuário alcance metas realísticas e responder as questões importantes. O ideal não é testar uma tela por vez, e sim uma vasta opções das telas para que analise todas as funcionalidades. O teste pode durar de 5 a 30 minutos. Conjunto Finito e previsível de soluções Ter telas suficientes prototipadas para todas as soluções previsíveis. Recomendável ter pelo menos uma solução de uma tarefa. Evitar o chamado “Red Herring" , fazer com que o usuário execute tarefas na qual não tenham soluções.

5. Ponto final claro Evitar tarefas do tipo “Explore o site” ou “Descubra algo interessante sobre os narcisos”. A interface precisa dar feedbacks suficientes de tarefas concluídas para que o usuário não se perca. Deixar os usuários decidirem quando uma tarefa é terminada. Provocar a ação não só a opinião Uma boa tarefa deve fazer com que o usuário interaja com a interface e não apenas olhar para ele e dizer o que eles pensam. Assistir os usuários usando a interface, sem interrompê-los, na maioria das vezes, esperar para fazer perguntas como “O que você acha deste serviço?” é preferível deixar para o final dos testes.

6. Processo de Criação de Tarefas Uma boa tarefa, o usuário abrange áreas da interface que temos dúvida sobre sua usabilidade. As tarefas precisam ser a interseção de duas coisas: Perguntas sobre o produto Objetivos do usuário Tarefas de Usabilidade

14. Muitas vezes é importante para que os usuários vejam como os dados aparecerão em outras partes do sistema. Se um usuário está criando um anúncio de classificados online, preenchendo um formulário, ele ou ela provavelmente irá querer visualizar o anúncio no mesmo formato que o sistema irá usar. Os dados usados devem ser realistas os suficiente para que os usuários possam interagir com a interface de forma significativa. Certifique-se que os dados "se encaixam" em uma maneira consistente em toda a tarefa. Não esquecer dos dados

15. Caso esteja trabalhando com protótipo de telas simples já existentes, somente precisa tirar ‘print’ das telas e imprimir. Caso a interface não exista ainda ou precisa de melhores,o ideal seria dividir a preparação das telas para uma possível colaboração da equipe. O protótipo de papel é criado pela equipe do núcleo, que por definição, inclui os responsáveis pela interface, portanto, o protótipo permanece sempre nas mãos adequadas. Dividir e Conquistar

16. Protótipo em papel não se limita a uma tela de computador. É importante que cada membro da equipe produza seu próprio protótipo, de forma a poder comparar os trabalhos de acordo com diversos pontos de vista . Curiosamente, o projeto paralelo parece facilitar a identificação e desenvolvimento de ideias bem sucedidas, mesmo quando estão contidos em projetos não tão bons (McGrew, 2001). Design Paralelo

17. Até iniciar os testes de usabilidade, você não sabe o que você não conhece. Se você tiver várias versões de uma interface, é provável que todos eles compartilham algumas importantes leis com base em todas as coisas que não sabe ainda. Assim, apesar de projeto paralelo pode ser uma técnica útil na vinda acima com ideias, eu recomendo que a equipe principal em estabelecer um projeto antes do primeiro teste de usabilidade. Quando duas ou mais ideias parecem tão boas começo, com o que é mais fácil de implementar. Se funcionar, você está feito. Se não, você pode tentar algo mais elaborado. Evitar Competição

18. O custo dos erros são baixos - Se você tentar algo novo e fracassar, você não terá desperdiçado muito tempo. Não redesenhar algo que você não tenha testado- Se você não tem um consenso sobre o que há de errado com a versão atual, primeiro precisa fazer testes para descobrir os problemas que precisa resolver para depois fazer o seu redesenho. Limite o tempo, não a criatividade – Estabeleça um limite superior para o tempo que vai gastar fazendo o protótipo, quando chegar a este limite, teste o que tem. O que já existe X Novo Design

19. Uma vantagem do protótipo de papel é algo que você pode prototipar sem levar em conta se ela pode realmente ser construída.

20. Quanto você espera mudar isso? Você pode também usar uma tela para algo que você sabe que não pode mudar, como uma tela do sistema operacional. No entanto, para as telas que você espera evoluir, você pode desenhá-las para que as mudanças fiquem do jeito que vão se utilizar as telas. Qual o método é mais rápido? Embora parecer ser mais rápido para criar um protótipo de telas, na prática isso nem sempre é o caso. Pergunte a si mesmo se você pode esboçar algumas telas mais rápido, especialmente as mais simples. Onde estão os dados estão vindo? Se a sua interface mostra informações de um banco de dados “prints” de telas pode ser a maneira mais fácil para mostrar estes dados. Será que o impresso pode ser lido? Analisar se os “prints” são fáceis de serem lidos, se não é melhor redesenhar a tela. Rascunhar ou “Print” de Telas?

21. O capricho não conta muito. P rotótipos de papel deve ser apenas puro o suficiente seja legível, mas não puro. É bom para desenhar à mão livre em vez de usar uma régua. Monocromático é bom. Não é preciso muito das cores para especificar as ações . Tamanho (geralmente) não importa. Se os usuários fará a gravação de dados sobre o protótipo, você precisa fazer a tela de editar campos suficientemente grande para acomodar seus escritos. Desenho do protótipo um pouco maior do que a vida também ajuda observadores assistir a ação. Fora isso, o tamanho geralmente não importa muito. Como regra, o conceito de "fazer tudo se encaixar" deve ser precedido por uma boa compreensão do que "ele" consiste. Dicas para protótipos desenhados a mão

22. “ Greeking” significa usar palavras sem significado para representar texto. “Greeking” não é necessária em muitos protótipos, mas vale a pena conhecer. A seguir, 3 razões na quais se pode usar “greeking”: 1. Não concluir o projeto da interface. Porque protótipos de papel permitem testar antes, pode haver partes da a interface que não foram criadas ainda. Por exemplo, seu aplicativo de software terá exibição menus e de ajuda, mas ainda não precisando de atenção ao seu conteúdo. Assim você pode criar “greeking” ‘Ver e menus’ e ‘Ajuda’, onde todas as escolhas são linhas onduladas, como a imagem a baixo demonstra. Se o usuário tenta ir para algo que você “greeking”, você dizer-lhes: - "As linhas onduladas significam que você entenderá tudo aqui, mas não é o que você está procurando. “ Dificultar ou Facilitar?

23. 2. Para simplificar as partes da interface que você não tem controle . Um típico exemplo é a caixa de diálogo ‘Abrir Arquivo’. Se uma tarefa requer que o usuário abra um arquivo que você pode criar uma versão simplificada que contém apenas o nome de que necessitam para a tarefa. 3. Para evitar que o usuário se atente mais ao conteúdo. Dificultar ou Facilitar?

24. 1. Ampliar de modo que os observadores possam ver. 2. Remover padrões de “radiobuttons” e “checkboxs” , em seguida, colocá-los novamente com versões em fita removível. 3. Link de Limpar histórico do “Browser” antes de fazer as capturas das telas, para que não mostre os caminhos a serem percorridos para seus usuários. 4. Capture uma página inteira de uma vez. Usando “Print Screen”

25. Muitos elementos podem se repetir na interface várias vezes, a separação destes elementos facilitará o reaproveitamento destes protótipos. Ex: Separar Elementos

26. Há frequentemente várias maneiras corretas para completar uma tarefa. É necessário preparar os protótipos suficientes para acomodar as coisas que os usuários podem fazer razoavelmente. Provavelmente alguns usuários sairão do caminho desejado. É sempre bom prototipar telas com mensagens de erros. Evite colocar muito esforço no protótipo inicial, para fazer os testes e analisar o que pode ser melhorado em seu protótipo. Custo da Prototipagem - antecipando erros

27. Organizando - Geralmente não é possível determinar a ordem exata em telas que serão utilizadas. Mesmo se houver uma sequência de passos esperado, os usuários pode voltar, saltar à frente, fazer coisas que causam mensagens de erro, e assim por diante. Mas se você pode ter certeza que os usuários vão ver uma série de telas em uma ordem fixa (por exemplo, um tutorial), pode ser útil por um numero no verso. Tabela ou Fichário – Fichários são usados para armazenar as telas em uma página correspondente, mas também pode limitar a visão de um todo . Organização por tarefa versus função – Funciona quando a interface não possuem multitarefas. Envelopes – Usar envelopes para guardar itens de menu. Peças Pequenas – O ideal é juntar estas peças em uma folha grande para melhor visualização. Organizar o Protótipo

28. Muitos especialistas quando estão desenhando os protótipos, antes mesmo dos testes, olham a interface de outra maneira. Os especialistas fazem um redesenho da interface com as discussões que surgiram durante a montagem dos protótipos. E logo após fazem os testes. Revisão de design

32. Deve-se resistir à tentação de redesenhar baseada apenas na opinião de alguém ou o desejo de tentar uma abordagem diferente, sem entender os pontos fortes e fracos do atual. O problema com a realização de testes antes do “re-design” é que você ainda não sabe o que você não conhece. Depois de assistir os usuários trabalharem com o protótipo, você vai entender melhor os problemas que estamos tentando resolver. Recolher dados de usuários reais, não a opinião de outro interno. Quando (e quando não) fazer Re-design

33. O ensaio do teste de usabilidade é basicamente uma outra explicação interna, mas com alguns elementos extras adicionados. Um ensaio não é específico para prototipagem de papel - é um passo importante na preparação para um teste de usabilidade. Idealmente, o ensaio deve ter lugar um dia antes do primeiro teste de usabilidade. Geralmente envolve um grupo maior do que aqueles que trabalharam no protótipo. Ensaio de teste de usabilidade

34. Testes pilotos não são levados em consideração para a melhoria da interface. Estes testes são usados para a melhoria do protótipo para só então aplicar os testes reais. Também é analisado o tempo que o usuário vai levar para fazer os testes. Teste Piloto