UFSC UNIVERSIDADE FEDERAL DE SANTA CATARINA CCE CENTRO DE COMUNICAO E EXPRESSO CURSO SUPERIOR DE DESIGN DISCIPLINA: EGR 5154

54 ERGONOMIA DE INTERFACE PROFESSORA: MARISA ARAJO CARVALHO

TAREFA DE DESIGN CENTRADO NA INTERFACE DO USURIO: UMA INTRODUO PRTICA por Lewis John Clayton e Rieman

BRENO TAKAMINE FERNANDA MORETTI RODRIGUES LETICIA DE FREITAS PIRES RAFAEL NARAVAN KIENEN RAISA HARUMI KAWASAKI THIAGO REGINALDO THULIO BECKER

FLORIANPOLIS 1

ABRIL DE 2011

SUMRIO 1- A tarefa centrada no processo de Design 1 1.1 Descobrir quem vai usar o sistema para fazer o que. 1.2 Escolher Tarefas Representantes para Design centrado em tarefas 1.3 Plagiar 1.4 Esboar o projeto 1.5 Pense Nisso 1.6 Criar uma Maquete ou Prottipo 1.7 Teste do Design com Usurios 1.8 Repetio (Iterao) 1.9 Construo do Design 1.10 Acompanhamento do Design 1.11 Mudana no Design 3- Criando o Design inicial 4 3.1 Trabalho dentro dos quadros da Interface 3.2 Fazer o uso das aplicaes existentes 3.3 Copias de Tcnicas de Interao de outros sistemas 3.4 Quando voc precisa inventar 3.5 Princpios de Design Grfico 4- Avaliando Design sem os usurios 5 4.1 Passo a passo cognitivo 4.1.1 Quem deve fazer um passo a passo, e quando? 4.1.2 O que necessrio antes que voc pode fazer um passo a passo? 4.1.3 O que voc deve procurar durante o passo a passo? 4.1.4 O que fazer com os resultados do passo a passo? 4.2 Anlise de ao 4.3 Anlise Heurstica 4.4 Resumo do Captulo e Discusses 5- Testando o Design com usurios. 7 5.1 Escolhas de usurios para o teste 5.2 Selees de tarefas para o teste 5.3 Fornecer um sistema para usurios de teste utilizarem 5.4 Deciso de quais dados coletar 5.5 O mtodo do pensamento em voz alta 5.6 Medies de usabilidade 5.6.1 Analisando os nmeros 5.6.2 Comparao de duas alternativas de projeto 5.7 Detalhes da configurao de um estudo de usabilidade 5.7.1 Escolha da Ordem de tarefas de teste 5.7.2 Teste de treinamento de usurios 5.7.3 O Estudo Piloto 5.7.4 E se algum no completar uma tarefa? 5.7.5 Variabilidade 5.7.6 Teste de Usurios interrogados CONSIDERAES FINAIS 11 1 1 2 2 2 2 3 3 3 3 3 4 4 4 4 4 5 5 6 6 6 6 7 7 7 7 7 8 8 8 9 9 9 10 10 10 10 10 10

TAREFA DE DESIGN CENTRADO NA INTERFACE DO USURIO: Uma Introduo Prtica por Lewis John Clayton e Rieman Este captulo apresenta uma viso geral da tarefa centrada no processo de concepo. O processo est estruturado em torno de tarefas especficas que o usurio deseja realizar com o sistema a ser desenvolvido. Essas tarefas so escolhidas no incio do projeto, em seguida, utilizadas para levantar questes sobre o mesmo, para auxiliar na tomada de decises de projeto e avaliar como ele desenvolvido. As etapas na tarefa de design centrado no processo so:

Descobrir quem que vai usar o sistema para fazer o que. Escolher tarefas representantes para o design centrado em tarefas. Plagiar. Esboar um projeto. Pense nisso. Criar um prottipo ou maquete. Teste com usurios. 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 anlise do usurio." Um sistema deve fazer o que necessrio mesclando harmoniosamente o mundo existente do usurio e da tarefa, tambm deve colocar as informaes de acordo com a tarefa tornando-a mais fcil. Devemos analisar os detalhes das tarefas que os usurios executam, observando as diversas consideraes sobre a interface, sabendo em qual nvel de entendimento eles esto. Tarefa eficaz e anlise do usurio requerem um contato pessoal entre os membros da equipe de projeto e as pessoas que iro realmente usar o sistema. certo que o contato inicial e continuado entre designers e usurios essencial para um bom projeto. 1.2 Escolher Tarefas Representantes para Design centrado em tarefas Depois de estabelecer uma boa compreenso dos usurios e suas tarefas, um processo de design mais tradicional pode abstrair a partir desses fatos e produzir uma especificao geral do sistema e de sua interface com o usurio. O processo de design centrado em tarefas leva a uma abordagem mais concreta. O designer deve identificar vrias tarefas representativas que o sistema ser utilizado para realizar. Estas devem ser as tarefas que os usurios tenham realmente descrito para os designers. As tarefas podem ser inicialmente referenciadas em poucas palavras, mas que so funes reais, que podem depois ser expandidas para qualquer nvel de detalhe necessrio para responder a questes de design ou analisar uma interface proposta. 1

As tarefas selecionadas devem fornecer uma cobertura razoavelmente completa da funcionalidade do sistema, e o designer pode querer fazer uma lista de funes e compar-las com as tarefas para garantir que a cobertura foi alcanada. Tambm deve haver uma mistura de tarefas simples e mais complexas. Produzir um conjunto eficaz de tarefas ser um verdadeiro teste de compreenso do designer, dos usurios e de seu trabalho. 1.3 Plagiar Voc deve encontrar interfaces existentes que trabalham para os utilizadores e, em seguida, construir idias a partir dessas interfaces em seus sistemas, tanto quanto na prtica e juridicamente possvel. Este tipo de cpia pode ser eficaz tanto para paradigmas de interao de alto nvel e para controle de baixo nvel. Nos nveis mais elevados, pense sobre tarefas representativas e os usurios que esto fazendo. Voc pode ser capaz de criar um novo paradigma de interao que mais adequado para sua aplicao, mas o risco de fracasso alto. Um paradigma existente ser mais rpido e mais fcil de implementar, porque muitas das decises de projeto j foram feitas. Mais importante, ser fcil e confortvel para os usurios a aprender e usar, porque eles j sabem muito da interface. Esta uma rea onde muito comum os designers tomarem a deciso errada, porque eles no parecem ir suficientemente longe das exigncias de seu prprio sistema. A maior parte das vezes, a melhor resposta ficar com o que os usurios saibam. 1.4 Esboar o projeto A descrio aproximada do projeto deve ser posta no papel, o que fora voc a pensar sobre as coisas. Mas no deve ser programada em um computador (ainda), porque o esforo de programao, mesmo com os sistemas mais simples de prototipagem, o designer acaba cometendo decises muito cedo no processo. Nesta fase, uma equipe de design vai ter muita discusso sobre as funcionalidades que o sistema deve incluir e como eles devem ser apresentados ao usurio. Essa discusso deve ser guiada pela abordagem de design centrado em tarefas. Se algum da equipe prope um novo recurso, outro membro da equipe deve perguntar qual das misses de representao que ele suporta. Caractersticas que no suportam qualquer uma das tarefas geralmente devem ser descartadas, ou a lista de tarefas deve ser modificada para incluir uma tarefa real que exerce essa funo. As funes representativas devem tambm ser usadas como uma espcie de lista de verificao para garantir que o sistema est completo. Se voc no pode trabalhar em cada tarefa com a definio atual do sistema, a definio precisa de ser melhorada. 1.5 Pense Nisso Os custos de construo de uma interface de usurio completa e testes com usurios suficientes para revelar todos os seus principais problemas so inaceitavelmente elevados. Existem vrias abordagens estruturadas que voc pode tomar para descobrir os pontos fortes e fracos de uma interface antes de constru-la. Um mtodo a contagem de digitao e operaes mentais (decises) para as tarefas que o projeto se destina a apoiar. Isso permitir que voc estime tempos de tarefa e identifique as tarefas que levam muitos passos.

1.6 Criar uma Maquete ou Prottipo Aps a descrio escrita do projeto, deve ser criado um modelo concreto para ser mostrado ao usurio. A principio pode ser feito apenas em esboos no papel (Maquete) ou utilizando ferramentas para prototipagem como HyperCard, Dan Bricklin's Demo Package ou User Interface Management System (UIMS). Com isso, ser possvel levantar muitas informaes relevantes para o projeto. O Prottipo deve se concentrar na interface necessria para tarefas representativas. Funcionalidades do sistema que ainda esto em produo podem ser emuladas com a tcnica Mgico de Oz onde o designer realiza as aes que ainda no foram programadas. 1.7 Teste do Design com Usurios H problemas que s aparecero quando o projeto for testado pelo usurio. Deve ser feita uma seleo de pessoas que se aproximem das caractersticas do usurio final. E eles devem relatar seus pensamentos enquanto testam a interface e experincia deve ser gravada e analisada posteriormente. 1.8 Repetio (Iterao) O teste com usurio apontar sempre apontar problemas, isto dar a possibilidade de melhorar a interface e repetir o teste. Deve ser levado em conta a gravidade do problema e o custo da correo. importante lembrar que as caractersticas da interface no so isoladas e ao resolver um problema outro problema pode surgir. Quando objetivos de usabilidade so atendidos ou quando a relao de custo e benefcio se equilibra, os testes param. 1.9 Construo do Design importante construir uma interface para que ela possa ser facilmente alterada. Antecipe mudanas que possam ser necessrias eventualmente como tamanho, cor e nmero de itens. A interface a maior parte da programao do produto. 1.10 Acompanhamento do Design O designer no deve estar isolado a apenas o desenvolvimento do projeto. O acompanhamento do projeto aps ele chegar ao usurio final. Isto, alm de verificar se o projeto cumpre seu propsito, pode trazer surpresas que abrem novas oportunidades de mercado. 1.11 Mudana no Design No mercado de hoje do computador h poucos ou nenhum produto de software que pode manter as suas vendas sem atualizaes regulares. As tarefas e os usurios mudam. Os usurios ganham novas habilidades e novas expectativas. Os designers precisam ficar a par destas mudanas, no apenas observando o local em que seus produtos esto instalados, mas tambm prestando ateno para a evoluo das outras partes da sociedade. A prxima reviso do projeto deve ser uma resposta no s aos problemas, mas tambm oportunidades. 1

3- Criando o Design inicial A fundao do bom design de interface apropriao inteligente, ou seja, o design usa como recurso o que j conhecido pelo usurio. 3.1 Trabalho dentro dos quadros da Interface Primeira apropriao o padro operacional que ir adotar. Ser for Macintosh, Motif ou Window. Cada sistema oferece um suporte ferramenta de linguagem que descreve as caractersticas da interface como menus, botes, padro de campos editveis e afins. 3.2 Fazer o uso das aplicaes existentes A apropriao encontrar bons aplicativos existentes que j fornecem algumas das funcionalidades que voc precisa e pretende incorporar esses aplicativos em seu sistema. Voc no ser capaz de desenvolver uma ferramenta como Excel, portanto mais fcil usar a existente. 3.3 Copias de Tcnicas de Interao de outros sistemas Outro tipo de apropriao de tcnicas especficas de interao dos sistemas existentes. Aes como movimento, memria, soluo de problemas, ateno so exemplos. 3.4 Quando voc precisa inventar Os autores falam que, ao se inventar algo novo, e necessrio primeiramente que esta novidade no seja apenas uma refinao do seu prprio design j existente, e sim um recurso que cause uma mudana central neste. Para isso, precisa haver a certificao de que esta inovao seja pertinente ao contexto no qual ser aplicada, preciso ter certeza de sua relevncia. Afirmam, ainda, que quando se cria, no se deve limitar esse processo apenas ao imaginrio, observao e cpia de precedentes similares, mas sim coloc-lo em teste atravs de esboos e experimentos com usurios. 3.5 Princpios de Design Grfico Lewis e Rieman comeam o captulo discorrendo sobre as decises envolvidas na criao 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 princpios que ajudaro o projetista a proporcionar uma melhor usabilidade a esta e a deix-la mais atrativa. - O princpio do agrupamento: Trata-se de organizar por meio de blocos separados os elementos de controle (menus, links, caixas de dilogo) que sejam similares entre si para que, atravs desse agrupamento, haja mais clareza e definio visual. H duas razes importantes para este princpio: em primeiro, temos o fato de que este ajuda o usurio a procurar com mais

facilidade o comando que precisa. Em segundo, o agrupamento de comandos ajuda o usurio a adquirir tambm uma organizao conceitual sobre o programa. - O princpio da "Visibilidade que reflete Utilidade": Aconselha que se coloque os controles mais frequentemente utilizados de maneira mais visvel e com o acesso facilitado ou ento que se encolha ou se escondam os controles usados com menor frequncia. Aplicando esse princpio permite que o usurio encontre rapidamente os controles que mais usa. - Princpio da Coerncia inteligente: Defende o uso de telas semelhantes para funes semelhantes. preciso ser cuidadoso para que, quando se tratarem de funes diferentes, as telas no fiquem parecidas umas com as outras (por exemplo, um pop-up com um aviso de erro crtico deve se diferenciar bem de um contendo ajuda ou uma mensagem informacional). -Princpio da Cor como Suplemento: Defende o cuidado que se deve ter para no confiar cor como transmissor de informaes, mas sim como ferramenta pra dar nfase a informaes cedidas por outros meios. preciso ter cuidado com o uso das cores, pois estas so mais comumente empregadas de uma forma indevida do que de maneira coerente. Devem-se levar em conta as questes culturais de cada cor, bem como o fato de que h parcelas de usurios com determinadas deficincias relacionadas a viso de cores. -Princpio da Desordem reduzida: No se deve colocar "muito" na tela. uma boa forma de verificar se o projeto est seguindo os demais princpios citados anteriormente, uma vez que para cumprir com esse ltimo princpio necessrio que os controles mais utilizados estejam bem visveis, que estejam agrupados em um pequeno grupo de clusters visual, que haja um uso de cores bem planejado, utilizando-se do mnimo possvel destas e, finalmente, a tela deve ser graficamente atraente. Este princpio defende que se varie o mnimo possvel tambm em caractersticas como, por exemplo, o tamanho de fonte e seus modelos, pois uma grande variedade de estilos em uma mesma tela causa desorganizao e confuso. 4- Avaliando Design sem os usurios 4.1 Passo a passo cognitivo A simulao cognitiva um modo formalizado de imaginar os pensamentos e aes das pessoas quando elas usam uma interface pela primeira vez. Resumidamente, um passo a passo assim: Voc tem um prottipo ou uma descrio pormenorizada da construo do interface, e voc sabe quem so os usurios sero. Voc seleciona uma das tarefas que o projeto se destina a apoiar. Ento voc tenta contar uma histria convincente sobre cada ao de um usurio a tomar para fazer a tarefa. Para fazer a histria verdica preciso motivar cada uma das aes do usurio, com base em conhecimentos gerais do usurio e as solicitaes e feedback fornecido pela interface. Se voc no pode contar uma histria verossmil sobre uma ao, ento 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 orientaes podem ser informais (em sua cabea); j as interfaces mais robustas comeam a fundir-se, ento til reunir-se com um grupo de pessoas, incluindo outros designers e usurios, e fazer um passo a passo para uma 1

tarefa completa. O passo a passo realmente uma ferramenta para o desenvolvimento da interface, no para valid-la. O passo a passo em grupo deve ser feito por pessoas que esto mais ou menos ao mesmo nvel na hierarquia da empresa. 4.1.2 O que necessrio antes que voc pode fazer um passo a passo? So necessrias quatro informaes: (1) descrio ou um prottipo da interface. (2) descrio da tarefa. (3) uma lista, escrita completa das aes necessrias para completar a tarefa com a interface. (4) uma idia de quem so os usurios sero e qual o tipo de experincia 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 histria sobre o porqu do usurio selecionar cada ao na lista das aes corretas. E a crtica da histria para ser certa tem que ser verdica. recomendvel manter quatro perguntas em mente como sua critica a histria: - Os usurios que esto tentando produzir qualquer efeito a ao? - Os usurios vero o controle (boto, menu, etc) para a ao? - Uma vez que os usurios encontram o controle, eles vo reconhecer que produz o efeito desejado? - Aps a ao tomada, os usurios iro perceber o feedback que recebem, para que eles possam ir para a prxima ao com confiana? 4.1.4 O que fazer com os resultados do passo a passo? Fixar a interface! Muitas das correes sero bvias: tornar os controles mais bvios, etiquetas de uso que os usurios reconhecero, proporcionar um melhor feedback. Provavelmente, o problema mais difcil de corrigir aquele em que o usurio no tem nenhuma razo para pensar que uma ao precisa ser executada. Uma soluo muito legal para esse problema eliminar a ao - deixar o sistema cuidar dela. Se isso no puder ser feito, ento dever ser possvel reordenar as tarefas para que os usurios comecem a fazer algo que eles precisam saber fazer, e ento ser solicitado para a ao em questo. 4.2 Anlise de ao Anlise de ao a avaliao feita a partir das aes de um usurio quando executa uma determinada tarefa numa interface. Neste livro o autor Clayton Lewis apresenta dois tipos de anlises de ao: a anlise formal e a anlise back of the envelope. Enquanto a primeira preocupa-se em analisar detalhes minuciosos, podendo prever o tempo de concluso da tarefa e at mesmo o tempo que o usurio leva para aprender a interface, a segunda preocupa-se em revelar problemas que podem passar despercebidos pelo avaliador. A anlise de ao formal tem sido utilizada para fazer previses precisas do tempo que um usurio leva para executar as tarefas numa interface. Para prever os tempos das tarefas, o tempo para executar cada pequeno passo da tarefa, fsica ou mental, estimado e, assim, os tempos so somados. O resultado final da anlise, aps dividir o desenvolvimento do processo em vrias sub-etapas, uma descrio hierrquica de uma tarefa e a seqncia de aes necessrias para realiz-la. Este tipo de anlise costuma ser bastante complexa, pois exige a 1

avaliao de tarefas que podem ser de apenas 10 segundos, mas que resultam em mais de mil aes do indivduo e, ainda, o resultado de cada avaliador pode vir a ser diferente dependendo da viso da hierarquia de tarefas e das aes que um usurio ir tomar. Por este motivo sempre necessrio ter certeza de que este tipo de avaliao a que mais convm a ser feita para certa circunstncia. A anlise back of the envelop, assim como a anlise formal, ela inicia-se em duas fases: realizar a lista de aes e analis-la. A diferena entre elas que nesta anlise no necessrio uma avaliao hierrquica detalhada das aes, pode-se trabalhar apenas com uma lista de aes naturais do usurio. Recomenda-se imaginar uma srie de explicaes e descries das aes mentais que o usurio faria e, ento, apontar algumas questes sobre a interface, a fim de obter respostas teis para todas essas perguntas sem entrar em detalhes frao de segundo. Este tipo de anlise da ao especialmente til para decidir se quer ou no adicionar recursos a uma interface, ou at mesmo para um sistema. 4.3 Anlise Heurstica Outro tipo de anlise tambm possvel a anlise heurstica. Diferentemente das outras anlises j apresentadas, que se concentram em apenas um avaliador encontrar problemas na tarefa do usurio em contato com a interface, Jacob Nielsen e Rolf Molich desenvolveram uma listagem de nove heursticas gerais nas quais mais de um avaliador ir analisar a interface. Assim, cada avaliador dever fazer a anlise sozinho e, em seguida, combinar os problemas identificados pelos outros avaliadores. 4.4 Resumo do Captulo e Discusses Escolher o tipo de anlise a ser realizada para avaliar uma interface no tarefa fcil. Ainda que seja bem aplicada, muitas vezes uma anlise pode ser falha. Em anlise ergonmica o recomendado que se utilize mais de um tipo de tcnica, que ainda assim, pode-se encontrar problemas. Ao se realizar uma anlise, portanto, no se tem a inteno de eliminar todos os problemas, mas sim miniz-los pois h tipos de problemas que nenhum destes mtodos captura e nenhuma anlise individual perfeita. 5- Testando o Design com usurios. Antes de o projeto amadurecer necessrio fazer alguns testes de usurio para observar o que acontece. 5.1 Escolhas de usurios para o teste A inteno da escolha de usurios para testar antecipar o que ir acontecer quando usurios reais utilizarem o sistema, deste modo, o melhor teste de usurios ser feito com usurios teste o mais prximo possvel dos usurios reais. 5.2 Selees de tarefas para o teste As tarefas de teste devem refletir o que as tarefas reais sero, o que indica a conduo de tarefas centradas no design. Caso pense em modificar alguma tarefa, tenha cuidado, para

no torn-las mais fceis ou ento dobr-las na direo do que o design do projeto suporta melhor. 5.3 Fornecer um sistema para usurios de teste utilizarem A chave para o teste no incio do desenvolvimento do processo, quando ainda possvel fazer alteraes no projeto sem incorrer a grandes custos usar maquetes no teste. Estas so as verses do sistema que no implementam todo o projeto, mas mostram como a interface se parece ou que o sistema faz e devem mostrar os recursos-chave para os usurios. As maquetes so mais baratas e menos acabadas que os prottipos, que so caros e mais acabados. As maquetes mais simples so apenas imagens (fotos, desenhos ou interfaces computadorizadas) de telas como elas aparecem em vrios estgios de uma interao do usurio. O teste feito com os usurios ao mostrar a primeira tela e perguntar-lhes o que eles fariam para realizar a tarefa atribuida. Eles descrevem a sua ao e fazem a prxima tela aparecer. Como resultado desse processo uma srie de informaes so obtidas, como entendimento e sequncia das telas, assim como, a explicao cognitiva do usurio. Se em algum momento durante o teste o usurio escolher uma possibilidade que no exixtir, deve-se gravar o que eles querem fazer, que so dados valiosos sobre a discrepncia entre o esperado e o que eles queriam fazer. Ento, o condutor do teste pode dar respostas ao que eles gostariam de achar ou ento conduzir a outra opo. Com isso possivel verificar se as principais linhas do sistema so slidas. Em alguns casos, pode-se evitar a implementao precoce do projeto falsificando a sua implementao. Este o mtodo Mgico de OZ. Nele se recebe uma pessoa para emular funes no implementadas e gerar feedback que os usurios devem ver. 5.4 Deciso de quais dados coletar Depois de ter as pessoas, tarefas, e sistema, necessrio descobrir qual a informao a recolher. til distinguir dados de processo e dados de linha de fundo. Os dados de processo so as observaes do que os usurios de teste esto fazendo e pensando enquanto trabalham nas tarefas. Essas observaes dizem o que est acontecendo, passo a passo, e sugere por que est acontecendo. Dados de linha de fundo do um resumo do que aconteceu: quanto tempo os usurios levaram, se foram bem sucedidos, quantos erros fizeram. Para obter as informaes no qual se precisa saber o que os usurios esto pensando, no apenas o que eles esto fazendo, existe o mtodo do pensamento em voz alta. 5.5 O mtodo do pensamento em voz alta Nesse mtodo os usurios ao executarem uma tarefa de teste, tambm falam com o condutor enquanto eles trabalham nela. O usurio fala o que est tentando fazer, os questionamentos que surgem, as coisas que lem. Esses dados podem ser gravados ou apenas tomados em notas. 5.6 Medies de usabilidade Existem algumas situaes em que os nmeros da linha de fundo so teis. Uma exigncia definitiva que as pessoas sejam capazes de completar uma tarefa em um determinado perodo 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 idia bsica medir o tempo que levam e contar seus erros. O processo de pensamento em voz alta pode afetar a rapidez e preciso que as pessoas trabalham, mas tambm demonstra que leva as pessoas a pensar com mais cuidado sobre o que esto fazendo e, consequentemente, ajudando-os a escolher as melhores formas de fazer as coisas. 5.6.1 Analisando os nmeros Os nmeros que se apresentam so to variveis que o condutor realmente no pode dizer muito sobre o que vai ser "tpico" em longo prazo. H duas coisas que contribuem para a incerteza na interpretao desses resultados. Um deles o pequeno nmero de usurios de teste. Em Segundo os resultados destes testes so muito variveis. o trabalho de anlise estatstica que deve ser utilizado para manipular tais fatores. Os dados de teste de usabilidade so bastante variveis, o que significa que se precisa muito dele para obter boas estimativas dos valores tpicos. Certamente o avaliador pode pedir para os usurios de teste uma classificao depois de terminar o trabalho, digamos, pedindo-lhes para indicar o quanto eles gostaram do sistema em uma escala de 1 a 10, ou escolhendo entre algumas afirmaes. Uma complicao adicional que pessoas diferentes podem chegar ao mesmo valor, por motivos muito diferentes. 5.6.2 Comparao de duas alternativas de projeto Se voc estiver usando medies da linha de fundo para comparar dois designs alternativos, as mesmas consideraes se aplicam para um nico projeto. Sua capacidade de extrair uma concluso definitiva vai depender de como os nmeros so variveis, bem como quantos utilizadores de teste que voc usa. Ento voc precisa de alguma forma comparar os nmeros que voc ganha num projeto com os nmeros dos outros. A abordagem mais simples de usar chamada de experimento entre os grupos. Voc pode usar dois grupos de usurios de teste, um dos quais utiliza uma verso A do sistema e as outras verso B. O que voc quer saber se o valor tpico para a verso A provvel que difiram do valor tpico para a verso B. Outra abordagem que voc pode considerar uma experincia intra-grupos. Aqui voc usa apenas um grupo de usurios de teste e voc comea cada um deles para usar as duas verses do sistema. Voc obviamente no pode usar as mesmas tarefas para as duas verses, uma vez que fazer uma tarefa pela segunda vez seria diferente de faz-lo pela primeira vez, e voc tem que se preocupar com quem usa qual sistema em primeiro lugar, porque poderia haver alguma vantagem ou desvantagem em ser o sistema de algum que tenta em primeiro lugar. Voc pode querer usar esta abordagem se voc comparar duas tcnicas de interao de baixo nvel, por exemplo. Voc pode saber mais sobre a abordagem intra-grupos a partir de qualquer texto padro sobre a psicologia experimental. 5.7 Detalhes da configurao de um estudo de usabilidade Os procedimentos que descrevemos so amplamente teis, mas eles repousam sobre alguns pressupostos para a validade tcnica completa. Ambos os procedimentos assumem que seus nmeros so desenhados a partir do que chamado de "distribuio normal", e o 1

procedimento de comparao pressupe que os dados de ambos os grupos provenientes das distribuies com o mesmo desvio padro. Mas a experincia tem mostrado que esses mtodos funcionam razoavelmente bem, mesmo que, estes pressupostos sejam violados de alguma forma. Voc far bem se us-los para a ampla orientao na interpretao de seus dados. Quando voc est realmente pronto para avaliar uma verso do projeto com os usurios, voc vai ter que considerar alguns dos detalhes da criao e execuo dos testes. 5.7.1 Escolha da Ordem de tarefas de teste Normalmente, voc deseja que os usurios de teste faam mais de uma tarefa. Isso significa que eles tm de faz-los em alguma ordem. O conselho escolher uma forma sensata, comeando com algumas coisas simples e teis at o ponto mais complexos. Isto significa que as tarefas que vm mais tarde, tero o benefcio da prtica sobre a primeira, ou alguma pena dos usurios de teste ficar cansados, ento voc no pode comparar a dificuldade de tarefas usando os resultados de um teste como este. 5.7.2 Teste de treinamento de usurios 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 usurios sero pr-formados, em seguida, trein-los antes de seu teste, use os materiais de treinamento real para fazer isso: assim voc pode aprender alguma coisa sobre o quo bem ou mal funcionam e faz parte de seu estudo. 5.7.3 O Estudo Piloto Voc deve sempre fazer um estudo-piloto, como parte de qualquer teste de usabilidade. Voc vai descobrir se suas polticas na prestao de assistncia so realmente viveis e se as instrues so bastante claras. Um estudo piloto ir ajud-lo a manter-se abaixo da variabilidade em um estudo. 5.7.4 E se algum no completar uma tarefa? Se voc est coletando nmeros da linha de fundo, um problema que vai provavelmente encontrar que nem todo mundo termina sua tarefa atribuda ou tarefas dentro do tempo disponvel, ou sem a ajuda do condutor. Uma abordagem razovel atribuir um tempo muito grande, e um nmero muito grande de erros, como os "resultados" para essas pessoas. 5.7.5 Variabilidade Diferenas entre os usurios de teste uma fonte de resultados variveis. Voc pode tentar recrutar mais usurios de teste com histrico pessoal semelhante, e voc pode tentar usurios de teste para aproxim-los a algum nvel comum de preparao para as suas tarefas. As diferenas de procedimento, o que voc realmente realizar no teste, tambm ir adicionar variabilidade. Finalmente, se as pessoas no entendem o que esto fazendo a sua variabilidade aumenta. Faa as suas instrues para teste de usurios e suas descries de tarefa to clara quanto possvel. 1

5.7.6 Teste de Usurios interrogados Ns enfatizamos que no aconselhvel fazer perguntas especficas durante um ensaio, as pessoas muitas vezes no lembram muito sobre os problemas que elas enfrentam, mesmo aps um curto perodo de tempo. Uma forma de esclarecimento, que menos problemtica pedir que comentem sobre as caractersticas especficas da interface. As pessoas podem dar sugestes ou ter reaes, positivas ou negativas, que poderiam no ser refletidas em seus dados. Isso funcionar melhor se voc puder levar o usurio de volta atravs de vrias telas que viram durante o teste. CONSIDERAES FINAIS O objetivo principal do livro ensinar como o design de interfaces para o usurio ir permitir que as pessoas aprendam rapidamente sistemas computacionais e us-los de forma eficaz, eficiente e confortvel. Os temas abordados so basicamente voltados s atividades mentais como percepo, memria, aprendizagem e resoluo de problemas. Como resultado de todas as medidas tomadas durante a concepo da interface para o usurio est o auxlio na tomada das melhores decises para o projeto. O Designer tem que acompanhar toda etapa de desenvolvimento do projeto: incio, meio, fim e depois da interface estar pronta, para ver se cumpre seu propsito e ver novas oportunidades para outros projetos. A descrio inicial do projeto deve ser feita no papel (maquete), o que fora o condutor a pensar melhor; um prottipo pode ser utilizado tambm dependendo da necessidade e do aporte financeiro e at o Mtodo do Mgico de OZ. Um brainstorm entre a equipe do projeto ajuda no momento de elencar as idias e atividades. As funes representativas do projeto devem ser utilizadas como uma lista de verificao para no deixar de fora os pontos mais importantes. Quando objetivos de usabilidade so atendidos ou quando a relao de custo e benefcio se equilibra, os testes param. O perfil grfico do design tambm discutido como palhetas de cores, agrupamentos na tela, coerncias de telas e excesso de informao. Ao seguir a linha do designer como participante ativo do processo da construo da interface o autor aborda outros aspectos desde a fase de concepo de ideia, utilizao de referencias e processo de inovao. Na concepo da ideia o processo cognitivo passo a passo de gerao 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 aes das pessoas quando utilizarem a interface pela primeira vez. Outra linha relevante da pesquisa relata sobre os usurios e tarefas, ambos durante o teste, devem estar o mais prximo de uma situao real. As instrues para o teste de usurios e suas descries de tarefa tm que ser o mais clara quanto possvel. Em relao aos dados e anlise deles o autor relata que se deve pensar em quais dados de usurios coletar, em como coletar (intra-grupo, intergrupo), fazer estudo piloto e qual mtodo de anlise ou combinao de mtodos de anlise so mais interessantes. Durante a anlise dos dados o estudo estatstico deles, sua variabilidade e outros aspectos assim como a anlise da ao (aes do usurio pra previses precisas do tempo para executar as tarefas numa interface) e anlise Heurstica (uma lista que pode ser empregada na interface por um avaliador e em seguida combinada com problemas identificados por outros avaliadores).

Ao finalizar o resumo fica a compreenso da relao direta da disciplina ergonomia de interface com o design centrado na interface do usurio. O texto sugere que o estudo da interface centrada no usurio leva o Designer a se preocupar com as expectativas do seu cliente. Deste modo, o bom entendimento das atividades a serem desenvolvidas na interface, a sequncia das aes, economia de tempo, localizao ideal das caixas na interface, atendimento do objetivo do usurio e como resultado final a satisfao do cliente.