Universidade Federal de Minas Gerais idade Instituto de Cincias Exatas Departamento de Cincia da Computao

Engenharia de Usabilidade Material de Referncia

Professor: Clarindo Isaas Pereira da Silva e Pdua

Belo Horizonte, MG Julho de 20111

SUMRIO

SUMRIO ................................................................................................................... 2 1 Introduo........................................................................................................... 5 1.1 Apresentao ................................................................................................ 5 1.1.1 Objetivos da disciplina ............................................................................. 5 1.1.2 contedo da disciplina ............................................................................. 5 1.2 Introduo usabilidade ................................................................................ 7 1.2.1 Benefcios ............................................................................................... 9 1.3 Glossrio ......................................................................................................12 1.4 Bibliografia ...................................................................................................12 2 Princpios de desenho ..........................................................................................13 2.1 Ciclo de execuo de uma ao .....................................................................14 2.2 Distribuio da informao ............................................................................16 2.3 Psicologia dos materiais/serventia ...............................................................17 2.4 Visibilidade ...................................................................................................19 2.5 Modelo mental..............................................................................................20 2.6 Mapeamentos ...............................................................................................21 2.7 Realimentao ..............................................................................................23 2.8 Ateno aos requisitos ..................................................................................24 2.9 Funo de fora............................................................................................25 2.10 Bibliografia ...................................................................................................26 3 Processo visando a usabilidade .............................................................................26 3.1 Detalhes de implementao do praxis-u..........................................................28 3.2 Atividades do fluxo de usabilidade ..................................................................28 3.2.1 Atividades gerenciais ..............................................................................30 3.2.2 Atividades tcnicas .................................................................................31 3.3 Glossrio ......................................................................................................39 3.4 Bibliografia ...................................................................................................40 4 Anlise de contexto de uso ..................................................................................41 4.1 Tcnicas ......................................................................................................42 4.1.1 Observao direta ..................................................................................43 4.1.2 Entrevistas ............................................................................................43 4.1.3 Levantamento por questionrio ...............................................................44 4.1.4 Fontes de informao .............................................................................45 4.2 Subprocesso de Anlise de contexto de uso ....................................................49 4.2.1 Viso geral ............................................................................................50 4.2.2 Planejamento.........................................................................................51 4.2.3 Preparao ............................................................................................54 4.2.4 Modelagem de usurios ..........................................................................55 4.2.5 Modelagem de tarefas ............................................................................56 4.2.6 Anlise de Produtos Concorrentes ou Similares .........................................56 4.2.7 Balano final ..........................................................................................56 4.3 Anlise de usurios .......................................................................................57 4.3.1 Viso geral ............................................................................................57 4.3.2 Objetivos ...............................................................................................58 4.3.3 Personas ...............................................................................................59 2

4.3.4 Detalhamento das atividades do subprocesso ...........................................74 4.4 Anlise de tarefas .........................................................................................78 4.4.1 Viso geral ............................................................................................81 4.4.2 Objetivos ...............................................................................................82 4.4.3 Roteiros de domnio de problema ............................................................83 4.4.4 Detalhamento das atividades do subprocesso de Anlise de tarefas ............87 4.4.5 Anlise de necessidades .........................................................................90 4.5 Anlise de ambiente......................................................................................93 4.6 Anlise de produtos concorrentes ou similares ................................................96 4.7 Glossrio ......................................................................................................97 4.8 Bibliografia ...................................................................................................97 Especificao de requisitos de usabilidade .............................................................98 5.1 Viso geral ...................................................................................................98 5.2 Tabela de especificao de requisitos de usabilidade ..................................... 100 5.2.1 Atributos de Usabilidade ....................................................................... 102 5.2.2 Ator .................................................................................................... 103 5.2.3 Instrumento de medida ........................................................................ 104 5.2.4 Valor a ser medido ............................................................................... 107 5.2.5 Nveis de desempenho .......................................................................... 108 5.2.6 Diretrizes para definio da Tabela ERU ................................................. 111 5.3 Glossrio .................................................................................................... 113 5.4 Bibliografia ................................................................................................. 113 Desenho da Interao ....................................................................................... 113 6.1 Atividade de Desenho da interao............................................................... 115 6.1.1 Modelagem conceitual .......................................................................... 117 6.1.2 Modelagem de contedo e navegao.................................................... 123 6.1.3 Desenho detalhado .............................................................................. 124 6.2 Guia de Estilo de Usabilidade ....................................................................... 125 6.3 Glossrio .................................................................................................... 130 6.4 Bibliografia ................................................................................................. 130 Avaliao de usabilidade .................................................................................... 131 7.1 Objetivos ................................................................................................... 132 7.2 Tcnicas .................................................................................................... 134 7.2.1 Analticas ............................................................................................. 134 7.2.2 Avaliaes experimentais ...................................................................... 136 7.2.3 Pesquisa de opinio .............................................................................. 137 7.3 Subprocesso de avaliao de usabilidade ...................................................... 138 7.3.1 Viso geral .......................................................................................... 139 7.3.2 Detalhamento das atividades................................................................. 142 7.4 Padro de Descrio de Avaliao de Usabilidade .......................................... 159 7.4.1 Descrio das Avaliaes de Usabilidade ................................................ 159 7.4.2 Relatrio de Avaliaes de Usabilidade ................................................... 160 7.5 Glossrio .................................................................................................... 160 7.6 Bibliografia ................................................................................................. 160 Diretrizes de usabilidade .................................................................................... 161 8.1 Fundamentos de desenho............................................................................ 162 8.2 Princpios ................................................................................................... 163 8.3 Diretrizes ................................................................................................... 167 8.4 Glossrio .................................................................................................... 178 8.5 Bibliografia ................................................................................................. 179 Elementos de Interao ..................................................................................... 179 3

9.1 Interfaces Grficas ...................................................................................... 180 9.1.1 Janelas (windows) ................................................................................ 180 9.1.2 Menus (menu) ..................................................................................... 181 9.1.3 Formulrios (Forms) ............................................................................. 189 9.1.4 Caixas (box) ........................................................................................ 191 9.2 Interfaces grficas em sentido amplo ........................................................... 194 9.2.1 Visualizao de dados ........................................................................... 195 9.2.2 Bancos de dados visuais ....................................................................... 195 9.2.3 Animaes ........................................................................................... 196 9.2.4 Vdeo (e udio) .................................................................................... 197 9.2.5 Realidade virtual .................................................................................. 197 9.3 Linguagem de comandos ............................................................................. 198 9.4 Outros elementos de interao .................................................................... 199 9.4.1 Tela de toque ...................................................................................... 199 9.4.2 Sntese da fala ..................................................................................... 200 9.4.3 Reconhecimento da fala e Linguagem natural ......................................... 200 9.5 Glossrio .................................................................................................... 201 9.6 Bibliografia ................................................................................................. 201 10 Glossrio ....................................................................................................... 201 11 Bibliografia .................................................................................................... 202

1 INTRODUO

1.1 APRESENTAO
Este documento foi desenvolvido para uso dos alunos da disciplina de Engenharia de Usabilidade. O contedo aqui abordado prov ao aluno o conhecimento bsico necessrio ao projeto da interao do usurio em um sistema de software, sendo este contedo contextualizado em um processo de desenvolvimento de software visando usabilidade.

1.1.1 OBJETIVOS DA DISCIPLINA

A disciplina de Engenharia de Usabilidade tem por objetivo apresentar tcnicas, conceitos e mtodos que podem ser utilizados sistematicamente para assegurar um alto grau de usabilidade na interface final de programas de computador. Usabilidade refere-se qualidade da interao usurio-computador proporcionada pela interface de um sistema de computao. Os benefcios alcanados pela aplicao de tcnicas da engenharia de usabilidade so visveis tanto no aspecto de eficincia e eficcia da interface como tambm se expressam em processos de desenvolvimento de software mais produtivos, confiveis e com maior satisfao dos usurios e clientes. O projeto de interfaces do usurio um dos principais objetivos da Engenharia de Usabilidade. O contedo da disciplina inclui tanto o produto, a prpria interface, como o processo, compreendendo metodologia e tcnicas usadas dentro de um ciclo de desenvolvimento de software. Uma abordagem de Engenharia ser adotada, no sentido de que as tcnicas utilizadas sero baseadas em mtodos onde utilizamos quantificaes visando estabelecer parmetros para avaliao de aspectos subjetivos. Ao final do curso o aluno dever conhecer as principais tcnicas utilizadas no projeto de interface com o usurio visando usabilidade e ser capaz de aplicar essas tcnicas no contexto de um processo de desenvolvimento de software.

1.1.2 CONTEDO DA DISCIPLINA

5

Para conceituar Usabilidade, podemos utilizar as normas ISO 9241 (ISO 92141, 1998), que trata de requisitos ergonmicos de trabalhos em escritrio com terminais visuais, e ISO/IEC 9126 (ISO/IEC 9126), que trata da qualidade de produtos de software. Segundo a norma ISO 9241, usabilidade a capacidade que um sistema interativo oferece a seu usurio, em um determinado contexto de operao, para a realizao de tarefas de maneira eficaz, eficiente e agradvel. J segundo a norma ISO/IEC 9126, usabilidade a facilidade com que um usurio pode aprender a operar, preparar entradas para e interpretar as sadas de um sistema ou componente. Simplificando, podemos dizer que a usabilidade est associada a uma caracterstica de qualidade de software que se refere sua adequao utilizao pelos usurios. A usabilidade trata da qualidade da interao usurio-computador proporcionada pela interface de um sistema de computao. importante salientar que a usabilidade est sempre associada a um contexto de utilizao do produto; a adequao ao uso significa adequao ao tipo de tarefas ou atividades que se pretende realizar com o produto de software, ao tipo de usurios que tipicamente utiliza o produto e ao ambiente de utilizao do produto. Segundo o dicionrio Aurlio, engenharia a arte de aplicar conhecimentos cientficos e empricos e certas habilitaes especficas criao de estruturas, dispositivos e processos que se utilizam para converter recursos naturais em formas adequadas ao atendimento das necessidades humanas. Neste documento, uma abordagem de Engenharia ser adotada, no sentido de que sero apresentados processos e tcnicas relacionadas ao desenvolvimento da interao, buscando-se a quantificao de resultados para que se possa executar o processo de forma controlada. O termo desenvolvimento da interao refere-se ao desenvolvimento da interface com o usurio nos aspectos relacionados usabilidade. A Engenharia de Usabilidade visa o desenvolvimento da interao entre o usurio e sistemas informatizados. A engenharia de usabilidade tem por objetivo oferecer tcnicas e mtodos que possam ser utilizadas sistematicamente para assegurar um alto grau de qualidade em termos de usabilidade da interface de programas de computador. A fronteira entre a engenharia de software e a engenharia de usabilidade, como acontece entre vrias outras reas do conhecimento, s vezes no muito ntida, mas, em linhas gerais, pode-se dizer que engenharia de software cuida dos aspectos construcionais de 6

sistemas de software enquanto a usabilidade trata dos aspectos comportamentais, relacionados interao humano-computador. Para se conseguir o desenvolvimento de um software de boa qualidade em termos de usabilidade necessria a realizao de uma srie de atividades que podem ser organizadas como um processo que deve se integrar ao processo utilizado para o desenvolvimento dos aspectos construcionais do software. O processo de desenvolvimento um aspecto importante quando se trata de usabilidade. Por este motivo, este documento apresenta a engenharia de usabilidade no contexto de um processo, denominado Praxis-u, que vem sendo desenvolvido no Departamento de Cincia da Computao da UFMG, visando o desenvolvimento da interao usurio-computador. O processo Praxis-u aqui apresentado foi desenvolvido de forma a se integrar com o Praxis (Padua, 2003), abordando aspectos relacionados usabilidade. O Praxis um processo desenhado para dar suporte a projetos didticos em disciplinas de engenharia de software e em programas de capacitao profissional em processos de software. Apesar de se integrar ao Praxis, o Praxis_u pode ser utilizado de forma independente no desenvolvimento da interao usurio-computador ou mesmo integrado a outros processos de desenvolvimento de software.

1.2 INTRODUO USABILIDADE

Os benefcios alcanados pela aplicao de tcnicas da engenharia de usabilidade so visveis tanto no aspecto de eficincia e eficcia da interface como tambm se expressam em processos de desenvolvimento de software mais produtivos, confiveis e com maior satisfao dos usurios e clientes. Dependendo do tipo de produto, a utilizao de tcnicas de usabilidade pode ser imprescindvel para seu sucesso ou pode resultar em um importante diferencial visando competitividade. Por esses motivos, o desenvolvimento de mtodos e prticas de engenharia que assegurem uma eficiente interao computadorusurio vem tendo uma importncia crescente no desenvolvimento de software.

Segundo Jakob Nielsen (Nielsen, 1993), um pesquisador reconhecido e precursor na rea de usabilidade, a engenharia de usabilidade visa o desenvolvimento de interfaces com os seguintes atributos: Produtividade na realizao de atividades: a interface deve permitir bom desempenho do usurio na realizao de suas tarefas. No se est falando de desempenho do software, que um atributo de qualidade utilizado na engenharia de software, mas do desempenho do usurio em sua interao com um sistema de software. Facilidade de aprendizado: deve ser fcil para o usurio aprender a utilizar o software. Reteno do aprendizado com uso intermitente: a interface deve permitir que o usurio (espordico) consiga utilizar o software adequadamente mesmo quando fica sem us-lo por um perodo relativamente longo de tempo. Preveno de erros do usurio: o sistema deve prevenir erros do usurio quando o utiliza em suas atividades. Cabe observar aqui tambm que no se est falando de erros no programa, mas sim de erros do usurio ao utilizar o sistema. Satisfao: o usurio deve gostar de utilizar o sistema. Observem que a satisfao um aspecto subjetivo, pessoal, mas ainda assim importante e que deve ser buscado no desenvolvimento de um produto de software. Cabe observar que, ainda que os cinco atributos de Nielsen sejam desejados, nem sempre se consegue contemplar todos eles em uma interface do usurio, ou, dependendo do contexto de utilizao do produto, um ou outro atributo podem se tornar prioritrio. Por exemplo, em um sistema usado no caixa de um banco, onde pode haver uma fila de pessoas para serem atendidas e o tempo de atendimento um aspecto crtico, o atributo Produtividade e provavelmente Preveno de erros tornam-se muito importante. admissvel inclusive sacrificar o atributo Facilidade de aprendizado; pode-se treinar o funcionrio do banco por certo tempo para que ele adquira destreza na operao do software. J em um software como um stio de comrcio eletrnico, onde se espera que um amplo perfil de usurios consiga utiliz-lo, os atributos Facilidade de aprendizado e Satisfao tornam-se prioritrio. Note, ento, que Usabilidade no significa facilidade de uso de um produto de software como muitos acreditam, mas sim adequao ao uso.

Alm dos cinco atributos de Nielsen, outros podem ser importantes dependendo do contexto de utilizao do software. Por exemplo, em um sistema de apoio ao diagnstico mdico, a preciso, ou acurcia, dos resultados pode ser um atributo muito importante a se buscar no desenvolvimento da interface.

1.2.1 BENEFCIOS
Um investimento em usabilidade pode trazer diversos benefcios para as partes envolvidas no desenvolvimento de um produto de software. Podemos agrupar os benficos em trs categorias: Organizao responsvel pelo desenvolvimento do software. Cliente contratante de um desenvolvimento de software Usurio do produto a ser desenvolvido

Esses benefcios advm no s da qualidade do produto, mas tambm da utilizao de tcnicas que tornam o processo de desenvolvimento mais eficiente e efetivo. Em termos de benefcios de negcio para a organizao desenvolvedora podemos citar: Diminuio de custos e tempo de desenvolvimento. Satisfao do cliente. Melhoria em credibilidade no mercado. Diminuio de riscos de projeto. Melhoria radical de chances de sucesso no mercado. Maiores vendas: produto tem melhor aceitao j que so mais intuitivos de se usar, mais rpidos e mais efetivos. A gerncia da equipe de desenvolvimento do software tambm se beneficia da utilizao de um processo adequado que visa usabilidade. Isso se deve principalmente s tcnicas relacionadas usabilidade que so utilizadas no processo de desenvolvimento. Segue lista de benefcios para a gerncia da equipe de desenvolvimento.

Melhora a gerncia de riscos j que alternativas de desenho so testadas e melhoradas muito antes que a codificao prossiga.

Simplifica o planejamento: permite o clculo mais preciso de necessidade de esforo j que reduz drasticamente a necessidade de re-trabalho devido a desenhos no satisfatrios e problemas de comunicao com o usurio

Prov evidncias de sucesso mais cedo: as avaliaes e relatrios com definies de requisitos de usabilidade e registros em vdeos confirmam a validade dos desenhos ainda em estgios iniciais de desenvolvimento.

As tcnicas que visam usabilidade tambm ajudam no processo de desenvolvimento do software, como mostrado a seguir. Gera confiana em que o desenho funciona: usurios reais validam o desenho muito antes que ele seja construdo. Propicia teste de mltiplos conceitos rapidamente: torna mais fcil e rpido tentar vrias solues de desenho para verificar-se qual a melhor. Evitam-se alteraes de ltima hora, com o stress associado aos atropelos e esforo concentrado de ltima hora. Diminui-se o stress associado aos testes de aceitao. Como as solues de desenho so bem testadas antes de sua implementao, os testes de aceitao tornam-se tarefas muito mais suaves. Pode levar a desenhos mais acurados: com os diversos aspectos da interao modelados e documentados, pode-se obter um quadro mais acurado do produto a ser construdo. Isso porque a anlise do contexto de uso do produto em desenvolvimento leva a uma viso mais acurada e documentada de como os usurios trabalham, sem suposies no fundamentadas de como os usurios vo usar a interface. A utilizao de prottipos e sua validao mais cedo no ciclo de desenvolvimento do produto propiciam que a documentao do produto tambm possa se iniciar mais cedo, com mais tempo para correes e para se produzir todos os aspectos envolvendo documentao, help e treinamento. Isso tambm facilita a identificao de defeitos e a correo de falhas potenciais no desenho da interface do usurio antes da construo. Interfaces mais intuitivas e de mais fcil utilizao podem diminuir a necessidade de documentao e de material de suporte. 10

Permite o planejamento de testes mais cedo e com mais tempo, partindo-se dos desenhos documentados.

Facilita a identificao de erros: com os testes de usabilidade cobrindo grande parte das interaes possveis, fica mais fcil a identificao de problemas.

Quanto ao cliente contratante do desenvolvimento de software, podemos listar os seguintes benefcios. Mais segurana no produto, a partir das evidncias oriundas dos testes e da prototipagem, com a confiana de que o produto foi desenhado para suprir suas necessidades. Melhora a produtividade do trabalho de seus usurios utilizando os produtos desenvolvidos, que tendem a ser mais rpidos e provendo navegao de maior qualidade. Diminuio dos custos de propriedade do produto, incluindo menor necessidade de treinamento e de infra-estrutura de suporte. O custo de aquisio apenas parte do custo de propriedade de um produto. O custo da propriedade inclui tambm os custos de operao, de treinamento de pessoal que vai utiliz-lo, de manuteno, etc. Diminuio do risco de ter que trocar de produto por no atender s suas necessidades. Finalmente, podemos identificar benefcios para os usurios do produto em desenvolvimento. Cabe observar que as pessoas que utilizam o software costumam tambm ser ouvidas e tm um impacto enorme na deciso de sua compra e na compra de verses futuras do produto. Facilidade de uso e de aprendizado. Usurio pode trabalhar de maneira mais rpida e agradvel, com uma ferramenta mais adequada s suas necessidades. Menos tempo perdido lendo manuais ou Helps e consultando o suporte, com mais tempo sendo produtivo. Menos stress na utilizao j que o produto ter sido construdo em torno das necessidades dos usurios e usando sua terminologia e conceitos.

11

1.3 GLOSSRIO
PROCESSO Processo um conjunto de passos parcialmente ordenados, cujo objetivo atingir uma meta. No caso de processo de desenvolvimento de software a meta entregar um produto de software de maneira eficiente, previsvel e que atinja as necessidades de negcio (Wikipedia n.d.).

PROTTIPO Prottipo uma verso parcial de um produto desenvolvida com um mnimo de custo com o objetivo de prover uma viso mais concreta de algum aspecto do produto antes de sua concluso. O prottipo geralmente usado para validao antecipada (antes da concluso) de algum aspecto do produto. Em usabilidade, o prottipo de interface muito utilizado para validao com os usurios do software em desenvolvimento.

1.4 BIBLIOGRAFIA
ISO 9241-11 Ergonomic requirements for office work with visual display terminals (VDTs) - Part 11: Guidance on usability 1998. ISO/IEC 9126 Information technology software product quality- part 1: quality model 1999, (FDIS). Nielsen, J. Usability Engineering. Chestnut Hill, MA, Academic Press, 1993. Livro clssico, precursor, sobre usabilidade. PADUA, W. Engenharia de Software: Fundamentos, Mtodos e Padres. 2. ed. Rio de Janeiro: Editora LTC, 2003. v. 1. 604 p. Wikipedia, http://pt.wikipedia.org/wiki/processo em 10/2009

12

2 PRINCPIOS DE DESENHO
Uma srie de princpios que se aplicam ao desenho (design) de objetos de modo geral tambm se aplica ao desenho de interfaces do usurio. O livro de Norman (Norman, 1998), muito citado em vrias referncias sobre usabilidade, aborda este tema de uma maneira muito instigante, constituindo uma leitura quase obrigatria para quem se interessa pelo tema de usabilidade. Donald A. Norman professor de cincia cognitiva na Universidade da Califrnia em San Diego e Professor de Cincia da Computao na Universidade Northwestern, mas seus trabalhos de hoje so na maioria na Engenharia de Usabilidade. O contedo deste captulo baseado nesta obra de Norman. MOTIVAO Em nosso dia-a-dia, freqentemente nos deparamos com dificuldade na utilizao de algum objeto. Por exemplo, portas que tentamos abrir puxando quando o correto seria empurrando, equipamentos eletrnicos que no conseguimos operar adequadamente, painis cheios de botes e controles que no conseguimos manejar, etc. Costumamos culpar a ns mesmos pela dificuldade em operar esses equipamentos, mas, na verdade, muitos desses problemas poderiam ser evitados atravs de um desenho adequado dos objetos. fcil reconhecer que se um objeto foi desenhado para ser usado por determinado perfil de usurio e se os usurios com esse perfil no conseguem utilizar adequadamente o objeto, ento o problema no est nos usurios, mas sim no projetista que no conseguiu realizar um desenho adequado do objeto. O objetivo do desenho, tornar o objeto acessvel aos seus usurios, no foi atingido. Muitos desses problemas poderiam ser evitados se alguns princpios fossem conhecidos do projetista e utilizados no desenho do objeto. O mesmo se aplica ao desenho de interfaces de usurios e muitos problemas de dificuldade de acesso a stios web poderiam ser evitados pela observncia, pelos desenvolvedores, de alguns princpios bsicos de design. Nas sees seguintes apresentaremos vrios desses princpios que podem ser usados como base para o entendimento do processo de interao do usurio e para o desenho de interfaces mais adequadas interao. 13

2.1 CICLO DE EXECUO DE UMA AO

Segundo Norman (Norman, 1998), toda ao que realizamos passa por sete estados que vo desde a formao de um objetivo que buscaremos atingir atravs da ao at a concluso dessa ao. Para que a ao possa ser bem executada, isto , para que um indivduo consiga interagir de forma satisfatria com o ambiente onde realiza suas atividades, necessrio que este indivduo tenha condies de atingir os sete estados envolvidos na realizao da ao. A realizao de qualquer atividade, portanto, envolve esses vrios estados onde continuamente executamos aes e avaliamos o que estamos fazendo. A Figura 2-1 mostra um ciclo de estados que ocorrem quando interagimos em um ambiente na realizao de uma ao. Esse ciclo pode ser caracterizado pelos estados ou etapas mostradas a seguir. Para ilustrao, vamos imaginar o cenrio que uma pessoa, Maria, que vai pintar as paredes de sua sala de visitas. Formao do objetivo: tudo se inicia com a formao de um objetivo. Esse objetivo pode ser de vrios tipos, por exemplo, lazer, uma atividade do dia-a-dia, uma atividade profissional, a interao com um stio Web, etc. Em nosso exemplo, Maria est em sua sala, pensando na vida, e, de repente, se sente aborrecida com a aparncia de sua sala e pensa que seria bom mudar a cor de sua pintura. A partir da formao de um objetivo, a realizao de uma ao envolve aspectos relacionados execuo da atividade e aspectos relacionados avaliao do est sendo executado para verificar se est tudo indo bem ou se necessrio alguma correo ou ajuste no que est sendo feito tendo em vista o objetivo definido.

14

Figura 2-1 Ciclo da interao: os sete estados da ao (adaptado de Norman, 1998) A execuo da ao envolve os seguintes estados: Inteno de agir: muitas vezes temos vontade de fazer alguma coisa, mas no agimos realmente para atingir nosso objetivo. A realizao de uma ao comea realmente quando tomamos a deciso de agir. Maria decide que vai pintar as paredes de sua sala de visita. Planejamento de (sub) aes: planejamos nossas aes ou subaes se consideramos aes mais complexas como formadas por subaes. Esse planejamento pode at ser feito de forma no consciente, mas qualquer sequencia de aes tem que ser planejada antes por nosso crebro. Maria pensa em comprar tinta e outros materiais, reserva um dia para a pintura e planeja outras providncias. Execuo da sequencia de (sub) aes: a ao efetivamente executada. Maria pinta as paredes de sua sala. J a avaliao da ao envolve os seguintes estados: Percepo do estado do mundo: quando realizamos uma ao, temos a necessidade de continuamente perceber o que estamos fazendo. A percepo se d atravs qualquer de nossos cinco sentidos, e qualquer dificuldade na percepo pode ser um obstculo 15

realizao de uma ao. Maria se utiliza principalmente da viso, mas provavelmente tambm do tato e olfato, para perceber o resultado de sua atividade. Interpretao da percepo: precisamos ser capazes de interpretar o que estamos percebendo tendo em vista nossos objetivos. Em nosso exemplo, Maria vai interpretar que h alguma coisa errada na rugosidade que esta percebendo em sua pintura. Avaliao dos resultados: para atingir nossos objetivos, importante tambm a capacidade de avaliar o que foi percebido e interpretado. Neste estado, avaliamos se o que estamos fazendo est de acordo com nossas expectativas e, caso necessrio, fazemos correes visando nossos objetivos. Maria avalia a rugosidade que est observando em sua pintura. Considera se que a causa disso pode ser no ter lixado a parede antes ou que a tinta requeira uma maior diluio. Depois de ler as instrues na embalagem da tinta, chega concluso que usou pouco diluente e que vai ter que refazer a pintura da parede que estava realizando. Contextualizando no desenho da interao no desenvolvimento de software, podemos observar que um usurio vai conseguir utilizar adequadamente um software se sua interface lhe capacita a passar pelos sete estados envolvidos na realizao de uma ao e vai ter dificuldades ou mesmo utilizar o software de uma maneira no efetiva, caso no consiga agir adequadamente como se espera em quaisquer desses estados. interessante observar tambm que esse ciclo de estados da ao est na origem de vrios princpios de desenho que so apresentados adiante no texto. Por exemplo, a realimentao (feedback). Na utilizao de um software, um usurio necessita uma realimentao contnua e completa sobre os resultados de suas aes. Uma realimentao adequada vai permitir ao usurio perceber, interpretar e avaliar o resultado de suas aes.

2.2 DISTRIBUIO DA INFORMAO

O comportamento de uma pessoa quando interage em um ambiente guiado pela combinao do conhecimento que a pessoa tem e da informao que capturam do mundo. Um comportamento adequado do usurio pode se dar mesmo com pouco conhecimento do ambiente com o qual interage, por que ele se utiliza tambm da informao que est no mundo, ou seja, no ambiente com o qual est interagindo. 16

Para ilustrar esse aspecto, imagina que voc mora em uma grande cidade e vai de sua casa at uma rua afastada que voc conhea no extremo oposto da cidade. Voc consegue, sem muita dificuldade, chegar ao seu destino, afinal voc j foi l vrias vezes. Mas imagina se voc for explicar a uma pessoa que no conhea sua cidade com fazer esse trajeto. Provavelmente, essa pessoa no conseguir repetir esse trajeto a partir de sua explicao somente. Por que isso acontece? Afinal, se voc tem a informao sobre o caminho voc poderia pass-la outra pessoa. Isso acontece por que no nos guiamos somente pela informao que temos na cabea, memorizada, mas sim pela combinao do que temos memorizado com a informao que est no mundo. E um comportamento perfeito desejado pode ser alcanado mesmo com informaes imprecisas pelas seguintes razes. Informao no mundo. O mundo nos apresenta muita informao que nos ajuda em nossa navegao. Por exemplo, placas, avisos e objetos que chamam nossa ateno. Um comportamento perfeito resultar se o conhecimento que temos fornece a informao ou comportamento que seja suficiente para se distinguir a escolha correta dentre todas as outras. No necessrio conhecer todas as alternativas; apenas aquelas relacionadas ao que estamos fazendo. Restries naturais esto presentes. O mundo restringe os comportamentos admissveis. As prprias propriedades fsicas dos objetos restringem as operaes que podemos executar. Por exemplo, uma cidade tem ruas e avenidas que restringem e facilitam nossa navegao. Restries culturais esto presentes. A sociedade cria inmeras convenes artificiais que foram aceitas e incorporadas em nosso comportamento. Essas convenes podem ser utilizadas pelo projetista de um equipamento para facilitar sua utilizao. Por exemplo, leis de trnsito podem restringir, mas tambm facilitar nossa movimentao em uma cidade.

2.3

PSICOLOGIA DOS MATERIAIS/SERVENTIA

As pessoas tm diferentes reaes frente aos objetos com que esto interagindo. Essa reao muitas vezes depende do tipo de material. como se houvesse uma psicologia das pessoas em relao aos materiais e objetos. Por exemplo, uma tesoura serve para cortar, 17

um papel serve para se escrever ou para embrulhar coisas. Madeira associada com solidez, opacidade e serve para suportar coisas ou para se entalhar. Dependendo da forma, um boto serve para se girar, se pressionar ou se mover como em um joystick. ra Bolas servem para se atirar ou jogar; placas para se empurrar; ranhuras para se encaixar coisas, etc. Podemos identificar para que serve um objeto por meio de suas caractersticas percebidas e reais. Nosso aprendizado dirio de como funcionam os objetos e para que servem ocorre ais. a partir de informaes apreendidas pela aparncia dos objetos (a psicologia dos objetos) e pela forma com que o designer que o projetou nos apresenta a operao do objeto. No desenho de um objeto, o projetista pode explorar a noo de serventia das pessoas para dar indicaes sobre operao ou utilizao. A vantagem dessa abordagem que o usurio entende o que fazer com aquele objeto apenas atravs do olhar. Muitas vezes, no so necessrias instrues. Cabe aqui observar que quando coisas simples necessitam de instrues uma boa indicao de que o design apresenta falhas. A primeira imagem na Figura 2-2 mostra o exemplo de um bom desenho: s de olhar para a maaneta de um veculo, pela sua forma podemos identificar se a maaneta de puxar ou de empurrar. A segunda imagem mostra o desenho de uma maaneta que necessitou um rtulo para tornar mais claro como operar manipulador de uma porta. como

Figura 2-2 Maanetas de veculos

J a Figura 2-3 apresenta um desenho de uma maaneta com qualidade questionvel j que sua forma no d uma boa indicao sobre se ela deve ser girada ou deve 18

puxada/empurrada; alm disso, sua forma arredondada e polida escorregadia, dificultando sua manipulao. Talvez por isso tenham envolvido a maaneta em fita adesiva!

Figura 2-3 Desenho questionvel

2.4 VISIBILIDADE
O usurio deve saber dizer o estado em que se encontra um dispositivo e as opes de ao a partir daquele estado apenas olhando para ele. Visibilidade a capacidade de uma interface de informar ao seu usurio sobre as aes disponveis em determinado momento ou sobre o estado em que se encontra o equipamento ou sistema de software. Um bom contra-exemplo so os telefones do tipo PABX, utilizado para gerenciar vrios ramais em uma empresa ( Figura 2-4), que muitas vezes proveem um grande nmero de funes mas no tornam visveis quais so as funes disponveis para os usurios. Muitas vezes esses aparelhos no oferecem nem mesmo uma tela com a informao necessria aos usurios e as funes tem que ser comandadas atravs de cdigos numricos. O resultado disso que em geral vrias das funes acabam no sendo utilizadas seja por que o usurio no sabe que elas existem ou por que j se esqueceram, no sabem mais como utiliz-las e no querem se dar ao trabalho de consultar o manual. 19

Figura 2-4 Telefone PABx

2.5 MODELO MENTAL

Modelo conceitual ou modelo mental o modelo que formamos para explicar o funcionamento de um objeto. Para utilizar o objeto recorremos ao modelo mental que temos do modo como ele funciona. Por exemplo, temos um modelo mental de como funciona a caixa de marcha de um veculo e utilizamos esse modelo para passar as marchas de forma adequada quando dirigimos. Para um objeto ser utilizado adequadamente, no necessitamos de um modelo conceitual detalhado nem mesmo de um modelo muito fiel ao modelo real. O importante que nosso modelo mental seja consistente com o modelo real. No necessitamos saber, por exemplo, que a caixa de marchas de um veculo constituda de engrenagens que reduzem o nmero de giro do motor e transmitem potncia s rodas. suficiente sabermos que o veculo tem cinco marchas, que a primeira deve ser usada para a partida, que as marchas mais fortes so usadas para subidas mais ngremes. Modelos mentais so importantes por que o projetista de um equipamento ou interface deve ter claro que ele precisa transmitir ao seu usurio um modelo conceitual correto para que ele consiga usar adequadamente o equipamento. A Figura 2-5 apresenta um teclado piano real, um instrumento fsico, e um produto de software, onde o modelo mental que o usurio, msico provavelmente, j possui foi explorado no desenho de sua interface. A interface fica de fcil utilizao para o usurio msico que j conhea o instrumento fsico. 20

Figura 2-5 Teclado: instrumento fsico e interface de software

A Figura 2-6 tambm apresenta uma interface de software representando a parte de trs de um equipamento de som. A interface to realstica que se podem mudar conexes arrastando-se os cabos com a utilizao de mouses.

Figura 2-6 Teclado Implementado em Software

2.6 MAPEAMENTOS
Mapeamento uma propriedade que se refere determinao do relacionamento entre as aes e os resultados, entre os controles e seus efeitos, entre o estado do sistema e o que 21

 visvel. Um bom desenho de um objeto deve facilitar o mapeamento ao usurio. Bons mapeamentos tiram vantagens de analogias fsicas e padres culturais. Por exemplo, o mapeamento entre o giro do volante de um carro e o acionamento das rodas. Tambm um controle em que um som mais alto significa mais alguma coisa, ou uma situao em que se movendo o controle para o alto o objeto move-se para o alto tambm. Outro bom exemplo seria o mapeamento entre os movimentos do mouse e do cursor em uma interface grfica. A Figura 2-7, que mostra detalhe de um fogo domestico, ilustra a dificuldade do usurio em fazer o mapeamento entre um registro e seu respectivo queimador. Para facilitar o mapeamento, o fabricante utiliza pequenos cones que mostram o posicionamento do queimador. Com o passar do tempo, com a limpeza, o desenho costuma se apagar e uma pessoa que no tenha familiaridade com o fogo, como uma visita, pode ter dificuldade em fazer o mapeamento. A Figura 2-8 apresenta duas solues com um melhor desenho em termos de mapeamento.

Figura 2-7 mapeamento registro x queimador em um fogo A Figura 2-9 mostra um equipamento que pode ser usado para controle de iluminao de grandes ambientes como em um teatro. fcil observar que importante que a interface desse tipo de equipamento permita um bom mapeamento ao usurio.

22

Figura 2-8 Foges com melhor soluo para o mapeamento

Figura 2-9 equipamento de controle de iluminao

2.7 REALIMENTAO
Na sua interao com o ambiente onde realizam suas atividades, as pessoas necessitam continuamente perceber, interpretar e avaliar o resultado de suas aes. Isso foi mostrado na seo 142.1 sobre o ciclo de execuo de uma ao, nos estados associados avaliao do que est sendo executado.

23

A cada ao realizada por um usurio, a interface deve enviar-lhe de volta informao sobre o que foi efetivamente realizado. O usurio deve receber uma realimentao contnua e completa sobre os resultados de suas aes. O tipo de realimentao a ser dado por uma interface pode depender muito do tipo de situao. Em certas situaes a realimentao deve ser mais visvel. Por exemplo, em caso de alertas sobre situaes em que a ao do usurio potencialmente pode causar algum tipo de dano. Em outros casos, a realimentao visa informar ao usurio sobre o resultado de uma ao que ele realizou. Por exemplo, quando um usurio de um editor de texto comanda a substituio de todas as ocorrncias da palavra x por y, o sistema deve lhe dar uma realimentao sobre o resultado de sua ao. A realimentao poderia ser mais completa, por exemplo, mostrando cada substituio e, possivelmente, at solicitando permisso para cada substituio. Pode ser desejvel tambm uma realimentao mais simples, mais rpida para o usurio. Por exemplo, o sistema poderia simplesmente informar ao usurio quantas substituies foram feitas e, com essa informao, o usurio busca avaliar se tudo ocorreu conforme sua expectativa. A realimentao, dependendo do contexto, pode e deve ser sutil. Por exemplo, ao passarmos o cursor do mouse sobre a interface grfica de um software, o sistema pode mudar frequentemente de estado. A informao sobre o estado do sistema sutil, muitas vezes expressa somente pela forma do cursor. Essa realimentao do sistema informa ao usurio, de uma forma no agressiva, simples, porm eficaz, que o sistema est percebendo o movimento do mouse e que a cada contexto, correspondente s diferentes formas do cursor, diferentes aes podem estar disponveis.

2.8 ATENO AOS REQUISITOS

Outro princpio de desenho mencionado por Norman (Norman, 1998) refere-se ateno aos detalhes. Por exemplo, no desenho de um objeto (ou interface), considerar sempre quem seriam seus possveis usurios, suas necessidades e as condies de uso. No processo de desenvolvimento que visa usabilidade que veremos adiante, essa 24

informao vem da atividade que chamamos e Anlise de contexto de uso. Um dos objetivos da Anlise de contexto de uso justamente coletar informao sobre os perfis de usurios, suas necessidades, tarefas que realizam, sobre o ambiente de realizao de suas atividades, dentre outras. Um bom exemplo desse princpio poderia ser um o desenho do pen-driver. O pen-driver prtico, fcil de ser usado quase que por qualquer tipo de usurio, resistente, tem uma capa protetora e um conector USB que tambm s se encaixa se for colocado na posio correta.

2.9 FUNO DE FORA

Funo de fora uma restrio utilizao de um objeto em determinadas circunstncias. Podemos observar trs tipos de funo de fora: Intertravamento: acontece quando se fora uma ordem de execuo ou no permite operaes que no devem ser executadas em dado momento. Por exemplo, quando uma console de jogo impede a retirada de um cartucho quando o equipamento est em operao, isto , quando o usurio est jogando. A restrio visa proteger o equipamento de possveis danos ou evitar que o sistema fique em um estado indefinido em determinada situao. Lockin: mantm uma operao ativa enquanto necessrio. Por exemplo, o interruptor de energia no desliga o computador imediatamente j que poderia deixar o sistema operacional em um estado inconsistente. Nesse caso, o sistema operacional providencia um fechamento lgico (log off) antes do desligamento fsico da fonte de energia. Lockout: impede o usurio de entrar em um local perigoso ou impede a ocorrncia de um evento indesejado. Por exemplo, a Figura 2-10 mostra um elevador para residncias ou pequenos prdios onde um mecanismo de lockout impede a abertura da porta quando o elevador no est posicionado no mesmo nvel, prevenindo acidentes.

25

Figura 2-10 Elevador com mecanismo de lock-out. Fonte: http://www.dwa.eng.br/elevadores.html

2.10 BIBLIOGRAFIA

http://webmail.faac.unesp.br/~paula/Paula/everydaythings.pdf Norman, D. A. The Design of Everyday Things. New York, Basic Books, reimpresso em 1998.

3 PROCESSO VISANDO A USABILIDADE

Como j mencionado anteriormente, para conseguirmos um produto de software de boa qualidade em termos de usabilidade necessrio seguirmos um processo de desenvolvimento que inclua atividades que visem usabilidade. No razovel, por exemplo, tentar desenhar uma interface do usurio, onde se busca qualidade em termos de usabilidade, sem o conhecimento de caractersticas importantes de seus usurios. A 26

Anlise de usurios e das tarefas que eles realizam, portanto, uma atividade importante e que deve ser realizada antes do desenho da interface do usurio. Um bom produto no surge por acaso, vai ser desenvolvido atravs de vrias atividades que so definidas de uma maneira sistematizada em um processo. Um processo tem como objetivo uma meta. Aqui, estamos falando de um processo cuja meta o desenvolvimento da interao humano-computador com qualidade em termos de usabilidade. Neste captulo apresentamos o Praxis-u, um processo de desenvolvimento de software visando usabilidade que vem sendo desenvolvido no Departamento de Cincia da Computao da UFMG. O processo Praxis-u aqui apresentado foi projetado de forma a se integrar ao Praxis (Padua, 2003), abordando aspectos relacionados usabilidade. No Praxis-u, as atividades que visam o desenvolvimento da interao usurio-computador foram organizadas em uma disciplina, ou subprocesso especfico, o subprocesso de usabilidade. Como parte do Praxis-u, foram definidos artefatos e atividades que, integrados ao Praxis, constituem um processo de desenvolvimento de software visando usabilidade. Apesar de se integrar ao Praxis, o Praxis_u pode ser utilizado de forma independente no desenvolvimento da interao usurio-computador ou mesmo integrado a outros processos de desenvolvimento de software. Basicamente, o fluxo de usabilidade define um ciclo de atividades onde se analisa o problema, define metas de usabilidade, desenha solues e avalia os resultados buscando a verificao das metas definidas. As solues so inicialmente realizadas na forma de prottipos, no final chega-se ao desenho da interface do usurio em um processo iterativo. A utilizao de prottipos vem da necessidade de se avaliar solues o mais cedo possvel visando reduzir os custos das (inevitveis) mudanas. As avaliaes, em suas diversas formas, constituem uma atividade importante da engenharia de usabilidade. A usabilidade requer experimentao e avaliao porque h a necessidade de verificao da qualidade de solues que envolvem a interao com o ser humano. Como no se consegue modelar efetivamente o comportamento do ser humano, devido a sua complexidade e variedade, as avaliaes com a participao dos usurios so muito utilizadas para validao das solues. As avaliaes de usabilidade visam verificao da qualidade da interface, comparando-se os resultados obtidos com as metas definidas anteriormente, com o objetivo de se definir 27

se o produto est concludo, com um nvel aceitvel de qualidade, ou se ser necessrio uma nova iterao pelo fluxo de usabilidade.

3.1 DETALHES DE IMPLEMENTAO DO PRAXIS-U

Um resumo do Praxis 2.0-u, incluindo seus artefatos e as atividades tpicas de cada iterao, est disponvel no stio http://www.dcc.ufmg.br/~clarindo/disciplinas/eu/material/index.htm. Cabe observar que no desenvolvimento do Praxis-u, para vrios artefatos que fazem parte do processo, havia duas possibilidades: 1. 2. Estender os artefatos do Praxis com os aspectos de usabilidade; Criar novos artefatos compreendendo os aspectos de usabilidade.

De maneira geral, a segunda abordagem foi a preferida, visando tornar a documentao dos aspectos relativos usabilidade mais independente do resto do processo. Essa opo tem como justificativa objetivos didticos, por facilitar o ensino, mas visou tambm facilitar a evoluo e o uso dos processos de engenharia de software e de usabilidade de maneira mais independente. Em alguns casos, preferimos estender o artefato do Praxis com os aspectos de usabilidade; por exemplo, o modelo de cadastro de requisitos foi estendido com uma folha para registro dos requisitos de usabilidade.

3.2 ATIVIDADES DO FLUXO DE USABILIDADE

A Figura 3-1 apresenta um diagrama mostrando as principais atividades e artefatos utilizados no Praxis-u. As atividades do fluxo de usabilidade esto organizadas em duas raias, correspondentes a atividades tcnicas e gerenciais. As atividades tcnicas so de responsabilidade da equipe tcnica de usabilidade e as atividades gerenciais so tpicas da gerncia de projeto referentes aos aspectos de usabilidade. Cabe observar que no estamos falando de uma gerncia do projeto especfica de usabilidade, normalmente isso no vai acontecer, mas sim de uma gerncia de projeto que vai ser responsvel tambm pela gerncia do esforo associado usabilidade.

28

Fluxo Tcnico

Fluxo Gerencial

MAHS w Anlise de contexto de uso ERUSw: 1e2 Def inio das f unes do produto

Praxis Planejamento
[Instanciado]

MAN Sw

Controle PRIS w Prototipao de requisitos de interf ace

ERS ... CRS W-u

DDIS ...

Def inio de requisitos e metas de usabilidade

RRE ...

Rev iso da anlise de usabilidade

ERU ...

GEU Sw

DDS w: 2.3

Def inio do estilo de interao

Desenho da Interao

PCIS w

PDIS w GEUS w: [Atualizado] DDISw

RRG ... RRD DISw DAU Sw

Rev iso do desenho da interao

RIDD ISw

RIPDIS w Av aliao de usabilidade

RAUS w

Desenho da interao no aprov ado

Desenho da interao aprov ado

Figura 3-1 Praxis-u: diagrama de atividades

O diagrama utilizado na Figura 3-1 um diagrama de atividades da UML (Booch, G. et al, 2005), (Rumbaugh, J. et al, 2004). Sendo assim, o retngulo com bordas arredondadas

29

denota atividades e os outros retngulos denotam objetos, no caso, artefatos, que podem ser consumidos ou produzidos pelas atividades. Tipicamente, durante o desenvolvimento de um produto de software, podem ser realizados vrios ciclos utilizando o fluxo de usabilidade. Pode-se, inclusive, adotar o padro em que um ciclo pelo fluxo de usabilidade seja realizado em cada iterao, sendo que em cada ciclo as atividades so realizadas com maior ou menor grau de detalhamento (podendo at ser omitida). No Praxis-u, um planejamento dos ciclos de usabilidade (quantos e em quais iteraes sero realizados) dever ser feito na atividade de personalizao do processo para projetos especficos. As atividades, mostradas no diagrama da Figura 3-1 e listadas abaixo, sero apresentadas nas sees a seguir. Planejamento; Controle; Anlise de contexto de uso; Definio das funes do produto; Prototipagem de requisitos de interface; Definio de requisitos e metas de usabilidade; Reviso da anlise de usabilidade; Definio do estilo de interao; Desenho da interao; Reviso do desenho da interao; Avaliao de usabilidade e Balano final.

3.2.1 ATIVIDADES GERENCIAIS

As atividades de Planejamento e Controle so atividades gerenciais; geralmente esto sob responsabilidade da gerncia do projeto.

30

3.2.1.1 Planejamento
O Planejamento compreende a personalizao do processo de desenvolvimento com relao aos aspectos de usabilidade e uma estimativa de recursos necessrios ao cumprimento do escopo do produto a ser desenvolvido. A personalizao do processo visa definio de uma instncia do fluxo de usabilidade a ser utilizada em um projeto especfico. A estimativa de recursos visa determinao do esforo (nmero de horas) e outros recursos necessrios ao projeto, no que se relaciona s atividades que visam usabilidade. A necessidade de recursos deve ser mapeada a marcos que indicam o progresso na evoluo do escopo durante a execuo do projeto. O mapeamento em marcos de progresso permitir o acompanhamento (controle) do projeto durante sua execuo, possibilitando a confrontao de metas atingidas de esforo, escopo, prazo e custo.

3.2.1.2 Controle
O Controle compreende o acompanhamento do progresso do projeto, durante sua realizao, por meio da confrontao de metas de esforo, escopo, prazo e custo, comparando o previsto no Planejamento com o realizado at um determinado momento.

3.2.2 ATIVIDADES TCNICAS

3.2.2.1 Anlise de contexto de uso

A Anlise de contexto de uso tem como objetivo principal a caracterizao dos usurios, das tarefas que eles realizam, de produtos semelhantes ou concorrentes e do ambiente onde ser utilizado o produto em considerao. A Anlise de contexto de uso produz informaes que constituem importante insumo para vrias atividades subseqentes no ciclo de desenvolvimento de software. Principalmente, essas informaes so utilizadas para a definio do produto, para o desenho da interface com o usurio e para as avaliaes de usabilidade. Cabe esclarecer que o termo Anlise aqui utilizado tem uma conotao diferente do termo usado na Engenharia de software. O termo Anlise usado na Engenharia de software para denotar as atividades que visam criao do modelo de Anlise. O modelo de Anlise 31

define o produto de software em nvel de definio do problema, cuja soluo em termos de sistema de software ser definida no modelo de Desenho. J o termo Anlise de contexto de uso, usado na Usabilidade, refere-se atividade que visa modelagem de todo o contexto onde o produto de software ser utilizado. importante ressaltar que o objetivo da Anlise de contexto de uso o de caracterizar a situao existente antes do desenvolvimento do software. O conhecimento obtido pela Anlise de contexto de uso, em um segundo momento, pode ser utilizado para se caracterizar as tarefas que se deseja informatizar e incorporar ao produto na forma de requisitos funcionais, e para se caracterizar os usurios alvos do software a ser desenvolvido. No cabe, na Anlise de contexto de uso, definir-se solues de desenho da interface com o usurio, j que a Anlise de contexto de uso visa justamente levantar informaes importantes para o posterior desenho da interface. Deve-se, no entanto, como resultado do trabalho de Anlise de contexto de uso, produzir-se recomendaes para as atividades subseqentes no desenvolvimento do software, incluindo, com nfase, recomendaes para o desenho da interface com o usurio. A Anlise de contexto de uso pode ser considerada como um detalhamento da modelagem de processo de negcio nos aspectos que influenciam a usabilidade do produto. Por exemplo, a Anlise de contexto de uso deve investigar as caractersticas das tarefas realizadas pelos usurios e a forma como essas tarefas so realizadas visando obteno de informao que vai ajudar, posteriormente, no desenho de uma interface mais adequada para a realizao das mesmas tarefas com o apoio do sistema em desenvolvimento. A Anlise de contexto de uso, assim como outras atividades visando usabilidade, tem certa interdependncia com outras atividades da engenharia de software. A Anlise de contexto de uso tem uma forte interdependncia com o levantamento dos requisitos do software. Isso porque as funes que vo ser implementadas pelo software em desenvolvimento, seus requisitos funcionais, devem dar apoio aos usurios na realizao das tarefas mais importantes (ou parte delas) que os usurios realizam. A Anlise de contexto de uso envolve diversos tipos de anlise que sero apresentadas a seguir: Anlise de usurios, 32

Anlise de tarefas Anlise de Ambiente Anlise de Produtos Concorrentes ou Similares

O Praxis-u prov um gabarito (modelo no sentido de template) de um artefato, denominado ERUSw.dot, para a documentao da Anlise de contexto de uso. ANLISE DE USURIOS A anlise dos usurios visa uma caracterizao dos diversos perfis de usurios com relao a aspectos que interessam para o desenvolvimento do produto de software. A caracterizao dos usurios feita em termos de um conjunto abstrato de necessidades, interesses, expectativas, comportamentos e responsabilidades dos diversos atores envolvidos na interao com o produto a ser desenvolvido. A Anlise de usurios combina resultados de teorias relacionadas com o processo cognitivo do ser humano (fatores humanos) com informaes especficas sobre os usurios potenciais e o ambiente onde desenvolvem suas atividades. As informaes sobre os usurios podem ser obtidas atravs da observao, de pesquisas de marketing, questionrios e estudos observacionais do futuro local de implantao do sistema ou entrevistas com usurios e com especialistas no domnio de aplicao. Reunies e grupos de discusso em que desenvolvedores e representantes dos usurios interagem para determinar as necessidades e caractersticas dos usurios tambm so freqentemente utilizadas. O resultado da Anlise de usurios registrado em modelos prprios e documentado na especificao de requisitos de usabilidade. Na realizao de suas atividades no dia a dia, as pessoas criam e utilizam modelos mentais que explicam e ajudam no controle dos objetos com os quais interagem. Na seo 2.5 apresentamos modelos mentais associados a um princpio bsico utilizado em design. Esses modelos mentais podem ser explorados no desenho da interface do usurio, tornando a interface mais intuitiva e de utilizao mais fcil para os usurios. Sendo assim, a Anlise de usurios deve incluir tambm uma anlise dos modelos mentais mais importantes que as pessoas envolvidas (potenciais usurios) utilizam na realizao de suas atividades.

33

ANLISE DE TAREFAS Esta atividade tem como objetivo a caracterizao das tarefas realizadas pelos usurios ou potenciais usurios em suas atividades relacionadas com o produto em considerao, a incluindo a definio das necessidades que as tarefas visam suprir, o ambiente onde as tarefas so realizadas e a definio das tarefas que sero automatizadas ou realizadas pelo sistema. As tarefas a serem realizadas pelo sistema, quando o produto estiver em operao em interao com os usurios, correspondem aos casos de uso. As outras tarefas realizadas pelos usurios so consideradas fora do escopo do produto a ser desenvolvido, mas a Anlise de tarefas como um todo constitui informao muito importante para o desenvolvimento da interao humano-computador. ANLISE DE AMBIENTE As pessoas no trabalham ou exercem suas atividades isoladas do meio ambiente. O ambiente de realizao das atividades pode ter muita influncia na utilizao do software e a incompatibilidade do ambiente com o software pode at resultar na rejeio do produto pelo usurio. A Anlise de Ambiente visa uma caracterizao do ambiente onde os usurios, ou potenciais usurios, realizam suas atividades relacionadas com o produto em considerao. Cabe ressaltar que o ambiente de realizao das atividades pode ser considerado como parte da Anlise de tarefas assim como parte da Anlise de usurios. A deciso sobre e melhor forma de se modelar o ambiente deve ser baseada no fato do ambiente estar mais associado s pessoas ou s atividades que elas realizam. Por exemplo, o risco de um ambiente exposto radioatividade pode estar associado tarefa de se tirar radiografias, para qualquer que seja o usurio envolvido nesta tarefa. J o aspecto da presso social por no se cometer erro pode ser modelado como associado ao usurio mdico, independente das tarefas que ele realiza. ANLISE DE PRODUTOS CONCORRENTES OU SIMILARES A anlise de concorrncia visa o estudo de produtos semelhantes ao produto em considerao com o objetivo de: familiarizao com o domnio do problema, identificao de oportunidades que possam diferenciar o produto. 34

No se trata, obviamente, de cpia ou violao de direitos de propriedade, mas de conhecer os possveis concorrentes ou produtos similares ao que est sendo desenvolvido com o objetivo de identificar oportunidades de diferenciais, conhecer limitaes ou mesmo utilizar como uma referncia para comparaes.

3.2.2.2 Definio das funes do produto

Um dos objetivos das atividades de Anlise de contexto de uso a definio de quais tarefas, dentre as identificadas, sero realizadas ou apoiadas pelo produto em perspectiva. Os requisitos funcionais de um produto de software definem as funes que sero providas pelo produto para apoiar a realizao dessas tarefas. Portanto, importante que as pessoas que vo definir os requisitos funcionais tenham conhecimento das tarefas que o produto apoiar, ou seja, que tenha participado da Anlise de contexto de uso. A atividade de Definio das funes do produto fica na fronteira das reas de engenharia de software e usabilidade. Em uma abordagem muito comum na engenharia de software, a definio dos casos de uso feita simplesmente a partir de informaes levadas pelos usurios em reunies de levantamento de requisitos. Acontece que os usurios, muitas vezes, tm uma viso mais localizada com relao s necessidades a serem cobertas pelo produto em considerao. A Anlise de contexto de uso pode fornecer uma viso mais global das questes envolvidas na definio e priorizao das funes a serem providas pelo produto. A definio de quais funes (ou casos de uso) devem ser incorporados em um software deve ser feita tendo com base na Anlise de tarefas que os usurios realizam. As tarefas caracterizadas na Anlise de contexto de uso podem ser consideradas como candidatas a serem contempladas como funes (casos de uso) do produto em considerao. Em outras palavras, pode-se dizer que dentre as tarefas caracterizadas na Anlise de contexto de uso, algumas, ou partes delas, vo poder ser realizadas pelos usurios com o apoio do produto quando ele estiver concludo. A Anlise de tarefas permite que a definio dos casos de uso do produto seja feita com base em informaes mais consistentes e com uma melhor viso do problema.

35

3.2.2.3 Prototipagem de requisitos de interface

O objetivo desta atividade a criao de um prottipo para validao dos requisitos de interface com os usurios. Requisitos de interface so, basicamente, requisitos de entrada e sada de informao associados aos casos de uso. Em geral, esses requisitos so representados na forma de telas ou mesmo de tabelas, sem preocupao com os aspectos de design. importante no confundir os requisitos de interface com o desenho da interface. O Desenho ser feito em uma etapa posterior quando, a sim, aspectos de design como design grfico, metfora utilizada, organizao de contedo, navegao, etc, sero considerados. O Prottipo de requisitos de interface tem o objetivo de prover uma viso mais concreta dos requisitos de interface para que seja utilizado na validao com os usurios e cliente. O Praxis-u prev um artefato denominado PRI como Prottipo de Requisitos de Interface. O PRI compreende os aspectos de contedo e de navegao da interface, entendidos como requisitos de interao. O PRI pode ser registrado no documento de Especificao de Requisitos de Software do Praxis, na seo correspondente ao requisito de interface externa. Apesar de sugerir o desenvolvimento do PRI, o Praxis-u no especifica um gabarito para este artefato. Isso porque se preferiu deixar livre para a organizao desenvolvedora do software definir a melhor maneira de se realizar a prototipagem. Existem inmeras possibilidades que vo desde um documento como a prpria especificao de requisitos ou uma apresentao (como um Power Point), at uma soluo mais sofisticada como um produto especfico contendo navegao de forma funcional.

3.2.2.4 Definio de requisitos e metas de usabilidade

Essa atividade visa definio de nveis de desempenho almejados para os atributos de usabilidade considerados importantes para o produto em considerao. Sem especificaes mensurveis, impossvel definir-se parmetros de qualidade em termos de usabilidade e dizer se o produto final alcana o nvel de qualidade desejada. Com o estabelecimento dos requisitos e ou metas de Usabilidade o mais cedo possvel no

36

processo de desenvolvimento, e monitorando-as a cada iterao, pode-se determinar quando a interface est, de fato, melhorando em qualidade. Quando envolve medidas objetivas, como, por exemplo, o tempo que o usurio gasta para realizar uma tarefa, os nveis de desempenho so definidos para Tarefas de referncia (benchmark), ou seja, define-se o desempenho esperado dos usurios na realizao de tarefas de referncia. Quando envolve aspectos subjetivos como Satisfao do usurio, questionrios podem ser utilizados. Por exemplo, pode-se definir como requisito de usabilidade que o produto de software dever ser avaliado com uma nota mdia mnima de 8,5 em um questionrio de satisfao que ser aplicado entre os usurios. Apesar de usarmos ambos os termos requisitos e metas de usabilidade com sentido semelhante, ou seja, no sentido de uma medida do desempenho esperado dos usurios quando utiliza o software, usamos o termo requisito quando estes so definidos pelo cliente ou usurios na especificao de requisitos e o termo meta quando o os nveis de desempenho so decises de desenho. Na prtica, significa que os requisitos so considerados critrios para a aceitao do software, podem ser exigidos pelo cliente da mesma forma que outros requisitos tambm o so. J as metas de usabilidade so utilizadas pela equipe de desenvolvimento com referncia para a avaliao da qualidade da interao proporcionada pela interface.

3.2.2.5 Reviso da anlise de usabilidade

O objetivo dessa atividade avaliar a qualidade e aperfeioar os artefatos produzidos nas atividades de Anlise de contexto de uso e de especificao de requisitos. Como parte do trabalho de reviso, dever ser realizado uma validao do PRI (Prottipo de Requisitos de Interface) com a participao dos usurios.

3.2.2.6 Definio do estilo da interao

O desenho da interface do usurio envolve a criao e utilizao de padres, usualmente chamados de Guia de Estilo, relacionados interao. Esses padres podem especificar, por exemplo, tipo de fonte a ser utilizado, formato de telas ou pginas web, comportamento e forma de elementos de interao, dentre outros. Padres so importantes no desenho de interface visando usabilidade no s porque facilitam a

37

utilizao pelos usurios, mas tambm pelo potencial de reuso que representam para o desenvolvimento. Um Guia de Estilo pode abranger padres, diretrizes ou at mtodos para o desenvolvimento da interao visando garantir a consistncia entre famlias de produtos ou mesmo dentro de um produto. Uma organizao que desenvolve software deve documentar os estilos de interao que utiliza em um Guia de Estilo, ou em um conjunto de guias de estilo para utilizao interna pelas equipes de desenvolvimento da interface com o usurio. Uma coleo de guias de estilo pode estar organizada em uma estrutura hierrquica, envolvendo relacionamentos de herana entre os documentos, de modo que um padro definido em um determinado nvel nesta hierarquia deve conformidade a padres definidos em nveis superiores da hierarquia. A atividade de definio de estilo da interao visa o desenvolvimento de um estilo de interao ou a atualizao ou a melhoria de estilos criados anteriormente. O Praxis-u prov um gabarito para a definio do estilo da interao denominado GEUS: Guia de Estilo de Usabilidade.

3.2.2.7 Desenho da interao

A atividade de Desenho da Interao parte dos resultados das atividades de anlise e de especificao de requisitos com o objetivo de se desenvolver a especificao da interface do usurio pronta para ser implementada em uma plataforma especfica. Cabe observar que a implementao da interface desenhada normalmente considerada fora do escopo da Engenharia de Usabilidade, sendo considerado um aspecto construcional e, portanto, como assunto para a Engenharia de Software. Assim, o resultado do desenho da interao uma especificao pronta para ser desenvolvida sob o aspecto construcional, objeto das disciplinas de Desenho e Implementao normalmente includas em um processo de desenvolvimento de software. O Desenho da interao uma atividade complexa, objeto de um subprocesso no Praxis-u, envolvendo, inclusive, atividades de avaliao da usabilidade com a utilizao de prottipos de desenho da interface do usurio.

38

3.2.2.8 Reviso do desenho da interao

O objetivo dessa atividade avaliar a qualidade e aperfeioar os artefatos produzidos nas atividades de Definio do Estilo de Interao e Desenho da Interao.

3.2.2.9 Avaliao de usabilidade

A Avaliao de usabilidade visa avaliao da qualidade da interface como instrumento da interao usurio-computador. comum serem feitas vrias avaliaes de usabilidade durante o ciclo de desenvolvimento de um produto de software. Um planejamento inicial da freqncia e tipo de avaliaes deve ser feito dentro da atividade de personalizao do processo para projetos especficos. Um planejamento detalhado de cada avaliao deve ser realizado dentro do cada ciclo pelo fluxo de usabilidade. Diferentes tipos de avaliao, com objetivos e caractersticas prprias, podem ser utilizados. Existem tcnicas de avaliao, como a Avaliao Heurstica, que utilizam o formato de revises. As avaliaes mais confiveis, no entanto, envolvem experimentaes com a utilizao de prottipos ou do produto final e a participao de representantes dos usurios. Estas avaliaes, tambm chamadas de testes com os usurios, normalmente fazem uso de roteiros de tarefas que so executadas por usurios com a utilizao de prottipos ou com o produto final, dependendo do estgio de desenvolvimento do software. No Praxis-u, o planejamento das avaliaes de usabilidade dever ser documentado em um documento prprio: dausw - Descrio de Avaliaes de Usabilidade. Um relatrio de cada avaliao tambm dever ser registrado em um relatrio denominado rausw Relatrio de Avaliaes de Usabilidade.

3.3 GLOSSRIO
REVISO Um processo ou reunio durante o qual um produto de trabalho ou um conjunto de produtos de trabalho apresentado a desenvolvedores, gerentes, usurios, clientes ou outras partes interessadas, para comentrios ou aprovao. (IEEE em Pdua Filho, 2009)

39

UML A Unified Modeling Language (UML) uma linguagem de modelagem que constitui um padro utilizado mundialmente para descrio de modelos usados no desenvolvimento de software. Foi definida inicialmente pelos criadores do UP (Unified Process), atualmente sob os cuidados da OMG. Basicamente, a UML permite que desenvolvedores visualizem os produtos de seus trabalhos em diagramas padronizados. Junto com uma notao grfica, a UML tambm especifica significados, isto , semntica. uma notao independente de processos, embora o RUP (Rational Unified Process) tenha sido especificamente desenvolvido utilizando a UML (Wikipedia n.d.). OMG O Object Management Group, ou OMG, uma organizao internacional que aprova padres abertos para aplicaes orientadas a objetos. O Object Management Group foi fundado em 1989. (Wikipedia n.d.).

3.4 BIBLIOGRAFIA
Booch, G.; Rumbaugh, J.; Jacobson, I., Unified Modeling Language User Guide, 2nd Edition, Addison Wesley, 2005. ISO 9241-11 Ergonomic requirements for office work with visual display terminals (VDTs) - Part 11: Guidance on usability 1998. ISO/IEC 9126 Information technology software product quality- part 1: quality model 1999, (FDIS). PADUA, W. Engenharia de Software: Fundamentos, Mtodos e Padres. 2. ed. Rio de Janeiro: Editora LTC, 2003. v. 1. 604 p. Rumbaugh, J.; Jacobson, I.; Booch, G., The Unified Modeling Language Reference Manual, Addison Wesley, 2nd edition, 2004. Wikipedia, em http://pt.wikipedia.org/wiki, acessado em 10/2009

40

4 ANLISE DE CONTEXTO DE USO

Este captulo detalha a atividade de Anlise de contexto de uso do Praxis_u que foi introduzida no captulo 3 deste texto. A Anlise de contexto de uso visa caracterizar todo o contexto envolvendo as pessoas e as atividades que elas realizam com o objetivo de coletar informaes importantes para outras atividades do processo de desenvolvimento. Neste texto, focamos a situao em que a Anlise de contexto de uso vai ser utilizada no processo de desenvolvimento de um produto de software. Isso, claro, no impede que esse tipo de anlise possa ser usado tambm para um produto j existente com objetivo de se fazer melhorias ou desenvolver uma nova verso, ou mesmo visando obteno de informao para se fazer uma avaliao mais criteriosa do produto. A Anlise de contexto de uso envolve diversos tipos de anlise que podem ser categorizadas como: Anlise de usurios Anlise de tarefas Anlise de Ambiente Anlise de Produtos Concorrentes ou Similares

importante ressaltar que os diversos tipos de Anlise de contexto de uso so interdependentes: por exemplo, a Anlise de tarefas fornece elementos para a Anlise de usurios e vice-versa. At por motivos didticos e para organizar o texto, separamos os diversos tipos de anlise. No entanto, normal que no levantamento de informaes associadas a um tipo de anlise sejam identificados aspectos relacionados a outro tipo de anlise. comum tambm que durante um tipo de anlise sejam lembrados de elementos que pertencem a outro tipo de anlise. Por exemplo, comum acontecer que durante uma Anlise de tarefas se identifique um novo papel de usurio, que ainda no havia sido registrado, e que se volte para melhorar a Anlise de usurios. por isso que se diz que o trabalho de modelagem por natureza iterativo e interativo!

41

H ainda o caso de atividades do processo que envolvem aspectos relacionados a mais de um tipo de Anlise de contexto de uso. Por exemplo, o Levantamento de modelos mentais est ligado Anlise de usurios, mas envolve tambm aspectos relacionados execuo de tarefas. Outro exemplo, o ambiente de realizao de atividades um aspecto que pode estar relacionado a um papel de usurio ou a uma tarefa que pode ser de responsabilidade de vrios papis de usurios. Algumas tcnicas so utilizadas para se obter as informaes desejadas na Anlise de contexto de uso. Essas tcnicas e aspectos a elas relacionados so apresentados na prxima seo.

4.1 TCNICAS
A caracterizao do contexto de uso de um produto de software deve ser realizada por meio do emprego de vrias tcnicas para obteno de informao, como as visitas a campo, entrevistas e reunies de prospeco. importante obter essas informaes sistematicamente para se garantir a qualidade dos dados obtidos e ouvindo, preferencialmente, os prprios usurios. Essa prtica est dentro da abordagem de desenvolvimento orientado pelo cliente e/ou usurios. A seleo da tcnica mais apropriada depende da informao desejada e dos custos envolvidos. Para gerar idias e conceber um modelo que leve em conta o ponto de vista dos usurios do produto, as tcnicas qualitativas so as mais apropriadas. Essas tcnicas permitem produzir um conjunto de informaes, o mais amplo possvel, evitando-se idias preconcebidas, buscando o conhecimento simplesmente ouvindo e observando os usurios ou outras fontes de informao apropriadas. As tcnicas qualitativas mais usadas so a observao direta e as entrevistas individuais ou em grupo. Quando se deseja obter informaes numricas, tais como, grau de preferncia entre verses de um mesmo produto, as tcnicas quantitativas so necessrias. Neste caso, pode-se usar o levantamento por questionrio (survey), que pode ser aplicado por meio de entrevistas diretas ou utilizando o correio e outros. A escolha da forma de aplicao do questionrio depende do tipo de informao que ser coletada, da velocidade desejada na resposta e oramento disponvel.

42

Para o desenvolvimento de um produto de sucesso deve-se fazer uso de ambos os tipos de tcnicas, qualitativas e quantitativas, uma vez que estas so complementares no tipo de informao que fornecem.

4.1.1 OBSERVAO DIRETA

Algum tipo de observao direta, formal ou informal, essencial para se obter uma compreenso do contexto de trabalho dos usurios finais (Hackos & Redish 1998). As observaes formais podem ser realizadas no prprio ambiente de trabalho dos usurios ou em laboratrio. A observao pode ser passiva (simplesmente ouvindo e observando) ou ativa (questionando). As observaes passivas podem servir de insumo para elaborao de questionrios e geralmente necessitam da realizao de entrevistas posteriores para descobrir as razoes de certas aes. A realizao das observaes depende dos prazos, permisso dos clientes e custos.

4.1.2 ENTREVISTAS
As entrevistas tm o objetivo de colher informaes sobre os usurios e as atividades que realizam atravs de conversas com pessoas envolvidas. As entrevistas se apiam na experincia dos entrevistados. As entrevistas podem ser feitas individualmente ou em grupos. Nas entrevistas individuais, deve-se buscar descobrir as caractersticas declaradas e as latentes, a forma com que a pessoa trabalha no cotidiano, as dificuldades e os aspectos positivos no modo com realizam suas atividades e as diferenas individuais dos usurios. J as entrevistas de grupos, so realizadas por meio de discusses abertas com um grupo de usurios. A forma como a reunio estruturada e conduzida depende da tcnica usada:

brainstorming ou oficinas de JAD (Joint Application Development) so algumas tcnicas

normalmente utilizadas. O JAD uma tcnica de oficina desenvolvida originalmente na IBM, mas hoje em dia utilizada largamente em vrias organizaes com o objetivo de se ganhar objetividade e eficincia me reunies de grupo - veja Glossrio. Entrevista uma tcnica muito utilizada, provavelmente ser mais rpida e prtica do que a observao direta dos usurios realizando suas atividades. No entanto, importante 43

observar que a entrevista tem a limitao de que a pessoa entrevistada vai sempre oferecer a sua verso de como as coisas acontecem. Inevitavelmente, a opinio de cada pessoa expressa uma tendenciosidade em funo de sua experincia pessoal. Essa tendenciosidade pode at ser intencional, quando envolve algum interesse da pessoa entrevistada. Mas a questo no esta, no que exista m f nas pessoas que concedem as entrevistas, isso um processo natural e que pode gerar distores. Por exemplo, a pessoa entrevistada tende a exagerar a importncia das coisas que faz bem feito e com as quais tem facilidade. Por outro lado, podem omitir ou minimizar suas dificuldades. Prs e contras considerados, pode-se dizer que a observao direta e a entrevistas so tcnicas que se complementam e que levam a informaes mais realistas e fidedignas sobre o contexto onde os usurios realizam suas atividades.

4.1.3 LEVANTAMENTO POR QUESTIONRIO

Essa tcnica indicada quando se deseja obter informaes tais como informaes sobre a experincia, atitudes e preferncias dos usurios que podem afetar o modo como eles realizam suas atividades. Geralmente so utilizadas quando se deseja informaes estatsticas sobre uma grande populao de usurios. Questionrios e levantamentos (surveys) so um meio alternativo para se saber a opinio dos usurios sobre algo e tambm descobrir quais caractersticas do produto so mais importantes para um determinado grupo de usurios. Quando comparados s entrevistas face-a-face ou oficinas de JAD (Joint Application Development) e Brainstorming, os questionrios so mais limitados na obteno de informaes. As questes abertas podem contornar essa limitao, uma vez que oferecem ao respondente a opo de livre expresso; no entanto, consome mais tempo para resposta e anlise. Geralmente, os questionrios so fontes de informao suplementar ou de confirmao de conjecturas. A construo de questionrios exige muitos cuidados e aplicao de tcnicas estatsticas para se conseguir coletar a informao desejada, fidedigna e com o mnimo de erros. As perguntas devem ser redigidas sem ambigidades, as escalas escolhidas com critrios apropriados e os pr-testes realizados com cautela. Por esses motivos, sempre que possvel, deve-se recorrer a profissionais da rea. 44

4.1.4 FONTES DE INFORMAO

Outro ponto a ser considerado na Anlise de contexto de uso so as fontes de informao. A principal fonte de informao e a que deve ser primeiramente consultada, quando possvel, o prprio usurio do produto. No entanto, outras fontes podem oferecer informaes complementares importantes para o desenho de uma interface, sob uma perspectiva diferente daquelas dos usurios finais. preciso ressaltar, no entanto, que a utilizao de outras fontes de informao no deve substituir, mas complementar, a observao direta e a entrevista envolvendo os usurios. As fontes alternativas de informao sobre o contexto de uso do software so mais teis medida que oferecem maior conhecimento sobre o usurio e suas necessidades reais. Por ordem decrescente de importncia, podemos citar as pessoas que atuam junto aos usurios, os informantes e intrpretes e as fontes no humanas.

4.1.4.1 Pessoas que atuam junto aos usurios

Alm das pessoas que sero usurios diretos do produto em considerao, h outros atores que atuam junto aos usurios ou que representam papis semelhantes e que, para alguns propsitos, podem complementar as informaes que so obtidas com os usurios finais. Os tipos de papis que podem ser considerados relacionados aos usurios e de interesse na Anlise de contexto de uso so apresentados a seguir. ESPECIALISTAS NO DOMNIO DA APLICAO Especialistas no domnio da aplicao so aquelas pessoas que tm um bom conhecimento do domnio de que trata o software em considerao, ainda que no sejam usurios (ou futuros usurios) do produto. Por exemplo, um bom Contador ser um especialista no domnio de Contabilidade quando estamos considerando um software para ser usado por um lojista, mas que vai envolver aspectos de contabilidade da loja onde for utilizado. Geralmente, os especialistas no domnio da aplicao oferecem perspectivas sobre as necessidades dos usurios finais que nem sempre os prprios usurios saberiam expressar. Entretanto, preciso cautela, pois o especialista pode no ter um conhecimento direto do trabalho a ser suportado, ou seja, as demandas e questes que surgem com a prtica no

45

trabalho dirio. Ou seja, o especialista complementa, mas nem sempre substitui, o usurio como fonte de informao. USURIOS DE SISTEMAS SIMILARES Usurios de produtos similares ao que est sendo desenvolvido podem fornecer informaes comparativas importantes e at estratgicas sobre diferenciais do outro produto, por exemplo, sobre pontos em que apresentam boas solues ou sobre necessidades que no so cobertas pelo produto que se tem em mente. Mesmo aspectos negativos do outro produto podem ser relevantes na medida em que podem ser explorados positivamente como um diferencial competitivo para o produto em considerao. INSTRUTORES Instrutores so responsveis por treinar pessoas em aspectos especficos de uma atividade alvo do sistema em considerao. O treinamento pode ser tambm no uso de um software semelhante ou uma verso anterior ao software em considerao. Instrutores tendem a ter alguma familiaridade com princpios gerais e assuntos prticos relacionados ao uso de um produto. Geralmente identificam o que no sistema ou no ambiente dificulta o aprendizado dos usurios ou causa ineficincia na realizao de algumas tarefas. SUPERVISORES Supervisores so os gerentes diretos dos usurios finais. So boas fontes de informao quando tm conhecimento de como realmente os usurios realizam o trabalho, no somente de como deveria ser realizado.

4.1.4.2 Informantes e Intrpretes

So aquelas pessoas que podem falar sobre as necessidades dos usurios ou interpretlas, mas no os substituem efetivamente. Geralmente, tm um conhecimento complementar, relacionado a algum aspecto do papel de usurio efetivo. Entre os candidatos a potenciais informantes e intrpretes esto os profissionais de marketing, vendedores, e pessoal do suporte tcnico SUPORTE TCNICO 46

As pessoas responsveis pelo suporte tcnico geralmente tm contato direto com os usurios e conhecem seu ambiente de trabalho. Podem ser uma boa fonte de informao sobre os usurios e o tipo de uso do software. O contato direto com os usurios finais propicia o conhecimento dos problemas que ocorrem quando estes utilizam o produto. No entanto, costumam saber pouco sobre como normalmente os usurios trabalham e sobre os aspectos que so relevantes em um projeto de interface dos usurios. MARKETING As pessoas responsveis pelo marketing podem servir como uma ponte entre os projetistas de interface e os usurios, mas, no entanto, podem ter somente uma viso limitada dos usurios e do produto. Muitas prticas da rea de marketing focalizam o mercado, tendo, portanto, conhecimento limitado sobre as necessidades do usurio e as circunstncias de uso do produto. Entretanto, h tambm prticas especficas de marketing que visam entender as necessidades do usurio, aquilo que ele valoriza, para que a empresa fornecedora do produto obtenha melhor posicionamento no mercado. importante, no entanto, considerar que, na maioria das vezes, as informaes obtidas via departamento de marketing, so insights sobre o que seria bom para os grupos potencias que utilizam ou utilizaro o produto. No podem ser confundidas com as informaes essenciais sobre os usurios e suas atividades, suas necessidades e a prtica de utilizao do produto. VENDEDORES De forma semelhante ao pessoal que cuida do marketing, para o vendedor s vezes mais importante conseguir clientes do que apreciar suas necessidades, ou seja, nem sempre o vendedor ter uma viso real da utilizao do produto pelos usurios. No entanto, em geral so mais indicados para serem ouvidos que os responsveis pelo marketing em face do contato direto com os usurios finais e a facilidade de acesso a eles. ESPECIALISTAS EM DOCUMENTAO Os especialistas em documentao so redatores e especialistas que escrevem manuais de usurios e criam artefatos de ajuda (help). Podem ser uma rica fonte de informao sobre os usurios e o modo de usar o produto, j que freqentemente so consumidores desse tipo de informao. Cabe lembrar que a documentao tambm objeto do trabalho que 47

visa garantir a usabilidade global do sistema, ou seja, a documentao faz parte do software e tem impacto em sua usabilidade.

4.1.4.3 Fontes no humanas

Os projetistas de interfaces tambm podem obter informaes a partir de objetos e artefatos produzidos nas empresas. Essas fontes podem ser importantes e usadas para complementar as informaes obtidas de humanos associados ao software em considerao. MANUAIS Manuais de padres, processos e procedimentos elaborados para definir o trabalho e a forma como deve ser realizado podem ser usados pelos desenvolvedores da interao como fonte de informao. No entanto, importante considerar que nem sempre expressam o modo prtico como o trabalho efetivamente realizado e, portanto, devem ser utilizados com cautela. Outro aspecto a considerar que os manuais podem ser usados para orientar o tratamento de aspectos especficos ou de circunstncias raras ou excepcionais. DADOS DERIVADOS Esta fonte refere-se informao sobre os usurios e suas necessidades que derivada de registros ou informaes obtidas para outros propsitos. Publicaes internas arquivadas na empresa podem ser uma boa fonte de informao indireta sobre o trabalho e necessidades dos usurios. Alm disso, banco de dados ou arquivos em papel contendo FAQs (Frequently Asked Questions) contm informaes sobre os problemas mais freqentes encontrados pelos usurios. Nem toda essa informao est relacionada com a usabilidade do produto, mas pode ter implicaes diretas ou indiretas. Por exemplo, um recurso ou servio que o usurio no consegue encontrar, talvez possa estar relacionado com o leiaute da interface ou a navegao. Feedbacks espontneos e queixas voluntrias relacionadas a verses anteriores do produto ou a produtos similares representam uma boa amostra a ser pesquisada. Ao se avaliar uma amostra desse tipo, deve-se pesquisar as causas dos problemas visando soluo, uma vez que geralmente nesse tipo de informao no se 48

registra quais caractersticas as pessoas consideram que proporcionariam um uso mais eficiente.

4.2 SUBPROCESSO DE ANLISE DE CONTEXTO DE USO

Nesta seo apresentamos o subprocesso de Anlise de contexto de uso do Praxis-u. As atividades e artefatos do subprocesso so apresentados de forma sistematizada, visando o leitor interessado no desenvolvimento da interao. A Anlise de contexto de uso produz artefatos que definem modelos, como o modelo de Personas que descreve papis de usurios, e o documento erusw.dot que registra toda a informao produzida. O diagrama de atividades abaixo apresenta o subprocesso de Anlise de contexto de uso. Cabe lembrar que, no diagrama, o retngulo com bordas arredondadas denota atividades e os outros retngulos denotam objetos, no caso, artefatos, que podem ser consumidos ou produzidos pelas atividades.

49

Figura 4-1: Atividades e artefatos do sub-fluxo de Anlise de contexto de uso

4.2.1 VISO GERAL

Basicamente, o subprocesso se inicia com as atividades de planejamento e preparao. A seguir, o diagrama apresenta trs fluxos de atividades que podem ser realizados em paralelo. Dois desses fluxos correspondem s atividades que visam modelagem de usurios e de tarefas. Os principais resultados da Anlise de contexto de uso so relacionados modelagem de usurios e de tarefas, que tm a finalidade de caracterizar os atores, as tarefas que eles realizam e os relacionamentos envolvendo os atores. Cada um desses fluxos constitudo de uma modelagem preliminar e outra mais detalhada. O outro fluxo trata da Anlise de Produtos Concorrentes ou Similares.

50

Cabe observar que, em geral, grande parte das tarefas de Anlise de contexto de uso so realizadas em campo, isto , no ambiente onde os potenciais usurios exercem suas atividades. O trabalho de campo envolve observao das pessoas no local onde realizam suas atividades e a realizao de entrevistas, conversas ou reunies de grupo com a participao das pessoas envolvidas visando coleta de informao para utilizao na modelagem. Portanto, as atividades de modelagem envolvem a realizao de trabalho de campo em paralelo com as atividades de modelagem no ambiente de trabalho dos desenvolvedores. Detalhando, as atividades da Anlise de contexto de uso, conforme prescritas no Praxis_u, so descritas abaixo.

4.2.2 PLANEJAMENTO
Nesta atividade, analisa-se o problema a ser resolvido, considerando-se os diversos tipos de Anlise de contexto de uso, e faz-se o planejamento dos trabalhos. O planejamento tem os seguintes objetivos: Identificao das pessoas de contatos, aquelas que podem dar orientaes iniciais (como por exemplo, sobre pessoas e locais para o trabalho de campo) para o trabalho de anlise a ser realizado. Definio da metodologia de trabalhos, especialmente do trabalho de campo. So definidas as formas do trabalho de observao e de entrevistas com as pessoas interessadas no produto. Programao das atividades a serem realizadas, incluindo cronograma de atividades e estimativas de escopo, recursos Alm disso, o Planejamento inclui a Definio estratgica conforme apresentado a seguir.

4.2.2.1 Definio estratgica

A Definio estratgica a atividade inicial que visa prover informao para o Planejamento e outras atividades da Anlise de contexto de uso. Nesta atividade, estudase o problema a ser resolvido, considerando o ambiente de negcio do qual far parte o produto em desenvolvimento. A Definio estratgica envolve identificao de aspectos estratgicos relacionados aos objetivos futuros de negcio da empresa que possam ter 51

impacto no produto em desenvolvimento. Por exemplo, a empresa quer expandir ou manter a posio no mercado? Quem so os clientes e concorrentes? Os resultados da atividade de Definio Estratgica so descritos em uma Declarao de Viso. DECLARAO DE VISO A Declarao de viso deve ser descrita no documento erusw. Esta apresenta uma concepo em termos estratgicos do produto em desenvolvimento. A Declarao de viso est muito relacionada anlise do negcio, muitas vezes executada na disciplina de Modelagem de Processos de Negcio utilizada na engenharia de software. O principal objetivo da Modelagem de Processos de Negcio se conhecer o negcio para apoio do qual o software ser desenvolvido, para que o software a ser desenvolvido possa estar alinhado com as necessidades de negcio. Sendo assim, podemos considerar a Declarao de Viso como uma sntese da descrio do negcio em termos estratgicos que usada como guia para o trabalho de Anlise de contexto de uso. A Declarao de Viso deve conter os seguintes elementos: objetivos, pressupostos e uma anlise inicial das partes interessadas (stakeholders). Deve tambm analisar o impacto desses aspectos no produto; conceito do produto em desenvolvimento; identificao de clientes, possveis usurios e demais partes interessadas: Quem so e quais suas caractersticas? Como a interao dos clientes com as mudanas no negcio? requisitos do negcio; descries do contexto do negcio corrente o que est mudando? o que importante? problemas que podem ser visualizados; quais tipos de resultados so esperados; possveis cenrios que podem vir a ocorrer; 52

concorrentes: quem so e o que fazem? de que modo esto mudando seus negcios?

tamanho e posio na indstria: como o negcio est posicionado na indstria? como a indstria est mudando?

ambiente do negcio: quais mudanas (especificamente poltica e tecnolgica) esto ocorrendo?

percepo pblica: como o pblico percebe a organizao? em que aspectos desejvel mudar essa percepo?

nvel de servio: qual o nvel do servio ao cliente? o servio pode ser melhorado ou estendido?

4.2.2.2 Detalhamento da atividade de planejamento

A atividade de planejamento realizada por meio de vrias tarefas que so apresentadas detalhadamente na Tabela 4-1. Alm de um detalhamento das tarefas, a tabela apresenta tambm os artefatos do processo Praxis-u envolvidos.
Descrio Insumos

Planejamento
1 Proposta de Especificao do Software (pesw) 2 Especificao de Requisitos do Software (ersw escopo do produto, funes do produto, restries, materiais de referncia).

Tarefas

1 Definio estratgica Atividade inicial que visa prover informao para o Planejamento e outras atividades da Anlise de Contexto. Estuda-se o problema a ser resolvido, considerando o ambiente de negcio do qual far parte o produto em desenvolvimento. Envolve identificao de aspectos estratgicos relacionados aos objetivos futuros de negcio da empresa que possam ter impacto no produto em desenvolvimento. Os resultados da atividade de Definio Estratgica so descritos em uma

53

Declarao de Viso no documento erusw. 2 Identificao das pessoas de contato. 3 Consulta a contatos e estudo da documentao disponvel, buscando informaes sobre os usurios e suas atividades relacionadas com o produto em desenvolvimento, tais como: informaes dos usurios coletadas em entrevistas durante as sesses de JAD ou distncia, sobre suas tarefas e modo de realiz-las; informaes internas empresa fornecedora do produto, ou seja, referentes ao histrico de produtos similares ou a ser substitudo; reclamaes dos usurios, no caso de produto a ser melhorado. as principais tarefas de usurios s quais o sistema dever dar suporte; os objetivos dessas tarefas e a maneira como se relacionam logicamente; os recursos tcnicos e fsicos disponveis para a realizao da tarefa, incluindo treinamento e apoio tcnico; o fluxo de informaes, ou seja, quem emite e quem recebe informaes na realizao de uma determinada tarefa na empresa cliente; quais so os documentos produzidos ou consumidos, suas estruturas, volume e modo de utilizao; o escopo do sistema: principais requisitos funcionais e no funcionais e restries sobre o desempenho, segurana, equipamentos. Identificao de produtos concorrentes ou similares com registro de suas caractersticas mais relevantes. Resultados 1 Eventuais pedidos de esclarecimentos s pessoas responsveis pelos outros tipos de anlises. 2 Levantamento inicial dos requisitos. 3 Programao das atividades de Anlise de contexto de uso. 4 Eventuais solicitaes de melhorias nos resultados de anlises realizadas anteriormente.

Tabela 4-1 Atividade de planejamento

4.2.3 PREPARAO
Nesta atividade identifica-se a populao alvo, isto , definem-se quais so as pessoas que devero ou podero usar o sistema e classifica-se essa populao, estabelecendo-se grupos de usurios com limites bem claros. Cabe observar que no se trata de uma Anlise de usurios, apenas de uma identificao em mais alto nvel de abstrao da populao alvo com o objetivo de se definir as pessoas que sero objeto da Anlise de usurios. Preparam-se os artefatos a serem usados durante o trabalho de anlise, especialmente no trabalho de campo. Faz-se o contato com as pessoas selecionadas para o trabalho de 54

campo visando prestar esclarecimentos sobre as atividades a serem realizadas e combinar os encontros de trabalho.

4.2.3.1 Detalhamento da Preparao

A atividade de Preparao da Anlise de contexto de uso consiste principalmente no levantamento da populao alvo, apresentado na Tabela 4-2.

Descrio Insumos

Preparao 1 Especificao de requisitos de Software (ERS) 2 Documentao do planejamento da anlise

Tarefas

1 Identificao das pessoas que potencialmente usaro o produto, direta ou indiretamente, em termos dos papis que podem assumir em relao ao produto, podendo ser: pessoas que comprariam o software e o utilizariam sem assistncia ou interao com outras pessoas, em casa ou em seus locais de trabalho; grupos de pessoas que usariam o produto como parte do trabalho que realizam ou como parte do processo de negcio; aqueles que iriam administrar o produto; pessoas que dariam suporte ao produto; pessoas que seriam responsveis pela instalao do produto para si e para outras; clientes dos usurios que sofreriam algum tipo de impacto devido ao uso do produto. 2 Categorizao dos possveis usurios em grupos e definio das categorias que o produto atender prioritariamente. 3 Preparao dos artefatos a serem usados nos trabalhos. 4 Fazer contatos e marcar encontros de trabalho.

Resultados

1 Lista preliminar de usurios potenciais e respectivas categorias.

Tabela 4-2 Levantamento da populao alvo

4.2.4 MODELAGEM DE USURIOS

Esta atividade visa modelagem dos papis de usurios, incluindo os vrios aspectos a eles relacionados. A modelagem de usurios foi subdividida em duas atividades que visam uma modelagem preliminar e um refinamento da modelagem dos usurios. Essas atividades so apresentadas na seo 4.3 Anlise de usurios adiante. 55

4.2.5 MODELAGEM DE TAREFAS

Esta atividade visa modelagem das tarefas, realizadas pelos usurios, que vo ter apoio do sistema em considerao. O apoio do software realizao de uma tarefa pode ser parcial, apoiando a realizao de partes das tarefas consideradas, ou pode se dar em maior grau com o sistema apoiando at a realizao completa da tarefa. H vrias formas de modelagem de uma tarefa, a escolha da forma de representao vai depender do tipo de tarefa, do tipo de apoio que se deseja que o sistema proveja e do detalhamento que se deseja atingir na modelagem da tarefa. De forma semelhante modelagem de usurios, a modelagem de tarefas tambm foi subdividida em duas atividades que visam uma modelagem preliminar e um refinamento da modelagem. Essas atividades so apresentadas na seo 4.4 Anlise de tarefas adiante.

4.2.6 ANLISE DE PRODUTOS CONCORRENTES OU SIMILARES

Esta anlise visa coleta de informaes para que se possa melhorar o produto em considerao a partir do conhecimento das fraquezas e pontos fortes dos produtos concorrentes ou similares. A Anlise de Produtos Concorrentes ou Similares pode ser realizada por meio de avaliaes de usabilidade de maneira mais formalizada ou de forma simplificada, como tambm pode ser complementada com anlises disponveis em revistas ou outros meios que podem dar subsdios valiosos para o desenvolvimento de um sistema. Quando possvel, a anlise de vrios produtos concorrentes permite uma avaliao comparativa bem interessante.

4.2.7 BALANO FINAL

Esta atividade visa basicamente verificao dos artefatos produzidos na Anlise de contexto de uso, incluindo a verificao da consistncia entre os diversos modelos. A atividade de Balano Final tem tambm o objetivo de registrar as concluses e lies aprendidas. As atividades de Balano Final esto descritas na Tabela 4-3.

56

Descrio Insumos

Reviso
1 Especificao de requisitos de Software (ersw) 2 Modelo de Atores Humanos 3 Informao levantada no trabalho de campo. 4 Manuais de usurios (de sistemas similares, se existirem, ou do atual, a ser melhorado).

Tarefas

1 Verificao dos artefatos produzidos, analisando sua correo e facilidade de entendimento. 2 Registro de concluses e lies aprendidas. 3 Realizao de melhorias no modelo, se necessrio.

Resultados

1 Artefatos relativos modelagem de usurios, de tarefas e anlise de produtos concorrentes e similares completos e revisados.

2 Seo da erusw que documenta a Anlise de contexto de uso completa e

revisada.

Tabela 4-3 Balano final

4.3 ANLISE DE USURIOS

4.3.1 VISO GERAL

A atividade de Anlise de usurios visa caracterizar a populao-alvo envolvida na utilizao do produto de software em perspectiva. A Anlise de usurios bastante relacionada com a Anlise de tarefas; em geral, essas atividades so realizadas em um processo incremental e iterativo, onde a Anlise de usurios d subsdios para a Anlise de tarefas, inclusive sugerindo novas tarefas a serem consideradas para serem contempladas no produto, e vice-versa. Do ponto de vista de engenharia de usabilidade, nos interessa caracterizar os usurios somente com relao aos aspectos que tm algum impacto no desenvolvimento do produto. O termo utilizado por (Constantine & Lockwood 1999) para representar uma abstrao das caractersticas relevantes dos usurios o de Papel-de-usurio, segundo ele: uma coleo abstrata de necessidades, interesses, expectativas, comportamentos e responsabilidades, caracterizando um relacionamento entre uma classe de usurios e o sistema. No contexto deste documento, assim como no Praxis-u, alm do termo Papel-de-usurio usaremos 57

tambm o termo Ator j que este termo consagrado na Engenharia de Software. No entanto, lembramos que o termo Ator usado na usabilidade refere-se somente a atores humanos. importante tambm notar que o Ator uma abstrao, no correspondendo a pessoas com existncia real. Um Ator pode abstrair o papel de vrias pessoas assim como uma pessoa pode desempenhar papeis que so modelados em vrios atores. Diferentes tcnicas podem ser usadas para a modelagem de usurios, por exemplo, os papis de usurio propostos por Constantine e Lockwood (Constantine, L.L. & Lockwood, L.A.D. 1999), as formas mais descritivas propostas por Hackos, JT & Redish (Hackos, JT & Redish, 1998) ou modelos mais simples como proposto por Hix e Hartson (Hix, D.; Hartson, H. R., 1993). Aqui, preferimos sugerir a tcnica de Personas, apresentada na seo 4.3.3, por ser considerada barata, fcil e, de certa forma, intuitiva e ldica para a equipe de desenvolvimento de um projeto.

4.3.2 OBJETIVOS
A Anlise de usurios visa obteno de conhecimento detalhado dos possveis usurios para que se possa desenvolver uma soluo de interface adequada para o tipo de utilizao que se espera do produto. A Anlise de usurios de um sistema interativo tem como objetivos especficos: Identificar e conhecer os diversos tipos de usurios que potencialmente utilizaro o produto; Caracterizar os usurios em todos os aspectos relacionados com seu modo de trabalho ou de comportamento que possam ter importncia para o desenvolvimento do produto; Gerar um modelo de usurios, incluindo o relacionamento entre atores, a partir das informaes obtidas; Fornecer insumos para a definio de requisitos e metas de usabilidade que devem ser observados para determinados atores; Definir os atores focais, ou seja, quais atores devem ser considerados prioritariamente no desenvolvimento do produto; 58

Fornecer insumos para o desenho da interao, tais como a arquitetura global, a navegao e o contedo da interface, o leiaute e o look-and-feel dos elementos de interao.

Fornecer insumos para o planejamento e especificao das avaliaes de usabilidade.

A Anlise de usurios representa um importante insumo para se conseguir agregar valor ao produto no sentido de torn-lo mais efetivo como ferramenta de apoio ao trabalho, ou outro tipo de atividade do usurio. Abaixo so listadas algumas questes mais comuns que se procura investigar na Anlise de usurios. Quais so os grupos de usurios envolvidos direta ou indiretamente com o produto em perspectiva? O que os usurios do software iro fazer que tenha relao com o produto que est sendo desenvolvido? Quais so os interesses dos usurios que possam estar relacionado com o produto em desenvolvimento? Em que os usurios necessitam do sistema para realizar algo ou alguma tarefa? Como o sistema deve prover o que eles necessitam? O que no momento atual no est funcionando ou ineficiente? Como o sistema seria mais efetivo para suportar as atividades do usurio?

4.3.3 PERSONAS

4.3.3.1 Introduo
Persona era o nome da mscara que atores do teatro grego usavam na caracterizao de um personagem (Wikipedia n.d.). O uso de personas como uma tcnica foi popularizado por Alan Cooper, em seu livro The Inmates are Running the Asylum (Cooper, 2000). Cooper introduziu o uso desse termo como uma ferramenta ou tcnica usada no desenho da interao no desenvolvimento de software. O livro de Cooper, por sua vez, trata das caractersticas, da utilizao e de boas prticas para a criao de personas. A Persona um personagem fictcio usado para caracterizar um Papel-de-usurio de um produto de software. A figura 1 (Wikipedia n.d.) ilustra um exemplo de um grupo de 59

personas utilizado em um projeto de desenvolvimento de software. A Persona como uma ersona ficha de personagem de RPG do usurio modelo, criada a partir de dados reais como: usurio-modelo, nome, gostos, hbitos, habilidades etc (Mulder, 2006). Essas informaes podem ser . obtidas atravs de entrevistas com usurios potenciais ou atravs de conversas com quem stas lida freqentemente com esse pblico. A tcnica de Personas aqui muito utilizada para a modelagem de usurios onde um Papel Papel-de-usurio modelado como uma persona. usurio

Figura 4-2 Grupo de Personas usado no projeto da ferramenta de diagramao Kivio (Similar ao Microsoft Visio) MOTIVAO No desenvolvimento de uma boa interface de software importante conhecer muito bem os perfis das pessoas que vo utilizar o produto (Cooper, 1999). Porm, como registrar 1999). 60

esse conhecimento de forma prtica durante o desenvolvimento? Como lidar com as diferenas que existem entre os usurios? Como no perder de vista as caractersticas relevantes dessas pessoas? As Personas se aproveitam do poder das narrativas para aumentar a ateno, a memorizao e a organizao dos dados coletados sobre os usurios. A tcnica de Personas considerada barata, fcil e at divertida para a equipe de desenvolvimento de um projeto. No ritmo agitado da produo tecnolgica, poucos so os que tm tempo (e interesse) em ler relatrios de dezenas de pginas sobre os estudos de usabilidade, a etnografia e as pesquisas de mercado do marketing (Grudin, 2002). Quando uma descoberta importante feita sobre a utilizao de um sistema que est sendo desenvolvido, muito mais fcil comunicar a equipe toda, dizendo, por exemplo: "o Adalberto no est conseguindo usar a ferramenta de busca na nossa pgina, no lugar de "uma quantidade representativa dos participantes nos testes de usabilidade tiveram problemas com a ferramenta de busca". COMO PODEM SER UTILIZADAS As Personas podem ser utilizadas em diferentes fases do projeto, contribuindo de forma distinta para cada uma delas. Abaixo so listados alguns exemplos do uso de Personas:

Fase do projeto
Definio do produto:

Exemplo de uso
Personas podem ajudar a determinar o que vai ser includo no produto e o que vai sair. Elas podem ser utilizadas na especificao de requisitos do sistema. Personas podem ajudar a equipe de desenho a definir como uma ferramenta ir se comportar. Para isso, podem ser criados, com o auxlio delas, cenrios realistas de utilizao do sistema. Personas podem ajudar a garantir a qualidade dos testes do produto, possibilitando os testadores escrever scripts de teste mais realsticos. possvel tambm que seja feita uma priorizao na correo de bugs do sistema.

Desenho do produto:

Medio e avaliao do produto:

VANTAGENS As principais vantagens da tcnica de Personas so (Mulder, 2006): 61

Engaja e conscientiza a equipe de projeto; Mantm o foco no usurio durante todo o projeto Facilita a chegada em um consenso sobre os interesses do usurio; Facilita a tomada de decises no projeto, porque no preciso consultar usurios reais a cada etapa de desenvolvimento;

De forma geral, Personas so um meio muito eficaz de comunicao interna da equipe. Na Microsoft, por exemplo, esse mtodo muito utilizado nos projetos de software. Eles criam cartazes atraentes comparando as caractersticas das personas, imprimem camisetas, bons e at mesmo canecas com os seus rostos, tudo para lembrar constantemente a equipe do foco do projeto. Outro ponto forte no uso de Personas sua capacidade de conciso para apresentar resultados de pesquisa. CUIDADOS Apesar de constituir um mtodo eficiente de representao de um Papel-de-usurio, Personas que no se baseiam em pesquisas rigorosas podem ser manipuladas para defender pontos de vista de membros da equipe de projeto. A tentativa de criar e alterar uma Persona de acordo com o que for mais cmodo para a equipe, ou para um profissional em particular, pode ser desastrosa. possvel que criadores das Personas, por exemplo, se sintam tentados a usar caricaturas para torn-las ainda mais atrativas. Uma Persona muito usada com esse intuito a chamada "minha me" ou "minha av". Muita gente j deve ter ouvido frases do tipo: "isso a nem minha me conseguiria usar!". Em geral, as pessoas acham mais fcil usar esses termos, porque podem assim julgar pelo senso-comum. Trata-se de um mero artifcio retrico para parecer que se est preocupando com o usurio. Na maioria das vezes, a "me" (ou a "av") nem faz parte do pblico-alvo da interface em questo e, mesmo quando faz, sua capacidade de representar a totalidade do pblico acaba sendo exagerada. Isso muito usado porque uma figura familiar, fcil de compreender. Se voc fala da sua me, eu consigo imaginar melhor como ela vai reagir do que uma figura abstrata representando "mulheres entre 40 e 55 anos". Entretanto, essa abordagem corre o risco de distanciar as decises da realidade, desviando o sentido original das Personas, que orientar o desenho centrado em usurios reais.

62

De que adianta saber somente que o usurio tem entre 30 e 45 anos na hora em que voc vai definir o fluxo de uma determinada tarefa? muito mais interessante saber como essas pessoas agem em situaes parecidas. Alan Cooper, criador da tcnica de Personas, recomenda que sejam feitas sempre entrevistas, observaes, testes de usabilidade, card-sorting, anlises das tarefas, leituras e estudos etnogrficos etc. As Personas vm depois, para resumir tudo aquilo que costuma ser colocado em extensos relatrios. Vale ressaltar que cada detalhe da persona deve estar muito bem embasado em dados reais, no em meras presunes. Personas no uma tcnica de coleta de dados, mas sim uma tcnica de agrupar e apresentar resultados de pesquisas. Quando so tratadas como fim e no meio, acontece toda uma distoro, pois a pesquisa passa a ser enviesada para sustentar os perfis, muitas vezes definidos antes mesmo que ela acontea.

4.3.3.2 Categorizao de Personas

A subdiviso de Personas em categorias permite que, no projeto, sejam focados os usurios cujas necessidades so as mais importantes. A distribuio das categorias (e a nomenclatura delas) pode variar de um autor para outro na literatura, mas o mais importante que sejam definidos critrios de priorizao para elas. PERSONAS PRIMRIAS Representam os usurios mais crticos no projeto. Os seus objetivos tm de ser satisfeitos, ou o risco de que a experincia da maioria dos usurios ao utilizar o sistema seja frustrante aumenta muito. Cada persona primria requer uma interface nica, a fim de que suas metas sejam efetivamente atendidas. PERSONAS SECUNDRIAS Personas secundrias so usurios que influenciam o design da interface, mas no representam necessariamente o foco principal do projeto. Personas secundrias incluem os usurios de nvel iniciante, utilizadores intermitentes e at mesmo os peritos. Uma interface que satisfaz apenas as necessidades das Personas secundrias ir frustrar e confundir as primrias. As necessidades 63

nicas das Personas secundrias, no entanto, devem ser atendidas, a fim de tornar os produtos viveis para um grande nmero de usurios no mundo real. PERSONAS SUPLEMENTARES So usurios que precisam ser representados, porque sua participao influencia no projeto da interface, ainda que no faam parte diretamente dos usurios focais do projeto.

4.3.3.3 Criao de Personas

Dois aspectos so muito importantes durante um trabalho de Anlise de contexto de uso de um sistema utilizando a tcnica de Personas: Entender bem o que os usurios fazem e dizem; Definir a metodologia de pesquisa que ser utilizada;

O QUE OS USURIOS DIZEM E O QUE FAZEM A importncia maior de se estudar minuciosamente o que as pessoas dizem e aquilo que elas fazem est no fato de que o que as pessoas dizem fazer no necessariamente o que elas fazem (Mulder, 2006). Em testes de usabilidade, por exemplo, os usurios muitas vezes claramente lutam tentando realizar uma determinada tarefa, mas, ao final, acabam dizendo que a tarefa foi fcil. Portanto, para entender bem os usurios de um sistema e realizar uma boa atividade de Personas, preciso entender ambos os aspectos. Alan Cooper incentiva o uso de tcnicas etnogrficas para o estudo dos usurios, porque tais tcnicas assumem que as atitudes de um sujeito e seus comportamentos so to habituais que podem estar no inconsciente de cada um. Ao invs de perguntar o que querem os usurios, mais eficaz concentrar-se naquilo que os usurios fazem, o que os deixa frustrados, e o que lhes d satisfao. Combinando entrevistas com a observao direta dos

usurios possvel obter uma grande quantidade de dados muito rapidamente. Se houver tempo e oramento, as descobertas podero ser verificadas com levantamentos quantitativos ou outras tcnicas, mas elas no podem substituir a observao direta. 64

O QUE OS USURIOS DIZEM Atitudes revelam como as pessoas percebem a si prprias e suas experincias. Entrevistas e pesquisas com questionrios so mtodos comuns para pesquisar o que as pessoas dizem e para aprender sobre seus objetivos e atitudes. Aquilo que as pessoas dizem revela seus objetivos, ou seja, aquilo que elas querem fazer. Se os objetivos no forem bem entendidos, no ser possvel saber o que melhorar e como melhorar no projeto de uma interface. O QUE OS USURIOS FAZEM O comportamento das pessoas revela aquilo que elas fazem. Atravs da anlise do comportamento, possvel saber, por exemplo, onde os usurios podem estar tendo problemas na realizao de suas atividades. As anlises feitas em um teste de usabilidade, por exemplo, compreendem tambm o comportamento do usurio enquanto utiliza uma determinada interface. A observao ajuda a minimizar os chamados "comportamento auto-reportados, que muitas vezes so imprecisos.

4.3.3.4 Metodologias de pesquisa

Nesta subseo, sero apresentadas as principais metodologias de pesquisa utilizadas para a construo das Personas, detalhadas no livro The User is Always Right: A Practical Guide to Creating and Using Personas for the Web, de Steve Mulder. Para cada uma das metodologias, sero abordadas trs etapas bsicas de construo das Personas: conduo da pesquisa, segmentao dos usurios baseada na pesquisa e definio das Personas para cada segmento. Ao final da apresentao das metodologias, ser apresentada uma tabela comparativa entre elas, com diretrizes sobre quando utilizar cada uma das abordagens.

4.3.3.5 Pesquisa qualitativa

um tipo de pesquisa que visa descobrir informaes novas sobre um pequeno conjunto de amostra. Essa metodologia utilizada quando o estudo para formar as Personas feito com um conjunto pequeno de usurios (de 10 a 20). Uma desvantagem da pesquisa qualitativa que ela no prova nada definitivamente, j que os dados no so analisados por meio de tcnicas estatsticas. Esse tipo de metodologia utilizado para definir um problema, gerar hipteses sobre ele, identificar 65

alguns determinantes e desenvolver meios de pesquisa quantitativa. A grande vantagem que esse tipo de pesquisa pode ser feita de forma relativamente rpida. Abaixo apresentamos os passos principais na conduo de uma pesquisa qualitativa. PASSO 1: CONDUO DA PESQUISA Neste passo, so realizadas entrevistas com usurios, que representam a forma mais comum de pesquisa qualitativa. feito tambm um trabalho de anlise do ambiente dos usurios, em que ocorre a observao de suas atividades e comportamentos no ambiente real de utilizao do futuro sistema. Enquanto se observa o comportamento dos usurios, questionamentos podem ser feitos sobre seus objetivos e atitudes. Voc saber que pode parar de entrevistar quando se pode prever como cada usurio ir responder. Isso significa que padres esto comeando a surgir. Assim que as entrevistas forem terminadas, devem ser listadas todas as variveis comportamentais, ou seja, as diferentes formas de comportamento dos entrevistados. A maioria das variveis pode ser representada como intervalos com dois extremos. Em um domnio de um shopping, por exemplo, poder haver variveis tais como a freqncia de compras, o grau de diverso, a importncia para o preo e o servio de orientao. Tambm poder haver variveis demogrficas que paream afetar o comportamento dos usurios, tais como a idade ou a habilidade tcnica. Mas importante ser cuidadoso ao focar na demografia durante a criao das Personas, uma vez que variveis comportamentais vo ter muito mais impacto sobre o desenho das interfaces. PASSO 2: SEGMENTAO DOS USURIOS Segmentao a arte de pegar muitos pontos e criar agrupamentos que podem ser descritos em funo de aspectos comuns entre os membros de um grupo. Em Personas, o objetivo encontrar padres que permitam agrupar pessoas com perfis similares juntas em determinados tipos de usurios. Essa segmentao das Personas normalmente baseada em seus objetivos, atitudes e/ou comportamentos. Porm importante ressaltar que segmentos no so personas. Segmentos so listas de caractersticas, possivelmente suportadas por planilhas eletrnicas de nmeros. Personas so personificaes dessas caractersticas, uma transformao dessas listas de fatos e caractersticas em histrias que outras pessoas entendam rapidamente, relembrem e utilizem, agindo de acordo com elas. 66

Como criar esses agrupamentos absolutamente crtico, e talvez, a parte mais difcil durante a criao das personas. Isso porque se o principal aspecto da definio de personas, a segmentao, no claro ou til, a utilizao de personas no se torna um hbito. No h uma maneira sempre certa de fazer a segmentao. Segmentao no uma cincia. Pense em segmentao como a arte de encontrar padres e histrias nos dados. O processo de segmentao colaborativo e iterativo. Colaborativo, porque independentemente da abordagem, ter que envolver todos os interessados (stakeholders) chaves de todas as partes da organizao: donos dos produtos, marketing, desenho, servios de clientes, vendas e outros que interagem com os usurios. Iterativo, porque todo ano pesquisas adicionais so conduzidas com os usurios reais para validar sua segmentao inicial. Mudanas de negcio, de ambiente e de usurios implicam na necessidade de validar as personas iniciais para verificar se ainda esto vlidas. Para optar por uma segmentao particular, algumas perguntas precisam ser feitas, por exemplo: os segmentos explicam as diferenas chaves que tm sido observadas? Conversando com os usurios, so notadas as diferenas entre indivduos: o que eles fazem, como eles fazem, o que eles pensam e/ou quem eles so? A abordagem de segmentao utilizada mostra essas diferenas-chave? Os segmentos so suficientemente diferentes uns dos outros? Se a nica diferena entre dois segmentos a idade dos usurios, ento eles representam o mesmo segmento. A segmentao pode ser descrita rapidamente? melhor encontrar um, dois ou trs fatores que melhor define cada segmento, descrever bem esses fatores e simplificar ligeiramente visando aumentar a compreenso. Os segmentos cobrem todos os usurios? Deve estar claro que todo usurio entrevistado se ajusta a um dos segmentos que est sendo explorado. A segmentao pode ser descrita rapidamente? melhor encontrar um, dois ou trs fatores que melhor define cada segmento, descrever bem esses fatores e simplificar ligeiramente visando aumentar a compreenso. Os segmentos cobrem todos os usurios? Deve estar claro que todo usurio entrevistado se ajusta a um dos segmentos que est seno explorado. Na metodologia de Personas qualitativa, a segmentao tambm um processo qualitativo. Tratamos aqui menos de cincia e mais sobre o pblico. importante rever aqui as anotaes feitas no Passo 1 e escutar novamente os usurios, quando necessrio. No desenvolvimento de um site de compras, por exemplo, os usurios podem ser

67

entrevistados e, ento, segmentados, baseando-se em seus objetivos: comprar uma casa, encontrar um apartamento, vender uma casa etc. ATRIBUTOS QUE DEVEM SER CONSIDERADOS NA SEGMENTAO: Recomenda-se utilizar atributos que revelem como as pessoas atualmente usam o produto. No caso de um site, so eles: objetivos do usurio ao usar o produto: o que os usurios querem fazer. Comportamento: como eles fazem isso? Atitudes: como eles percebem a experincia ou eles mesmos? Comece segmentando por objetivos. Caso a primeira abordagem no seja a mais adequada, segmente por ciclo de vida de uso. Se a segunda no for melhor opo, segmente baseando-se em uma combinao de comportamento e atitudes. Outro exemplo: imagine que voc tenha um conjunto de rochas. Sua misso descrever os diferentes tipos de rochas nesses conjuntos. Voc pode organizar as rochas pelo tamanho e, ento, descrever cada grupo. Voc pode agrupar pela cor ou textura, ou voc pode considerar a classe geolgica e ento agrupar pelo tipo (sedimentar, gnea etc.). Organizar todos essas rochas individuais em clusteres tudo o que a segmentao faz. Todos os usurios so nicos. Mas, para falar sobre quem so seus usurios e o que fazem com seus conhecimentos, voc tem que agrup-los em segmentos que no final sero transformados em Personas. PASSO 3: DEFININDO PERSONAS Neste passo, so criadas Personas para cada segmento. Cada tipo de usurio representado por uma Persona, de acordo com os detalhes levantados envolvendo seus objetivos, comportamentos e atitudes. As Personas se tornaro realsticas quando forem relacionadas a elas um nome, uma foto, informaes demogrficas, cenrios etc. CRIANDO O NOME A escolha do nome importante porque de certa forma sintetiza o carter da Persona. Por ser importante, o processo de escolha do nome deve ser colaborativo. Pessoas tm respostas diferentes para nomes diferentes. Dessa forma, interessante encontrar um nome que todos sintam ser o nome certo para a Persona. Voc saber que suas Personas esto funcionando quando os membros da equipe na empresa comearem a referenci-la pelo nome. 68

ESCOLHENDO A FOTO Personas no adquirem vida sem foto. A foto que voc escolhe tem um forte impacto em como os outros vero as Personas. Assim como o nome, a escolha da foto um processo colaborativo. Quando se est trabalhando com a abordagem de segmentao, todos comeam a formar uma imagem mental de quem so essas pessoas. Dessa forma, pode levar tempo para encontrar uma foto que todos concordem como sendo verdadeiramente a Persona representada. No use pessoas que so modelos, ou que, de alguma maneira, podem ser vistas como modelo. importante escolher caractersticas realsticas que representem usurios reais. A escolha de fotos que no representem pessoas reais, com falhas reais, terminar com a criao de perfis de usurios que podem causar confuses durante as tomadas decises (Chapman, 2006). No se preocupe em escolher fotos imperfeitas, porque elas so para uso interno. Entretanto, para qualquer imagem utilizada, tenha certeza de que ela a certa para o que voc pretende. Evite poses fotogrficas. Uma face sorrindo para a cmera agradvel, mas se a imagem for cuidadosamente planejada ou no natural ela no adequada para a Persona. Assim como o nome, fotos devem ser apropriadas para a personalidade que est sendo criada. Pense nas roupas que a pessoa costuma vestir, no estilo de cabelo, na maquiagem e constituio, entre outros. Escolher uma foto significa escolher uma idade, mas no fique confinado a isso. No interessante ter quatro personas com a mesma idade. Opte pela diversidade, particularmente de raa. Recomenda-se usar rosto e ombros para as fotos, porque a face captura um excelente nvel de detalhes de personalidade. Certifique-se de escolher fotos em que as pessoas esto olhando na direo da cmera fotogrfica e no que estejam de perfil. Voc deve ser capaz de ver os rostos das Personas claramente. No bom que a foto tenha outras pessoas ou objetos prximos. Isso pode distrair aqueles que iro utiliz-la. Use fotos com cores, com alta resoluo e que no sejam distorcidas quando forem impressas. Isso porque voc usar as fotos de vrias maneiras (impressa e em apresentaes).

69

(a) Usurio com ateno dispersa

(b) Usurio acompanhado

Figura 4-3 Fotos Ruins

Figura 4-4 Fotos Boas

NMERO DE PERSONAS Recomenda-se de 3 a 7 personas (Cooper, 2004). So recomendadas de 3 a 6 personas por stio Web. Com menos de duas personas voc est perdendo algumas diferenas chaves entre os usurios. Com mais de seis, provavelmente voc pode combinar as personas. Alm disso, podem ser desenvolvidas personas demais para a equipe mant-las corretas. Quanto mais personas, mais risco de interesses conflitantes e confuses.

70

4.3.3.6 Pesquisa quantitativa

Pesquisa quantitativa uma metodologia de pesquisa utilizada para testar ou provar alguma coisa com tamanho de amostra grande. As informaes e dados coletados so analisados estatisticamente, atravs de mtodos conhecidos. De maneira prtica, nessa abordagem so testadas uma variedade de modelos de segmentao, com o objetivo de encontrar o modelo que mais adequado e til para criar as Personas. Sua vantagem oferecer uma compreenso melhor e mais realista da amostra de usurios que est sendo estudada. Esse tipo de pesquisa muito utilizado na anlise do trfego em sites. Por exemplo, dizer que 35% dos sites nunca foram visitados uma informao com considervel grau de preciso.

Para que sejam criadas as Personas atravs de uma metodologia de pesquisa quantitativa, so realizados cinco passos, descritos abaixo. PASSO 1: CONDUO DA PESQUISA De forma semelhante ao que ocorre na pesquisa qualitativa, so analisados aqui tambm os objetivos, comportamentos e atitudes dos usurios. A pesquisa pode ser feita por meio de questionrios e entrevistas, no ambiente real de utilizao do futuro produto. PASSO 2: FORMULANDO HIPTESES PARA A SEGMENTAO So levantadas as vrias potenciais maneiras de segmentar os usurios, de acordo com os dados levantados no passo anterior. O objetivo uma fazer uma lista de uma variedade de candidatos que podero ser analisados. PASSO 3: REUNINDO DADOS PARA A SEGMENTAO O objetivo aqui reunir mais dados para a etapa de segmentao. Para cada potencial opo de segmentao, h questes particulares que precisam ser respondidas atravs de questionrios, ou questes que precisam ser respondidas atravs da anlise do trfego de um site. Por exemplo: histrias de usurios sobre a experincia de utilizao de um site pode ser uma maneira de segmentar. Sendo assim, uma questo do questionrio preparado para a pesquisa pode abordar quanto tempo e com que freqncia os usurios utilizam o site. 71

Se uma longa lista de opes de segmentao estiver sendo avaliada, para ter os candidatos mais promissores, uma estratgia muito til colocar as variveis em um grfico. Da lista de variveis, selecionam-se duas. Coloque um atributo no eixo vertical e outro na horizontal e um grfico ser construdo com quatro quadrantes. Cada quadrante representa uma possvel configurao das personas que combina as duas caractersticas. A partir da segmentao realizada, decide-se se cada quadrante pode ser uma persona. Pode-se descrever os segmentos criados para cada quadrante. Ento veja se a segmentao passa pelo teste de qualidade da segmentao apresentado no passo de segmentao da pesquisa qualitativa. Se no passar pelo teste, tenta-se uma combinao diferente de comportamento e atitudes em uma nova matriz at resultar em um modelo de segmentao til. No necessrio restringir sua segmentao a duas variveis, entretanto recomenda-se utilizar poucas variveis, sendo de preferncia duas. Quanto mais variveis usar para fazer a segmentao, mais difcil fica entender o grfico montado e lembrar as histrias que se constri com a persona. Lembre-se de que voc no est tentando descobrir um modelo de segmentao correto de forma mgica. Sua misso explorar todas as potenciais abordagens de segmentaes, e pela avaliao de cada uma, determinar qual ser a mais til para a sua situao especfica. PASSO 4: SEGMENTANDO COM CLUSTERIZAO Neste passo, so utilizados algoritmos estatsticos para guiar o processo de segmentao. Coloca-se um conjunto de variveis em uma ferramenta, que procurar ocorrncias de clusters (agrupamentos) baseadas em alguns conjuntos de associao. possvel terminar com um nmero de clusters e um nmero de atributos como diferenciadores chaves entre os clusters. Esse processo um pouco mais complexo e muito influenciado pela maneira como ele executado. significantemente diferente das outras abordagens, porque a segmentao dirigida por dados bem como dirigida por humanos. PASSO 5: DEFININDO PERSONAS Com a anlise da semelhana dos clusters com os segmentos, os dados so transformados em reais atravs dos processos de: adicionar nome, foto, histrias etc. A planilha de dados transformada em informaes reais de pessoas. 72

4.3.3.7 Pesquisa qualitativa com validao quantitativa

uma metodologia de pesquisa que combina aspectos qualitativos e quantitativos para a construo das Personas. PASSO 1: CONDUZINDO A PESQUISA De forma semelhante ao que ocorre na pesquisa qualitativa, so tambm utilizadas entrevistas e questionrios com os usurios, alm de estudos de campo que revelem hipteses sobre os objetivos, comportamentos e atitudes dos usurios. PASSO 2: SEGMENTAO DOS USURIOS A segmentao de usurios, por sua vez, baseada em pesquisa quantitativa (rever Passos 2, 3 e 4 da Pesquisa quantitativa). So preparados alguns tipos de segmentao que resultaro em um nmero de segmentos baseados em objetivos, comportamentos e ou atitudes particulares de usurios. PASSO 3: TESTE DE SEGMENTAO Neste passo, inicialmente, atravs de questionrios ou outra forma de pesquisa qualitativa, testa-se o modelo de segmentao usando um tamanho grande de amostra (para assim verificar se o modelo criado reflete exatamente a realidade). Os dados da pesquisa levantados com os questionrios so melhores para avaliar objetivos e atitudes dos usurios. A anlise dos dados pode ser feita por meio de simples cruzamentos, ou ento utilizar tcnicas de anlise quantitativa mais complexas. Se o objetivo for, por exemplo, testar o modelo de segmentao em funo dos objetivos dos usurios, o questionrio deve conter uma questo do tipo: qual a razo dos usurios visitarem o site?. PASSO 4: NOVO TESTE DE SEGMENTAO Neste passo, sobretudo, preciso observar se existem diferenas significativas no perfil dos usurios que do suporte ao seu planejamento de segmentao. Se sim, ento ele foi um sucesso; caso contrrio, ser preciso tentar outras maneiras de segmentar os usurios e testar a segmentao.

73

PASSO 5: DEFININDO AS PERSONAS A criao das Personas baseada nas anlises dos dados qualitativos. As Personas precisaro ser segmentadas de acordo com alguns fatores. necessrio fazer uma pesquisa para cada usurio do modelo de segmentos. Posteriormente, devem ser analisados os resultados para cada usurio da segmentao, tambm de forma separada. Da em diante sero feitas as atividades para tornar as Personas realsticas, com a escolha de nomes, fotos, informaes demogrficas, cenrios etc (Rever Passo 3 da Pesquisa qualitativa).

4.3.4 DETALHAMENTO DAS ATIVIDADES DO SUBPROCESSO

Esta seo apresenta um detalhamento das atividades de modelagem dos usurios introduzida na seo 4.3. importante notar que diferentes formas ou tcnicas de representao dos papis de usurios podem ser usadas no processo apresentado e que poderia ser necessria uma adaptao da tcnica utilizada para que seja mapeada nas atividades de modelagem em duas etapas (preliminar e detalhada) como sugerimos nas sees 4.3.4.1 e 4.3.4.2 abaixo. Sendo assim, a tcnica de Personas sugerida para a modelagem de papis de usurios na seo 4.3.3 poderia ser mapeada em atividades de modelagem preliminar e detalhada. Claro que, tambm, possvel considerar a atividade de modelagem dos usurios em nosso processo como constituda de uma nica atividade que seria realizada de acordo com a tcnica utilizada. No entanto, a proposta de se fazer a modelagem dos usurios em duas etapas (preliminar e detalhada) normalmente ser uma prtica saudvel j que a atividade de modelagem por natureza iterativa. Um dos aspectos a serem levantados, e que merece um destaque especial, so os modelos mentais que os usurios utilizam na realizao de suas atividades. A descrio dos modelos mentais foi considerada como parte da modelagem dos usurios j que esses modelos so abstraes que os usurios utilizam na realizao de suas atividades. No entanto, como esses modelos esto envolvidos na realizao das atividades dos usurios, o levantamento desses modelos poderia tambm ser considerado como parte da Anlise de tarefas. Realmente, com j mencionamos, h uma grande interdependncia entre os diversos tipos de Anlise de contexto de uso. Sendo assim, normal que um Modelo Mental de um usurio seja identificado na anlise de uma tarefa que este usurio realiza e aceitvel, ou 74

at indicado, que este modelo mental seja caracterizado e mencionado na descrio da tarefa. LEVANTAMENTO DOS MODELOS MENTAIS O Levantamento dos modelos mentais visa descrio dos modelos mentais mais importantes que as pessoas envolvidas (potenciais usurios) utilizam na realizao de suas atividades. A descrio pode ser textual, se necessrio com a utilizao de figuras explicativas. Na realizao de suas atividades no dia a dia, as pessoas criam e utilizam modelos mentais que explicam e ajudam no controle dos objetos com os quais interagem. Por exemplo, quando estamos dirigindo um veculo, utilizamos modelos mentais que nos explicam como acelerar, como frear, como fazer uma curva, etc. Utilizando esses modelos mentais, conseguimos controlar o carro. O modelo mental no necessita ser preciso nem mesmo ser coincidente como o modelo real de como funciona o objeto, basta ser compatvel. Um motorista precisa ter a noo de que quando pressiona o pedal de freio, uma fora, proporcional presso que aplica no pedal, transmitida roda. Mas ele no precisa conhecer o mecanismo real que realiza a frenagem do veculo. A descrio pode ser textual, se necessrio com a utilizao de figuras explicativas. O conceito de modelos mentais foi apresentado na seo 2.5. O levantamento desses modelos pode ser feito durante as atividades de modelagem preliminar e modelagem detalhada dos usurios, descritas a seguir.

4.3.4.1 Modelagem preliminar de usurios

Esta atividade consiste na criao preliminar de um modelo de usurios onde se define quais so os atores que interagiro com o produto e como esses atores se relacionam entre si. As principais atividades realizadas so: identificao de atores a partir dos grupos de usurios levantados; anlise preliminar da forma de trabalho ou do comportamento relacionado com o produto, das pessoas representadas por cada Ator. ordenao e simplificao inicial do modelo de atores com base no relacionamento entre eles. 75

Identificao dos atores focais, com a finalidade de definir quais atores, daqueles que representam a populao alvo, so mais importantes e devem ser considerados com mais ateno no desenvolvimento do sistema. Os atores focais so aqueles considerados particularmente importantes do ponto de vista do negcio da empresa cliente ou de riscos, ou em funo de alguma considerao tcnica.

A Tabela 4-4 apresenta um detalhamento das atividades de modelagem preliminar dos usurios.
Descrio Insumos Modelagem preliminar 1 Especificao de requisitos de Software (ersw) 2 Documentao do planejamento da anlise 3 Lista preliminar de usurios potenciais e respectivas categorias. 4 Informao j levantada no trabalho de campo. 5 Manuais de usurios (de sistemas similares, se existirem, ou do atual, a ser melhorado). Tarefas 1 Identificao dos atores a partir das categorias de usurios levantadas; 2 Realizao do trabalho de campo de observao e consulta s pessoas envolvidas visando modelagem de usurios. 3 Levantamento das caractersticas principais dos atores, identificando: experincia no trabalho, nvel educacional, necessidades de treinamento; idade, sexo e diferenas fsicas que podem ser significantes; localidades geogrficas, cultura e nacionalidades; linguagem usada, terminologias; nvel de trabalho, tais como tcnicos e especialistas; o modo de trabalhar do usurio; 4 Verificao das diferenas relevantes entre as caractersticas levantadas dentro de grupos de usurios. (preliminar). Verifica se as caractersticas similares indicam diferenas significativas que no tinham sido observadas, considerando-se vrias perspectivas, por exemplo, a distribuio esperada de freqncia de utilizao (preliminar) do produto em considerao. 5 Ordenao, simplificao ou generalizao de atores do modelo de usurios com base no relacionamento entre eles (preliminar). 6 Determinao dos atores focais considerando-se: freqncia de uso; os processos de negcio; os riscos associados a custo e utilizao do produto. Obs.: Os critrios mencionados acima podem ser considerados isoladamente ou em conjunto utilizando-se uma metodologia como QFD, por exemplo. Esta ltima abordagem mais precisa, onde se determina a importncia de cada critrio, utilizando-se, por exemplo, o mtodo Analytic Hierarchy Process (AHP) (Cheng &

76

Resultados

Scapin, 1995). O grau de importncia de cada Ator , ento, calculado multiplicando-se o valor de correlao existente entre os critrios com a importncia de cada critrio e somando-se os produtos resultantes. 1 Modelo de Atores Humanos preliminar

Tabela 4-4 Atividades da modelagem preliminar dos usurios

4.3.4.2 Refinamento da modelagem de usurios

Esta atividade visa um refinamento e melhoria do modelo de usurios. Faz-se o detalhamento dos atores, descrevendo suas necessidades, interesses, expectativas e comportamentos e faz-se a identificao dos relacionamentos envolvendo esses atores. Os atores focais devem receber mais ateno no trabalho de desenvolvimento da interao. Neste trabalho de modelagem detalhada, o modelo de usurios pode ser reorganizado com a criao ou extino de atores ou com a redefinio de relacionamentos entre os atores. A organizao e simplificao mais apurada do modelo de usurios so realizadas com base em um trabalho de consulta e validao dos dados levantados.
Descrio Insumos Refinamento da modelagem de usurios 1 Especificao de requisitos de Software (ersw) 2 Documentao do planejamento da anlise 3 Modelagem preliminar de atores humanos. 2 Informao levantada no trabalho de campo. 4 Manuais de usurios (de sistemas similares, se existirem, ou do atual, a ser melhorado). Tarefas 1 Realizao do trabalho de campo de observao e consulta s pessoas envolvidas visando modelagem de usurios. 2 Detalhamento da caracterizao dos atores, principalmente para os atores focais, descrevendo: proficincia: como a proficincia de uso distribuda em certo intervalo de tempo e entre os usurios de um determinado papel; interao: quais so os padres de uso associados com um determinado papel. informao: qual a natureza da informao manipulada pelos usurios em um determinado papel ou o intercmbio entre os usurios e o sistema; critrio de usabilidade: qual a importncia relativa de objetivos de usabilidade especficos em relao a um dado papel; suporte funcional: funes especficas, caractersticas necessrias para usurios em um papel especfico. ou facilidades

risco operacional: tipo e nvel de risco associado com a interao usuriosistema para um Papel-de-usurio especfico; restries de dispositivos: limitaes ou restries de um equipamento atravs

77

do qual um usurio, exercendo um determinado papel, interage com o sistema; fatores relevantes do ambiente de trabalho, incluindo aspectos fsicos, culturais e sociais, no qual um usurio interage com um sistema; como os usurios aplicam o conhecimento e experincia na realizao das tarefas (modelos mentais). 3 Melhoria e concluso da modelagem de papis de usurios validando os relacionamentos previamente levantados ou identificando novos relacionamentos envolvendo os atores. Este trabalho pode levar ao desdobramento de atores considerados complexos em atores mais simples ou fuso ou generalizao de atores com base no relacionamento entre eles e suas caractersticas. 4 Verificao das diferenas relevantes entre as caractersticas levantadas dentro de grupos de usurios. Verifica se as caractersticas similares indicam diferenas significativas que no tinham sido observadas, considerando-se vrias perspectivas, por exemplo, a distribuio esperada de freqncia de utilizao. 5 Ordenao, simplificao ou generalizao de atores do modelo de usurios com base no relacionamento entre eles. Resultados 1 Descrio de Caractersticas de Atores Humanos completa. 2 Modelo de Atores Humanos completo.

Tabela 4-5 Refinamento da modelagem de usurios A Tabela 4-5 apresenta as atividades de refinamento da modelagem de usurios.

4.4 ANLISE DE TAREFAS

A Anlise de tarefas visa caracterizar as tarefas realizadas pelos usurios ou (futuros usurios) em suas atividades relacionadas com o produto em considerao. Note que tarefas aqui tm a conotao de atividades que as pessoas realizam ou vo realizar, podendo ser uma atividade de lazer ou qualquer outro tipo de atividade relacionada com o produto em considerao. Como j mencionamos, a Anlise de tarefas bastante relacionada com a Anlise de usurios; em geral, essas atividades so realizadas em um processo incremental e iterativo, onde a Anlise de tarefas d subsdios para a Anlise de usurios, inclusive sugerindo novos Papis-de-usurios a serem considerados para serem associados ao produto, e vice-versa. Os sistemas de software so criados para apoiar a realizao de tarefas, da a importncia da caracterizao dessas tarefas antes do desenvolvimento de um software. Note que, 78

muitas vezes, um sistema apia apenas parcialmente a realizao de uma tarefa, o restante da tarefa realizado manualmente ou com a ajuda de outros meios. As tarefas a serem realizadas pelo sistema, quando o produto estiver em operao em interao com os usurios, correspondem aos casos de uso. Sendo assim, a Anlise de tarefas importante no s para propiciar o desenvolvimento de uma interface do usurio adequada, como tambm para ajudar na definio e priorizao das funes (casos de uso) que so ou sero providas pelo software em considerao. As outras tarefas realizadas pelos usurios so consideradas fora do escopo do produto em considerao, mas a Anlise de tarefas como um todo constitui informao essencial para o desenvolvimento da interao humano-computador. EXEMPLO PARA MOTIVAO Segue um exemplo interessante que ilustra bem a importncia da Anlise de tarefas no desenvolvimento de um produto de software. Uma empresa fornecedora de gua para a populao resolveu desenvolver um sistema para apoiar a necessidade de leitura de medidores para a produo das contas. A Figura 4-5 a seguir mostra o roteiro que um leiturista segue na realizao de suas medies sem o apoio de um sistema. No seu trabalho, o leiturista percorre a rua uma vez s, fazendo a leitura nas residncias dos dois lados, quando necessrio tocando a campainha (para chamar o dono) de vrias casas ao mesmo tempo.

Figura 4-5 Roteiro normalmente seguido pelo leiturista

79

Um sistema foi desenvolvido para o apoio medio do consumo de gua das residncias. O sistema utiliza uma tecnologia que permite que a conta seja impressa logo aps a leitura, Figura 4-6.

Figura 4-6 Leiturista com equipamento de registro de leituras de conta No entanto, com o objetivo de otimizar a leitura, o sistema impe uma seqncia de domiclios a serem visitados. A prxima figura mostra um roteiro que o leiturista segue na realizao de suas medies conforme exigido pelo sistema de apoio. Observe que o leiturista percorre cada rua nos dois sentidos.

Figura 4-7 Leiturista com equipamento de registro de leituras de conta Apesar de, primeira vista, representar um trajeto otimizado, a experincia dos usurios no foi levada em conta. O resultado foi que a soluo com o apoio do sistema automatizado se mostrou ineficiente na prtica, requerendo muito mais tempo (da ordem do dobro) para a realizao das leituras. O sistema est sendo rejeitado pelos usurios, 80

apesar dos avanos que oferece, por tornar o trajeto mais longo e a execuo da leitura mais demorada.

4.4.1 VISO GERAL

A atividade de Anlise de tarefas prescreve que, inicialmente, realizemos a Anlise de Necessidades. A Anlise de Necessidades pode ser considerada como uma anlise dos interesses e das necessidades das pessoas envolvidas, no estritamente como uma Anlise de tarefas. No entanto, tarefas so realizadas, em ltima anlise, para suprir necessidades dos seres humanos e o entendimento dessas necessidades muito importante para o entendimento das motivaes por trs da realizao de tarefas. A descrio das tarefas dos usurios pode ser feita de diversas formas, cada uma delas correspondendo a um modelo que propicia uma determinada viso da questo. Dentre as diversas formas, devem ser escolhidas aquelas que sejam mais convenientes dadas as caractersticas das tarefas a serem modeladas. Algumas formas de definio de tarefas so listadas abaixo. 1. 2. 3. 4. 5. Fluxo de trabalho Trabalho individual Seqncia de tarefas Hierarquia de tarefas Procedimentos

importante lembrar que o objetivo da Anlise de tarefas o de caracterizar a situao existente antes do desenvolvimento do software. No cabe, na Anlise de tarefas, definirse solues de desenho da interface com o usurio, j que a Anlise Tarefas visa justamente levantar informaes importantes para o posterior desenho da interface. Devemos, no entanto, como resultado do trabalho de Anlise de tarefas, bem como em outras atividades da Anlise de contexto de uso, produzir recomendaes para as atividades subseqentes no desenvolvimento do software, incluindo, com nfase, recomendaes para o desenho da interface com o usurio. Diferentes tcnicas podem ser usadas para a modelagem de tarefas, por exemplo, as formas mais descritivas propostas por Hackos, JT & Redish (Hackos, JT & Redish, 1998) ou modelos mais simples como proposto por Hix e Hartson (Hix, D.; Hartson, H. R., 1993). Aqui, preferimos sugerir a tcnica de Roteiros de Rosson e Carrol (Rosson e Carrol, 2002), 81

apresentada na seo 4.4.3, por ser considerada barata, fcil e, de certa forma, intuitiva e ldica, para a equipe de desenvolvimento de um software. De certa forma, podemos traar um paralelo entre a tcnica de Roteiros usada na descrio de tarefas e a tcnica de Personas usada na modelagem de usurios, no sentido de que ambas se utilizam de narrativas que constituem uma espcie de cenrio ilustrativo da situao, que se utiliza de histrias com um esprito de certa forma ldico.

4.4.2 OBJETIVOS
A Anlise de tarefas visa obteno de conhecimento detalhado das atividades realizadas pelos usurios para que se possa desenvolver uma soluo de interao adequada para o tipo de utilizao que se espera do produto. A Anlise de tarefas de um sistema interativo tem como objetivos especficos: conhecer os interesses, motivaes e necessidades dos usurios relacionados s tarefas que eles realizam que tm relao com o produto em considerao; caracterizar as tarefas em todos os aspectos, como freqncia de realizao, modo de interao envolvendo os usurios, etc, que possam ter importncia para o desenvolvimento da interface do usurio; gerar um modelo (descrio) de tarefas a partir das informaes obtidas; contribuir para a especificao de requisitos e metas de usabilidade, na definio das tarefas para as quais o desempenho dos usurios em sua execuo dever ser medido; fornecer insumos para o desenho da interao, tais como a arquitetura global, a navegao e o contedo da interface, o leiaute e o comportamento (look-and-feel ) dos elementos de interao; fornecer insumos para o planejamento e especificao das avaliaes de usabilidade;

A Anlise de tarefas representa um importante insumo para se conseguir agregar valor ao produto no sentido de torn-lo mais efetivo como ferramenta de apoio ao trabalho ou a outro tipo de atividade realizada pelos usurios. Abaixo so listadas algumas questes mais comuns que se procura investigar na Anlise de tarefas;

82

Que caractersticas das tarefas tm impacto no soluo em termos da interface do usurio?

Quais so os interesses dos usurios que possam estar relacionado com o produto em desenvolvimento?

Quais as necessidades das pessoas envolvidas que podem ser supridas com o apoio do produto em considerao ou que tem impacto na especificao ou na soluo do produto em considerao?

O que os usurios do software iro fazer que tenha relao com o produto que est sendo desenvolvido?

Em que os usurios necessitam do sistema para realizar algo ou alguma tarefa? Como o sistema deve apoiar a realizao das tarefas dos usurios? O que no momento atual no est funcionando ou ineficiente? Como o sistema seria mais efetivo para suportar as atividades do usurio?

4.4.3 ROTEIROS DE DOMNIO DE PROBLEMA

As metodologias de engenharia de usabilidade propem a descrio das tarefas a serem contempladas no produto de uma forma mais ampla do que normalmente utilizado na rea de engenharia de software. Por exemplo, Carrol & Rosson (2002), sugerem a utilizao de roteiros na descrio das funes do produto. A tcnica de Roteiros utiliza-se de histrias que descrevem um cenrio onde a tarefa realizada. No se trata de uma simples descrio de tarefas, mas de uma descrio enriquecida com aspectos relevantes como a caracterizao das pessoas envolvidas, os objetivos da tarefa, as estratgias utilizadas pelas pessoas envolvidas na realizao das tarefas, etc. Estes aspectos constituem informaes importantes usadas no desenvolvimento da interao para o produto em considerao. Os Roteiros so histrias sobre pessoas e suas atividades, descrevendo situaes de interesse onde pessoas realizam suas atividades. Os autores Rosson e Carrol propem dois tipos de roteiro: os Roteiros de domnio de problema, que descrevem essas histrias no contexto de uso antes da introduo do sistema que est sendo desenvolvido, e os

83

Roteiros de desenho da interao, que descrevem histrias no contexto de uso desenhado, isto , mostram a tarefa sendo realizada com o apoio do sistema desenvolvido. A Tabela 4-6 mostra os vrios aspectos que devem ser registrados em um roteiro e o significado desses aspectos.
Aspectos usados no Roteiro Cenrio Detalhes da situao que motivam ou explicam os objetivos, aes, reaes dos atores. Atores Papis de pessoas que interagem com o ambiente do cenrio; eventualmente com suas caractersticas relevantes. Objetivos da tarefa Modelos mentais Aspectos da situao que motivam as aes realizadas pelos atores. Modelos conceituais e atividade mental de que os atores se utilizam para converterem objetivos em comportamentos. Avaliao Atividade mental dos envolvidos que visa interpretar caractersticas da situao. Aes Eventos Comportamento observvel das pessoas. Ocorrncias externas ou internas que podem influenciar a atividade. Podem no ser percebidas pelos atores, mas so importantes para o roteiro. Significado dos aspectos usados no roteiro

Tabela 4-6 Roteiros de domnio do problema O quadro abaixo mostra um exemplo de Roteiro que descreve um cenrio onde um cliente (Jos) de um supermercado deseja comprar um vinho para presentear um amigo e o vendedor (James) do setor de vinhos do supermercado vai apoiar a venda. Observe que os aspectos indicados na Tabela 4-6 Roteiros de domnio do problema podem ser identificados no quadro apresentado. Por exemplo, o trecho do roteiro:

84

James, um vendedor especializado em vinhos, trabalha no setor de vinhos de um supermercado sofisticado. Jos, um cliente, deseja comprar uma garrafa de vinho para presentear um amigo. Jos est indeciso sobre o que comprar, deseja otimizar a relao custo-benefcio

apresenta o cenrio onde a tarefa executada, introduz os atores James e Jos, e indica que o objetivo do cliente, Jos, seria otimizar a relao custo-benefcio.

James, um vendedor especializado em vinhos, trabalha no setor de vinhos de um supermercado sofisticado. Jos, um cliente, deseja comprar uma garrafa de vinho para presentear um amigo. Jos est indeciso sobre o que comprar, deseja otimizar a relao custo-benefcio. Jos tem em mente um presente na faixa de R$ 50,00 mas se sente constrangido em revelar este valor para o vendedor. James est posicionado discretamente, pronto para ajudar o cliente se solicitado. Eventualmente , Jos solicita ajuda ao vendedor na escolha do vinho. James, pergunta sobre o gosto do amigo de Jos. Com habilidade, procura conhecer mais detalhes do perfil de vinho desejado pelo cliente, principalmente a faixa de preos que o cliente se dispe a gastar. James sabe que, muitas vezes, o cliente se sente constrangido em deixar transparecer que entende muito pouco (quase nada) de vinhos. James comenta sobre as vrias opes de tipos de vinho, de acordo com o perfil desejado pelo cliente. Em particular, se existir, enfatiza as ofertas de produtos que se encaixem no perfil de vinho desejado pelo cliente, visando oferecer um bom servio.

De repente, outro cliente pede ajuda ao vendedor. James pede desculpas ao novo cliente mas solicita que aguarde um momento pois est atendendo outro cliente. James no quer ser indelicado com seu outro cliente Jos.

Os aspectos registrados no Roteiro podem ser teis no posterior desenho da interao de um software que seria desenvolvida para realizar ou apoiar a venda de vinhos no supermercado. Por exemplo, o Cenrio indica que o cliente deseja otimizar a relao

custo-benefcio. Isso significa que fazer uma compra com baixo custo e ao mesmo tempo
com qualidade do produto adquirido representa valor para o cliente. Se o cliente est preocupado com a economia em sua compra, isso deve ser respeitado na soluo de 85

interface a ser desenvolvida no software, caso contrrio o software poder ser rejeitado ou no interessar ao usurio. Como veremos adiante, um software tende a ter sucesso quando ajuda os usurios a atingir seus interesses e objetivos e fracassam quando tornam os interesses dos usurios mais difceis ou impossveis de serem atingidos. Portanto, essa informao sugere que o software a ser desenvolvido deve prover mecanismos, como busca de produtos ordenados por preo, por exemplo, que permitam ao usurio (cliente do supermercado) fazer suas compras com economia. O ultimo pargrafo ilustra a ocorrncia de um evento que pode influenciar a execuo da tarefa:

De repente, outro cliente pede ajuda ao vendedor. James pede desculpas ao novo cliente, mas solicita que aguarde um momento, pois est atendendo outro cliente. James no quer ser indelicado com seu cliente Jos.
Observe que se o software a ser desenvolvido for um stio Web para venda do supermercado, um supermercado virtual, felizmente, isso no seria um motivo de preocupao, j que provavelmente no haveria como um usurio ser interrompido em sua compra por outro cliente. No entanto, se imaginarmos a soluo informatizada na forma de um quiosque eletrnico onde o usurio realiza sua compra, a figura do cliente maleducado seria uma preocupao j que um cliente mal-educado poderia querer interromper uma cliente que estivesse usando o terminal no quiosque! Para ficarem mais simples e atrativos, Roteiros descrevem uma situao especfica, uma instncia, dentre outras, possveis na realizao de uma tarefa. At, possivelmente, a est a razo do uso do termo Roteiro pelos idealizadores da tcnica. No entanto, roteiros podem e devem ser complementados com uma anlise de possveis variaes no modo com a tarefa descrita pode ser realizada. Possveis variaes relacionadas aos roteiros devem ser identificadas e analisadas seus prs e contras. Por exemplo, no roteiro mostrado acima, poderamos considerar a situao em que seriam utilizados vdeos sobre vinhos para apoiar as vendas. Isso teria a favor o fato de facilitar a divulgao dos principais produtos (vinhos) a serem oferecidos aos clientes e atrair consumidores. No entanto, teria o lado desfavorvel de distrair o cliente. Prs e contras devem ser considerados.

86

4.4.4 DETALHAMENTO DAS ATIVIDADES DO SUBPROCESSO DE ANLISE DE TAREFAS

Esta seo apresenta um detalhamento das atividades de modelagem dos usurios introduzida na seo 4.4. importante notar que diferentes formas ou tcnicas de representao de tarefas podem ser usadas no processo apresentado e que poderia ser necessria uma adaptao da tcnica utilizada para que seja mapeada nas atividades de modelagem em duas etapas (preliminar e detalhada) como sugerimos nas sees 4.3.4.1 e 4.3.4.2 abaixo. A tcnica de Roteiros foi aqui sugerida com destaque para a modelagem de tarefas, mas outras formas de descrio podem tambm ser usadas e uma ou outra forma pode ser mais indicada dependendo do tipo de tarefa que queremos descrever. Claro que, tambm, possvel considerar a atividade de modelagem de tarefas em nosso processo como constituda de uma nica atividade que seria realizada de acordo com a tcnica utilizada. No entanto, a proposta de se fazer a Anlise de tarefas em duas etapas (preliminar e detalhada) normalmente ser uma prtica saudvel j que a atividade de modelagem por natureza iterativa. Cabe, ainda, considerar que na documentao da Anlise de tarefas podemos usar vrios tipos de notao. Podemos usar desde uma notao informal que pode ser simplesmente no forma de texto, podemos usar notaes informais com diagramas ou na forma de algoritmos informais, ou at podemos utilizar diagramas UML. Se desejado, se julgado apropriado, podemos usar diagramas UML de atividades, de estado ou mesmo diagramas de interao para a descrio mais formal de uma tarefa.

4.4.4.1 Modelagem preliminar de tarefas

Esta atividade consiste na criao preliminar de um modelo de tarefas onde se define quais so as principais tarefas a serem modeladas. Essas tarefas so aquelas realizadas pelos usurios no ambiente onde realizam suas atividades. Normalmente, as principais tarefas so as relacionadas com os principais usurios do produto em considerao. As principais atividades realizadas so: identificao de tarefas a serem analisadas; anlise preliminar do modo como as tarefas so executadas e suas caractersticas principais tendo em perspectiva o software em considerao; 87

priorizao das tarefas, identificando aquelas que devem ser analisadas em mais detalhes e simplificao do modelo de tarefas.

A Tabela 4-7 apresenta um detalhamento das atividades de modelagem preliminar de tarefas.

Descrio Insumos Modelagem preliminar 1 Especificao de requisitos de Software (ERSw) 2 Documentao do planejamento da anlise 3 Lista preliminar de usurios potenciais e respectivas categorias. 4 Informao j levantada no trabalho de campo. 5 Manuais ou outras formas de documentao de procedimentos ou processos usados na organizao contratante (se existirem). Tarefas 1 Realizao do trabalho de campo de observao e consulta s pessoas envolvidas visando modelagem de tarefas. 2 Identificao das tarefas a serem analisadas a partir de reunies com pessoas envolvidas ou de consulta documentao existente. 3 Levantamento das caractersticas principais das tarefas, identificando: Aspectos como cenrio, objetivo, atores envolvidos, planos, modelos mentais e avaliaes que as pessoas envolvidas utilizam na realizao das tarefas. Freqncia de realizao. Fluxo de comunicao na interao em que os usurios realizam as tarefas. Aspectos ligados localidade geogrfica, cultura e nacionalidade dos atores envolvidos se forem relevantes. 4 Verificao das diferenas relevantes entre as caractersticas de tarefas j levantadas (preliminar). Verifica se as caractersticas similares indicam diferenas significativas que no tinham sido observadas, considerando-se vrias perspectivas, por exemplo, a distribuio esperada de freqncia de realizao das tarefas. 5 Ordenao, simplificao ou generalizao relacionamento entre elas (preliminar). Resultados 3 Modelo de Tarefas preliminar das tarefas com base no

Tabela 4-7 Atividades da modelagem preliminar de tarefas

4.4.4.2 Refinamento da modelagem de tarefas

Esta atividade visa o refinamento e melhoria do modelo de tarefas. Faz-se o detalhamento das tarefas consideradas mais relevantes. Essas tarefas so candidatas a serem automatizadas no sistema a ser desenvolvido, portanto, so essas tarefas ou parte delas que daro origem aos casos de uso do sistema em perspectiva. Vrias formas de descrio 88

podem ser utilizadas para cada tarefa, dependendo do enfoque que se quer dar a descrio. Por exemplo, quando se quer enfatizar a interao entre os usurios na realizao de uma tarefa, pode-se usar uma descrio da tarefa na forma de fluxo de trabalho. s vezes, pode tambm ser interessante descrever as tarefas realizadas por um ator, isto , dar nfase descrio do conjunto de atividades realizadas por um ator considerado importante. As descries das tarefas so registradas diretamente no documento ERUSw. As tarefas consideradas mais crticas, muitas vezes aquelas realizadas pelos atores focais, devem receber mais ateno no trabalho de desenvolvimento da interao. Neste trabalho de modelagem detalhada, o modelo de tarefas pode ser reorganizado com a criao ou extino de tarefas. A modelagem de atores tambm pode ser revista. A organizao e simplificao mais apurada do modelo de tarefas so realizadas com base em um trabalho de consulta e validao dos dados levantados. A Tabela 4-8 apresenta as atividades de refinamento da modelagem de tarefas.

Descrio Insumos

Refinamento da modelagem de tarefas 1 Especificao de requisitos de Software (ERSw) 2 Documentao do planejamento da anlise 3 Modelagem preliminar de atores humanos. 4 Informao levantada no trabalho de campo. 4 Manuais ou outras formas de documentao de procedimentos ou processos usados na organizao contratante (se existirem).

Tarefas

1 Realizao do trabalho de campo de observao e consulta s pessoas envolvidas visando modelagem de tarefas. 2 Detalhamento das caractersticas principais das tarefas, identificando: Aspectos como cenrio, objetivo, atores envolvidos, planos, modelos mentais e avaliaes que as pessoas envolvidas utilizam na realizao das tarefas. Freqncia de realizao. Fluxo de comunicao na interao em que os usurios realizam as tarefas. Aspectos ligados localidade geogrfica, cultura e nacionalidade dos atores envolvidos se forem relevantes. 3 Melhoria e concluso da modelagem de tarefas validando as descries e considerando os relacionamentos entre tarefas. Este trabalho pode levar ao desdobramento de tarefas considerados complexas em tarefas mais simples ou fuso ou generalizao de tarefas com base no relacionamento entre elas e suas

89

caractersticas. 4 Verificao das diferenas relevantes entre as caractersticas levantadas das tarefas. Verifica se as caractersticas similares indicam diferenas significativas que no tinham sido observadas, considerando-se vrias perspectivas, por exemplo, a distribuio esperada de freqncia de realizao. Resultados 1 Modelo de Tarefas completo e documentado no ERUsw.

Tabela 4-8 Refinamento da modelagem de tarefas

4.4.5 ANLISE DE NECESSIDADES

A Anlise de tarefas deve comear pela Anlise de Necessidades j que necessidades constituem motivao para a realizao de tarefas. A Anlise de Necessidades visa estabelecer o que se deseja do sistema baseado na organizao cliente, necessidades de mercado, objetivo dos usurios ou de qualquer outro interessado no sistema. O objetivo da anlise de necessidades resumido a seguir. Caracterizar em um ou mais nveis de abstrao, as necessidades ou interesses dos envolvidos que se espera serem supridas, ainda que parcialmente, pelo produto em desenvolvimento. Caracterizar e priorizar os benefcios que seriam conseguidos por meio da satisfao das necessidades atravs do produto. Fazer a correlao entre benefcios e necessidades, de modo que, no passo seguinte, se possa tambm fazer uma correlao entre benefcios e tarefas para se priorizar as tarefas a serem realizadas pelo sistema. Cabe observar que as necessidades sero supridas atravs de tarefas que podem ser realizadas de maneira automtica pelo sistema software/hardware ou de maneira manual (ou sem a utilizao do sistema) pelos usurios. Na Anlise de Necessidades importante considerar tambm os interesses de todos os envolvidos em relao ao sistema. Produtos tm sucesso quando ajudam os usurios a atingir seus interesses e objetivos e fracassam quando tornam os interesses dos usurios mais difceis ou impossveis de serem atingidos.

90

Segue um exemplo que ilustra a questo de interesses conflitantes e a importncia desses interesses serem considerados na Anlise de Necessidades. Consideremos um sistema, a ser desenvolvido, de apontamento de horas de trabalho de empregados relacionadas com a realizao de tarefas. Quais os interesses da empresa e do empregado relacionados a este sistema? H interesses explcitos, mas interesses no declarados tambm podem ser to ou mais importantes que os interesses explicitados pelas pessoas. Os interesses de uma empresa contratante do desenvolvimento do software poderiam, talvez, ser resumidos como se segue. Evitar problemas com auditores Aumentar lucros Obter o mximo dos empregados Obter melhores dados para futuros planejamentos Melhorar a organizao da empresa

J os interesses dos empregados da empresa, usurios do sistema a ser desenvolvido, poderiam ser os seguintes. Manter seu emprego Fazer seu trabalho para ir embora para casa na hora certa Fazer o patro feliz para ser promovido No se esquecer de anotar horas trabalhadas para evitar desconto de pagamento.

Se o software frustrar os interesses dos usurios eles podem no usar o produto como se esperava. No exemplo, se for difcil para o usurio anotar uma tarefa no usual, ele pode simplesmente lanar qualquer cdigo que o sistema aceite. Os usurios tambm no ficaro nem um pouco satisfeitos se se esquecerem de fazer um apontamento de horas trabalhadas em um dia e no puder fazer as devidas correes no dia seguinte, especialmente se isso significar desconto em seu pagamento! Observe que muitos desses aspectos no seriam revelados explicitamente pelos envolvidos. No entanto, essas questes so relevantes e podem ser, s vezes, identificadas nas observaes, entrevistas e outras formas de contato com as pessoas envolvidas.

91

Podemos concluir que produtos de sucesso so desenhados para atingir os interesses e objetivos de todos os envolvidos: usurios, empresa, investidores, pais, filhos, etc dependendo da situao. Interesses representam valores para os usurios e, portanto, devem ser respeitados e considerados. A Anlise de Necessidades deve comear por um levantamento de necessidades, considerando-se os interesses e objetivos, dos diversos envolvidos com o sistema em perspectiva. Definem-se tambm os principais conceitos envolvidos na descrio das necessidades. importante tambm levantar os benficos, para os envolvidos, que o software poder acarretar na medida em que este contribua para que as necessidades levantadas sejam supridas. O resultado da Anlise de Necessidades uma viso externa do que o usurio ser capaz de fazer e ganhar com o sistema. O modelo resultante da Anlise de Necessidades pode ser descrito primeiramente na forma de um texto analisando os aspectos mais importantes, como os interesses e objetivos das partes envolvidas. Em seguida, podem ser usadas uma tabela de Necessidades e uma tabela de Benefcios para substanciar a Anlise de Necessidades. Na redao de interesses e objetivos preciso ter cuidado j que estes podem constituir assuntos sensveis para as pessoas envolvidas. necessria uma ateno forma de se colocar as coisas, possivelmente at omitindo aspectos que possam ser comprometedores para as partes envolvidas. Na tabela de Necessidades, as necessidades podem ser desdobradas em subnecessidades em colunas separadas, criando-se uma hierarquia de necessidades e subnecessidades. Isso geralmente feito em dois ou trs nveis. De forma semelhante, a tabela de Benefcios tambm deve apresentar uma hierarquia de benefcios e subbenefcios desdobrados. interessante fazermos tambm a priorizao de benefcios e necessidades e uma correlao entre necessidades e benefcios. A priorizao de benefcios costuma ser mais fcil do que a priorizao de necessidades. Por isso, devemos comear por pela priorizao de benefcios, que deve ser feita com a participao de clientes, usurios e demais envolvidos. A correlao entre necessidades e benefcios visa determinar quais necessidades, uma vez atendidas no software em considerao, contribuem para quais benefcios. Esta correlao ajuda na priorizao das necessidades, j que, normalmente, as necessidades mais importantes so aquelas que mais fortemente contribuem para a 92

obteno dos benefcios. Sendo assim, recomendvel realizarmos, na sequncia, a priorizao dos benefcios, a correlao entre necessidades e benefcios, e a priorizao das necessidades a serem contempladas no produto em perspectiva.

4.5 ANLISE DE AMBIENTE

As pessoas no trabalham ou exercem suas atividades isoladas do meio ambiente. O ambiente de realizao das atividades pode ter muita influncia na utilizao do software e a incompatibilidade do ambiente com o software pode at resultar na rejeio do produto pelo usurio. A Anlise de Ambiente visa uma caracterizao do ambiente onde os usurios, ou potenciais usurios, realizam suas atividades relacionadas com o produto em considerao. A anlise do ambiente de realizao das atividades compreende trs aspectos, apresentados a seguir. Ambiente fsico Ambiente social Ambiente cultural

O ambiente fsico compreende os espaos onde os usurios realizam suas atividades. A anlise de ambiente fsico aborda aspectos como os listados a seguir. Esses aspectos so importantes e nos interessam na medida em que tm impacto na utilizao do software em considerao. Meio ambiente Por exemplo, poeira, leo, ou qualquer elemento nocivo que dificulte o uso do equipamento. A temperatura, umidade, ou outro fator relacionado com o clima pode afetar o trabalho do usurio. O nvel de rudos pode perturbar a concentrao do usurio A iluminao pode colocar obstculos utilizao de certos dispositivos de interface. Espao de trabalho 93

Por exemplo, pode ser difcil utilizar-se o mouse no atendimento ao pblico. Pode haver dificuldade das pessoas em oper-lo ou mesmo deve ser considerada a possibilidade de ocorrncia de furtos em ambientes pblicos.

Disponibilidade de equipamento Pode ser relevante considerar, por exemplo, se o usurio tem seu prprio equipamento ou pode necessitar tom-lo emprestado.

Disponibilidade de energia eltrica A energia eltrica disponvel de maneira adequada aos usurios?

Mas no s o ambiente fsico que precisa ser considerado. Muitas vezes, dependendo do tipo de produto a ser desenvolvido, o ambiente social e cultural precisa tambm ser considerado. O ambiente social est relacionado, por exemplo, a presses por produtividade, por preciso ou qualquer outro fator que possa influenciar na utilizao do software a ser desenvolvido. O modo como as pessoas interagem entre si, ou a separao geogrfica das pessoas tambm so exemplos de fatores sociais que podem ser relevantes para a utilizao do produto. Por exemplo, os seguintes fatores devem ser considerados. Usurio trabalha sob presso por produo, rapidez, preciso ou qualquer fator que possa afetar a utilizao do produto? Recursos disponveis para ajudar o usurio. Existem manuais ou pessoas por perto a quem possam recorrer? As pessoas com as quais interagem ficam em local prximo? A separao geogrfica afeta o trabalho? Como os usurios se comunicam? Os usurios utilizam Fax, e-mail, telefone, etc em sua comunicao? Esses hbitos so importantes, por exemplo, na definio de um mecanismo de comunicao a ser utilizado no software a ser desenvolvido. Como o ambiente fsico interfere no ambiente social? As pessoas trabalham em casa? As pessoas trabalham em cubculos ou em ambientes compartilhados? Um espao de trabalho com alta concentrao de pessoas pode dificultar a comunicao entre elas. Por outro lado, a presena de companheiros de trabalho pode favorecer as atividades das pessoas envolvidas.

94

Como a relao entre os usurios e seus clientes? Como se comunicam? H tenso na relao? H necessidade de respostas em tempos estritos?

O desempenho do usurio ou precisaria ser monitorado? Quais as conseqncias isso em relao aos interesses das pessoas envolvidas?

O ambiente cultural est relacionado a aspectos de cultura regional ou de grupos scioeconmicos que tambm podem ser relevantes. Seguem alguns exemplos de fatores a serem considerados. A cultura do pas ou regio influencia no trabalho do usurio? Os usurios trabalham em locais com diferenas culturais significativas? O grupo socioeconmico a que pertencem precisa ser considerado? Os usurios pertencem a uma cultura profissional que determine valores, estilos de trabalho ou comportamentos que necessitem ser considerados? Isso tem implicaes quanto ao estilo de uso, ajuda e documentao, por exemplo? E quanto s expectativas de tempo de resposta do sistema? Este aspecto pode ser muito importante porque determina a expectativa (ou tolerncia) dos usurios em relao aos tempos de respostas dos sistemas com o quais ir interagir. Como j mencionamos, o ambiente de realizao das atividades pode ser considerado como parte da Anlise de tarefas assim como parte da Anlise de usurios. A deciso sobre e melhor forma de se modelar o ambiente deve ser baseada no fato do ambiente estar mais associado s pessoas ou s atividades que elas realizam. Por exemplo, o risco de um ambiente exposto radioatividade pode estar associado tarefa de se tirar radiografias, para qualquer que seja o usurio envolvido nesta tarefa. J o aspecto da presso social por no se cometer erro pode ser modelado como associado ao usurio mdico, independente das tarefas que ele realiza. No documento erusw a anlise de Ambiente pode ser documentada junto com a Modelagem dos usurios ou com a Modelagem de Tarefas.

95

4.6 ANLISE DE PRODUTOS CONCORRENTES OU SIMILARES

A Anlise de Produtos Concorrentes ou Similares visa o estudo de produtos semelhantes ao produto em considerao com o objetivo de: coleta de informaes para que se possa melhorar o produto em considerao a partir do conhecimento das fraquezas e pontos fortes de produtos concorrentes ou similares. familiarizao com o domnio do problema; estudo de caractersticas de produtos similares tendo em perspectiva o software a ser desenvolvido ou analisado (produto em considerao); identificao de oportunidades que possam diferenciar o produto; utilizao do produto similar para se promover avaliaes de aspectos especficos quando essas caractersticas no esto ainda disponveis em um produto em desenvolvimento ou mesmo quando se considera estender o produto em considerao com essas caractersticas; obter-se a viso de um produto semelhante j implementado - pode dar uma viso mais realista do que a permitida por prottipos. No se trata, obviamente, de cpia ou violao de direitos de propriedade, mas de se conhecer os possveis concorrentes ou produtos similares ao que est sendo desenvolvido com o objetivo de identificar oportunidades de diferenciais, identificar limitaes ou mesmo utilizar como uma referncia para comparaes. A Anlise de Produtos Concorrentes ou Similares pode ser realizada por meio de avaliaes de usabilidade de maneira mais formalizada ou de forma simplificada, como tambm pode ser complementada com anlises disponveis em revistas ou outros meios que podem dar subsdios valiosos para o desenvolvimento de um sistema. Quando possvel, a anlise de vrios produtos concorrentes permite uma avaliao comparativa bem interessante. A anlise de produtos semelhantes, funcionando com se fosse um prottipo, tambm pode viabilizar a comparao de diversas abordagens para questes de interao que interessam aos desenvolvedores. Pode ser proveitosa, tambm, a anlise de produtos concorrentes com outros tipos de interface. Por exemplo, na anlise de um livro eletrnico pode ser interessante analisar-se como os usurios utilizam uma enciclopdia em papel. 96

O Praxis-u prescreve que a Anlise de Produtos Concorrentes ou similares seja registrada no documento erusw.

4.7 GLOSSRIO
JAD Joint Application Development JAD ou Joint Application Design uma metodologia criada pela IBM do Canad em 1977 e adaptada para o Brasil em 1982 para moderao de discusses de brainstorming acelerando e consolidando o desenvolvimento de aplicaes de Sistemas de Informao. JAD uma metodologia que acelera o projeto de sistemas. Guiados por um lder de reunio, usurios e analistas projetam o sistema juntos, em sesses de grupo estruturadas. JAD utiliza a criatividade e o trabalho em equipe de dinmica de grupo para definir o ponto de vista dos usurios sobre o sistema, desde os objetivos e aplicaes do sistema at a gerao de telas e projetos de relatrios. A aplicao JAD permite a criao, em menos tempo, de sistemas mais eficazes (Wikipedia, n.d.).

4.8 BIBLIOGRAFIA
Chapman, C.N. & Milham, R. The personas' new clothes. Human Factors and Ergonomics Society (HFES) 2006, San Francisco, CA. October 2006. Cheng, L., Scapin, C. A. at al. QFD: Planejamento da Qualidade. Escola de Engenharia da

UFMG. Fundao Cristiano Ottoni, Belo Horizonte, MG, 1995.

Constantine, L.L. & Lockwood, L.A.D. Software for Use: a Practical Guide to the Models and Methods of Usage Centered Design, Addison-Wesley, Reading-MA, 1999 Cooper, A. The Inmates are Running the Asylum: Why High Tech Products Drive Us Crazy

and How To Restore the Sanity. Macmillan Publishing Co., 2000.

Cooper, M. Evaluating accessibility and usability of web pages. In Proceedings of 2nd Int. Conference on Computer-Aided Design of User Interfaces, Kluwer Academics, 33-42, 1999. Cooper, A. e Reimann, R. About face 2.0: The essentials of interaction design. Information Visualization. 2004 97

Grudin, J. and Pruitt, J. Personas, participatory design and product development: an

infrastructure for engagement. Paper presented at Participatory Design Conference 2002,

Malmo, Sweden. June 2002. Hackos, JT & Redish, JC, User and Task Analysis for Interface Design, John Wiley &Sons 1998 Hix, D.; Hartson, H. R. Developing User Interfaces: ensuring usability through product &

process, John Wiley and Sons, 1993.

Mulder, S. and Yaar, Z. The user is Always Right: A practical Guide to Creating and Using

Personas for the Web. New Riders Publishing Thousand Oaks, CA, USA, 2006.
Rosson, M. B., Carrol, J.M. Usability Engineering:

Scenario Development of Human-

computer Interaction. Morgan kaufmann Publishers, 2002.

Wikipedia, em http://pt.wikipedia.org/wiki/ acessado em 10/2009

5 ESPECIFICAO DE REQUISITOS DE USABILIDADE

5.1 VISO GERAL

A especificao de requisitos usada na Engenharia de Software para definir as condies que um produto de software deve satisfazer para ser aceito e considerado com um nvel aceitvel de qualidade De forma semelhante, a Especificao de Requisitos de Usabilidade uma atividade de processo que tem como objetivo a definio de metas verificveis, geralmente quantitativas, de desempenho que so usadas como referncia para avaliarmos a qualidade da interface do usurio. A ISO 13407 Human-centred design processes for interactive systems uma norma internacional que define processos de usabilidade. Um diagrama de processos, em alto nvel de abstrao, prescritos pela norma ISO 13407 mostrado na Figura 5-1. Podemos observar que, em linhas gerais, o processo de usabilidade previsto pela norma ISSO 13407 constitudo por uma atividade de planejamento e um ciclo onde so realizadas as atividades de: 98

Anlise de contexto de uso (que a Norma define como Especifica o contexto de uso); especificao de requisitos de usabilidade; desenho da interao; avaliao do desenho.

Observe que a norma ISO 13407 sugere um ciclo onde, em uma viso bem simplificada, o contexto analisado, desenhos (podem ser prottipos) so produzidos e a interface avaliada at que seja considerada satisfatria. A especificao de requisitos de usabilidade, ento, serve como uma referncia para avaliarmos se a interface apresenta um nvel satisfatrio de qualidade em termos de usabilidade.
ad ISO 13407 Planej a o processo de usabilidade Especifica o contexto de uso

OK?

Av alia desenho confrontando com requisitos

Especifica os requisitos dos usurios e da organizao

Produz solues de desenho

Figura 5-1 Processos de usabilidade definido pela norma ISO 13407

As metas de desempenho estabelecidas na Especificao de Requisitos de Usabilidade so nveis de desempenho que desejamos que os usurios pudessem atingir ao interagir com o sistema. A Especificao de requisitos de usabilidade, que para simplificar usaremos tambm a expresso Especificao de Usabilidade poder, assim, ser usada como uma indicao de quando o projeto de desenvolvimento est convergindo em direo a uma interface com sucesso. Com o estabelecimento da Especificao de Usabilidade o mais cedo possvel no processo de desenvolvimento, e monitorando-as a cada iterao, pode-se determinar quando a interface est, de fato, indo em direo a melhorias.

99

A realizao de medidas essencial para termos controle de um processo e em Usabilidade isso no diferente. a realizao de medidas que nos permite deixar especulaes, o chamado achismo, para termos processos mais maduros e profissionais. A importncia da realizao de medidas pode ser apreciada na citao dos autores Good, M. e outros (Good, M. et al, 1986): Engenharia de Usabilidade um processo atravs do qual as caractersticas de usabilidade so especificadas, antecipadamente e de forma quantitativa no processo de desenvolvimento, e medidas durante todo o processo . Sem especificaes mensurveis, impossvel determinar metas de usabilidade e dizer se o produto final alcana essas metas. No fundo, se no conseguimos realizar medidas em uma atividade, provavelmente no conseguiremos gerenci-la adequadamente (claro, falando de atividades complexas como o desenvolvimento de software).

5.2 TABELA DE ESPECIFICAO DE REQUISITOS DE USABILIDADE

O conceito de especificao formal de requisito em formato de tabela foi desenvolvido por Gilb (Gilb, 1981). Gilb prope a utilizao de uma tabela, que chamaremos de ERU, para a especificao de requisitos de usabilidade. A Tabela ERU uma das principais fontes para o planejamento das avaliaes com os usurios. Deve ser utilizada tanto para avaliaes formativas, aquelas realizadas durante o desenvolvimento do software, quanto somativas, ou seja, avaliaes de produtos j existentes.

100

Req Ordem Identificador uisit o ou met a? 1 RU01 R

Atributo de usabilidade Ator Instrumento de medida Valor a ser medido

Nveis de desempenho Pior Atual aceit vel Todos Acrescente o compromisso... - benchmark 1 Tempo de execuo na primeira tentativa 15s 30 s Melhor Possivel 20s 10s

Alv o

Desempenho inicial

RU02

Desempenho inicial

Todos

Apague o compromisso... benchmark 2

Nmero de erros na primeira tentativa

0 erro

3 erros

1 erro

0 erro

RU03

Satisfao - inicial

Secretari a

Questionrio: questes...

Mdia das avaliaes

??

7,0

9,5

8,5

4 5

RU04 RU06

M R

Tabela 5-1 Tabela ERU A Tabela Tabela 5-1 mostra um excerto de uma Tabela ERU ilustrando os requisitos de usabilidade para o exemplo apresentado no livro de Hix e Hartson, (Hix, D.; Hartson, 1993). Neste exemplo, os autores propem o desenvolvimento da interface de uma agenda eletrnica que substituiria as agendas de papel, alis, muito usadas pela praticidade. A seguir, apresentamos os elementos que constituem a Tabela ERU, com o significado das colunas, utilizando o exemplo da agenda eletrnica para ilustrao. As trs primeiras colunas so: ORDEM: esta coluna utilizada para numerao das linhas da tabela. IDENTIFICADOR: a coluna identificador utilizada para associar um identificador a cada item (ou linha) da tabela. Isso pode ser til para se fazer uma referncia a um item, podendo inclusive, em uma implementao mais sofisticada, ser usado como um ndice em uma tabela de banco de dados. REQUISITO OU META? Esta coluna usada para definir se o elemento apresentado em uma linha especfica da Tabela se trata de um requisito ou de uma meta de usabilidade. Os dois conceitos so semelhantes, a diferena que consideramos como 101

requisito se este for estabelecido pelo contratante do projeto e meta se o requisito for definido pela equipe desenvolvedora do software em considerao. Em essncia, a diferena que o requisito de usabilidade seria considerado uma condio para aceitao do produto enquanto a meta seria uma referncia utilizada para a equipe desenvolvedora para avaliar a qualidade da interface Os demais elementos da Tabela ERU sero apresentados nas sees seguintes.

5.2.1 ATRIBUTOS DE USABILIDADE

Atributo de usabilidade a caracterstica geral de Usabilidade a ser usada como critrio para avaliao da interface. Esse elemento essencial j que corresponde a parmetros usados para se medir a usabilidade de uma verso da interface. Como atributo, pode-se usar os cinco principais definidos por Nielsen (Nielsen, 1993) ou outros relevantes. s vezes interessante estabelecer condies em que um atributo avaliado. Por exemplo, podemos definir Desempenho inicial quando importante medir o desempenho de um usurio que nunca usou ou que iniciante no uso do software em considerao ou Desempenho em longo prazo quando for interessante avaliar o desempenho de um usurio que j tenha experincia no uso de um sistema. Para uma tarefa complexa, pode ser interessante estabelecer diferentes atributos, por exemplo, aprendizado e desempenho em longo prazo. SUGESTES DE ATRIBUTOS Seguem sugestes de atributos interessantes que podem ser utilizados na Tabela ERU Desempenho inicial: refere-se ao desempenho do usurio que est iniciando-se e no tem experincia no uso do sistema. Desempenho em longo prazo: refere-se ao desempenho do usurio em uso mais regular do sistema durante um longo perodo. muito utilizado quando a tarefa a ser avaliada (descrita em Instrumento de medida na tabela) uma tarefa realizada no dia a dia no ambiente de trabalho das pessoas.

102

Facilidade de Aprendizagem: facilidade ou rapidez com que o usurio aprende a lidar com o sistema.

Reteno a capacidade de o usurio que usou um software e ficou um perodo de tempo sem utiliz-lo, de reter na memria o que aprendeu para que consiga utiliz-lo novamente no futuro.

Uso de caractersticas (features) avanadas utilizado para determinar a usabilidade de funes complexas da interface.

Satisfao inicial: ou primeira impresso, a avaliao que o usurio que est iniciando-se e no tem experincia no uso do software faz de sua utilizao.

Satisfao em longo prazo: a avaliao do usurio que tem experincia na utilizao do sistema.

Preveno de erros: a capacidade do sistema de prevenir erros dos usurios em sua utilizao.

Acurcia a capacidade do software de oferecer resultados na preciso desejada pelo usurio.

confiabilidade, clareza, etc so exemplos de outros atributos que podem ser interessantes para determinados produtos de software.

5.2.2 ATOR
Na escolha dos atributos devemos considerar os diversos perfis de atores para os quais desejamos determinar o desempenho como prescrito na especificao de requisitos de usabilidade. Pode ser interessante utilizar-se atributos associados a papis de usurios especficos, para isso pode ser utilizada a coluna identificada como Ator na Tabela ERU. Normalmente, os papis de usurio focais que sero de maior interesse para se ter seu desempenho medido (listado na Tabela ERU), mas, claro, qualquer ator pode ser considerado relevante o suficiente para ter o seu desempenho, na utilizao do software em considerao, medido.

103

Em geral no vivel estabelecer metas para todas as classes de usurios ou tarefas possveis. Especula-se que aproximadamente 80% dos usurios usam somente 20% das funcionalidades de um sistema interativo. Sendo assim, as tarefas mais importantes ou crticas, para os atores mais importantes, que sero objeto da especificao de requisitos.

5.2.3 INSTRUMENTO DE MEDIDA

O Instrumento de medida descreve o mecanismo utilizado para se obter valores de um atributo particular de usabilidade. Deve ser quantitativo, isto , poder ser medido numericamente. No entanto, a medida pode ser objetiva ou subjetiva. A medida objetiva se refere s medidas quantitativas do desempenho observvel do usurio durante a realizao de tarefas usando a interface e a medida subjetiva quando baseada em opinies de usurios sobre a interface. Os termos objetivo e subjetivo esto associados ao modo como so obtidos os dados relacionados aos atributos de usabilidade. Medidas so objetivas quando os dados so coletados por observao do desempenho do usurio em tarefas especficas. Essas tarefas so consideradas de benchmark.

Figura 5-2 Benchmark O significado original do termo benchmark o de uma marca permanente usada como referncia para observaes topogrficas ou de nvel de reservatrios ou fluxos de gua. A 104

Figura 5-2 ilustra o uso de um benchmark em um fluxo de gua. Este termo usado em vrias reas com o significado de um indicador que d a referncia de desempenho de algum objeto ou atributo que se deseja avaliar. Em computao, por exemplo, benchmark o ato de executar um programa de computador, um conjunto de programas ou outras operaes, a fim de avaliar a performance relativa de um objeto, normalmente executando uma srie de testes padres e ensaios nele (Wikipedia, n.d.). Aqui, em Usabilidade, usamos o termo benchmark para denotar uma tarefa usada como referncia para avaliao do desempenho do usurio na interao com um sistema. Medidas subjetivas so quando os dados so obtidos atravs de questionrios de preferncias dos usurios. As medidas objetivas e subjetivas so igualmente importantes para a especificao e para a avaliao da usabilidade de um desenho. TAREFA DE BENCHMARK Como mencionamos, a tarefa de Benchmark uma tarefa usada como referncia para as medies objetivas. importante que uma tarefa de benchmark seja bem redigida, para indicar claramente ao usurio participante de uma avaliao o que se deseja, em que consiste a tarefa, e permitir comparaes. As tarefas de benchmark devem ser especficas para que o participante no desvie sua ateno para detalhes irrelevantes durante o teste. Devem ser descritas na linguagem do domnio da aplicao. Por exemplo, uma tarefa redigida como Utilize o sitio que voc est avaliando para fazer uma reserva de hotel para o perodo de Natal no especfica. Vai deixar o participante da avaliao confuso e provavelmente ele (ou ela) vai perguntar: Mas em quais datas? ou O que se entende por perodo de Natal ou, ainda, mas para quantas pessoas seria a reserva?. Para evitar essas confuses e permitir uma base melhor para fazermos comparaes do desempenho entre vrios participante, a tarefa de Benchmark deve ser redigida de forma precisa, clara e especfica. Outro ponto importante que deve ser observado ao definirmos tarefas de benchmark: coloque essa tarefa em termos de um objetivo (associado realizao de uma tarefa) a ser atingido. Ao iniciar uma tarefa, uma pessoa tem em mente um objetivo ou uma necessidade que a motiva. Deve-se ter o cuidado de colocar para o usurio participante de um teste de usabilidade, a proposta de realizao de uma tarefa, um objetivo, no lhe 105

dizer como realizar a tarefa. Diga o que o usurio participante deve fazer, mas no como deve fazer. O objetivo da avaliao justamente avaliar como o usurio realiza a tarefa utilizando a interface do produto em considerao, que, no caso, o instrumento para sua realizao. Por exemplo, redija uma tarefa como adicione um compromisso de almoo com os diretores Joo e Gilberto todas as quartas as 14:00h por 3 meses e no v no menu de compromisso, entre na tela de repetio de compromisso e .... Neste ltimo caso, voc j ter dada a soluo de como usar a interface para realizar a tarefa, e a avaliao da interface perder o sentido. A redao da tarefa deve permitir avaliar se o usurio consegue perceber como realizar a tarefa. Na escolha de tarefas de benchmark, bom usar caractersticas (features) simples da interface ou grupos pequenos de caractersticas, para que a causa dos problemas identificados possam ser mais facilmente rastreadas no desenho. Quando as tarefas so complexas, elas devem ser convertidas em subtarefas para a avaliao, porque as tarefas complexas so demoradas para se executar, dificultam a identificao de problemas e dificultam a comparao do desempenho de diferentes participantes. Mas, por outro lado, pode ser necessrio usar-se uma seqncia de tarefas, como no caso em que elas costumam ocorrer em seqncia. Por exemplo, uma tarefa de pagamento de uma compra em um stio de comrcio eletrnico. Tarefas complexas como essas, chamadas de tarefas representativas, tambm tm seu interesse, mas geralmente so usadas para a obteno de dados qualitativos j que fica difcil se obter dados quantitativos confiveis que permitam comparaes. QUESTIONRIOS Questionrios podem ser usados para avaliar a satisfao subjetiva do usurio com a interface. Alm de utilizao em testes de usabilidade, o questionrio um instrumento que pode ser utilizado para guiar o desenho ou melhorias de desenho da interface, identificar reas potencias para introduo de melhorias, validar avaliaes comparativas, dentre outros. Existem mtodos cientficos para elaborao e validao de questionrios. A utilizao desses mtodos importante para que se obtenham dados confiveis. Por exemplo, um questionrio deve relacionar vrias caractersticas de interface de usurio, de uma forma organizada. Montar um questionrio no somente montar uma lista de caractersticas, 106

list-las e coloc-las juntas. O questionrio deve enderear problemas de confiabilidade e validao, criando uma medida confivel para determinados aspectos da interface. Sendo assim, de preferncia, profissionais devem ser utilizados para sua produo. Uma alternativa a desenvolver um questionrio seria utilizar um questionrio j elaborado, de um fornecedor confivel, e adapt-lo para uso em uma situao especfica. Por exemplo, o QUIS (Quis, University of Maryland, 2009) um exemplo conhecido de questionrio para avaliao de satisfao de usurios que pode ser obtido mediante licenciamento. O QUIS contm, primeiramente, uma parte demogrfica onde se registra o perfil do participante. Depois, apresenta uma parte dedicada medida de satisfao do usurio de modo geral, seguido de outras partes dedicadas medida de onze fatores especficos de uma forma organizada hierarquicamente. So eles: aspectos de tela; terminologia e feedback do sistema; aprendizado; caractersticas do sistema; documentao tcnica; tutoriais on-line; multimdia; reconhecimento de voz; ambiente virtual; acesso internet e instalao do software.

5.2.4 VALOR A SER MEDIDO

Esta coluna da Tabela ERU indica o tipo dos dados, ou o tipo de valores, que sero coletados durante os testes juntos aos participantes. As medidas mais comuns so o tempo em que se completou uma tarefa e o nmero ou percentagem de erros, no entanto, vrios outros tipos de valores podem ser de interesse. No caso de medida de erros, necessrio definir exatamente o que significa um erro. Por exemplo, se o usurio no usa um boto ou menu esperado na realizao de uma tarefa, ainda que ele tenha conseguido realizar uma tarefa, deve ser contado como erro. Isso porque o erro de usabilidade indica qualquer aspecto da interface que merea ser analisado e, se necessrio, alterado para melhoria da interao. Geralmente, consideramos que houve um erro de usabilidade em uma avaliao quando um participante no completa uma tarefa ou quando faz uma ao que no leva a progresso na execuo de uma tarefa (o que exclui acesso a Helps e documentao). Por exemplo, se o participante toma um caminho errado, volta e toma um caminho certo na execuo de uma tarefa, ainda assim ocorreu o erro. 107

Para um questionrio, tipicamente utilizada a mdia de avaliaes medidas. O Valor a ser medido de um atributo como Satisfao inicial na Tabela ERU pode ser obtido como uma mdia entre vrios itens (questes) de um questionrio. Outro exemplo de Valor a ser medido que pode ser interessante a percepo do usurio do tempo decorrido. Por exemplo, uma instalao demorada, mas na qual o usurio fica ocupado trocando CDs pode ser percebida como rpida. Algumas outras medidas que podem ser usadas nas tarefas de benchmark so apresentadas a seguir. Percentagem de tarefas completadas em um tempo determinado. Proporo sucesso / fracasso na execuo de uma tarefa; Tempo gasto em erros e recuperao de erros. Nmero de comandos/aes usados para realizar uma tarefa. Frequncia do uso do help e documentao. Nmero de repeties ou falhas na tentativa de execuo de uma tarefa. Nmero de comandos disponveis no executados. Nmero de vezes em que o usurio expressou frustrao ou satisfao.

5.2.5 NVEIS DE DESEMPENHO

Na Tabela ERU, os nveis de desempenho referem-se a metas quantitativas de desempenho esperado dos usurios na interao com o software em considerao. O tempo atribudo a cada tarefa depende de sua complexidade e uso. Por exemplo, em uma tarefa freqente, a durao admitida deve ser menor. Quando o sistema a ser avaliado j se encontra operacional, a definio dos nveis esperados de desempenho dos usurios fica mais fcil. No entanto, mesmo quando se trata de um software em desenvolvimento, vrios critrios ou fontes podem ser utilizados para se fazer as estimativas de nveis de desempenho. Alguns desses so listados a seguir. Um sistema semelhante existente ou verso anterior de um sistema em desenvolvimento; 108

Sistemas concorrentes, principalmente aqueles com uma grande fatia do mercado ou com uma interface de usurio reconhecida pela qualidade.

A realizao de tarefas sem o uso de um sistema de computao (ex. manualmente, usando papel e caneta).

O uso pelos desenvolvedores de seu prprio prottipo para alguma verso da interface. Feedback de mercado, baseado na aspirao dos usurios com sistemas similares Estimativa baseada na experincia dos envolvidos, popularmente chamado de saque, quando h pouco com o que se comparar!

Diferentes papis de usurios podem significar necessidade de avaliao de diferentes tarefas e diferentes nveis de desempenho nas tarefas. Pode-se inclusive usar diferentes tabelas de Especificao de Requisitos de Usabilidade. Com a prtica, desenvolvedores tornam-se bastante habilidosos em estabelecer especificaes de usabilidade confiveis e estabelecer nveis razoveis de valores para os atributos. O nvel Atual o nvel corrente do valor a ser medido para o atributo de usabilidade na presente verso do sistema. Ou seja, o nvel atual de desempenho observado do usurio, sem a utilizao do sistema em considerao. A medio do nvel Atual ajuda a assegurar que os outros nveis possam ser estimados. til tambm saber como est o nvel atual de desempenho em relao a um ou mais sistemas concorrentes ou similares. No exemplo mostrado na Tabela 5.1 apresentada anteriormente e copiada abaixo, foi atribudo o valor do nvel Atual de desempenho para Apague o compromisso... como 0 (zero) j que em uma agenda em papel no esperado que ocorra um erro para a realizao desta tarefa. O valor do nvel Atual para Satisfao inicial foi considerado no aplicvel (denotado ??) j que no interessa avaliar-se esse atributo para agenda em papel: no se espera um usurio da agenda eletrnica que no conhea uma agenda em papel!

109

Ordem

Identificador

Req uisit o ou met a?

Atributo de usabilidade

Ator

Instrumento de medida

Valor a ser medido Atual

Nveis de desempenho Pior aceit vel Melhor possivel 4s 7s

Alvo

RU01

Desempenho inicial

Todos

Acrescente o compromisso... - benchmark 1

Tempo de execuo na primeira tentativa

5s

12 s

RU02

Desempenho inicial

Todos

Apague o compromisso... benchmark 2

Nmero de erros na primeira tentativa

0 erro

3 erros

1 erro

0 erro

RU03

Satisfao - inicial

Secretari a

Questionrio: questes...

Mdia das avaliaes

??

7,0

9,5

8,5

4 5

RU04 RU06

M R

Tabela 5-2 Tabela ERU

O nvel Pior aceitvel indica o pior nvel de desempenho do usurio que seria ainda aceitvel para cada atributo de usabilidade; no o pior que pode acontecer. o nvel mnimo de desempenho que os usurios podem alcanar e ainda considerar-se que a interface possui algum crdito em termos de usabilidade. Espera-se que, para todos os atributos avaliados, o pior nvel aceitvel, no mnimo, deve ser alcanado. O nvel Melhor possvel indica o limite superior realstico do estado de arte, o nvel de inspirao de um atributo de usabilidade. Mostra o potencial de um atributo e serve como referncia para futuras verses do sistema. Deve que ser vivel, ainda que represente um desafio, atingi-lo. O nvel Alvo indica um valor que significa sucesso inquestionvel de usabilidade para a interface, isto , o nvel que voc deseja. A expectativa que o nvel Alvo deva ser alcanado para todos os atributos especificados. Finalmente cabe observar que quando forem realizados os testes de usabilidade com usurios baseado na Tabela ERU, vo ser obtidos os valores reais de desempenho 110

observado dos usurios. Os valores obtidos permitem uma comparao rpida entre os nveis especificados e o resultado real dos testes com os usurios. A partir dessa comparao, pode ser feita uma reviso dos valores dos nveis estimados na Tabela ERU.

5.2.6 DIRETRIZES PARA DEFINIO DA TABELA ERU

Algumas diretrizes relacionadas definio da Tabela ERU podem ser apontadas. No dimensionamento da Tabela ERU, necessrio considerar os recursos/prazos disponveis. O nmero de atributos a ser medido deve ser razovel na prtica. Quando o desenvolvedor no tem muita experincia, no deve ser muito ambicioso em relao ao nmero de atributos a serem avaliados. Importante, tambm, todos os membros do projeto devem concordar com os atributos e valores da Tabela ERU; isso importante para o comprometimento da equipe. preciso considerar que cada atributo de usabilidade deve ser mensurvel na prtica. Por exemplo, razovel fazer-se uma medio do desempenho do usurio por um longo tempo? Os papis-de-usurios aplicveis devem ser especificados de forma clara. Pode-se usar uma coluna de Atores na Tabela ERU, como mostramos, ou mesmo fazerem-se tabelas separadas para cada papel relevante de usurios. Verificar se os atributos utilizados refletem as prioridades de usabilidade importante para evitar desperdcio de recursos nas avaliaes. A escolha de uma tarefa no representativa pode representar investimento em uma funo que no ser muito utilizada - perda de dinheiro e tempo! Outro ponto importante verificar se as metas para os vrios nveis so razoveis. Cabe observar que comum que o desenvolvedor iniciante seja muito leniente, defina nveis de desempenho que ficam aqum do necessrio, o que no producente. Quando os resultados do desempenho observado dos usurios participantes na realizao dos testes de usabilidade so muito piores do que os estimados na Tabela ERU h duas possibilidades:

111

o processo est caminhando normalmente mas h srios problemas de usabilidade na interface que devem ser resolvidos, ou

os valores estimados na Tabela ERU so irrealsticos. necessrio rever os nveis de desempenho estimados apresentados na Tabela ERU.

Alm de diretrizes gerais, algumas diretrizes para se determinar o nvel Pior aceitvel podem ser arroladas, como se segue. Deve, quando possvel, estar prximo do valor do nvel Atual de desempenho dos usurios. Deve ser mais alto, ou seja, indicar melhor desempenho, do que o nvel Atual na medida em que o nvel Atual no seja considerado satisfatrio. Como o sistema atual pode ser muito diferente do sistema planejado, como no caso de nosso exemplo, onde temos agenda em papel versus agenda eletrnica, pode acontecer at que nvel Atual seja considerado inatingvel para ser o nvel Alvo. Nesse caso, deve-se fazer uma estimativa ponderada para os outros nveis de desempenho. Por exemplo, tarefas simples como acrescentar compromisso, linha 1 da tabela Tabela 5-2 , podem ser feitas muito rapidamente em papel. Sendo assim, o desempenho Alvo e o Pior aceitvel foram estimados como aqum do nvel Atual (pior do que o nvel Atual). O nvel Melhor possvel o melhor nvel de desempenho que voc pode esperar em uma situao ideal, o que nos leva diretriz que, para estim-lo, deve-se considerar onde possvel se chegar com os melhores usurios (mais bem treinados), nas melhores condies, com o melhor desenho e com o melhor uso da tecnologia disponvel. Na estimativa do nvel Alvo podemos usar as seguintes diretrizes. O nvel Alvo deve, normalmente, ser mais alto que o nvel Atual para o sistema/verso existente, para representar melhoria. necessrio comparar com sistemas concorrentes. O nvel Alvo deve ser tal que se for alcanado durante os testes com o usurio, podemos estar confiantes de boa qualidade em termos de usabilidade.

112

5.3 GLOSSRIO
BENCHMARK Em usabilidade, usamos o termo benchmark para denotar uma tarefa usada como referncia para avaliao do desempenho do usurio na interao com um sistema.

5.4 BIBLIOGRAFIA
Gilb, T. Design by Objectives, Manuscritos no publicados, 1981. Good, M. et al. User Derived Impact Analysis as a Tool for Usability Engineering, Proceedings of CHI Conference on Human Factors in Computing Systems, New York: ACM, 241-246, 1986. Hix, D.; Hartson, H. R. Developing User Interfaces: ensuring usability through product &

process, John Wiley and Sons, 1993.

http://lap.umd.edu/QUIS (site QUIS). ISO/DIS 13407 Human-centred design processes for interactive systems, 1999.

QUIS (University of Maryland): acessado em http://lap.umd.edu/quis/ em 20/10/2009

Nielsen, J. Usability Engineering. Chestnut Hill, MA, Academic Press, 1993. Wikipedia, em http://pt.wikipedia.org/wiki, acessado em 10/2009

6 DESENHO DA INTERAO
O desenho da interface do usurio envolve aspectos relacionados interao usuriocomputador e aspectos construcionais, relacionados Engenharia de software. Este captulo trata de aspectos relacionados ao desenho da interao dentro do escopo da usabilidade; no abordamos aspectos construcionais. Conforme definido no Praxis-u, a atividade de desenho da interface compreende duas atividades: Definio do estilo de interao e Desenho da interao. As duas atividades podem ser consideradas atividades de desenho da interface do usurio, no entanto, 113

preferimos separ-las para enfatizar para enfatizar os aspectos relacionados a padres, que esto includos na atividade de Definio do estilo de interao. Padres so importantes no desenho da interao porque alm de facilitar a utilizao pelos usurios, promovem uma srie de benefcios para o desenvolvimento, como por exemplo, promovem a reuso e contribuem para reduzir custos de desenvolvimento. Neste captulo, aspectos associados a padres so tratados dentro da atividade de Definio do estilo de interao e os demais aspectos de desenho da interface do usurio so apresentados dentro da seo relativa ao Desenho da interao. importante mencionar que, diferente da situao observada na Anlise de contexto de uso, agora vamos considerar que o nosso produto, ou o produto em perspectiva, estar apoiando as atividades realizadas pelos usurios. Sendo assim, as tarefas descritas na Analise de Contexto de uso que forem ser apoiadas pelo sistema automatizado, devem agora ser repensadas para que sejam executadas com o apoio do sistema em considerao. importante notar, ento, que na Anlise de Contexto de Uso registramos como os usurios realizam suas tarefas, enquanto que no Desenho da Interao, vamos projetar como os usurios devero executar suas tarefas com o apoio do sistema em perspectiva.

Figura 6-1 Garom anotando pedido. Fonte: acessado na internet em 21/10/2009 em http://melhoresbaresdorio.com.br/sem-categoria/dicas-de-como-atender-bem-segundo-avisao-de-um-bohemio 114

Por exemplo, vamos imaginar que estamos desenvolvendo um sistema para ser usado pelos garons no atendimento aos clientes de um restaurante. Na Anlise de tarefas podemos registrar que os garons se utilizam de um bloco para anotar os pedidos dos clientes ( Figura 6-1) e descrever como os garons realizam o atendimento aos clientes. No entanto, no Desenho podemos decidir que queremos uma soluo mais tecnolgica e vamos projetar a utilizao de computador de mo (PDA) para os garons comandarem o pedido do cliente com comunicao direta com a cozinha do restaurante, Figura 6-2.

Figura 6-2 Dispositivo de mo a ser usado para comandar pedidos. Fonte: acessado na internet em 21/10/2009 em http://www.coolbluehomes.com/home/handheld/choose_your_handheld_model_type.htm Acima, nos referimos s tarefas descritas na Analise de Contexto de uso que forem ser apoiadas pelo sistema automatizado porque pode acontecer que desistamos de ter o software em considerao apoiando alguma tarefa anteriormente descrita na Anlise de tarefas. Isso pode acontecer devido priorizao, por falta de recurso, tempo ou por outro motivo relevante qualquer.

6.1 ATIVIDADE DE DESENHO DA INTERAO

A atividade de Desenho da Interao, conforme definida no Praxis-u, apresentada na Figura 6-3 na forma de um diagrama (de atividades) UML. O Desenho da Interao composto de trs atividades principais: Modelagem conceitual, Modelagem de contedo e navegao e Desenho detalhado, que sero apresentadas nas sees seguintes.

115

Modelagem conceitual

Modelagem de contedo e navegao

Reviso do modelo de contedo e navegao

Avalia modelo ?

Sim

Prototipao do modelo de contedo e navegao

pcisw : Componente

No Avaliao de usabilidade do modelo de contedo e navegao

Desenho aprovado

Desenho rejeitado

Desenho detalhado

Prototipao do desenho detalhado

pdisw : Componente

Avaliao de usabilidade usando o prottipo

Desenho rejeitado Desenho aprovado Implementao do desenho da interao

Figura 6-3 Subprocesso de Desenho da interao do Praxis-u Na Figura 6-3 podemos observar que o processo prescreve a realizao das atividades de Modelagem Conceitual seguida da Modelagem de contedo e navegao. A seguir, prope uma atividade de reviso seguida de dois possveis caminhos. A primeira possibilidade seguir diretamente para o Desenho detalhado. A alternativa, que consideramos mais 116

indicada, desenvolver um prottipo correspondente ao Modelo de contedo e navegao, denominado pcisw, e utilizar este prottipo em um teste de usabilidade com os usurios visando validao do modelo. Se, na avaliao com usurios, o Modelo de contedo e navegao no for considerado satisfatrio, o processo sugere que voltemos atividade de Modelagem conceitual para a realizao de melhorias e o ciclo se repete. Posteriormente, o processo prescreve outro ciclo onde feito um prottipo do desenho detalhado, esse prottipo avaliado com usurios visando validao, e, caso o desenho seja rejeitado, o processo tambm sugere uma volta atividade de Modelagem conceitual para a realizao de melhorias no desenho da interao em suas vrias etapas.

6.1.1 MODELAGEM CONCEITUAL

A Modelagem Conceitual um desenho da interao em alto nvel de abstrao. No nvel de abstrao considerado no estamos preocupados com a aparncia, em termos de design grfico, dos elementos de interface; isso ser considerado em uma etapa posterior do desenho. A atividade de Modelagem conceitual tem como objetivo definir os principais aspectos relativos interface do usurio, incluindo a definio de quais vo ser e como vo ser realizadas as atividades que os usurios vo executar com o apoio do produto em considerao. Alm das atividades em si, que constituem aspectos dinmicos, devemos descrever tambm aspectos estticos relacionados a essas atividades, por exemplo, os objetos e demais recursos envolvidos. A Modelagem conceitual envolve trs sub-atividades. Definio do modelo conceitual esttico: define os objetos que faro parte do desenho e os relacionamentos entre eles Definio dos modelos mentais: modelos mentais ou metforas a serem usados na interao so definidos. Definio dos roteiros de desenho: define os aspectos dinmicos da interao, isto , apresentamos uma definio de como as atividades dos usurios sero realizadas com o apoio do sistema em considerao.

117

DEFINIO DO MODELO CONCEITUAL ESTTICO Nesta atividade, definem-se os objetos que atuaro na interao. Os objetos incluem pessoas, equipamentos, artefatos, recursos, etc que estaro envolvidos na interao. importante tambm definir relacionamentos entres os objetos. Na modelagem como utilizada em desenvolvimento de software, importante descrever no apenas objetos ou conceitos, mas tambm modelar os relacionamentos ou conexes semnticas relevantes existentes entre eles. Por exemplo, vamos considerar o sistema para ser usado pelos garons no atendimento aos clientes de um restaurante, ilustrado na Figura 6-2 acima. Podemos querer representar em um Modelo conceitual esttico que a execuo da tarefa de atendimento aos clientes do restaurante envolve os seguintes objetos. Garom: recurso humano, empregado que serve mesa. Dispositivos PDAs: computadores de mo a serem utilizados pelos garons para comandar os pedidos diretamente cozinha do restaurante. Cozinha: cozinha do restaurante, responsvel por receber, executar e avisar quando os pedidos comandados pelos garons estiverem prontos por meio dos PDAs. Pedido: relao de pedidos dos clientes de uma mesa. Mesa: mesa do restaurante, corresponde a um grupo de clientes que esto sendo atendidos juntos. ...

Os objetos so os listados acima; os relacionamentos entre eles podem ser vnculos como: cada mesa est associada a um grupo de clientes durante um atendimento; cada garom utiliza-se de um dispositivo PDA do qual faz uso exclusivo; o garom atende a vrias mesas ao mesmo tempo, a Cozinha atende a todas as mesas, etc. O Modelo conceitual pode ser descrito informalmente, como fizemos no exemplo acima, ou pode-se usar diagramas de classe ou de objetos da UML em uma descrio mais formal (Booch, G. et al, 2005), (Rumbaugh, J. et al, 2004). A deciso do que utilizar vai levar em conta a formao da equipe (conhecimento de UML) e a complexidade do modelo. Pode-se organizar os modelos em diagramas associados a tarefas ou a casos de uso do software em considerao. 118

DEFINIO DE MODELOS MENTAIS A Definio dos modelos mentais visa definir os modelos mentais que sero passados aos usurios atravs da interface do software, para serem usados na realizao de suas atividades suportadas pelo sistema. Modelos mentais ou metforas formam um pano de fundo onde se desenvolve o desenho da interao. Em geral, na interface desenhada vamos procurar utilizar os modelos mentais dos usurios levantados na Anlise de Contexto. Isso porque os usurios j conhecem e se utilizam desses modelos na realizao de suas atividades. No entanto, pode ser que se descubram modelos conceituais que sejam melhores em algum aspecto do que aqueles utilizados no momento atual pelos usurios. Nesse caso, devemos considerar se vale realmente utilizar esses novos modelos em substituio aos modelos usados atualmente, considerando o custo e benefcios. Os custos esto ligados principalmente necessidade dos usurios de terem que aprender e se adaptar aos novos modelos, os benefcios podem ser em termos de eficincia ou eficcia na interao, que permita um melhor uso dos recursos, humanos ou de outro tipo, envolvidos. Os modelos mentais, ento, sero utilizados pelos usurios na interao. Os modelos mentais sero passados atravs das imagens ou outros meios que sero colocadas na interface. No entanto, modelos mentais mais complexos podem exigir treinamento para que sejam passados aos usurios. Como em todo trabalho de modelagem, deve haver uma anlise de alternativas, pesando os prs e contras de cada uma delas. DEFINIO DOS ROTEIROS DE DESENHO Esta atividade visa definio de aspectos dinmicos associados interao, isto , a definio de como as atividades dos usurios sero realizadas com o apoio do sistema em considerao. O resultado dessa atividade uma viso externa, ou seja, uma viso do ponto de vista dos usurios. Sugerimos a tcnica de Roteiros para ser utilizada para a descrio da interao. Porm, diagramas de atividades, de estado ou de interao ou modelos informais tambm podem ser utilizados para complementar, ou mesmo para compor, a descrio.

119

Roteiros so histrias sobre pessoas e suas atividades (Rosson & Carrol, 1990), como j apresentado no Captulo 4 - Anlise de contexto de uso. A tcnica de Roteiros usada no Desenho da interao a mesma utilizada no domnio do Problema, na Modelagem de tarefas. Entretanto, enquanto no domnio do problema os roteiros descrevem a situao corrente onde o sistema em perspectiva ainda no aparece, no Desenho da Interao os Roteiros vo ser usados para descrever o modo projetado de como as atividades vo ser realizadas com o apoio do sistema em considerao. Os Roteiros utilizados so histrias que descrevem um cenrio onde uma tarefa de interesse realizada com o apoio do sistema em perspectiva. No se trata de uma simples descrio de tarefas, como vimos, mas de uma descrio enriquecida com aspectos relevantes como a caracterizao das pessoas envolvidas, os objetivos da tarefa, as estratgias utilizadas pelas pessoas envolvidas na realizao das tarefas, etc. Estes aspectos constituem informaes importantes usadas no desenvolvimento da interao, especificamente no Desenho detalhado, para o produto em considerao. Naturalmente, os Roteiros de domnio de problema constituem a principal fonte de informao para a criao dos Roteiros de Desenho da interao. Podemos dizer que os Roteiros esto para a usabilidade assim como os casos de uso esto para a engenharia de software. Mas os Roteiros envolvem um contexto mais amplo que o representado pelos casos de uso da engenharia de software, j que os casos de uso so utilizados para descrever apenas as partes de uma tarefa que envolvem a utilizao do sistema de software. J os Roteiros so usados tambm para descrever outras partes das tarefas alm de estritamente aquelas em que o sistema est apoiando sua realizao. O contedo de um Roteiro de desenho da interao semelhante ao contedo de um Roteiro de domnio de problema apresentado no Captulo 4 e reproduzido aqui na Tabela 6-1. Em geral, os Roteiros descrevem uma instncia da interao, mas alternativas importantes podem tambm ser descritas.

120

Aspectos usados no Roteiro Cenrio

Significado dos aspectos usados no roteiro

Detalhes da situao que motivam ou explicam os objetivos, aes, reaes dos atores. O software em perspectiva apia a realizao da atividade modelada.

Atores

Papis de pessoas que interagem com o ambiente do cenrio; eventualmente com suas caractersticas relevantes.

Objetivos da tarefa Modelos mentais

Aspectos da situao que motivam as aes realizadas pelos atores. Modelos conceituais e atividade mental de que os atores se utilizam para converterem objetivos em comportamentos.

Avaliao

Atividade mental dos envolvidos que visa interpretar caractersticas da situao.

Aes

Comportamento observvel das pessoas. Deve envolver o uso do sistema em considerao.

Eventos

Ocorrncias externas ou internas que podem influenciar a atividade. Podem no ser percebidas pelos atores, mas so importantes para o roteiro.

Tabela 6-1 Roteiros de desenho da interao

O Roteiro apresentado no exemplo mostrado no Captulo 4, seo 4.4.3, descreve um cenrio onde um cliente (Jos) de um supermercado deseja comprar um vinho para presentear um amigo e o vendedor (James) do setor de vinhos do supermercado vai apoiar a venda. O quadro abaixo utiliza este mesmo exemplo, s que agora considerando o uso de um software que est sendo desenvolvido para apoiar a tarefa de venda de vinhos. Observe que as informaes contidas no Roteiro de domnio de problema foram utilizadas. Por exemplo, ciente de que o cliente do supermercado ficaria constrangido em deixar transparecer que no conhece de vinho, os desenvolvedores colocaram essa informao 121

como parte do software de modo que o cliente se sinta vontade para fazer suas consultas. Tambm a faixa de preo do presente que o cliente tem em mente informada ao sistema em um contato impessoal.

James, um vendedor especializado em vinhos, trabalha no setor de vinhos de um supermercado sofisticado. O supermercado utiliza o produto Bem-Vinho para apoiar as vendas no setor de vinhos. Jos, um cliente, deseja comprar uma garrafa de vinho para presentear um amigo. Jos est indeciso sobre o que comprar, deseja aperfeioar a relao custo-benefcio. Jos tem em mente um presente na faixa de R$ 50,00; ele navega pela interface do software Bem-Vinho a procura de sugestes de vinhos para sua compra. Jos teria reserva em revelar o valor que tem em mente para o presente ao vendedor, mas se sente a vontade para inform-lo ao software Bem-Vinho (esta seria uma das primeiras informaes solicitada pelo software). O produto lista 10 sugestes de vinhos na faixa de preo pretendida por Jos. O vendedor est posicionado discretamente, pronto para ajudar se solicitado. James sabe que, muitas vezes, o cliente se sente constrangido em transparecer que entende muito pouco (quase nada) de vinhos e que no se sente a vontade para informar (pessoalmente ao vendedor) a faixa de preo do presente pretendida. Eventualmente, Jos pede a opinio do vendedor. James, pergunta sobre o gosto do amigo de Jos. Discretamente, consulta o software Bem-Vinho para conhecer mais detalhes do perfil de vinho desejado pelo cliente, principalmente a faixa de preos que o cliente se dispe a gastar. James comenta sobre as vrias opes de tipos de vinho, fornecidas pelo Bem-Vinho, de acordo com o perfil desejado pelo cliente. O Bem-Vinho utilizado pelo cliente ou pelo vendedor para consultas e eventuais detalhamentos de alguma informao. Em particular, com auxlio do Bem-Vinho, pesquisa e apresenta as ofertas de produtos que se encaixem no perfil de vinho desejado pelo cliente, visando oferecer um bom servio. De repente, outro cliente pede ajuda ao vendedor. James deixa Jos se distraindo utilizando o Sistema e passa a atender ao outro cliente. James fica tranqilo ao deixar o cliente anterior porque sabe que ele pode ir se ocupando com o sistema Bem-Vinho.

122

Roteiros de desenho tambm devem ser complementados com uma anlise de argumentos. Para isso, so identificadas possveis variaes relacionadas aos roteiros identificados e analisados prs e contras. Por exemplo, poderia ser considerada a utilizao de um formato de hipertexto na interface. Isso teria a vantagem de permitir ao usurio consultas no nvel de detalhamento que julgar conveniente. Alm disso, o hipertexto uma forma eficiente de organizar a informao. No entanto, h o risco de o usurio ter dificuldade na navegao seno tiver familiaridade com esse formato.

6.1.2 MODELAGEM DE CONTEDO E NAVEGAO

Aps a modelagem conceitual, chegamos ao ponto de nos preocupar com a interface mais concretamente, fazendo o desenho da arquitetura da interface. A Modelagem de contedo e navegao envolve os aspectos estticos ou estruturais e dinmicos. O aspecto estrutural corresponde criao de um modelo simplificado do contedo da interface e o aspecto dinmico corresponde definio da navegao associada ao modelo estrutural. O Modelo de contedo e navegao define a interface em termo de Espaos de interao, conforme proposto por Constantine e Lockwood (Constantine & Lockwood 1999). Um Espao de interao um espao de trabalho onde o usurio tem disponvel ferramentas para realizar suas atividades utilizando o software. O Espao de interao pode ser visto como uma metfora de um atelier ou um ambiente virtual de trabalho. No software, um Espao de interao vai corresponder a agrupamento de telas (ou pginas web), telas, ou mesmo partes de telas, ainda sem a preocupao com o design grfico. A parte esttica do Modelo de contedo e navegao descreve a interface em termos de distribuio de contedos em espaos de interao. Este modelo deve ser colocado na forma de uma hierarquia de espaos de interao. Os autores Constantine e Lockwood (1999) sugerem uma maneira informal de representao desses modelos com a utilizao de cartes de papel ou de post-its em um quadro representando a interface, onde cada carto representa um Espao de interao. A topologia dos cartes no quadro est associada hierarquia. O Post-it aquele pequeno papel adesivo, em geral amarelo, de fcil remoo, utilizado para se deixar recados ou notas para lembrana de compromissos ou coisas a realizar. 123

Aqui, ns sugerimos a utilizao de textos explicativos e diagramas UML para notao do Modelo de contedo e navegao. Esse modelo tem as seguintes caractersticas: o modelo mostra uma hierarquia de espaos de interao; pacotes lgicos da UML so utilizados para representar a organizao hierrquica entre espaos de interao; relacionamentos de associao, com esteretipos <<web page link> entre Espaos de interao indicam possibilidade de navegao; relacionamento de associao, com esteretipo <<affinity>> , indicam semelhana de espaos ; relacionamentos de agregao ou composio podem indicar relao parte-todo entre espaos de interao, tipicamente, entre elementos de interao e suas telas (ou pginas); relacionamentos de generalizao podem representar herana entre espaos de interao. diagramas de sequncia ou de comunicao com objetos representando telas (ou pginas Web) e mensagens indicando navegao tambm so utilizados para representar o aspecto dinmico de navegao. Um exemplo ilustrativo desse modelo pode ser encontrado no stio do professor (http://homepages.dcc.ufmg.br/~clarindo/disciplinas/eu/material/index.htm). O Modelo de contedo e navegao pode ser implementado na forma de prottipo, o que facilita a realizao de avaliaes de usabilidade com usurios visando validao do Modelo, conforme mostrado na Figura 6-3 acima. O modelo baseado em UML que sugerimos pode, inclusive, ser usado diretamente como um prottipo para avaliaes com os usurios. Ou ento, pode-se criar um prottipo navegvel a partir desse modelo, o que pode ser feito facilmente com ferramentas de prototipagem ou mesmo com ferramentas de criao de apresentaes.

6.1.3 DESENHO DETALHADO

A atividade de Desenho detalhado visa chegar ao nvel do desenho de telas em um processo que envolve refinamentos e melhorias sucessivas. Nessa atividade, o desenho 124

conceitual e o modelo de contedo e navegao so utilizados como insumo, e chegamos ao nvel de nos preocupar com a aparncia de objetos, navegao entre telas, redao de mensagens, rtulos, etc. Como resultado final, temos o desenho da interface pronto para ser implementado no desenvolvimento de um produto de software. A atividade de Desenho complexa. H uma vasta literatura disponvel sobre o assunto, sendo assim, vamos preferir somente indicar algumas referncias sobre o assunto. Por exemplo, Shneiderman et al. (2009) tm um livro considerado com uma referncia, com extensa cobertura do assunto.O livro de Van Harmelen (2001) um livro de editor que apresenta varias tcnicas e mtodos para o desenho de interface. Podem ser consultados tambm (Hix & Hartson 1993), (Galitz 2007), (Krug & Black 2005), (Rosson & Carrol 2002), dentre outros.

6.2 GUIA DE ESTILO DE USABILIDADE

A utilizao de padres no desenho da interface do usurio traz benefcios tanto para os clientes/usurios como tambm para a equipe de desenvolvimento do software. Dada a importncia que representa a utilizao de padres, o Praxis-u prescreve que, em adio ao Desenho da interao, a atividade de desenho da interface inclua tambm a atividade de Definio do estilo de interao para tratar de aspectos de desenho ligados a padres. A atividade de Desenho do estilo de interao define padres ou estilos a serem utilizados internamente pela equipe de desenvolvimento da interface com o usurio. Esses padres so registrados no documento Guia de estilo de usabilidade (geusw). O objetivo do Guia de estilo de usabilidade estabelecer diretrizes e padres para o desenvolvimento de software e, em alguns casos, descrever tambm mtodos para garantir a consistncia entre produtos de uma famlia de produtos ou mesmo dentro de um produto. Um Guia de estilo de usabilidade pode, ento, abranger um produto de software ou uma famlia de produtos com algum vnculo que os une. Por exemplo, o conjunto de produtos de software de um mesmo cliente de uma empresa desenvolvedora de software pode estar submetido a um mesmo padro estabelecido em um Guia.

125

A utilizao de padres no desenvolvimento de interfaces traz vrios benefcios, como listados a seguir. Garante a consistncia em uma famlia de produtos. Uma das principais vantagens que justificam a utilizao de padres justamente a de estabelecer uma base comum que facilite a consistncia em relao a diversos aspectos associados interface. Contm um repositrio de diretrizes e padres, fonte de consulta para os desenvolvedores, principalmente, mas tambm para outros atores envolvidos no desenvolvimento de software. uma ferramenta para o treinamento de novos desenvolvedores que tm o Guia com fonte de consulta. Facilita o trabalho em conjunto de grupos.

Para os usurios, especificamente, podemos listar os seguintes benefcios. Reduo de erros na utilizao do software. Aumento da confiana na utilizao de um produto cuja interface se utiliza de padres que lhes so familiares. Aumento da eficincia na utilizao do software. Reduo da resistncia dos usurios nova tecnologia que um produto de software pode representar. A organizao desenvolvedora tambm pode se beneficiar do uso de padres. Reduz tomadas de decises arbitrrias. Minimiza a reinveno, beneficia o re-uso Diminui o tempo de desenvolvimento. Reduo de testes pela utilizao de elementos padronizados confiveis. Neste aspecto, tambm um instrumento que ajuda a reduzir erros encontrados em avaliaes de usabilidade. O Guia de estilo de usabilidade deve ser desenvolvido em um trabalho de grupo para que todos os envolvidos estejam de acordo. O comprometimento da equipe importante para o sucesso na definio e uso do Guia. Sendo assim, idealmente, um Guia de estilo de usabilidade deve envolver a equipe de usabilidade ou de desenho da interface, outros 126

desenvolvedores da rea de engenharia de software, profissionais responsveis por documentao, design grfico e marketing, usurios, clientes e especialistas no domnio. Claro que nem sempre todos esses profissionais esto disponveis ou mesmo participam de um projeto de desenvolvimento de software; nesse caso, faz-se o melhor possvel com as pessoas disponveis. Com sugesto, um Guia de estilo de usabilidade pode ter a seguinte estrutura que utilizado no artefato geuswdo Praxis-u. 1. Introduo: define o contexto de utilizao do Guia. Deve incluir os seguintes aspectos ou sees no documento: Objetivos do documento de Guia de Estilo; audincia esperada do documento; como se espera que o Guia seja utilizado; um histrico de acontecimentos relevantes para mostrar o contexto onde o Guia ser utilizado e o escopo ou abrangncia do documento; definio de consistncia com outros Guias ou documentos; referncia a outros documentos relevantes para o leitor; identificao do cliente e fornecedor; dados do projeto; plataforma utilizada e outras decises importantes que forem tomadas nas reunies entre os grupos envolvidos. organizao do documento;

2. Conceitos preliminares: d uma viso geral de usabilidade, apresentando os principais conceitos relacionados ao assunto. Lembre-se que o Guia de estilo pode ser utilizado por usurios e outras pessoas que podem no ter muita familiaridade com a usabilidade. 3. Diretrizes Gerais: diretrizes de usabilidade que se aplicam a qualquer tipo de produto. Essas diretrizes servem com uma espcie de padro mais leve, alertando os desenvolvedores sobre diretrizes importantes para o desenho da interface do usurio. 127

4. Padres especficos da famlia de produtos <nome da famlia de produtos>: pode ser organizado com o seguinte contedo. 1. Aspectos gerais: apresenta padres em mais alto nvel de abstrao relativos organizao e formato de telas ou pginas Web e aspectos do ambiente de programao que impem restries ao desenho da interface. 2. Padres de comportamento da interface: apresenta aspectos de comportamento da interface, como navegao, forma de pesquisa, etc. 3. Elementos de interao: deve existir uma seo separada para cada objeto de interao. Dentro de cada seo deve haver figuras ilustrativas de como deve ser o leiaute do objeto e as diretrizes aplicveis a ele. 4. Mensagens: essa seo deve apresentar diretrizes relativas s mensagens de erro, mensagens informativas e feedback do progresso de uma tarefa, etc, ou seja, todos os tipos de mensagens, incluindo figuras ilustrativas, devem estar nesta seo. 5. Tratamento da ajuda aos usurios: descreve padres relativos ajuda online aos usurios. Padres de manuais de usurios so normalmente considerados associados aos processos de desenvolvimento. 6. Dispositivos de interface de hardware: descreve os dispositivos de entrada e sada para os quais o Guia se aplica. 5. Padres especficos de produtos da famlia: opcional. Os Padres especficos de produtos da famlia vo descrever padres especficos de cada produto da famlia. Os padres de cada produto especfico so vistos como uma especializao ( no sentido Orientado a Objeto do termo) dos Padres especficos da famlia de produtos <nome da famlia de produtos>. As sees que descrevem cada produto e a sees que descrevem a famlia de produtos tm a mesma estrutura, e qualquer aspecto definido para a famlia de produtos considerado vlido para todos os produtos da famlia e no precisam ser repetidos. Voc s vai usar a parte de padres de cada produto se quiser modificar (sobrescrever) o que j foi definido para a famlia de produtos, como funciona no conceito de herana em O-O. Observe , ainda, que o Guia permite descrever vrios produtos de uma mesma famlia, que apareceriam em sees 5.1, 5.2, ..., quantos forem necessrios!

128

6. Glossrio

7. Bibliografia: citar bibliografia relevante para os usurios.

Vrios tipos de consistncia podem ser importantes e devem ser objeto de padronizao registrada do Guia de estilo de usabilidade, como se segue. Consistncia com outros guias de estilo usados. Pode ser interessante criarmos uma hierarquia de guias de estilo. Por exemplo, considerando o chamado governo eletrnico, as instncias de governo federal, estadual e municipal, cada uma, pode definir padres que se aplicam a qualquer stio de governo eletrnico. Neste caso, podemos imaginar uma hierarquia, onde o governo municipal deve seguir os padres estabelecidos em nvel estadual e o governo estadual deve seguir os padres estabelecidos em nvel federal. Consistncia em relao ao aspecto visual da interface. Consistncia em termos de mensagens de erro. Consistncia de comportamento dos objetos de interao usados na interface. Consistncia com as expectativas do usurio. Ou seja, uma interface deve ser desenvolvida considerando os usurios, seus comportamentos e expectativas. Os seguintes passos so recomendados na criao de Guia de Estilo. 1. Definio das pessoas que vo desenvolver o Guia. Deve incluir pessoas dos vrios perfis de profissionais descritos anteriormente. 2. Definio da plataforma para qual o Guia vai ser desenvolvido. 3. Confeco da estrutura do documento. 4. Escolha das diretrizes que sero colocadas. 5. Definio de requisitos que o Guia de Estilo deve satisfazer. Definio dos objetos de interao que o Guia de Estilo deve abordar. 6. Confeco dos gabaritos (templates) de telas e dos exemplos dos objetos de interao. 7. Montagem do documento.

129

8. Reviso.

Vrios fatores podem levar ao fracasso na adoo do conceito de Guia de estilo no desenvolvimento da interao. Por exemplo, os gerentes de projeto podem negligenciar os benefcios do Guia de Estilo e no promoverem adequadamente sua utilizao. Ou um Guia de Estilo pode ser muito amplo, perdendo muito de sua aplicabilidade; neste caso, deve ter seu foco reduzido. Pode ser tambm que a equipe de desenvolvimento fique relutante em adot-lo - a cabe a atuao da gerncia para buscar fomentar sua utilizao efetiva. Outro risco que o Guia se torne maante se tiver muita informao textual. Por isso, muito importante que o Guia de estilos de usabilidade seja rico em exemplos prticos e ilustraes para facilitar e tornar at mais agradvel sua utilizao. Para facilitar a consulta, importante que o Guia tenha um sumrio. Outro fator que pode colocar a utilizao do Guia em riso a discordncia entre membros da equipe que o desenvolve. Sendo assim, importante o trabalho de uma equipe motivada e comprometida. Concluindo, a elaborao de um Guia de estilos de usabilidade envolve o trabalho de grupos de diversas reas da empresa/instituio. Ele sozinho, obviamente, no garante o sucesso do design, mas um documento que contribui muito para garantia de padres e agilidade no desenvolvimento.

6.3 GLOSSRIO
Sem contedo

6.4 BIBLIOGRAFIA
Booch, G.; Rumbaugh, J.; Jacobson, I., Unified Modeling Language User Guide, 2nd Edition, Addison Wesley, 2005. Constantine, L.L. & Lockwood, L.A.D. Software for Use: a Practical Guide to the Models

and Methods of Usage Centered Design, Addison-Wesley, Reading-MA, 1999.

Galitz, W. O. The Essential Guide to User Interface Design. John Wiley, 2007. 130

Krug, S.; Black, R. Don't Make Me Think: Common Sense Approach to Web Usability, 2nd edition, New Riders, 2005 Nielsen, J. Designing Web Usability, New Riders Press, 2000. Rosson, M. B., Carrol, J.M. Usability Engineering:

Scenario Development of Human-

computer Interaction. Morgan kaufmann Publishers, 2002.

Rumbaugh, J.; Jacobson, I.; Booch, G., The Unified Modeling Language Reference Manual, Addison Wesley, 2nd edition, 2004. Shneiderman, B; Plaisant, C.; Cohen, M.; Jacobs, S. Designing the User Interface:

Strategies for Effective Human-Computer Interaction, 5 ed. Reading, MA, Addison-Wesley,

2009 Van Harmelen, M. Object Modeling and User Interface Design: Designing Interactive

Systems, Addison-Wesley, 2001.

Hix, D.; Hartson, H. R. Developing User Interfaces: ensuring usability through product &

process, John Wiley and Sons, 1993.

7 AVALIAO DE USABILIDADE
A atividade de Avaliao de usabilidade prescrita pelo Praxis-u visa avaliao da qualidade da interface como instrumento da interao usurio-computador. Pode ser considerada como uma atividade de garantia da qualidade dentre outras que so utilizadas no processo de desenvolvimento de software. Diferentes tipos de avaliao, com objetivos e caractersticas prprias, podem ser utilizados. Existem tcnicas de avaliao, que utilizam o formato de revises. As avaliaes mais confiveis, no entanto, envolvem experimentaes com a participao de representantes dos usurios. Estas avaliaes, tambm chamadas de testes com os usurios, normalmente fazem uso de roteiros de tarefas que so executadas por usurios com a utilizao de prottipos ou com o produto final, dependendo do estgio de desenvolvimento do software. Representantes dos usurios so convidados a executar as tarefas previstas no roteiro enquanto um avaliador/observador se coloca ao lado analisando a qualidade da interao e identificando possveis problemas. 131

Este captulo apresenta a atividade de Avaliao de usabilidade prescrita no Praxis-u. O processo de avaliao semelhante para as vrias tcnicas de avaliao que podem ser utilizadas, no entanto, neste documento, vamos nos enfatizar a tcnica de Teste de usabilidade com o usurio.

7.1 OBJETIVOS
A avaliao de usabilidade pode ter o carter formativo ou somativo. A avaliao formativa realizada durante um projeto de desenvolvimento de software com o objetivo de aperfeioar o produto. A avaliao somativa realizada, em geral, com o produto concludo, visando julg-lo ou compar-lo com produtos semelhantes. A avaliao somativa pode tambm ser utilizada como critrio de aceitao de um produto, ou seja, como parte dos requisitos no funcionais acordados com os usurios. As avaliaes formativas devem ser realizadas o mais cedo possvel durante o desenvolvimento do software, em respeito ao princpio que preconiza que quanto mais cedo se detecta um problema, menor o custo de sua soluo. Sendo assim, para se fazer avaliaes antes do desenvolvimento do produto final, nas avaliaes formativas, muitas vezes so utilizados prottipos. Apesar da necessidade de se avaliar as interfaces o mais cedo possvel, isso no significa que deva se avaliar solues toscas, sem muita reflexo, j que o custo das avaliaes tambm precisa ser levado em conta. O custo das avaliaes inclui no somente o aspecto financeiro, mas tambm o possvel desgaste dos desenvolvedores/fornecedores com os usurios ou clientes ocasionado por uma soluo ruim submetida de maneira intempestiva. No entanto, preciso no confundir um prottipo simples com uma soluo ruim ou inadequada para a avaliao; um prottipo simples, por exemplo, desenhado a mo, pode ser adequado e til para uma avaliao de aspectos especficos da interao. As avaliaes de usabilidade so indicadores da qualidade da interao usurio-sistema. A deteco de problemas de usabilidade por meio de uma avaliao permite diagnosticar, em determinados contextos de operao do produto, quais objetivos foram atingidos. A avaliao de usabilidade de um sistema interativo tem os seguintes objetivos gerais:

132

verificar a qualidade da interface em termos de sua adequao para que os principais atributos de usabilidade sejam alcanados;

validar os requisitos e metas de usabilidade, verificando o desempenho dos usurios face aos objetivos estabelecidos;

validar a eficcia da interao humano-computador face efetiva realizao das tarefas por parte dos usurios;

verificar a eficincia dessa interao, face aos recursos empregados. obter dados qualitativos que sirvam de insumo para uma melhoria da qualidade da interface;

obter indcios da satisfao ou insatisfao (efeito subjetivo) que a interface possa trazer ao usurio.

Os objetivos especficos so: avaliar o desempenho, constatar, observar e registrar problemas efetivos de usabilidade durante a interao; obter mtricas objetivas para eficcia, eficincia e produtividade do usurio na interao com o sistema. Por exemplo, podem ser analisadas mtricas relacionadas ao tempo gasto, a quantidade de incidentes ou de erros dos usurios, passos desnecessrios na realizao de tarefas e busca de ajuda, dentre outros; diagnosticar as caractersticas do desenho que provavelmente atrapalham a interao por estarem em desconformidade com padres implcitos e explcitos de usabilidade; prever dificuldades de aprendizado na operao do sistema; avaliar o desempenho dos usurios, na utilizao do sistema, em relao aos atributos de usabilidade considerados mais importantes como, por exemplo, produtividade, preveno de erros, facilidade de aprendizagem e reteno do conhecimento de como utilizar o sistema; conhecer a opinio do usurio em relao ao sistema; sugerir as aes de re-projeto mais evidentes para melhorias considerando-se os problemas de interao efetivos ou diagnosticados.

133

7.2 TCNICAS
Para realizar a avaliao de um sistema interativo, podem-se empregar vrias tcnicas que podem ser classificadas, dependendo da estratgia utilizada, em analtica, experimentais e de pesquisa de opinio. As tcnicas analticas so realizadas por especialistas em desenvolvimento de interface atravs de revises de prottipos ou do produto final buscando avaliar a qualidade da interao proporcionada pela interface. As tcnicas empricas ou experimentais objetivam detectar problemas de usabilidade por meio da observao do usurio interagindo com os prottipos ou a interface finalizada, atravs de experimentos controlados. As tcnicas de pesquisa de opinio buscam avaliar a satisfao do usurio atravs de tcnicas de questionrios e ou entrevistas, com o objetivo de se antecipar reao do usurio com relao ao produto. Cabe observar a participao de usurios em tcnicas analticas s faz sentido se eles tm um conhecimento de interface que lhes permita contribuir na anlise da qualidade da interao do produto sob avaliao. Normalmente, a participao dos usurios mais indicada nas tcnicas experimentais ou de pesquisa de opinio onde sua contribuio ser baseada em sua experincia na utilizao do sistema em considerao ou no uso de sistemas semelhantes. Ou seja, nestas tcnicas se espera que os participantes sejam representativos de perfis dos usurios e que se comportem nada mais, nada menos, do que como usurios tpicos. Cabe tambm observar que no somente problemas, mas tambm aspectos positivos da interface, podem ser interessantes e merecem ser registrados nas avaliaes de usabilidade. Isso no s por contribuir para a auto estima da equipe, mas tambm porque uma boa soluo deve ser lembrada para, quem sabe, ser utilizada em outros locais ou situaes em que se apliquem.

7.2.1 ANALTICAS
As tcnicas analticas em geral so realizadas por projetistas ou especialistas em usabilidade, podendo at dispensar a participao de usurios. As tcnicas analticas mais conhecidas so as avaliaes heursticas e as inspees atravs de listas de conferncia.

134

7.2.1.1 Avaliao heurstica

A avaliao heurstica deve envolver a participao de especialistas componentes da equipe de desenvolvimento da interao ou convidados externos. Esses convidados podem incluir especialistas em usabilidade, conhecedores do domnio de que trata o software em considerao, desenvolvedores da rea de engenharia de software, pessoas da rea de marketing ou de comunicao do cliente, ou mesmo usurios. A composio da equipe depender do tipo de produto e das condies especficas do projeto. A avaliao heurstica realizada considerando-se um conjunto de regras ou diretrizes que so observadas para identificar possveis problemas na interao humano-computador que provavelmente os usurios encontraro. Esse tipo de avaliao baseado no conhecimento e na experincia de avaliadores especialistas, que analisando as interfaces de um determinado sistema fazem o levantamento dos possveis problemas e sugerem solues. Posteriormente, os resultados da avaliao de cada avaliador so organizados em um nico relatrio, onde resultados iguais ou similares so agrupados e depois categorizados em funo da gravidade do problema. Segundo Nielsen (1993), trs a cinco avaliadores so suficientes para identificar a maior parte dos problemas. Cabe observar que a primeira etapa de anlise deve ser efetuada individualmente por cada avaliador para evitar que um influencie outros. A segunda etapa, no entanto, onde os envolvidos se renem para analisar e priorizar os problemas encontrados, deve ser um trabalho de equipe.

7.2.1.2 Inspees com listas de conferncia (Checklists)

A avaliao de usabilidade por inspeo com listas de conferncia realizada por meio de vistorias atravs das quais profissionais diagnosticam rapidamente problemas gerais e repetitivos das interfaces (Bastien & Scapin 2009) e (Cybis, Betiol, e Faust 2007). Esses profissionais podem ser programadores, analistas, ou especialistas em usabilidade. Nesse tipo de tcnica, a qualidade das listas determina as possibilidades de avaliao. A utilizao de listas de conferncia tem a vantagem de poder suprir a carncia de profissionais especializados na equipe avaliadora, considerando que as listas foram desenvolvidas por pessoal altamente capacitado. A utilizao de listas de conferncia geralmente produz resultados mais uniformes e abrangentes, em termos de identificao 135

de pequenos problemas, visto que os avaliadores so conduzidos no exame da interface por meio de uma lista de questes a responder sobre a usabilidade do produto. No entanto, importante considerar que a qualidade das listas influencia a qualidade do resultado final. A avaliao com listas de conferncia pode ser combinada com a avaliao heurstica para se alcanar as vantagens das duas abordagens. Neste caso, recomenda-se que a avaliao pelos especialistas seja feita primeiramente como na avaliao heurstica, em que os especialistas fazem sua avaliao livremente. Somente aps uma primeira avaliao mais livre, os especialistas utilizariam as listas de conferncia em uma segunda avaliao. O objetivo desta separao em duas avaliaes evitar que os avaliadores sejam dirigidos pelos ou se atenham somente aos itens que constem nas listas de conferncia.

7.2.2 AVALIAES EXPERIMENTAIS

As tcnicas experimentais, tambm chamadas de empricas, de avaliao de usabilidade contam com a participao direta dos usurios, utilizando-se de experimentos. Compreendem basicamente os testes com usurios atravs do monitoramento de sesses de uso do produto, ou prottipo, em considerao. Os teste de usabilidade com a participao dos usurios so consideradas as formas mais confiveis de avaliao e, geralmente, as mais indicadas (Hix & Hartson 1993). Isso por ser muito difcil modelar ou prever o comportamento do ser humano na utilizao de um produto de software. Dada a dificuldade de se prever o comportamento do ser humano, devido a sua enorme complexidade, a soluo mais confivel para se validar a qualidade de uma interface em termos de usabilidade envolve a experimentao e observao do usurio realmente utilizando o produto ou um prottipo do produto. Os testes empricos avaliam a interface de um determinado produto por meio da simulao de uso do produto com participantes que sejam representantes da populao dos usurios que utilizaro o sistema. Para a composio dos cenrios de realizao dos testes, so elaborados roteiros, cujo contedo baseado no perfil dos usurios e nas suas tarefas tpicas, que sero executados durante uma sesso de testes. Essas tarefas geralmente so aquelas j definidas na Especificao de requisitos de usabilidade.

136

Nesta tcnica, os representantes de usurios devem executar as tarefas que constam dos scripts em sesses que so gravadas e acompanhadas por avaliadores no papel de monitores. Os monitores, especialistas em usabilidade e avaliao, tm a responsabilidade de conduzir as sesses de avaliao e coletar dados quantitativos e qualitativos que so posteriormente submetidos anlise visando identificao de problemas e a indicao de solues. importante salientar que uma das limitaes apresentadas pelos testes relacionada representatividade da amostra testada. imprescindvel compor um grupo de usurios que incorpore, seno todas, pelo menos as principais caractersticas do pblico alvo do produto. Outro ponto importante relativo s condies de aplicao dos testes. Os testes no so situaes reais de uso do sistema e por mais transparentes que possam parecer podem causar constrangimentos aos usurios. Desta forma fundamental esclarecer que o alvo dos testes o produto e no o usurio participante. Alm disso, dever do monitor que conduz os testes manter um ambiente confortvel para que os participantes ajam com mais naturalidade.

7.2.3 PESQUISA DE OPINIO

As tcnicas de pesquisa de opinio so baseadas na aplicao de questionrios ou entrevistas com o usurio para avaliar o seu grau de satisfao em relao ao sistema e sua utilizao. A opinio do usurio ajuda a identificar problemas correntes do sistema em considerao. Esses problemas sero corrigidos ou serviro de referncia para algum tipo de anlise. Em termos de qualidade, a satisfao do usurio est estritamente ligada ao atendimento daquilo que ele julga importante em um produto. Os dados resultantes da anlise do questionrio ajudam na identificao das reais necessidades do usurio, a orientar as revises de projeto e a validar avaliaes analticas ou experimentais. Nesses casos, os avaliadores podem concentrar suas anlises nos pontos problemticos apontados pelo usurio.

137

A elaborao de questionrios de avaliao requer uma capacitao especfica para que sejam confiveis e, portanto, deve contar com a participao de especialistas nessa rea.

7.3 SUBPROCESSO DE AVALIAO DE USABILIDADE

Para ser eficaz e eficiente, a avaliao de usabilidade deve ser organizada dentro de uma metodologia bem definida. Diversas avaliaes de usabilidade, s vezes utilizando-se diferentes mtodos, podem ser executadas durante o ciclo de vida de desenvolvimento de um produto de software. Essas avaliaes podem ser feitas com prottipos ou com o produto final, dependendo do momento e dos objetivos. As avaliaes devem ser cuidadosamente especificadas, desenhadas e planejadas, antes de serem realizadas. Assim como nos testes funcionais, durante e aps a realizao das avaliaes de usabilidade, os resultados de cada avaliao devem ser analisados minuciosamente, comparando-se os resultados obtidos com as metas estabelecidas. No Praxis-u, a atividade de Avaliao de Usabilidade do fluxo de usabilidade, que se desdobra em um sub-fluxo, visa uma avaliao da qualidade da interao proporcionada pela interface usurio-computador. Um planejamento inicial da freqncia e tipo de avaliaes deve ser feito dentro da atividade de personalizao do processo para projetos especficos. Um planejamento detalhado de cada avaliao deve ser realizado dentro do cada ciclo de desenho ou associado a liberaes (verses parciais) do produto. O planejamento das avaliaes de usabilidade dever ser documentado em um documento prprio: dausw - Descrio de Avaliaes de Usabilidade. Um relatrio de cada avaliao tambm dever ser registrado em um relatrio denominado rausw Relatrio de Avaliaes de Usabilidade. As principais referncias utilizadas so: o processo de avaliao de produtos de software descritos na norma ISO/IEC 14598, o modelo de qualidade de software descrito na norma ISO/IEC 9126, considerando-se especificamente a usabilidade do produto, uma proposta de metodologia apresentada em (Cybis 2002) e o fluxo de testes de software descrito em (Padua, 2003). Outras referncias importantes so (Hix & Hartson 1993), (Nielsen 1993), (Rubin 1994).

138

7.3.1 VISO GERAL

O processo de avaliao de usabilidade constitudo de trs macro-atividades bem definidas para cada ciclo de avaliaes realizadas: preparao, realizao e anlise de dados resultantes. Apesar de envolver atividades bem diferentes, as etapas de preparao e realizao das avaliaes so semelhantes s atividades dos testes funcionais da engenharia de software (Padua, 2008). Durante a preparao, elaborado o plano e so desenhadas as especificaes de cada tipo de avaliao. Durante a realizao, as avaliaes so executadas, problemas de usabilidade so identificados e os dados coletados so registrados. Por fim, os dados so analisados: os defeitos encontrados so categorizados e avaliados com relao sua gravidade, solues so sugeridas e os relatrios de avaliao so redigidos. Se possvel, antes mesmo da liberao final dos relatrios, pode-se corrigir alguns defeitos encontrados, observando-se as solues sugeridas.

139

Figura 7-1 Diagrama de atividades do sub-fluxo de Avaliao de Usabilidade O subprocesso de avaliao aqui proposto, Figura 7-1, prescreve as seguintes atividades.

Planejamento: define as tcnicas de avaliao mais adequadas para serem usadas em cada avaliao de usabilidade no ciclo de vida de desenvolvimento do produto em 140

considerao. Para cada tcnica, identifica os objetivos, componentes ou unidades a avaliar, as sub-caractersticas de qualidade a serem observadas, a abordagem metodolgica a ser adotada na avaliao, critrios de completeza e sucesso, critrios de suspenso e retomada, artefatos e resultados esperados da avaliao, ferramentas e equipamentos, responsabilidades pelas avaliaes, agenda das avaliaes nas iteraes e identificao de riscos e contingncias. No documento de Descrio de Avaliao de Usabilidade do Software (dausw), o resultado dessa atividade apresentado nos planos especficos de cada tcnica de avaliao. Desenho: configura as tcnicas selecionadas para a avaliao. So detalhados os parmetros especficos das tcnicas utilizadas em cada avaliao especfica. Define o prottipo ou produto a ser avaliado e os recursos a serem utilizados - infraestrutura, participantes (avaliadores, especialistas, usurios). Define tambm os procedimentos para a realizao das avaliaes e o material para a realizao das avaliaes. Por exemplo, a definio de roteiros de tarefas e cenrios, o nmero de usurios a participar dos testes com usurios e o nmero de especialistas que iro realizar uma avaliao heurstica devem ser definidos nessa atividade. No dausw, os resultados dessa atividade so apresentados nas Especificaes que detalham as avaliaes. Implementao: prepara o ambiente para as avaliaes, incluindo a execuo de uma avaliao piloto, se prevista no mtodo escolhido. Execuo: executam-se as avaliaes seguindo as indicaes de cada tcnica e coleta os dados. Anlise dos dados: caracteriza os problemas, que so compilados, categorizados e priorizados; prope solues e elabora as recomendaes para a implementao de melhorias. Verificao do trmino: inspeciona as avaliaes, determinando se as condies para sua completeza e sucesso esto satisfeitas. Balano final: realiza o balano final das avaliaes de usabilidade, verificando se os requisitos esperados para a atividade foram efetivamente alcanados e registrando as concluses e lies aprendidas. A preparao, realizao e anlise de dados de cada avaliao correspondem a uma passada completa pelo sub-fluxo de avaliao de usabilidade. Para cada etapa (fase ou iterao) do projeto de desenvolvimento do produto, podem-se combinar vrias tcnicas 141

para testar o desenho ou a implementao da interface, da forma mais abrangente possvel, dentro das limitaes de recursos humanos e tcnicos, custos e prazos.

7.3.2

DETALHAMENTO DAS ATIVIDADES

O resultado das atividades de avaliao de usabilidade que se seguem documentado em dois artefatos (documentos): o dausw (Descrio de Avaliao de Usabilidade) e o rausw (Relatrio de Avaliao de Usabilidade) que apresentam, respectivamente, toda a documentao gerada antes da avaliao e os resultados das avaliaes relacionados com um projeto. Sendo assim, o dausw e o rausw so nicos para cada projeto e documentam todas as avaliaes realizadas em um projeto. O dausw dividido em duas macrossees: a seo de Planos e a seo de Especificaes. A relao entre um Plano e a respectiva Especificao para uma determinada tcnica de avaliao corresponde ao conceito de herana na metodologia O-O (Orientada a Objetos), isto , a Especificao de cada avaliao herda todas as definies feitas no respectivo Plano e eventualmente pode definir novos parmetros ou alterar os parmetros j definidos no plano, para uma avaliao especfica. Por exemplo, a definio de roteiros de tarefas, cenrios e nmero de usurios a participarem dos testes empricos pode ser realizada em nvel de Plano no dausw e valer para todas as avaliaes documentadas nas Especificaes. No entanto, estes parmetros tambm podem ser alterados em uma Especificao correspondente a uma avaliao especfica. A utilizao do conceito de herana com relao s Especificaes e aos Planos (em uma tcnica especfica de avaliao) permite que os parmetros de desenho comuns a diversas avaliaes sejam documentados somente no respectivo Plano. O subprocesso de Avaliao de usabilidade mostrado na Figura 7-1 utiliza os seguintes artefatos. pdsw: Plano de Desenvolvimento do Software, documento indicado no Praxis que descreve, de forma detalhada, os compromissos que o fornecedor assume em relao ao projeto, quanto a recursos, custos, prazos, riscos e outros aspectos gerenciais. pqsw: Plano da Qualidade do Software, documento do Praxis que descreve, de forma detalhada, os procedimentos de garantia da qualidade que sero adotados no projeto.

142

ersw: Especificao dos Requisitos do Software, documento do Praxis que descreve, de forma detalhada, o conjunto de requisitos especificados para um produto de software.

erusw: Especificao de Requisitos de Usabilidade, documento do Praxis-u que descreve, de forma detalhada, a anlise de contexto e os requisitos relacionados com a usabilidade.

ddsw: Descrio do Desenho do Software, documento do Praxis que descreve, de forma detalhada, os aspectos mais importantes do desenho do software.

ddisw: Descrio do Desenho da Interao do Software, documento do Praxis-u que descreve prottipos e aspectos mais importantes relacionados ao desenho da interao com o usurio.

dausw: Descrio das Avaliaes de Usabilidade, documento do raxis-u que descreve de forma detalhada o planejamento das avaliaes de usabilidade

rausw: Relatrio das Avaliaes de Usabilidade, relatrio do Praxis-u que descreve os resultados das avaliaes de usabilidade

mdsw: Modelo de Desenho do Software, modelo do Praxis que detalha a estrutura lgica e fsica do produto, em termos de seus componentes.

apusw: Modelo de Anlise de Problemas de Usabilidade, modelo do Praxis-u utilizado na anlise de problemas em avaliaes de usabilidade

riausw: Relatrio de Inspeo de Avaliao de Usabilidade, relatrio do Praxis-u que descreve se esto satisfeitas ou no as condies para o trmino de uma avaliao de usabilidade.

7.3.2.1 Planejamento
Como as avaliaes de usabilidade podem ocorrer em diversos momentos durante o desenvolvimento de um produto de software, a atividade de Planejamento pode ser realizada junto com o Planejamento do processo de usabilidade conforme prescrito no Praxis-u e, posteriormente, pode ser completada com elementos de novas avaliaes quando estas forem realizadas. O Planejamento da avaliao composto das atividades de Identificao inicial dos requisitos da avaliao, Identificao dos itens a testar e Identificao detalhada dos requisitos da avaliao. 143

Cabe observar que estamos falando de uma avaliao formativa, realizada dentro de um processo de desenvolvimento do software. Sendo assim, todo o contexto que envolve a avaliao j bem conhecido. Este no sendo o caso, por exemplo, em uma avaliao somativa, seria necessrio um trabalho anterior visando um bom conhecimento do produto e a determinao de objetivos, contexto e requisitos de usabilidade envolvidos na avaliao.

7.3.2.1.1 Identificao inicial dos requisitos da avaliao

Essa atividade realizada por meio de vrias tarefas que so apresentadas detalhadamente na Erro! Fonte de referncia no encontrada..
Descrio Insumos Identificao inicial dos requisitos da avaliao. 1 Especificao de Requisitos do Software (ERSw requisitos de interface) 2 Especificao de Requisitos de Usabilidade (ERUSw perfil do usurio, atributos e metas de usabilidade). 3 Descrio do Desenho da Interao do Software (DDISw) 4 Plano de Desenvolvimento de Software (PDSw).

5 Plano da Qualidade de Software (PQSw).

Tarefas 1 Levantar recursos existentes, identificando: pessoas (monitores de avaliao, especialistas, usurios, etc); hardware; software de sistema; ferramentas de teste; histrico de avaliaes anteriores; formulrios; suprimentos. 2 Escolher as tcnicas para as avaliaes, identificando: necessidades de estruturas provisrias; reas de riscos que devem ser avaliadas; fontes existentes de casos de testes de usabilidade; etapa do ciclo de vida do produto de software; cronogramas e avaliao de custo/benefcio;

requisitos de recursos existentes ou necessrios.

Resultados

1 Requisies de recursos para as avaliaes. 2 Seleo de tcnicas de avaliao de usabilidade. Tabela 7-1 Identificao inicial dos requisitos da avaliao

144

7.3.2.1.2 Identificao dos componentes a testar

Essa atividade realizada por meio de vrias tarefas que so apresentadas detalhadamente na Tabela 7-2.

Descrio Insumos

Identificao dos componentes a testar. 1 Especificao de requisitos de Software (ERS casos de uso e desenho das telas de usurios) 2 Plano de Desenvolvimento de Software (PDSw) 3 Descrio do Desenho de Software (DDS Desenho Arquitetnico e planos de liberao)

4 Descrio do Desenho da Interao do Software (DDISw)

Tarefas 1 Identificar: componentes a testar; atributos e metas de usabilidade dos componentes a testar (testes empricos); status (situao de prototipao ou de desenvolvimento no momento da avaliao) dos itens a testar, dentro do projeto;

caractersticas dos dados de entrada e sada (nos testes empricos isso

essencial para a descrio das tarefas) Resultados 1 Lista de componentes e aspectos a avaliar.

2 Eventuais pedidos de esclarecimentos aos projetistas de interface, relativos aos

componentes a testar.

Tabela 7-2 Identificao dos componentes a testar

7.3.2.1.3 Identificao detalhada dos requisitos da avaliao

As tarefas a serem realizadas nessa atividade so apresentadas detalhadamente na Tabela 7-3.

Descrio Insumos

Identificao detalhada dos requisitos da avaliao. 1 Lista de itens e aspectos a testar. 2 Informao geral da identificao inicial dos requisitos da avaliao.

Tarefas

1 Determinar: requisitos de recursos especficos dos componentes a testar; detalhes da abordagem; cronograma detalhado.

2 Especificar condies de completeza das avaliaes: 145

 itens a serem avaliados; grau de cobertura por itens. Resultados 1 Plano de teste completo.

Tabela 7-3: Identificao detalhada dos requisitos da avaliao

7.3.2.2 Desenho das avaliaes

Nesta atividade so definidas as Especificaes de avaliaes que detalham os procedimentos de avaliao. Os procedimentos de avaliao compreendem os protocolos que definem o formato das avaliaes, uma caracterizao dos usurios participantes e avaliadores e os roteiros de tarefas a serem executadas durante a realizao da avaliao. Cabe observar que, enquanto feito somente um Plano para cada tipo de tcnica, a Especificao associada a uma avaliao especfica, ou seja, pode ser feita uma Especificao para cada avaliao a ser realizada. Essa atividade realizada por meio de vrias tarefas que so apresentadas detalhadamente na Tabela 7-4.

Descrio Insumos

Desenho das avaliaes.

2 Especificao de requisitos de Software (ERSw especificao de requisitos de interface, perfil do usurio, atributos e metas de usabilidade). 3 Descrio da Avaliao de Usabilidade (dausw).

4 Descrio do Desenho da Interao do Software (DDISw).

Tarefas 1 Desenhar avaliaes, considerando: tipo de avaliao; objetivos gerais. 2 No desenho, estabelecer: objetivos especficos; reutilizao de especificaes de avaliaes anteriores (heursticas, tarefas do usurio); ordem de execuo se for um requisito do mtodo de avaliao escolhido.

3 Especificar os procedimentos de avaliao, tais como roteiros (scripts), papis e

responsabilidades, nmero de usurios, participao de especialistas, dentre outros. Resultados

1 Especificaes das avaliaes. Tabela 7-4: Tarefas de desenho das avaliaes

146

7.3.2.2.1 Especificao das avaliaes

As Especificaes das avaliaes so sees do dausw que contm um detalhamento das avaliaes a serem realizadas. A especificao compreende uma descrio dos procedimentos da avaliao e das responsabilidades dos atores envolvidos, na forma de uma seqncia de aes (roteiros). Esses roteiros devem ser observados e execuo das avaliaes para efeito de padronizao e rigor experimental. Os procedimentos so configurados dependendo do tipo de avaliao. O padro adotado para as especificaes de avaliaes, independentemente do tipo escolhido, prev a estrutura mostrada na Tabela 7-5. Os Recursos a serem utilizados e os Procedimentos de avaliao so detalhados em subsees a seguir.

Item

Descrio

Identificador da Identificador nico para esta avaliao. especificao da avaliao Especializao Planejamento do Pode ser usado para alterar qualquer parmetro do Planejamento para
uma avaliao especfica objeto do Desenho da interao. Alocao dos recursos humanos necessrios para a realizao desta avaliao. Agenda detalhada das avaliaes. Identificao e descrio de cada um dos procedimentos desta avaliao.

Recursos a serem utilizados Agenda detalhada Procedimentos da avaliao

Material para execuo da Descreve o material de suporte, como roteiros, listas de conferncias, etc, a ser utilizado nas avaliaes. avaliao Tabela 7-5: Especificao das avaliaes

7.3.2.2.2 Recursos a serem utilizados

Essa atividade consiste principalmente em especificar, em funo dos requisitos de recursos humanos determinados previamente, qual o perfil das pessoas que participaro da avaliao (planejamento, realizao, anlise e validao) e qual a quantidade necessria por perfil. Para os testes com usurios (experimentais), deve-se descrever o nmero total de participantes dos testes, o perodo de realizao dos testes, o nmero de sees de teste por dia, e como os participantes sero distribudos nestas sees, considerando-se critrios especficos em relao ao perfil, s verses do produto, aos custos e prazos. 147

Na avaliao heurstica, devem-se especificar quantos especialistas e monitores participaro da avaliao. A definio do nmero de especialistas depende de uma anlise de custo/benefcio, no entanto, a literatura (Nielsen, 1993) sobre o assunto recomenda de trs a cinco para identificar a maior parte dos problemas de usabilidade das interfaces, visto que o diagnstico baseado na experincia e competncia do especialista no assunto. Na inspeo por lista de conferncia, os prprios programadores e analistas podem fazer a avaliao. Como os inspetores so conduzidos no exame da interface atravs de uma mesma lista de questes sobre a usabilidade do projeto, os resultados tendem a ser uniforme. Entre trs e cinco inspetores tambm suficiente para detectar grande parte dos problemas.

7.3.2.2.3 Procedimentos da avaliao

Os procedimentos da avaliao devem descrever a seqncia de passos ou roteiros a serem executados ou observados pelos monitores de avaliao, especialistas em usabilidade, projetistas de interface e participantes de sesses de testes com usurios, dependendo do tipo de avaliao de usabilidade. DETALHAMENTO DOS PROCEDIMENTOS DA AVALIAO HEURSTICA Na avaliao heurstica, alm dos procedimentos a serem executados ou observados pelo monitor da avaliao, deve-se especificar tambm quais so os procedimentos para os especialistas em usabilidade Tabela 7-6 Tarefas Seleo de heursticas Elaborao de roteiros Descrio
Escolha e adaptao das heursticas ao contexto e tipo de produto a ser avaliado. Elaborao de roteiros para o monitor de avaliao, descrevendo os passos que devem ser seguidos e observados na conduo da avaliao e elaborao de roteiros para os especialistas de usabilidade, descrevendo objetivos, aspectos a serem avaliados e como a avaliao ser conduzida, em termos de cronograma, por exemplo.

Tabela 7-6: Procedimentos para avaliao heurstica

148

DESENHO DOS PROCEDIMENTOS DOS TESTES EXPERIMENTAIS Nos testes empricos, devem-se especificar quais procedimentos sero executados ou observados pelo monitor de teste e equipe, e quais tarefas os usurios devem realizar em cada sesso de teste. O padro adotado para descrio dos procedimentos apresentado na Tabela 7-7. Tarefa Definio dos aspectos gerais Descrio
Descrio sucinta dos objetivos que orientam o desenho do teste e de que forma este se dar (observao direta, por exemplo).

Levantamento das medidas de Descreve quais tipos de dados sero medidos na avaliao e como medi-los. Os dados podem ser de natureza quantitativa, que avaliao

correspondem a resultados numricos como medidas do desempenho do usurio ou avaliao de opinies por questionrio, ou qualitativos, i.e., resultados no numricos, como lista de problemas ocorridos durante o uso da interface pelo usurio. No caso de testes empricos, importante caracterizar bem os valores a serem medidos por exemplo, deve ficar bem claro o que ser considerado um erro de usabilidade na utilizao da interface pelo usurio. Este trabalho deve ser baseado naEspecificao de usabilidade j realizada, possivelmente aps uma reviso. Como o participante deve ser recepcionado e quais atividades ele deve fazer inicialmente. Apresentao das explicaes que devem ser dadas aos participantes, tais como: finalidade do teste, como ser o teste, o que o usurio poder ou no fazer.

Procedimentos para orientar os participantes

Recepo Explanaes sobre o teste

Elaborao das listas de Descreve as tarefas que sero realizadas pelos participantes dos testes. tarefas para os usurios Cada descrio de tarefa inclui o estado ou contexto onde iniciada, a descrio das aes a serem realizadas, os critrios de completeza e participantes.
sucesso e tempo mximo para execuo, dentre outros. Esta lista tambm chamada de Roteiro de tarefas para os usurios.

Elaborao de roteiros para os Elaborao de roteiros para o monitor de avaliao, descrevendo os passos que devem ser seguidos e observados na conduo da avaliao. monitores da avaliao
Cabe observar que a lista de tarefas para os usurios participantes tambm utilizada pelos monitores das avaliaes.

Etapas de execuo das tarefas Descrever os cenrios nos quais os participantes estaro sendo observados. Quais so as circunstncias, equipamentos e estados (cenrios)
destes, documentos usados, atitudes que o monitor ou equipe de testes devero ter.

Procedimentos ps-tarefas

O que deve ser feito aps o participante terminar a execuo do conjunto de tarefas elaboradas para obteno de dados. Quais aes o monitor de teste e equipe devem realizar.

Tabela 7-7: Descrio dos procedimentos para testes experimentais

149

DESENHO DOS PROCEDIMENTOS DAS AVALIAES COM LISTAS DE CONFERNCIA A avaliao com listas de conferncia semelhante avaliao heurstica Tabela 7-8. Tarefa Descrio

Definio e organizao do Definio da organizao e contedo geral ou especfico da lista de contedo da lista de conferncia a ser utilizada, ou escolha de alguma lista previamente validada. conferncia Elaborao dos scripts
Elaborao dos roteiros constando orientaes, atividades e a ordem destas, se for o caso, para os analistas ou projetistas da interface.

Tabela 7-8: Descrio dos procedimentos para listas de conferncia

7.3.2.3 Implementao da Avaliao

Nesta atividade preparado o ambiente para as avaliaes, compreendendo a instalao de prottipos ou verso de avaliao do produto, a disponibilizao da infra-estrutura necessria e a execuo de uma avaliao piloto, se prevista no mtodo escolhido, visando preveno de ocorrncias de problemas que poderiam vir a comprometer a realizao da avaliao posteriormente, Tabela 7-9.

Descrio Insumos

Implementao das avaliaes.

1 Plano das avaliaes. 2 Especificao das avaliaes. 3 Recursos para as avaliaes. 4 Itens a testar. 5 Ferramentas para execuo da avaliao. 6 Dados de atividades anteriores de avaliao se houver.

7 Estruturas provisrias ou permanentes de avaliaes se houver. Tarefas

1 Configurar ambiente das avaliaes. 2 Disponibilizar recursos necessrios. 3 Instalar itens a testar, ferramentas e estruturas provisrias.

4 Executar uma avaliao piloto, se a tcnica escolhida exigir tal atividade. Resultados
1 Itens a avaliar instalados e configurados.

2 Ferramentas e estruturas provisrias instaladas e configuradas. Tabela 7-9: Implementao da avaliao

150

7.3.2.4 Execuo da Avaliao

Essa atividade consiste na realizao da avaliao propriamente dita. Seguindo-se as indicaes de cada tcnica, coletam-se os dados e registram-se os problemas de usabilidade identificados, Tabela 7-10. O desenrolar de cada avaliao controlado e dirigido pelos monitores de teste que devem planejar com antecedncia como proceder nos casos de interrupes, retomadas e encerramento precoce da avaliao. Alm disso, as normas e os procedimentos descritos no plano de avaliao devem ser observados e seguidos. Se existir documentos anexos ao plano de avaliao, eles devem ser utilizados, em conformidade com o planejamento. Descrio Insumos Realizao das avaliaes.
1 Especificao das avaliaes. 2 Recursos para as avaliaes. 3 Itens a testar instalados e configurados. 4 Ferramentas e estruturas provisrias ou permanentes de avaliaes instaladas e configuradas.

5 Dados de atividades anteriores de avaliaes se houver. Tarefas

1 Executar as avaliaes. 2 Coletar e registrar os dados. 3 Analisar as falhas e tomar as providncias adequadas: em caso de falhas da prpria avaliao; em caso de defeitos de implementao dos prottipos ou produto final;

em caso de defeitos de desenho dos itens. Resultados

1 Coleo de dados das avaliaes. 2 Especificaes de avaliaes revisadas se for o caso.

3 Solicitao de investigao e correo de defeitos se for o caso. Tabela 7-10: Realizao da avaliao Na coleta de dados, dependendo do tipo de avaliao sendo realizado, cabe observar que diversos tipos de dados podem ser importantes e, portanto, devem ser registrados. Segundo sua natureza, os dados podem ser classificados em: Objetivo: representa medidas observadas, por exemplo, o desempenho do usurio enquanto usa a interface para realizar tarefas de benchmark. Subjetivo: representa opinies, de usurio ou de avaliadores, sobre usabilidade da interface.

151

Quantitativo: so dados e resultados numricos, como medidas do desempenho do usurio ou avaliao de opinies.

Qualitativo: dados e resultados no numricos, como lista de problemas ocorridos durante o uso da interface pelo usurio.

Normalmente, as pessoas associam avaliao objetiva com dados quantitativos e avaliao subjetiva com dados qualitativos. Porm, avaliaes subjetivas podem gerar dados quantitativos (com a utilizao de questionrios com notas para os quesitos colocados) e avaliaes objetivas podem gerar dados qualitativos (por exemplo, sugestes de melhorias a partir da observao).

7.3.2.5 Anlise de dados

A anlise de dados coletados durante uma avaliao de usabilidade visa anlise dos problemas levantados para priorizao da soluo e investimento em melhorias. Pode ser dividida em dois processos maiores, distintos pela abrangncia e resultado produzido, a saber: a anlise preliminar e a anlise detalhada como sugerido por Rubin e outros (2008). A Tabela 7-11 sumariza a atividade de anlise de dados. Na anlise preliminar, os problemas mais crticos so passados para os projetistas de interface antes da liberao final do relatrio, com o objetivo de fazer as devidas melhorias antes mesmo de a avaliao ser concluda. Pode-se entregar uma verso resumida do relatrio com a descrio dos problemas e solues iniciais propostas ou fazer solicitaes informais. A anlise detalhada mais exaustiva. Alm dos problemas e recomendaes apresentadas na anlise preliminar, atualizados se necessrio, outras anlises pormenorizadas e recomendaes devem ser implementadas e descritas no relatrio final. A durao da anlise detalhada pode levar de duas a quatro semanas aps a avaliao, dependendo da complexidade e tamanho dos produtos avaliados. Independentemente dos dois tipos de anlise, os passos seguidos geralmente so (Rubin et al. 2008): compilao e sumarizao dos dados; anlise detalhada; 152

desenvolvimento de solues; produo do relatrio de avaliao.

importante salientar que esses podem interagir entre si, no seguindo, portanto, uma ordem necessariamente linear. Descrio Insumos Tarefas Anlise de dados. 1 Coleo de dados resultantes da avaliao.
1 Compilao e sumarizao de dados. 2 Anlise detalhada. 3 Desenvolvimento de solues e recomendaes.

4 Produo do relatrio de avaliao. Resultados 1 Relatrio da avaliao. Tabela 7-11: Anlise dos dados da avaliao

7.3.2.5.1 Compilao e sumarizao dos dados

Compilar os dados significa organiz-los de acordo com padres pr-definidos para que a uniformizao propicie maior facilidade durante a anlise de resultados. importante utilizar durante a avaliao formulrios ou algum meio eletrnico padronizado que permitam uma ordenao com menor esforo do conjunto de dados levantados. No Praxisu recomendamos a planilha apusw. Durante a compilao, dados que so iguais devem ser registrados apenas uma vez, juntamente, se desejado, com o nmero de ocorrncias. aconselhvel organizar os dados ao final de cada sesso para se obter maior agilidade no processo e esclarecer eventuais dvidas que com o passar do tempo podem exigir maior esforo para serem esclarecidas devido a possveis dificuldades de se lembrar de situaes especficas. Uma vez que os dados coletados sejam organizados, sejam ao final do dia de trabalho ou quando todas as sesses de realizao das avaliaes forem concludas, o passo seguinte a classificao dos problemas encontrados segundo critrios especficos, tais como tipo de tarefa, tipo de usurio. Para a avaliao com listas de conferncia essa tarefa no precisa ser executada, visto que as questes normalmente j so categorizadas.

153

A tarefa subseqente a sumarizao ou criao de resumos dos dados organizados previamente. O objetivo generalizar os resultados para a populao de usurios ou verses de produtos. Por exemplo, pode-se optar por fazer uma distribuio de freqncia para os tipos de problemas encontrados, tais como obstculos e barreiras; ou um resumo especfico para cada grupo de usurios. Dependendo da tcnica de avaliao escolhida, essa tarefa pode ser opcional.

7.3.2.5.2 Anlise detalhada

A anlise de dados tem os seguintes objetivos: identificar a causa dos problemas levantados; analisar dados qualitativos e quantitativos; priorizar problemas.

IDENTIFICAR A CAUSA DOS PROBLEMAS LEVANTADOS

Para apontar as causas dos problemas pode ser til a identificao da fonte e do componente, ou combinao de componentes, responsveis. Compreendendo-se as causas dos problemas possvel propor recomendaes mais precisas e solues mais eficazes. A causa de um problema pode ser considerada tambm como uma heurstica ou diretriz no atendida.

ANALISAR DADOS QUALITATIVOS E QUANTITATIVOS

A anlise de dados qualitativos e quantitativos permite, utilizando-se inferncias estatsticas a partir dos dados sumarizados, definir com mais preciso a quantidade e quais tipos de problemas de usabilidade afetam determinados grupos de usurios ou verses do produto. Alm disso, auxilia na atribuio de severidade para um problema. Por exemplo, um problema que pode ocorrer para qualquer tipo de usurio do produto , normalmente, mais grave que outro que se verifica somente para alguns tipos de usurios. A severidade do problema pode ser determinada pela combinao de vrios fatores, incluindo-se a estrutura do problema, o tipo de tarefa em que ele se manifesta ou o tipo de usurio que ele afeta. A severidade pode ser quantificada por meio da seguinte escala (Nielsen 1993), Tabela 7-12:

154

Severidade 0 1 2 3

Descrio
Problema cosmtico (Irritante): no preciso corrigi-lo a menos que se tenha tempo extra no cronograma do projeto. Pequeno problema de usabilidade (Moderado): baixa prioridade para corrigi-lo. Grande problema de usabilidade (Severo): importante corrigi-lo, indica alta prioridade. Catstrofe de usabilidade (Inutilizado): imperativo corrigi-lo antes de ser liberado para uso. Altssima prioridade

Tabela 7-12: Escala de severidade de um problema Diversos fatores podem ser considerados para se determinar a Seriedade dos problemas encontrados. A freqncia com que um problema pode ocorrer influenciada por dois fatores: a porcentagem do total de usurios afetados pelo problema e a probabilidade que um usurio do grupo afetado experimentar o problema. A freqncia pode ser medida com base na seguinte escala (Rubin et al. 2008), Tabela 7-13.

Freqncia 0 1 2 3

Descrio
Ocorre em 10% ou menos de utilizao do produto. Ocorre de 11 a 50% do tempo de utilizao do produto. Ocorre de 51 a 89% do tempo de utilizao do produto. Ocorre em 90% ou mais do tempo de utilizao do produto.

Tabela 7-13: Escala para medir a freqncia de ocorrncia de um problema

Alm da freqncia de ocorrncia, outros fatores podem ser considerados na determinao da severidade de um problema de usabilidade identificado, seguem alguns exemplos. Impacto: ser fcil ou difcil para os usurios superar o problema? Persistncia: um problema que s ser experimentado uma vez (usurios conseguem super-lo uma vez que sabem sobre ele) ou ser problema toda vez que for encontrado?

155

Impacto de mercado: certos problemas de usabilidade podem ter um efeito devastador sobre a popularidade do produto, mesmo que sejam objetivamente fceis de superar.

No artefato apusw do Praxis-u, sugerimos que os quatro fatores: Frequencia, Impacto, Persistncia e Impacto de mercado sejam analisados e a cada um atribudo uma notade gravidade em uma escala de 0 a 3 conforme sugerido acima. Com base na avaliao desses quatro fatores, sugerimos que uma outra nota, tambm na escala de 0 a 3 conforme indicado na Tabela 7-12, seja atribuda Estimativa de seriedade considerada globalmente. Cabe ainda observar que a priorizao dos problemas encontrados um aspecto importante da avaliao de usabilidade e, portanto, deve refletir o julgamento de toda a equipe envolvida na avaliao. Seno assim, sugerimos que seja usado um esquema de votao, onde cada membro da equipe de avaliao d uma nota para a Estimativa de seriedade (cada um considerando os quatro fatores) e uma mdia dessas notas seja considerada como a nota final da Estimativa de seriedade a ser considerada.

PRIORIZAR PROBLEMAS

O conjunto de problemas levantados devem ser priorizados a fim de permitir que a equipe responsvel pelo desenho ou projeto da interface realize as melhorias em uma ordem definida com base na seriedade ou criticidade dos problemas. Alm disso, por questes de custos e prazos, pode-se definir a ordem das correes ou re-projeto a partir dos problemas prioritrios e minimizar o impacto negativo sobre o produto liberado. Os problemas podem ser priorizados considerando-se somente a severidade do problema ou a combinao desta e a probabilidade de ocorrncia, ou se for o caso, o consenso estabelecido pelos especialistas ou usurios em alguma reunio de brainstorming ou JAD. Tcnicas baseadas no uso de cartes ou fichas podem ser utilizadas (Constantine & Lockwood 1999) para a busca do consenso em trabalho de equipes.

7.3.2.5.3 Desenvolvimento de solues e recomendaes

Essa atividade consiste em converter as informaes obtidas na anlise de dados para aes e recomendaes a serem executadas e seguidas, respectivamente, pela equipe responsvel pelo projeto das interfaces. Para se obter bons resultados nessa atividade, 156

importante considerar os princpios do projeto centrado no usurio, as diretrizes ou normas para desenho de interface, bem como a forma como as pessoas lidam com a informao (processo cognitivo). Outro aspecto a ser considerado a interdisciplinaridade da equipe responsvel por essa tarefa. Profissionais da rea de comunicao, ergonomia e fatores humanos podem propor solues a partir de perspectivas diferentes e entrar em consenso sobre as alternativas apresentadas. Uma forma mais simples a prpria equipe de usabilidade juntamente com a equipe de desenho, buscar uma boa soluo. DIRETRIZES PARA ELABORAO DE SOLUES E RECOMENDAES Observar princpios do projeto centrado no usurio. Considerar normas, padres e diretrizes para desenho de interface de usurio. Procurar solues simples e eficazes. Focalizar primeiramente nas solues e recomendaes que causam maior impacto sobre o produto, por exemplo, uma mudana do estilo de navegao na maioria das telas da interface. Definir pequenas e grandes recomendaes: nas pequenas recomendaes se gasta menos tempo para realizar as mudanas, sem o risco de tropear no planejamento. J nas grandes recomendaes, as mudanas requerem mais tempo para serem realizadas. Definir quais so as reas que exigem pesquisa adicional para delimitar melhor o problema e propor solues mais coerentes.

7.3.2.5.4 Produo do relatrio de avaliao

A equipe responsvel pelo desenho da interface deve ter contato direto com os resultados, solues e recomendaes propostas. Para isso importante transcrever esses itens para um relatrio. Este deve ser confeccionado aps se promover discusses sobre as percepes, opinies e verificao de possveis falhas nas recomendaes. O relatrio final deve ser completo, constando todos os tipos de problemas identificados, crticos ou no. Os objetivos e revises tambm devem ser relatados. O relatrio final

157

deve suportar e iniciar mudanas, dirigir aes, prover um registro histrico, ter um papel educacional e ser um importante veculo de comunicao. A estrutura do relatrio, ou seja, as sees que o compem so descritas em padres de avaliao de usabilidade. Em linhas gerais, o incio do relatrio descreve a motivao para a avaliao e como foi preparado, o meio descreve o que aconteceu durante a avaliao e o fim relata as recomendaes e sugestes propostas.

7.3.2.6 Verificao do Trmino

Essa atividade determina se as condies para completeza e sucesso das avaliaes esto satisfeitas. Se for necessrio para garantir a cobertura desejada, avaliaes suplementares podem ser desenhadas, retornando-se atividade de desenho da avaliao. Descrio Insumos Verificao do trmino da avaliao.
1 Plano das avaliaes. 2 Especificao da avaliao. 3 Relatrio da avaliao.

Tarefas

1 Checar trmino normal das avaliaes: verificar se h necessidade de mais testes; se no houver, registrar o trmino normal. 2 Checar trmino anormal das avaliaes, documentando o ocorrido. 3 Suplementar o conjunto de avaliaes, se necessrio. 4 Retornar execuo das avaliaes, se necessrio.

Resultados 1 Relatrio verificado e completado. 2 Especificao de avaliaes revisadas se for o caso. Tabela 7-14: Verificao do trmino da avaliao

7.3.2.7 Balano Final

Essa atividade realiza o balano final das avaliaes de usabilidade, verificando se os requisitos esperados para a atividade foram efetivamente alcanados e registrando as concluses e lies aprendidas. Deve-se tambm ser feita uma aferio da qualidade da interao proporcionada pela interface atravs de uma comparao dos resultados obtidos com as metas ou requisitos de usabilidade pr-definidos. Se necessrio, pode ser proposto uma realizao de um novo ciclo completo do fluxo de usabilidade visando melhoria da qualidade da interface.

158

Descrio Insumos

Balano final
1 Relatrio da avaliao verificado. 2 Especificao da avaliao revisada se for o caso.

3 Dados sumarizados da avaliao revisados se for o caso. Tarefas

1 Aferir a qualidade da interao com relao aos requisitos ou metas estabelecidos. 2 Descrever o status da avaliao, registrando: variaes; avaliao dos trminos anormais da avaliao; problemas no-resolvidos. 3 Descrever o status das unidades sob avaliao. 4 Completar o relatrio da avaliao.

5 Colocar os artefatos reutilizveis sob Gesto de Configurao. Resultados 1 Relatrio de resumo das avaliaes.
2 Possivelmente, componentes de avaliao reutilizveis.

Tabela 7-15: Balano final da avaliao

7.4 PADRO DE DESCRIO DE AVALIAO DE USABILIDADE

A documentao das avaliaes de usabilidade consiste em dois documentos: Descrio das Avaliaes de Usabilidade do Software (dausw): documenta o planejamento, executado antes da realizao das avaliaes, abrangendo os planos e especificaes. Relatrio das Avaliaes de Usabilidade do Software (rausw): rene todos os relatrios de avaliao produzidos em um projeto. A confeco da Descrio das Avaliaes de Usabilidade e dos Relatrios das Avaliaes de Usabilidade deve seguir as diretrizes que so apresentadas nas prximas sees.

7.4.1 DESCRIO DAS AVALIAES DE USABILIDADE

O documento dausw subdividido em duas partes, uma referente aos planos de avaliao e a outra referente s especificaes das avaliaes. 159

Cada plano de avaliao de usabilidade registra os aspectos relativos ao planejamento de uma avaliao de usabilidade utilizando-se uma tcnica especfica. Cada especificao da avaliao define o desenho de uma avaliao. O documento de Descrio das Avaliaes de Usabilidade do Software dever utilizar a seguinte estrutura: 1. Planos de avaliaes 1.1. Plano de avaliaes heursticas 1.2. Plano de testes de usabilidade 1.3. Plano de avaliaes com listas de conferncia 2. Especificaes de avaliaes

7.4.2 RELATRIO DE AVALIAES DE USABILIDADE

Os vrios Relatrios das Avaliaes de Usabilidade do Software registram os dados relativos s realizaes das avaliaes e as recomendaes desenvolvidas baseadas nos acontecimentos. A seguir apresentada uma sugesto para a organizao de relatrios: 1. Relatrios de Avaliaes Heursticas 1.1. Relatrios de Avaliaes Heursticas do mdulo A 1.2. Relatrios de Avaliaes Heursticas do mdulo B 1.3. ... 2. Relatrios de Avaliaes com Listas de Conferncia 2.1. Relatrios de Avaliaes com Listas de Conferncia do mdulo B 2.2. Relatrios de Avaliaes com Listas de Conferncia do mdulo C 2.3. ... 3. Relatrios de Testes Empricos 3.1. Relatrios de Testes Empricos do mdulo B 3.2. Relatrios de Testes Empricos do mdulo C 3.3. ...

7.5 GLOSSRIO
Sem contedo

7.6 BIBLIOGRAFIA
160

Bastien & Scapin, links Critrios Ergonmicos e ErgoList em pgina de sito web acessado em http://www.labiutil.inf.ufsc.br/ em outubro 2009. Cybis, W. Betiol, A. H. Faust, R. Ergonomia e Usabilidade Conhecimentos, Mtodos e

Aplicaes, Novatec, 2007

Constantine, L.L. & Lockwood, L.A.D. Software for Use: a Practical Guide to the Models

and Methods of Usage Centered Design, Addison-Wesley, Reading-MA, 1999.

Hix, D.; Hartson, H. R. Developing User Interfaces: ensuring usability through product &

process, John Wiley and Sons, 1993.

ISO/IEC 14598-2 Software Product evaluation, 1999. ISO/IEC 9126 Information technology software product quality- part 1: quality model 1999, (FDIS). Nielsen, J. Usability Engineering. Chestnut Hill, MA, Academic Press, 1993. PADUA, W. Engenharia de Software: Fundamentos, Mtodos e Padres. 2. ed. Rio de Janeiro: Editora LTC, 2003. v. 1. 604 p. Rubin, J. Chisnell, D. Spool, J. Handbook of Usability Testing: how to plan, design, and

conduct effective tests, John Wiley and Sons, 2nd edition, 2008.

8 DIRETRIZES DE USABILIDADE
Neste captulo apresentamos de forma sucinta uma compilao de diretrizes para o desenvolvimento da interao. Esse tipo de diretriz em geral pode ser encontrado em livros e artigos sobre usabilidade. As diretrizes enfatizam a atividade de desenho da interao, mas no se limitam a essas. As diretrizes que se seguem esto organizadas em trs nveis, fundamentos, princpios e diretivas, de acordo com o nvel de abstrao que abordam. As diretrizes so de vrias fontes como Constantine e Lockwood (1999) e Hix (1993).

161

8.1 FUNDAMENTOS DE DESENHO

Apresentamos aspectos de fundamentos relacionados ao desenho de interfaces do usurio, colocados em nvel mais alto de abstrao. 1. Apoio: o sistema deve apoiar as atividades ou tarefas reais que os usurios precisam executar, tornando-as mais fcil, simples, rpido ou mais divertido ou tornando coisas novas possveis. O sistema deve, de alguma forma, contribuir e agregar valor s atividades realizadas pelos usurios. 2. Acesso: o sistema deve ser acessvel sem help ou documentao para o usurio que tem conhecimento do domnio da aplicao. Ou seja, a no ser por motivo de falta de conhecimento do domnio, o usurio no deve ter dificuldades em utilizar um sistema. 3. Progresso: o sistema deve facilitar o avano contnuo em conhecimento e habilidade, e acomodar mudanas progressivas medida que o usurio ganha experincia com seu uso. O sistema deve acompanhar a evoluo do usurio, atendendo s necessidades que vo surgindo medida que o usurio ganha domnio sobre o uso do sistema. 4. Consistncia: consistncia est associada ao uso de padres. Diversos tipos de consistncia devem ser observados no desenho da interao. Conforme mencionado no texto referente a Guia de Estilos, consistncia sempre importante para propiciar a boa qualidade da interao. 5. Contexto: o sistema deve ser adequado para as condies reais e presentes no contexto operacional onde o sistema utilizado. O desenho da interface do sistema deve levar em conta o ambiente fsico, social e cultural em que vai ser utilizado. 6. Eficincia: o sistema no deve interferir (ou impedir) no uso eficiente por usurios habilidosos e com experincia no sistema. Ou seja, o sistema deve prover mecanismos como atalhos ou comandos mais poderosos que permitam maior desempenho aos usurios experientes.

162

8.2 PRINCPIOS
No segundo nvel de abstrao esto as princpios de desenho de interface do usurio ndo enho usurio. Vrios deles esto relacionados aos princpios bsicos de design de modo geral, j apresentados no captulo 2 deste documento. 1. Informao: a disponibilizao adequada de informao na interface reduz a necessidade de memorizao do usurio. Ao invs de ter que memorizar as diversas opes disponveis, o usurio necessita apenas escolher dentre as opes que lhes so oferecidas. Como mencionado na seo 2.2, a colocao adequada de informao na interface reduz a necessidade de memorizao do usurio. Figuras e cones quando significativas podem levar muita informao aos usurios de maneira direta.

Figura 8-1 Informao sobre funes disponveis.

2. Estrutura: organize a interface de modo que seja til e faa sentido, consistente com : modelos mentais dos usurios, colocando coisas relacionadas juntas e separando coisas no relacionadas, diferenciando coisas diferentes e fazendo coisas semelhantes lembrar uma s outras. A estrutura de uma interface deve fazer sentido para os usurios, deve estar consistente com seus modelos mentais, no necessariamente va refletir a viso vai dos desenvolvedores.

163

Figura 8-2 Imagem de uma estrutura confusa para o usurio. 3. Visibilidade: mantenha visveis as opes necessrias para a realizao de uma tarefa, sem distrair o usurio com informao redundante e fora de contexto. As ferramentas e materiais devem estar disponveis onde e quando forem necessrias, todas as opes devem ser explcitas e aparentes ao usurio.

Figura 8-3 Permita que usurio identifique facilmente as ferramentas disponveis.

4. Realimentao (Feedback):

mantenha os usurios informados de aes e

interpretaes, mudanas de estado ou condio, erros ou excees que sejam de seu interesse , atravs de uma linguagem clara, concisa, no ambgua e familiar ao usurio. O estado do sistema uma informao importante para o usurio se situar na interao. Em muitas situaes, o feedback sutil, eficiente mas sem chamar a ateno, no intrusivo, recomendado. Um bom exemplo disso um cursor de mouse que assume diferentes formas dependendo do elemento da interface que est sendo apontado.

164

5. Modelo mental: garanta que o usurio forme um modelo mental compatvel com o modelo real. Isso pode ser conseguido por um desenho adequado da interface ou at mesmo por meio de treinamentos.

Figura 8-5 Modelos Mentais so utilizados pelas pessoas para compreender o mundo. 6. Simplicidade: faa que tarefas simples e comuns possam ser realizadas de forma simples, comunicando de forma clara e objetiva na linguagem do usurio.

Figura 8-6 Ferramenta de seleo do PAINT, simples, mas eficiente. 7. Tolerncia: seja flexvel e tolerante, reduzindo os custos de erros e mau uso atravs da disponibilizao de desfazer (undos) e refazer ( redos), prevenindo erros, tolerando uma variedade de entradas e seqncias e interpretando todas aes razoveis de uma maneira razovel. O sistema deve ser flexvel, para, quando possvel, buscar a interao com o usurio de forma razovel.

165

Figura 8-7 Exemplos de Tolerncia no adequada. 8. Reuso: reuse objetos e comportamentos internos e externos, mantendo consistncia ao invs de faz-la arbitrariamente, desse modo reduzindo a necessidade do usurio pensar e ter que se lembrar. A reutilizao ajuda no s os usurios como tambm os programadores, porem a reutilizao deve ser racional e utilizar consistncias solues bem elaboradas como fonte do reuso.

Figura 8-8 Um bom exemplo de reutilizao; mantido em diversas verses de programas.

166

8.3 DIRETRIZES
Em terceiro nvel de abstrao, seguem algumas diretrizes de usabilidade.
1. Cuidado com diretrizes:

As diretrizes podem at ser conflitantes, por exemplo, uma diretriz pode indicar que se deve dar ao controle ao usurio, deix-lo fazer o que desejar. Isso pode ir de encontro a outra diretriz que prescreve que se deve prevenir erros dos usurios. Nesses casos, avaliando a situao especfica, com bom senso, pode-se decidir sobre qual diretriz seguir. Seguem dois exemplos dessa situao. Apresentao e remoo de mensagens na tela: deve-se manter sob o controle do usurio ou fazer a mensagem desaparecer aps um tempo (em nome da celeridade ou facilidade para o usurio)? Se no houver risco de dano, pode-se utilizar remoo automtica, mas com tempo de exibio apropriado. Havendo risco de danos, deve-se requerer ao do usurio para remoo da mensagem. Exemplo de caixa de mensagens com os botes Help, Cancel e OK. Qual seria a opo default, aquela que o sistema utilizaria em resposta a um Enter, por exemplo? Poderia ser o mais utilizado, ex. OK, ou o mais seguro, ex. Cancel.

Figura 8-10 Exemplo onde o boto Sim tido como padro resposta a um Enter do usurio. 2. Desenho centrado no usurio: Nem sempre o que bom para o desenvolvedor bom para o usurio. Conhea o usurio final da aplicao. importante conhecer seu o comportamento relacionando estas caractersticas com aspectos do sistema a ser desenvolvido.

167

Figura 8-11 Usurios e desenvolvedores apresentam vises diferentes do sistema. 3. Envolva o usurio: No desenvolvimento participativo, a participao do usurio desde o incio recomendvel, pois o conhecimento e o comprometimento do usurio so importantes. Saiba escolher bem o usurio e identificar juntamente com ele suas necessidades.

Figura 8-12 Muitas organizaes j adotam a idia do desenvolvimento participativo com o usurio. 4. Mantenha o usurio no controle da situao: O Usurio deve poder fazer o que julgar necessrio, a menos que haja uma situao de risco ou de dano, que lhe deve ser comunicado. O sistema deve ser previsvel e as mensagens devem ser consistentes. Cuidado com o decurso de prazo: aquelas mensagens indicando aes que so efetivadas se o usurio no se manifesta dentro de certo tempo.

168

Figura 8-13 Deixe o usurio exercer controle da situao. 5. Previna erros do usurio: Em situaes de risco de dano resultante da ao do usurio importante antecipar as suas reaes evitando a gerao de erros. Torne indisponveis funes no pertinentes ao sistema e pea confirmao de aes de riscos.

Figura 8-14 Exemplo de solicitao de confirmao aos usurios. 6. Invista tempo em desenho: Se por um lado buscamos produzir prottipos e test-los o mais rapidamente possvel, o tempo investido em melhorar um desenho representa economia de tempo em interao com o usurio. Alm disso, a avaliao de um desenho mal elaborado com o usurio, de maneira intempestiva, pode levar ao descrdito em relao ao produto em desenvolvimento. A produo do prottipo ou de solues de desenho no deve ser feita de maneira aodada.

169

Figura 8-15 um bom desenho requer dedicao 7. Aperfeioe as operaes do usurio: Permita o uso de atalhos e imponha processos otimizados via seqncias de aes aos usurios do sistema. Isso facilita e aumenta o aprendizado por parte dos usurios.

Figura 8-16 Use teclas de atalho, aumentando a eficincia por parte dos usurios. 8. Ajude o usurio a iniciar-se no sistema: Considere as necessidades do usurio novio em relao ao sistema que ele ou ela estaro aprendendo a utilizar. Por exemplo, use demonstraes de como utilizar o sistema; isso facilita o aprendizado por parte de usurios inexperientes. Podemos tambm utilizar tutoriais e um modo de ajuda bem claro e consistente. Lembrem-se que tudo deve ser bem claro, pois muito formalismo pode confundir os usurios.

170

Figura 8-17 Auxilie o usurio na iniciao ao uso do sistema. 9. Considere limitao humana de memria: Muitos sistemas apresentam inmeras opes de funcionalidade e operaes, no interessante fazer com que o usurio saiba todas de cor. Utilize listas de opes, de modo que o sistema auxilie na sua memorizao e utilizao. O uso de fechamentos tambm facilita a controle da realizao de uma tarefa pelos usurios. Fechamento uma tcnica que consiste em se dividir uma tarefa complexa em subtarefas e indicar claramente a concluso de cada subtarefa para que usurio se situe mais facilmente com relao ao estado do sistema.

Figura 8-18 Facilite a memorizao por parte dos usurios. 10. Considere questes de cognio: Considere questes de cognio, isto , questes relacionadas ao conjunto dos processos mentais usados no pensamento humano, por exemplo, a memorizao, a percepo, a classificao e o reconhecimento. Use pistas cognitivas, por exemplo, ctrl + C para copiar.

171

Tente usar analogias com mundo real, com cuidado porque pessoas diferentes podem entender de maneira diferente as analogias utilizadas.

Figura 8-19 Exemplo de analogia com o mundo real, Firewall -> Proteo. 11. Use realimentao informativa: Na interao com uma interface o usurio tem a necessidade de uma realimentao (feedback) constante sobre o que est sendo realizado para que este possa fazer uma avaliao de suas aes. Esse princpio foi apresentado na seo 2.7 acima. Podemos considerar dois tipos de realimentao, a articulatria e a semntica. A realimentao articulatria refere-se ao mapeamento de movimentos ou posicionamentos associados s aes dos usurios. A realimentao semntica aquela em que se informa ao usurio sobre os efeitos de suas aes em termos semnticos, para que este possa avaliar se seus objetivos na interao foram atingidos.

Figura 8-20 Exemplo de realimentao articulatria

172

Figura 8-20 Exemplo de realimentao semntica 12. Use indicadores de progresso apropriados: Aes simples realizadas pelo usurio na utilizao de um sistema normalmente no requerem indicadores de progresso. As pessoas tm um entendimento, que subjetivo e baseada em suas experincias, de quanto tempo ser necessrio para a realizao de aes na interao com um sistema. Tipicamente, para aes que um usurio considere simples, o tempo de resposta tolerado pelos est em torno de: 50 a 150 ms para clicks, 1 segundo para tarefas simples e freqentes, E at 12 segundos para tarefas complexas.

Esse valores foram obtidos em experimentos e refletem a expectativa dos usurios em relao ao tempo em que suas aes sero processada pelo sistema que est utilizando. Em tarefas mais complexas, com durao de mais de 2 a 4 segundos, interessante a utilizao de indicadores de progresso. Os indicadores de progresso distraem os usurios e ajudam na reduo do tempo por eles percebido, dando-lhes uma estimativa do tempo que a operao ir demorar. A partir de um indicador de progresso, o usurio forma uma expectativa de quanto falta para o trmino da execuo de uma tarefa. Sendo assim, importante que o indicador de progresso d uma noo realista do tempo que ainda falta para a realizao de uma tarefa para que suas expectativas no sejam frustradas.

173

Figura 8-21 Indicador de progresso criando expectativa adequada para o usurio.

13. Use mensagens apropriadas: Use mensagens centradas no usurio e nas tarefas e que possam ser entendidas com facilidade. Tente utilizar mensagens positivas, nunca ameaadoras, principalmente mensagens como erro fatal, execuo abortada. Evite ser espirituoso. Claro que, dependendo do contexto e do tipo de produto, o humor pode ajudar na interao. Procure usar termos especficos apropriados: por exemplo, ao invs de dado ilegal use dado fora do limite permitido de 0 a 99. Ponha a culpa de erros no sistema: por exemplo, ao invs de comando ilegal use o sistema no reconhece este comando. So coisas sutis, mas que fazem a diferena.

Figura 8-22 Mensagem de erro que no compreendida pelos usurios. 14. Cuidado com antropomorfismo: Antropomorfismo a aplicao, em algum domnio, em nossa caso na interface do usurio, de linguagem ou de conceitos prprios do homem ou do seu comportamento. Dependendo do contexto, um bom dia ou obrigado pode ser interessante, mas, no fundo, todos 174

sabem que o computador no gente nem amigo da gente! Sendo assim, o antropomorfismo s deve ser usado com cautela.

Figura 8-23 Cuidado ao tentar colocar sentimentos em sistemas computacionais.

15. Use dilogos modais com cuidado: A utilizao de elementos modais em sistemas computacionais exige ateno e impedem outras aes do usurio at que alguma tarefa seja completada. Sua utilizao deve ser feita quando realmente necessrio, j que tira do usurio, de certa forma, o controle das aes do sistema.

Figura 8-24 Exemplo da utilizao de uma tela modal.

16. Permita o usurio reverter aes facilmente: O mecanismo de UNDO e REDO (fazer e desfazer) proporciona vrios benefcios para a interao dos usurios: permitem a recuperao em caso de erros ou falhas causadas por uma ao indesejada executada distraidamente; representa comodidade, facilitando a recuperao de erros;

175

prov uma ferramenta que pode ser usada para experimentao, proporcionando segurana para o usurio. Por exemplo, em uma planilha, permite ao usurio testar cenrios do tipo e se eu fizer tal coisa....

Claro que sempre o custo e benefcio devem ser avaliados, mas sempre que vivel deve-se implementar funes de UNDO e REDO nos sistemas.

Figura 8-25 Os botes undo/redo melhora o desempenho dos usurios em suas operaes. 17. Prudncia ao exigir a ateno do usurio: Lembre que o sistema deve ser claro mas cauteloso em relao a chamar a ateno dos usurios. Evite pisca-pisca e alertas sonoros; cuidado com negritos e sublinhados. Isso pode confundir o usurio e tirar seu foco na realizao de suas atividades. Evite utilizar caixas altas para chamar a ateno dos usurios, elas aumentam o tempo de leitura em at 10%. Cuidado tambm com o uso de cores, especialmente com seu significado em uma dada cultura e contexto.

Figura 8-26 Cores fortes e fora do contexto podem tirar o foco dos usurios.

176

18. Uso apropriado de telas: A disposio de telas em um sistema computacional muito importante. Tente manter a inrcia de telas, reduzindo mudanas drsticas entre telas que so apresentadas em sequncia aos usurios. Siga padres associados a telas. Alm disso, a posio de objetos usados internamente deve ser consistente entre telas. Evite telas muito carregadas, pois a produtividade de leitura cai muito quando se usa menos de 25% de espao branco; 50% seria recomendado para tela mais textuais. Organize telas para gerenciar a complexidade. Observa-se ganhos de at 40% em produtividade do usurio uma tela. conseguido com uma melhor organizao da informao em

Figura 8-27 Evite utilizar varias pginas para representar dados diferentes ao mesmo tempo. 19. Considere diferenas de usurios: Permita personalizao, que deve manter-se mesmo entre sesses de uso. Sistemas computacionais podem apresentar tipos diferentes de usurios, podemos destacar, entre eles, usurios novios, intermitentes e frequentes.

177

Figura 8-28 O sistema pode ser utilizado por diversos tipos de usurios.

preciso considerar o conhecimento sinttico e o conhecimento semntico necessrios realizao de uma tarefa pelos usurios.O conhecimento sinttico relativo estrutura e organizao dos elementos de um interface; o conhecimento semntico relativo ao entendimento do significado desses elementos. Usurios novios tm desconhecimento sinttico e semntico do sistema. Eles necessitam de clareza, simplicidade, pequeno nmero de funes mais teis (facilitando a memorizao), mensagens claras, feedback informativo e manuais completos, tutoriais e demonstraes. J os usurios intermitentes possuem um conhecimento semntico, mas perdem mais facilmente o conhecimento sinttico. Suas principais necessidades so em relao a comandos simples e consistentes, seqncia lgica de passos, funes fceis de se lembrar, assistncia e help on-line e manuais concisos. Por outro lado, os usurios freqentes tm um bom conhecimento sinttico e semntico. Para um uso eficiente do sistema eles necessitem de uma interao rpida, comandos poderosos, digitao reduzida, mensagens breves com acesso a detalhes s se necessrio, feedback conciso e uma possibilidade de personalizao da interface.

8.4 GLOSSRIO
Sem contedo

178

8.5 BIBLIOGRAFIA
Hix, D.; Hartson, H. R. Developing User Interfaces: ensuring usability through product &

process, John Wiley and Sons, 1993.

Constantine, L.L. & Lockwood, L.A.D. Software for Use: a Practical Guide to the Models

and Methods of Usage Centered Design, Addison-Wesley, Reading-MA, 1999.

9 ELEMENTOS DE INTERAO
Neste captulo apresentamos de forma geral e sucinta elementos de interao usados em interfaces do usurio. Podemos definir elementos de interao como colees de objetos de interface, linguagens de comando e tcnicas associadas, os quais podem ser utilizados para desenhar os componentes de interao de uma interface de um software. As diversas formas de interao podem ser classificadas de acordo com o tipo de elementos de linguagem utilizados, como de manipulao direta (com objetos) e linguagens de comando. A maioria dos estilos de interao discutidos neste captulo usada em interfaces de manipulao direta. Neste tipo de interface, o usurio executa as aes desejadas atravs de interao imediata com os objetos de interao, ao invs de descrever as aes a serem executadas, indiretamente. O objetivo das interfaces com manipulao direta minimizar os possveis erros do usurio e aumentar o sentimento de primeira pessoa (Hutchins et al., 1986). J na interao por meio de linguagens de comandos, como o nome indica, a interface disponibiliza comandos, geralmente apresentados em forma textual, que so utilizados pelos usurios para comandar a execuo de funes do sistema. Na literatura podem ser encontradas descries e anlises de diversos tipos de elementos de interao. Os elementos de interao aqui apresentados so baseados principalmente nos trabalhos de Hartson e Hix (1993). Cada estilo de interao apresentado independentemente de uma plataforma especfica de hardware ou software. Os elementos de interao mais utilizados e disseminados so as interfaces grficas, as interfaces 179

grficas em sentido amplo e as linguagens de comando. Estes elementos so apresentados nas prximas sees.

9.1 INTERFACES GRFICAS

Interfaces grficas podem ser definidas como qualquer estilo de interao que proveja janelas, botes, cones, e outros. geralmente chamada de interface grfica do usurio, ou GUI (Graphical User Interface), utilizada em um estilo de manipulao direta de objetos. O principal objetivo dessas interfaces permitir a interao com a utilizao de elementos grficos como cones e outros indicadores visuais. Essa interao feita geralmente atravs de um mouse ou um teclado, com os quais o usurio capaz de selecionar smbolos e manipul-los de forma a obter algum resultado prtico. Assim como existem vrios tipos de pessoas e gostos, existem tambm interfaces grficas que vo ser mais ou menos apreciadas de acordo com o gosto pessoal. No entanto, a deciso sobre qual tipo de elemento de interao a ser utilizado vai depender muito das caractersticas do tipo de tarefa a ser executada. Cada interface grfica possui um modo particular de utilizao e de gerncia de sua aparncia; as principais formas de interfaces grficas podem ser sub-divididas em: Janelas (windows) Menus Formulrios (Forms) Caixas (Box)

9.1.1 JANELAS (WINDOWS)

As janelas (windows) podem ser considerados objetos de tela que fornecem uma arena para apresentao e interao com outros objetos de interao. Basicamente elas posem ser classificadas como janelas primrias e janelas secundrias. A janela primria a janela inicial do sistema; dela que podemos acessar ou gerar as demais janelas. Uma janela secundria originada da janela primria ou de outras janelas secundrias. 180

Caixas de dilogo ou at mesmo caixas de mensagens do sistema podem ser consideradas como janelas secundrias. Quando vrias janelas so abertas na tela simultaneamente, apenas uma fica ativa, isto , pode aceitar entradas do usurio. Esta ativao geralmente feita colocando-se o ponteiro do mouse em qualquer posio na janela.

As janelas podem ser movidas horizontalmente e verticalmente pela rea de trabalho, de acordo com o gosto do usurio. Outra propriedade importante o tamanho, que pode ser redimensionado horizontalmente, verticalmente ou em ambos os sentidos. Outra propriedade das janelas a modalidade. Uma janela modal requer foco do usurio enquanto estiver aberta, o utilizador deve necessariamente interagir com ela a fim de fech-la, para ento voltar a usar o sistema. Um exemplo um editor de texto, que geralmente abre uma janela modal para confirmar o salvamento de um arquivo aberto. Enquanto a confirmao no respondida, a janela do documento aberto no pode ser fechada.

Para a utilizao de janelas alguns cuidados devem ser tomados. No conveniente o uso de muitas janelas, isso pode confundir o usurio. A organizao e a ordem das janelas devem ser importantes, faa com que a seqncia seja feita de forma lgica facilitando os usurios em suas tarefas. Todas as janelas devem seguir um padro, como tamanho, cores, ttulos entre outras caractersticas. Evite utilizar a mesma janela para atividades diferentes, como por exemplo, a mesma janela lista os funcionrios e seus relatrios de venda. Faa a distino de cada janela em referncia a sua funcionalidade especfica.

9.1.2 MENUS (MENU)

Menus podem ser considerados lista de itens na qual uma ou mais selees podem ser feitas pelo usurio. um dos mais populares estilos de interao, pois reduz a necessidade de memorizaes pelos usurios. O usurio simplesmente seleciona itens de uma lista diretamente, sem necessidade de memorizao desses itens, reduzindo o nmero de erros possveis. Entretanto, usurios experientes geralmente acham lenta a operao de ativao/desativao de menus. preciso tambm considerar o espao na tela requerido pelos menus.

181

A funo bsica de qualquer menu oferecer escolhas ao usurio. Existem vrias formas de menus, como por exemplo, menus push-buttons, menus pull-down, menus radiobutton, menus check-button, menus dinmicos, menus pop-up, menu de opo (Combobox), menus de alternativa (toggle menu), menus de cascata, menus em pizza (pie menu), menu de paleta (menu de cones) e menu embutido.

9.1.2.1 Menus push-buttons

Em um menu push-button, as escolhas so distribudas sobre botes separados e os botes so visveis a todo tempo em uma determinada janela. Alguns dos comandos mais comuns push-buttons que aparecem em muitas interfaces so ok, quit, cancel, help e comandos bsicos especficos da aplicao. Geralmente um dos botes escolhido como default; sua aparncia diferente dos outros botes: contorno em negrito ou uma borda extra em volta do boto. Os push-buttons geralmente so ativados via mouse ou teclas de funo ou combinao de teclas, sendo destacados quando escolhidos pelo usurio.

Figura 9-1 Menu push-button

9.1.2.2 Menus pull-down

o estilo de interao mais popular. Geralmente so ativados no topo da janela; somente o ttulo do menu ocupa espao permanente na tela. So utilizados para se acessar as funes mais importantes do sistema.

182

Figura 9-2 Menu pull-down

9.1.2.3 Menus radio-button

Os menus raio-button oferecem escolhas que so exaustivas e mutuamente exclusivas. Na figura abaixo, as opes Fonte das Listas e Funo de Cpia so menus radiobutton.

Figura 9-3 Menu radio-button

9.1.2.4 Menus check-button

Esses menus oferecem escolhas que podem no ser mutuamente exclusivas. O usurio pode fazer uma ou mais escolhas de um conjunto, via mouse. As opes escolhidas geralmente so marcadas por um indicador visual.

183

Figura 9-4 Menu check-button

9.1.2.5 Menus dinmicos

Contm opes que so dependentes da execuo. Um exemplo simples consiste em menus que podem ter opes meio apagadas para indicar que no esto disponveis naquele momento. Outro exemplo seria um menu de possveis vos entre duas cidades, que s pode ser determinado quando o usurio especifica as cidades origem e destino em tempo de execuo. Tornou-se comum incluir os nomes dos ltimos arquivos dos objetos recuperados no menu File, de forma que os arquivos mais recentemente utilizados possam ser reabertos com facilidade (esta seo chamada de MRU - Most Recently Used). Esse tambm um bom exemplo de menu dinmico.

Figura 9-5 Menus dinmicos

184

9.1.2.6 Menus pop-up

Os menus Pop-up podem aparecer em diferentes lugares na tela, determinado pela posio corrente do cursor, quando o usurio clica um boto especfico do mouse. Geralmente no h indicao de existncia do menu pop-up. Sua principal vantagem em relao utilizao de espao, pois no utiliza espao permanente da tela. Por outro lado, este tipo de menu apresenta a limitao de baixa visibilidade, o que pode levar ao desconhecimento de sua existncia, principalmente por usurios novios.

Figura 9-6 Menu pop-up

9.1.2.7 Menu de opo (Combo-box)

A origem do nome Combo que este tipo de menu pode ser considerado uma combinao de menus de boto com menu pop-up, agregando, tambm, suas vantagens de visibilidade aliado pouca ocupao de espao de tela.

Figura 9-7 Menu de opo (combo) 185

O menu de opo se parece muito com um campo (em um formulrio), sendo a descrio da opo escolhida sempre visvel. Outras opes aparecem quando o usurio ativa o menu. Depois de feita a escolha, o menu desaparece e o valor da nova opo escolhida passa a ser visvel na janela. O menu de opes funciona como os menus radio-button, devido a possibilidade de fazer apenas uma escolha na lista. Apesar de serem funcionalmente semelhantes, deve-se utilizar o menus de opes se o nmero opes for grande, se variar consideravelmente, ou se o layout de uma caixa de dilogo o exigir.

9.1.2.8 Menus de alternativas (toggle menu)

Nos menus de alternativas ou toggle o valor da opo corrente tambm mostrado na janela, porm, as possveis escolhas so apresentadas uma de cada vez a cada acionamento do usurio. Um exemplo tpico deste tipo de menu o utilizado em TVs que tm um boto no controle remoto utilizado para selecionar o sinal de entrada (que pode ser, por exemplo, antena, DVD, jogo, etc). A cada toque do usurio uma nova entrada selecionada, todas consideradas em uma sequncia circular.

Figura 9-8 Menus de alternativas O menu de alternativas mais utilizado para um pequeno nmero de opes, por exemplo, para escolhas binrias do tipo on/off. Como nos menus pop-up, o menu toggle indicado quando o espao na tela limitado. A desvantagem, comparando com o menu de opes, que as escolhas no podem ser todas visveis simultaneamente. 186

9.1.2.9 Menus de cascata

Os menus em cascata, tambm conhecidos como menus hierrquicos ou menus pull-right, se parecem com uma seqncia de menus pull-down. Quando o usurio seleciona uma das opes do primeiro nvel de menu na sequncia, um outro menu aparece a partir da opo selecionada, e assim por diante at o final da sequncia. As opes em um menu que levam a outro nvel de menus podem ter um indicador visual (por exemplo, > ) para indicar que um outro menu ir aparecer.

Figura 9-9 Menu de cascata

9.1.2.10

Menus em pizza (pie menu)

Figura 9-10 Menu em pizza 187

Os menus tipo pizza pie apresentam as opes arranjadas num crculo ou semi-crculo, procurando minimizar os movimentos do mouse feitos pelo usurio. Aps um tempo de uso, a seleo nesse tipo de menu tende a se tornar mais rpida, e pode ser feita sem muita ateno visual.

9.1.2.11

Menu de paleta (menu de cones)

Os menus de paleta ou menus icnicos so aqueles nos quais as opes so representadas por cones grficos que podem conter desenho e/ou texto. As opes geralmente so mutuamente exclusivas e dispostas no lado esquerdo da janela. So, em essncia, pushbuttons agrupados juntos; as escolhas geralmente so mutuamente exclusivas e podem implicar mudanas de modo. Muito usados em editores grficos.

Figura 9-11 Menu de Paleta

9.1.2.12

Menu embutido

Menus embutidos so encontrados em hipertextos ou hipermdia. Numa tela com texto e/ou grficos, alguns objetos so selecionveis via mouse ou touchscreen. Depois de feita a seleo do objeto em destaque, esse objeto instanciado e o usurio interagir com ele. So indicados em sistemas de armazenamento e recuperao de informao online, onde o usurio pode selecionar um objeto numa tela cheia de informao para encontrar maiores detalhes sobre o objeto selecionado.

188

9.1.3 FORMULRIOS (FORMS)

Um formulrio anlogo aos formulrios de papel a que estamos acostumados e consiste em uma tela contendo campos rotulados a serem preenchidos pelo usurio, geralmente atravs de linha de comando ou fazendo escolhas em menus. Um formulrio uma janela secundria que geralmente possui informaes associadas a uma base de dados.

Figura 9-12 Formulrio interessante que os formulrios contenham um visual atraente e contedo consistente. Evite assumir que os formulrios de papel possam ser convertidos diretamente para o desenho na tela, pois a tela tem dimenses diferentes e outras caractersticas a mais.

Use indicadores apropriados para campos no formulrio, como indicadores visuais, e organize os formulrios em sees, como por exemplo, campos opcionais, campos obrigatrios, entre outros.

Aproveite e utilize de maneira consciente abreviaes, como por exemplo, CPF, CEP. Use uma navegao lgica entre os campos. Use mensagens de erros informativas e consistentes para caracteres e valores invlidos juntamente com mensagens que auxiliem o preenchimento de campos, evitando erros por dvidas dos usurios.

189

Existem vrios tipos de valores para os campos de um formulrio, como por exemplo, os valores digitados; lista de escolhas; valores default; valores obrigatrios e valores opcionais; e valores dependentes.

9.1.3.1 Valores digitados

Os valores digitados pelo usurio podem ser validados ou no validados. Num campo no validado o usurio pode digitar qualquer cadeia de caracteres, que ser aceita pelo sistema. Num campo validado, o usurio deve digitar a cadeia numa sintaxe pr-definida, por exemplo, data e hora. Se o usurio no seguir o formato prescrito, a cadeia no aceita pelo sistema e o usurio deve tentar novamente.

Figura 9-13 Valor digitado

9.1.3.2 Lista de escolhas

Nas listas de escolhas, todas as opes permitidas so apresentadas ao usurio, geralmente atravs de um menu toggle ou menu de opes. Os possveis erros de digitao so reduzidos e o usurio no precisa recordar-se de todas as opes.

Figura 9-14 Lista de escolhas

9.1.3.3 Valores default

Alguns campos possuem valores default, tal como data corrente, que pode ser facilmente obtida do sistema. O usurio pode alterar este valor, se o desejar.

190

Figura 9-15 Valores default

9.1.3.4 Valores obrigatrios e valores opcionais

Campos com valores opcionais, ao contrrio dos obrigatrios, podem permanecer vazios. Em um formulrio, campos com valores obrigatrios devem ser distinguidos dos campos com valores opcionais; se possvel agrupados em diferentes posies da tela.

Figura 9-16 Valores obrigatrios e opcionais

9.1.3.5 Valores dependentes

Campos com valores dependentes so aqueles que devem ser preenchidos somente se outro valor for digitado. Por exemplo, se o campo estado civil foi preenchido com a opo casado, o campo com o nome do cnjuge deve ser completado. O sistema pode forar esta dependncia entre campos automaticamente.

9.1.4 CAIXAS (BOX)

Uma caixa consiste em uma rea da tela usada para mensagens, entrada de texto, comandos, seleo e controle. Podem ser vistas como uma janela que no possui as opes de minimizar/maximizar e redimensionar. Alguns tipos de caixas aparecem como resultado de aes dos usurios, enquanto outras so apresentadas pelo sistema para informar alguma situao corrente. As caixas suportam agrupamento visual de diferentes tipos de objetos como botes, listas e scroll-bars. Se no forem cuidadosamente projetadas, as caixas (principalmente as 191

caixas de dilogo) podem parecer bastante confusas ao usurio. Existem vrios tipos de caixas, como por exemplo, as caixas de listas, as caixas de entrada, as caixas de mensagem e as caixas de dilogo.

9.1.4.1 Caixas de lista

Uma Caixa de lista consiste em uma sequncia de opes, geralmente com scroll-bars horizontal e vertical. Podem ter um pequeno campo para entrada de texto, geralmente na base da caixa, onde o usurio digita uma cadeia de caracteres, o sistema percorre as opes procurando por aquela que casa com a cadeia digitada. Sua utilizao evita erros por parte do usurio, e no requer que o usurio se lembre de todas as opes.

Figura 9-17 Caixa de lista

9.1.4.2 Caixas de entrada

Uma Caixa de entrada permite ao usurio entrada de texto, geralmente possui funes bsicas de edio (como inserir, apagar e quebrar linhas (wraparound)).

Figura 9-18 Caixa de entrada

9.1.4.3 Caixas de mensagem

Uma Caixa de mensagens um objeto de interao que apresenta informao ao usurio, mostrando o progresso de uma operao, fazendo perguntas, dando algum aviso ou requerendo algum tipo de informao. Geralmente, a caixa de mensagens apresentada 192

pela aplicao sem que o usurio tenha requerido diretamente, muito utilizada para apresentar mensagens de sada (ex.: mensagem de erro, mensagens de confirmao) para o usurio.

Figura 9-19 Caixa de mensagem

9.1.4.4 Caixas de dilogo

Uma Caixa de dilogo um objeto de interao que contm outros objetos, como: listas, botes, caixas e campos para entrada de texto. Geralmente apresentada como parte de uma tarefa, como resposta a uma escolha em um menu ou ao de uma tecla aceleradora. Caixas de dilogo desaparecem como resultado de uma ao explcita do usurio, como pressionar o boto ok ou cancel dentro da prpria caixa. Elas podem ser classificadas como caixas de dilogo no-modais ou caixas de dilogo modal. CAIXAS DE DILOGO NO-MODAIS Este tipo de caixa meramente informa ou aguarda entradas. Uma barra de ferramentas do Windows um exemplo de uma caixa de dilogo no-modal. Ela apenas fica na tela e responder se for clicada. Outro exemplo de caixa de dilogo tpica no-modal do corretor ortogrfico exibido pelo Word for Windows, que permite ao usurio continuar a editar o documento enquanto a caixa de dilogo permanece exibida na tela.

Figura 9-20 Caixa de dilogo no modal 193

CAIXAS DE DILOGO MODAL Algumas vezes o aplicativo no pode continuar sem o auxlio do usurio. Por exemplo, um erro durante a impresso como uma mensagem do tipo acabou o papel no deve ser do tipo que o aplicativo ignore com facilidade. Em outro exemplo, alguns aplicativos podem no permitir a edio de um documento enquanto o aplicativo est imprimindo. Isto chamado caixa de dilogo modal, pois no se pode fazer nada enquanto a caixa est sendo exibida, mas, no entanto, possvel passar para um outro aplicativo (Ctrl-Esc ou AltTab no Windows).

Figura 9-21 Caixa de dilogo modal

9.2 INTERFACES GRFICAS EM SENTIDO AMPLO

Neste captulo usamos o termo interface grfica em um sentido mais amplo, vinculada ao uso de representao visual da informao em contraste com o uso de textos ou nmeros - mais amplo que o conceito WIMP (Windows, Icons, Menus and Pointers) ou interfaces VUI (Visual User Interfaces). As interfaces grficas usam manipulao direta, interao point-and-click, seguindo o paradigma objeto-ao: aponta e clica um objeto para selecion-lo, depois executa uma ao sobre ele. As interfaces grficas fazem tambm uso de representaes visuais, ao invs de simples representaes alfanumricas, para a comunicao com o usurio. Entretanto, alguns tipos so mais difceis de serem projetadas e implementadas do que as interfaces alfanumricas, 194

e o hardware para elas tambm pode ser bem mais caro. A seguir apresentamos algumas interfaces grficas muito utilizadas atualmente, so elas: a visualizao de dados, bancos de dados visuais, animaes, vdeo (e udio) e realidade virtual.

9.2.1 VISUALIZAO DE DADOS

A Visualizao de dados representa uma das primeiras aplicaes de grficos na interao com o usurio, incluindo grafos, histogramas, e vrios tipos de imagens mais bem elaboradas. Estas tcnicas de visualizao tm sido largamente utilizadas nas mais diversas reas, por exemplo, Qumica, Medicina, Geografia, Geologia, Astronomia. usado muito em diagnsticos mdicos usando ultra-som, simulao de fluxo de fluido, transferncia de calor, entre outros.

Figura 9-22 Visualizao de dados

9.2.2 BANCOS DE DADOS VISUAIS

Os Bancos de Dados visuais consistem de bancos de dados com tcnicas de navegao atravs de representaes visuais como imagens digitalizadas (por exemplo, manuscritos 195

num museu) ou imagens geradas pela aplicao (por exemplo, um poo de petrleo e a geologia da vizinhana). As tcnicas para navegao atravs de uma representao visual para banco de dados esto se tornando mais populares, principalmente em relevo de terreno, documentos histricos, entre outros. As imagens podem tambm ser geradas a partir de bancos de dados com informao numrica, como por exemplo, imagens geolgicas utilizadas em explorao de petrleo.

Figura 9-23 Banco de dados virtuais

9.2.3 ANIMAES
A Animao visa a criao de imagens em movimento em uma interface. Uma Animao pode ser, por exemplo, a representao de sada de uma simulao medida que ela muda no tempo. So muito utilizadas em aplicaes militares para treinamento em reas perigosas e inacessveis. Pode incluir, alm de imagens visuais, sons, vibraes e temperaturas de um ambiente real. Muito utilizada tambm em jogos. Um exemplo pode ser visto em: http://pt.wikipedia.org/wiki/Ficheiro:Newtons_cradle_animation_book.gif

196

9.2.4 VDEO (E UDIO)

O Vdeo como animao realstica, e o udio que tipicamente o acompanha, pode ser combinado com outros elementos de interao em uma interface - por exemplo, em uma janela.

O vdeo ilustra de forma mais realista as atividades e, como na animao, pode ser muito bem empregado em softwares de treinamento. A produo de vdeo de alta qualidade envolve vrias atividades que requerem tcnicas especiais e equipamentos caros, com altos custos e nem sempre disponveis para os projetistas da interao com o usurio.

9.2.5 REALIDADE VIRTUAL

O termo Realidade virtual freqentemente utilizado para se referir a qualquer simulao interativa onde geralmente so explorados vrios sentidos do usurio (viso, audio, tato e at mesmo olfato). Ao invs de usar o mouse para manipular objetos na tela, os usurios podem projetar-se em qualquer ambiente tridimensional. A realidade virtual representa a experincia mxima de primeira pessoa. Atravs do uso de equipamentos especiais como displays montados na cabea e luvas de dados (data gloves), os usurios podem entrar no mundo virtual e manipular objetos fazendo movimentos com algumas partes do corpo.

Figura 9-24 Realidade Virtual Estes sistemas podem ser extremamente caros, entretanto, avanos tecnolgicos atuais prometem torn-los disponveis brevemente. 197

Pioneiros na rea prometem que os sistemas com realidade virtual iro mudar a maneira como as pessoas usam computadores, a maneira como aprendem e at mesmo a maneira como se relacionam umas com as outras. O objetivo principal da realidade virtual projetar sistemas de computao que se comuniquem com pessoas de maneira mais prxima da humana, ao invs de forar os usurios a se conformarem com as restries de comunicao do computador.

9.3 LINGUAGEM DE COMANDOS

A Linguagem de comando constitui um dos primeiros estilos de interao encontrados em interfaces com o usurio. Consistem em cadeias alfanumricas representando comandos, parmetros e/ou opes que so digitadas pelo usurio. Compreendem um estilo de comunicao rpido e poderoso que muitas vezes preferido pelos usurios com habilidade de digitao. Entretanto, estes comandos requerem treinamento e boa capacidade de memria do usurio para lembrar a sintaxe precisamente. A linguagem de comandos pode ser mais difcil de se implementar, dependendo da anlise sinttica a ser feita. As linguagens de comando tambm podem ser utilizadas em associao com entradas de voz.

Figura 9-25 Linguagem de comandos Com o aparecimento das interfaces de manipulao direta, as linguagens de comando se tornaram menos comuns, mas ainda so utilizadas em vrias interfaces, principalmente por profissionais da rea de informtica. Algumas aplicaes mais antigas permitiam ao usurio mais de uma forma de comunicao, por exemplo, atravs da digitao de comandos curtos ou ativando menus ou teclas de funo para selecionar operaes. 198

Para que uma linguagem de comando possa ser usada de forma eficiente pelos usurios, deve-se levar em conta algumas consideraes para facilitar o seu uso. Procure usar regras consistentes de formao para comandos de entrada, usando uma sintaxe consistente e escolha nomes de comandos significativos, especficos que facilitem o entendimento e a memorizao. Aplique de forma consciente abreviaes de palavras, permitindo uma correlao fcil em relao aos erros de digitao.

9.4 OUTROS ELEMENTOS DE INTERAO

Embora existam muitos outros estilos de interao que podem ser apresentados, sero mencionados apenas alguns daqueles que esto se tornando cada vez mais populares.

9.4.1 TELA DE TOQUE

Touchscreens esto entre os dispositivos de entrada de dados mais durveis e robustos de todos os dispositivos de entrada. So bastante utilizados em ambientes hostis e em sistemas de acesso pblico, como no Epcot Center. So ideais para usurios novatos devido simplicidade de uso.

Figura 9-26 Tela de toque So muito teis tambm quando h pouco espao para o teclado e/ou mouse e situaes em que os usurios tm que ser guiados atravs de seqncias complexas de tarefas.

199

Recentemente, vem sendo muito utilizados como tela em notebooks e dispositivos portteis como o Iphone e similares.

9.4.2 SNTESE DA FALA

Os Sistemas que utilizam sntese da fala (criao de sons e palavras no computador) so ideais para usurios deficientes que no podem ver a tela ou manipular o teclado ou o mouse efetivamente. A gerao de sons audveis e palavras com o computador uma tecnologia relativamente bem dominada, conseguindo-se atualmente que soe mais natural. Pode ser usado de forma redundante, associado a textos e imagens.

9.4.3 RECONHECIMENTO DA FALA E LINGUAGEM NATURAL

So aplicaes que permitem ao usurio se expressar em linguagem natural, ou seja, utilizando a lngua com que ele se comunica com outros seres humanos, seja portugus, ingls, entre outras.

A interao em linguagem natural bastante atrativa para usurio com pouco ou nenhum conhecimento em computao. Entretanto, ela no se aplica a todos os tipos de sistemas. Sistemas de consulta a informaes e sistemas baseados em conhecimento so exemplos onde a utilizao de interfaces em linguagem natural bastante interessante. No primeiro caso, por possibilitar que usurio no especialistas possam fazer consultas em sua prpria lngua. No segundo caso, para que o sistema gere explicaes a partir da sua base de conhecimento, uma vez que a linguagem natural expressiva o suficiente para a descrio do raciocnio artificial do programa, o que no seria possvel com outros estilos de interao.

Uma aplicao que oferece interface em linguagem natural precisa lidar com construes vagas, ambguas, e at gramaticalmente incorretas. Ainda no possvel desenvolver sistemas que compreendam qualquer expresso em linguagem natural, mas diversos tipos de sistemas especialistas utilizam com sucesso algum subconjunto de uma linguagem natural, nos quais o usurio deve se expressar de forma inequvoca e tendo em vista as frases que tais sistemas possam interpretar.

200

Alm da fala, pode-se permitir que um usurio interaja com aplicaes em linguagem natural por meio de uma interface textual onde ele deve digitar as frases que expressem seus comandos ou questionamentos. Outra alternativa so as interfaces orientadas por menus, atravs dos quais ele pode selecionar cada palavra ou expresso at compor a frase desejada. Muita pesquisa ainda ser necessria antes do desenvolvimento de um computador que possa reconhecer e entender qualquer tipo de frase dita pelo usurio. As principais dificuldades no reconhecimento da fala esto relacionadas com as ambigidades lxicas, sintticas e semnticas inerentes a qualquer idioma.

9.5 GLOSSRIO
Animao digital a arte de criar imagens em movimento utilizando computadores. um subcampo da computao grfica e da animao. So criados cada vez mais trabalhos com o uso de grficos de computador a 3D, mas ainda se usam bastante os grficos de computador a 2D. Por vezes, o destino da animao o prprio computador, mas por vezes outro meio, como filmes dedicados parapropaganda e cinema. (Wikipedia, n.d.).

9.6 BIBLIOGRAFIA
Hartson, H. R. and Hix, D., Developing User Interfaces: ensuring usability through product

and process, John Willey & Sons, 1983.

Hutchins, E. L., Hollan, J. D. & Norman, D. A., Direct Manipulation Interfaces, In Norman, D. A. & Draper, S. W., User Centered System Design, Lawrence Erlbaum Associates, 1986. Wikipedia, http://pt.wikipedia.org/wiki/Animao_digital em 4/2010

10 GLOSSRIO
PROCESSO Processo um conjunto de passos parcialmente ordenados, cujo objetivo atingir uma meta. No caso de processo de desenvolvimento de software a meta entregar um produto 201

de software de maneira eficiente, previsvel e que atinja as necessidades de negcio (Wikipedia, n.d.).

11 BIBLIOGRAFIA
Booch, G.; Rumbaugh, J.; Jacobson, I., Unified Modeling Language User Guide, 2nd Edition, Addison Wesley, 2005. Chapman, C.N. & Milham, R. The personas' new clothes. Human Factors and Ergonomics Society (HFES) 2006, San Francisco, CA. October 2006. Cheng, L., Scapin, C. A. at al. QFD: Planejamento da Qualidade. Escola de Engenharia da

UFMG. Fundao Cristiano Ottoni, Belo Horizonte, MG, 1995.

Constantine, L.L. & Lockwood, L.A.D. Software for Use: a Practical Guide to the Models

and Methods of Usage Centered Design, Addison-Wesley, Reading-MA, 1999.

Cooper, A. The Inmates are Running the Asylum: Why High Tech Products Drive Us Crazy and How To Restore the Sanity. Macmillan Publishing Co., 2000. Cooper, M. Evaluating accessibility and usability of web pages. In Proceedings of 2nd Int. Conference on Computer-Aided Design of User Interfaces, Kluwer Academics, 33-42, 1999. Cooper, A. e Reimann, R. About face 2.0: The essentials of interaction design. Information Visualization. 2004. Galitz, W. O. The Essential Guide to User Interface Design. John Wiley, 2007. Grudin, J. and Pruitt, J. Personas, participatory design and product development: an infrastructure for engagement. Paper presented at Participatory Design Conference 2002, Malmo, Sweden. June 2002. Hackos, JT & Redish, JC 1998, User and Task Analysis for Interface Design, John Wiley &Sons. Hix, D.; Hartson, H. R. Developing User Interfaces: ensuring usability through product &

process, John Wiley and Sons, 1993.

http://webmail.faac.unesp.br/~paula/Paula/everydaythings.pdf

202

ISO 9241-11 Ergonomic requirements for office work with visual display terminals (VDTs) - Part 11: Guidance on usability 1998. ISO/IEC 9126 Information technology software product quality- part 1: quality model 1999, (FDIS). ISO/IEC 14598-2 Software Product evaluation, 1999 Krug, S.; Black, R. Don't Make Me Think: Common Sense Approach to Web Usability, 2nd edition, New Riders, 2005 Mulder, S. and Yaar, Z. The user is Always Right: A practical Guide to Creating and Using Personas for the Web. New Riders Publishing Thousand Oaks, CA, USA, 2006. Nielsen, J. Usability Engineering. Chestnut Hill, MA, Academic Press, 1993. Livro clssico, precursor, sobre usabilidade. Nielsen, J. Designing Web Usability, New Riders Press, 2000. Norman, D. A. The Design of Everyday Things. New York, Basic Books, reimpresso em 1998. PADUA, W. Engenharia de Software: Fundamentos, Mtodos e Padres. 2. ed. Rio de Janeiro: Editora LTC, 2003. v. 1. 604 p. Rosson, M. B., Carrol, J.M. Usability Engineering:

Scenario Development of Human-

computer Interaction. Morgan kaufmann Publishers, 2002.

Rubin, J. Chisnell, D. Spool, J. Handbook of Usability Testing: how to plan, design, and

conduct effective tests, John Wiley and Sons, 2nd edition, 2008.
Rumbaugh, J.; Jacobson, I.; Booch, G., The Unified Modeling Language Reference Manual, Addison Wesley, 2nd edition, 2004. Shneiderman, B; Plaisant, C.; Cohen, M.; Jacobs, S. Designing the User Interface:

Strategies for Effective Human-Computer Interaction, 5 ed. Reading, MA, Addison-Wesley,

2009 Van Harmelen, M. Object Modeling and User Interface Design: Designing Interactive

Systems, Addison-Wesley, 2001.

Wikipedia, em http://pt.wikipedia.org/wiki, acessado em 10/2009

203