Lafayette B. Melo – CEFET-PB - COINFO O projeto e o design de sistemas são inerentemente criativos e imprevisíveis: São processos, não-hierárquicos, transformacionais

Lafayette B. Melo – CEFET-PB - COINFOLafayette B. Melo – CEFET-PB - COINFO

• O projeto e o design de sistemas são inerentemente criativos e imprevisíveis:• São processos, não-hierárquicos, transformacionais e envolvem

a descoberta de novos objetivos

• … mas em todo domínio criativo pode haver disciplina, técnicas refinadas, métodos corretos e medidas de sucesso

• Os projetos de desenvolvimento também envolvem métodos de avaliação e usabilidade

• Neste sentido, engenheiros de usabilidade e arquitetos de interface do usuário estão ganhando experiência em gerenciar as mudanças organizacionais, o que repercute em $

6. MÉTODOS DE AVALIAÇÃO DA INTERFACE E 6. MÉTODOS DE AVALIAÇÃO DA INTERFACE E USABILIDADEUSABILIDADE


• É importante definir o método de avaliação adequado e escolher a definição de usabilidade a ser utilizada…– “É a capacidade do sofware em permitir que o usuário alcance

suas metas de interação com o sistema (Scapin)– “É o quanto o software é fácil de aprender e permite utilização

eficiente e apresenta poucos erros” (Nielsen)– “Qualidade da experiência… um software intuitivo, completo e

que não ‘quebre’” (Wright)

• Há a definição “fácil de”– Usar, aprender (e ensinar), re-aprender, desaprender, evitar

perdas, dar suporte, explorar, compartilhar com um grupo, integrar com operações existentes


• Há definições atualizadas na http://www.UPAssoc.org

• A despeito das definições, o que importa é saber O QUE o usuário quer fazer, QUANDO e COMO

• A idéia de software ou interface amigável não ajuda em nada– O que significa?– Tem uma noção muito subjetiva– Como as empresas podem dizer mais que um software é fácil

de usar do que é um produto competitivo– Não tem grande significado, a não ser que sej adefinido em

termos reais, operacionais, que possa ser medido e testado


• Melhor solução do que interface amigável

Engenharia da Usabilidade =

Projeto bom de Interface

+

Testes de

Usabilidade


• Porque a avaliação da usabilidade é tão importante?– Intuições de designers e desenvolvedores não estão sempre

corretas– Terminologia de designers e desenvolvedores nem sempre

significa a mesma do usuário– Pessoas diferem e não há um usuário médio– Princípios de usabilidade e guidelines não são suficientes– Feedback informal é inadequado para avaliações do produto– Tempo, dinheiro e recursos gastos nas avaliações de usabilidade

valem a pena– Produtos construídos em pedaços sempre têm inconsistências de

alto nível– Problemas encontrados mais tarde no software são mais difíceis

e caros de consertar– Problemas consertados no processo de desenvolvimento

reduzem os custos mais tarde– Avaliações de usabilidade podem dar vantagens sobre produtos

competitivos


• A ISO define usabilidade como “a efetividade, eficiência e satisfação com a qual um conjunto específico de usuários pode alcançar um conjunto específico de tarefas em um ambiente particular”

• Os métodos de avaliação da interface e os testes de usabilidade são muitos e seguem orientações teóricas diversas

• Quando se deve parar de fazer um teste?– Se a sessão não produziu feedback do usuário em novos

problemas

• Algumas característicascaracterísticas específicas e medidasmedidas são hoje consideradas fundamentais para se avaliar usabilidade em Websites:


Características e medidas de Websites

CARACTERÍSTICASCARACTERÍSTICAS

•Fácil aprendizagemnão há manual

•Orientados a processos

Não altera o resultado original do sistemaNão altera o resultado obtido

•…

MEDIDASMEDIDAS

•EfetividadeAtingir os objetivos iniciais da interaçãoTodo Website tem uma tarefa primáriaEntender o usuário no mundo real e físico

•EficiênciaQuantidade de esforço para se chegar a um objetivoRotas e conteúdosQuanto menos trabalho melhor Divisão

Desvios da navegaçãoÍndice de errosTempo gasto na tarefa

•Satisfação•Mais subjetiva•Nível de conforto do usuário•Quantitativa na linguagem corporal •Qualitativa em questionário

Observadas na

execução dos

trabalhos

Observadas no

relatório / apresenta

ção dos trabalhos


• Além disso, para todo método é importante determinantes da avaliação:

– Estágio do projeto– Novidade do projeto (bem definido vs exploratório)– Número de usuários esperado– Criticalidade da interface (sistema médico crítico ou

exibição de museu)– Custos do produto e finanças/recursos alocados– Tempo disponível– Experiência de design e grupo de avaliação


• Tipos de métodos de avaliação da interface e da usabilidadeRevisões do especialista

• Avaliações heurísticas

• Revisão de guidelines

• Inspeção da consistência

• Walkthrough

• Inspeção formal de

usabilidade

Testes de usabilidad

e

Informais, definidos

por tarefas, com

condições de

autorização próprias e técnicas diversas

Levantamentos

(surveys)

Preparação, tipos de

pergunta e escalas

Testes de

aceitação

Medidas mais

rígidas que

podem se estender

a uma avaliação durante o uso ativo

Modelos

Modelagem do desenvolvimen

to e da usabilidade em métodos mais

formais de especificação


6.1 Revisões do especialista6.1 Revisões do especialista• Não é um feedback informal, mas dependente da

disponibilidade de especialistas na equipe ou de consultores

• Os especialistas podem ser da aplicação ou com domínio em interface do usuário

• O resultado do trabalho é um relatório com problemas identificados ou recomendações

• Podem ser escalados em qualquer momento e o número dependerá do projeto (3 a 5 pode ser produtivo)

• Problemas: muitas variáveis não são controláveis, os especialistas podem não ter um domínio adequado da tarefa e da comunidade de usuários


6.1.1 Avaliações heurísticas6.1.1 Avaliações heurísticas• Os revisores especialistas criticam uma interface para

identificar se ela está de acordo com uma lista curta de heurísticas de design como “as regras de ouro”

• Há uma grande diferença se os especialistas são familiares com as regras ou se são capazes de interpretá-las e aplicá-las (TRABALHO 1)

• Os revisores geralmente observam problemas para a discussão com o projetista, mas a solução é deixada para que o projetista desenvolva


6.1.2 Revisão de Guidelines6.1.2 Revisão de Guidelines• A interface é checada em conformidade com documentos

organizacionais ou outros guidelines

• Pelo fato de os documentos de guidelines poderem conter centenas de itens, pode levar algum tempo para os revisores dominarem os guidelines e dias ou semanas para revisarem um sistema grande (TRABALHO 2)

• Guidelines devem ser considerados geralmente para:– Terminologia (objetos e ações), abreviações e capitalizações– Conjunto de caracteres, fontes, tamanho das fontes e estilo– Ícones, gráficos e espessuras de linha – Uso de cor e background– Características de layout– Dispositivos de entrada e saída– Sequência de ação (manipulação, sintaxe e semântica)– Funções programadas e procedimentos de recuperação de erro– Treinamento, ajuda e referência


• Guidelines devem ser textos vivos a serem frequentemente adaptados devido às necesssidades e ao tipo de experiência

• A criação de guidelines no início do projeto de implementação foca a atenção no projeto de interface e possibilita uma oportunidade para discussão de características controversas

• Recomendações para documentos de guideline– Possibilita um processo social entre desenvolvedores– Registra todas as decisões para todas as partes acompanharem– Promove consistência e completude– Facilita a automação do projeto– Permite múltiplos níveis

• Padrões rígidos• Práticas aceitas• Guidelines flexíveis

– Retorna políticas para:• Execução (quem revisa)• Isenção (quem decide)• Melhoramentos (em que frequência)


• Como se beneficiar dos guidelines– Escolher os guidelines da indústria apropriados para os

ambientes de software– Criar um guia de estilo para as próprias interfaces do produto– Escolher uma aplicação alvo a seguir os guidelines– Seguir os guidelines ao desenvolver e ao apresentar os

produtos

• Pirâmide de guias de estilo de guidelines e padrões

Padrões internacionais (ISO, DIN)

Guidelines de plataforma industrial

Guia de estilo de interface da organização

Guias de estilo

dos produto

sGuia de estilo de um pacote


6.1.3 Inspeção da consistência6.1.3 Inspeção da consistência• O especialista verifica a consistência em uma família de

interfaces, checando a consistência da terminologia, cor, layout, formatos de entrada e saída etc dentro da interface bem como do material de treinamento e do help online

• Deve ser feita para todos os elementos

• Deve ser feita para outros elementos que não os visuais bem como para o estilo


6.1.4 Walkthrough6.1.4 Walkthrough• O especialista simula a trajetória do usuário através da

interface para a realização de tarefas típicas.

• Tarefas de alta frequência são um ponto de partida, mas tarefas críticas raras, como a descoberta de erro, também devem ser percorridas.

• Pode ser feito privadamente ou com um grupo de designers, usuários ou executivos para conduzir o walkthrough e provocar uma discussão (Yourdon)


6.1.6.1.55 Inspeção formal da usabilidadeInspeção formal da usabilidade• Reunião com moderador ou juiz para discutir méritos e

fraquezas

• Membros do design rebatem as evidências do problema em um formato de adversarial

• Preparação para novatos e gerentes longas e mais pessoal para realizar do que outros tipos de revisão


6.6.22 Testes de usabilidadeTestes de usabilidade• Têm acelerado muitos projetos bem como produzido economias

dramáticas de custo

• É indicador da atenção das necessidades ao usuário

• O laboratório de usabilidade se separa de suas raízes acadêmicas, influenciado pelos anúncios e pesquisas de mercado

• Experimentos controlados têm pelo menos dois tratamentos e procuram mostrar estatisticamente mudanças significativas

• Testes de usabilidade são projetados para encontrar falhas na interface, com poucos sujeitos (geralmente não mais do que três)

• É em geral associado com outros métodos

• O grupo que testa participa da análise da tarefa ou da revisão do design, provê informação através de ferramentas de software ou de referências da literatura


• Em geral, duas a seis semanas antes do teste de usabilidade, um plano de teste é desenvolvido (TRABALHOS 3 e 4)– Há uma lista de tarefas e questões subjetivas– O número, tipo e origem dos participantes são identificados– Um teste piloto é geralmente deenvolvido– No dia do teste efetivo, os participantes são identificados em

relaçãp a sua representação sobre a comunidade de usuários, bem como suas condições físicas

• Os participantes devem ser tratados com respeito (“eles não estão sendo testados”) e informados sobre o que vão fazer e até quando vão fazer (são voluntários e uma autorização precisa ser obtida)

• Limitações– Ênfase no uso da primeira vez– Cobertura limitada das características da interface


• Há testes modernos de rastreamento do olho do usuário


• Condições da autorização– “Estou paricipando livremente como voluntário deste experimento”– “Fui informado antes sobre que tarefas e procedimentos deveria

seguir”– “Eu tive a oportunidade de fazer perguntas e obter respostas

satisfatoriamente”– “Estou consciente de que posso negar esta autorização e parar a

minha participação, sem prejuízo em relação a meu tratamento futuro”

– “Minha assinatura abaixo confirma meu consentimento sobre todas as afirmações anteriores”

• No teste, algumas técnicas podem ser usadas– Pensar alto– Informalidade e mais de um participante– Uso de softwares para “logar” a atividade– Testes de campo (o maior é o do Windows 95)– Mockups– “Can you break this?” (erros fatais)– Teste de usabilidade competitiva (com a versão anterior)


6.6.3 Levantamentos (Surveys)3 Levantamentos (Surveys)• Tipicamente são um conjunto de várias perguntas para

muitos respondentes– Surveys são geralmente aceitáveis, familiares e baratos para os

testes de usabilidade e a revisão do especialista– Têm um sentido de autoridade

• A chave de sucesso é o uso de objetivos claros e o desenvolvimento de de itens focados que ajudem a se ater a esses objetivos

• Um survey deve ser preparado e revisado entre colegas antes de uma distribuição ampla (TRABALHO 5)

• O tipo de análise estatística e a apresentação devem ser definidos antes do survey final ser distribuído a no mínimo 20 pessoas


• Podem ser feitas perguntas sobre as impressões subjetivas que os usuários têm a respeito de aspectos específicos da interface– Domínio da tarefa sobre os objetos e ações– Domínio da interface sobre as metáforas e ações– Sintaxe de entrada e displays

• Outras perguntas– Background– Experiência com informática– Tipo de responsabilidade no trabalho– Estilo de personalidade– Familiaridade com especificidades – Sentimento após uso da interface (confuso X esclarecido,

frustrado X em controle, calmo X excitado)


• Podem ser administrados online

• Podem ser usados em escala– 1. Concorda fortemente– 2. Concorda– 3. Não sabe– 4. Não concorda– 5. Não concorda fortemente

• As escalas podem ser usadas em frases como:– “Eu acho os comandos do sistema fáceis de usar”– “Eu me sinto capaz de usar e entender os comandos do

sistema”– “Quando eu escrevo um conjunto de comandos para uma nova

aplicação, estou certo de que acertarei na primeira vez”– Ainda podem ser feitas frases sobre mensagens de erro,

quantidade de opções, simplicidade, confusão e consulta a outras fontes


• Exemplos de opções em escala sobre mensagens de erro– Hostil 1 2 3 4 5 6 7 Amigável– Vago 1 2 3 4 5 6 7 Específico

• Também podem ser feitas perguntas para se avaliar aspectos do design de interface como a legibilidade de caracteres, o significado dos nomes de comando ou sobre o quanto têm ajudado as mensagens de erro

• Há outras escalas e questionários de usabilidade que incluem utilidade do sistema, qualidade da informação e qualidade da interface


6.6.4 Testes de aceitação4 Testes de aceitação• Noções de interação homem-máquina como um todo

são estendidas para as interfaces computacionais com o ser humano (geralmente m projetos muito grandes)

• Mais do que o critério vago de “interface amigável”, há critérios de medida rígidos– Tempo de aprender funções específicas– Velocidade no desempenho da tarefa– Taxa de erros do usuário– Retenção de comandos durante o tempo– Satisfação subjetiva do usuário

• Um teste de aceitação deve relatar várias medidas e suas relações


6.6.5 Modelos5 Modelos• Feitos por especialistas e aplicados para quem adquire

conhecimento do modelo

• Exemplo: OAI de Shneiderman– Foca quatro componentes em duas áreas

• 1. Tarefas– Objetos de informação estruturada (hierarquias, redes)– Ações de informação (busca, link)

• 2. Interface– Metáforas (estante, enciclopédia)– Planos de ação (query, zoom)

Documents

Lafayette B. Melo – CEFET-PB - COINFO O projeto e o design de sistemas são inerentemente criativos e imprevisíveis: São processos, não-hierárquicos, transformacionais