Estilos de Interação Estilos de Interação

(1)

serg

semiotic engineering research group

Estilos de Interação Estilos de Interação

(2)

Estilos de interação Estilos de interação

• De que formas o usuário poderá interagir com a aplicação?

– linguagem natural

– linguagem de comando – menus

• De que formas o usuário poderá interagir com a aplicação?

– linguagem natural

– linguagem de comando – menus

– menus

– manipulação direta

– preenchimento de formulários

– WIMP (Windows, Icons, Menus, and Pointers) – 3DUI – Interação 3D

– menus

– manipulação direta

– preenchimento de formulários

– WIMP (Windows, Icons, Menus, and Pointers)

– 3DUI – Interação 3D

(3)

Linguagem natural – exemplos

(4)

Linguagem natural – aspectos de design Linguagem natural – aspectos de design

• qual é o vocabulário permitido? (léxico)

• quais são as sentenças permitidas?

(gramática)

• qual é o vocabulário permitido? (léxico)

• quais são as sentenças permitidas?

(gramática)

(5)

Linguagem de comando – exemplo

(6)

Linguagem de comando – aspectos de design

• organização

– comandos simples

– comandos + parâmetros

– comandos + opções + parâmetros

• estrutura

– ordenação dos parâmetros – símbolos vs. palavras-chave

• organização

– comandos simples

– comandos + parâmetros

– comandos + opções + parâmetros

• estrutura

– ordenação dos parâmetros – símbolos vs. palavras-chave – símbolos vs. palavras-chave – estrutura hierárquica

• vocabulário

– especifidade vs. generalidade

– estratégias de abreviação: truncar, eliminar vogais, primeira e última letras, primeira letra de cada palavra, abreviações padronizadas de outros contextos, fonética

– símbolos vs. palavras-chave – estrutura hierárquica

• vocabulário

– especifidade vs. generalidade

– estratégias de abreviação: truncar, eliminar vogais, primeira e última letras, primeira letra de cada palavra, abreviações padronizadas de outros contextos, fonética

(7)

Menus – exemplo

(8)

Menus – aspectos de design Menus – aspectos de design

• organização

– grupos de itens logicamente semelhantes – grupos cobrem todas as possibilidades – sobreposições inexistentes

– itens ordenados

• estrutura

• organização

– grupos de itens logicamente semelhantes – grupos cobrem todas as possibilidades – sobreposições inexistentes

– itens ordenados

• estrutura

estrutura linear

• estrutura

– linear – árvore

• vocabulário

– rótulos familiares – opções bem distintas

• estrutura

– linear – árvore

• vocabulário

– rótulos familiares – opções bem distintas

estrutura em árvore

(9)

Manipulação direta – exemplo

(10)

Manipulação direta – aspectos de design Manipulação direta – aspectos de design

• mapeamento de conceitos (concretos ou abstratos) do mundo real para elementos gráficos concretos

• mapeamento de operações do mundo real para movimentos e operações do mouse

• mapeamento de conceitos (concretos ou abstratos) do mundo real para elementos gráficos concretos

• mapeamento de operações do mundo real

para movimentos e operações do mouse

(11)

Preenchimento de formulário – exemplo

(12)

Preenchimento de formulário – aspectos de design

• organização

– agrupamento lógico – seqüência dos campos – layout

• organização

– agrupamento lógico – seqüência dos campos – layout

• vocabulário

– título e rótulos – instruções

• prevenção e tratamento de erros

• vocabulário

– título e rótulos – instruções

• prevenção e tratamento de erros

(13)

WIMP (Windows, Icons, Menus, and Pointers)

WIMP (Windows, Icons, Menus, and

Pointers)

(14)

Desktop PC Desktop PC

• Display do computador como representação visual de uma mesa onde documentos e pastas são organizados

• Vantagem: organização!

(15)

3D interfaces 3D interfaces

• Espaço de um único display é pequeno. Se

considerássemos a equivalência a um desktop físico:

• Espaço de um único display é pequeno. Se

considerássemos a equivalência a um desktop físico:

• Soluções:

– Múltiplos monitores – 3D interfaces

• Soluções:

– Múltiplos monitores

– 3D interfaces

(16)

3D interfaces 3D interfaces

Microsoft’s Task Gallery Windows Vista

3D Desktops

(Compiz-fusion)

(17)

Definição formal de 3DUI Definição formal de 3DUI

• Uma definição formal para 3DUI

…uma interface humano-computador em que a linguagem usada pelo usuário para introduzir

comandos e informação no computador, e/ou a

linguagem usada pelo computador para apresentar a informação ao usuário, são baseadas no espaço físico e suas 3 dimensões.

• Uma definição formal para 3DUI

…uma interface humano-computador em que a linguagem usada pelo usuário para introduzir

comandos e informação no computador, e/ou a

linguagem usada pelo computador para apresentar a informação ao usuário, são baseadas no espaço físico e suas 3 dimensões.

suas 3 dimensões.

• Cobre as várias maneiras em que 3DUI pode aparecer em diferentes tipos de aplicações.

suas 3 dimensões.

• Cobre as várias maneiras em que 3DUI pode aparecer

em diferentes tipos de aplicações.

(18)

3DUI – Entrada 3D

(19)

3DUI – Informação no Espaço 3D

(20)

3DUI – Saída 3D

(21)

serg

semiotic engineering research group

Ciclos de vida

(22)

Ciclo de vida em cascata Ciclo de vida em cascata

Análise de Requisitos

Projeto e Especificação Especificação

Implementação

Testes

Manutenção

(23)

Ciclo de vida em espiral (Boehm, 1986)

(24)

Design Centrado no Usuário: Mudança de Paradigma

desenvolvimento centrado no

sistema

desenvolvimento centrado no

usuário

desenvolvimento situado no contexto

organizacional e social

envolvimento de usuários no processo de design

considerações sobre grupos de usuários com tarefas e papéis diferentes (ex: gerentes e técnicos)

importância da qualidade de IHC

(25)

Processo de desenvolvimento em estrela (Hix & Hartson, 1993)

implementação análise de tarefas

e funcional

prototipação requisitos e

especificação

design conceitual/

representação formal do design

avaliação

(26)

Um ciclo de vida simples para projeto da interação

(Preece et al., 2002)

Um ciclo de vida simples para projeto da interação

(Preece et al., 2002)

identificação de necessidades e definição de

requisitos

(re)design

requisitos

avaliação

construção de uma

versão interativa produto

final

(27)

Ciclo de Vida de Engenharia de Usabilidade (Nielsen 1993)

1. Conhecendo o usuário 2. Análise competitiva 3. Definindo metas de

usabilidade

4. Design paralelo

5. Design participativo 1. Conhecendo o usuário 2. Análise competitiva 3. Definindo metas de

usabilidade

4. Design paralelo

5. Design participativo

7. Aplicação de diretrizes e análise heurística

8. Prototipação

9. Avaliação empírica 10.Design iterativo

– captura do design

7. Aplicação de diretrizes e análise heurística

8. Prototipação

9. Avaliação empírica 10.Design iterativo

– captura do design

5. Design participativo 6. Design coordenado da

interface global

5. Design participativo 6. Design coordenado da

interface global

– captura do design rationale

11.Coleta de feedback do uso

– captura do design rationale

11.Coleta de feedback do

uso

(28)

1. Conhecendo o usuário 1. Conhecendo o usuário

• estude os usuários-alvo e o uso pretendido do produto

• visite o ambiente de trabalho do cliente

• inclua todos os usuários

– administradores, suporte técnico, ...

– “usuário”: todos cujo trabalho será afetado pelo produto de alguma forma, incluindo os usuários do produto final gerado pelo sistema → stakeholders

• estude os usuários-alvo e o uso pretendido do produto

• visite o ambiente de trabalho do cliente

• inclua todos os usuários

– administradores, suporte técnico, ...

– “usuário”: todos cujo trabalho será afetado pelo produto de alguma forma, incluindo os usuários do produto final gerado pelo sistema → stakeholders

• dificuldades no acesso aos usuários

– empresas de desenvolvimento

• não querem que os usuários conheçam diretamente os desenvolvedores, para não os usarem como “atendimento ao cliente”

– representantes de vendas

• relutam em deixar que outros na empresa falem com os “seus” clientes, pois poderiam ofendê-los ou criar insatisfação com a geração atual de produtos

– usuários

• têm pouco tempo disponível ou não gostam de ser “estudados”

• dificuldades no acesso aos usuários

– empresas de desenvolvimento

• não querem que os usuários conheçam diretamente os desenvolvedores, para não os usarem como “atendimento ao cliente”

– representantes de vendas

• relutam em deixar que outros na empresa falem com os “seus” clientes, pois poderiam ofendê-los ou criar insatisfação com a geração atual de produtos

– usuários

• têm pouco tempo disponível ou não gostam de ser “estudados”

(29)

1.1 Características individuais 1.1 Características individuais

• experiência no trabalho, nível instrucional, idade, experiência prévia com computadores

– previsão de dificuldades de aprendizado

– estabelecimento de limites para a complexidade da interface

• habilidade lingüística e de leitura

– ex.: crianças pequenas precisam de interfaces não-textuais

• de quanto tempo os usuários dispõem para aprender a usar o sistema ou se terão treinamento

• experiência no trabalho, nível instrucional, idade, experiência prévia com computadores

– previsão de dificuldades de aprendizado

– estabelecimento de limites para a complexidade da interface

• habilidade lingüística e de leitura

– ex.: crianças pequenas precisam de interfaces não-textuais

• de quanto tempo os usuários dispõem para aprender a usar o sistema ou se terão treinamento

sistema ou se terão treinamento

– pouco ou nenhum treinamento requer interfaces mais simples

• contexto social e de trabalho do usuário

– alarmes ou efeitos sonoros, “beeps”

• como coletar informações sobre os usuários

– análise de mercado – estudos etnográficos

– questionários e entrevistas

sistema ou se terão treinamento

– pouco ou nenhum treinamento requer interfaces mais simples

• contexto social e de trabalho do usuário

– alarmes ou efeitos sonoros, “beeps”

• como coletar informações sobre os usuários

– análise de mercado – estudos etnográficos

– questionários e entrevistas

(30)

1.2 Análise de tarefas 1.2 Análise de tarefas

• objetos de análise

– objetivos gerais dos usuários

• Por que você faz isto?

– como realizam as tarefas atualmente

• Como você faz isto? Por que não faz da maneira tal?

– necessidades de informação

• objetos de análise

– objetivos gerais dos usuários

• Por que você faz isto?

– como realizam as tarefas atualmente

• Como você faz isto? Por que não faz da maneira tal?

– necessidades de informação – necessidades de informação

• De que vc precisa saber para fazer isto?

– como situações emergenciais ou excepcionais são conduzidas

• Ocorrem erros quando você faz isto? Como você descobre e corrige esses erros?

• como os usuários entendem a tarefa

– modelo conceitual

– metáforas para a interface – necessidades de informação

• De que vc precisa saber para fazer isto?

– como situações emergenciais ou excepcionais são conduzidas

• Ocorrem erros quando você faz isto? Como você descobre e corrige esses erros?

• como os usuários entendem a tarefa

– modelo conceitual

– metáforas para a interface

(31)

1.2 Análise de tarefas (cont.) 1.2 Análise de tarefas (cont.)

• entrevistas e observação

– usuários extremamente eficientes

– estratégias que contornam situações problemáticas

– exemplos concretos dos artefatos utilizados ou produzidos pelos usuários

– situações de solução de problemas reais

• produto da análise de tarefas

• entrevistas e observação

– usuários extremamente eficientes

– estratégias que contornam situações problemáticas

– exemplos concretos dos artefatos utilizados ou produzidos pelos usuários

– situações de solução de problemas reais

• produto da análise de tarefas

– lista dos objetivos dos usuários (metas)

– informações necessárias para atingir estas metas (pré- condições)

– passos a serem executados e as interdependências entre estes passos

– resultados e relatórios que precisam ser produzidos

– critérios de avaliação da qualidade e “aceitabilidade” desses resultados

– necessidades de comunicação do usuário com outras pessoas durante a execução da tarefa

• produto da análise de tarefas

– lista dos objetivos dos usuários (metas)

– informações necessárias para atingir estas metas (pré- condições)

– passos a serem executados e as interdependências entre estes passos

– resultados e relatórios que precisam ser produzidos

– critérios de avaliação da qualidade e “aceitabilidade” desses resultados

– necessidades de comunicação do usuário com outras pessoas durante a execução da tarefa

(32)

1.3 Análise funcional 1.3 Análise funcional

• Não se trata de perpetuar formas

inadequadas ou pouco eficientes de se

realizar tarefas por causa de limitações de uma tecnologia antiga!

• Não se trata de perpetuar formas

inadequadas ou pouco eficientes de se

realizar tarefas por causa de limitações de uma tecnologia antiga!

• O que realmente precisa ser feito? E por quê?

– Quais são os procedimentos que podem ser alterados?

• Análise de tarefas ↔ Análise funcional

• O que realmente precisa ser feito? E por quê?

– Quais são os procedimentos que podem ser alterados?

• Análise de tarefas ↔ Análise funcional

(33)

1.4 Evolução dos usuários 1.4 Evolução dos usuários

• o usuário não permanece o mesmo

– na medida em que evolui, utilizará o sistema de novas formas

• co-evolução de tarefas e artefatos

– ex.: uso de planilha como banco de dados

• o usuário não permanece o mesmo

– na medida em que evolui, utilizará o sistema de novas formas

• co-evolução de tarefas e artefatos

– ex.: uso de planilha como banco de dados – ex.: uso de planilha como banco de dados

• uso criativo é impossível de prever

– design flexível tem mais chances de apoiar novos usos: atalhos, linguagens de extensão – ex.: uso de planilha como banco de dados

• uso criativo é impossível de prever

– design flexível tem mais chances de apoiar

novos usos: atalhos, linguagens de extensão

(34)

2. Análise competitiva 2. Análise competitiva

• avaliação de produtos de competidores

– benefícios

• idéias sobre o que funciona e o que não funciona

– avaliação empírica

• pode ser mais realista do que outros tipos de

• avaliação de produtos de competidores

– benefícios

• idéias sobre o que funciona e o que não funciona

– avaliação empírica

• pode ser mais realista do que outros tipos de

• pode ser mais realista do que outros tipos de protótipos

• como as técnicas de interação apóiam os tipos de tarefas requeridos para o novo produto

– análise comparativa

• abordagens diferentes para questões de design do produto

• produtos de software ou outras mídias (p.ex.:

livros, telefone, ...)

• pode ser mais realista do que outros tipos de protótipos

• como as técnicas de interação apóiam os tipos de tarefas requeridos para o novo produto

– análise comparativa

• abordagens diferentes para questões de design do produto

• produtos de software ou outras mídias (p.ex.:

livros, telefone, ...)

(35)

3. Definindo metas de usabilidade 3. Definindo metas de usabilidade

• nem todos os aspectos de usabilidade podem ter peso igual em um projeto de design

– prioridades com base na análise dos usuários e de suas tarefas

• exemplo: facilidade de aprendizado em organizações com alta rotatividade

– metas mensuráveis

• nem todos os aspectos de usabilidade podem ter peso igual em um projeto de design

– prioridades com base na análise dos usuários e de suas tarefas

• exemplo: facilidade de aprendizado em organizações com alta rotatividade

– metas mensuráveis – metas mensuráveis

• análise do impacto financeiro

– estimativa do impacto na organização desenvolvedora

• magnitude do orçamento voltado para usabilidade

– estimativa do impacto nas organizações dos usuários

• priorização do foco dos recursos de usabilidade disponíveis

– metas mensuráveis

• análise do impacto financeiro

– estimativa do impacto na organização desenvolvedora

• magnitude do orçamento voltado para usabilidade

– estimativa do impacto nas organizações dos usuários

• priorização do foco dos recursos de usabilidade

disponíveis

(36)

4. Design paralelo 4. Design paralelo

• vários designers elaboram designs preliminares distintos

– explorar alternativas de design diferentes – designs direcionados: foco em

• diferentes classes de usuários

• vários designers elaboram designs preliminares distintos

– explorar alternativas de design diferentes – designs direcionados: foco em

• diferentes classes de usuários

• metas de usabilidade distintas

• diversos estilos de interface

– ex: usuários novatos; usuários especialistas;

interfaces não-verbais

• comparação e combinação dos diferentes designs

• diferentes classes de usuários

• metas de usabilidade distintas

• diversos estilos de interface

– ex: usuários novatos; usuários especialistas;

interfaces não-verbais

• comparação e combinação dos diferentes

designs

(37)

5. Design participativo 5. Design participativo

• envolvimento de um grupo de usuários a que se tem acesso

– apesar da análise de usuário, não se pode conhecê-lo totalmente para ter respostas a todas as perguntas que surgem durante o design

– usuários levantam questões interessantes e sobre as quais os designers não pensariam

• as tarefas reais dos usuários podem ser diferentes dos modelos conceituais que os designers têm destas tarefas

– recursos

• envolvimento de um grupo de usuários a que se tem acesso

– apesar da análise de usuário, não se pode conhecê-lo totalmente para ter respostas a todas as perguntas que surgem durante o design

– usuários levantam questões interessantes e sobre as quais os designers não pensariam

• as tarefas reais dos usuários podem ser diferentes dos modelos conceituais que os designers têm destas tarefas

– recursos – recursos

• protótipos ou maquetes em papel para avaliar a reação dos usuários a idéias de design

• discussões guiadas

• não se trata simplesmente de perguntar aos usuários o que eles querem

– eles não conhecem todas as possibilidades da tecnologia

– eles nem sempre sabem elaborar soluções para os seus problemas

• deve-se evitar o envolvimento intensivo de um único usuário

– ele pode ser levado a pensar mais como os designers do que como os usuários que deveria representar

– os usuários são diferentes, e deve-se conhecer diversos pontos de vista

– recursos

• protótipos ou maquetes em papel para avaliar a reação dos usuários a idéias de design

• discussões guiadas

• não se trata simplesmente de perguntar aos usuários o que eles querem

– eles não conhecem todas as possibilidades da tecnologia

– eles nem sempre sabem elaborar soluções para os seus problemas

• deve-se evitar o envolvimento intensivo de um único usuário

– ele pode ser levado a pensar mais como os designers do que como os usuários que deveria representar

– os usuários são diferentes, e deve-se conhecer diversos pontos de vista

(38)

6. Design coordenado da interface global 6. Design coordenado da interface global

• em busca da consistência

– em um único produto

– em produtos de uma mesma “família” (setor ou organização)

– conformidade com padrões de interface da

• em busca da consistência

– em um único produto

– em produtos de uma mesma “família” (setor ou organização)

– conformidade com padrões de interface da – conformidade com padrões de interface da

empresa

• autoridade centralizada para coordenar os diversos aspectos da interface

– possíveis conflitos com outros critérios de usabilidade

– padrões de interface – reuso de código

– conformidade com padrões de interface da empresa

• autoridade centralizada para coordenar os diversos aspectos da interface

– possíveis conflitos com outros critérios de usabilidade

– padrões de interface

– reuso de código

(39)

7. Aplicação de diretrizes 7. Aplicação de diretrizes

• diretrizes (guidelines):

– princípios bem conhecidos para o design de interfaces de usuário – diferentes níveis de guidelines:

• gerais: aplicáveis a todas as interfaces

– ex.: (1) forneça feedback

• por categoria: para um tipo de sistema (ex.: sistema para o gerenciamento de arquivos baseado em janelas)

– ex.: (1) forneça feedback →(1.1) os principais objetos de interesse devem estar visíveis na tela e seus principais atributos devem ser apresentados

• diretrizes (guidelines):

– princípios bem conhecidos para o design de interfaces de usuário – diferentes níveis de guidelines:

• gerais: aplicáveis a todas as interfaces

– ex.: (1) forneça feedback

• por categoria: para um tipo de sistema (ex.: sistema para o gerenciamento de arquivos baseado em janelas)

– ex.: (1) forneça feedback →(1.1) os principais objetos de interesse devem estar visíveis na tela e seus principais atributos devem ser apresentados

• por produto individual

– ex.: (1.1) →cada arquivo e subdiretório deve ser representado por um ícone, e diferentes ícones devem representar diferentes classes de objetos (arquivos de dados, arquivos executáveis, e subdiretórios)

• padrões x diretrizes

– padrão (no sentido de padronização) especifica como a interface deve aparecer para o usuário

• objetivo maior é consistência

– diretriz aconselha sobre características de usabilidade da interface

• por produto individual

– ex.: (1.1) →cada arquivo e subdiretório deve ser representado por um ícone, e diferentes ícones devem representar diferentes classes de objetos (arquivos de dados, arquivos executáveis, e subdiretórios)

• padrões x diretrizes

– padrão (no sentido de padronização) especifica como a interface deve aparecer para o usuário

• objetivo maior é consistência

– diretriz aconselha sobre características de usabilidade da interface

(40)

8. Prototipação 8. Prototipação

• elaboração rápida e de baixo custo

• propicia melhor entendimento do design da interface, antes da construção do sistema final

• dimensões de prototipação – vertical

• poucas features, mas com funcionalidade

• testa uma parte limitada do sistema, em condições realistas

– horizontal

• camada superficial com toda a interface do usuário, mas sem a funcionalidade subjacente

• elaboração rápida e de baixo custo

• propicia melhor entendimento do design da interface, antes da construção do sistema final

• dimensões de prototipação – vertical

• poucas features, mas com funcionalidade

• testa uma parte limitada do sistema, em condições realistas

– horizontal

• simulação da interface: interação e navegação, sem funcionalidade

– cenários: simulação de algumas features

• como reduzir o tempo de desenvolvimento de protótipos

– pouca ênfase na eficiência da implementação (exceto o tempo de interação) – código menos confiável ou de baixa qualidade

– algoritmos simplificados (que não dão conta de casos específicos) – Wizard of Oz (ser humano operando “por trás”)

– protótipos de baixa fidelidade (imagens estáticas vs. vídeo) – dados fictícios e conteúdo provisório

– maquetes em papel

• simulação da interface: interação e navegação, sem funcionalidade

– cenários: simulação de algumas features

• como reduzir o tempo de desenvolvimento de protótipos

– pouca ênfase na eficiência da implementação (exceto o tempo de interação) – código menos confiável ou de baixa qualidade

– algoritmos simplificados (que não dão conta de casos específicos) – Wizard of Oz (ser humano operando “por trás”)

– protótipos de baixa fidelidade (imagens estáticas vs. vídeo) – dados fictícios e conteúdo provisório

– maquetes em papel

(41)

8. Prototipação (cont.) 8. Prototipação (cont.)

• cenários

– são descrições de

• um usuário individual

• utilizando um conjunto específico de facilidades de um sistema

• para alcançar um certo resultado

• cenários

– são descrições de

• um usuário individual

• utilizando um conjunto específico de facilidades de um sistema

• para alcançar um certo resultado

• sob circunstâncias específicas

• em um determinado período de tempo

– uso de cenários:

• durante o design da interface para expressar e compreender a forma como os usuários vão interagir com o sistema

• durante avaliação preliminar de um design de interface para obter feedback do usuário sem o custo de se construir um protótipo funcional

• para alcançar um certo resultado

• sob circunstâncias específicas

• em um determinado período de tempo

– uso de cenários:

• durante o design da interface para expressar e compreender a forma como os usuários vão interagir com o sistema

• durante avaliação preliminar de um design de

interface para obter feedback do usuário sem o

custo de se construir um protótipo funcional

(42)

9. Avaliação empírica 9. Avaliação empírica

• faça!

• diferentes tipos de avaliação

– envolvimento de usuários reais (ou não) – interface já implementada (ou não)

• produtos

– lista de problemas de usabilidade

• faça!

• diferentes tipos de avaliação

– envolvimento de usuários reais (ou não) – interface já implementada (ou não)

• produtos

– lista de problemas de usabilidade – lista de problemas de usabilidade

– dicas para apoiar estratégias bem-sucedidas

– prioridade para se solucionar os problemas, com base em sua gravidade (severidade):

• quantas pessoas serão afetadas pelo problema

• quanto tempo (ou outro recurso) cada uma perderá com o problema

• será um problema somente na primeira vez em que for encontrado, ou sempre?

– lista de problemas de usabilidade

– dicas para apoiar estratégias bem-sucedidas

– prioridade para se solucionar os problemas, com base em sua gravidade (severidade):

• quantas pessoas serão afetadas pelo problema

• quanto tempo (ou outro recurso) cada uma perderá com o problema

• será um problema somente na primeira vez em que for encontrado, ou sempre?

(43)

Ex:Problema de baixa gravidade porque só ocorre uma vez

• Não clicar no ícone da barra de títulos por não saber que revela um menu.

• Assim que o usuário descobrir que o menu existe (por indicação de outro usuário ou consultando o manual, por exemplo), não terá problemas em usá-lo novamente.

• Não clicar no ícone da barra de títulos por não saber que revela um menu.

• Assim que o usuário descobrir que o menu existe (por indicação de outro usuário ou consultando o manual, por exemplo), não terá problemas em usá-lo novamente.

terá problemas em usá-lo novamente.

(44)

10. Design iterativo 10. Design iterativo

• são necessárias várias iterações

– alterações feitas para resolver um problema de usabilidade podem...

• não resolvê-lo

• criar novos problemas

• criar problemas para outros usuários que não eram

• são necessárias várias iterações

– alterações feitas para resolver um problema de usabilidade podem...

• não resolvê-lo

• criar novos problemas

• criar problemas para outros usuários que não eram

• criar problemas para outros usuários que não eram afetados pelo problema original

• deve-se registrar as decisões de design

– preservar importantes princípios de usabilidade

– ajudar na elaboração de documentação e de versões em outras línguas

– manter a consistência da interface entre versões

• criar problemas para outros usuários que não eram afetados pelo problema original

• deve-se registrar as decisões de design

– preservar importantes princípios de usabilidade

– ajudar na elaboração de documentação e de versões em outras línguas

– manter a consistência da interface entre

versões

(45)

11. Coleta de feedback de uso 11. Coleta de feedback de uso

• captura de dados de usabilidade para versões futuras

– satisfação dos usuários

– impacto do sistema na qualidade e custo do trabalho dos usuários

• captura de dados de usabilidade para versões futuras

– satisfação dos usuários

– impacto do sistema na qualidade e custo do trabalho dos usuários

– problemas enfrentados pelos usuários

(atendimento aos usuários ou instrutores)

• técnicas

– entrevistas – questionários

– observação do uso

– instrumentação do software

– problemas enfrentados pelos usuários

(atendimento aos usuários ou instrutores)

• técnicas

– entrevistas – questionários

– observação do uso

– instrumentação do software

(46)

Para reflexão – Como fazer tudo errado (Norman, 1988)

• Torne tudo invisível. Não dê qualquer dica sobre as operações esperadas. Não forneça feedback ou qualquer resultado visível das ações que foram tomadas.

Explore a tirania da tela em branco.

• Seja arbitrário.Computadores tornam isto fácil. Use nomes de comandos e ações que não sejam óbvios. Use mapeamentos arbitrários entre a ação pretendida e o que realmente precisa ser feito.

• Seja inconsistente. Mude as regras. Faça com que algo deva ser feito de uma forma em um modo e de outra forma em outro modo. Isto é especialmente eficiente se for necessário ficar trocando um modo pelo outro.

• Torne tudo invisível. Não dê qualquer dica sobre as operações esperadas. Não forneça feedback ou qualquer resultado visível das ações que foram tomadas.

Explore a tirania da tela em branco.

• Seja arbitrário.Computadores tornam isto fácil. Use nomes de comandos e ações que não sejam óbvios. Use mapeamentos arbitrários entre a ação pretendida e o que realmente precisa ser feito.

• Seja inconsistente. Mude as regras. Faça com que algo deva ser feito de uma forma em um modo e de outra forma em outro modo. Isto é especialmente eficiente se for necessário ficar trocando um modo pelo outro.

for necessário ficar trocando um modo pelo outro.

• Torne as operações ininteligíveis.Use linguagem ou abreviações idiosincráticas.

Use mensagens de erro não informativas.

• Seja rude. Trate ações erradas do usuário como quebras de contrato. Insulte. Use expressões incompreensíveis.

• Torne as operações perigosas. Permita que uma simples ação equivocada destrua um trabalho valioso. Torne fácil que se façam coisas desastrosas. Mas coloque avisos no manual; assim, quando as pessoas reclamarem, você pode perguntar,

“Mas você não leu o manual?”

for necessário ficar trocando um modo pelo outro.

• Torne as operações ininteligíveis.Use linguagem ou abreviações idiosincráticas.

Use mensagens de erro não informativas.

• Seja rude. Trate ações erradas do usuário como quebras de contrato. Insulte. Use expressões incompreensíveis.

• Torne as operações perigosas. Permita que uma simples ação equivocada destrua um trabalho valioso. Torne fácil que se façam coisas desastrosas. Mas coloque avisos no manual; assim, quando as pessoas reclamarem, você pode perguntar,

“Mas você não leu o manual?”