Prototipagem

2.630 visualizações

Publicada em

Um pouco sobre prototipagem de papel e testes de usabilidade.

Publicada em: Tecnologia
0 comentários
1 gostou
Estatísticas
Notas
  • Seja o primeiro a comentar

Sem downloads
Visualizações
Visualizações totais
2.630
No SlideShare
0
A partir de incorporações
0
Número de incorporações
951
Ações
Compartilhamentos
0
Downloads
29
Comentários
0
Gostaram
1
Incorporações 0
Nenhuma incorporação

Nenhuma nota no slide

Prototipagem

  1. 1. Taynara Jaegger da Silva – PUC Gávea
  2. 2. “ Task Design” <ul><li>Permite descobrir peças na interface que funcionam bem e os problemas encontrados enquanto o usuário estiver navegando. </li></ul>
  3. 3. Características de boa tarefa <ul><li>Baseado nos objetivos do perfil do seu usuário. </li></ul><ul><li>Abrange questões importantes para o sucesso do seu produto e empresa. </li></ul><ul><li>Escopo adequado – não muito largo, não muito específico. </li></ul><ul><li>Conjunto finito e previsível das possíveis soluções. </li></ul><ul><li>Ponto final evidente, que o usuário reconheça. </li></ul><ul><li>Provoca ação e não apenas uma opinião. </li></ul>
  4. 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&quot; , fazer com que o usuário execute tarefas na qual não tenham soluções.
  5. 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. 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
  7. 7. Para se conseguir esses dois itens, precisamos seguir as seguintes etapas : <ul><li>Listar as metas e realizações que os usuários que podem alcançar usan do </li></ul><ul><li>a interface </li></ul><ul><li>Fazer uma lista de metas e realizações que são importantes para o perfil de </li></ul><ul><li>usuário escolhido. Quais são as pessoas que utilizam a interface? O que é </li></ul><ul><li>importante para eles? Como o produto torna sua vida melhor. Sempre pensar </li></ul><ul><li>sobre os objetivos dos usuários e não somente em funcionalidades. </li></ul><ul><li>Listar perguntas, riscos e outras questões sobre a interface </li></ul><ul><li>Fazer uma lista de todas as questões e preocupações que você tem em relação </li></ul><ul><li>ao produto, que pode ser feito numa reunião “kickoff” (reunião de “startup” do projeto). </li></ul><ul><li>Algumas questões podem vir a partir de “feedbacks” dos usuários ou a partir de </li></ul><ul><li>ideias ocasionadas por algum incomodo na interface. </li></ul>
  8. 8. <ul><li>Priorizar as perguntas </li></ul><ul><li>As questões específicas são as mais fáceis de responder, mas as questões gerais são as mais importantes para o sucesso do produto. </li></ul><ul><li>Uma forma de priorizar os problemas é uma votação para as 3 perguntas que se demonstrarem ser as mais importantes. </li></ul><ul><li>Escolha uma realização do usuário que cobre questões importantes para </li></ul><ul><li>poder transformar em uma tarefa – Criar uma tarefa </li></ul><ul><li>Existe um modelo padrão usado para criação de tarefas, que está no site “ www.paperprototyping.com ”. As tarefas precisam responder os seguintes itens: </li></ul><ul><li>Tarefa nome e número - Dê a cada tarefa um nome breve descritivo e um número. </li></ul><ul><li>Objetivo / saídas - O que os usuários tenham feito quando é feito com a tarefa? Existe uma saída concreta? Como eles saberão a tarefa está completa? Quais deverão ser os usuários fazem ter a certeza? </li></ul><ul><li>Entradas - lista de todas as informações ou os recursos tangíveis e intangíveis Hipóteses - Pressupostos são as condições e pré-requisitos que estão em vigor </li></ul><ul><li>no início da tarefa. Os pressupostos dependem daquilo que você quer aprender </li></ul><ul><li>a tarefa que um usuário precisa para completar esta tarefa. </li></ul>
  9. 9. <ul><li>Passos - Anote os passos que você espera que o usuário irá percorrer na realização da tarefa. </li></ul><ul><li>Tempo estimado para perito - estimar quanto tempo levaria um perito (alguém da equipe do núcleo) para completar a tarefa. </li></ul><ul><li>Instruções para os usuários. Não escreva as instruções para os usuários, quando </li></ul><ul><li>você está enchendo o resto do modelo. Embora o design tarefa funciona bem como </li></ul><ul><li>uma atividade de grupo, escrevendo as instruções pode ser feito por uma pessoa </li></ul><ul><li>depois de você ter elaborado o seu conjunto de tarefas. </li></ul><ul><li>Determinar a ordem das tarefas </li></ul><ul><li>Numerar as tarefas é necessário, para que o usuário tenha noção do tempo que </li></ul><ul><li>está levando para executar a tarefa. Estimativamente o usuário leva de 5 a 20 min </li></ul><ul><li>para executar uma tarefa completa. </li></ul><ul><li>Junte-se a tarefa expandido vezes e veja se você preencheu o seu tempo de prova previsto. É uma boa ideia para criar uma tarefa extra ou dois. Especialmente em um protótipo de papel, é comum para os usuários em testes posteriores para executar as tarefas mais para melhorar a interface de torná-la mais fácil de usar. Certifique-se que as tarefas não são muito longos. </li></ul><ul><li>Para alguns tipos de testes de usabilidade é importante usar as mesmas funções na mesma ordem para cada usuário. </li></ul>
  10. 10. <ul><li>Escrever as instruções que serão dadas aos usuários O ideal para as instruções das tarefas é descrever o objetivo de cada tarefa e não os passos. Evite descrever o que revela o método, como por exemplo “Criar um gráfico” no menu, ao invés disso instruir a criação de um gráfico qualquer, assim o usuário procurará ao entendimento dele como executar esta tarefa. Imagens são importantes e as vezes valem mais que a escrita. Prefira escrever as tarefas e não falar sobre as mesmas, assim o usuário pode consultar quando for preciso. Seria ideal ter uma tarefa por página, assim o usuário tem a flexibilidade de ordenação destas. </li></ul><ul><li>Revise suas tarefas </li></ul>
  11. 11. Elaboração do Protótipo <ul><li>Criação de protótipos para ser usado nos testes de usabilidade. A criação de protótipos e atividades passo a passo acontecem iterativamente. </li></ul>
  12. 12. Necessário para uma tarefa <ul><li>Listar em um quadro todas as telas que o protótipo precisará apoiando as tarefas planejadas </li></ul><ul><li>Manter a lista em alto nível, não precisa especificar todas os itens do menu, só os que a tarefa utiliza </li></ul><ul><li>Geralmente é mais rápido criar esta lista sem olhar para a interface existente. </li></ul>
  13. 13. <ul><li>Por exemplo uma tarefa, de abrir uma conta de aposentadoria em um site financeiro pode exigir as seguintes telas: </li></ul><ul><li>Janela de Navegador com controles </li></ul><ul><li>Home Page </li></ul><ul><li>Usuários de login existentes </li></ul><ul><li>Telas de novas contas </li></ul><ul><li>Explicações sobre “Regular / Roth IRA” </li></ul><ul><li>Resumo da conta </li></ul><ul><li>Política de Privacidade </li></ul><ul><li>Termos e Condições </li></ul><ul><li>Fundos </li></ul>Necessário para uma tarefa
  14. 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 &quot;se encaixam&quot; em uma maneira consistente em toda a tarefa. Não esquecer dos dados
  15. 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. 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. 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. 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. 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. 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. 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 &quot;fazer tudo se encaixar&quot; deve ser precedido por uma boa compreensão do que &quot;ele&quot; consiste. Dicas para protótipos desenhados a mão
  22. 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: - &quot;As linhas onduladas significam que você entenderá tudo aqui, mas não é o que você está procurando. “ Dificultar ou Facilitar?
  23. 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. 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. 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. 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. 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. 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
  29. 29. <ul><li>Identificação de peças do protótipo, que ainda precisam ser criadas. </li></ul><ul><li>Prepare-se para diferentes caminhos que o usuário possa razoavelmente ter . </li></ul><ul><li>Veja como a interface destina-se ao trabalho, que é especialmente útil para aqueles que criação de documentação, treinamento ou que são novos para a equipe de desenvolvimento. </li></ul><ul><li>Dar a prática do computador em manipular todos aqueles pedaços de papel. </li></ul><ul><li>Identificar as questões relativas à viabilidade técnica. </li></ul>Passo a Passo Internamente
  30. 30. <ul><li>Para manter um passo a passo, é preciso uma tabela grande o suficiente para espalhar-se o protótipo. As pessoas atribuem as seguintes funções: </li></ul><ul><li>Monitor - Pessoa que organiza e manipula todos os pedaços de papel. </li></ul><ul><li>Usuário avançado - Um membro da equipe de produtos desempenha este papel, realizando as tarefas como um especialista. </li></ul><ul><li>Escritor - Essa pessoa escreve todas as peças em falta, problemas e questões que surgem. </li></ul><ul><li>Facilitador - Pessoa designada para tirar algumas dúvidas do usuário que não comprometam seus testes. </li></ul>Como fazer o passo a passo?
  31. 31. <ul><li>Você não está pronto para o primeiro-tempo - Se você não está pronto para o primeiro teste, não o faça. Pode ser bom para você, mas uma perda de tempo para quem for te ajudar. </li></ul><ul><li>Co-trabalhadores não são usuários reais - Co-trabalhadores geralmente não são representativos de usuários reais, não é o mesmo que lidar com os usuários finais. </li></ul><ul><li>Há considerações éticas e legais - Quando o teste de usabilidade é feito com os colaboradores internos,você realmente tem mais responsabilidades éticas e legais do que se fossem estranhos. </li></ul><ul><li>Você não quer mais opiniões - O propósito do teste de usabilidade é a recolha de dados de usuários reais, não as opiniões de outras pessoas da equipe. </li></ul>Atenção para o que não é um teste de usabilidade
  32. 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. 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. 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

×