SlideShare a Scribd company logo
1 of 34
Download to read offline
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

More Related Content

What's hot

Aula 1 - Minicurso sobre Design Centrado no Usuário
Aula 1 - Minicurso sobre Design Centrado no UsuárioAula 1 - Minicurso sobre Design Centrado no Usuário
Aula 1 - Minicurso sobre Design Centrado no UsuárioErico Fileno
 
Introdução a Automação de Teste de Software
Introdução a Automação de Teste de SoftwareIntrodução a Automação de Teste de Software
Introdução a Automação de Teste de SoftwareCamilo Ribeiro
 
Modelos de Processo e Desenvolvimento de Software 1 - Prof.ª Cristiane Fidelix
Modelos de Processo e Desenvolvimento de Software 1 - Prof.ª Cristiane FidelixModelos de Processo e Desenvolvimento de Software 1 - Prof.ª Cristiane Fidelix
Modelos de Processo e Desenvolvimento de Software 1 - Prof.ª Cristiane FidelixCris Fidelix
 
Validação e Testes de software
Validação e Testes de softwareValidação e Testes de software
Validação e Testes de softwareRondinelli Mesquita
 
Modelo de Prototipação
Modelo de PrototipaçãoModelo de Prototipação
Modelo de PrototipaçãoJuliano Pires
 
Ciclo de vida de software
Ciclo de vida de softwareCiclo de vida de software
Ciclo de vida de softwarediha36
 
Aula 1 - Introdução a POO
Aula 1 -  Introdução a POOAula 1 -  Introdução a POO
Aula 1 - Introdução a POODaniel Brandão
 
Análise e Projeto de Sistemas com UML e Java
Análise e Projeto de Sistemas com UML e JavaAnálise e Projeto de Sistemas com UML e Java
Análise e Projeto de Sistemas com UML e Javaarmeniocardoso
 
Programação orientada a objetos
Programação orientada a objetosProgramação orientada a objetos
Programação orientada a objetosCleyton Ferrari
 
Perfil do usuário, Personas, Cenários, Storyboard em IHC
Perfil do usuário, Personas, Cenários, Storyboard em IHCPerfil do usuário, Personas, Cenários, Storyboard em IHC
Perfil do usuário, Personas, Cenários, Storyboard em IHCRos Galabo, PhD
 
Interfaces Gráficas em Java Parte 1
Interfaces Gráficas em Java Parte 1Interfaces Gráficas em Java Parte 1
Interfaces Gráficas em Java Parte 1Elaine Cecília Gatto
 
Qualidade de Software: Teste de software
Qualidade de Software: Teste de softwareQualidade de Software: Teste de software
Qualidade de Software: Teste de softwareAlex Camargo
 
Prototipação de software
Prototipação de softwarePrototipação de software
Prototipação de softwareleopp
 
Teste de software - aula 01 (motivação)
Teste de software - aula 01 (motivação)Teste de software - aula 01 (motivação)
Teste de software - aula 01 (motivação)Elmano Cavalcanti
 
Principais Técnicas de Elicitação de Requisitos
Principais Técnicas de Elicitação de RequisitosPrincipais Técnicas de Elicitação de Requisitos
Principais Técnicas de Elicitação de RequisitosNorton Guimarães
 

What's hot (20)

Aula 1 - Minicurso sobre Design Centrado no Usuário
Aula 1 - Minicurso sobre Design Centrado no UsuárioAula 1 - Minicurso sobre Design Centrado no Usuário
Aula 1 - Minicurso sobre Design Centrado no Usuário
 
Teste de Software - Introdução
Teste de Software - IntroduçãoTeste de Software - Introdução
Teste de Software - Introdução
 
Introdução a Automação de Teste de Software
Introdução a Automação de Teste de SoftwareIntrodução a Automação de Teste de Software
Introdução a Automação de Teste de Software
 
Modelos de Processo e Desenvolvimento de Software 1 - Prof.ª Cristiane Fidelix
Modelos de Processo e Desenvolvimento de Software 1 - Prof.ª Cristiane FidelixModelos de Processo e Desenvolvimento de Software 1 - Prof.ª Cristiane Fidelix
Modelos de Processo e Desenvolvimento de Software 1 - Prof.ª Cristiane Fidelix
 
Validação e Testes de software
Validação e Testes de softwareValidação e Testes de software
Validação e Testes de software
 
Modelo de Prototipação
Modelo de PrototipaçãoModelo de Prototipação
Modelo de Prototipação
 
Ciclo de vida de software
Ciclo de vida de softwareCiclo de vida de software
Ciclo de vida de software
 
UML - Diagrama de Pacotes
UML - Diagrama de PacotesUML - Diagrama de Pacotes
UML - Diagrama de Pacotes
 
Aula 1 - Introdução a POO
Aula 1 -  Introdução a POOAula 1 -  Introdução a POO
Aula 1 - Introdução a POO
 
Análise e Projeto de Sistemas com UML e Java
Análise e Projeto de Sistemas com UML e JavaAnálise e Projeto de Sistemas com UML e Java
Análise e Projeto de Sistemas com UML e Java
 
Programação orientada a objetos
Programação orientada a objetosProgramação orientada a objetos
Programação orientada a objetos
 
Perfil do usuário, Personas, Cenários, Storyboard em IHC
Perfil do usuário, Personas, Cenários, Storyboard em IHCPerfil do usuário, Personas, Cenários, Storyboard em IHC
Perfil do usuário, Personas, Cenários, Storyboard em IHC
 
Interfaces Gráficas em Java Parte 1
Interfaces Gráficas em Java Parte 1Interfaces Gráficas em Java Parte 1
Interfaces Gráficas em Java Parte 1
 
Qualidade de Software: Teste de software
Qualidade de Software: Teste de softwareQualidade de Software: Teste de software
Qualidade de Software: Teste de software
 
Design Centrado no Usuário
Design Centrado no UsuárioDesign Centrado no Usuário
Design Centrado no Usuário
 
Prototipação de software
Prototipação de softwarePrototipação de software
Prototipação de software
 
Java - Primeiros passos
Java - Primeiros passosJava - Primeiros passos
Java - Primeiros passos
 
Teste de software - aula 01 (motivação)
Teste de software - aula 01 (motivação)Teste de software - aula 01 (motivação)
Teste de software - aula 01 (motivação)
 
Teste de Software
Teste de SoftwareTeste de Software
Teste de Software
 
Principais Técnicas de Elicitação de Requisitos
Principais Técnicas de Elicitação de RequisitosPrincipais Técnicas de Elicitação de Requisitos
Principais Técnicas de Elicitação de Requisitos
 

Viewers also liked

Prototipagem
PrototipagemPrototipagem
Prototipagemjwainer
 
MERCEDES BENZ - SLA e SLS: Um fator de sucesso na Mercedes Benz
MERCEDES BENZ - SLA e SLS: Um fator de sucesso na Mercedes BenzMERCEDES BENZ - SLA e SLS: Um fator de sucesso na Mercedes Benz
MERCEDES BENZ - SLA e SLS: Um fator de sucesso na Mercedes BenzRobtec
 
Processos de fabricação: Estudo avançados sobre a prototipagem rápida
Processos de fabricação: Estudo avançados sobre a prototipagem rápidaProcessos de fabricação: Estudo avançados sobre a prototipagem rápida
Processos de fabricação: Estudo avançados sobre a prototipagem rápidaRafael Lial
 
CPBR7 - Pensamento Visual e Prototipagem
CPBR7 - Pensamento Visual e PrototipagemCPBR7 - Pensamento Visual e Prototipagem
CPBR7 - Pensamento Visual e PrototipagemNei Grando
 

Viewers also liked (6)

Prototipagem
PrototipagemPrototipagem
Prototipagem
 
MERCEDES BENZ - SLA e SLS: Um fator de sucesso na Mercedes Benz
MERCEDES BENZ - SLA e SLS: Um fator de sucesso na Mercedes BenzMERCEDES BENZ - SLA e SLS: Um fator de sucesso na Mercedes Benz
MERCEDES BENZ - SLA e SLS: Um fator de sucesso na Mercedes Benz
 
Processos de fabricação: Estudo avançados sobre a prototipagem rápida
Processos de fabricação: Estudo avançados sobre a prototipagem rápidaProcessos de fabricação: Estudo avançados sobre a prototipagem rápida
Processos de fabricação: Estudo avançados sobre a prototipagem rápida
 
Modefer
ModeferModefer
Modefer
 
Prototipação
PrototipaçãoPrototipação
Prototipação
 
CPBR7 - Pensamento Visual e Prototipagem
CPBR7 - Pensamento Visual e PrototipagemCPBR7 - Pensamento Visual e Prototipagem
CPBR7 - Pensamento Visual e Prototipagem
 

Similar to 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
 
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 to 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
 
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
 
Design de Interface - Diretrizes
Design de Interface - DiretrizesDesign de Interface - Diretrizes
Design de Interface - Diretrizes
 

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