Conteúdo - Instituto de Informáticampimenta/Cursos/Notas-aula-BR-Salv-jan-2012.pdf · Design de Interfaces com Usabilidade Marcelo S. Pimenta ([email protected] ) Salvador,

Design de Interfaces com Usabilidade

Marcelo S. Pimenta([email protected] )

Salvador, janeiro de 2012 2

Conteúdo

• Introdução à Interação Humano-Computador (IHC): fundamentos, conceito de usabilidade, etc

• Princípios e técnicas de Desenvolvimento de Software visando usabilidade e Design de Interação: prototipação, projeto centrado no usuário, análise de tarefas, casos de uso essenciais; (inclui noções básicas de avaliação de usabilidade)

• Integração de modelos de Engenharia de Software e IHC

• Exemplos e Exercícios

3

Bibliografia (em português)

• Preece, J. et alli, Design da Interação – Além da Interface Homem-Computador, Bookman, 2005.

Livro texto fundamental sobre Interação Homem-Computador, contendo desde conceitos iniciais a técnicas para design e avaliação de sistemas interativos com usabilidade.

• Barbosa, S.D.J.; Silva, B.S. Interação Humano-Computador. Editora Campus-Elsevier, 2010.

• Cybis, Walter; Betiol, Adriana H.; Faust, Richard. Ergonomia e Usabilidade - Conhecimentos, Métodos e Aplicações. Novatec, 2010 (2a. ed.)

4

PrimeiraParte

5

Roteiro

• I – Motivação

• II – Fundamentos: IHC, Usabilidade

• III – Usabilidade: Como Desenvolver Software Usável?

• IV – Conclusões

6

Interação em Toda a Parte

7

� Usuário frente a um novo dispositivo interativo:� Final feliz :

� Satisfação e Conforto � Saúde e bem-estar � Produtividade

� Interface de qualidade ...� Utilidade� Usabilidade� Eficiência de uso

Importância de IHC (1/3)

8

� Usuário frente a um novo dispositivo interativo:� Final nem tão feliz:

� aborrecimentos, frustrações� stress, psicopatologias � desperdícios e abandono do sistema

� Deficiências de interface...� desconhecimento da atividade� desconhecimento do usuário e das

características (físicas, cognitivas, sociais) humanas

� desinteresse pela lógica de utilização


9

� 95% de todos sistemas atualmente desenvolvidos atualmente são interativos� exceção: sistemas embarcados, “batch”

� Desenvolvimento da interface demanda no mínimo 50% do esforço total de desenvolvimento do sistema

� Bom Preço permite que usuários comprem sistemas;

� Boas interfaces permitem que usuários usem sistemas


10

Qualidade de Interfaces

� Qualidade historicamente ligada a ‘amigabilidade’ (user friendliness)

� Diferentes pontos de vista de qualidade de interfaces:a) Performance humana satisfatória(ISO)

� Eficácia (%) - coeficientes de erro� Eficiência (t, $) - velocidade de uso� Satisfação: grau de aceitação do produto pelo

usuário.

b) Tempo de aprendizado e de retenção

11

– Adequação entre características (físicas/cognitivas) dos usuários e características da interação (com o sistema) para realização de tarefas

– Não é propriedade intrínseca do sistema mas do trio (usuário, sistema, tarefa)

– Expressa por alguns fatores:• facilidade de aprendizado , intuitiva e “natural” • flexibilidade de interação , multiplicidade de formas de uso• robustez de interação , acompanhamento e recuperação em situações de

incidentes

Usabilidade

12

Definitions: What is Usability?

Usability is the measure of the quality of a user's experience when interacting with a product or system — whether a Web site, a software application, mobile technology, or any user-operated device.http://www.usability.gov

13

Why Should You Care About Usability?

� Have you ever…� gotten lost in a Web site?� left a site without finding the information

you wanted?� waited too long for a feedback ?� gone to a site you can’t view or read?� visited a site with outdated information?� SH%$**@DGJ a system ??

14

Why Should You Care?

Jakob Nielsen reports:

"Studies of user behavior on the Web find a low tolerance for difficult designs or slow sites. People don't want to wait. And they don't want to learn how to use a home page. There's no such thing as a training class or a manual for a Web site. People have to be able to grasp the functioning of the site immediately after scanning the home page — for a few seconds at most."

Information Technology Services15

Jakob who?

� Jakob Neilsen is generally recognised as a world authority on usability for the web; a web ´guru´ ;-)

� Has published numerous books on usability;

� Homepage Usability: 50 websites deconstructed;

� Website: www.useit.com

16

Problema de Usabilidade

• se há dificuldades (reais ou potenciais) para determinado usuário ou (grupo de usuários) realizar uma tarefa com a interface !!!

• Graus de severidadeTipo Descrição (necessidade de reparo)

0 Sem importância Não afeta a operação da interface

1 Cosmético Não há necessidade imediata de solução

2 Simples Problema de baixa prioridade (pode ser reparado)

3 Grave Problema de alta prioridade (deve ser reparado)

4 Catastrófico PRIORIDADE MÁXIMA no reparo

17

Usabilidade é importante?

18

Usabilidade é importante?

19

Exemplos de problemas

http://www.englishpractice.com/

20


21


22


23


24


USA

Internacional

25


Onde achar “Portuguese”? Acima ou abaixo?

26


27


http://www.englishpractice.com/

28


29

Types of Usability Problems

� Product doesn’t match job or task� Poor organization/layout� Unexpected occurrence of events� Product not self-evident� Requires recall rather than recognition� Inconsistent screens, messages, terminology� Design is inefficient� Cluttered or unattractive design� No feedback or poor feedback about status or errors� No exit or undo� Help or documentation is not helpful

30

Usabilidade: problema genérico

Problemas em Interfaces em geral: NÃO somente em Software !!!

Don Norman, The Design of Everyday Things

31

Usability of Everyday Objects

� Examples from http://www.baddesigns.com

� Further Reading:� Donald Norman: The Design (Psychology)

of Everyday Things

32

Don who?

� Don Norman pioneering book from 1988 The Design of Everyday Things� Originally published as The psychology of

everyday things� Motivates and explains usability principles

Norman, Donald A. (2002). The Design of Everyday Things. New York: Basic Books.

33

Usability Problem Example: Inconsistent

34

Exercício provocativo

� Escolha um aplicativo qualquer� Investigue-o procurando problemas (reais

ou potenciais) de usabilidade

� Faça uma lista de problemas Atenção: pare após 20 problemas ;-)

� Discussão com colegas e professor

35

Métricas para medir usabilidade?

• Desempenho durante a realização de tarefas:– Conclusão de tarefas (c/ sucesso, parcialmente concluída, não-concluída);– Tempo de realização da tarefa;– Ocorrência de erros;

• Satisfação subjetiva do usuário e correspondência com os objetivos do usuário;

• Adequação a padrões (normas, recomendações, regras ergonômicas, etc.)– Internacionais (ISO)– Continentais (Comunidade Européia, MercoSul, etc)– Nacionais– Institucionais (Style guide)

36

How usable ?

� Spectrum� Not “Is your system usable”, but “How

usable is your system?”

� Can set minimum standards to meet (time, error rate, user satisfaction)

37

Usability is about money too

� Usability is shaped by the UI but usability is much deeper than UI

� Usability relates to the (complex) choices that users make to accomplish one or more tasks easily, efficiently, enjoyably, and with a minimum of errors

� A system is USABLE because it was fundamentally architected that way

38

Usabilidade tem futuro !!

Revista INFO-ExameSetembro, 2007

39

40

41

SegundaParte

42

Roteiro





43

IHC: Interface e Interação

•Alan Kay: ‘For users, the user interface is the program’

sistema

interface aplicação

ação

interpretação

usuário

44

IHC: Interface e Interação

• Interface: • aquilo que interliga dois sistemas• software e hardware para comunicação entre o

usuário e um sistema

• Interação: • comunicação entre usuário e sistema, inter

+ação• processo que engloba ações do usuário sobre

sistema e interpretações dos resultados

45

Sistema Interativo: Funções

� Interface Homem-Computador� Sintaxe da interação: visa completar a interação� Disponibilizar objetos e funções interativas

� do domínio do aplicação� de uso geral

� Núcleo Funcional� Aplicação propriamente dita� Semântica da Interação: visa realizar o objetivo

da tarefa

46

IHC: Objetos e Funções de uso geral

� Apoiar as entradas� Copiar/Colar� Permitir entradas por

Seleção/Combinação� Fornecer valores default/prévios� Desfazer/Refazer� Localizar (browse)

47

IHC: Objetos e Funções de uso geral

� Definir as apresentações (saídas)� Formas de Visualização (zoom, preview, etc...)� Organização das Unidades de Apresentação (telas,

janelas, caixas de diálogo)� Navegação dentro de uma unidade de apresentação

(rolagem/paginação)

� Apoiar o diálogo ...� Navegação entre Unidades de Apresentação� Ajuda� Personalização (cores, minimizar/maximizar, etc)

48

Modelo de Norman

49

Sistemas Interativos são Ferramentas

� Sistemas são FERRAMENTAS de suporte à realização de tarefas:

� UTILIDADE da ferramenta : � Para que usar? O que faz?

� USABILIDADE da ferramenta : � Como usar?

computador como ferramenta

atividade

50

Arquitetura e Comportamento

Formulação Avaliação

N. Funcional Componente de

Apresentação

Sistema Interativo = Núcleo Funcional (Aplicação)+ Interface

Comportamento (Modelo de Norman) :

Linguagemde Ação

Linguagemde Apresentação

Interface

Componente de

Diálogo

Usuário

51

SistemaUsuário

Usuário SistemaCPD

Sistema

Usuário

Internet

Usuário

Sistema

Hoje:IntegraçãoUsuários-Sistemasvia Internet

80’s e 90’s:InteraçãoUsuário-sistema

60’s e 70’s:Sist.em batch

Interação Humano-Computador (IHC): evolução

52

� Adequação entre características (físicas/cognitivas) dos usuários e características da interação (com o sistema) para realização de tarefas

� Não é propriedade do sistema mas do trio (usuário, sistema, tarefa)

� Expressa por 3 fatores:� facilidade de aprendizado , intuitiva e “natural”� flexibilidade de interação , multiplicidade de formas� robustez de interação , acompanhamento e recuperação

Usabilidade

53

Usabilidade

� Facilidade de aprendizado , que agrupa os aspectos da interface que permitem ao usuário novato de compreender inicialmente como o usar e em seguida alcançar por experiência a um nível elevado de performance:

� previsibilidade (histórico de interações → interação futura)

� rastreabilidade (influência de operações passadas no estado atual)

� familiaridade (correlação entre o conhecido e o necessário)

� generalisabilidade (interação específica → similares)

54

Usabilidade

� Flexibilidade de interação , que agrupa os aspectos que permitem uma multiplicidade de maneiras de trocar informações entre o usuário e o sistema:� iniciativa do diálogo (latitude ou liberdade decisional)

� pre-emptivo: usuário no controle � pre-emptivo local: diálogo modal local� pre-emptivo global: diálogo modal global

� multiplos diálogos (intercalados ou paralelos)� migração de tarefas (usuário ↔ sistema)� substutividade (de valores de E/S)� multimodalidade (modos ou canais de comunicação)� configurabilidade (pelo usuário)� adaptabilidade e personalização (ao usuário)

55

Usabilidade

� Robustez de interação , que agrupa os aspectos de interação que suportam a realização e a avaliação de objetivos:

� observabilidade (do estado corrente)� recuperabilidade (de erros)� conformidade à tarefa do usuário

56

Usabilidade

� Resumo� facilidade de aprendizado� facilidade de uso (operação)� taxa de erros minimizada� adequação à tarefa

� Usabilidade obtida por construção � Clara compreensão dos requisitos de

usabilidade durante as etapas iniciais da concepção e não somente ao final� BUSCAR: Usabilidade como requisito do

sistema (´built-in approach´)� EVITAR: Usabilidade somente como critério

de avaliação (´day-after approach´)

57

Métricas para medir usabilidade?

� Desempenho durante a realização de tarefas:� Conclusão de tarefas (c/ sucesso, parcialmente concluída, não-

concluída);� Tempo de realização da tarefa;� Ocorrência de erros;

� Satisfação subjetiva do usuário e correspondência com os objetivos do usuário;

� Adequação a padrões (normas, recomendações, regras ergonômicas, etc.)� Internacionais (ISO)� Continentais (Comunidade Européia, MercoSul, etc)� Nacionais� Institucionais (Style guide)

58

Traditional Criteria:• ease of learning• efficient/ergonomic use• minimal errors• retention over time• subjective satisfaction

Q: What makes something usable?A: It depends …

Some Human Factors:• users’ computer aptitude• users’ computer experience• users’ computer expertise• users’ domain expertise• frequency of users’ use of the tool• physical coordination & health

Some Technology Factors:• de facto standards• display factors (eg screen size)• interactions of software and hardware

Individual Differences•All users are not the same!•We think about “homogeneous target user groups”•Distinguishing between individual and group differences is not easy

59

•Many “design guidelines” exist that claim to ensure usability

•Usability Goals are always Tradeoffs, and can conflict with one another

Rapid learning

Subjective satisfaction for novices

Safety/error constraint Awkward/extra steps

Extreme irritation for experts

Low power

•BUT while acessibility guidelines and checklists are important, it is also vital to observe REAL USERS IN ACTION

•Usability is perceived, not ascribed.

•BUT there are some universal principles for good design and bad design

Usability Goals

60

What about Acessibility?

�"The power of the Web is in its universality. Access by everyone regardless of disability is an essential aspect." Tim Berners-Lee, W3C Director and inventor of the World Wide Web

61

Acessibilidade� “Possibilidade de acesso, processo de conseguir

igualdade de oportunidade em todas as esferas da sociedade" ONU

� “A acessibilidade da Internet caracteriza-se pela flexibilidade da informação e interação relativamente ao respectivo suporte de apresentação” hp Brasil

� "The power of the Web is in its universality. Access by everyone regardless of disability is an essential aspect." Tim Berners-Lee, W3C Director and inventor of the World Wide Web

62

Experimento� IHC2002: Pimenta et alli. A (in)acessibilidade

de sites governamentais, Fortaleza, 2002.

� Sites governamentais analisados� GOVERNO FEDERAL:

� SEESP: www.mec.gov.br/seesp� INPA: www.inpa.gov.br

� GOVERNO ESTADUAL:� PROCON/RS : www.procon.rs.gov.br

� GOVERNO MUNICIPAL:� PREFEITURA DE PoA: www.portoalegre.rs.gov.br

63

Plataforma e Navegadores

� SISTEMAS OPERACIONAIS E

NAVEGADORES

64


Internet Explorer X Netscape

65

Exemplos de Problemas� EXEMPLO

66

Iniciativas� Ação Brasileira para a Acessibilidade - ABRA

� " ... garantir a acessibilidade das pessoas com deficiência e/ou necessidades especiais aos portais(públicos) na Internet". � http://www.acessibilidade.org.br

� W3C Acessibility Initiative

67

Alertas� Mais Prioridade à acessibilidade:

� Acessibilidade: requisito social e de qualidade de vida

� Conseqüências:� Alertar e conscientizar órgãos responsáveis por

sites de e-government :� Contatos com prefeituras e Webmasters de alguns sit es

� Alertar e conscientizar os desenvolvedores� Pequenas correções para adequação� Maior Divulgação de Recomendações Básicas (como “Qu ick

Tips to make Accessible Web Sites” da W3C)� Maior divulgação de ferramentas

� Mais avaliações e divulgação de resultados

68

Acessibilidade

RECOMENDAÇÕES W3C� "Web Content Accessibility Guidelines 1.0“� www.w3c.org/TR/WCAG10/� Todos os pontos de prioridade 1, alguns de 2 e 3

FERRAMENTAS ■ P.ex. Para validar XHTML/HTML de um website no W3c: http://validator.w3.org/

USO EM DIVERSOS NAVEGADORES E PLATAFORMAS

69

Guidelines para acessibilidade

http://www.w3.org/WAI/

70

Acessibility problem: example

http://www.terra.com.br/istoe/

browser1 X browser2

Devices x platforms x browsers

71

Acessibility initiative and tools� Brazilian:

•Ação Brasileira para a Acessibilidade - ABRA •http://www.acessibilidade.org.br

� Universal:• W3C Acessibility Initiative•"Web Content Accessibility Guidelines 1.0“�www.w3c.org/TR/WCAG10/

� Tools �Bobby www.cast.org/Bobby/

72

Acessibility Guidelines


73

HCI background

� Cognitive Psychology� Human Factors (Ergonomics)� Graphic Design� Semiotics

� ´H´side of HCI ;-)

74

Semantic Distance

input

Articulatory Distance

input

Exe

cutio

n gu

lf Evaluation gulf

Semantic Distance

output

Articulatory Distance

output

75

TerceiraParte

76

Roteiro





77

Como desenvolver software usável?

� multidisciplinary activity (CS, Ergonomics, Cognitive Psych, graphical design. etc)

� team activity� HCI DOES NOT traditionally

appear in CS curricula� ACM Currícula• SBC (brazilian computer society)

curricula•UFRGS : since 1993 !!!!

� What about YOU ????� DID you know HCI issues?

78

HCI: focus is on USAGE

� Try to do it:� Menu design for CRUD functions

PRODUCT

SUPPLIER

1..*

1..1

1..*

1..*

79

Product

Fornecedor

InsertDeleteUpdateRetrieve

InsertDeleteUpdateRetrieve

Developer´s View

(system-oriented)

Menu basically reflects internal DB operations

80

Insert Product

Update Product

Retrieve Product

Insert Supplier

Delete Product

Retrieve Supplier

Insert/Update Supplier

Retrieve Supplier

User´s View

(usage-oriented)Menu basically reflects frequent tasks when usermanipulates´Product´

81

User-Centred Design (UCD) - HCI Approach

� Taking in account cognitive and physical aspects of user(s)

� Have a goal or purpose for your software� Spend time in planning and design.� Don’t do things because you can, do them

because they add value.� Continually evaluate and update your

software.

� “Design for user”

82

UCD Summary

Know Your Users!!Know Your Users!!Talk to themTalk to themGet feedback from themGet feedback from them

Know the Users´ Tasks !!Know the Users´ Tasks !!

83

Value of User-Centred Design?

Managers/Developers view of user involvement� I haven’t really thought about it� I know what my users need� It would be nice to do more work with users but I

don’t have the time / budget� My managers are happy with my statistics, so that’s

‘job done’� Customers are central to my service

84


The Standish CHAOS report (1994):

Red = success

Green = completed, over-budget/time, under-functional

Yellow = cancelled

85


The Standish report (1994):Project Success Factors % of Responses

1. User Involvement 15.9%2. Executive Management Support 13.9%3. Clear Statement of Requirements 13.0%4. Proper Planning 9.6%5. Realistic Expectations 8.2%6. Smaller Project Milestones 7.7%Etc.

86

Involving users in development projects

Projects developed in-house:� Seek user involvement early

� understand their requirements� graphic design development� information architecture and interaction

design� technical environment� content type, format, level

� Build-in time and budget for this (bearing CHAOS in mind!)

87

Activities for Designing Usable Systems (quick view)

Evaluation

Planning

Design

Maintenance

� Planning � Design� Implementation� Evaluation and Test� Maintenance

88

Activity One: Planning

“You can use an eraser on the drafting table or a sledge hammer on the construction site.”

- Frank Lloyd Wright

89

Planning: Activities

� Planning activities:� Define the purpose of the system� Identify the contextual information

� Identify target users � Get to know your users� Define the users’ tasks (create scenarios)� Determine scope, usage and change

characteristics of the information� Define the “personality” of your system

� Put together your team

90

7

About Owners•What are their motivation and goals?•Whom do they wish to design for?•What constraints are there?•What aspects of the environment need to be considered?

About Users•Who are they?•How many different individuals, groups?•What are their characteristics, abilities, and limitations?•Why will they use this system?•How often will they use this system?•For what purpose(s) will they use this system?

About Environment•What are/have others done in a

similar setting?•What regulatory or ethical considerations are there?

About Technology•What choices are available?•What tradeoffs need to be considered?•What are the costs, and what is

cost-effective?

Planning: Identify contextual information

91

Planning: Get to know your users

� Talk to your users� Observe your users� Get feedback from your users� Find out…

� Who are your users (characteristics)� What do they do (tasks )

� Current vs. desired� Critical vs. non-critical� User/task matrix

� How do they do it (Task Flow )� Where do they do it (environment )

92

Planning: Knowing Your Users

� What are your users’ characteristics?� Age, computer literacy, domain

knowledge, access methods, browsers, work environments, handicaps, etc.

� Collect this information through� Surveys / Questionnaires� Visits to their environment

93

Planning: Development TeamA cross-disciplinary team includes:

� Project manager (Web site manager)� HTML Authors� Programmers� Interface and Interaction designer� Graphic designer� Human factors/ Usability expert� Writers / Editors� Content Owner(s)� Client / customer� User� System/ server administrator� Representative from a Legal department� Security

94

Activity 2 - Design

“Any object or element of the interface that does not add to communication is subtracting from it.”

-Bruce Tognazzini

95

Design

� Iterative process� Apply guidelines and heuristics� Prototyping:

� Paper prototypes -> Review with users

� On-line prototypes -> Review with users

96

Interaction Design

•Interaction Design is closely related to industrial (physical) design(See Donald Norman’s book, The Design of Everyday Things)

•Three Key Principles:

AffordancesFeatures of an object that convey how it is to be used

ConstraintsAttributes of an object that prevent its incorrect use, or prevent errors

MappingThe arrangement of controls for an object that has natural spatial meaning

•Interaction design refers to the various controls (or “widgets”) that the user must manipulate in using the system

97

Affordances

� Concept from Gibson’s ecological psychology� Norman refers to perceived or actual properties

of objects� Given user’s capabilities, goals, plans, values, etc.

� What can you do with it?� Should you click it, drag it, is it part of the

background?� Can you tell what parts of a user interface are

interactive?

98

Affordances

� Poor affordances� Doors� Push or Pull?� Where to push?

� Good affordances� Buttons that

appear clickable

99

Constraints

� Restrict user actions to valid actions� Eliminate need for perfect knowledge� Recognition over recall� Good constraints are rarely noticed

PREVIOUS NEXT

100

Mappings

� User intentions to available actions� Is there a natural mapping between what

users want to do and what appears possible?� Do users stare at technology for sometime

before they take action?� Or do they immediately know what to do?� Simplicity can help

101

Mappings

� Natural mappings: no explanations needed

User intentions

Available actions

Perceived system state

Actual system state

102

Activity 3 - Implementation

“The intelligent use of graphic elements and design can add greatly to the attractiveness of a web page. But it's like putting on makeup -- you have to know when to stop.”

-Zen and the Art of Web Design

103

Implementation

Follow Design Guidelines and Style GuidesConsider:

� Devices idiosyncrasies� Cross-platform issues� Browser differences� Accessibility issues� Consistency

104

Consistency

� Look and feel

� Style guides

� Same operation has same effect on different objects, screens

105

Implementation: Design Style Guide

Create a design style guide:� The guidelines for a consistent look and feel and

site navigation experience.� The key to success is making the details simple,

understandable, and easy to implement. � A style guide should include:

� Overall navigation and organization� Templates for each “page type”� Guidelines for adding content� Guidelines for removing/archiving content� Presentation guidelines (e.g., color schemes)� Approval and workflow checklists

106

Implementation:Creating the Style Guide

How do you create a style guide?� Start with a general, high-level style guide.� Make it more specific to your project.

� E.g., if high-level says “use a consistent font”, your project style guide would say which font to use.

� Make it easy to use.� Allow it to evolve as your system evolves.

107

Activity 4 - Evaluation

“If the user can’t find it, it isn’t there!”

108

Evaluation: Early and Often

Evaluate your system to verify that it meets your purpose and that your users can use it successfully.

Evaluate early and often:� Conduct tests iteratively.� Do not work in isolation; start collecting feedback

as soon as the structure is defined.� Do not wait for graphics to do testing.� Make it easy for people to give feedback.

109

Evaluation: Usability Testing

What is Usability Testing?� A way to evaluate the interface with real users.� Can be done in a lab or in their environment.� Can be performed on paper prototypes as well as

implemented systems.� How?

� Give users representative tasks to complete.� Watch for where the interface does not support

their task completion.� Identify changes to be made to the interface to

support the user.

110

Activity Five: Maintenance

Do maintenance thinking in the next maintenance ...

Your maintenance budget should be as honest as possible

111

Como desenvolver software usável? (visão detalhada)

Processo de Concepção de Interfaces com Usabilidade:�Análise Contextual�Design de Interfaces�Prototipação de Interfaces�Avaliação de Interfaces

112

Ciclo de Concepção de Interfaces

� Não há ‘receita de bolo’ para concepção de boas interfaces:� É necessário um ciclo de estudo, construção,

experimentação e avaliação de interfaces� Ciclo organiza um procedimento ‘tentativa e

erro’ a partir de uma boa tentativa e guiado por princípios e heurísticas de projeto

� Princípios e heurísticas são aproveitamento da experiência de outros desenvolvimentos (DOs e DON’Ts de projeto)

113

Ciclo de Concepção Ergonômica de Interfaces

� 1a. Etapa: Análise Contextual� Análise do Usuário (modelo do usuário);� Análise da Tarefa de Referência (modelo de

tarefas do usuário);� Análise do Estado-da-Arte (sistemas similares

existentes)� Engenharia de Requisitos:

� Requisitos Funcionais e Não-funcionais� Modelo de Negócio e Casos de Uso Preliminares

114


� 2a. Etapa: Projeto da Interface com o Usuário� Definição das Unidades de Apresentação (UAS =

telas, janelas , folders, etc)� Definição das Sequências entre Uas

(Navegação)� Definição dos Estilos de Diálogo� Projeto das Apresentações (comandos, controles

e mostradores)� Definição do Diálogo de Baixo Nível (de operação

dentro de uma UA)

115


� 3a. Etapa: Prototipação� “Protótipos” em papel� Maquetes em editores de recursos� Protótipos funcionais

� uso de “templates” e geradores

� 4a. Etapa: Avaliação� Implementação de uma versão de trabalho� Avaliação

116

Questões de Concepção� Deve responder às questões:

1) Quais são os usuários?

2) Quais tarefas serão suportadas?

3) Qual o contexto de realização destas tarefas?4) Quais comandos e ações o usuário pode realizar através

da interface?

5) Como os componentes da Interface serão apresentados aos usuários?

6) Como provocar as críticas/sugestões dos usuários? 7) O sistema e sua interface suportam adequadamente as

tarefas dos usuários?

117

Atividades da Concepção



3) Qual o contexto de realização destas tarefas?

Análise Contextual

118

Análise Contextual: O quê?

� Compreender o Problema e o Contexto do Problema

� Contexto Estável:� usuários� tarefas e informações associadas� contexto organizacional e social� restrições tecnológicas

� Contexto Instável:� Cenários de Uso: situações típicas,

singularidades: exceções, erros, interrupções, desvios

119

Análise Contextual: Modelagem do Usuário

Modelo do usuário é o conhecimento sobre o usuário, explícita ou implicitamente representado.

� Por que modelar o usuário ?� Modelos podem ser usados para predizer o

comportamento do usuário, diagnosticar seus erros e auxiliá-los;

� Os dados extraídos da modelagem podem ajudar o projetista no processo de personalização de interfaces.

120

Análise Contextual: Modelo de Usuário

� Tipos de usuário e atributos relevantes� Exemplos de atributos:

� freqüência de uso: (freqüente, periódico,ocasional)� experiência na tarefa: (leigo, novato, com prática, competente,

expert)� experiência em tecnologia de informática: (leigo, novato, com

prática, competente, expert)� experiência em sistemas similares: (elementar, média, grande)� idade, nível de escolaridade, necessidades especiais, etc...

� Perfil = combinação (evolutiva) destes atributos

121

EXERCÍCIO

� Criar uma lista de atributos que você considera relevantes para caracterizar os seus usuários

� Criar categorias de usuários a partir de valores de atributos comuns.

� Discussão !!

122

Análise Contextual: Tarefas

� Tarefa = Objetivo + Mecanismos� Ações orientadas a objetivos que um

agente (usuário ou sistema) realiza por meio de mecanismos

� Integrantes do processo de trabalho (business process)

� Conhecer o Trabalho para Modificá-lo� Análise Ergonômica do Trabalho

� Lógica de Funcionamento e de Utilização� Análise de Tarefa (Task Analysis) � Modelo de Tarefa

123

Análise Contextual: Tarefas� Lógicas do Sistema

� Lógica de Funcionamento (projetistas)� Representação baseada em aspectos internos

� funções e mecanismos internos dos dispositivos,� as inter-relações entre esses mecanismos.

� Lógica de Operação (projetistas e usuários)� Representação baseada em aspectos visívei

� na interação com os dispositivos. � nas repercussões visíveis do sistema

� Sistema é mais usável se mantém coerência com o modus operandi atual da tarefa do usuário

124

Análise Contextual: Cenários de Uso

� Descrições narrativas das interações entre usuário(s) e sistema.

� Diferentes noções e nomes: scripts, use cases, storytelling� Descreve uma situação concreta atual (corrente) ou

potencial (futura) de uso do sistema do ponto de vista do usuário

� Características principais:� Facilitam a comunicação usuário-analista pois permitem exemplificar

comportamentos e refletir sobre sua adequação através de situações concretas de uso do sistema;

� Interessantes para comparar diferentes alternativas para as sequências de ação em função do grau de automação e da metáfora de interação escolhida;

• Podem evoluir e tornar-se artefatos úteis para todo o desenbvolvimento (como os use cases usados em Objectory [Jacobson 92] e UML), e que podem ser aumentados e rearranjados a medida em que o desenvolvimento avança.

125

Análise Contextual: Como Coletar?� Técnicas de Coleta

� Técnicas Baseadas em Comunicação (TBC)� Entrevistas, Surveys, Questionários, Grupos

de Foco, Contextual Inquiry� Técnicas Baseadas em Estudo (TBE)

� Estudo de Formulários e Manuais, Revisão Bibliográfica, Análise dos Sistemas Existentes, Instantâneos de Telas

� Técnicas Baseadas em Observação (TBO)� Imersão, Observação (Direta, Verbalizada,

Seguida de Diálogo), Etnografia

126


4) Quais comandos e ações o usuário pode realizar através da interface?


Projeto da Interface� Projeto de Diálogo� Projeto da Apresentação

127


6) Como provocar as críticas/sugestões dos usuários?

Prototipação/Maquetagem

128


� Protótipo: versão simplificada do sistema� Protótipo Horizontal:

Amplitude: Interface quase completa mas com funcionalidade reduzida

� Protótipo Vertical:Profundidade: Interface e Funcionalidade

completas de uma parte do sistema

129


� Maquetagem� Maquete: versão simplificada da interface

do sistema sem funcionalidade afora a navegação

� Críticas� Críticas Específicas são mais preciosas

que críticas gerais

130


Ciclo de Experimentação/Avaliação/Revisão

1.Construir Primeiro Protótipo/Maquete

2. Submetê-lo ao Usuário

3. Usuário executa tarefas reais em ambiente real ou usuário simula seu uso em laboratório (ensaios de interação)

4. Recolher críticas/sugestões/comentários sobre esta versão

5. Se Usuário acha OK, fim

6. Senão, Revisar/Alterar a versão levando em conta as críticas do usuário e repetir passos 2-6.

131


7) O sistema e sua interface suportam adequadamente as tarefas dos usuários?

Avaliação

132

Concepção de IU do Sw interativo

� atividade multidisciplinar (Informática, Ergonomia, Psicologia Cognitiva, Linguística, Design Visual

e Gráfico, entre outras)� em equipe ou por indivíduos

com consciência de outras áreas

� tradicionalmente, não faz parte da formação de profissionais de Informática

133

SW Interativo:Tipos de Concepção

� Concepção Tradicional (Engenharia de Software)

� Concepção Centrada no Usuário

� Concepção Integrada

134

Concepção Tradicional

� Pouca ou nenhuma consideração ao ponto de vista do usuário e aos aspectos de usabilidade

� Orientação a sistema:� ausência de modelos para IHC � qualidade interna tem mais prioridade que

qualidade externa

� “Design from user”

135

Concepção Centrada no Usuário

� Consideração dos aspectos cognitivos e físicos do usuário

� Orientação a qualidade externa� qualidade interna considerada apenas

superficialmente

� “Design for user”

136

Concepção Centrada no Usuário

� Centrar no Usuário :� Conhecer o usuário : objetivos, técnicas, características� Adaptar o sistema ao usuário e não o usuário ao

sistema : vocabulário, experiência, necessidades� Dar o máximo de controle ao usuário : feedback,

correção, escolha de alternativas e caminhos� Auxiliar o usuário : guiar se necessário, mensagens

explicativas, help on-line, documentação� Perdoar o usuário : não exigir leitura de manuais, prevenir

erros, explicar os erros, desfazer erros

137

Concepção Integrada

� Consideração de aspectos contextuais da realização do trabalho do usuário além dos aspectos cognitivos e físicos do usuário: � centrada no trabalho do usuário � Noção confirmada pela Teoria da Atividade

� Busca integrada da qualidade externa e interna

� “Design for user needs ” 138

Concepção Integrada

� Necessidades solicitadas explicitamente pelo usuário (requisitos do usuário) +

� Necessidades:� Implícitas , identificadas pela análise da tarefa, nem

sempre reconhecidas ou expressas pelos usuários� Contingentes , relativas às regras organizacionais

associadas às atividades dentro de um processo da organização

� Aceitação do sistema depende mais da qualidade de suporte a algumas tarefas e menos da quantidade de funções suportadas

139

Integração de Engenharia de Software e IHC

Fatores de Qualidade e Requisitos para Sistemas Interativos

Fator de Qualidade Requisitos Área

Utilidade Funcionais Engenharia de Software (ES)

Usabilidade Comportamentais IHC

Desenvolvimento de sistemasinterativos úteis e usáveis

Integração de conceitos,modelos, técnicas e ferramentas de ES e IHC

140

Concepção Integrada usa Prototipação/Maquetagem

Ciclo de Experimentação/Avaliação/Revisão:

1.Construir Primeiro Protótipo/Maquete2. Submetê-lo ao Usuário3. Usuário executa tarefas reais em ambiente real ou

usuário simula seu uso em laboratório (ensaios de interação)

4. Recolher críticas/sugestões/comentários sobre esta versão

5. Se Usuário acha OK, fim6. Senão, Revisar/Alterar a versão levando em conta

as críticas do usuário e repetir passos 2-6.

141

Concepção Integrada usa Prototipação/Maquetagem

� Protótipo: versão simplificada do sistema� Protótipo Horizontal:

Amplitude: Interface quase completa mas com funcionalidade reduzida

� Protótipo Vertical:Profundidade: Interface e Funcionalidade completas

de uma parte do sistema

� Maquete: versão simplificada da interface sem funcionalidade, somente com navegação

142

- Usuários- Tarefas - Tecnologia Disponível

Aspectos Envolvidos

143

Usuários (1/2)

� Usuário ≠ Cliente� Diferentes tipos de usuários

� diferentes personalidades, motivações, culturas, idades, experiências, habilidades, necessidades

� todo usuário tem receios: parecer ‘burro’, aprender algo novo, ser substituído, destruir algum dado, etc.

� P.ex: Quanto a nível de experiência no uso de computadores:

experiente mediano novato leigoPânicoNecessidade de atalhos

+

+

144

Usuários (2/2)

- * Perfis Diferentes de Usuários• * Experts x Noviços:

- - Noviços tornam-se experts- - Noviços co-existem com experts- - Aceitação implica contentar vários perfis

- * Usuários com necessidades especiais:- - físicas, cognitivas,etc.- - acessibilidade

145

Tarefas

� Fazem parte dos processos de trabalho (business process)

� Grande maioria das tarefas NÃO se concentram unicamente no sistema :� Manuais , Automáticas e INTERATIVAS:

� Responsabilidades dos Usuários que o sistema deve apoiar !!

� Influenciadas pelo ambiente de trabalho (configuração física) e aspectos organizacionais (papéis, dependências, etc)

146

Tecnologia Disponível

� Hardware� Software de suporte (sist.

Operacional)� Ferramentas para desenvolvimento de

IHM:� Toolkits e/ou Editores de Recursos� Estilos de Interação� Objetos de Interação

147

Estilos de Interação

� Menus (*)� Teclas Rápidas (Atalhos) (*)� Preenchimento de Formulários (*)� Linguagem de Comando� Questão/Resposta (*)� Linguagem Natural� Manipulação Direta(*)� Realidade Virtual

� Em geral vários estilos coexistem em uma

148


� Menu: lista de opções

Opções:01 - Saque02 - Extratos03 - Saldo04 - Transferências05 - Pagamentos

Entre com a opção:

Ex. 1

Ex. 2

Ex. 3

149

• seleção de itens • organização hierárquica explícita• usuários pouco treinados ou ocasionais

Menus

• atrativos• fácil treinamento

150

Menus

� Barra de Menu + Drop-down: � agrupados por função

� Cascading:� hierarquizar grupos de muitas funções� indicar existência por seta triangular 8888

� Uso deve ser minimizado� Uso PROIBIDO para comandos frequentes !!

� Pop-UP: � na posição do cursor� agrupados por objeto apontado

151


� Teclas rápidas (atalhos)� P.ex.: Microsoft POWERPOINT 97:

� ALT-E - Ativa menu Editar� ALT-A - Ativa menu Arquivo� CTRL-X - Recortar objeto selecionado� CTRL-C - Copiar objeto selecionado� CTRL-V - Colar seleção no local indicado� F7 - Verificar ortografia

152

Teclas de Atalho

ATENÇÃO: Teclas de Atalho Inconsistentes (Ver select all ) !!!

153


� Preenchimento de Formulários� formulário eletrônico similar a formulários em

papel: adequado para entrada de dados através de digitação de valores em vários campos, identificados por rótulos.

Nome: ________________________

Data de Nasc: __________________

CPF: _________________________

Curso: ________________________ 154

Formulários• excelente para aquisição de dados• exige conhecimento sobre o campo a ser preenchido• complementa o uso de menus

155

• interação baseada em comandos (ling. Imperativa)• considerável tempo de aprendizagem• alto desempenho com usuários experientes• ex.: MS-DOS, UNIX...

Linguagem de Comando

156


� Linguagem de Comando: linguagem imperativa para entrada de comandos (vocabulário limitado, sintaxe formalmente definida)� P.ex. DOS:

� dir /p� copy file.doc a:

� P.ex. UNIX� ls -l� chmod a+r *.html

157


� Questão/Resposta� Usuário deve fornecer respostas às

questões na ordem em que são solicitadas. Interação é totalmente conduzida pelo sistema.

� P.ex. Programas de instalação de nova aplicação (software) ou novo dispositivo (hardware) no Windows 95

158

Linguagem Natural

● Forma ideal de comunicação entre humanos...E entre Humanos e Computadores ?

� Linguagem Natural: usuário usa linguagem corrente, mas ainda limitada a um vocabulário exíguo e a uma sintaxe mais rigidamente definida → técnicas de Inteligência Artificial (IA)

� uso via linguagem de comandos ou reconhecimento de voz.� precisa de diálogo claro (abrev. e gírias são de difícil tratamento)� comunicação imprevisível� ex.: OS/2 Warp, Elisa, Doktor/LISP

159

Manipulação Direta

• estilo GUI ou WIMP - janela, ícones, menu, cursores, mouse

•usuário manipula diretamente representações visíveis de objetos

• estado continuamente exibido e alterações são visíveis (feedback)

• ex.: OS/Mac, Windows, Solaris, Next, Motif, etc.

160

Realidade Virtual

Uso de dispositivos para aumentar a realidade de ambientes virtuais

Interação em universos 3D

161

Objetos de InteraçãoI. Painéis de Controle 1.1 Janelas 1.2 Caixas de Diálogo

1.2.1 Fichas (folders)1.2.2 Caixas de Mensagem1.2.3 Formulários1.2.4 Paleta1.2.5 Barra de Ferramentas

II. Controles Complexos 2.1 Painel de Menu

2.1.1 Barra de Menu2.1.2 Painel de Menu Local2.1.3 Painel de Menu em Cascata2.1.4 Painel de Menu Hipertexto2.1.5 Página de Menu

2.2 Listas de Seleção 2.3 Caixas de Combinação(combo box)III. Grupos de Controle

3.1 Grupo de Botões de Rádio (radio buttons)3.2 Grupo de Caixas de Atribuição (check box)

IV. Controles Simples4.1 Grupo de Botões de Comando4.2 Controle Deslizante (escala)4.3 Calendário4.4 Interruptor4.5 Botão de Rotação4.6 Opção de Menu4.7 Item de Seleção4.8 Campo de Dado4.9 Campo de Texto4.10 Barra de Rolagem (scroll bar)

V. Mostradores5.1 Tabelas de Dados5.2 Listas5.3 Mostradores Analógicos5.4 Mostradores Digitais5.5 Mostradores de Status

VI. Orientações6.1 Caixa de Agrupamento (group box)6.2 Indicador de Progressão6.3 Bolha de Informação6.4 Rótulo (etiqueta)

162

Importância de Tarefas

� Utilidade: adequação das funções do sistema às tarefas do usuário

� Usabilidade: adequação do suporte que o sistema fornece às tarefas do usuário

� Para isto :� Conhecer o Usuário� Conhecer as Tarefas

163

Sistemas Interativos são Ferramentas

Tarefa

Usuário

Ferramenta: Transparência, Flexibilidade, Facilidade de Uso, Intuitividade no aprendizado

Núcleo Funcional

Interface

Sistema Interativo

164

Definições

� Tarefa� Modelo de Tarefa� Análise de Tarefa

165

Tarefa

� “Uma tarefa é um objetivo associado a um conjunto ordenados de ações que podem satisfazer tal objetivo nos contextos apropriados” [Storrs 95]

166

Tarefas

� Tarefa = Objetivo + Mecanismos� Ações orientadas a objetivos que um

agente (usuário ou sistema) realiza por meio de mecanismos

� Integrantes do processo de trabalho (business process)

� Conhecer o Trabalho para Modificá-lo� Análise Ergonômica do Trabalho

� Lógica de Funcionamento e de Utilização� Análise de Tarefa (Task Analysis) � Modelo de Tarefa

167

Análise de Tarefa

� “Análise de Tarefa (AT) é o termo genérico para um conjunto de métodos para descrever as tarefas das pessoas visando entender melhor os procedimentos para sua realização.[UsabGlossary]

168

Análise de Tarefa voltada a Lógica de Uso

� Lógicas do Sistema� Lógica de Funcionamento (projetistas)

� Representação baseada em aspectos internos� funções e mecanismos internos dos dispositivos,� as inter-relações entre esses mecanismos.

� Lógica de Uso ou Operação (projetistas e usuários)� Representação baseada em aspectos visívei

� na interação com os dispositivos. � nas repercussões visíveis do sistema

� Sistema é mais usável se mantém coerência com o modus operandi atual da tarefa do usuário

169

Lógica de funcionamento vs de Uso

� Exemplo

� Propor uma configuração de menus que permita manipular informações (I,R,C,A) nesta base

PRODUTO

FORNECEDOR

1..*

1..1

1..*

1..*

170

Produto

Fornecedor

InserirRemoverModificarConsultar

InserirRemoverModificarConsultar

Lógica de Funcionamento

(Visão do Analista)

Lógica de funcionamento reflete as funções internas de manipulação do BD

171

Extraído da análise da tarefa

� MUITO FREQUENTE : o usuário insere um novo produto de um novo fornecedor;

� PORTANTO deve haver um caminho a partir da inserção de produto para chegar diretamente à inserção de fornecedor ...

172

Inserir Produto

Modificar Produto

Consultar Produto

Inserir fornecedor

Remover Produto

Consultar fornecedor

Inserir/Modificar fornecedor

Consultar fornecedor

Lógica de Uso

� Organizar manipulação de produtos de acordo com a análise da tarefa

173

Modelo de Tarefa

� “Modelo de Tarefa (MT)é uma descrição lógica das atividades a serem executadas para alcançar os objetivos do usuário.”[Paternó 2001]

174

Modelo de Tarefa� Descrição das Tarefas do Usuário

para atingir um certo objetivo (com ou sem sistema)

� Componentes Básicos:� Decomposição da tarefa:

� Objetivo� Subtarefas, ações, operações

� Procedimento (relação temporal/causal entre subtarefas: seqüência, paralelismo, sincronização)

� Modelo de Tarefa vai influir diretamente no Projeto de Diálogo e indiretamente no Projeto da Apresentação !!

175

Modelo de Tarefas� Elementos Adicionais

� Condições (pré/pós) da execução� Informações relacionadas às subtarefas

(entrada/saída)� Atributos:

� freqüência (esporádica, anual, semestral, mensal, diária, constantemente usada)

� importância/prioridade� interrompível/ multitarefa

176

Análise de tarefa

� Análise (das atividades) do trabalho � Análise Hierárquica de Tarefa (ou

Planificação Hierárquica)� mais comumente usada

� Análise Cognitiva de tarefas

177

Análise Hierárquica de tarefasGoal

Goal1 Goal 2

Goal 1.1

Operation1.1.1

Operation1.1.2

Operation1.1.3

Goal 1.2 Goal 1.n

Goal n

178

Análise de tarefas

� Etapas:� Inventariar tarefas� Selecionar tarefas (+ freqüentes e/ou críticas)

� Descrever (modelar) tarefas� Validar tarefas

179

Modelagem da tarefa

� Objetivo : descrever a maneira típica utilizada pelo usuário de um determinado sistema para atingir um objetivo estabelecido� objetivo: estado final da interação

homem-sistema

� A tarefa é descrita como um conjunto de passos que podem ser seqüenciais, paralelos, entrelaçados, etc)

180

Exemplo de AHT: Making Tea

181

Exercícios

Elaborar um modelo de tarefa para:

1) preparação de um bolo de laranja

* alguém tem uma boa receita?

2) as tarefas de busca, seleção e compra de um produto on-line (e-commerce)

182

Categorias de tarefas

� Tarefa prescrita (prevista)� Oficial, presente nos treinamentos e

manuais� geralmente descrita nas entrevistas !!

� Tarefa efetiva (real)� Coletada por observação

183

Análise de Tarefa: Como Coletar?

� Técnicas de Coleta� Técnicas Baseadas em Comunicação (TBC)

� Entrevistas, Surveys, Questionários, Grupos de Foco, Contextual Inquiry

� Técnicas Baseadas em Estudo (TBE)� Estudo de Formulários e Manuais, Revisão

Bibliográfica, Análise dos Sistemas Existentes, Instantâneos de Telas

� Técnicas Baseadas em Observação (TBO)� Imersão, Observação (Direta, Verbalizada,

Seguida de Diálogo), Etnografia

184

Os diferentes modelos de tarefa

� Modelo de tarefas cognitivas do usuário (cognitive model)

� Modelos de tarefas interativas (interactive task model ou dialog model)� Sistema existente� Sistema futuro (projeção)

� Modelos de tarefas do usuário (user tasks model)� Atividade do usuário

185

Uso de modelos de tarefa

� Aumentar a compreensão (do uso) de uma aplicação

� Registrar os resultados (intermediários ou finais) de discussões multidisciplinares

� Auxiliar no design� Auxiliar na avaliação de usabilidade� Auxiliar na avaliação da eficácia e performance� Documentação

186

Notações de modelos de tarefa

� MAD (INRIA)� UAN (User Action Notation)� (a família) GOMS, KLM� CTT (Paternó)

� Diferentes notações (textual e gráfica)� Diferentes níveis de rigor� Diferentes operadores para decomposição da

tarefa

187

CTT

188

Links principais

� CTT� http://giove.isti.cnr.it/tools/CTT/home

� CTTE (Ambiente CTT):� http://giove.isti.cnr.it/tools/CTTE/home

189

Modelo de Tarefa CTT

190

ConcurTaskTrees

User Task

Interaction Task

Application Task

Abstraction Task

DescriptionIcon

Types of Tasks

T1Connection

[ T1 ]Optional [ ]

T1 *Iterative *

SyntaxDescriptionIcon

Unary Operators

T1 [] >> T2Enabling with information exchange

[] >>

T1 >> T2Enabling>>

T1 |> T2Suspend/Resume|>

T1 [> T2Disabling[>

T1 |[ ]| T2Concurrent with information exchange

|[ ]|

T1 ||| T2Concurrent|||

T1 |=| T2Order Independency|=|

T1 [] T2Choice[]

SyntaxDescriptionIcon

Temporal Relations

191

Tipos de tarefas

Interativas (interaction tasks)

Seleção

Edição

Controle

Decisão

…

Aplicação (application tasks)

Computar

Comparar

Localizar (Find)

Imprimir

...

192

Exercício

� Criar modelos de tarefa para uso de um caixa eletrônico

193

Exercício: restrições

� Inserir_Cartão, Entrar_Senha, Retirar_Cartão� Invocar_Saque, Fornecer_Valor, Retirar_Cédulas

Request_Cash Select_Amountbefore

Insert_Card Wi thdraw _Cardbefore

Enter_Code Insert_Cardjust after

andSelect_Amount

Insert_CardWi thdraw _Cashbefore

194

Exercício: tarefas

� Objetivo : Obter dinheiro ($$) � Pré-requisitos:

� Ter um cartão � Saber valor desejado� Conhecer a senha

� Resultados� Obter dinheiro� Conservar o cartão� Obter recibo

195

Exercício

196

Usos possíveis de modelos de tarefa

� Avaliar complexidade de realização de uma dada tarefa

� Otimizar o sistema para facilitar a realização de tarefas típicas (freqüentes e/ou críticas)

� MAS PRINCIPALMENTE construir um sistema de acordo com a lógica de uso e não com a lógica de funcionamento !!

197

Construir um sistema conforme a lógica de uso

� Construir um sistema de acordo com a lógica de uso e não com a lógica de funcionamento:� Definição de requisitos� Design de interfaces WIMP� Design de interfaces Web� Avaliação de interfaces

198

Requisitos (1/2)� Visão histórica: requisitos são funções � Visão atual:

� Requisitos são objetivos, funções, propriedades, restrições que o sistema deve possuir/obedecer para satisfazer contratos, padrões ou especificações de acordo com o(s) usuário(s)

� Requisito : condição (predicado) necessária para satisfazer um objetivo

Especificação: plano para uma solução Programa: solução

199

Requisitos (2/2)� Classificação de Requisitos:

� Requisitos Funcionais � O quê o sistema deve fazer : funções

e informações � Requisitos Não-Funcionais

� Requisitos de performance� Requisitos de confiabilidade e robustez� Requisitos de interação e usabilidade� Restrições para concepção

� Prioridades variam conforme a natureza do SW, o contexto de desenvolvimento e as decisões dos usuários!!

200

Suposições (implícitas) à Análise ...

� Há um problema bem definido e estável;� Especificação de Requisitos = contrato “congelado”

entre analista e cliente (≠usuário)� Cliente conhece bem seu domínio e sabe bem o que

quer : basta saber lhe interrogar corretamente� Processo linear baseado em abstrações: é possível

atingir um conjunto completo, coerente e não ambíguo de requisitos mesmo sem a participação do usuário

� Assim, Métodos de Análise são generalizações de métodos de projeto e programação

201

... Mas de fato...

� O problema a ser resolvido (e seu domínio) não é claramente delimitado nem descrito e está em constante mudança;

� Os requisitos mudam mesmo durante o desenvolvimento � O cliente não sabe bem o que quer : em geral, suas exigências

emergem ou se modificam a partir de interações com o analista e versões preliminares do sistema

� Nem sempre se chega a especificações corretas e completas: deve-se lidar com diferentes graus de incompletude e inconsistência e atribuir prioridades diferentes aos requisitos

� Engenharia de Requisitos : � Mudança de ponto de vista em relação à Análise� Enfoque sistemático para identificação e manutenção

dos requisitos

202

Ciclo da Engenharia de Requisitos

� Determinação: identificação das fontes de informação; coleta, refinamento e integração de informações

� Expressão: representação das informações obtidas; representação das várias versões dos requisitos

� Validação: avaliação da informação recolhida e representada quanto à correção, completude, coerência para o(s) usuário(s)

203

Ciclo da Engenharia de Requisitos

•Os processos de engenharia de requisitos variam de uma organização para outra, mas a maioria dos processos de Engenharia de Requisitos é composta das seguintes atividades

–Determinação: identificação das fontes de

informação; coleta, refinamento e integração de

informações

–Expressão: representação das informações

obtidas; representação das várias versões dos 204

Expressão de requisitos

o Estabelecer um conjunto de requisitos consistentes e sem

ambigüidades, que possa ser usado como base para o

desenvolvimento do software

o Deve-se classificar os requisitos em: Funcionais e não funcionais

o Para esta atividade, alguns tipos de modelos podem ser construídos

o Um modelo é uma representação de alguma coisa do mundo real,

uma abstração da realidade, e, portanto, representa uma seleção

de características do mundo real relevantes para o propósito do

sistema em questão

205

Expressão de requisitos

oModelos

o São fundamentais no desenvolvimento de

sistemas e são construídos para:

oAuxiliar no estudo do comportamento do sistema

o Facilitar a comunicação entre os componentes da

equipe e clientes e usuários

o Facilitar a discussão de correções e modificações com o

usuário

o Formar a documentação do sistema

206

Modelos e Requisitos

• Modelos auxiliam Analistas a :– Comunicar com clientes e aumentar compreensão do domínio do

problema e do sistema a ser desenvolvido– Explorar múltiplas soluções (sem implementá-las)– Permitir abstrações para gerenciar complexidade e ocultar

detalhes – Analisar os modelos para verificar se determinados requisitos e

propriedades estão presentes (ou ausentes) – Determinar como certos requisitos estão sendo derivados dos

existentes e quais artefatos correspondem a quais requisitos...

207

Casos de uso e requisitos

o Caso de uso é um documento narrativo que

descreve a seqüência de eventos de um ator (um

agente externo) que usa um sistema para completar

um processo;

o Um diagrama de Caso de Uso descreve um cenário

que mostra as funcionalidades do sistema do ponto

de vista do usuário

o O cliente deve ver no diagrama de Casos de Uso as

principais funcionalidades de seu sistema208

Casos de Uso: DICAS

Um caso de uso deve:

* cobrir TODA a sequencia de passos do INICIO ao FIM da tarefa

* Descrever a INTERAÇÃO do ator com o sistema

- NÃO as computações que o sistema executa

* Ser escrito idealmente de forma INDEPENDENTE DE TECNOLOGIA e

de DESIGN DE INTERFACE COM USUÁRIO

* Somente incluir ações em que o ator interage com o SISTEMA

(realizadas através do sistema)

- NÃO ações realizadas manualmente

209

Tipos de casos de uso• Casos de uso são informais• Podem ser usados a vários níveis de abstração• Conteúdo pode ser adequado às necessidades da aplicação

• Tipos de casos de uso– Preliminar (ou alto-nível)

• Conceitual, abstrato e pouco detalhado (independente de implementação)• usados na especificação de requisitos e delimitação de escopo no início da

análise

– Essencial (ou expandido)• Conceitual (independente de implementação)• Detalhado em termos de funcionalidade

– Real (ou concreto)• Concreto (dependente de tecnologia)• Detalhado em termos de funcionalidade, comportamento (operação) e

referências a interface 210

Caso de Uso Preliminar

Diagrama de Caso de Uso Preliminar(trecho mostrando apenas 1 ator)

• Formato Textual BásicoCaso de Uso : Encomenda ProdutoAtores : ClienteDescrição : Cliente solicita produtos presentes no catálogo, fornecendo seu código e a quantidade desejada. Cliente escolhe forma de entrega e de pagamento. Lista de produtos encomendados é exibida ao Cliente que confirma (ou não) a encomenda.

Encomenda Produto

Consulta Catálogo

Cliente

Altera Encomenda

211

Caso de Uso Preliminar

Diagrama de Caso de Uso Preliminar

• Formato Textual Básico Caso de Uso : Altera Encomenda Atores : ClienteDescrição : Cliente altera dados da encomenda efetuada previamente por

ele. Os dados que podem ser alterados são: endereço de entrega do produto, produto(s) encomendados, quantidade(s) de produto(s), DESDE QUE a encomenda não esteja sendo entregue. Nova encomenda é exibida ao Cliente e este confirma (ou não) a (nova) encomenda. Se não confirmar, continua valendo a antiga encomenda.

Encomenda Produto

Consulta Catálogo

Cliente

Altera Encomenda

212

Gráfico sobre Níveis de Casos de Uso

Fonte: Cockburn, A. Escrevendo Casos de Uso Eficazes, Bookman, 2004

213

(Um) Formato de Escrita de Casos de Uso

A. Nome significativo, iniciando por Verbo

B. Atores : o iniciador e os participantes

C. Objetivos que os atores querem atingir

D. Pré-condições: estado antes do caso de uso

E. Resumo: Descrição sucinta (1 parágrafo) e informal

F. Passos

G. Pós-condições: estado após caso de uso

Os elementos mais importantes são A, B e F

214

Descrição dos passos de caso de uso (essencial)

Sistema mostra estar Pronto para Uso

Cliente Identifica-se Verifica Identificação

Fornece Opções de Operações

Cliente Seleciona Saque Verifica Opção Selecionada

Solicita Valor de Saque

Cliente Fornece Valor Verifica se valor é válido

Verifica saldo do Caixa Eletrônico

Verifica saldo disponível na C. Corrente

Processa Saque

Disponibiliza Cédulas

Disponibiliza Recibo

Cliente Retira Cédulas e Recibo Encerra Saque

215

O Processo de Escrita de Casos de Uso

1. Especifique o escopo e os limites do sistema.

2. Faça brainstorming e liste os atores primários (humanos ou não) do sistema.

3. Faça brainstorming e liste exaustivamente os objetivos dos atores com o sistema.

4. Capture os casos de uso preliminares para cada ator primário.

5. Revise os casos de uso preliminares.

6. Selecione um caso de uso para expandir (criando o formato essencial)

7. Capture os stakeholders e interesses, pré-condições e garantias.O sistema assegurará as pré-condiçoes e garantirá os interesses.

8. Escreva o cenário de sucesso principal (CSP).Use de 3 a 9 passos para satisfazer todos interesses e as garantias.

9. Faça brainstorming e liste exaustivamente as condições de extensão.

10. Escreva os passos de tratamento de extensão.Cada um terminará voltando para o CSP, em uma saída de sucesso separada, ou na falha.

11. Refatore: Decomponha em sub casos de uso; junte sub casos de uso triviais.

12. Reajuste o conjunto: Verifique a legibilidade, integridade, e satisfação dos interesses dos stakeholders.

216

Casos de uso alternativos

• Percorrer o caso de uso básico em busca de – ações alternativas ou optativas (casos de uso

alternativos)– possibilidades de erro, obstáculos e singularidades

(casos de uso de exceção: E se ...?– ações que se repetem em diversos cenários (casos de

uso extensão)

217

Exemplo de Identificação de Caso de Uso Alternativo

ID dasingula-laridade

ID doepisódioonde a sin-gularidadeacontece

ID da açãodo episódioonde a sin-gularidadeacontece

Problema Singularidade(Causa do problema)

Ações (D)efensivas ou(C)orretivas

S09 EP3 3 Valor de saque incorreto Cliente entrou com valoresincorretos

(C) Notificar o cliente epermitir escolher o valor,novamente

S10 EP3 3 Valor de saque nãoescolhido

Cliente não entra com ovalor de saque a tempo(timeout)

(C) Notificar o cliente eretornar ao estado inicial,à pré-condição do episódio

S11 EP3 4 Dinheiro insuficiente O valor do saque escolhidoexcede a quantia disponívelno caixa eletrônico

(C) Informar o cliente daquantia disponível epermitir que escolha estaquantia

S12 EP3 5 Saldo Insuficiente O valor do saque escolhidoexcede o saldo da conta docliente

(D) Exibir o saldo daconta do cliente(C) Notificar o cliente epermitir escolher o valor,novamente

S13 EP3 8 Transação não confirmada Cliente não confirma atransação a tempo (timeout)

(C) Notificar o cliente eretornar ao estado inicial,à pré-condição do episódio

218

Casos de Uso Essenciais� Descrevem Casos de Uso de Alto Nível de forma

independente de tecnologia� Representação de Intenções do ator e

Responsabilidades do sistema� Caso de Uso normal: a história “normal” das

atividades e do término bem-sucedido de um processo; descreve a seqüência típica de eventos� Podem originar Casos de Uso Alternativos além do

“Normal”, que envolvem ações alternativas ou opcionais� Podem originar subseções de exceção (uma para cada

desvio) ou ações repetidas na seqüência típica de eventos do caso de uso Normal

� Possibilidades de erro, obstáculos e singularidades (casos de uso de exceção: E se ...?

219

Exemplo de caso de uso “normal”: Realizar Saque

Sistema Pronto para Uso

Cliente Identifica-se Verifica Identificação

Fornece Opções de OperaçõesCliente Seleciona Saque Verifica Opção Selecionada

Solicita Valor de SaqueCliente Fornece Valor Verifica se valor é válido

Verifica saldo do Caixa Eletrônico

Verifica saldo disponível para saque da Conta Corrente

Processa SaqueDisponibiliza Cédulas e Recibo

Cliente Retira Cédulas e Recibo Encerra Saque

Intenções do Usuário (a partir de MT):

Responsabilidades do Sistema

220

Aplicando Casos de Uso: Roteiro

• Analisar Processos de Negócio

• Identificar Atividades a serem realizadas por um sistema computadorizado

• Listar funções do sistema, definir fronteiras, identificar atores e casos de uso

• Escrever todos casos de uso em um formato Preliminar

• Desenhe diagrama de casos de uso preliminares

• Refine os casos de uso mais críticos e/ou freqüentes no formato Essencial expandido; postergue os demais se preciso até a fase de projeto

221

Modelos de tarefa para Design de Interfaces

� Requisitos do Sistema:� Sistemas raramente são construídos

para suportar tarefas iguais às atuais

� Requisitos determinam:� mudanças nas tarefas e no suporte a elas� aspectos de tarefas que não devem mudar

222


� Nova tarefa� Tarefa do sistema: Interativa ou

automática� Criada a partir do modelo de tarefas

atuais como um processo de re-design, de acordo com os requisitos

� Projeção explícita permite exploração e avaliação de alternativas de concepção

� Geralmente representada na mesma notação da tarefa atual

223


� Heurísticas para Projetar novas tarefas� Delimitar o escopo de concepção:

� Re-engenharia de tarefas : eliminar tarefas desnecessárias mas não reduzir o que atualmente é possível

� Identificar as tarefas do usuário e do sistema� Melhorar o trabalho

� Identificar sequências que podem ser facilitadas � Identificar informações usadas conjuntamente� Ser mais eficiente e mais simples de realizar que a

tarefa atual

224


� Sistematização da construção de um protótipo que será exercitado até versão final

� Processo guiado pelas informações obtidas na Análise Contextual:� Das tarefas atuais a novas tarefas� De novas tarefas a um modelo abstrato de

interface� Do modelo abstrato de interface a um protótipo

Novas Tarefas

Modelo abstrato

de Interface

Protótipo

Projeto de Interfaces

225


� Modelo Abstrato de Interface� Descrição de alto nível da interface � Apresentação: Unidades de

Apresentação mas não definição final da aparência

� Diálogo: Sequências de Interação mas não detalhes de comportamento

� Comparável ao modelo de alguns enfoques baseados em modelos (model-based) para design de interfaces

226


� Protótipo� Representação Concreta do sistema proposto� Implementação do modelo abstrato da interface� Composto por objetos de interação (widgets),

com comportamento, aparência e sequência de uso definidas

� Pode ser descrito em papel (p.ex. storyboards) ou ser executável, possivelmente gerado automaticamente

227

Design da Interface

� Do Modelo de Tarefas à IU:� Projeto de Diálogo:

� definir o diálogo de alto nível (inter UAs)� definir o diálogo de baixo nível (intra UAs)

� Projeto da Apresentação� definição de unidades de apresentação (UA)� seleção dos objetos de interação dentro das UAs� respeito a princípios, recomendações e normas

ergonômicos� limitada às opções tecnológicas disponíveis

228


Diálogo de Alto Nível

Unidades de Apresentação

Diálogo de Baixo Nível

Estilos de Interação e Objetos de Interação

Modelo Abstrato da Interface

Protótipo

Projeto de Diálogo Projeto de Apresentação

229

Design da Interface (visão geral)

Modelo de Tarefas

Projeto deApresentação

Projeto deDiálogo

Proj. DiálogoAlto Nível

Definir UAs

Proj. DiálogoBaixo Nível

Selecionar Estilose Objetos de Interação

Recomendaçõese NormasErgonômicas

OpçõesTecnol.Disponíveis

Modelo.deUsuário

230

Design da Interface

� Do Modelo de Tarefas à IU:� Projeto de Diálogo:

� definir o diálogo de alto nível (inter UAs)� definir o diálogo de baixo nível (intra UAs)

� Projeto da Apresentação� definição de unidades de apresentação (UA)� seleção dos objetos de interação dentro das UAs� respeito a princípios, recomendações e normas

ergonômicos� limitada às opções tecnológicas disponíveis

231

Design da Interface

� Projeto de Diálogo� Objetivo: especificar os comandos do usuário,

as técnicas de interação, as respostas da IU (feedback e mensagens), seqüências de comandos disponíveis na IU durante a realização das tarefas.

� Características dinâmicas da IU: seqüência entre ações, iniciativas do usuário e do sistema, caminhos possíveis, etc

� Deve ser conduzido pelo modelo de tarefas do usuário para refletir o modo do usuário de realizar a tarefa

232

Design da Interface

� Projeto da Apresentação� Seleção de estilos e de objetos de

interação� Uso de heurísticas de projeto e/ou guias

de estilo e respeito às normas, recomendações e plataformas existentes (Motif, Windows,etc)

� Características da IU: layout, organização e atributos como fontes e cores…

233

Design de Interface

� ``A combo box is a text box with an attached, integrated and interdependent list. Combo boxes are useful when the application requires user input and can display a list of possible responses. The user can type a response in the text box if the correct one is not available in the list. .'' (The Windows Interfaces: An Application Design Guide, p.114).

234

Knowndomain:

Number of pos-sible values

∈[2,3]


∈[4,7]


∈ [8,50]


∈ ]50,+∞[

Projeto de Apresentação a partir do MT : seleção de objeto de interação para tarefa

235

� Operador « Desactivation ». As tarefas devem ser próximas para mostrar a correlação

Projeto de Apresentação a partir de operadores temporais do MT

236

Projeto de Apresentação a partir de operadores temporais do MT

� Operador « Escolha » (T1[] T2)

237

Design da Interface

UA-1

UA-2

UA-3

UA-4

UA-5

UA-6 Legenda:

UA(Tela Miniatura)

Evento

E1

E4E2

E3

E6

E7

E5

Lista de Eventos:E1 - Tecla F1 (físico)E2 - On enter (lógico)E3 - CPF-OK (semântico)E4 - ...

� Definição do diálogo de alto nível (inter UAs): Flipbook� UAs podem ser seqüenciais ou simultâneas� Eventos podem ser acionados por usuários ou pela aplicação

238

� Tarefas concorrentes (|[]|) são apresentadas umas às outras

Projeto de Diálogo a partir de operadores temporais do MT

239

� Operador « Activation » (T1>>T2)� Exemple :

� Uma opção de menu

desabilitada


240

� Operador « Activation e troca de informações » ([]>>). � Tarefas podem (ou não) ser apresentadas na

mesma janela


Jo*

Submit

Name:

Name AgeJohansen 52Jones 27Joxibon 18

Jo*

Submit

Name:

Age:

Name AgeJohansen 52Jones 21

Results:

>20

Results:

Situation 1 Situations 2 and 3

241

Design de Interface� Respeito a Recomendações e Normas Ergonômicas:

� Considerações sobre configuração (layout,cores, disposição,etc) dos objetos de Interação

� Recomendações refletem experiência acumulada por pesquisadores de IHC� Exemplo: Recomendações do LabiUtil

� http://www.labiutil.inf.ufsc.br/ergolist/rec.htm� Normas: elaboradas por Institutos de Padronização Oficiais

� Exemplo: Normas da ISSO, ABNT, etc

242

Respeito a recomendações e

normas ergonômicas

� Normas de usabilidade ISO � ISO 9126 -Características de qualidade� ISO 9241 - Ergonomia de Soft. Escritórios

� Voltada a Trabalho de escritório informatizado� Contexto: tipos particulares de usuários, tarefas,

ambientes e tecnologia).� É prevista uma sistemática para definir a aplicabilidade

das recomendações.� ISO 11581 - Ícones - Design� ISO 14915 - Multimídia IU Design� ISO 14598 - Projeto de Avaliação

243

Norma ISO-9241

� Parte 1: Introdução geral.� Parte 2: Condução quanto aos requisitos das tarefas.� Parte 3: Requisitos dos terminais de vídeo.� Parte 4: Requisitos dos teclados.� Parte 5: Requisitos posturais e do posto de trabalho.� Parte 6: Requisitos do ambiente.� Parte 7: Requisitos dos terminais de vídeo quanto as

reflexões.� Parte 8: Requisitos dos terminais de vídeo quanto as

cores.� Parte 9: Requisitos de dispositivos de entrada, que não

sejam os teclados. 244

Norma ISO-9241

� Parte 10: Princípios de diálogo - IS/EN� Parte 11: Especificação da usabilidade - IS/EN.� Parte 12: Apresentação da informação - FDIS.� Parte 13: Condução ao usuário - IS/EN.� Parte 14: Diálogo por menu - IS/EN.� Parte 15: Diálogo por linguagem de comandos - IS/EN.� Parte 16: Diálogo por manipulação direta - FDIS.� Parte 17: Diálogo por preenchimento de formulários -

FDIS.� Obs.:

� IS/EN: Norma Internacional e Européia aprovada� FDIS: Versão final da norma para votação

245

Exemplo 1 de recomendaçãoParte 14 - Diálogo por Menu

� Opção defaulta) Opção mais freqüente - Se a freqüência da seleção de

opção é conhecida e uma das opções tem uma maior probabilidade de seleção que as outras.

b) Opção precedente - Para tarefas repetitivas, o cursor deveria ser colocado sobre a opção no grupo que foi a última selecionado pelo usuário .

c) Primeira opção - Se a repetição da seleção de opção não é considerada importante e não se conheça a frequência de seleção.

d) Opção menos destrutiva - o cursor deveria ser colocado na opção menos destrutiva do grupo.

246

Exemplo 2 de recomendaçãoParte 14 - Diálogo por Menu

� Levando para outro painel ou caixa de diálogo

Indicações consistentes devem ser fornecidas ao usuário caso uma opção leve para outro painel ou para uma caixa de diálogo (em vez de executar uma ação).

EXEMPLO: uma seta (>) apontando para a direita no final do rótulo da opção para indicar outro painel.

EXEMPLO: Reticências (...) poderiam ser utilizadas para indicar outro dialogo.

247

Exercício 1� Trabalhar em duplas� Criar um modelo de tarefa visando desenvolvimento de um sistema de

agendamento (incluindo proposição, marcação e confirmação) de reuniões

� Pensar em:� como configurar agendas dos membros e da ocupação dos locais� permitir formação de agendas de grupos� permitir consulta a agendas individuais, de grupos e de outrem� proposição de reuniões (data/hora, local, membros obrigatórios, pauta, etc.)

� marcação exige confirmação dos participantes� divulgação e atualização de agendas após agendamento

� Discussão com a turma e o professor

248

Exercício 2� Definir grupos de 2 ou 3 alunos� O objetivo final do trabalho que inicia por esta tarefa é a prototipação

de parte de um interface.Nesta tarefa você e seu grupo devem realizar o que segue:a) Escolha um sistema com o qual esteja trabalhando ou aquele usado

para o exercício 1b) Descreva os usuários típicos desse sistema.c) Descreva duas tarefas de usuário que o sistema suporta. Cuide para

escolher uma tarefa de um nível razoavelmente baixo para que o seu detalhamento posterior não seja muito complexo. Por exemplo, cadastro de um cliente, agendamento de atendimento.

d) Descreva os cenários de uso do sistema para ambas as tarefas.


249

Exercício 3

� Qual o modelo de tarefa para o voto eletrônico no Brasil?� Simulador da Urna Eletrônica Brasileira:

� http://www.tse.gov.br/eleicoes/urna_eletronica/simulacao_votacao/UrnaApplet2.htm


250




3) Qual o contexto de realização destas tarefas?

Análise Contextual

251


4) Quais comandos e ações o usuário pode realizar através da interface?


Projeto da Interface� Projeto de Diálogo� Projeto da Apresentação

252


6) Como provocar as críticas/sugestões dos usuários a respeito da interface projetada?


253


7) O sistema e sua interface suportam adequadamente as tarefas dos usuários?

Avaliação

254

Técnicas de Avaliação de Interfaces

� Verificação sem participação de Usuário(s)� baseada na confrontação com princípios, guidelines,

recomendações e normas ergonômicas � baseada no julgamento do avaliador (avaliação heurística)� baseada em modelos formais

� Validação com Participação de Usuário(s)� baseada na opinião do(s) usuário(s) sobre a interação � baseada em análise de dados comportamentais� baseada em experimentos controlados

(ensaios de interação)

255

Verificação Baseada na confrontação com princípios, guidelines, recomendações e normas

� Listas de verificação� Inspeções formais de Conformidade

� Normas ISO de Usabilidade

� Checklists informais� ErgoList (LabiUtil/UFSC - Brasil)

� http://www.labiutil.inf.ufsc.br/ergolist/check.htm� PUTQ

256

Avaliação Heurística � Avaliadores julgando a interface baseados em seu

conhecimento empírico e/ou em heurísticas (ou ainda critérios ergonômicos)

� Heurísticas de Nielsen (Nielsen, 1994)� Como conduzir a avaliação heurística:

http://www.useit.com/papers/heuristic/heuristic_evaluation.html

� Dez heurísticas de usabilidade http://www.useit.com/papers/heuristic/heuristic_list.html

� Critérios Ergonômicos� (Scapin & Bastien, 1993) Ver definições precisas e detalhes em

http://www.labiutil.inf.ufsc.br/ergolist/check.htm

257

Avaliação Heurística

� Procedimento :� Durante uma sessão de avaliação, o avaliador usa a

interface várias vezes e avalia os vários elementos de diálogo e de apresentação, comparando-os com as heurísticas e/ou cirtérios adotados como referência

� Avaliadores� Especialistas em IHC (ou assessorados

por)� 5 avaliadores acham 75% dos problemas

(Nielsen)

258

Avaliação Heurística [ Heurísticas ]

H1) Dar feedback;

H2) Falar a linguagem do usuário;

H3) Concepção minimalista

H4) Ser consistente;

H5) Diálogos simples e naturais;H6) Controle explícito do usuário

H7) Fornecer atalhos;

H8) Boas mensagens de erro;

H9) Prevenir erros;

H10) Ajuda e documentação.

259

Heuristicas (Nielsen) (1/3)

� Dar feedback: Visibilidade do estado do sistema� O sistema deve sempre manter o usuário informado do que está

acontecendo, através de feedback em tempo razoável.

� Falar a linguagem do usuário: compatibilidade entre o vocabulário do sistema e o do domínio � O sistema deve conter termos usuais do domínio do problema e da

prática de trabalho do usuário, ao invés de termos orientados a sistema.

� Concepção minimalista� Diálogos não devem conter informação irrelevante ou raramente

necessária. Toda unidade de informação extra compete com as unidades de informação realmente relevantes e diminui sua visibilidade.

260

� Ser consistente � Usuários devem usar os mesmos comandos, termos e ações para

situações similares no sistema.

� Diálogos simples e naturais � Tornar objetos, ações e opções visíveis. O usuário não deve necessitar

lembrar informações de outra parte do diálogo. Instruções para uso do sistema devem ser visíveis ou facilmente encontráveis quando necessárias.

� Controle explícito do usuário � Usuários muitas vezes se enganam e necessitam ter controle sobre a

aplicação para abandonar um estado indesejado sem um diálogo extenso. Suporte a “undo” e “redo” é importante.

� Fornecer atalhos: Flexibilidade e eficiência de uso� Aceleradores - embora indiferentes para os usuários novatos, podem servir

muito ao usuário mais experiente.

Heurísticas (Nielsen) (2/3)

261

� Boas mensagens de erro� Ajudar usuários a reconhecer, diagnosticar e corrigir erros; Mensagens

de erro devem ser expressas em texto claro (sem códigos), indicando precisamente o problema e sugerindo construtivamente possibilidades de correção.

� Prevenir erros� Uma concepção cuidadosa (“concepção defensiva”) é melhor do do

que prover boas mensagens de erro.

� Ajuda e documentação � Mesmo que o melhor seja o sistema ser utilizável SEM documentação,

é necessário prover ajuda (on-line) e documentação consistentes uma com a outra.

Heurísticas (Nielsen) (3/3)

262

Critérios Ergonômicos(Scapin&Bastien, 1993)

� Condução� Carga de Trabalho� Controle do Usuário� Adaptabilidade� Gestão de Erros� Significado dos Códigos e Denominações� Homogeneidade/Consistência� Compatibilidade

263

Exercício de avaliação

� Simulador da Urna Eletrônica Brasileira: http://www.tse.jus.br/eleicoes/eleicoes-

anteriores/eleicoes-2010/eleicoes-2010/eleicoes-2010-simulacao-de-votacao

� Realizar uma avaliação heurística INDIVIDUAL rápida, anotando:

� Problema, situação em que aparece, heurística/critério violada(o)

� Comparar com os problemas encontrados com o colega ao lado


264

Métodos de avaliação para Interfaces

� Avaliação Heurística;� Ensaios de Interação;� Inspeção de regras ergonômicas (guidelines e

checklist);� Questionários;� Relatos de Incidentes Críticos

265

Avaliação Heurística (1/5)

� Desenvolvido por Nielsen e Molich (1993);

� Princípio de base: julgamento do avaliador.

� Inspeção sistemática de um protótipo guiada por um conjunto restrito de 10 heurísticas;

266

Avaliação Heurística (2/5)[ Heurísticas ]

H1) Diálogos simples e naturais;

H2) Falar a linguagem do usuário;

H3) Minimizar a sobrecarga de memória do usuário;

H4) Ser consistente;

H5) Dar feedback;

H6) Saídas claramente marcadas;

H7) Fornecer atalhos;

H8) Boas mensagens de erro;

H9) Prevenir erros;

267

Avaliação Heurística (3/5)[ Procedimento ]

� 3 - 5 avaliadores inspecionam a interface em seções individuais;

� problemas identificados são classificados c/ relação à severidade e à(s) heurística(s) infringida(s);

� compilação dos resultados individuais:� Há intersecções mas muitos problemas

disjuntos !!!

268

Descrição do problema: Na obra “O tempo e o Vento” o botão [crítica]é disponível mas, uma vez selecionado, não mostra o texto correspondente à crítica do livro, como esperado.

Severidade (1-3): 3

Heurística violada: Dar feedback (H5).

Avaliação Heurística (4/5)[ Exemplo: (CD-ROM Literatura Gaúcha; Nemetz, 1997) ]

269

Avaliação Heurística (5/5)[ Comentários ]

+ método simples;

+ qualquer pessoa pode ser treinada (!!!);

+ relação custo X benefício;

- resultados dependem da experiência do avaliador

- não cobre todos os tipos de problemas...

270

Ensaios de Interação (1/6)

� Observação de usuários durante a realização de tarefas;

� Necessita de um laboratório de usabilidade para registrar as sessões de teste;

� Usuários realizam tarefas predefinidas;

� Thinking aloud protocol p/ estimular comentários dos usuários;

271

Ensaios de Interação (2/6)[ Laboratórios de usabilidade ]

http://labiutil.inf.ufsc.br/

• Som e vídeo da seção

• Sala com espelhos falsos;

• Registros de logs;

http://www.microsoft.com/usability/tour.htm 272

Ensaios de Interação (3/6)[ Thinking Aloud Protocol ]

� Consiste em estimular o usuário à falar tudo o que está pensando;

� Permite coletar informações subjetivas;

� Deve-se evitar induzir, intimidar, ou dar respostas ao usuário;

� Não é uma atividade natural para usuários;

� Exige treinamento para boa utilização do método.

273

Ensaios de Interação (4/6)[ Etapas ]

� Obtenção da amostra de usuários� Ajustes nos cenários� Planejamento� Execução (Registro e Coleta dos

Dados)� Análise e interpretação dos dados

obtidos� Redação do relatório do ensaio

274

Ensaios de Interação (5/6)[ Roteiro ]

� Convidar usuários para os testes;� Preparar sala antes e deixar usuário

confortável;� Explicar propósito da avaliação;� Aplicar pré-questionário;� Fornecer lista de tarefas e observar a

execução das mesmas;� Pós-questionário ou entrevista;� Agradecer e recompensar participantes.

275

Ensaios de Interação (6/6)[ Comentários ]

+ Análise de tarefas por usuários reais;

+ Identificação dos problemas mais graves;

- Alto custo de realização;

- Necessita de um laboratório de usabilidade (!!!)

- Avaliador precisa de treinamento adequado.

276

Inspeção de regras ergonômicas (1/7)

� Regras ergonômicas descrevem o conhecimento sobre usabilidade;

� Tais regras são usadas para guiar a concepção ou a avaliação

� Avaliação consiste da inspeção sistemática onde se verificar se as regras são respeitadas;

� Vários conjuntos de regras são disponíveis, de acordo com o tipo de aplicação;

� Guidelines tem centenas de regras...

277

Inspeção de regras ergonômicas (2/7)[ Exemplos de regras ]

� Selecione cuidadosamente os títulos de páginas. Use nomes que estejam relacionados com o conteúdo ou função da página. (Fonte: Nielsen, 1999)

� Páginas iniciais, que suportam navegação, que devam ser lidas rapidamente ou, que contenham gráficos grandes, devem ser curtas. Usar páginas longas para simplificar a manutenção do site e tornar as páginas mais fáceis de imprimir. (Fonte: Lynch e Hortson, 1999)

278

Inspeção de regras ergonômicas (3/7)[ Exemplo: Guidelines para acessibilidade ]


279

http://www.labiutil.inf.ufsc.br/ergolist/

Inspeção de regras ergonômicas (4/7)[ Exemplo: Ferramenta auxiliar inspeção ]

ErgoList

280

Inspeção de regras ergonômicas (5/7)[ Outros exemplos de guidelines para Web ]

� « Os 10 maiores erros de Design para Web », Nielsen

http://www.useit.com/alertbox/990530.html

� “Web Design & usability guidelines“, NCI – National Cancer Institute

281

� Forma de questionário que deve ser respondido por um avaliador;

� Fácil realização;� Focaliza pontos específicos a verificar

na interface;� Resultados limitados aos critérios

definidos no roteiro.

Inspeção de regras ergonômicas (6/7)[ Checklist ]

282

Inspeção de regras ergonômicas (7/7)[ Exemplo: Checklist p/ e-shopping ]

(fonte: Information & Design http://www.infodesign.com.au).

283

Questionários (1/4)

� Usados para obter informações dos usuários;

� Bons resultados na obtenção de informações subjetivas, ex. preferências;

� Baixo custo de realização; � Exige um avaliador experiente para

identificar problemas; � Pode ser aplicado à distância;

284

Questionários (2/4)[ Tipos ]

� Identificação do perfil do usuário:� Múltiplas características dos usuários;

� Grau de satisfação do usuário:� Wammi - http://www.wammi.com/

� Estruturar descrições de problemas:� Cenários de uso:

� (problema + objetivo + ações);

285

Questionários (3/4)[ Identificação do perfil do usuário]

� Categorias: � Identificação funcional; (Ex. profissão)� Informações pessoais; (Ex. idade)� Configuração do computador; (Ex. S.O.)� Experiência c/ computadores; (Ex. uso

h/semana)� Uso da internet; (Ex. freqüência de impressão)� Questões específicas sobre o site;

286

Questionários (4/4)[ Grau de satisfação do usuário]

� Wammi p/ Web;� Desenvolvido a partir do QUIS (Kirakowisk, (1988)� Disponível em vários idiomas, inclusive em

português;� Ferramenta comercial...� Útil apenas p/ avaliar satisfação subjetiva;� Resultados não explicam os problemas.

287

Relatos de Incidentes Críticos (1/4)

� Consiste em analisar descrições de incidentes críticos relatados espontaneamente por usuários;

� Incidente crítico (IC) é uma descrição de uma situação de uso que pode esconder um problema de usabilidade;

� Geralmente informações poucos estruturadas;� Descrevem situações reais de uso.

288

Relatos de Incidentes Críticos (2/4)[ Dados que auxiliam a identificar problemas c/ ICs ]

� Início e fim do IC;� Tarefa e objetivo do usuário antes do

IC;� Expectativa do usuário antes do IC;� Freqüência do IC;� Como evitar um IC;� Sugestões do usuário para resolver o

IC.

289

Relatos de Incidentes Críticos (3/4)[ Cenários de Uso p/ estruturar ICs ]

� Usuários podem ser treinados para estruturar ICs na forma de cenários de uso:� objetivo � problema � ações

290

Relatos de Incidentes Críticos (4/4)

+ Fácil coleta de dados;

+ Baixo custo;

+ Descrevem problemas que usuários enfrentam;

- Exige habilidade p/ interpretar ICs;

- Depende da boa vontade dos usuários em descrever ICs.

291

Roteiro para Avaliação [ Recomendações ]

� Regra n° 1 – A “melhor” avaliação não substitui os cuidados para evitar problemas de usabilidade;

� Regra n° 2 - Avaliações periódicas devem ser realizadas;

� Regra n° 3 – Documentação é a palavra-chave para a boa condução do projeto;

� Regra n° 4 – Investir na capacitação das pessoas mesmo aquelas que não estão diretamente relacionadas à avaliação;

� Regra n° 5 – Utilizar mais de um método de avaliação;

292

QuartaParte

293

Roteiro





294

Conclusion

� Start somewhere

� Plan to apply at least one of these ideas to your current and/or next project.

� Identifying users and their tasks is most important

295

Conclusion yet� More Technology is not enough: usability need

awareness !!� Usability awareness will potentially increase... :

� More we use systems, more we need usability !!

� In Brazil, good news...� More HCI courses in Computer Science curricula

� UFRGS since 1993 ;-) � Special Interest Group (Comissão Especial) in Brazilian Computer Society

since 2000� More professionals , more companies

296

Links Interessantes

Usabilidade:useit.comusableweb.comlabiutil.inf.ufsc.br

HCI Bibliography hcibib.orginteraction-design.org

297

Fim

Dúvidas?

Obrigado!

298

[email protected]

Marcelo Soares PimentaInstituto de Informática (INF)-UFRGS

http://www.inf.ufrgs.br/~mpimenta

Ou google me “ Marcelo Pimenta ” ...

Informação de contato...

Documents

Conteúdo - Instituto de Informáticampimenta/Cursos/Notas-aula-BR-Salv-jan-2012.pdf · Design de Interfaces com Usabilidade Marcelo S. Pimenta ([email protected] ) Salvador,