SlideShare una empresa de Scribd logo
1 de 34
Taynara Jaegger da Silva – PUC Gávea
“ Task Design” ,[object Object]
Características de boa tarefa ,[object Object],[object Object],[object Object],[object Object],[object Object],[object Object]
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.
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.
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
Para se conseguir esses dois itens, precisamos seguir as seguintes etapas : ,[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object]
[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object]
[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object]
[object Object],[object Object]
Elaboração do Protótipo ,[object Object]
Necessário para uma tarefa ,[object Object],[object Object],[object Object]
[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],Necessário para uma tarefa
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
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
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
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
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
Uma vantagem do protótipo de papel é algo que você pode prototipar sem levar em conta se ela pode realmente ser construída.
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?
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
“ 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?
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?
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”
Muitos elementos podem se repetir na interface várias vezes, a separação destes elementos facilitará o reaproveitamento destes protótipos. Ex: Separar Elementos
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
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
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
[object Object],[object Object],[object Object],[object Object],[object Object],Passo a Passo Internamente
[object Object],[object Object],[object Object],[object Object],[object Object],Como fazer o passo a passo?
[object Object],[object Object],[object Object],[object Object],Atenção para o que não é um teste de usabilidade
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
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
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

Más contenido relacionado

La actualidad más candente

Aps lista de exercícios
Aps lista de exercíciosAps lista de exercícios
Aps lista de exercíciosGuilherme
 
Aulas 1 e 2 - Hardware
Aulas 1 e 2 - HardwareAulas 1 e 2 - Hardware
Aulas 1 e 2 - HardwareJocelma Rios
 
Metodologias de Desenvolvimento de Software
Metodologias de Desenvolvimento de SoftwareMetodologias de Desenvolvimento de Software
Metodologias de Desenvolvimento de SoftwareÁlvaro Farias Pinheiro
 
Introdução à Análise de Sistemas
Introdução à Análise de SistemasIntrodução à Análise de Sistemas
Introdução à Análise de SistemasNécio de Lima Veras
 
Engenharia de Software - Conceitos e Modelos de Desenvolvimento
Engenharia de Software - Conceitos e Modelos de Desenvolvimento Engenharia de Software - Conceitos e Modelos de Desenvolvimento
Engenharia de Software - Conceitos e Modelos de Desenvolvimento Sérgio Souza Costa
 
Aula - Introdução a Engenharia de Software
Aula - Introdução a Engenharia de SoftwareAula - Introdução a Engenharia de Software
Aula - Introdução a Engenharia de SoftwareCloves da Rocha
 
Aula 01 fundamentos da informática
Aula 01   fundamentos da informáticaAula 01   fundamentos da informática
Aula 01 fundamentos da informáticaGilberto Campos
 
Ihc2016.2 aula 9 engenharia cognitiva e teoria da ação
Ihc2016.2 aula 9    engenharia cognitiva e teoria da açãoIhc2016.2 aula 9    engenharia cognitiva e teoria da ação
Ihc2016.2 aula 9 engenharia cognitiva e teoria da açãoTicianne Darin
 
Curso de Informatica Básica - Noções básicas de um computador
Curso de Informatica Básica - Noções básicas de um computadorCurso de Informatica Básica - Noções básicas de um computador
Curso de Informatica Básica - Noções básicas de um computadorPerondi15
 
Usabilidade aula-01 Introdução
Usabilidade aula-01 IntroduçãoUsabilidade aula-01 Introdução
Usabilidade aula-01 IntroduçãoAlan Vasconcelos
 
Modelo de Prototipação
Modelo de PrototipaçãoModelo de Prototipação
Modelo de PrototipaçãoJuliano Pires
 
Aula 1 word
Aula 1 wordAula 1 word
Aula 1 wordWELDES
 

La actualidad más candente (20)

Teste de software
Teste de softwareTeste de software
Teste de software
 
1ª aula sistema operacional
1ª aula  sistema operacional1ª aula  sistema operacional
1ª aula sistema operacional
 
Aps lista de exercícios
Aps lista de exercíciosAps lista de exercícios
Aps lista de exercícios
 
Aulas 1 e 2 - Hardware
Aulas 1 e 2 - HardwareAulas 1 e 2 - Hardware
Aulas 1 e 2 - Hardware
 
Metodologias de Desenvolvimento de Software
Metodologias de Desenvolvimento de SoftwareMetodologias de Desenvolvimento de Software
Metodologias de Desenvolvimento de Software
 
Introdução à Análise de Sistemas
Introdução à Análise de SistemasIntrodução à Análise de Sistemas
Introdução à Análise de Sistemas
 
Engenharia de Software - Conceitos e Modelos de Desenvolvimento
Engenharia de Software - Conceitos e Modelos de Desenvolvimento Engenharia de Software - Conceitos e Modelos de Desenvolvimento
Engenharia de Software - Conceitos e Modelos de Desenvolvimento
 
Aula - Introdução a Engenharia de Software
Aula - Introdução a Engenharia de SoftwareAula - Introdução a Engenharia de Software
Aula - Introdução a Engenharia de Software
 
Aula 01 fundamentos da informática
Aula 01   fundamentos da informáticaAula 01   fundamentos da informática
Aula 01 fundamentos da informática
 
Informática Básica - Aula 04 - Software
Informática Básica - Aula 04 - SoftwareInformática Básica - Aula 04 - Software
Informática Básica - Aula 04 - Software
 
Workshop Design Thinking
Workshop Design ThinkingWorkshop Design Thinking
Workshop Design Thinking
 
Ihc Aula7
Ihc Aula7Ihc Aula7
Ihc Aula7
 
Usabilidade IHC
Usabilidade IHCUsabilidade IHC
Usabilidade IHC
 
Pacote office
Pacote officePacote office
Pacote office
 
Ihc2016.2 aula 9 engenharia cognitiva e teoria da ação
Ihc2016.2 aula 9    engenharia cognitiva e teoria da açãoIhc2016.2 aula 9    engenharia cognitiva e teoria da ação
Ihc2016.2 aula 9 engenharia cognitiva e teoria da ação
 
Curso de Informatica Básica - Noções básicas de um computador
Curso de Informatica Básica - Noções básicas de um computadorCurso de Informatica Básica - Noções básicas de um computador
Curso de Informatica Básica - Noções básicas de um computador
 
Usabilidade aula-01 Introdução
Usabilidade aula-01 IntroduçãoUsabilidade aula-01 Introdução
Usabilidade aula-01 Introdução
 
Ciclo desenvolvimento de sistemas
Ciclo desenvolvimento de sistemasCiclo desenvolvimento de sistemas
Ciclo desenvolvimento de sistemas
 
Modelo de Prototipação
Modelo de PrototipaçãoModelo de Prototipação
Modelo de Prototipação
 
Aula 1 word
Aula 1 wordAula 1 word
Aula 1 word
 

Similar a Prototipagem

Simplicidade nos Testes de Usabilidade
Simplicidade nos Testes de UsabilidadeSimplicidade nos Testes de Usabilidade
Simplicidade nos Testes de UsabilidadeErika
 
Design thinking - Prototipando melhores experiências web
Design thinking - Prototipando melhores experiências webDesign thinking - Prototipando melhores experiências web
Design thinking - Prototipando melhores experiências webLuanna Eroles
 
Prototipagem em Papel - Oficina
Prototipagem em Papel - OficinaPrototipagem em Papel - Oficina
Prototipagem em Papel - OficinaLtia Unesp
 
designer grafico Aula 05 - Heurísticas de Nielsen.pdf
designer grafico Aula 05 - Heurísticas de Nielsen.pdfdesigner grafico Aula 05 - Heurísticas de Nielsen.pdf
designer grafico Aula 05 - Heurísticas de Nielsen.pdfJulioCesar371362
 
Prototipagem de Software para Devs
Prototipagem de Software para DevsPrototipagem de Software para Devs
Prototipagem de Software para DevsMarcos Marcolin
 
Estratégia de Produto Eficaz - Marcell Almeida - Live PM3 + Impulso
Estratégia de Produto Eficaz - Marcell Almeida - Live PM3 + ImpulsoEstratégia de Produto Eficaz - Marcell Almeida - Live PM3 + Impulso
Estratégia de Produto Eficaz - Marcell Almeida - Live PM3 + ImpulsoMarcell Almeida
 
Prototipação de software
Prototipação de softwarePrototipação de software
Prototipação de softwareMarcio Costa
 
Palestra de SCRUM em Juazeiro
Palestra de SCRUM em JuazeiroPalestra de SCRUM em Juazeiro
Palestra de SCRUM em JuazeiroPaulo Furtado
 
300 ideias para programar
300 ideias para programar300 ideias para programar
300 ideias para programarAdrielle Dri
 
Produtos que viciam - Mercado Livre Experience
Produtos que viciam - Mercado Livre ExperienceProdutos que viciam - Mercado Livre Experience
Produtos que viciam - Mercado Livre ExperienceLe Wagon Brasil
 
1º Curitiba Scrum Day
1º Curitiba Scrum Day1º Curitiba Scrum Day
1º Curitiba Scrum Dayjrompkovski
 
Ferramentas de Gerenciamento de Projetos
Ferramentas de Gerenciamento de ProjetosFerramentas de Gerenciamento de Projetos
Ferramentas de Gerenciamento de ProjetosVMayfair
 
1- Apresentacao Metodologia RCP
1- Apresentacao Metodologia RCP1- Apresentacao Metodologia RCP
1- Apresentacao Metodologia RCPFrank Coelho
 
1 apresentacao metodologia rcp
1  apresentacao metodologia rcp1  apresentacao metodologia rcp
1 apresentacao metodologia rcpFrank Coelho
 

Similar a Prototipagem (20)

Usabilidade1
Usabilidade1Usabilidade1
Usabilidade1
 
Simplicidade nos Testes de Usabilidade
Simplicidade nos Testes de UsabilidadeSimplicidade nos Testes de Usabilidade
Simplicidade nos Testes de Usabilidade
 
Design thinking - Prototipando melhores experiências web
Design thinking - Prototipando melhores experiências webDesign thinking - Prototipando melhores experiências web
Design thinking - Prototipando melhores experiências web
 
Prototipagem em Papel - Oficina
Prototipagem em Papel - OficinaPrototipagem em Papel - Oficina
Prototipagem em Papel - Oficina
 
Conceitos de Usabilidade
Conceitos de UsabilidadeConceitos de Usabilidade
Conceitos de Usabilidade
 
Tdd x testes unidades
Tdd x testes unidadesTdd x testes unidades
Tdd x testes unidades
 
designer grafico Aula 05 - Heurísticas de Nielsen.pdf
designer grafico Aula 05 - Heurísticas de Nielsen.pdfdesigner grafico Aula 05 - Heurísticas de Nielsen.pdf
designer grafico Aula 05 - Heurísticas de Nielsen.pdf
 
DevQA: UI Testing , como fazer?
DevQA: UI Testing , como fazer?DevQA: UI Testing , como fazer?
DevQA: UI Testing , como fazer?
 
Prototipagem de Software para Devs
Prototipagem de Software para DevsPrototipagem de Software para Devs
Prototipagem de Software para Devs
 
Estratégia de Produto Eficaz - Marcell Almeida - Live PM3 + Impulso
Estratégia de Produto Eficaz - Marcell Almeida - Live PM3 + ImpulsoEstratégia de Produto Eficaz - Marcell Almeida - Live PM3 + Impulso
Estratégia de Produto Eficaz - Marcell Almeida - Live PM3 + Impulso
 
Prototipação de software
Prototipação de softwarePrototipação de software
Prototipação de software
 
Palestra de SCRUM em Juazeiro
Palestra de SCRUM em JuazeiroPalestra de SCRUM em Juazeiro
Palestra de SCRUM em Juazeiro
 
eXtreme Programming
eXtreme ProgrammingeXtreme Programming
eXtreme Programming
 
300 ideias para programar
300 ideias para programar300 ideias para programar
300 ideias para programar
 
Produtos que viciam - Mercado Livre Experience
Produtos que viciam - Mercado Livre ExperienceProdutos que viciam - Mercado Livre Experience
Produtos que viciam - Mercado Livre Experience
 
1º Curitiba Scrum Day
1º Curitiba Scrum Day1º Curitiba Scrum Day
1º Curitiba Scrum Day
 
Teste de usabilidade
Teste de usabilidadeTeste de usabilidade
Teste de usabilidade
 
Ferramentas de Gerenciamento de Projetos
Ferramentas de Gerenciamento de ProjetosFerramentas de Gerenciamento de Projetos
Ferramentas de Gerenciamento de Projetos
 
1- Apresentacao Metodologia RCP
1- Apresentacao Metodologia RCP1- Apresentacao Metodologia RCP
1- Apresentacao Metodologia RCP
 
1 apresentacao metodologia rcp
1  apresentacao metodologia rcp1  apresentacao metodologia rcp
1 apresentacao metodologia rcp
 

Prototipagem

  • 1. Taynara Jaegger da Silva – PUC Gávea
  • 2.
  • 3.
  • 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
  • 7.
  • 8.
  • 9.
  • 10.
  • 11.
  • 12.
  • 13.
  • 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
  • 29.
  • 30.
  • 31.
  • 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