Primeira Parte. Conteúdo. Bibliografia (em português) Design de Interfaces com Usabilidade. Marcelo S. Pimenta

Transcrição

1 Conteúdo Design de Interfaces com Usabilidade Marcelo S. Pimenta 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 Salvador, janeiro de Bibliografia (em português) Preece, J. et alli, Design da Interação Além da Interface Homem-Computador, Bookman, 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, Cybis, Walter; Betiol, Adriana H.; Faust, Richard. Ergonomia e Usabilidade - Conhecimentos, Métodos e Aplicações. Novatec, 2010 (2a. ed.) Primeira Parte 3 4

2 Roteiro Interação em Toda a Parte I Motivação II Fundamentos: IHC, Usabilidade III Usabilidade: Como Desenvolver Software Usável? IV Conclusões 5 6 Importância de IHC (1/3) 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 (2/3) 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 7 8

3 Importância de IHC (3/3) 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 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 9 10 Usabilidade Definitions: What is Usability? 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 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

4 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?? 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." 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: 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 severidade Tipo 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 Information Technology Services 15 16

5 Usabilidade é importante? Usabilidade é importante? Exemplos de problemas Exemplos de problemas

6 Exemplos de problemas Exemplos de problemas Exemplos de problemas Exemplos de problemas USA Internacional 23 24

7 Exemplos de problemas Exemplos de problemas Onde achar Portuguese? Acima ou abaixo? Exemplos de problemas Exemplos de problemas

8 Types of Usability Problems Usabilidade: problema genérico 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 Problemas em Interfaces em geral: NÃO somente em Software!!! Don Norman, The Design of Everyday Things Usability of Everyday Objects Don who? Examples from Further Reading: Donald Norman: The Design (Psychology) of Everyday Things 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

9 Usability Problem Example: Inconsistent 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 Métricas para medir usabilidade? How usable? 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) Spectrum Not Is your system usable, but How usable is your system? Can set minimum standards to meet (time, error rate, user satisfaction) 35 36

10 Usability is about money too Usability is shaped by the UI but usability is much deeper than UI Usabilidade tem futuro!! Revista INFO-Exame Setembro, 2007 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

11 Roteiro I Motivação Segunda Parte II Fundamentos: IHC, Usabilidade III Usabilidade: Como Desenvolver Software Usável? IV Conclusões IHC: Interface e Interação IHC: Interface e Interação ação sistema Interface: aquilo que interliga dois sistemas software e hardware para comunicação entre o usuário e um sistema usuário interface aplicação interpretação Alan Kay: For users, the user interface is the program 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 43 44

12 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 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) IHC: Objetos e Funções de uso geral Modelo de Norman 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) 47 48

13 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? Arquitetura e Comportamento Sistema Interativo = Núcleo Funcional (Aplicação)+ Interface Comportamento (Modelo de Norman): Componente de Diálogo N. Funcional Componente de Apresentação Interface atividade Linguagem de Ação Linguagem de Apresentação Formulação Usuário Avaliação computador como ferramenta Interação Humano- Computador (IHC): evolução Usabilidade 60 s e 70 s: Sist.em batch 80 s e 90 s: Interação Usuário-sistema Hoje: Integração Usuários-Sistemas via Internet Usuário Usuário Usuário CPD Sistema Internet Sistema Sistema Usuário Sistema 51 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 52

14 Usabilidade 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) 53 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) 54 Usabilidade 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 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 ) 55 56

15 Métricas para medir usabilidade? Desempenho durante a realização de tarefas: Conclusão de tarefas (c/ sucesso, parcialmente concluída, nãoconcluí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) 57 Q: What makes something usable? A: It depends Traditional Criteria: ease of learning efficient/ergonomic use minimal errors retention over time subjective satisfaction Some Technology Factors: de facto standards display factors (eg screen size) interactions of software and hardware 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 Individual Differences All users are not the same! We think about homogeneous target user groups Distinguishing between individual and group differences is not easy 58 Usability Goals What about Acessibility? Usability Goals are always Tradeoffs, and can conflict with one another Rapid learning Safety/error constraint Subjective satisfaction for novices Low power Awkward/extra steps Extreme irritation for experts Many design guidelines exist that claim to ensure usability 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 "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 59 60

16 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 Experimento IHC2002: Pimenta et alli. A (in)acessibilidade de sites governamentais, Fortaleza, Sites governamentais analisados GOVERNO FEDERAL: SEESP: INPA: GOVERNO ESTADUAL: PROCON/RS : GOVERNO MUNICIPAL: PREFEITURA DE PoA: Plataforma e Navegadores Exemplos de problemas NAVEGADORES SIS TE MA S OP ER ACI ON AIS E Internet Explorer X Netscape 63 64

17 Exemplos de Problemas EXEMPLO 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". W3C Acessibility Initiative 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 sites Alertar e conscientizar os desenvolvedores Pequenas correções para adequação Maior Divulgação de Recomendações Básicas (como Quick Tips to make Accessible Web Sites da W3C) Maior divulgação de ferramentas Mais avaliações e divulgação de resultados Acessibilidade RECOMENDAÇÕES W3C "Web Content Accessibility Guidelines Todos os pontos de prioridade 1, alguns de 2 e 3 FERRAMENTAS P.ex. Para validar XHTML/HTML de um website no W3c: USO EM DIVERSOS NAVEGADORES E PLATAFORMAS 67 68

18 Guidelines para acessibilidade Acessibility problem: example Devices x platforms x browsers browser1 X browser Acessibility initiative and tools Brazilian: Ação Brasileira para a Acessibilidade - ABRA Acessibility Guidelines Universal: W3C Acessibility Initiative "Web Content Accessibility Guidelines Tools Bobby

19 HCI background Cognitive Psychology Human Factors (Ergonomics) Graphic Design Semiotics Execution gulf Semantic Distance input Articulatory Distance input Semantic Distance output Articulatory Distance output Evaluation gulf H side of HCI ;-) Roteiro I Motivação Terceira Parte II Fundamentos: IHC, Usabilidade III Usabilidade: Como Desenvolver Software Usável? IV Conclusões 75 76

20 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!!!! HCI: focus is on USAGE PRODUCT * 1..* SUPPLIER Try to do it: Menu design for CRUD functions What about YOU???? DID you know HCI issues? Developer s View User s View (system-oriented) Menu basically reflects internal DB operations Product Fornecedor Insert Delete Update Retrieve Insert Delete Update Retrieve (usage-oriented) Menu basically reflects frequent tasks when user manipulates Product Insert Product Retrieve Supplier Insert Supplier Retrieve Product Update Product Retrieve Supplier Insert/Update Supplier Delete Product 79 80

21 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. UCD Summary Know Your Users!! Talk to them Get feedback from them Know the Users Tasks!! Design for user Value of User-Centred Design? 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 The Standish CHAOS report (1994): Red = success Green = completed, over-budget/time, under-functional Yellow = cancelled 83 84

22 Value of User-Centred Design? 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. 85 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!) 86 Activities for Designing Usable Systems (quick view) Activity One: Planning Planning Design Implementation Maintenance Evaluation and Test Maintenance Evaluation Planning You can use an eraser on the drafting table or a sledge hammer on the construction site. - Frank Lloyd Wright Design 87 88

23 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 Planning: Identify contextual information 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: 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) 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 91 92

24 Planning: Development Team A 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 Activity 2 - Design Any object or element of the interface that does not add to communication is subtracting from it. -Bruce Tognazzini Design Iterative process Apply guidelines and heuristics Prototyping: Paper prototypes -> Review with users On-line prototypes -> Review with users Interaction Design Interaction design refers to the various controls (or widgets ) that the user must manipulate in using the system Interaction Design is closely related to industrial (physical) design (See Donald Norman s book, The Design of Everyday Things) Three Key Principles: Affordances Features of an object that convey how it is to be used Constraints Attributes of an object that prevent its incorrect use, or prevent errors Mapping The arrangement of controls for an object that has natural spatial meaning 95 96

25 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? Affordances Poor affordances Doors Push or Pull? Where to push? Good affordances Buttons that appear clickable Constraints Mappings Restrict user actions to valid actions Eliminate need for perfect knowledge Recognition over recall Good constraints are rarely noticed 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 PREVIOUS NEXT

26 Mappings Natural mappings: no explanations needed Available actions 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. User intentions Perceived system state -Zen and the Art of Web Design Actual system state Implementation Follow Design Guidelines and Style Guides Consider: Devices idiosyncrasies Cross-platform issues Browser differences Accessibility issues Consistency Consistency Look and feel Style guides Same operation has same effect on different objects, screens

27 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 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 Activity 4 - Evaluation If the user can t find it, it isn t there! 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

28 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. Activity Five: Maintenance Do maintenance thinking in the next maintenance... Your maintenance budget should be as honest as possible 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 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)

29 Ciclo de Concepção Ergonômica de Interfaces 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 113 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) 114 Ciclo de Concepção Ergonômica de Interfaces 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 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?

30 Atividades da Concepção 1) Quais são os usuários? 2) Quais tarefas serão suportadas? 3) Qual o contexto de realização destas tarefas? 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 Análise Contextual restrições tecnológicas Contexto Instável: Cenários de Uso: situações típicas, singularidades: exceções, erros, interrupções, desvios 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. 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

31 EXERCÍCIO Análise Contextual: Tarefas 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!! 121 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 122 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 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

32 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, Atividades da Concepção 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? Projeto da Interface Projeto de Diálogo Projeto da Apresentação Seguida de Diálogo), Etnografia Atividades da Concepção 6) Como provocar as críticas/sugestões dos usuários? Prototipação/Maquetagem 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

33 Prototipação/Maquetagem 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 Prototipação/Maquetagem 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 Atividades da Concepção 7) O sistema e sua interface suportam adequadamente as tarefas dos usuários? Avaliação 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

34 SW Interativo: Tipos de Concepção Concepção Tradicional Concepção Tradicional (Engenharia de Software) Concepção Centrada no Usuário Concepção Integrada 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 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 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

35 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 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 Integração de Engenharia de Software e IHC Concepção Integrada usa Prototipação/Maquetagem Ciclo de Experimentação/Avaliação/Revisão: Fatores de Qualidade e Requisitos para Sistemas Interativos Fator de Qualidade Requisitos Área Utilidade Funcionais Engenharia de Software (ES) Usabilidade Comportamentais IHC Desenvolvimento de sistemas interativos úteis e usáveis Integração de conceitos, modelos, técnicas e ferramentas de ES e IHC 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

36 Concepção Integrada usa Prototipação/Maquetagem Aspectos Envolvidos 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 - Usuários - Tarefas - Tecnologia Disponível Maquete: versão simplificada da interface sem funcionalidade, somente com navegação Usuários (1/2) Usuários (2/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: - * 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: Pânico Necessidade de atalhos experiente mediano novato leigo físicas, cognitivas,etc. - - acessibilidade

37 Tarefas Tecnologia Disponível 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) 145 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 146 Estilos de Interação 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 Ex. 1 Menu: lista de opções Ex. 3 Ex. 2 Opções: 01 - Saque 02 - Extratos 03 - Saldo 04 - Transferências 05 - Pagamentos Entre com a opção: Em geral vários estilos coexistem em uma

38 Menus seleção de itens organização hierárquica explícita usuários pouco treinados ou ocasionais atrativos fácil treinamento Menus Barra de Menu + Drop-down: agrupados por função Cascading: hierarquizar grupos de muitas funções indicar existência por seta triangular 8 Uso deve ser minimizado Uso PROIBIDO para comandos frequentes!! Pop-UP: na posição do cursor agrupados por objeto apontado Estilos de Interação Teclas de Atalho 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 ATENÇÃO: Teclas de Atalho Inconsistentes (Ver select all)!!!

39 Estilos de Interação 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. Formulários excelente para aquisição de dados exige conhecimento sobre o campo a ser preenchido complementa o uso de menus Nome: Data de Nasc: CPF: Curso: Linguagem de Comando interação baseada em comandos (ling. Imperativa) considerável tempo de aprendizagem alto desempenho com usuários experientes ex.: MS-DOS, UNIX... Estilos de Interação 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

40 Estilos de Interação 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 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 Manipulação Direta Realidade Virtual 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. Uso de dispositivos para aumentar a realidade de ambientes virtuais Interação em universos 3D

41 Objetos de Interação Importância de Tarefas I. Painéis de Controle 1.1 Janelas 1.2 Caixas de Diálogo Fichas (folders) Caixas de Mensagem Formulários Paleta Barra de Ferramentas II. Controles Complexos 2.1 Painel de Menu Barra de Menu Painel de Menu Local Painel de Menu em Cascata Painel de Menu Hipertexto 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 Simples 4.1 Grupo de Botões de Comando 4.2 Controle Deslizante (escala) 4.3 Calendário 4.4 Interruptor 4.5 Botão de Rotação 4.6 Opção de Menu 4.7 Item de Seleção 4.8 Campo de Dado 4.9 Campo de Texto 4.10 Barra de Rolagem (scroll bar) V. Mostradores 5.1 Tabelas de Dados 5.2 Listas 5.3 Mostradores Analógicos 5.4 Mostradores Digitais 5.5 Mostradores de Status VI. Orientações 6.1 Caixa de Agrupamento (group box) 6.2 Indicador de Progressão 6.3 Bolha de Informação 6.4 Rótulo (etiqueta) 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 Sistemas Interativos são Ferramentas Definições Tarefa Sistema Interativo Núcleo Funcional Interface Tarefa Modelo de Tarefa Análise de Tarefa Usuário Ferramenta: Transparência, Flexibilidade, Facilidade de Uso, Intuitividade no aprendizado

42 Tarefa Tarefas Uma tarefa é um objetivo associado a um conjunto ordenados de ações que podem satisfazer tal objetivo nos contextos apropriados [Storrs 95] 165 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 166 Análise de Tarefa Análise de Tarefa voltada a Lógica de Uso 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] 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

43 Lógica de funcionamento vs de Uso Lógica de Funcionamento Exemplo PRODUTO * 1..* FORNECEDOR Propor uma configuração de menus que permita manipular informações (I,R,C,A) nesta base (Visão do Analista) Lógica de funcionamento reflete as funções internas de manipulação do BD Produto Fornecedor Inserir Remover Modificar Consultar Inserir Remover Modificar Consultar Extraído da análise da tarefa Lógica de Uso 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... Organizar manipulação de produtos de acordo com a análise da tarefa Inserir Produto Consultar fornecedor Inserir fornecedor Consultar Produto Modificar Produto Consultar fornecedor Inserir/Modificar fornecedor Remover Produto

44 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] 173 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!! 174 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 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

45 Análise Hierárquica de tarefas Análise de tarefas Goal 1.1 Goal Goal1 Goal 2 Goal 1.2 Goal 1.n Goal n Etapas: Inventariar tarefas Selecionar tarefas (+ freqüentes e/ou críticas) Descrever (modelar) tarefas Validar tarefas Operation Operation Operation Modelagem da tarefa Exemplo de AHT: Making Tea 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)

46 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 (ecommerce) Categorias de tarefas Tarefa prescrita (prevista) Oficial, presente nos treinamentos e manuais geralmente descrita nas entrevistas!! Tarefa efetiva (real) Coletada por observação 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 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

47 Uso de modelos de tarefa Notações 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 185 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 186 CTT Links principais CTT CTTE (Ambiente CTT):

48 Modelo de Tarefa CTT ConcurTaskTrees Icon * [ ] Types of Tasks Icon Iterative Optional Description Abstraction Task Application Task Interaction Task User Task Unary Operators Description Connection Syntax T1 * [ T1 ] T1 Temporal Relations Icon [] = [ ] [> > >> [] >> Description Choice Order Independency Concurrent Concurrent with information exchange Disabling Suspend/Resume Enabling Enabling with information exchange Syntax T1 [] T2 T1 = T2 T1 T2 T1 [ ] T2 T1 [> T2 T1 > T2 T1 >> T2 T1 [] >> T Tipos de tarefas Exercício Interativas (interaction tasks) Seleção Edição Controle Decisão Criar modelos de tarefa para uso de um caixa eletrônico Aplicação (application tasks) Computar Comparar Localizar (Find) Imprimir

49 Exercício: restrições Exercício: tarefas Inserir_Cartão, Entrar_Senha, Retirar_Cartão Invocar_Saque, Fornecer_Valor, Retirar_Cédulas Request_Cash Sel ect_amount and Insert_ Ca rd Insert_Card En te r_co de be fore be fore be fore just after Select_Amount Withdraw _Cash Withdraw _Card Insert_Ca rd 193 Objetivo : Obter dinheiro ($$) Pré-requisitos: Ter um cartão Saber valor desejado Conhecer a senha Resultados Obter dinheiro Conservar o cartão Obter recibo 194 Exercício 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!!

50 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 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 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!! 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

51 ... 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 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) 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 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 obtidas; representação das várias versões dos

52 Expressão de requisitos omodelos osão fundamentais no desenvolvimento de sistemas e são construídos para: o Auxiliar no estudo do comportamento do sistema ofacilitar a comunicação entre os componentes da equipe e clientes e usuários ofacilitar a discussão de correções e modificações com o usuário 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... o Formar a documentação do sistema Casos de uso e requisitos Casos de Uso: DICAS ocaso 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 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) principais funcionalidades de seu sistema NÃO ações realizadas manualmente 208

53 Tipos de casos de uso Caso de Uso Preliminar 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 209 Diagrama de Caso de Uso Preliminar (trecho mostrando apenas 1 ator) Cliente Encomenda Produto Consulta Catálogo Formato Textual Básico Altera Encomenda Caso de Uso: Encomenda Produto Atores: Cliente Descriçã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. 210 Caso de Uso Preliminar Gráfico sobre Níveis de Casos de Uso Diagrama de Caso de Uso Preliminar Encomenda Produto Consulta Catálogo Formato Textual Básico Cliente Caso de Uso: Altera Encomenda Altera Encomenda Atores: Cliente Descriçã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. Fonte: Cockburn, A. Escrevendo Casos de Uso Eficazes, Bookman,

54 (Um) Formato de Escrita de Casos de Uso Descrição dos passos de caso de uso (essencial) A. Nome significativo, iniciando por Verbo Sistema mostra estar Pronto para Uso 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 Cliente Identifica-se Cliente Seleciona Saque Cliente Fornece Valor Cliente Retira Cédulas e Recibo Encerra Saque Verifica Identificação Fornece Opções de Operações Verifica Opção Selecionada Solicita Valor de Saque 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 Os elementos mais importantes são A, B e F O Processo de Escrita de Casos de Uso Casos de uso alternativos 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. 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) 12. Reajuste o conjunto: Verifique a legibilidade, integridade, e satisfação dos interesses dos stakeholders

55 ID da singulalaridade ID do episódio onde a singularidade acontece Exemplo de Identificação de Caso de Uso Alternativo ID da ação do episódio onde a singularidade acontece Problema Singularidade (Causa do problema) S09 EP3 3 Valor de saque incorreto Cliente entrou com valores incorretos S10 EP3 3 Valor de saque não escolhido Cliente não entra com o valor de saque a tempo (timeout) S11 EP3 4 Dinheiro insuficiente O valor do saque escolhido excede a quantia disponível no caixa eletrônico S12 EP3 5 Saldo Insuficiente O valor do saque escolhido excede o saldo da conta do cliente S13 EP3 8 Transação não confirmada Cliente não confirma a transação a tempo (timeout) Ações (D)efensivas ou (C)orretivas (C) Notificar o cliente e permitir escolher o valor, novamente (C) Notificar o cliente e retornar ao estado inicial, à pré-condição do episódio (C) Informar o cliente da quantia disponível e permitir que escolha esta quantia (D) Exibir o saldo da conta do cliente (C) Notificar o cliente e permitir escolher o valor,novamente (C) Notificar o cliente e retornar ao estado inicial, à pré-condição do episódio 217 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...? 218 Exemplo de caso de uso normal : Realizar Saque Aplicando Casos de Uso: Roteiro Intenções do Usuário (a partir de MT): Cliente Identifica-se Cliente Seleciona Saque Cliente Fornece Valor Cliente Retira Cédulas e Recibo Sistema Pronto para Uso Verifica Identificação Fornece Opções de Operações Verifica Opção Selecionada Solicita Valor de Saque Verifica se valor é válido Verifica saldo do Caixa Eletrônico Verifica saldo disponível para saque da Conta Corrente Processa Saque Disponibiliza Cédulas e Recibo Encerra Saque Responsabilidades do Sistema 219 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 220

56 Modelos de tarefa para Design de Interfaces Modelos de tarefa para Design de Interfaces Requisitos do Sistema: Nova tarefa 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 221 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 222 Modelos de tarefa para Design de Interfaces Modelos de tarefa para Design de Interfaces 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 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 223 Projeto de Interfaces 224

57 Modelos de tarefa para Design de Interfaces Modelos de tarefa para Design de Interfaces 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 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 Diálogo: Sequências de Interação mas não detalhes de comportamento Comparável ao modelo de alguns enfoques baseados em modelos (modelbased) para design de interfaces 225 Pode ser descrito em papel (p.ex. storyboards) ou ser executável, possivelmente gerado automaticamente 226 Design da Interface Modelos de tarefa para Design de Interfaces 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) Diálogo de Alto Nível Unidades de Apresentação Modelo Abstrato da Interface 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 Diálogo de Baixo Nível Estilos de Interação e Objetos de Interação Protótipo 227 Projeto de Diálogo Projeto de Apresentação 228

58 Design da Interface (visão geral) Modelo de Tarefas Proj. Diálogo Alto Nível Proj. Diálogo Baixo Nível Projeto de Diálogo Recomendações e Normas Ergonômicas Definir UAs Selecionar Estilos e Objetos de Interação Projeto de Apresentação Modelo. de Usuário Opções Tecnol. Disponíveis 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 Design da Interface Design da Interface Projeto de Diálogo Projeto da Apresentação 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 231 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 232

59 Design de Interface Projeto de Apresentação a partir do MT : seleção de objeto de interação para tarefa ``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). Known domain: Number of possible values [2,3] Number of possible values [4,7] Number of possible values [8,50] Number of possible values ]50,+ [ Projeto de Apresentação a partir de operadores temporais do MT Projeto de Apresentação a partir de operadores temporais do MT Operador «Desactivation». As tarefas devem ser próximas para mostrar a correlação Operador «Escolha» (T1[] T2)

60 Design da Interface UA-1 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 E1 E2 UA-2 UA-3 E4 UA-5 Lista de Eventos: E1 - Tecla F1 (físico) E2 - On enter (lógico) E3 - CPF-OK (semântico) E Projeto de Diálogo a partir de operadores temporais do MT Tarefas concorrentes ( [] ) são apresentadas umas às outras E3 E5 UA-4 E6 UA-6 Legenda: E7 UA (Tela Miniatura) Evento Projeto de Diálogo a partir de operadores temporais do MT Operador «Activation» (T1>>T2) Exemple : Uma opção de menu desabilitada Projeto de Diálogo a partir de operadores temporais do MT Operador «Activation e troca de informações» ([]>>). Tarefas podem (ou não) ser apresentadas na mesma janela Situation 1 Situations 2 and 3 Name: Jo* Results: Name Age Johansen 52 Jones 27 Joxibon 18 Submit Name: Age: Jo* >20 Submit Results: Name Age Johansen 52 Jones

61 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 Normas: elaboradas por Institutos de Padronização Oficiais Exemplo: Normas da ISSO, ABNT, etc 241 Respeito a recomendações e normas ergonômicas Normas de usabilidade ISO ISO Características de qualidade ISO 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 Ícones - Design ISO Multimídia IU Design ISO Projeto de Avaliação 242 Norma ISO-9241 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. 243 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 244

62 Exemplo 1 de recomendação Parte 14 - Diálogo por Menu Exemplo 2 de recomendação Parte 14 - Diálogo por Menu Opção default a) 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. 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 Exercício 1 Exercício 2 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 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 1 b) 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. Discussão com a turma e o professor Discussão com a turma e o professor

63 Exercício 3 Qual o modelo de tarefa para o voto eletrônico no Brasil? Simulador da Urna Eletrônica Brasileira: naapplet2.htm Atividades da Concepção 1) Quais são os usuários? 2) Quais tarefas serão suportadas? 3) Qual o contexto de realização destas tarefas? Discussão com a turma e o professor Análise Contextual Atividades da Concepção Atividades da Concepção 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 a respeito da interface projetada? Projeto da Interface Projeto de Diálogo Projeto da Apresentação Prototipação/Maquetagem

64 Atividades da Concepção Técnicas de Avaliação de Interfaces 7) O sistema e sua interface suportam adequadamente as tarefas dos usuários? Avaliação 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) 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) PUTQ 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: Dez heurísticas de usabilidade heuristic/heuristic_list.html Critérios Ergonômicos (Scapin & Bastien, 1993) Ver definições precisas e detalhes em

65 Avaliação Heurística Avaliação Heurística [ Heurísticas ] 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) 257 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. 258 Heuristicas (Nielsen) (1/3) Heurísticas (Nielsen) (2/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. 259 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. 260

66 Heurísticas (Nielsen) (3/3) 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. 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 Exercício de avaliação Simulador da Urna Eletrônica Brasileira: 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 Discussão com a turma e o professor 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

67 Avaliação Heurística (1/5) Avaliação Heurística (2/5) [ Heurísticas ] 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; 265 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; 266 Avaliação Heurística (3/5) [ Procedimento ] Avaliação Heurística (4/5) [ Exemplo: (CD-ROM Literatura Gaúcha; Nemetz, 1997) ] 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!!! 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)

68 Avaliação Heurística (5/5) [ Comentários ] Ensaios de Interação (1/6) + 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 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; 270 Ensaios de Interação (2/6) [ Laboratórios de usabilidade ] Ensaios de Interação (3/6) [ Thinking Aloud Protocol ] Som e vídeo da seção Sala com espelhos falsos; Registros de logs; 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. 272

69 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 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 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. 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

70 Inspeção de regras ergonômicas (2/7) [ Exemplos de regras ] Inspeção de regras ergonômicas (3/7) [ Exemplo: Guidelines para acessibilidade ] 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) Inspeção de regras ergonômicas (4/7) [ Exemplo: Ferramenta auxiliar inspeção ] Inspeção de regras ergonômicas (5/7) [ Outros exemplos de guidelines para Web ] ErgoList «Os 10 maiores erros de Design para Web», Nielsen html Web Design & usability guidelines, NCI National Cancer Institute 280

71 Inspeção de regras ergonômicas (6/7) [ Checklist ] Inspeção de regras ergonômicas (7/7) [ Exemplo: Checklist p/ e-shopping ] 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. (fonte: Information & Design 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; 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 - Estruturar descrições de problemas: Cenários de uso: (problema + objetivo + ações); Pode ser aplicado à distância;