Interação Humano-Computador

Apresentação em tema: "Interação Humano-Computador"— Transcrição da apresentação:

1 Interação Humano-Computador
IHC Interação Humano-Computador aula 09 aula 01

2 Tópicos Usabilidade Engenharia de Usabilidade
IHC x Engenharia de Software Requisitos Requisitos de Interface HC Guidelines Heurísticas de Nielsen

3 Usabilidade Usabilidade é a extensão na qual um produto pode ser usado por usuários específicos para alcançar objetivos específicos com efetividade, eficiência e satisfação em um contexto de uso específico. Ou seja, a usabilidade de um sistema é um conceito que se refere à qualidade da interação de sistemas com os usuários e depende de vários aspectos. Avaliamos a usabilidade entendendo os fatores que levam a uma maior ou menor usabilidade em um contexto de uso específico.

4 Usabilidade Facilidade em Aprender
A 1ª experiência com um sistema é a de aprender a usá-lo. Tem ligação direta com a distância semântica Comportamento freqüente dos usuários ao aprender: Os usuários não despendem tempo suficiente para aprender a interface antes de iniciar seu uso. Começam a usar o sistema assim que aprendem a utilizar parte da interface.

5 Usabilidade Facilidade em Usar
Um sistema pode ser fácil de aprender mas não ser fácil de usar! Ou seja, você até sabe o que deve fazer, mas o esforço de execução é grande. Tem ligação direta com a distância articulatória Facilidade de uso compreende: O esforço cognitivo necessário para interagir com o sistema A quantidade de vezes em que o objetivo pretendido é atingido pelas ações desencadeadas pelo usuário (taxa de acerto)

6 Usabilidade Facilidade em Rememorar
Ter uma interface fácil de lembrar é importante para usuários que usam eventualmente um sistema. Memorização de uma interface raramente é testada como os outros atributos de usabilidade.

7 Usabilidade Eficiência de Uso
Refere-se ao tempo exigido para executar as tarefas levando em consideração usuários experientes no uso sistema. Deve-se decidir o nível de experiência que caracteriza um usuário “experiente”.

8 Usabilidade Flexibilidade
Permitir que os usuários façam as mesmas coisas de formas diferentes Importante quando usuários do sistema possuem diferenças significativas

9 Usabilidade Poucas falhas e não catastróficas
Falha é qualquer evento que impeça o atingimento do objetivo desejado. Falha catastrófica é aquela que destroe o trabalho do usuário, tornando difícil a recuperação.

10 Usabilidade Satisfação subjetiva
Diz respeito a quanto o sistema é “agradável” na avaliação do usuário. É importante para sistemas que envolvem o lazer e entretenimento.

11 Engenharia de Usabilidade
Engenharia de Usabilidade, também chamada de Design Centrado no Usuário, está diretamente relacionada com: Entendimento de quem são os usuários Entendimento das tarefas dos usuários Envolvimento dos usuários no design da interface Envolvimento dos usuários na avaliação da interface

12 Engenharia de Usabilidade
Pré-design Análise do perfil dos usuários Análise do contexto da tarefa Análise das capacidades e restrições das plataformas Análise competitiva Especificação das metas de usabilidade Design Design Inicial Técnicas participativas Guidelines Desenvolvimento Interativo Técnicas de antecipação Avaliação Pós-design Avaliação no campo

13 Engenharia de Usabilidade
Pré-design Análise do perfil dos usuários Análise do contexto da tarefa Análise das capacidades e restrições das pataformas Análise competitiva Especificação das metas de usabilidade Design Design Inicial Técnicas participativas Guidelines Desenvolvimento Interativo Técnicas de antecipação Avaliação Pós-design Avaliação no campo Entendimento Projeto e Avaliação contínua Avaliação final (teste)

14 Pré-design Análise do perfil dos usuários:
Para cada tipo de usuário previsto, os desenvolvedores devem conhecer seus atributos pessoais (faixa etária, sexo, limitações físicas, motivação) e suas habilidades e competências (na tarefa, na organização e com sistemas informatizados). Análise do contexto da tarefas: Para cada tarefa a ser apoiada pelo sistema, os desenvolvedores devem conhecer os objetivos e resultados, a estrutura, a duração, as dependências, os custos, a carga mental, etc.

15 Pré-design Análise das capacidades e restrições da plataforma:
Devem ser examinadas as possibilidades e restrições em termos de equipamentos, estilos de interação, sistemas operacionais, recursos de rede, etc. Análise competitiva: Aprender com os produtos existentes Observar pontos de melhoria em produtos existentes

16 Pré-design Especificação das metas de usabilidade:
Características de interface que devem ser implementadas de modo a melhor satisfazer o tipo de usuário, a tarefa e a plataforma especificados. Definição de metas quantitativas para a usabilidade: Facilidade em aprender Facilidade em usar Facilidade em rememorar Eficiência de uso Flexibilidade Poucas falhas e não catastróficas Satisfação subjetiva

17 Design Design Inicial Técnicas participativas
Entrevistas, reuniões, workshops, brainstorms, observação, etc. Guidelines Para guiar o projetista no sentido de sugerir uma interface HC que atenda aos requisitos de usabilidade, podemos lançar mão de uma série de orientações (guidelines)

18 Design Desenvolvimento Interativo Técnicas de antecipação
Procuram tornar as idéias acerca do design visíveis aqueles que participam do processo: wireframes, esboços, storyboards, mapas de navegação, protótipos Avaliação

19 Pós-design Avaliação no campo Obter dados para nova versão
Registro de reclamações Log de sessões Observação Avaliar impacto do produto no trabalho (produtividade, qualidade, etc.)

20 Técnicas de Antecipação
Wireframes

21 Técnicas de Antecipação
Esboços

22 Técnicas de Antecipação
Storyboard

23 Técnicas de Antecipação
Storyboard

24 Técnicas de Antecipação
Mapas navegacionais

25 Técnicas de Antecipação
Prototipos (alta fidelidade e baixa fidelidade)

26 Técnicas de Antecipação
Prototipos (alta fidelidade e baixa fidelidade)

27 IHC x Engenharia do Software
Os diversos aspectos da interface humano-computador vistos anteriormente não podem ser tratados de forma isolada do contexto de desenvolvimento de sistemas de software. Conceitos relacionados a usabilidade e acessibilidade são apenas alguns dos critérios de qualidade a serem avaliados. No desenvolvimento de softwares reais os requisitos funcionais não podem ser negligenciados. Afinal softwares são construídos para desempenhar alguma função útil para um indivíduo ou organização. É preciso estar ciente que os critérios de aceitação de um software englobam várias perspectivas e essas perspectivas precisam ser tratadas de forma integrada: Utilidade (funcionalidades) Usabilidade Confiabilidade Acessibilidade ...

28 IHC x Engenharia do Software
Entretanto, como integrar essas perspectivas ? Tratar as questões relacionadas à interface HC no contexto das metodologias de desenvolvimento de software. O projeto da interface faz parte do projeto do software ! Do ponto de vista da interface HC, é preciso entender as demandas existentes no contexto do desenvolvimento de um software específico.

29 IHC x Engenharia do Software
Por exemplo, com relação à interface: O software deve ser projetado de tal forma que pessoas com deficiência visual possam explorar todas as suas funcionalidades. O usuário deve acionar no máximo 3 links para chegar a qualquer uma das funcionalidades do software. A consulta ao cadastro de inadimplentes deve estar acessível tanto a partir do navegador do desktop quanto do navegador de um smartphone com as mesmas informações. O software deve disponibilizar acesso direto às funcionalidades mais acessadas pelo usuário a partir da tela principal. O que são essas demandas afinal de contas ?

30 IHC x Engenharia do Software
Por exemplo, com relação à interface: O software deve ser projetado de tal forma que pessoas com deficiência visual possam explorar todas as suas funcionalidades O usuário deve acionar no máximo 3 links para chegar a qualquer uma das funcionalidades do software. A consulta ao cadastro de inadimplentes deve estar acessível tanto a partir do navegador do desktop quanto do navegador de um smartphone com as mesmas informações. O software deve disponibilizar acesso direto às funcionalidades mais acessadas pelo usuário a partir da tela principal. O que são essas demandas afinal de contas ? Requisitos e como tal, devem ser tratados juntamente com os outros requisitos.

31 IHC x Engenharia do Software
Dessa forma, o tratamento de questões relacionadas à interface HC passam, obrigatoriamente, pelo entendimento desses requisitos dentro de um contexto que trate também todos os demais requisitos do software. Ao tratarmos todos os requisitos de forma integrada temos a possibilidade de entender a relevância de cada um deles para os usuários. Lembre-se: os usuários avaliam o software sob diversas perspectivas e tratar parte delas sem ter o entendimento do que é relevante é um risco. Mas como identificar o que é relevante para os usuários ?

32 IHC x Engenharia do Software
Dessa forma, o tratamento de questões relacionadas à interface HC passam, obrigatoriamente, pelo entendimento desses requisitos dentro de um contexto que trate também todos os demais requisitos do software. Ao tratarmos todos os requisitos de forma integrada temos a possibilidade de entender a relevância de cada um deles para os usuários. Lembre-se: os usuários avaliam o software sob diversas perspectivas e tratar parte delas sem ter o entendimento do que é relevante é um risco. Mas como identificar o que é relevante para os usuários ? Entender quem são os usuários Entender qual a utilidade do software para eles (requisitos funcionais) Entender os demais critérios que restringem as possíveis soluções (requisitos não funcionais) Questões relacionadas à interface HC se enquadram aqui !

33 IHC x Engenharia do Software
Traçando um paralelo entre essa visão e aquela proposta pela Engenharia da Usabilidade, temos: Engenharia de Usabilidade Engenharia de Requisitos Conhecer o usuário: características pessoais, físicas e cognitivas, motivações, etc. Conhecer todos aqueles que tem algum interesse no sistema (inclusive os usuários), denominados stakeholders Entender as tarefas do usuário Entender o propósito do sistema e as funcionalidades esperadas Entender as possibilidades e restrições tecnológicas Estabelecer metas de usabilidade Entender os requisitos não funcionais que impõem determinadas características ou restrições ao software (usabilidade é um desses critérios) Guidelines - Técnicas de antecipação Métodos participativos Várias técnicas em comum, iterações pequenas com avaliações frequentes, algumas técnicas de métodos ágeis

34 Requisitos No nosso dia-a-dia estamos o tempo inteiro trabalhando com requisitos, mesmo sem nos darmos conta disso: Quando planejamos comprar algo e definimos que características gostaríamos de obter do novo produto. Quando estamos planejando uma viagem de férias. Quando desejamos contratar um serviço e estabelecemos os critérios que nos satisfazem. Quando escolhemos onde fazer um curso (preço, horário, ementa, qualidade dos professores, etc). Quando contratamos um empregado. Podemos, então, dizer que sem estabelecer os requisitos não temos como decidir sobre o que comprar ou contratar, ou seja, não temos parâmetros para avaliar se aquele produto ou serviço é adequado às nossas necessidades.

35 Requisitos Requisitos de software:
Um requisito é uma característica do produto ou a descrição de algo que ele é capaz de realizar, para atingir os seus objetivos.

36 Requisitos Classificação dos Requisitos: Funcionais
Estão diretamente ligados as funcionalidades do produto, ou seja, descrevem as funções que o produto deve desempenhar. Um requisito funcional descreve uma interação entre o produto e o seu ambiente. Exemplos: “O sistema deve disponibilizar para os funcionários CLT um formulário eletrônico para solicitação de férias” “O sistema deve permitir que os pacientes remarquem suas consultas” “O sistema deve enviar semanalmente, via , um relatório de acompanhamento dos processos de indenização”

37 Requisitos Classificação dos Requisitos: Não-funcionais
Expressam condições que o produto deve atender ou características específicas que o mesmo deve ter. Impõem restrições ao produto. Exemplos: “As consultas devem ser realizadas usando o protocolo HTTPS” “As consultas on-line devem ser respondidas em no máximo 3 segundos” “O usuário deve ser capaz de realizar a operação de cadastramento em menos de 2 minutos”

38 Requisitos Podemos também classificar os requisitos sob duas perspectivas: Estruturais: descrevem características estáticas relacionadas com os conceitos existentes no sistema e seus relacionamentos. Independem dos processos ou funcionalidades implementados pelo sistema. Exemplos: “O formulário de cadastramento deve solicitar o nome, cpf, data de nascimento e do usuário” “Na lista de produtos apresentada ao usuário deve haver uma opção para excluir todos os produtos” “Os links da página devem ser apresentados em cores contrastantes para facilitar a utilização dos usuários com problemas visuais” “Todas as enquetes devem ser apresentadas em uma área isolada das demais informações da página” “Os campos obrigatórios dos formulários devem ser apresentados com uma cor diferente dos campos não obrigatórios”

39 Requisitos Comportamentais: descrevem características relacionadas com a dinâmica do sistema, ou seja, expressam o comportamento esperado do sistema. Devem estar associados a um ou mais processos ou funcionalidades imlementados pelo sistema. Exemplos: “A nota final do aluno é calculada como a média aritmética das provas 1 e 2” “Ao apresentar o resultado da consulta de produtos, o sistema deve apresentar, no máximo, 10 produtos de cada vez” “O sistema deve solicitar o cpf do usuário apenas se ele tiver mais de 18 anos na data corrente” “O nome e o cpf do cônjuge é obrigatório somente se o estado civil do funcionário é casado” “A opção de enviar só deve estar habilitada se o usuário preencher o nome, e a reclamação”

40 Requisitos Juntando essas duas classificações temos:
Focando na questão das interfaces HC temos: Dentre os requisitos funcionais existem os requisitos funcionais relacionados à interface HC. Dentre os requisitos não-funcionais existem os requisitos de usabilidade, acessibilidade, etc. São esses requisitos que iremos tratar daqui por diante. Perspectiva Requisitos Funcionais Requisitos Não-Funcionais Definem características e necessidades Definem restrições Estrutural Características relacionadas com a estrutura Restrições que podem afetar tanto a estrutura quanto o comportamento do sistema Comportamental Características relacionadas com o comportamento

41 Requisitos de Interface
Requisitos funcionais de interface HC: Estruturais: Definem diagramação da interface. Definem estilos relacionados ao look-and-feel da interface. Definem os elementos da interface gráfica a serem utilizados. ... Dinâmicos: Definem condições para acesso à informação. Definem condições para a entrada das informações.

42 Requisitos de Interface
Requisitos funcionais de interface HC: Estruturais: Definem diagramação da interface. Definem estilos relacionados ao look-and-feel da interface. Definem os elementos da interface gráfica a serem utilizados. ... Dinâmicos: Definem condições para acesso à informação. Definem condições para a entrada das informações. Podem ser representados com maior ou menor grau de fidelidade através das técnicas de antecipação São difíceis de serem representados fielmente, pois necessitam da implementação desses comportamentos

43 Requisitos de Interface
Requisitos não-funcionais de interface HC: Com relação à usabilidade, existe um conjunto de atributos que definem essa característica e que são normalmente usados na definição dos requisitos: Facilidade em aprender Facilidade em usar Facilidade em rememorar Eficiência de uso Rapidez com que se consegue atingir o objetivo Flexibilidade Poucas falhas e não catastróficas Satisfação subjetiva Entretanto, o uso desses atributos na definição dos requisitos é problemático...

44 Requisitos de Interface
Como escrever os requisitos de usabilidade ? Imagine no contexto de um sistema de caixa eletrônico exista um requisito descrito como: “o sistema deve ser fácil de aprender” Esse tipo de requisito é de pouca utilidade pois não informa: Como avaliar ou medir isso ? Em quais tarefas isso é importante ? Para que tipo de usuário ? Quais as pre-condições ?

45 Requisitos de Interface
Refraseando a especificação anterior: O sistema deve permitir que 70% dos clientes sem nenhum treinamento prévio realizem a operação de saque em até 2 minutos, desde a inserção do cartão até a retirada do dinheiro.

46 Requisitos de Interface
Refraseando a especificação anterior: O sistema deve permitir que 70% dos clientes sem nenhum treinamento prévio realizem a operação de saque em até 2 minutos, desde a inserção do cartão até a retirada do dinheiro. Quais usuários Qual a pré-condição Qual a tarefa Como avaliar

47 Guidelines Para guiar o projetista no sentido de sugerir uma interface HC que atenda aos requisitos funcionais e não-funcionais, podemos lançar mão de uma série de orientações (guidelines). Essas orientações têm várias origens, mas a maioria delas se baseia em estudos de pesquisadores da área de interação humano-computador. Apesar dessas orientações terem origem em pesquisadores distintos, a maioria delas apresenta algum tipo de sobreposição naquilo que elas realmente propõem. Ou seja, muitos autores descrevem a mesma orientação, mas com nomes diferentes. A seguir, veremos um conjunto de orientações extraídas de trabalhos de 4 pesquisadores.

48 Guidelines x

49 Guidelines x

50 Heurísticas de Nielsen
Exemplos das heurísticas de Nielsen: 1) Visibilidade do estado do sistema (feedback) Você precisa se certificar de que a interface sempre informe ao usuário o que está acontecendo, ou seja, todas as ações precisam de feedback instantâneo para orientá-lo.

51 Heurísticas de Nielsen
2) Relacionamento entre a interface do sistema e o mundo real Não usar termos que não façam sentido para o usuário. Toda a comunicação do sistema precisa ser contextualizada e ser coerente com o chamado modelo mental do usuário.

52 Heurísticas de Nielsen
2) Relacionamento entre a interface do sistema e o mundo real

53 Heurísticas de Nielsen
2) Relacionamento entre a interface do sistema e o mundo real

54 Heurísticas de Nielsen
3) Liberdade e controle do usuário Facilite as “saídas de emergência” para o usuário, permitindo desfazer ou refazer a ação no sistema e retornar ao ponto anterior, quando estiver perdido ou em situações inesperadas.

55 Heurísticas de Nielsen
3) Liberdade e controle do usuário

56 Heurísticas de Nielsen
4) Consistência Fale a mesma língua o tempo todo, e nunca identifique uma mesma ação com ícones ou palavras diferentes. Trate coisas similares, da mesma maneira, facilitando a identificação do usuário.

57 Heurísticas de Nielsen
4) Consistência

58 Heurísticas de Nielsen
4) Consistência

59 Heurísticas de Nielsen
5) Prevenção de erro Na tradução livre das palavras do próprio Nielsen “Ainda melhor que uma boa mensagem de erro é um design cuidadoso que possa prevenir esses erros”. Por exemplo, ações definitivas, como deleções ou solicitações podem vir acompanhadas de um checkbox ou uma mensagem de confirmação.

60 Heurísticas de Nielsen
6) Reconhecer ao invés de lembrar Evite acionar a memória do usuário o tempo inteiro, fazendo com que cada ação precise ser revista mentalmente antes de ser executada. Faça com que a interface ofereça ajuda contextual e informações capazes de orientar as ações do usuário – ou seja – que o sistema dialogue com o usuário.

61 Heurísticas de Nielsen
7) Flexibilidade e eficiência de uso O sistema precisa ser fácil para usuários leigos, mas flexível o bastante para se tornar ágil à usuários avançados. Essa flexibilidade pode ser conseguida com o uso de teclas de atalhos, por exemplo. No caso de websites, uso de máscaras e navegação com tab em formulários são outros exemplos.

62 Heurísticas de Nielsen
7) Flexibilidade e eficiência de uso

63 Heurísticas de Nielsen
8) Estética e design minimalista Evite que os textos e o design fale mais do que o usuário necessita saber. Os diálogos do sistema precisam ser simples, diretos e naturais, presentes nos momentos em que são necessários.

64 Heurísticas de Nielsen
8) Estética e design minimalista

65 Heurísticas de Nielsen
9) Ajude os usuários a reconhecer, diagnosticar e sanar seus erros As mensagens de erro do sistema devem possuir uma redação simples e clara que ao invés de intimidar o usuário com o erro, indique uma saída construtiva ou possível solução.

66 Heurísticas de Nielsen
9) Ajude os usuários a reconhecer, diagnosticar e sanar seus erros

67 Heurísticas de Nielsen
10) Ajuda e documentação Um bom design deveria evitar ao máximo a necessidade de ajuda na utilização do sistema. Ainda assim, um bom conjunto de documentação e ajuda deve ser utilizado para orientar o usuário em caso de dúvida. Deve ser visível, facilmente acessada e oferecer uma ferramenta de busca na ajuda.