interação humano-computador aula 09 aula 01 ihc. interação humano-computador 2 ihc ciência da...

Interação Humano-Computadoraula 09aula 01

IHC

Interação Humano-Computador2

IHC

Ciência da Computação

Usabilidade Engenharia de Usabilidade IHC x Engenharia de Software Requisitos

Requisitos de Interface HC Guidelines

Heurísticas de Nielsen

Tópicos


IHC


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.

Usabilidade


IHC


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.

Usabilidade


IHC


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)

Usabilidade


IHC


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.

Usabilidade


IHC


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

Usabilidade


IHC


Flexibilidade

Permitir que os usuários façam as mesmas coisas de formas diferentes

Importante quando usuários do sistema possuem diferenças significativas

Usabilidade


IHC


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.

Usabilidade


IHC


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.

Usabilidade


IHC


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

Engenharia de Usabilidade


IHC


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



IHC


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)


IHC


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.

Pré-design


IHC


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

Pré-design


IHC


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

Pré-design


IHC


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)

Design


IHC


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

Design


IHC


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

Pós-design


IHC


Wireframes

Técnicas de Antecipação


IHC


Esboços



IHC


Storyboard



IHC


Mapas navegacionais



IHC


Prototipos (alta fidelidade e baixa fidelidade)



IHC


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

IHC x Engenharia do Software


IHC


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.



IHC


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 ?



IHC


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.



IHC


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 ?



IHC


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 !



IHC


Traçando um paralelo entre essa visão e aquela proposta pela Engenharia da Usabilidade, temos:


Engenharia de Usabilidade Engenharia de RequisitosConhecer 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ógicasEstabelecer 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 Técnicas de antecipaçãoMétodos participativos Várias técnicas em comum, iterações

pequenas com avaliações frequentes, algumas técnicas de métodos ágeis


IHC


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.

Requisitos


IHC


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.

Requisitos


IHC


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 email, um

relatório de acompanhamento dos processos de indenização”

Requisitos


IHC


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”

Requisitos


IHC


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 email 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”

Requisitos


IHC


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, email e a reclamação”

Requisitos


IHC


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.

Requisitos

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 sistemaComportamental Características relacionadas

com o comportamento


IHC


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

Requisitos de Interface


IHC


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


São difíceis de serem representados fielmente, pois necessitam da implementação desses comportamentos

Podem ser representados com maior ou menor grau de fidelidade através das técnicas de antecipação


IHC


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



IHC


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 ?



IHC


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.



IHC


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.


Como avaliar

Qual a tarefa

Qual a pré-condição

Quais usuários


IHC


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.

Guidelines


IHC


x

GuidelinesNome Definição Autor(es) Definição do Autor

Aderência ao mundo real

Construir interfaces que lembrem algo do mundo real para que o usuário se sinta a vontade e consiga encontrar as funcionalidades com mais rapidez.

Nielsen Correspondência entre o Sistema e o Mundo Real

Norman Fornecer um bom modelo conceitual

Ajuda Rápida Ajudas rápidas e de fácil acesso devem ser incluídas com recursos de imagens quando possível

Nielsen Documentação e Ajuda

Coesão e Clareza

As interfaces devem ser coerentes, ou seja, devem seguir padrões. Os padrões devem conduzir formato (gráfico) e escrita (mesmas definições)

Nielsen Consistência e Normas

Norman O princípio do Mapeamento

Shneiderman 4. Desenhar as caixas de Diálogos Fechadas

Feedback

As ações do usuário não devem ficar sem um feedback mesmo quando não é gerada uma exceção, um aviso discreto deve ser providenciado (ex. barra de status)

Constantine & Lockwood Feedback

Nielsen Ajudar os usuários a reconhecer, diagnosticar e recuperar erros Visibilidade do estado do sistema

Norman O princípio do Feedback Shneiderman 3. Utilizar feedback Informativo

Flexibilidade As interfaces devem possuir flexibilidade para permitir que usuários avançados consigam construir ou acessar atalhos.

Nielsen Flexibilidade e eficiência na utilização

Shneiderman 2. Permitir aos usuários freqüentes a utilização de atalhos


IHC


x

GuidelinesNome Definição Autor(es) Definição do Autor

Intuitividade e consistência

Interfaces que prezam pelo intuitivo fazem o usuário não precisar de muito esforço para memorizar a localização das funcionalidades. Manter uma interface consistente, com variações pequenas entre as telas também ajudam na assertividade das funcionalidades.

Constantine & Lockwood Reutilização

Nielsen Reconhecimento em vez de Recordação

Norman Tornar as coisas visíveis Shneiderman 1. Lutar pela consistência

Shneiderman 8. Reduzir a carga sobre memória de curta-duração

Liberdade e Controle da Situação

Deixar o usuário no controle do software ajuda na aceitação do software Nielsen Liberdade e controle de usuários

Prevenção e Tratamento de Erros

Tolerância a Falhas do usuário devem estar presentes em todos os pontos, pois não está correto uma exceção produzida pelo usuário invalidar todo o trabalho até o ponto da falha. Permitir que o usuário reverta um erro ou ação indesejada todas as vezes que possível.

Constantine & Lockwood Tolerância

Nielsen Prevenção de Erros

Shneiderman 5. Utilizar Prevenção e Tratamento de erros

Shneiderman 6. Permitir fácil reposição de ações

Simplicidade e estética

Uma interface simples ajuda na memorização e reconhecimento de padrões, o que ajuda o usuário a se sentir mais a vontade e melhorar o aprendizado da ferramenta.

Constantine & Lockwood Simplicidade

Nielsen Desenho estético e minimalista

Shneiderman 7. Suportar a localização interna de controle

Visibilidade Deixar claro para o usuário qual é o estado atual do sistema, se este está processando algo ou está esperando uma entrada de dados.

Constantine & Lockwood Visibilidade

Nielsen Visibilidade do Estado do Sistema


IHC


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.



IHC


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.



IHC





IHC


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.



IHC


3) Liberdade e controle do usuário



IHC


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.



IHC


4) Consistência



IHC


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.



IHC


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.



IHC


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.



IHC


7) Flexibilidade e eficiência de uso



IHC


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.



IHC


8) Estética e design minimalista



IHC


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.



IHC


9) Ajude os usuários a reconhecer, diagnosticar e sanar seus erros



IHC


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.


interação humano-computador aula 09 aula 01 ihc. interação humano-computador 2 ihc ciência da...

Documents