eBook Ergonomia de Interface - Clayton Lewis & John Rieman

5/5/2018 eBook Ergonomia de Interface - Clayton Lewis & John Rieman - slidepdf.com

http://slidepdf.com/reader/full/ebook-ergonomia-de-interface-clayton-lewis-john-rieman

UFSC – UNIVERSIDADE FEDERAL DE SANTA CATARINACCE – CENTRO DE COMUNICAÇÃO E EXPRESSÃO

CURSO SUPERIOR DE DESIGNDISCIPLINA: EGR 5154

ERGONOMIA DE INTERFACEPROFESSORA: MARISA ARAÚJO CARVALHO

TAREFA DE DESIGN CENTRADO NA INTERFACE DO USUÁRIO: UMAINTRODUÇÃO PRÁTICA

por Lewis John Clayton e Rieman

BRENO TAKAMINEFERNANDA MORETTI RODRIGUES

LETICIA DE FREITAS PIRESRAFAEL NARAVAN KIENENRAISA HARUMI KAWASAKI

THIAGO REGINALDOTHULIO BECKER

FLORIANÓPOLIS

1



ABRIL DE 2011

1



SUMÁRIO

1- A tarefa centrada no processo de Design 11.1 Descobrir quem vai usar o sistema para fazer o que. 1

1.2 Escolher Tarefas Representantes para Design centrado em tarefas 11.3 Plagiar 21.4 Esboçar o projeto 21.5 Pense Nisso 21.6 Criar uma Maquete ou Protótipo 21.7 Teste do Design com Usuários 31.8 Repetição (Iteração) 31.9 Construção do Design 31.10 Acompanhamento do Design 31.11 Mudança no Design 3

3- Criando o Design inicial 4

3.1 Trabalho dentro dos quadros da Interface 43.2 Fazer o uso das aplicações existentes 43.3 Copias de Técnicas de Interação de outros sistemas 43.4 Quando você precisa inventar 43.5 Princípios de Design Gráfico 4

4- Avaliando Design sem os usuários 54.1 Passo a passo cognitivo 5

4.1.1 Quem deve fazer um passo a passo, e quando? 54.1.2 O que é necessário antes que você pode fazer um passo a passo? 64.1.3 O que você deve procurar durante o passo a passo? 64.1.4 O que fazer com os resultados do passo a passo? 6

4.2 Análise de ação 64.3 Análise Heurística 74.4 Resumo do Capítulo e Discussões 7

5- Testando o Design com usuários. 75.1 Escolhas de usuários para o teste 75.2 Seleções de tarefas para o teste 75.3 Fornecer um sistema para usuários de teste utilizarem 75.4 Decisão de quais dados coletar 85.5 O método do pensamento em voz alta 85.6 Medições de usabilidade 8

5.6.1 Analisando os números 95.6.2 Comparação de duas alternativas de projeto 95.7 Detalhes da configuração de um estudo de usabilidade 9

5.7.1 Escolha da Ordem de tarefas de teste 105.7.2 Teste de treinamento de usuários 105.7.3 O Estudo Piloto 105.7.4 E se alguém não completar uma tarefa? 105.7.5 Variabilidade 105.7.6 Teste de Usuários interrogados 10

CONSIDERAÇÕES FINAIS 11

1



TAREFA DE DESIGN CENTRADO NA INTERFACE DO USUÁRIO: UmaIntrodução Prática por Lewis John Clayton e Rieman

Este capítulo apresenta uma visão geral da tarefa centrada no processo de concepção.O processo está estruturado em torno de tarefas específicas que o usuário deseja realizar como sistema a ser desenvolvido. Essas tarefas são escolhidas no início do projeto, em seguida,utilizadas para levantar questões sobre o mesmo, para auxiliar na tomada de decisões de

projeto e avaliar como ele é desenvolvido. As etapas na tarefa de design centrado no processosão:

● Descobrir quem é que vai usar o sistema para fazer o que.● Escolher tarefas representantes para o design centrado em tarefas.● Plagiar.● Esboçar um projeto.● Pense nisso.● Criar um protótipo ou maquete.● Teste com usuários.● Iterar.● Construí-lo.● Monitorá-lo.● Alterá-lo.

1- A tarefa centrada no processo de Design

1.1 Descobrir quem vai usar o sistema para fazer o que.

A terminologia para este passo é "tarefa e análise do usuário." Um sistema deve fazer o que é necessário mesclando harmoniosamente o mundo existente do usuário e da tarefa,também deve colocar as informações de acordo com a tarefa tornando-a mais fácil.

Devemos analisar os detalhes das tarefas que os usuários executam, observando asdiversas considerações sobre a interface, sabendo em qual nível de entendimento eles estão.

Tarefa eficaz e análise do usuário requerem um contato pessoal entre os membros daequipe de projeto e as pessoas que irão realmente usar o sistema. É certo que o contato inicial

e continuado entre designers e usuários é essencial para um bom projeto.

1.2 Escolher Tarefas Representantes para Design centrado em tarefas

Depois de estabelecer uma boa compreensão dos usuários e suas tarefas, um processode design mais tradicional pode abstrair a partir desses fatos e produzir uma especificaçãogeral do sistema e de sua interface com o usuário. O processo de design centrado em tarefasleva a uma abordagem mais concreta. O designer deve identificar várias tarefasrepresentativas que o sistema será utilizado para realizar. Estas devem ser as tarefas que osusuários tenham realmente descrito para os designers. As tarefas podem ser inicialmentereferenciadas em poucas palavras, mas que são funções reais, que podem depois ser

expandidas para qualquer nível de detalhe necessário para responder a questões de design ouanalisar uma interface proposta.

1



As tarefas selecionadas devem fornecer uma cobertura razoavelmente completa dafuncionalidade do sistema, e o designer pode querer fazer uma lista de funções e compará-lascom as tarefas para garantir que a cobertura foi alcançada. Também deve haver uma misturade tarefas simples e mais complexas. Produzir um conjunto eficaz de tarefas será um

verdadeiro teste de compreensão do designer, dos usuários e de seu trabalho.

1.3 Plagiar

Você deve encontrar interfaces existentes que trabalham para os utilizadores e, emseguida, construir idéias a partir dessas interfaces em seus sistemas, tanto quanto na prática e

juridicamente possível. Este tipo de cópia pode ser eficaz tanto para paradigmas de interaçãode alto nível e para controle de baixo nível.

Nos níveis mais elevados, pense sobre tarefas representativas e os usuários que estãofazendo. Você pode ser capaz de criar um novo paradigma de interação que é mais adequado

para sua aplicação, mas o risco de fracasso é alto. Um paradigma existente será mais rápido e

mais fácil de implementar, porque muitas das decisões de projeto já foram feitas. Maisimportante, será fácil e confortável para os usuários a aprender e usar, porque eles já sabemmuito da interface.

Esta é uma área onde é muito comum os designers tomarem a decisão errada, porqueeles não parecem ir suficientemente longe das exigências de seu próprio sistema. A maior

parte das vezes, a melhor resposta é ficar com o que os usuários saibam.

1.4 Esboçar o projeto

A descrição aproximada do projeto deve ser posta no papel, o que força você a pensar sobre as coisas. Mas não deve ser programada em um computador (ainda), porque o esforçode programação, mesmo com os sistemas mais simples de prototipagem, o designer acabacometendo decisões muito cedo no processo.

Nesta fase, uma equipe de design vai ter muita discussão sobre as funcionalidades queo sistema deve incluir e como eles devem ser apresentados ao usuário. Essa discussão deveser guiada pela abordagem de design centrado em tarefas. Se alguém da equipe propõe umnovo recurso, outro membro da equipe deve perguntar qual das missões de representação queele suporta. Características que não suportam qualquer uma das tarefas geralmente devem ser descartadas, ou a lista de tarefas deve ser modificada para incluir uma tarefa real que exerceessa função.

As funções representativas devem também ser usadas como uma espécie de lista de

verificação para garantir que o sistema está completo. Se você não pode trabalhar em cadatarefa com a definição atual do sistema, a definição precisa de ser melhorada.

1.5 Pense Nisso

Os custos de construção de uma interface de usuário completa e testes com usuáriossuficientes para revelar todos os seus principais problemas são inaceitavelmente elevados.Existem várias abordagens estruturadas que você pode tomar para descobrir os pontos fortes efracos de uma interface antes de construí-la.

Um método é a contagem de digitação e operações mentais (decisões) para as tarefasque o projeto se destina a apoiar. Isso permitirá que você estime tempos de tarefa e identifique

as tarefas que levam muitos passos.

1



1.6 Criar uma Maquete ou Protótipo

Após a descrição escrita do projeto, deve ser criado um modelo concreto para ser mostrado ao usuário. A principio pode ser feito apenas em esboços no papel (Maquete) ou

utilizando ferramentas para prototipagem como HyperCard, Dan Bricklin's Demo Package ouUser Interface Management System (UIMS). Com isso, será possível levantar muitasinformações relevantes para o projeto.

O Protótipo deve se concentrar na interface necessária para tarefas representativas.Funcionalidades do sistema que ainda estão em produção podem ser emuladas com a técnica“Mágico de Oz” onde o designer realiza as ações que ainda não foram programadas.

1.7 Teste do Design com Usuários

Há problemas que só aparecerão quando o projeto for testado pelo usuário. Deve ser feita uma seleção de pessoas que se aproximem das características do usuário final. E eles

devem relatar seus pensamentos enquanto testam a interface e experiência deve ser gravada eanalisada posteriormente.

1.8 Repetição (Iteração)

O teste com usuário apontará sempre apontará problemas, isto dará a possibilidade demelhorar a interface e repetir o teste. Deve ser levado em conta a gravidade do problema e ocusto da correção. É importante lembrar que as características da interface não são isoladas eao resolver um problema outro problema pode surgir.

Quando objetivos de usabilidade são atendidos ou quando a relação de custo e benefício se equilibra, os testes param.

1.9 Construção do Design

É importante construir uma interface para que ela possa ser facilmente alterada.Antecipe mudanças que possam ser necessárias eventualmente como tamanho, cor e númerode itens. A interface é a maior parte da programação do produto.

1.10 Acompanhamento do Design

O designer não deve estar isolado a apenas o desenvolvimento do projeto. O

acompanhamento do projeto após ele chegar ao usuário final. Isto, além de verificar se o projeto cumpre seu propósito, pode trazer surpresas que abrem novas oportunidades demercado.

1.11 Mudança no Design

No mercado de hoje do computador há poucos ou nenhum produto de software que pode manter as suas vendas sem atualizações regulares. As tarefas e os usuários mudam. Osusuários ganham novas habilidades e novas expectativas.

Os designers precisam ficar a par destas mudanças, não apenas observando o local emque seus produtos estão instalados, mas também prestando atenção para a evolução das outras

partes da sociedade. A próxima revisão do projeto deve ser uma resposta não só aos problemas, mas também oportunidades.

1



3- Criando o Design inicial

A fundação do bom design de interface é apropriação inteligente, ou seja, o design usacomo recurso o que já é conhecido pelo usuário.

3.1 Trabalho dentro dos quadros da Interface

Primeira apropriação é o padrão operacional que irá adotar. Ser for Macintosh, Motif ou Window. Cada sistema oferece um suporte à ferramenta de linguagem que descreve ascaracterísticas da interface como menus, botões, padrão de campos editáveis e afins.

3.2 Fazer o uso das aplicações existentes

A apropriação é encontrar bons aplicativos existentes que já fornecem algumas dasfuncionalidades que você precisa e pretende incorporar esses aplicativos em seu sistema.Você não será capaz de desenvolver uma ferramenta como Excel, portanto é mais fácil usar aexistente.

3.3 Copias de Técnicas de Interação de outros sistemas

Outro tipo de apropriação é de técnicas específicas de interação dos sistemasexistentes. Ações como movimento, memória, solução de problemas, atenção são exemplos.

3.4 Quando você precisa inventar

Os autores falam que, ao se inventar algo novo, e necessário primeiramente que estanovidade não seja apenas uma refinação do seu próprio design já existente, e sim um recursoque cause uma mudança central neste. Para isso, precisa haver a certificação de que estainovação seja pertinente ao contexto no qual será aplicada, é preciso ter certeza de suarelevância. Afirmam, ainda, que quando se cria, não se deve limitar esse processo apenas aoimaginário, à observação e à cópia de precedentes similares, mas sim colocá-lo em testeatravés de esboços e experimentos com usuários.

3.5 Princípios de Design Gráfico

Lewis e Rieman começam o capítulo discorrendo sobre as decisões envolvidas nacriação de uma interface digital - como cores, fontes, etc. Com o intuito de instruir e facilitar o processo de um projeto de interface, o autor pontua alguns princípios que ajudarão o

projetista a proporcionar uma melhor usabilidade a esta e a deixá-la mais atrativa.

- O princípio do agrupamento: Trata-se de organizar por meio de blocos separados oselementos de controle (menus, links, caixas de diálogo) que sejam similares entre si para que,através desse agrupamento, haja mais clareza e definição visual. Há duas razões importantes

para este princípio: em primeiro, temos o fato de que este ajuda o usuário a procurar com mais

1



facilidade o comando que precisa. Em segundo, o agrupamento de comandos ajuda o usuárioa adquirir também uma organização conceitual sobre o programa.

- O princípio da "Visibilidade que reflete Utilidade": Aconselha que se coloque os controles

mais frequentemente utilizados de maneira mais visível e com o acesso facilitado ou entãoque se encolha ou se escondam os controles usados com menor frequência. Aplicando esse princípio permite que o usuário encontre rapidamente os controles que mais usa.

- Princípio da Coerência inteligente: Defende o uso de telas semelhantes para funçõessemelhantes. É preciso ser cuidadoso para que, quando se tratarem de funções diferentes, astelas não fiquem parecidas umas com as outras (por exemplo, um pop-up com um aviso deerro crítico deve se diferenciar bem de um contendo ajuda ou uma mensagem informacional).

-Princípio da Cor como Suplemento: Defende o cuidado que se deve ter para não confiar à cor como transmissor de informações, mas sim como ferramenta pra dar ênfase a informações

cedidas por outros meios. É preciso ter cuidado com o uso das cores, pois estas são maiscomumente empregadas de uma forma indevida do que de maneira coerente. Devem-se levar em conta as questões culturais de cada cor, bem como o fato de que há parcelas de usuárioscom determinadas deficiências relacionadas a visão de cores.

-Princípio da Desordem reduzida: Não se deve colocar "muito" na tela. É uma boa forma deverificar se o projeto está seguindo os demais princípios citados anteriormente, uma vez que

para cumprir com esse último princípio é necessário que os controles mais utilizados estejam bem visíveis, que estejam agrupados em um pequeno grupo de clusters visual, que haja umuso de cores bem planejado, utilizando-se do mínimo possível destas e, finalmente, a tela deveser graficamente atraente. Este princípio defende que se varie o mínimo possível também emcaracterísticas como, por exemplo, o tamanho de fonte e seus modelos, pois uma grandevariedade de estilos em uma mesma tela causa desorganização e confusão.

4- Avaliando Design sem os usuários

4.1 Passo a passo cognitivo

A simulação cognitiva é um modo formalizado de imaginar os pensamentos e açõesdas pessoas quando elas usam uma interface pela primeira vez. Resumidamente, um passo a

passo é assim: Você tem um protótipo ou uma descrição pormenorizada da construção dointerface, e você sabe quem são os usuários serão. Você seleciona uma das tarefas que o projeto se destina a apoiar. Então você tenta contar uma história convincente sobre cada açãode um usuário a tomar para fazer a tarefa. Para fazer a história verídica é preciso motivar cadauma das ações do usuário, com base em conhecimentos gerais do usuário e as solicitações efeedback fornecido pela interface. Se você não pode contar uma história verossímil sobre umaação, então você localizou um problema com a interface.

4.1.1 Quem deve fazer um passo a passo, e quando?

Se a interface é projetada por você, as orientações podem ser informais (em sua

cabeça); já as interfaces mais robustas começam a fundir-se, então útil reunir-se com umgrupo de pessoas, incluindo outros designers e usuários, e fazer um passo a passo para uma

1



tarefa completa. O passo a passo é realmente uma ferramenta para o desenvolvimento dainterface, não para validá-la. O passo a passo em grupo deve ser feito por pessoas que estãomais ou menos ao mesmo nível na hierarquia da empresa.

4.1.2 O que é necessário antes que você pode fazer um passo a passo?

São necessárias quatro informações: (1) descrição ou um protótipo da interface. (2)descrição da tarefa. (3) uma lista, escrita completa das ações necessárias para completar atarefa com a interface. (4) uma idéia de quem são os usuários serão e qual o tipo deexperiência que eles trazem para o trabalho.

4.1.3 O que você deve procurar durante o passo a passo?

Ao fazer o passo a passo, você tentará contar uma história sobre o porquê do usuário

selecionar cada ação na lista das ações corretas. E a crítica da história para ser certa tem queser verídica. É recomendável manter quatro perguntas em mente como sua critica a história:

- Os usuários que estão tentando produzir qualquer efeito a ação?- Os usuários verão o controle (botão, menu, etc) para a ação?- Uma vez que os usuários encontram o controle, eles vão reconhecer que produz o efeitodesejado?- Após a ação tomada, os usuários irão perceber o feedback que recebem, para que eles

possam ir para a próxima ação com confiança?

4.1.4 O que fazer com os resultados do passo a passo?

Fixar a interface! Muitas das correções serão óbvias: tornar os controles mais óbvios,etiquetas de uso que os usuários reconhecerão, proporcionar um melhor feedback.Provavelmente, o problema mais difícil de corrigir é aquele em que o usuário não temnenhuma razão para pensar que uma ação precisa ser executada. Uma solução muito legal

para esse problema é eliminar a ação - deixar o sistema cuidar dela. Se isso não puder ser feito, então deverá ser possível reordenar as tarefas para que os usuários comecem a fazer algo que eles precisam saber fazer, e então ser solicitado para a ação em questão.

4.2 Análise de ação

Análise de ação é a avaliação feita a partir das ações de um usuário quando executauma determinada tarefa numa interface. Neste livro o autor Clayton Lewis apresenta doistipos de análises de ação: a análise formal e a análise “back of the envelope”. Enquanto a

primeira preocupa-se em analisar detalhes minuciosos, podendo prever o tempo de conclusãoda tarefa e até mesmo o tempo que o usuário leva para aprender a interface, a segunda

preocupa-se em revelar problemas que podem passar despercebidos pelo avaliador.A análise de ação formal tem sido utilizada para fazer previsões precisas do tempo que

um usuário leva para executar as tarefas numa interface. Para prever os tempos das tarefas, otempo para executar cada pequeno passo da tarefa, física ou mental, é estimado e, assim, ostempos são somados. O resultado final da análise, após dividir o desenvolvimento do processo

em várias sub-etapas, é uma descrição hierárquica de uma tarefa e a seqüência de açõesnecessárias para realizá-la. Este tipo de análise costuma ser bastante complexa, pois exige a

1



avaliação de tarefas que podem ser de apenas 10 segundos, mas que resultam em mais de milações do indivíduo e, ainda, o resultado de cada avaliador pode vir a ser diferente dependendoda visão da hierarquia de tarefas e das ações que um usuário irá tomar. Por este motivo ésempre necessário ter certeza de que este tipo de avaliação é a que mais convém a ser feita

para certa circunstância.A análise “back of the envelop”, assim como a análise formal, ela inicia-se em duasfases: realizar a lista de ações e analisá-la. A diferença entre elas é que nesta análise não énecessário uma avaliação hierárquica detalhada das ações, pode-se trabalhar apenas com umalista de ações naturais do usuário. Recomenda-se imaginar uma série de explicações edescrições das ações mentais que o usuário faria e, então, apontar algumas questões sobre ainterface, a fim de obter respostas úteis para todas essas perguntas sem entrar em detalhesfração de segundo. Este tipo de análise da ação é especialmente útil para decidir se quer ounão adicionar recursos a uma interface, ou até mesmo para um sistema.

4.3 Análise Heurística

Outro tipo de análise também possível é a análise heurística. Diferentemente dasoutras análises já apresentadas, que se concentram em apenas um avaliador encontrar

problemas na tarefa do usuário em contato com a interface, Jacob Nielsen e Rolf Molichdesenvolveram uma listagem de nove heurísticas gerais nas quais mais de um avaliador iráanalisar a interface. Assim, cada avaliador deverá fazer a análise sozinho e, em seguida,combinar os problemas identificados pelos outros avaliadores.

4.4 Resumo do Capítulo e Discussões

Escolher o tipo de análise a ser realizada para avaliar uma interface não é tarefa fácil.Ainda que seja bem aplicada, muitas vezes uma análise pode ser falha. Em análiseergonômica o recomendado é que se utilize mais de um tipo de técnica, que ainda assim,

pode-se encontrar problemas. Ao se realizar uma análise, portanto, não se tem a intenção deeliminar todos os problemas, mas sim minizá-los pois há tipos de problemas que nenhumdestes métodos captura e nenhuma análise individual é perfeita.

5- Testando o Design com usuários.

Antes de o projeto amadurecer é necessário fazer alguns testes de usuário para

observar o que acontece.

5.1 Escolhas de usuários para o teste

A intenção da escolha de usuários para testar é antecipar o que irá acontecer quandousuários reais utilizarem o sistema, deste modo, o melhor teste de usuários será feito comusuários teste o mais próximo possível dos usuários reais.

5.2 Seleções de tarefas para o teste

As tarefas de teste devem refletir o que as tarefas reais serão, o que indica a condução

de tarefas centradas no design. Caso pense em modificar alguma tarefa, tenha cuidado, para

1



não torná-las mais fáceis ou então dobrá-las na direção do que o design do projeto suportamelhor.

5.3 Fornecer um sistema para usuários de teste utilizarem

A chave para o teste no início do desenvolvimento do processo, quando ainda é possível fazer alterações no projeto sem incorrer a grandes custos é usar maquetes no teste.Estas são as versões do sistema que não implementam todo o projeto, mas mostram como ainterface se parece ou que o sistema faz e devem mostrar os recursos-chave para os usuários.As maquetes são mais baratas e menos acabadas que os protótipos, que são caros e maisacabados.

As maquetes mais simples são apenas imagens (fotos, desenhos ou interfacescomputadorizadas) de telas como elas aparecem em vários estágios de uma interação dousuário. O teste é feito com os usuários ao mostrar a primeira tela e perguntar-lhes o que elesfariam para realizar a tarefa atribuida. Eles descrevem a sua ação e fazem a próxima tela

aparecer. Como resultado desse processo uma série de informações são obtidas, comoentendimento e sequência das telas, assim como, a explicação cognitiva do usuário.

Se em algum momento durante o teste o usuário escolher uma possibilidade que nãoexixtir, deve-se gravar o que eles querem fazer, que são dados valiosos sobre a discrepânciaentre o esperado e o que eles queriam fazer. Então, o condutor do teste pode dar respostas aoque eles gostariam de achar ou então conduzir a outra opção. Com isso é possivel verificar seas principais linhas do sistema são sólidas.

Em alguns casos, pode-se evitar a implementação precoce do projeto falsificando a suaimplementação. Este é o método Mágico de OZ. Nele se recebe uma pessoa para emular funções não implementadas e gerar feedback que os usuários devem ver.

5.4 Decisão de quais dados coletar

Depois de ter as pessoas, tarefas, e sistema, é necessário descobrir qual a informação arecolher. É útil distinguir dados de processo e dados de linha de fundo. Os dados de processosão as observações do que os usuários de teste estão fazendo e pensando enquanto trabalhamnas tarefas. Essas observações dizem o que está acontecendo, passo a passo, e sugere por queestá acontecendo. Dados de linha de fundo dão um resumo do que aconteceu: quanto tempoos usuários levaram, se foram bem sucedidos, quantos erros fizeram. Para obter asinformações no qual se precisa saber o que os usuários estão pensando, não apenas o que elesestão fazendo, existe o método do pensamento em voz alta.

5.5 O método do pensamento em voz alta

Nesse método os usuários ao executarem uma tarefa de teste, também falam com ocondutor enquanto eles trabalham nela. O usuário fala o que está tentando fazer, osquestionamentos que surgem, as coisas que lêem. Esses dados podem ser gravados ou apenastomados em notas.

5.6 Medições de usabilidade

Existem algumas situações em que os números da linha de fundo são úteis. Uma

exigência definitiva que as pessoas sejam capazes de completar uma tarefa em umdeterminado período de tempo ou comparar duas alternativas de projeto com base na rapidez

1



com que as pessoas possam trabalhar ou quantos erros que cometem. A idéia básica é medir otempo que levam e contar seus erros. O processo de pensamento em voz alta pode afetar arapidez e precisão que as pessoas trabalham, mas também demonstra que leva as pessoas a

pensar com mais cuidado sobre o que estão fazendo e, consequentemente, ajudando-os a

escolher as melhores formas de fazer as coisas.

5.6.1 Analisando os números

Os números que se apresentam são tão variáveis que o condutor realmente não podedizer muito sobre o que vai ser "típico" em longo prazo. Há duas coisas que contribuem para aincerteza na interpretação desses resultados. Um deles é o pequeno número de usuários deteste.

Em Segundo os resultados destes testes são muito variáveis. É o trabalho de análiseestatística que deve ser utilizado para manipular tais fatores.

Os dados de teste de usabilidade são bastante variáveis, o que significa que se precisamuito dele para obter boas estimativas dos valores típicos.

Certamente o avaliador pode pedir para os usuários de teste uma classificação depoisde terminar o trabalho, digamos, pedindo-lhes para indicar o quanto eles gostaram do sistemaem uma escala de 1 a 10, ou escolhendo entre algumas afirmações. Uma complicaçãoadicional é que pessoas diferentes podem chegar ao mesmo valor, por motivos muitodiferentes.

5.6.2 Comparação de duas alternativas de projeto

Se você estiver usando medições da linha de fundo para comparar dois designsalternativos, as mesmas considerações se aplicam para um único projeto. Sua capacidade deextrair uma conclusão definitiva vai depender de como os números são variáveis, bem comoquantos utilizadores de teste que você usa. Então você precisa de alguma forma comparar osnúmeros que você ganha num projeto com os números dos outros.

A abordagem mais simples de usar é chamada de experimento entre os grupos. Você pode usar dois grupos de usuários de teste, um dos quais utiliza uma versão A do sistema e asoutras versão B. O que você quer saber é se o valor típico para a versão A é provável quedifiram do valor típico para a versão B. Outra abordagem é que você pode considerar umaexperiência intra-grupos. Aqui você usa apenas um grupo de usuários de teste e você começacada um deles para usar as duas versões do sistema. Você obviamente não pode usar as

mesmas tarefas para as duas versões, uma vez que fazer uma tarefa pela segunda vez seriadiferente de fazê-lo pela primeira vez, e você tem que se preocupar com quem usa qualsistema em primeiro lugar, porque poderia haver alguma vantagem ou desvantagem em ser osistema de alguém que tenta em primeiro lugar.

Você pode querer usar esta abordagem se você comparar duas técnicas de interação de baixo nível, por exemplo. Você pode saber mais sobre a abordagem intra-grupos a partir dequalquer texto padrão sobre a psicologia experimental.

5.7 Detalhes da configuração de um estudo de usabilidade

Os procedimentos que descrevemos são amplamente úteis, mas eles repousam sobre

alguns pressupostos para a validade técnica completa. Ambos os procedimentos assumem queseus números são desenhados a partir do que é chamado de "distribuição normal", e o

1



procedimento de comparação pressupõe que os dados de ambos os grupos provenientes dasdistribuições com o mesmo desvio padrão. Mas a experiência tem mostrado que essesmétodos funcionam razoavelmente bem, mesmo que, estes pressupostos sejam violados dealguma forma. Você fará bem se usá-los para a ampla orientação na interpretação de seus

dados. Quando você está realmente pronto para avaliar uma versão do projeto com osusuários, você vai ter que considerar alguns dos detalhes da criação e execução dos testes.

5.7.1 Escolha da Ordem de tarefas de teste

Normalmente, você deseja que os usuários de teste façam mais de uma tarefa. Issosignifica que eles têm de fazê-los em alguma ordem. O conselho é escolher uma formasensata, começando com algumas coisas simples e úteis até o ponto mais complexos. Istosignifica que as tarefas que vêm mais tarde, terão o benefício da prática sobre a primeira, oualguma pena dos usuários de teste ficar cansados, então você não pode comparar a dificuldade

de tarefas usando os resultados de um teste como este.

5.7.2 Teste de treinamento de usuários

Isso depende do que você está tentando descobrir, e a forma como o sistema seráusado na vida real. Se você realmente acredita que os usuários serão pré-formados, emseguida, treiná-los antes de seu teste, use os materiais de treinamento real para fazer isso:assim você pode aprender alguma coisa sobre o quão bem ou mal funcionam e faz parte deseu estudo.

5.7.3 O Estudo Piloto

Você deve sempre fazer um estudo-piloto, como parte de qualquer teste deusabilidade. Você vai descobrir se suas políticas na prestação de assistência são realmenteviáveis e se as instruções são bastante claras. Um estudo piloto irá ajudá-lo a manter-se abaixoda variabilidade em um estudo.

5.7.4 E se alguém não completar uma tarefa?

Se você está coletando números da linha de fundo, um problema que vai provavelmente encontrar é que nem todo mundo termina sua tarefa atribuída ou tarefas dentro

do tempo disponível, ou sem a ajuda do condutor. Uma abordagem razoável é atribuir umtempo muito grande, e um número muito grande de erros, como os "resultados" para essas pessoas.

5.7.5 Variabilidade

Diferenças entre os usuários de teste é uma fonte de resultados variáveis. Você podetentar recrutar mais usuários de teste com histórico pessoal semelhante, e você pode tentar usuários de teste para aproximá-los a algum nível comum de preparação para as suas tarefas.

As diferenças de procedimento, o que você realmente realizar no teste, também iráadicionar à variabilidade. Finalmente, se as pessoas não entendem o que estão fazendo a sua

variabilidade aumenta. Faça as suas instruções para teste de usuários e suas descrições detarefa tão clara quanto possível.

1



5.7.6 Teste de Usuários interrogados

Nós enfatizamos que não é aconselhável fazer perguntas específicas durante um

ensaio, as pessoas muitas vezes não lembram muito sobre os problemas que elas enfrentam,mesmo após um curto período de tempo.Uma forma de esclarecimento, que é menos problemática é pedir que comentem sobre

as características específicas da interface. As pessoas podem dar sugestões ou ter reações, positivas ou negativas, que poderiam não ser refletidas em seus dados. Isso funcionará melhor se você puder levar o usuário de volta através de várias telas que viram durante o teste.

CONSIDERAÇÕES FINAIS

O objetivo principal do livro é ensinar como o design de interfaces para o usuário irá

permitir que as pessoas aprendam rapidamente sistemas computacionais e usá-los de formaeficaz, eficiente e confortável. Os temas abordados são basicamente voltados às atividadesmentais como percepção, memória, aprendizagem e resolução de problemas. Como resultadode todas as medidas tomadas durante a concepção da interface para o usuário está o auxílio natomada das melhores decisões para o projeto.

O Designer tem que acompanhar toda etapa de desenvolvimento do projeto: início,meio, fim e depois da interface estar pronta, para ver se cumpre seu propósito e ver novasoportunidades para outros projetos. A descrição inicial do projeto deve ser feita no papel(maquete), o que força o condutor a pensar melhor; um protótipo pode ser utilizado tambémdependendo da necessidade e do aporte financeiro e até o Método do Mágico de OZ. Umbrainstorm entre a equipe do projeto ajuda no momento de elencar as idéias e atividades. Asfunções representativas do projeto devem ser utilizadas como uma lista de verificação paranão deixar de fora os pontos mais importantes. Quando objetivos de usabilidade são atendidosou quando a relação de custo e benefício se equilibra, os testes param.

O perfil gráfico do design também é discutido como palhetas de cores, agrupamentosna tela, coerências de telas e excesso de informação.

Ao seguir a linha do designer como participante ativo do processo da construção dainterface o autor aborda outros aspectos desde a fase de concepção de ideia, utilização dereferencias e processo de inovação.

Na concepção da ideia o processo cognitivo passo a passo de geração de uma interface pode ser feita individual ou em grupo dependendo do tamanho do projeto e complexidade da

interface. Ele auxilia no pensamento e nas ações das pessoas quando utilizarem a interface pela primeira vez.Outra linha relevante da pesquisa relata sobre os usuários e tarefas, ambos durante o

teste, devem estar o mais próximo de uma situação real. As instruções para o teste de usuáriose suas descrições de tarefa têm que ser o mais clara quanto possível.

Em relação aos dados e análise deles o autor relata que se deve pensar em quais dadosde usuários coletar, em como coletar (intra-grupo, intergrupo), fazer estudo piloto e qualmétodo de análise ou combinação de métodos de análise são mais interessantes. Durante aanálise dos dados o estudo estatístico deles, sua variabilidade e outros aspectos assim como aanálise da ação (ações do usuário pra previsões precisas do tempo para executar as tarefasnuma interface) e análise Heurística (uma lista que pode ser empregada na interface por um

avaliador e em seguida combinada com problemas identificados por outros avaliadores).

1



Ao finalizar o resumo fica a compreensão da relação direta da disciplina ergonomia deinterface com o design centrado na interface do usuário. O texto sugere que o estudo dainterface centrada no usuário leva o Designer a se preocupar com as expectativas do seucliente. Deste modo, o bom entendimento das atividades a serem desenvolvidas na interface, a

sequência das ações, economia de tempo, localização ideal das caixas na interface,atendimento do objetivo do usuário e como resultado final a satisfação do cliente.

1

Documents

eBook Ergonomia de Interface - Clayton Lewis & John Rieman