SlideShare uma empresa Scribd logo
Taynara Jaegger da Silva – PUC Gávea
“ Task Design” Permite descobrir peças na interface que funcionam bem e os problemas encontrados enquanto o usuário estiver navegando.
Características de boa tarefa Baseado nos objetivos do perfil do seu usuário. Abrange questões importantes para o sucesso do seu produto e empresa. Escopo adequado – não muito largo, não muito específico. Conjunto finito e previsível das possíveis soluções. Ponto final evidente, que o usuário reconheça. Provoca ação e não apenas uma opinião.
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 : Listar as metas e  realizações que os usuários que podem alcançar usan do a interface Fazer uma lista de metas e realizações que são importantes para o perfil de  usuário escolhido. Quais são as pessoas que utilizam a interface? O que é importante para eles? Como o produto torna sua vida melhor. Sempre pensar sobre os objetivos dos usuários e não somente em funcionalidades. Listar perguntas, riscos e outras questões sobre a interface Fazer uma lista de todas as questões e preocupações que você tem em relação  ao produto, que pode ser feito numa reunião “kickoff” (reunião de “startup” do projeto). Algumas questões podem vir a partir de “feedbacks” dos usuários ou a partir de  ideias ocasionadas por algum incomodo na interface.
Priorizar as perguntas 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. Uma forma de priorizar os problemas é uma votação para as 3 perguntas   que se demonstrarem ser as mais importantes. Escolha uma realização do usuário que cobre questões importantes para  poder transformar em uma tarefa – Criar uma tarefa 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: Tarefa nome e número -  Dê a cada tarefa um nome breve descritivo e um    número.  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?  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  no início da tarefa. Os pressupostos dependem daquilo que você quer aprender  a tarefa que um usuário precisa para completar esta tarefa.
Passos -  Anote os passos que você espera que o usuário irá percorrer na   realização da tarefa. Tempo estimado para perito -  estimar quanto tempo levaria um perito   (alguém da equipe do núcleo) para completar a tarefa. Instruções para os usuários.  Não escreva as instruções para os usuários, quando  você está enchendo o resto do modelo. Embora o design tarefa funciona bem como  uma atividade de grupo, escrevendo as instruções pode ser feito por uma pessoa  depois de você ter elaborado o seu conjunto de tarefas. Determinar a ordem das tarefas Numerar as tarefas é necessário, para que o usuário tenha noção do tempo que  está levando para executar a tarefa. Estimativamente o usuário leva de 5 a 20 min para executar uma tarefa completa. 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. Para alguns tipos de testes de usabilidade é importante usar as mesmas funções   na mesma ordem para cada usuário.
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. Revise suas tarefas
Elaboração do Protótipo 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.
Necessário para uma tarefa Listar em um quadro todas as telas que o protótipo precisará apoiando as tarefas planejadas Manter a lista em alto nível, não precisa especificar todas os itens do menu, só os que a tarefa utiliza Geralmente é mais rápido criar esta lista sem olhar para a interface existente.
Por exemplo uma tarefa, de abrir uma conta de aposentadoria em um site financeiro pode exigir as seguintes telas: Janela de Navegador com controles Home Page Usuários de login existentes Telas de novas contas Explicações sobre “Regular / Roth IRA” Resumo da conta Política de Privacidade Termos e Condições Fundos 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
Identificação de peças do protótipo, que ainda precisam ser criadas. Prepare-se para diferentes caminhos que o usuário possa razoavelmente ter . 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. Dar a prática do computador em manipular todos aqueles pedaços de papel. Identificar as questões relativas à viabilidade técnica.  Passo a Passo Internamente
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: Monitor -  Pessoa que organiza e manipula todos os pedaços de papel. Usuário avançado -  Um membro da equipe de produtos desempenha este papel, realizando as tarefas como um especialista. Escritor -  Essa pessoa escreve todas as peças em falta, problemas e questões que surgem. Facilitador  - Pessoa designada para tirar algumas dúvidas do usuário que não comprometam seus testes. Como fazer o passo a passo?
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.  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.  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. 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.  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

Mais conteúdo relacionado

PDF
Projeto e Desenvolvimento de Software
PPT
Prototipagem
PPTX
Aula 3 - Sistemas operacionais - Linux
PPTX
Sistema Operacional Windows (versão 11)
PDF
Introdução ao desenvolvimento Web
PPT
Prototipagem
PDF
Minicurso de App Inventor
PPTX
Aula 01 - Ms PowerPoint
Projeto e Desenvolvimento de Software
Prototipagem
Aula 3 - Sistemas operacionais - Linux
Sistema Operacional Windows (versão 11)
Introdução ao desenvolvimento Web
Prototipagem
Minicurso de App Inventor
Aula 01 - Ms PowerPoint

Mais procurados (20)

PDF
Dispositivos móveis
PPTX
Design Centrado no Usuário
PDF
Gerenciamento de projetos aula 1 (introdução)
PDF
Aula Lógica de Programação - cap1
PDF
IHC - Slide 2 - Usabilidade e Princípios de Design
PDF
Aula 6 - Design e Processo de Design de Interfaces de Usuário
PPTX
Informática Básica - Aula 04 - Software
PDF
Introdução a Linguagem Java
PPT
Aula 1 - Minicurso sobre Design Centrado no Usuário
PPTX
Aula 01 - História da Computação
PDF
Arquitetura da informação
PPT
Sistema Operativos
PDF
Aula - Introdução a Engenharia de Software
PPTX
Editores de texto
PPT
AOO - Diagrama de Caso de Uso
PPT
Apresentação Scratch
PDF
Exercc3adcio word
PPTX
Metodologias de Desenvolvimento de Software
PDF
Aula 4 - Avaliação de Interface - Parte 1
Dispositivos móveis
Design Centrado no Usuário
Gerenciamento de projetos aula 1 (introdução)
Aula Lógica de Programação - cap1
IHC - Slide 2 - Usabilidade e Princípios de Design
Aula 6 - Design e Processo de Design de Interfaces de Usuário
Informática Básica - Aula 04 - Software
Introdução a Linguagem Java
Aula 1 - Minicurso sobre Design Centrado no Usuário
Aula 01 - História da Computação
Arquitetura da informação
Sistema Operativos
Aula - Introdução a Engenharia de Software
Editores de texto
AOO - Diagrama de Caso de Uso
Apresentação Scratch
Exercc3adcio word
Metodologias de Desenvolvimento de Software
Aula 4 - Avaliação de Interface - Parte 1
Anúncio

Destaque (6)

PPTX
MERCEDES BENZ - SLA e SLS: Um fator de sucesso na Mercedes Benz
PDF
Processos de fabricação: Estudo avançados sobre a prototipagem rápida
PDF
PPTX
Modelo de Prototipação
PPT
Prototipação
PDF
CPBR7 - Pensamento Visual e Prototipagem
MERCEDES BENZ - SLA e SLS: Um fator de sucesso na Mercedes Benz
Processos de fabricação: Estudo avançados sobre a prototipagem rápida
Modelo de Prototipação
Prototipação
CPBR7 - Pensamento Visual e Prototipagem
Anúncio

Semelhante a Prototipagem (20)

PPTX
PPT
Simplicidade nos Testes de Usabilidade
PDF
Design thinking - Prototipando melhores experiências web
PDF
Prototipagem em Papel - Oficina
PPS
Conceitos de Usabilidade
PPTX
Tdd x testes unidades
PDF
designer grafico Aula 05 - Heurísticas de Nielsen.pdf
PDF
DevQA: UI Testing , como fazer?
PDF
Prototipagem de Software para Devs
PDF
Estratégia de Produto Eficaz - Marcell Almeida - Live PM3 + Impulso
PPTX
Prototipação de software
PPTX
Palestra de SCRUM em Juazeiro
PPT
eXtreme Programming
PDF
300 ideias para programar
PPTX
Produtos que viciam - Mercado Livre Experience
PDF
Os princípios do design de interfaces para uma IHC eficaz!
PDF
1º Curitiba Scrum Day
PDF
Teste de usabilidade
PPTX
Ferramentas de Gerenciamento de Projetos
PPTX
1- Apresentacao Metodologia RCP
Simplicidade nos Testes de Usabilidade
Design thinking - Prototipando melhores experiências web
Prototipagem em Papel - Oficina
Conceitos de Usabilidade
Tdd x testes unidades
designer grafico Aula 05 - Heurísticas de Nielsen.pdf
DevQA: UI Testing , como fazer?
Prototipagem de Software para Devs
Estratégia de Produto Eficaz - Marcell Almeida - Live PM3 + Impulso
Prototipação de software
Palestra de SCRUM em Juazeiro
eXtreme Programming
300 ideias para programar
Produtos que viciam - Mercado Livre Experience
Os princípios do design de interfaces para uma IHC eficaz!
1º Curitiba Scrum Day
Teste de usabilidade
Ferramentas de Gerenciamento de Projetos
1- Apresentacao Metodologia RCP

Último (19)

PPTX
Gestao-de-Bugs-em-Software-Introducao.pptxxxxxxxx
PDF
Custos e liquidação no SAP Transportation Management, TM130 Col18
PPTX
Como-se-implementa-um-softwareeeeeeeeeeeeeeeeeeeeeeeee.pptx
PDF
Custos e faturamento no SAP S/4HANA Transportation Management, S4TM3 Col26
PDF
Gestão de transportes básica no SAP S/4HANA, S4611 Col20
PPTX
Aula 18 - Manipulacao De Arquivos python
PDF
Fullfilment AI - Forum ecommerce 2025 // Distrito e Total Express
PDF
20250805_ServiceNow e a Arquitetura Orientada a Serviços (SOA) A Base para Ap...
PPTX
Aula16ManipulaçãoDadosssssssssssssssssssssssssssss
PDF
COBITxITIL-Entenda as diferença em uso governança TI
PDF
Processos na gestão de transportes, TM100 Col18
PDF
Aula04-Academia Heri- Tecnologia Geral 2025
PDF
Otimizador de planejamento e execução no SAP Transportation Management, TM120...
PDF
Fundamentos de gerenciamento de ordens e planejamento no SAP TransportationMa...
PDF
Mergulho profundo técnico para gestão de transportes no SAP S/4HANA, S4TM6 Col14
PPTX
Informática Aplicada Informática Aplicada Plano de Ensino - estudo de caso NR...
PPTX
BANCO DE DADOS - AULAS INICIAIS-sgbd.pptx
PDF
Apple Pippin Uma breve introdução. - David Glotz
PPTX
Programação - Linguagem C - Variáveis, Palavras Reservadas, tipos de dados, c...
Gestao-de-Bugs-em-Software-Introducao.pptxxxxxxxx
Custos e liquidação no SAP Transportation Management, TM130 Col18
Como-se-implementa-um-softwareeeeeeeeeeeeeeeeeeeeeeeee.pptx
Custos e faturamento no SAP S/4HANA Transportation Management, S4TM3 Col26
Gestão de transportes básica no SAP S/4HANA, S4611 Col20
Aula 18 - Manipulacao De Arquivos python
Fullfilment AI - Forum ecommerce 2025 // Distrito e Total Express
20250805_ServiceNow e a Arquitetura Orientada a Serviços (SOA) A Base para Ap...
Aula16ManipulaçãoDadosssssssssssssssssssssssssssss
COBITxITIL-Entenda as diferença em uso governança TI
Processos na gestão de transportes, TM100 Col18
Aula04-Academia Heri- Tecnologia Geral 2025
Otimizador de planejamento e execução no SAP Transportation Management, TM120...
Fundamentos de gerenciamento de ordens e planejamento no SAP TransportationMa...
Mergulho profundo técnico para gestão de transportes no SAP S/4HANA, S4TM6 Col14
Informática Aplicada Informática Aplicada Plano de Ensino - estudo de caso NR...
BANCO DE DADOS - AULAS INICIAIS-sgbd.pptx
Apple Pippin Uma breve introdução. - David Glotz
Programação - Linguagem C - Variáveis, Palavras Reservadas, tipos de dados, c...

Prototipagem

  • 1. Taynara Jaegger da Silva – PUC Gávea
  • 2. “ Task Design” Permite descobrir peças na interface que funcionam bem e os problemas encontrados enquanto o usuário estiver navegando.
  • 3. Características de boa tarefa Baseado nos objetivos do perfil do seu usuário. Abrange questões importantes para o sucesso do seu produto e empresa. Escopo adequado – não muito largo, não muito específico. Conjunto finito e previsível das possíveis soluções. Ponto final evidente, que o usuário reconheça. Provoca ação e não apenas uma opinião.
  • 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. Para se conseguir esses dois itens, precisamos seguir as seguintes etapas : Listar as metas e realizações que os usuários que podem alcançar usan do a interface Fazer uma lista de metas e realizações que são importantes para o perfil de usuário escolhido. Quais são as pessoas que utilizam a interface? O que é importante para eles? Como o produto torna sua vida melhor. Sempre pensar sobre os objetivos dos usuários e não somente em funcionalidades. Listar perguntas, riscos e outras questões sobre a interface Fazer uma lista de todas as questões e preocupações que você tem em relação ao produto, que pode ser feito numa reunião “kickoff” (reunião de “startup” do projeto). Algumas questões podem vir a partir de “feedbacks” dos usuários ou a partir de ideias ocasionadas por algum incomodo na interface.
  • 8. Priorizar as perguntas 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. Uma forma de priorizar os problemas é uma votação para as 3 perguntas que se demonstrarem ser as mais importantes. Escolha uma realização do usuário que cobre questões importantes para poder transformar em uma tarefa – Criar uma tarefa 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: Tarefa nome e número - Dê a cada tarefa um nome breve descritivo e um número. 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? 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 no início da tarefa. Os pressupostos dependem daquilo que você quer aprender a tarefa que um usuário precisa para completar esta tarefa.
  • 9. Passos - Anote os passos que você espera que o usuário irá percorrer na realização da tarefa. Tempo estimado para perito - estimar quanto tempo levaria um perito (alguém da equipe do núcleo) para completar a tarefa. Instruções para os usuários. Não escreva as instruções para os usuários, quando você está enchendo o resto do modelo. Embora o design tarefa funciona bem como uma atividade de grupo, escrevendo as instruções pode ser feito por uma pessoa depois de você ter elaborado o seu conjunto de tarefas. Determinar a ordem das tarefas Numerar as tarefas é necessário, para que o usuário tenha noção do tempo que está levando para executar a tarefa. Estimativamente o usuário leva de 5 a 20 min para executar uma tarefa completa. 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. Para alguns tipos de testes de usabilidade é importante usar as mesmas funções na mesma ordem para cada usuário.
  • 10. 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. Revise suas tarefas
  • 11. Elaboração do Protótipo 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.
  • 12. Necessário para uma tarefa Listar em um quadro todas as telas que o protótipo precisará apoiando as tarefas planejadas Manter a lista em alto nível, não precisa especificar todas os itens do menu, só os que a tarefa utiliza Geralmente é mais rápido criar esta lista sem olhar para a interface existente.
  • 13. Por exemplo uma tarefa, de abrir uma conta de aposentadoria em um site financeiro pode exigir as seguintes telas: Janela de Navegador com controles Home Page Usuários de login existentes Telas de novas contas Explicações sobre “Regular / Roth IRA” Resumo da conta Política de Privacidade Termos e Condições Fundos Necessário para uma tarefa
  • 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. Identificação de peças do protótipo, que ainda precisam ser criadas. Prepare-se para diferentes caminhos que o usuário possa razoavelmente ter . 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. Dar a prática do computador em manipular todos aqueles pedaços de papel. Identificar as questões relativas à viabilidade técnica. Passo a Passo Internamente
  • 30. 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: Monitor - Pessoa que organiza e manipula todos os pedaços de papel. Usuário avançado - Um membro da equipe de produtos desempenha este papel, realizando as tarefas como um especialista. Escritor - Essa pessoa escreve todas as peças em falta, problemas e questões que surgem. Facilitador - Pessoa designada para tirar algumas dúvidas do usuário que não comprometam seus testes. Como fazer o passo a passo?
  • 31. 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. 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. 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. 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. Atenção para o que não é um teste de usabilidade
  • 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