Avaliação em IHC e Análise de Tarefas: Guia Completo

Avaliação em IHC: Planejamento e Fundamentos

O que é Avaliação de IHC?

A avaliação de IHC é um momento onde o avaliador:

• Faz um julgamento de valor sobre a qualidade de uso da solução de IHC;
• Identifica problemas na interação e na interface que prejudiquem a experiência particular do usuário durante o uso do sistema.

Por que Avaliar em IHC?

Nem sempre os produtos de um processo de fabricação são de qualidade. Problemas podem ocorrer devido a:

• Matéria-prima com defeito ou de má qualidade;
• Erro humano, etc.

No desenvolvimento de sistemas interativos, os problemas costumam ocorrer:

• Na coleta, interpretação, processamento e compartilhamento de dados entre os interessados no sistema (stakeholders);
• Na implementação do sistema projetado.

A avaliação do produto final possibilita entregar um produto com uma garantia maior de qualidade.

Por que Avaliar em Diferentes Perspectivas?

Um sistema interativo deve ser avaliado na perspectiva de quem concebe, constrói e de quem o utiliza.

Para Quem Constrói

Deve-se verificar se o sistema funciona de acordo com a especificação de requisitos (testes da Engenharia de Software).

Para Quem Concebe e Utiliza

Deve-se verificar se o sistema apoia adequadamente os usuários a atingirem seus objetivos em um contexto de uso (avaliações de IHC).

As diferenças entre quem concebe e quem utiliza não podem ser desprezadas. Os usuários podem ou não:

• Compreender e concordar com a lógica do designer;
• Julgar a solução de IHC apropriada e melhor do que as soluções existentes;
• Incorporá-la no seu dia a dia, quando tiverem escolha.

É importante avaliar IHC do ponto de vista dos usuários, preferencialmente com a participação deles.

Por que Avaliar a Qualidade de Uso?

• Problemas de IHC podem ser corrigidos antes e não depois de o produto ser lançado;
• A equipe de desenvolvimento pode se concentrar na solução de problemas reais, em vez de gastar tempo debatendo gostos e preferências particulares de cada membro da equipe;
• Engenheiros sabem construir um sistema, mas não sabem e não estão em uma posição adequada para discutir sobre a qualidade de uso. Quem será o advogado do usuário para defender seus interesses durante o processo de desenvolvimento?
• O tempo para colocar o produto no mercado diminui, pois os problemas de IHC são corrigidos desde o início do processo de desenvolvimento;
• Identificar e corrigir os problemas de IHC permitem entregar um produto mais robusto, ou seja, a próxima versão corretiva não precisa já começar a ser desenvolvida no momento do lançamento do produto no mercado.

O Que Avaliar em IHC?

É importante definirmos quais são os objetivos da avaliação, a quem eles interessam e por quê. Os objetivos de uma avaliação determinam quais aspectos relacionados ao uso do sistema devem ser investigados.

Alguns objetivos de avaliação comuns são:

• Apropriação de tecnologia pelos usuários, incluindo o sistema computacional a ser avaliado, mas não se limitando a ele;
• Ideias e alternativas de design;
• Conformidade com um padrão;
• Problemas na interação e na interface.

Os objetivos precisam ser detalhados em perguntas mais específicas para torná-los operacionais.

Apropriação de Tecnologia

• Quais os objetivos e as necessidades do usuário? Pode ser utilizado estudo exploratório.
• O uso da tecnologia atual é produtivo? Utilização de protótipos e esboços de tela.
• Avaliação de como os usuários usam o sistema antes e depois da intervenção.

Ideias e Alternativas de Design

Comparar diferentes alternativas de solução. Ex: Com relação ao uso, podemos avaliar a facilidade de aprendizado, usabilidade, recuperação de erros. É possível comparar soluções de IHC prontas de outros sistemas existentes.

Relembrando Usabilidade: Fatores de Nielsen (1993)

Para Nielsen (1993), a usabilidade é um conjunto de fatores:

• Facilidade de aprendizado (learnability);
• Facilidade de recordação (memorability);
• Eficiência (efficiency);
• Segurança no uso (safety);
• Satisfação do usuário (satisfaction).

Quando Avaliar o Uso de um Sistema?

Em diferentes momentos do processo de desenvolvimento, dependendo dos dados disponíveis sobre a solução de IHC sendo concebida.

Avaliação Formativa

Realizada antes de termos uma solução pronta, geralmente utilizada para:

• Analisar e comparar ideias e alternativas de design;
• Identificar problemas na interação e na interface.

Artefatos que podem servir de insumo:

• Cenários de uso;
• Esboços de tela;
• Storyboards;
• Modelagem da interação;
• Protótipos do sistema em diferentes níveis de detalhe e fidelidade.

Avaliação Somativa (ou Conclusiva)

Realizada depois que a solução estiver pronta, utilizada para avaliar qualquer objetivo de avaliação.

A solução de IHC final pode ser representada:

• Por um protótipo de média ou alta fidelidade;
• Ou até mesmo pelo sistema interativo implementado.

Avaliação em Contexto de Uso

• Fornece dados de situações típicas de uso que não seriam percebidos em uma avaliação em laboratório;
• Permite entender melhor como os usuários se apropriam da tecnologia no seu cotidiano e quais problemas podem ocorrer em situações reais de uso;
• É difícil controlar sua execução para assegurar que certos aspectos do sistema sejam analisados.

Avaliação em Laboratório

• Oferece um controle maior sobre as interferências do ambiente na interação usuário-sistema;
• Facilita o registro de dados das experiências de uso com a solução de IHC avaliada;
• Uma sala de reunião com mesa e cadeiras é um ambiente adequado para utilizar os métodos de grupo de foco e prototipação em papel;
• Ambientes de observação são adequados para o teste de usabilidade e o método de avaliação de comunicabilidade.

Que Tipos de Dados Coletar e Produzir?

Os dados coletados e produzidos em uma avaliação de IHC podem ser classificados de diferentes maneiras.

Classificações Comuns de Dados

As classificações mais comuns são:

• Nominais, ordinais, de intervalo e de razão;
• Dados qualitativos e quantitativos;
• Dados subjetivos e objetivos.

Cada método de avaliação de IHC privilegia dados e resultados de diferentes tipos.

• Dados Nominais: Representam conceitos na forma de rótulos ou categorias, por exemplo: a origem étnica de uma pessoa pode ser africana, hispânica, asiática, etc.
• Dados Ordinais: Representam conceitos com relações que definem algum tipo de ordem entre eles, por exemplo, uma lista de sites que um usuário mais utiliza.
• Dados de Intervalo: Representam períodos, faixas ou distâncias entre os dados ordinais, por exemplo, faixa etária.
• Dados de Razão: São dados que possuem um valor zero verdadeiro, por exemplo, o tempo que uma pessoa leva para realizar uma tarefa, ou o número de erros cometidos.
• Dados Qualitativos: Representam conceitos que não são representados numericamente. Por exemplo, os dados nominais e as respostas livres, tais como expectativas, explicações, críticas, sugestões e outros tipos de comentário.
• Dados Quantitativos: Representam numericamente uma quantidade, ou seja, uma grandeza resultante de uma contagem ou medição, tais como: o tempo e número de passos necessários para alcançar determinado objetivo ou quantas vezes a ajuda on-line e o manual de uso foram consultados. Nessa classificação se encaixam os dados ordinais, intervalares e de razão.
• Dados Objetivos: Podem ser medidos por instrumentos ou software, por exemplo, as músicas que ele mais ouviu no último mês no seu computador ou o tempo que ele levou para realizar uma tarefa numa sessão de teste.
• Dados Subjetivos: Precisam ser explicitamente expressos pelos participantes da avaliação, como opiniões e preferências.

Análise de Tarefas em IHC

O Que é Análise de Tarefas?

Utilizada para se ter um entendimento sobre qual é o trabalho dos usuários, como eles o realizam e por que.

Alguns métodos de análise de tarefas mais comuns:

• Análise Hierárquica de Tarefas (HTA - Hierarchical Task Analysis);
• GOMS (Goals, Operators, Methods, e Selection Rules);
• ConcurTaskTrees (CTT).

Definição de Tarefa

Uma tarefa é qualquer parte do trabalho que precisa ser realizado.

• Tarefas complexas são decompostas em uma hierarquia de objetivos, subobjetivos e operações.
• Um plano define a ordem em que os subobjetivos devem ser alcançados.

GOMS: Goals, Operators, Methods e Selection Rules

As tarefas são descritas em termos de:

• Objetivos (Goals): Representam o que o usuário quer realizar utilizando o sistema;
• Operadores (Operators): Primitivas internas (cognitivas) ou externas (as ações concretas que o sistema permite que os usuários façam, tal como um comando e seus parâmetros digitados num teclado; a seleção de menus; o clique de um botão);
• Métodos (Methods): Sequências bem conhecidas de subobjetivos e operadores que permitem atingir um objetivo maior;
• Regras de Seleção (Selection Rules): Permitem decidir qual método utilizar numa determinada situação.

ConcurTaskTrees (CTT)

As ConcurTaskTrees (CTT) são uma notação para representar a análise de tarefas.

Tipos de Tarefas no CTT

Existem 4 tipos de tarefas:

• Tarefas do Usuário: Realizadas fora do sistema;
• Tarefas do Sistema: Em que o sistema realiza um processamento sem interagir com o usuário;
• Tarefas Interativas: Em que ocorrem os diálogos usuário-sistema;
• Tarefas Abstratas: Que não são tarefas em si, mas sim uma representação de uma composição de tarefas que auxilie a decomposição.

Relações entre Tarefas no CTT

• Ativação: T1 >> T2 significa que a segunda tarefa (T2) só pode iniciar após a primeira tarefa (T1) terminar;
• Ativação com Passagem de Informação: T1 [ ] >> T2 especifica que, além de T2 só poder ser iniciada após T1, a informação produzida por T1 é passada para T2;
• Escolha (Tarefas Alternativas): T1 [ ] T2 especifica duas tarefas que estejam habilitadas num momento, mas que, uma vez que uma delas é iniciada, a outra é desabilitada;
• Tarefas Concorrentes: T1 ||| T2 especifica que as tarefas podem ser realizadas em qualquer ordem ou ao mesmo tempo;
• Tarefas Concorrentes e Comunicantes: T1 | [ ] | T2 especifica que, além de as tarefas poderem ser realizadas em qualquer ordem ou ao mesmo tempo, elas podem trocar informações;
• Tarefas Independentes: T1 |=| T2 especifica que as tarefas podem ser realizadas em qualquer ordem, mas quando uma delas é iniciada, precisa terminar para que a outra possa ser iniciada;
• Desativação: T1 [> T2 especifica que T1 é completamente interrompida por T2;
• Suspensão/Retomada: T1 |> T2 especifica que T1 pode ser interrompida por T2 e é retomada do ponto em que parou assim que T2 terminar.

Preparação na Prototipação em Papel

O avaliador deve elaborar protótipos em papel:

• Parte Estática: As telas do sistema com os principais elementos com os quais o usuário vai interagir;
• Parte Dinâmica: Os itens de interface que se modificam, tais como menus, dicas, itens de alguma lista e resultados de busca.

O que for possível prever deve ser preparado antes das simulações de uso. O que não for possível será desenhado no papel durante as simulações.

Avaliação Heurística

Método de avaliação de IHC criado para encontrar problemas de usabilidade durante um processo de design iterativo. É um método simples, rápido e de baixo custo para avaliar IHC, quando comparado aos métodos empíricos. Tem como base um conjunto de heurísticas de usabilidade, que descrevem características desejáveis da interação e da interface. Nielsen propõe um conjunto inicial de 10 heurísticas, que pode ser complementado conforme o avaliador julgar necessário.

Visibilidade do Estado do Sistema

O sistema deve sempre manter os usuários informados sobre o que está acontecendo através de feedback (resposta às ações do usuário) adequado e no tempo certo.

Correspondência entre o Sistema e o Mundo Real

O sistema deve utilizar palavras, expressões e conceitos que são familiares aos usuários, em vez de utilizar termos orientados ao sistema ou jargão dos desenvolvedores. O designer deve seguir as convenções do mundo real, fazendo com que a informação apareça em uma ordem natural e lógica, conforme esperado pelos usuários.

Controle e Liberdade do Usuário

Os usuários frequentemente realizam ações equivocadas no sistema e precisam de uma saída de emergência claramente marcada para sair do estado indesejado sem ter de percorrer um diálogo extenso. A interface deve permitir que o usuário desfaça e refaça suas ações.

Consistência e Padronização

Os usuários não devem ter de se perguntar se palavras, situações ou ações diferentes significam a mesma coisa. O designer deve seguir as convenções da plataforma ou do ambiente computacional.

Reconhecimento em Vez de Memorização

O designer deve tornar os objetos, as ações e opções visíveis. As instruções de uso do sistema devem estar visíveis ou facilmente acessíveis sempre que necessário.

Flexibilidade e Eficiência de Uso

Aceleradores podem tornar a interação do usuário mais rápida e eficiente, permitindo que o sistema consiga servir igualmente bem os usuários experientes e inexperientes.

Projeto Estético e Minimalista

A interface não deve conter informação que seja irrelevante ou raramente necessária. Cada unidade extra de informação em uma interface reduz sua visibilidade relativa, pois compete com as demais unidades de informação pela atenção do usuário.

Prevenção de Erros

Melhor do que uma boa mensagem de erro é um projeto cuidadoso que evite que um problema ocorra, caso isso seja possível.

Ajude os Usuários a Reconhecerem, Diagnosticarem e se Recuperarem de Erros

As mensagens de erro devem ser expressas em linguagem simples (sem códigos indecifráveis), indicar precisamente o problema e sugerir uma solução de forma construtiva.

Ajuda e Documentação

É necessário oferecer ajuda e documentação de alta qualidade. Tais informações devem ser facilmente encontradas, focadas na tarefa do usuário, enumerar passos concretos a serem realizados e não ser muito extensas.