Plano de Ensino da Disciplina

Disciplina de Interface Homem Mquina Prof Maximiliano Z. Pezzin

DISCIPLINA: Interface Homem Mquina HORA/AULA: 60 CRDITOS: 04 ANO/SEMESTRE: 2006/02 OBJETIVOS Expor as principais tcnicas, relacionadas a Interfaceamento do Software

com o Usurio EMENTA Interface HM, Ergonomia, Componentes de SW, Arquiteturas reativas, Mtodos de apoio, Anlise de desenvolvimento e consideraes a respeito da interface.
PROGRAMA DA DISCIPLINA

Tpicos Interface HM Anlise de Interfaces Anlise de Ferramentas Anlise de Softwares

Andamento da Disciplina Etapas Atividade

Material

1 2 3 4 5 6

Apresentao da Disciplina Importncia Necessidade Metas da Disciplina Anlise inicial de:

-x-xWindows Linux Word Star Office Winzip

Projetando a Interface com o Usurio

Analisando Softwares Comerciais

Trabalho 1 a ser desenvolvido

Analisando e criando um projeto prprio

Uma sistema de controle de Contas a Pagar e a Receber

Criando um relatrio de alteraes - Sugestes

Projeto Contas

Trabalho 2 a ser desenvolvido

Avaliao Final dos Trabalhos Desenvolvidos

-xTrabalhos Desenvolvid os

Conceitos da Disciplina

Projetando a Interface com o Usurio

Uma viso de Projeto O Software como meio de comunicao 1. Introduo 2. As Componentes do Projeto Amigvel
2.1 Definio do Universo de Estudo 2.2 O Pblico Alvo 2.3 Manuteno do Interesse do Usurio 2.4 Comunicao Visual 2.5 Definio do Nvel de Conhecimento do Usurio 2.6 Utilizando a Linguagem do Usurio 2.7 Comunicando-se por Metforas 2.8 Concentrar a Ateno do Usurio 2.9 Antecipar os Problemas na tica do Usurio 2.10 Evitando Informaes Irrelevantes 2.11 Quebrando a Resistncia do Usurio 2.12 Passando ao Usurio o Controle 2.13 Considerando a Resoluo dos Problemas 2.14 Evitando a Frustrao do Usurio 2.15 Auxiliando o Usurio na resoluo de Seus Problemas 2.16 Dando Satisfaes s Aes do Usurio 2.17 Tirando do Usurio a Tarefa de 'Processar' o Que Fez 2.18 Consolidando o Pensamento do Usurio 2.19 Envolvendo o Usurio aos Dados do Sistema 2.20 Desgeneralizando o Sistema 2.21 Definindo Uma Seqncia de Procedimentos De Forma Amigvel 2.22 Estruturando a Interface com o Usurio 2.23 Definindo as Caractersticas de um Produto Confivel 2.24 Eliminando a Exigncia de Experincia do Usurio 2.25 Aproximando-se do Usurio 2.26 Pensando na Primeira Impresso

2.27 Pensando Como o Usurio 2.28 Projetando Algo Simples

3. Consideraes de Desenvolvimento
3.1 3.2 3.3 3.4
3.4.1 3.4.2 3.4 3 3.4 4

Concentrando-se em Uma Soluo Eficaz Pensar Sobre Como Pensar a Respeito do Problema Desvincular os Aspectos Convencionais do Sistema Atendo-se a Aspectos Essenciais
Agregando alguma vantagem relativa Compatibilizando-se com o usurio Possibilitando experimentaes e Observaes Utilizando-se de Exemplos e Modelos

3.5 Aplicando Inteligncia ao Sistema

4. Concluses Finais 5. Bibliografia 1. Introduo

A histria do Software pode ser considera, ao mesmo tempo, recente e velha, dependendo do enfoque em que este analisado. O software pode ser considerado velho ao considerar-se que novas verses de muitos sistemas ocorrem quase que diariamente (a exemplo de browsers de internet), onde algo utilizado a semana passada pode e ultrapassado, no somente em recursos como at mesmo em performance. Observando-se com olhos mais conservadores, a idia agregada a utilizao de software recente (considere o nmero de aposentados na funo de programador !). O mundo mudou radicalmente, e est em uma eterna revoluo, onde a utilizao de novas tecnologias exigem um acompanhamento, ou o profissional estar desatualizado, o que o coloca no grupo de risco (desemprego). Estas mudanas esto intimamente relacionadas aos softwares e aos seus recursos, cada vez maiores. Imagine voc nos anos 80, imaginando que o video-fone acabaria por se tornar o vdeo-celular, ou que as cartas e telefonemas seriam substitudas por mensagens eletrnicas, que por fim seria lidas em um celular que estaria conectado a internet, tudo apresentando-se de forma extremamente simples, natural e voltada ao usurio. Em seu estudo [NAN99] expem as caractersticas da chamada tecnologia da Informao, apontando a questo da complexidade como o paradoxo de estudo, visto que a incerteza da informao Este trabalho tem por idia a exposio, de uma forma clara (humana) e objetiva (direta), de como um programa ou sistema (como costuma-se dizer), deve ser imaginado, projetado e desenvolvido. Primeiramente, no captulo 2, so apresentados os principais componentes desejados em uma interface que seja amigvel, considerando as caractersticas interessantes do ponto de vista do usurio. No captulo 3, so apresentadas idias quanto ao desenvolvimento da interface, apontando as principais caractersticas que o desenvolvedor deve almejar durante o processo de criao da interface No captulo 4 so apresentadas as concluses a respeito do trabalho desenvolvido.

2. As Componentes do Projeto Amigvel

2.1 Definio do Universo de Estudo
Sempre que h a necessidade de se definir um universo de estudo devem ser considerados os seguintes itens: Pesquisar o Assunto

Definir o enfoque Delimitar o universo Considerar os diferentes ngulos de viso No ater-se a detalhes de implementao durante a fase de definies Definir a profundidade da anlise Considerar que toda a anlise dever retratar o universo criado O Universo enfocado dever ser descrito e direcionado a interface, sem preocupar-se com a idia do desenvolvimento em si.

Em seu estudo, [SAN98], apresentou uma soluo para o problema da aprendizagem, baseado na implementao de um 'Knowledge-based Decision Support Systems (KBDSS)' ou Sistema de Suporte a Deciso Baseado em Conhecimento. A idia mescla conceitos de programao, anlise, banco de dados e inteligncia artificial, criando um meio onde a aprendizagem do sistema e do usurio so facilitados com a utilizao de mecanismos especiais.

O Conhecimento do Universo e de todas as suas peculiaridades algo indispensvel nas definies iniciais do sistema, visto ser o passo inicial na anlise e de onde todo o desenvolvimento se iniciar.

2.2 O Pblico Alvo

Considerando as velhas perguntas que sempre devem ser respondidas, no tocante aos pretensos usurios: Quem vai operar? O que pode lhe pode ser considerado importante? Qual o seu grau de conhecimento sobre o assunto? Quanto este entende de informtica? O que estes esperam do sistema? O que estes sabem fazer? Quanto esto dispostos a aprender? Qual ser sua resistncia a assimilar as novidades? Quais so as suas reais necessidades? No tocante a interao do usurio ao seu meio e as informaes concernentes devem, ainda, ser considerados: O sistema atualmente supre as necessidades de informaes? Quais so seus receios quanto a utilizao de um novo sistema? O usurio est satisfeito com os dados atualmente disponveis? Quanto ao desenvolvimento em si, deve-se objetivar sempre: Tornar o sistema amigvel, exigindo o mnimo de conhecimento pr-existente por parte do usurio; Criar algo til, para que mesmo que contrariado, o usurio utilize-se do sistema a fim de melhorar seu desempenho; Tornar o sistema, por assim dizer, indispensvel, considerando-se suas potencialidades e deficincias; Voltar a criao do desenvolvimento ao usurio, ou de como o usurio espera que o sistema reaja a insero de dados; Sistemas robusto, que abrajam o maior pblico possvel. [MCQ97] apresenta a idia que: " A transferncia de tecnologia dos sistemas de aprendizagem dentro de organizaes amostram um aspecto crtico da aprendizagem organizacional, a interpretao dos dados, que ocorre em duas frentes distintas: 1) a ajuda no reconhecimento dos dados por no especialistas, onde pode ocorrer uma certa derivao dos dados e 2) a determinao de diferentes chaves

entre os diversos sistemas de aprendizagem e os mtodos de anlise dos dados, a serem utilizados em selees e planejamentos." Outras perguntas so sugeridas por [MCQ97], agora no tocante aos dados do sistema: a dados suficintes para que seja realizada uma anlise inicial dos dados; que mtodos podem ser utilizados para minimizar as falhas e atenuar os erros da informao; quais as categorias de atributos devero ser analisadas na anlise; quais valores estatsticos pdoem ou no ser utilizados, em cada caso; at onde os dados encontrados podem ser considerados vlidos; como organizar os dados a fim de obter um sistema mais 'esperto'; que dados podem ser agregados ao sistema sem fazer com que os atuais dados tenham seu sentido alterado. The general goal of the research is to assist in technology transfer of learning systems capabilities into organizational usage. More specifically, the goals are to assist in one critical aspect of organizational learning -- namely the interpretation of data (Daft and Weick 1984) -- by: 1) helping non-specialists recognize the various forms of "knowledge queries" that can be posed to derive meaning from data, and 2) determining key differences between the various computer learning and data analysis methods, for use in technology selection and planning.

Assumir ao sistema as tarefas de compreender a informao, e no ao usurio, ou seja, desenvolver um sistema for USURIO.

2.3 Manuteno do Interesse do Usurio

Um sistema, quando em desenvolvimento, deve colocar-se como centro da ateno do usurio. Uma simples anlise de diversos sites, atualmente disponveis na internet, permitem extrair-se algumas concluses a respeito de interesses de usurios ao acessar sites diversos na internet: Se no obter o interesse do usurio nos primeiros instantes o usurio este no ir novamente acess-lo; O interesse do usurio depender das primeiras telas que este ver; A primeira impresso a que fica; O tempo para encontrar o que se procura cada vez menor, isto porque no se quer perder tempo; O interesse do usurio est diretamente relacionado ao encontro rpido e fcil do que deseja; Se for complicado, com desvios ou macetes o usurio criar uma resistncia natural a novos acessos, com medo de no encontrar novamente os dados; O interesse em manter o interesse do usurio dever ser de interesse do sistema. O interesse do usurio pode ser obtido e principalmente, mantido com simples tcnicas: No preocupar o usurio com aspectos tcnicos e mecnicos de suas atividades; Deixar para o usurio o mnimo de responsabilidades; Usar tons e cores suaves e neutras; Dar uma resposta, ou satisfao ao usurio sempre que este faa algo; No indicar erros do usurio de forma dura, ou que possa aborrecer o usurio; Apontar de uma forma clara qual o prximo passo a ser seguido.

O interesse do usurio depender exclusivamente da interface e da metodologia utilizada no desenvolvimento, ou seja, a primeira impresso a mais importante.

2.4 Comunicao Visual

Uma idia ou informao pode assumir diferentes imagens dependendo da interpretao ou viso do usurio. Desta forma a comunicao visual pode ser considerada uma cincia, e como tal, ser analisada e uma forma cientfica. Assim, antes de algo ser criado, um modelo genrico, dever ser pr-concebido de forma que se obtenha um mnimo de variantes, no que se refere a interpretaes pelos diversos usurios, isto porque, deve-se sempre pensar de forma genrica, especificando somente em casos especiais.

A idia da otimizao da comunicao pode ser aplicada com a utilizao de elementos de linguagem, ou cones, que representem funcionalmente, de forma clara e rpida, o que o comando ou mtodo , e isto indiferentemente ao grau de conhecimento do usurio ao sistema.

imprescindvel no s criar uma padro de comunicao, como tambm que este padro mostre-se genrico. Desta forma, exime-se o usurio da necessidade de conhecer o sistema, deixando-o genrico, do ponto de vista do usurio.

2.5 Definio do Nvel de Conhecimento do Usurio

A representao do conhecimento pode ser considerado, no mnimo, algo complexo. Isto se deve a diferenas culturais e at mesmo de capacidade intelectual. Partindo-se do princpio das diferenas de compreenso baseadas em nveis de conhecimento sobre o assunto, pode-se pressupor que as vises sobre o assunto tendem a ser as mais diversas. Um leigo com poucos conhecimentos em informtica ter uma viso complexa sobre o sistema, achando tudo complicado e mostrando-se confuso perante um volume gigantesco de informaes, exposto de uma forma um tanto contundente. J um perito em computao, ao ver o sistema ter conhecimentos que lhe ajudaro a operar o sistema, apesar deste carecer de conhecimentos a respeito das informaes do sistema. No entanto, um usurio que conhea a metodologia de trabalho e no conhea a informtica, como ferramenta de produtividade expe-se arredio as novidades, mesmo que estas sejam comprovadamente eficazes. Um problema solucionvel, aponta [SAN98], a utilizao de mecanismos que garantam a preciso e validao dos dados fornecidos pelo usurio. Isto pode ser feito com algoritmos de IA aplicados os banco de dados j existente no sistema. No se pode exigir que o usurio tenha um conhecimento prvio a respeito do assunto, pois isto implicaria na padronizao do conhecimento, algo inconcebvel. A linguagem de comunicao a ser utilizada deve ser o mais ampla possvel, sem que com isto seja ferida a pacincia e o nvel intelectual do usurio. Isto pode ser obtido com a utilizao de interfaces inteligentes, onde o conhecimento e os mtodos necessrios para o desenvolvimento estejam implicitamente agregados ao sistema. Pode-se criar uma tabela de tipos de usurios: Conhecimento de Informtica Nenhum Nenhum Razovel Razovel Nenhum Bom Bom Conhecimento do Problema Nenhum Razovel Nenhum Razovel Bom Nenhum Bom Compresso Geral do Sistema Muito Pouco Pouco Pouco Bom Bom - Situao A Pouco - Situao B timo

Tabela 1 - Tabela de usurios e compreenso do sistema

Na tabela 1 pode-se observar a questo da necessidade de conhecimento sobre o problema evidente, isto porque os conhecimentos em informtica sero DESNECESSRIOS. A situao A tem-se o caso onde o usurio detenha poucos conhecimentos a respeito de informtica, mas conhece o problema em si. Assim, se o sistema for amigvel, o desconhecimento sobre o programa no afetar o desempenho geral do usurio sobre o sistema. J na situao B, os conhecimentos sobre o problema que so poucos, e mesmo conhecendo informtica h a impossibilidade de que o usurio compreenda os aspectos gerenciais do problema, ao que o faz ter uma viso confusa do programa.

O que pretende-se alcanar uma interface com o usurio onde este no tenha que preocupar-se com os aspectos mecnicos, sendo necessrio apenas que este conhea o

problema o qual esta sendo trabalho, dispensando o usurio de que este tenha conhecimentos de informtica.

2.6 Utilizando a Linguagem do Usurio

A apresentao de qualquer assunto, bem como o manuseio de um sistema em si exige exige um conhecimento prvio sobre o assunto, pois o grande problema apresentado a questo da comunicao com o usurio. Este conhecimento deve ser ao usurio natural. Isto porque no devero existir dvidas quanto ao que se quer solucionar com o sistema. Comumentemente, empresas contratam pessoas que j tenham conhecimentos na rea onde iro atuar, no havendo como exigir que seu conhecimento seja total, sobre todos os aspectos do problema. A idia de trabalhar com termos e palavras nativas (naturais/ambientais) ao usurio pode ser entendido como uma forma eficaz de comunicao, principalmente em casos onde o sistema apresenta novas idias, que tenham agregadas inovaes ou vantagens ao modo de trabalho. Deve-se tomar cuidado com as expresses e palavras que o sistema utilize. Isto porque pequenas alteraes nos termos do sistema podem gerar confuses catastrficas, tais quais perder informaes e tratar informaes de forma equivocada. Deve-se tomar cuidados especiais quanto aos termos a serem utilizados, pois o sentimento de frustrao do usurio algo de difcil recuperao, isto quando esta for possvel. A garantia da comunicabilidade do sistema com o usurio exige a utilizao de uma linguagem mais do clara e objetiva. H a necessidade primordial de que a linguagem tenha coerncia, de que os mtodos utilizados sejam coerentes com as atividades realizadas, e de que a forma que os dados sejam tratados seja a mais correta possvel.

A utilizao de jarges, que retratem o modus-operandis do problema a ser resolvido uma excelente soluo para o problema de comunicao.

2.7 Comunicando-se por Metforas

As metforas podem ser consideradas como uma das mais importantes ferramentas de linguagem utilizadas pelo homem. Grande parte da comunicao do homem baseia-se em metforas. Seja em um programa de computador que utilize-se de cones, ou em sinaleiros de transito ou at mesmo em um sinal de positivo, que pode ter milhares de significados. As vantagens da utilizao de metforas so grandes, tais como a padronizao e a organizao do sistema, pois cabe ao desenvolvedor definir quais sero as metforas a serem utilizadas. As desvantagens, no entanto, so muitas. Da mesma forma que um sinal de OK pode ser bem recebido nos EUA, no Brasil este sinal certamente ser mal recebido. Partindo-se da idia das diferentes interpretaes que pode assumir uma metfora, evidenciada a responsabilidade do projetista no instante em que decide por uma ou outra conotao. Como de se imaginar, o usurio gostaria de encontrar elementos familiares no sistema, pois desta forma o seu prprio interesse tende a ser maior. O usurio tende a criar relacionamentos entre as metforas criadas pelo projetista e o seu problema. Assim, a utilizao de elementos que lhe sejam familiares, certamente, auxiliar em muito o grau de compreenso do usurio no sistema.

A implementao, inconsciente, de mecanismos de linguagem e metforas que tenham um significado real e correto, do ponto de vista do usurio, e a maior prova de que se esteja pensando como um comunicador, e sendo imparcial quanto aos mtodos e procedimentos.

2.8 Concentrar a Ateno do Usurio

A implementao do sistema deve ter um enfoque bem definido. A falta do enfoque, ou sua disperso, acaba por confundir o usurio.

Uma tela cheia de comandos e funes tende a desviar a ateno do usurio, apesar de ser, as vezes, indispensvel. Partindo-se do pressuposto de que o usurio tende a ser resistente as novidades, e esteja procurando problemas os quais pretenda utilizar de argumento para no gostar do sistema, cabe ao projetista tambm criar um meio termo entre uma tela com um mnimo de componentes e um cenrio onde o usurio tenha fcil acesso a todos os recursos do sistema. Uma forma eficiente de gerao de um foco a utilizao de uma metodologia de conversao, onde o sistema solicite confirmaes, do usurio para atitudes que venham a ser realizadas. Exemplos deste tipo de comunicao no faltam, tais como os assistentes do Office da Microsoft e o sistema de solicitao de confirmao do Star Office.

O enfoque sobre as informaes importantes, ou necessrias no momento, devem ser absorver a ateno do usurio, assim, a tela deve ser o menos poluda possvel, direcionando o enfoque para o que realmente interessa na resoluo do problema. Devese portanto trabalhar com a idia de enfocar ao mximo a ateno do usurio no que realmente interessa.

2.9 Antecipar os Problemas na tica do Usurio

Para o desenvolvedor um aviso de falta de disquete no drive algo sem a menor importncia, porem, para um usurio inexperiente, ou que tenha resistncias quanto a utilizao do sistema, talvez este seja um motivo para simplesmente dizer que o sistema no funciona. O ponto de vista do usurio fundamental. O projetista dever se colocar na posio do usurio e 'prever' quais sero as atitudes que este poder tomar nos diversos casos (ou problemas) que venha a enfrentar. Mais que antever os problemas de desenvolvimento, tais como erros de clculo e erros de amostragem, caber ao desenvolvedor 'imaginar' os problemas que o usurio 'ver' na tela, no sentido de no entender, ou compreender de forma errnea um componente ou informao. Quanto maior for o grau de compreenso do programador, sob o ponto de vista do usurio, menores sero os dilemas que o usurio enfrentar ao tentar compreender o sistema como um todo. Compreender o que o usurio ir compreender sobre o sistema antever as dificuldades de compreenso do usurio. Algumas tcnicas de organizao podem ser aplicadas ao sistema: Uma alternativa muitas vezes utilizada por alguns sistemas a realizao de algumas conferncias intermedirias, tal como uma tela de amostragem onde os procedimentos so armazenados e, mediante uma conferncia e confirmao final, o usurio aceita ou no a realizao de tal procedimento; Outra alternativa a utilizao de assistentes, mas a grande falha deste tipo de mtodo a exigncia da obedincia de certos passos, o que em muitos casos pode acabar por gera outro problema; Uma ltima soluo a realizao de testes em campo, o que, alm de dispendioso pode ser ineficiente, devido as diferenas entre os diversos usurios que um dia podero utilizar o sistema. Uma forma muito eficiente, ostensivamente utilizada por muitos programas, uma amostragem OBJETIVA, do que o comando dever fazer, reforando a idia de forma tal que haver certeza sobre o que dever ocorrer. Um bom exemplo ocorria em alguns editores de texto mais antigos como o Word Star, que no menu no apresentava somente Imprimir, mas Imprimir o arquivo XXX, ou o comando salvar como Salvar o Arquivo XXX.

Pode-se afirmar que quanto mais claros e objetivos forem os comandos a disposio do usurio, menores sero suas dvidas quanto ao que o sistema pode fazer. importante que o desenvolvedor coloque-se na posio do usurio final, considerando as pequenas dvidas e confuses do usurios como sendo os grandes problemas que este poder enfrentar. E este o desafio, antecipar as dvidas e impedir que elas venham a ocorrer.

2.10 Evitando Informaes Irrelevantes

Muitos dos sistemas atuais, utilizam-se dos mais diversos mtodos de organizao, tais como menus, comandos e listas para que o usurio escolha qual o mdulo ou parte do sistema este quer acessar. Analisando da viso organizacional (computacional) isto est correto, mas sob o ngulo do usurio (humano) isto pode ser considerado uma complexidade a mais, totalmente dispensvel. Basta imaginar um sistema com dezenas de cadastros e relacionamentos onde o usurio trabalhe somente com uma pequena parte do total (algo muito comum), visto que a sua idia de gerenciar a informao resume-se ao mais especfico ao seu caso. Assim, o usurio tem dezenas de mdulo e somente acessa uns poucos deles. As idias que o usurio acaba por fazer do sistema seriam algo como: Poderia ser mais simples, j que somente utilize uma pequena parte dele; Poderia ser mais barato, pois s uso uma parte dele; Poderia ser mais rpido, pois somente uso um pedao; Poderia ser mais direto, pois sempre acesso os mesmo mdulos. Outro tipo de irrelevncia retrata os avisos e informaes que retiram a ateno do usurio sobre o que ele estava trabalhando, para que este tenha que compreender esta nova informao, gerada pelo sistema, que em muitos casos no tem nenhuma importncia no contexto. O sistema deve ajudar o usurio, mas em hiptese alguma dever desviar a ateno do usurio, pois este, perdendo a linha de raciocnio, ficar, no mnimo chateado. Assim, ao desenvolvedor cabe a responsabilidade de compreender todo o ciclo do processamento da informao como um todo, ou seja, no podem ocorrer interrupes no processo de cadastramento dos dados.

Sistemas que utilizem imensos menus, com dezenas de possibilidades, podem e so um transtorno para grande parte dos usurios de sistemas. A irrelevncia na amostragem de informaes , seja em mdulos, avisos ou mesmo em campos de uma cadastro, acabam por desviar a ateno do usurio, diminuindo seu grau de satisfao com o sistema, visto que acaba achando-o um elefante branco, sendo que um simples gatinho era tudo o que ele queria (inconscientemente).

2.11 Quebrando a Resistncia do Usurio

Regra mgica de qualquer vendedor: NUNCA DISCUTA COM O CLIENTE, pois ele sempre tem a razo. A comunicabilidade de um usurio inexperiente parecida com a de um beb de alguns meses. Estudos do governo americano demonstram que toda a pessoa, antes de gastar dinheiro ou adquirir um bem, sentem, basicamente 3 sentimentos: Medo, dvida e incerteza. Da mesma forma, a primeira impresso que o usurio ter ser baseada nos 3 sentimentos acima, ficando bvia a comparao da venda de um produto com a empatia criada com o programa. A apresentao do sistema realmente um fator importante, porem a comunicabilidade dos objetivos e dos passos que o usurio tomar so de suma importncia na gerao de uma empatia pelo sistema. Pode-se dizer que o usurio tomar uma posio defensiva perante a comunicao, assumindo um papel submisso ao sistema, e esperando que o sistema tome controle da situao. Isto no chega a ser um problema, mas somente no caso de um programa bem projetado e que tenha esta metodologia como verdadeira, ou seja, o sistema dita as ordens e o usurio somente preenche os dados. Geralmente os desenvolvedores ignoram ou desvalorizam crticas quando estas so feitas aos seus produtos, isto um grande erro, pois somente so criticados os produtos que foram analisados, e que geraram algum interesse ao usurio. Partindo-se da idia de que o sistema possa conter erros, seria interessante, que estes erros, quando fossem reportados ao usurio, no o agredissem, no sentido da compreenso do que realmente est ocorrendo. Um caso tpico de frustrao que quase todos os usurios j passaram a famosa tela de erro azul do windows. Mais do que conhecer o usurio e falar a sua lngua, importante que o usurio tome as decises, que este no se sinta inferior ao programa, pois isto poderia ser interpretado como um gesto arrogante ou indiferente, por parte do sistema.

Outro fator de auxlio, na tarefa de quebrar a resistncia do usurio, demonstrar e tornar evidente que aes que este venha a tomar, podem ser desfeitas. Ou seja, em caso de dvida quanto a uma informao ou ao, evidencia-se a possibilidade de retornar ao estado anterior, assim, se fiz errado posso voltar em meu erro.

A resistncia do usurio , talvez, o maior desafio do desenvolvedor, pois no momento em que o usurio ache que o sistema seja ruim, ou ineficiente, a chance de que este venha a utiliz-lo, espontaneamente, so virtualmente nulas. Assim, deve-se tratar o usurio, desde o primeiro instante da forma mais amigvel possvel, minimizando seus medos, suas incertezas e as provveis dvidas que este venha a ter sobre o sistema.

2.12 Passando ao Usurio o Controle

importante repassar ao usurio a idia de que ele est tendo o controle sobre o processo. A idia de que o sistema esta controlando a situao a mesma de um passageiro de um nibus rotineiro de um nibus quanto ao horrio e o seu percurso. S pudesse, muito provavelmente, o passageiro utilizaria uma condio prpria, chegando ao destino exato, na hora que quiser, tendo assim o controle total sobre o processo de deslocamento. Termos e mtodos imperativos, onde o usurio seja uma simples ferramenta de auxlio no processo um dos maiores erros, e tambm um dos mais comuns, quando se fala em controlar o domnio do sistema. Um caso simples, horrvel e extremamente comum, quando se fala em controle de processo o exemplo de um sistema onde, em meio a insero de uma informao, o usurio deseja verificar, ou buscar uma parte da informao em outro local do sistema, e para tal, fica impedido de continuar, at que conclua a insero da informao corrente, ORA. este exatamente o problema ... O usurio no sabe qual o restante da informao que deseja colocar, e assim precisa parar de fazer o que esta fazendo e/ou recomear desde o comeo, isto pode ser considerado um absurdo, no que tange ao controle do processo, pois o sistema est atrapalhando e no ajudando o usurio. H um lado positivo quando o controle do processo est entregue ao sistema, a questo da organizao funcional, isto porque um sistema onde o usurio simplesmente fique respondendo perguntas, ou seguindo uma srie de passos pr-determinados, do ngulo do programador, muito mais previsvel e mais simples de se desenvolver. Outro exemplo interessante o que acontece com programas de reconhecimento, tanto de voz como os famosos OCR's (optical character recognize), onde imperativamente, o sistema exige um treinamento, ao invs de trabalhar de uma forma cooperativa, acompanhando os procedimentos do usurio, no decorrer de seu trabalho usual, atrapalhando sua rotina, verdade, mas a forma de insero da informao , por assim dizer, mais suave, visto que no ser exigido do usurio um tempo para cadastrar dados, sendo que as vezes somente utilizaria uma pequena parte do universo total do cadastramento. A possibilidade de desfazer alguma atitude que tenha realizado, seja em teste ou cadastrando o dado definitivamente, de extrema valia ao usurio, pois no s o tranqilizar enquanto insere dados, de uma forma mais humana, como tambm o retira da defensiva, visto que esta forma de trabalho aproxima-se mais da metodologia humana de desenvolvimento.

A idia de repassar ao usurio o controle sobre o processo de muita valia, principalmente se o sistema expem as possibilidades e, implicitamente, deixa claro ao usurio que este poder trabalhar de uma forma mais natural.

2.13 Considerando a Resoluo dos Problemas

O cadastramento ou anlise de qualquer informao pode e deve ser analisado em partes, comumentemente duas partes, uma inicial, onde so retratadas as principais caractersticas, ou as mais importantes, e a seguir, em um segundo momento, os detalhes so introduzidos. Pode ser considerado como a parte pesada e a parte leve, ou a parte grossa e a parte fina. Considerando os procedimentos de desenvolvimento e gerenciamento de software equivalente a uma obra de arte sendo gerada, o usurio poder cadastrar os dados de forma organizada. Uma grande vantagem na utilizao destes mtodos a liberdade dada ao usurio no tocante a insero da informao, visto que simplesmente a informao colocada, para posteriormente ser analisada e,

digamos, refinada, sendo que seu sentido poder ser totalmente alterado, tomando outro sentido, ou na maioria dos casos simplesmente a informao 'desgeneralizada' e colocada no seu devido lugar. O que se tem em mente, a considerao da informao sob dois ngulos distintos, assim, primeiramente se considera a informao de uma forma direta, para posteriormente ser refinada a informao. O que se consegue com esta metodologia aliar criatividade ao processo da entrada da informao, para que esta seja analisada a posterior. O que se obtm desta forma uma maior robustez do sistema, tornando-o mais confivel, do ponto de vista humano, pois considera a informao de uma forma mais natural.

A forma que os dados so recebidos, tratados e analisados dependero em muito da metodologia utilizada pelo desenvolvedor, sendo que o projeto do ambiente deve priorizar a resoluo do problema da forma mais humana possvel, segundo as idias e mtodos humanos.

2.14 Evitando a Frustrao do Usurio

Um objetivo do sistema, colocado sempre como principal, no frustrar o usurio durante o seu manuseio do sistema. Assim, deve-se sempre tentar: minimizar a complexidade; agilizar os cadastramentos; manter um alto grau de amigabilidade; deixar bvios os objetivos dos comandos; minimizar as redundncias; eliminar a demoras e esperas desnecessrias; eliminar a falta de conhecimento do que se est fazendo; eliminar a falta de satisfaes ( por parte do sistema) sobre o que est acontecendo; tornar o sistema o menor possvel. Complexidade desnecessria uma certeza de frustrao, apesar um projeto simples no garantir uma boa aceitao. O ideal seria que o software fosse obvio de ser utilizado, eliminando a necessidade de um manual. A espera indefinida ou sem satisfaes (explicaes) tendem a irritar o usurio, principalmente quando este est testando um sistema. O que pode, simplesmente, eliminar qualquer desejo do usurio de prosseguir a utilizar-se do sistema. Apesar de muitas vezes um sistema fornecer muitas informaes totalmente desnecessrias para um tipo de usurio, para outro tipo de usurio as informaes podem ser de extrema valia, assim, um usurio pode considerar um sistema e seus recursos inadequados ou simplesmente ignorveis, enquanto outro usurio considere-os de extrema valia, isto muito evidenciando quando se compara usurios iniciantes e usurios experts, que queiram se utilizar do mximo de recursos que o sistema possa oferecer. Uma tcnica interessante, mas pouco utilizada devido a sua complexidade e custos a realizao de testes com diversos tipos de usurios.

A frustrao do usurio pode ser considerada a pior coisa a acontecer com um sistema. Pode ser considera inevitvel a frustrao do usurio sob alguns aspectos do sistema, visto que nada no mundo perfeito. O que se pode, se deve e possvel fazer a minimizao das frustraes, tornando o sistema o mais amigvel possvel, o mais natural e simples possvel.

2.15 Auxiliando o Usurio na Resoluo de Seus Problemas

Independente do tamanho do sistema ou do seu nvel de interao com o usurio, SEMPRE o usurio ter novos problemas e dvidas. Por mais que sejam bem feitos e organizados os sistemas, as dvidas sempre surgiro e criaro confuses na interpretao do usurio, isto nada mais do que um grande problema para o usurio.

Solues simples podem ajudar o usurio, tais como informaes a respeito do que este est fazendo, e isto no exige muito do programador, alm de um pouco de tempo e criatividade. Um grande problema, para muitos usurios , no momento da entrada da informao, a colocao ou cadastro correto da informao, considerando as variantes que a informao pode tomar. Uma soluo para o problema citado acima a criao de uma metodologia de sugesto da informao baseada em algum mecanismo de SAD (sistema de apoio a deciso) e que utilize-se para tal de algum SI (sistema de informao) aliado a um BD (banco de dados). Qualquer ajuda, por parte do sistema sempre ser bem vinda, seja ela funcional ou uma simples sugesto a respeito dos dados que esto sendo cadastrados. Exemplos deste tipos de ajuda so muito comuns nos softwares atuais, alguns bons ( tais os sistemas de busca de programas como o Corel e as bibliotecas MSDN) e outros irritantes como o auxiliar de procedimentos do Office. Uma sugesto interessante uma anlise minuciosa a respeito das mensagens que sero dadas ao usurio. No incomum encontrar mensagens onde o usurio seja exposto com coisas do tipo: "Item no encontrado" e "Comando Ilegal". Seria muito mais interessante que fosse repassada alguma informao que no desmotivasse o usurio, ou que lhe sugerisse algum item semelhante para busca. Alguns sistemas so eficazes (ou quase) em sua tarefa de ajudar o usurio em sua tarefa de trabalhar com a informao. Um excelente exemplo disto demonstrado nas atuais ferramentas de busca da internet, como o Altavista, o Google e o Miner. Estes sistemas realizam buscas e permitem que o usurio delimite a busca, a partir de comandos e mtodos pr-definidos. Na verdade, utilizam-se de mecanismos de sugesto e de um banco de dados de acesso a fim de sugerir ao usurio qual o site que teria a informao mais relevante, partindo-se do princpios que outras pessoas j se interessaram pelo assunto. No exemplo acima, um grande problema do usurio foi solucionado, que a busca da informao de forma rpida e simples.

O usurio no espera que o sistema solucione sozinho os problemas, mas quanto maior for o grau de interao entre o usurio e o sistema, melhor ser a sua comunicabilidade, e com isto melhor ser a utilizao dos recursos do sistema por parte do usurio. Desta forma, cabe ao projetista criar funes que auxiliem (ou tentem auxiliar) o usurio no seu manuseio do sistema, mais que prevendo suas dvidas, e sim criando mecanismos que otimizem a resoluo de seus problemas.

2.16 Dando Satisfaes as Aes do Usurio

Todo e qualquer produto que for vendido ou repassado, se quiser se manter no mercado, dever buscar em seus clientes informaes referentes a satisfao do cliente em relao ao produto. Em um mbito muito mais restrito e direcionado, pode-se aplicar esta idia a um software onde um constante e contnuo processo de 'satisfaes' dado ao usurio a respeito das atividades e informaes repassadas pelo usurio. A pior coisa que pode acontecer a um cliente este ser ignorado, independente de seu problema ou reclamao. O processo de satisfao tende a acalmar o usurio, e mesmo que os resultados encontrados no sejam os esperados ou imaginados, o fato de alguma coisa ser informada ao usurio, mesmo que negativa, tende a aumentar a compreenso do usurio, e a mostr-lo que este continua no controle da situao.

A viso do que foi feito e do que se poder ser feito pode ser considerada como uma ferramenta muito poderosa na compreenso do que foi feito e do que se pode fazer com a informao em si. A importncia de compreender os dados e o que se est fazendo (funcionalidade) depende basicamente do grau de controle do usurio sobre o sistema, e tudo isto depende do sistema deixar o usurio com domnio a respeito dos estados do sistema.

2.17 Tirando do Usurio a Tarefa de 'Processar' o Que Fez

"No me importa como foi feito, contanto que funcione", foi o que disse o primeiro-ministro ingls, no instante em que tentava-lhe explicar-lhe como funcionava a mquina que decifraria os cdigos alemes em

1944. Na verdade, pouco importava a origem e os mtodos utilizados pelo sistema, contanto que este realizasse o que lhe foi solicitado. O que se pode afirmar que o usurio est muito pouco interessado em como tal tarefa foi realizada e sim que ela se concretize, corretamente e sempre da mesma forma. Muitas vezes o usurio, inconscientemente cria um modelo mental do que imagina ser a resposta, e de base neste modelo define uma metodologia de busca. Ora, se os mtodos de busca forem alterados, o resultado certamente ser diferente do que se esperava, e isto pssimo, do ponto de vista da confiabilidade do usurio em relao a funcionalidade do sistema. Toda e qualquer necessidade de se interpretar o que se fez distrai o usurio, e isto, em um ambiente complexo, onde os dados tendem a ser dispersos em sua compreenso.

A importncia de padronizar os procedimentos, extraindo a necessidade de interpretar a mecnica do que esta fazendo, crucial quando trabalham-se com dados complexos, visto a vantagem em deixar que o usurio se concentre somente em seus problemas e no com o programa que utiliza.

2.18 Consolidando o Pensamento do Usurio

Um usurio pode ter que fazer diversas vezes alguma tarefa, e, mesmo assim, a cada vez ter que consultar um manual e certificar-se de como tal tarefa dever ser realizada. A idia de consolidao do conhecimento denota a necessidade de que o sistema seja constante, no s em mtodos de processamento quanto em metodologia de interao com o usurio. Tem-se que ter como princpio que o usurio tentar criar um modelo mental, baseado em sua experincia e em sua compreenso do sistema como um todo. Este pensamento gerado se tornar um padro e ser utilizado ao longo de todo o programa, o que exigir uma padronizao de todo o sistema.

A padronizao fundamental, ou seja, um comando ter sempre a mesma funcionalidade, ou seja um comando sempre far a mesma coisa, da mesma forma e ter sempre o mesmo resultado. Desta forma um modelo mental ser criado na mente do usurio e este sempre compreender da mesma forma.

2.19 Envolvendo o Usurio aos Dados do Sistema

A idia de envolver o usurio, seja com uma anlise do programa ou com usa simples interao auxilia em muito a compreenso do usurio, visto que com isto cria-se um ambiente onde os dados do mundo real so relacionados ao sistema, e com isto uma imagem mental da soluo comea a ser formar na mente do usurio, solues e alternativas de solues so inconscientemente criadas. Considerando-se os dados do usurio e a funcionalidade do sistema, de se prever que caso no seja possvel gerar um envolvimento intuitivo do usurio com o sistema, as chances de que o usurio aprove e utilize o sistema so nfimas. Na verdade o envolvimento do usurio a chave do sucesso da implementao do sistema, mesmo que a utilizao do sistema seja fundamental.

O envolvimento do usurio com o sistema fundamental. Caso o usurio crie indisposies referentes a utilizao do programa, esta resistncia dificilmente ser quebrada, por outro lado, se forem utilizadas tcnicas onde o usurio seja envolvido , o fato do usurio interagir lhe criar um 'compromisso' e este certamente se sentir responsvel e se dedicar com mais afinco na tarefa de fazer com o que o sistema realmente funcione.

2.20 Desgeneralizando o Sistema

Apesar de bom para o programador/desenvolvedor, a generalizao no momento do desenvolvimento pssima para o usurio, visto que complica a vida do usurio, compreendendo erroneamente algumas das metforas utilizadas no programa. O fato de especificar (ou especializar) melhor o programa melhora a compreenso intuitiva do usurio,

visto que possvel utilizar termos e jarges especficos do assunto que est se relacionando. A idia da desgeneralizao pode ser expandida e aplicada de forma geral, em todo o sistema, possibilitando a criao de padres que podero ser utilizados de forma intuitiva, sempre que a funo seja a mesma ou parecida a que se pretende realizar. Obviamente h desvantagens e vantagens na especializao do sistema. A grande desvantagem est para o programador, que tem que fazer um programa em especfico para cada aplicao, complicando seu trabalho e o tornando mais caro, visto que no pode ser simplesmente aplicado em outras situaes, por outro lado, o do usurio, tem-se um sistema especfico, criado justamente para solucionar um problema em especial. A grande vantagem a do usurio, que como dito acima, tem uma coisa especificamente criada para aquela problemtica. Certamente isto gerar um problema para o programador. A grande soluo o desenvolvimento de um sistema que trabalhe de forma especfica, baseada em um sistema de generalizao o qual permita a adaptao do sistema para um caso em especial, direcionando sempre a otimizao da informao para o usurio.

Um meio termo deve ser criado, que viabilize os problemas de custo e desenvolvimento para a criao de um sistema especfico para um certo padro de cliente, e que mesmo assim, possa ser adaptado ou generalizado, sem que com isto seja necessria muitas alteraes no sistema, o que certamente o inviabilizaria.

2.21 Definindo Uma Seqncia de Procedimentos de Forma Amigvel

Por mais amigvel e interativo que seja um sistema, caso este no seja intuitivo e organizado, do ponto de vista das funes que este pretenda realizar. No incomum, em muitos sistemas a ocorrncia de uma mensagem onde o usurio fique totalmente desorientado e perca, no somente a linha de raciocnio como tambm a calma, ao tentar imaginar o que deve ser feito para eliminar o problema que acabou de enfrentar. Mais que importante, fundamental que se crie uma seqncia lgica, onde as informaes estejam organizadas na forma que o usurio imagine ou pretenda manuse-las. O ideal que os usurios encontrem intuitivamente e automaticamente as respostas as perguntas tpicas que qualquer usurio faria no instante em que comearia a trabalhar em um sistema desconhecido. Deve-se tambm tomar o cuidado de utilizar sempre as mesmas tcnicas, em todas as telas e funes do programa, pois casos contrrio isto poderia e confundiria o usurio.

Os procedimentos devem ser tratados como um amigo do usurio, nunca sendo um problema a ser resolvido mas sim como uma ferramenta que o usurio tem a certeza com a qual poder contar. Cabe novamente ao desenvolvedor definir quais sero as melhores tcnicas e meio de otimizar a manipulao dos dados de que sejam o mais eficientes e exijam o mnimo de conhecimento por parte do usurio.

2.22 Estruturando a Interface com o Usurio

O grande desafio dos projetistas a definio da organizao e estruturao dos projetos, nada mais que a gerncia intelectual do projeto. Considerando o fato de que teremos usurios envolvidos, deve ser dada uma ateno toda especial ao problema da interface. A estrutura deve ser basicamente lgica, seguir preceitos conceituais conhecidos e trabalhar na mesma sincronia que o usurio. Caso a estruturao seja precria ou ineficiente, certamente a impresso repassada ao usurio no ser das melhores. Como dito anteriormente, a estruturao deve seguir uma metodologia humana, ou que seja interpretada naturalmente pelo usurio. Os comandos e mtodos utilizados retrataro as informaes e dados que sero gerenciados pelo sistema, e por mais que seja organizado e direcionado para um certo grupo de usurios, dificilmente o xito ser total.

A complexidade faz com que a tarefa de definir a interface e a definio de uma estrutura faz com que se crie um problema de desenvolvimento, inviabilizando muitos aspectos referentes a interface. As diferenas da interface que evidenciam as tcnicas e a experincia do programador e do projetista, isto porque a qualidade de comunicao da interface est intimamente relacionada aos mtodos utilizados. Estes mtodos devem ser criados, adaptados e desenvolvidos no decorrer do projeto, mesmo que para isto tenha que abortar partes do projeto j criadas e refazer partes do cdigo j desenvolvido.

A idia de estruturar a interface vem do desejo ntimo e inconsciente das pessoas, que anseiam que as mquinas trabalhem na forma humana, nos mesmos meios e preceitos humanos, para que a compreenso, por parte do homem seja a mais natural possvel. A soluo deve ser obtida a partir da organizao e da resoluo dos problemas mecnicos do sistema, e nunca atravs da resoluo dos problemas baseados na compreenso da mente do usurio.

2.23 Definindo as Caractersticas de um Produto Confivel

A confiabilidade pode ser analisada, considerada e vista sob diversos ngulos. A questo da segurana no armazenamento de dados e backups de segurana deve ser algo extremamente simples, e sempre que possvel automtica, sendo realizada pelo sistema sempre que possvel, de uma forma simples rpida e que d ao usurio uma impresso de que os dados esto em segurana. Outro ponto de confiabilidade trata do armazenamento temporal e imediato dos dados que estiverem sendo inseridos no sistema. A conhecidas caractersticas ACID (advindas do estudo de bancos de dados concorrentes), so aqui mencionadas como sendo a base da confiabilidade, sendo: A tomicidade - se algo comear, deve ser concludo antes de que outra seja iniciada - razes humanas C onsistncia - se algo for feito isto deve ter uma base lgica confivel e que lhe garanta recuperao e integridade I solao - se algo for feito, isto independer de outros processos concorrentes D urabilidade - se algo for feito isto deve ser realizado de forma permanente, os dados devero permanecer armazenados

A idia de confiabilidade depender em muito do que o usurio entende por confiana. Assim, um produto confivel pode ser um que no perca informaes, como pode ser algo que salve os dados automaticamente, como tambm pode ser um simples backup que guarde os dados regularmente. Mas para o projetista a idia de confiana deve ser mais ampla, da ao criar mtodos que realizem com perfeio as metas que o usurio, no deixando-o insatisfeito nem decepcionado com o que fizer.

2.24 Eliminando a Exigncia de Experincia do Usurio

Um problema que para alguns usurios seja de simples soluo, para outros usurios pode ser algo de extrema complexidade para outros, e isto no depende somente de seu nvel de conhecimentos e informtica, e sim de todo um contexto de conhecimentos, que envolve muito mais que a mera e simples informtica. Exigir que o usurio seja experiente, algo inconcebvel, mesmo para sistemas que sejam desenvolvidos exclusivamente para experts. Da mesma forma, no se pode considerar que o usurio seja inexperiente, agregando funes simples pois isto seria quase um desrespeito para com usurios com mais experincia. O grande desafio a criao de sistemas onde sejam agradados tanto os usurios experts, como os usurios leigos ou inexperientes, mas certamente isto um grande desafio, at mesmo porque o usurio iniciante no compreende nem mesmo o que o sistema faz, oxal o que pode fazer. Um sistema deve prever que o usurio o ser mais burro e inexperiente possvel, que est vendo o computador pela primeira vez, e tem medo que a mquina o recrimine por ter feito algo errado. Infelizmente esta a realidade.

Desenvolver um sistema para todos os usurios parece difcil, mas pior que isso. O nmero de variveis, e a falta de padro gerada devido a disperso da compreenso humana a respeito dos mtodos que esto por serem gerados realmente pode ser considerado algo notvel.

Exigir que o usurio tenha conhecimentos prvios a respeito de como se opera um ou outro sistema no algo aceitvel, por estar totalmente fora da realidade. Deve sempre ser considerada a problemtica relacionada a diferena de conhecimento existente entre os diversos usurios que utilizaro o sistema. Isto implica que o sistema tenha um projeto sem especificaes, ao menos quanto ao tipo de usurio, atendendo as necessidades de aprendizagem dos novatos e de extrao de dados avanados dos usurios experientes.

2.25 Aproximando-se do Usurio

Uma forma inteligente e eficaz de quebrar a resistncia do usurio aproximando-o do produto. A gerao de relacionamentos, onde o usurio veja o produto como uma ferramenta de auxlio. A aproximao do usurio no uma tarefa simples, e depender em muito da interface utilizada, e principalmente da forma que a soluo apresentada. Mais que solucionar, o sistema deve trocar conhecimentos com o usurio, mostrar-se eficiente e capaz de suprir as necessidades. Pode-se solucionar o problema de forma mais amena criando uma interface que lembre o ambiente normal, e atual, do usurio, pois assim este tende a sentir um domnio sobre a situao, o que no o coloca na defensiva, motivando-o a avanar e compreender, agora sem medos, as potencialidades e vantagens que a utilizao do sistema gerar. A idia gira em torno de deixar claro que o sistema no est l para lhe roubar o servio e sim para ajud-lo, sendo uma ferramenta de produtividade que simplesmente o ajudar a ser mais til e eficiente em suas tarefas.

Todo o projeto e desenvolvimento deve almejar a idia da aproximao com o usurio. Utilizar-se da caracterizao do meio onde o usurio trabalhe a fim de criar relacionamento com o sistema, a fim de que o usurio sinta-se prximo do sistema, e aceite-o com mais facilidade e naturalidade.

2.26 Pensando na Primeira Impresso

Independente da questo de que esteja em teste, temporrio ou at mesmo comprado, a aceitao do produto pode ser vista como a de um produto qualquer sendo vendido. Obviamente, se for um produto de suma importncia, o usurio ficar obrigado a aceitar o produto, mas isto se este souber da importncia e compreender os benefcios, o que geralmente no ocorre. Deve-se ter em mente que o produto deve trabalhar com vistas a idia que o usurio far dele, e a primeira impresso certamente a que ficar. Achando-o simples e fcil o usurio tende aceit-lo com mais naturalidade, mas com certeza a primeira impresso contar . Muito raramente o projetista ou desenvolvedor estar junto ao usurio a fim de acompanhar as primeiras impressores que o usurio ter do produto, assim o usurio dever compreender o sistema sozinho, navegando entre os mdulos e funes e tendo sua prpria noo sobre o que aquele programa e o que ele pode fazer. O produto deve ser algo auto-demonstrvel, onde a interao humana necessria seja a mnima.

Este pode ser o grande desafio, deixar o sistema e o usurio se conhecerem. O sistema por si s amostrando suas vantagens e deficincias. Do ngulo organizacional, pode-se considerar a primeira impresso como sendo o teste de aceitao, bem como uma comprovao da eficincia da comunicabilidade do sistema.

2.27 Pensando Como o Usurio

Desenvolver o sistema no ser algo como fazer um simples programa. Os anseios e os objetivos do usurios devem ser colocados em primeiro lugar.

Deve-se trabalhar para o usurio e no para o sistema. As danarinas polacas comentavam: " Estes tamancos de madeira so excelentes para danar, principalmente se usarmos 3 pares de meias bem grossas". Este tipo de comportamento horrvel. claro que se houver uma necessidade de utilizar-se de tal objeto, ou sistema este ser utilizado, mas somente at o momento em que outro melhor (mais natural), no surgir. O pensamento do usurio sempre gira em torno de algo simples, natural e de fcil compreenso. Mtodos demorados, ineficientes e complicados sempre so rejeitados ou tendem a criar indisposio, pois geralmente fogem a compreenso e exigem uma organizao dispensvel. O importante o que o usurio pensar a respeito do programa, o quanto o sistema suprir suas necessidades. Definir a importncia algo muito subjetivo, mas criar modelos de compreenso humana de certo ou errado algo relativamente simples. Assim, a troca de experincias homem-mquina. pode ser otimizada, visto que o usurio ter consigo no um programa mas uma ferramenta de produtividade. Claro que a utilizao de metforas tende a ser menos agressiva ao usurio, quebrando sua resistncia e impelindo-o a querer conhecer esta ferramenta da qual agora dispem.

A utilizao de mtodos humanos de representao, bem como de tcnicas mais direcionadas a compreenso humana tende a ser mais eficientes e de melhor aceitao. A criao de um modelo mental, que represente a soluo proposta pelo sistema e algo comum, e cabe ao desenvolvedor/projetista, imaginar este modelo, criando mtodos que trabalhem segundo a metodologia humana, onde existam relacionamentos entre os diversos dados que estejam sendo manipulados.

2.28 Projetando Algo Simples

Por fim, o desenvolvedor dever sempre pensar em algo simples, que crie um modelo mental simples na mente do usurio, apontando suas vantagens e potencialidades. O projeto sempre deve criar interfaces simples, desenvolvendo modelos mentais claros ao usurio, onde este imagine e consiga chegar em solues de forma rpida e direta. A complexidade poder ser considerada uma frustrao ao usurio, principalmente tratando-se de usurios leigos ou pouco experientes. [NAN99]

O desenvolvimento do projeto tanto quanto sua elaborao so indispensveis se considerado que o pblico alvo ser o maior e mais diverso possvel. O projeto deve ser simples e conciso, claro e principalmente voltado ao usurio, que a princpio deve ser o mais humano possvel.

3. Consideraes de Desenvolvimento
3.1 Concentrando-se em uma Soluo Eficaz
Um paradoxo da programao e desenvolvimento de programas o enfoque do projeto. Mesmo que o sistema seja completo e repleto de relatrios produzindo informaes extremamente interessantes, caso o usurio no tenha conhecimentos ou experincia suficientes para compreend-los a idia que far a de que o sistema mal desenvolvido, ineficiente ou at mesmo intil. Da mesma forma, uma sistema totalmente voltado ao usurio, com uma interface amigvel, e com funes simples, que produzam informaes, por assim dizer, simples, seria, do ponto de vista de um conhecedor de sistemas, ineficaz ou mesmo intil. A partir do momento em que foi definido o tipo do usurio, todas as caractersticas apontadas no captulo 2 so direcionadas e definidas a fim de solucionar os problemas deste tipo especial de usurio.

A metodologia mais indicada a anlise inicial e a definio formal e rigorosa de quais sero os usurios do sistema, e a partir deste ponto todo o desenvolvimento ser direcionado ao modelo ou usurio caracterstico em especial.

3.2 Pensar Sobre Como Pensar a Respeito do Problema

Toda e qualquer anlise pode ser intil se a viso ou enfoque do problema ocorrer de forma errnea ou equivocada. O que deve-se ser levado em considerao a problemtica da anlise do que se quer fazer. Existem muitas forma de solucionar um problema, porem, geralmente existe uma forma mais correta ou especfica. De nada adiantar ao usurio se a resoluo do problema gerar outro problema, ou se esta resoluo apontar para informaes que fogem ao escopo de se u entendimento. Para que o problema seja solucionado, os dados gerados devem, obrigatoriamente, suprir as necessidades do usurio, ou, de certa forma trazer ao usurio informaes que lhe sejam teis. e lhe possibilitem chegar a concluses. O projetista deve no s conhecer o problema mas ter conhecimentos reais sobre o funcionamento total, pois ficaria impossvel analisar e compreender o sistema sem que se tenha uma macro viso a respeito do problema.

A compreenso das informaes e dos mtodos utilizados para se projetar e desenvolver qualquer sistema exige um profundo conhecimento do problema que est por ser resolvido. Obviamente deve ser considerados os passo de especificao do problema e a anlise de requisitos, a fim de se ter uma correta compreenso do universo de estudo.

3.3 Desvincular os Aspectos Convencionais do Sistema

O fato do sistema ser simples ou convencional no chega a ser um problema. O grande problema pode ser visto como um programa que no tenha uma interface direcionada, que no tenha como enfoque a utilizao pelo usurio. A organizao e estruturao do projeto pode trazer consigo metodologias no convencionais que dem ao usurio as ferramentas necessrias ao bom desempenho em suas atividades. Nem sempre uma interface simples pode ser considerada ideal, pois a falta de recursos avanados pode afetar no s o andamento como o prprio desempenho geral do sistema. Sistemas onde clculos ocorram automaticamente, sem que para isto o usurio tenha que recorrer a execuo de comandos interessante, e esta idia for expandida para as outras 'funes' tem-se um sistema onde os dados so responsabilidade do usurio e o processamento responsabilidade do sistema.

A desvantagem de se utilizar uma metodologia convencional a necessidade de exigir do usurio que este no somente insira os dados como tambm execute os comandos, o que, metodologicamente pssimo, pois exigir um treinamento prvio do usurio. O ideal, que ao usurio seja destinada a nica tarefa de insero dos dados, deixando todo o controle do processo e dos mtodos por cargo do sistema.

3.4 Atendo-se a Aspectos Essenciais

O desenvolvimento de qualquer que seja o produto, independente de sua finalidade ou utilizao, ter uma aceitao tanto melhor quanto mais direcionada e orientada esta for ao usurio. Certamente o usurio analisar o sistema de forma crtica, procurando por falhas e vantagens na utilizao. Algumas consideraes bsicas podem ser feitas:

3.4.1 Agregando alguma vantagem relativa

Um fator que pode aumentar em muito interesse do usurio este encontrar inovaes no sistema. Por mais simples que sejam, operacionais ou at mesmo financeiras, estas vantagens encontradas, tendem a criar no usurio uma predisposio no conhecimento do sistema, o que pode ser considerado um passo importantssimo na aquisio efetiva do sistema.

3.4.2 Compatibilizando-se com o usurio

Criar metforas ou utilizar termos que sejam naturais ao usurio mais que importante, pois pode ser o divisor de guas quanto a no somente a compreenso, por parte do usurio, bem como a prpria aquisio.

Cabe lembrar que se o usurio no compreender a interface, ou mesmo se ele no compreender a prpria idia da interface e suas funes as chances deste disponibilizar-se a utilizar o sistema so mnimas ou at mesmo nulas.

3.4 3 Possibilitando experimentaes e Observaes

Permitir que o sistema seja testado e experimentado, mais que importante, FUNDAMENTAL, pois tem-se o mesmo caso da compra de um carro, algum compra um carro sem antes test-lo ou verificar suas condies. Basta pensar um pouco e chega-se a concluso que criar mtodos onde o usurio interaja, experimentando e analisando algo fundamental, pois amostrando as vantagens e as possibilidades, onde o usurio veja, de forma clara e simplificada o que realmente pode ser feito e possibilitado pelo sistema.

3.4 4 Utilizando-se de Exemplos e Modelos

Uma tcnica excelente de auxlio ao usurio, a fim de que este compreenda as reais possibilidades do sistemas, a utilizao de EXEMPLOS, pois desta forma as potencialidades podem ser expostas, obviamente explorando ao mximo os recursos os quais este sistema em especial disponibiliza. Um usurio, por mais experiente que seja, sempre ter dificuldades em trabalhar com os diversos recursos que o sistema disponibilizar. Assim, a utilizao de exemplos, mais que importante, fundamental, para uma anlise real das reais possibilidades, utilizando, para tal de dados, obviamente reais, chega-se assim a uma viso REAL, deixando as suposies e hipteses a parte, isto com certeza dar uma maior SEGURANA ao usurio, se este estiver indeciso.

3.5 Aplicando Inteligncia ao Sistema

A idia de aplicar inteligncia aos sistemas de computao no novidade. Diversos so os sistemas que anseiam em facilitar a vida do usurio. Grande parte deles utilizam-se de tcnicas de Inteligncia artificial visando a extrao de informaes que no sejam obvias, ou de difcil obteno do usurio. Em sistema de informao, a inteligncia pode ser aplicada auxiliando o usurio no processo de insero e na recuperao desta informao. Assim, a inteligncia na manipulao dos dados pode e deve ser agregada no instante do cadastramento da informao e tambm na sada da informao, basicamente os relatrios. Existem diversos tipos de geradores de relatrio, o que nada tem haver com um relatrio inteligente, e sim com um sistema que expem dos dados cadastrados, no momento, dentro do sistema.

O que se propem diminuir ao mnimo a interferncia do usurio quanto ao processamento dos dados, ou seja, o usurio no deve e nem pode preocupar-se com os aspectos mecnicos e funcionais do que faz, atendo-se puramente a compreenso e anlise crtica dos dados inseridos. Da mesma forma o sistema deve prover ao usurio uma ferramenta poderosa de relatrios, que permita a extrao de informaes sob os ngulos mais diversos possveis, preferivelmente com alguma metodologia de vises ou cenrios de relatrios.

4. Concluses
A utilizao de mtodos e funes que venha a auxiliar o usurio tendem a aumentar a performance do sistema. Certamente a utilizao de dados pr-existentes aliados a tecnologias de inteligncia artificial tendem a aumentar ainda mais a performance geral, criando meios que efetivamente ajudem o usurio, no somente a extrair os dados de uma forma mais organizada, mas organizando os dados de forma transparente, sem ao menos que o usurio saiba que o sistema est o fazendo. A idia deve estar centralizada basicamente na compreenso do usurio. Independente do grau de conhecimento do usurio a respeito de informtica ou mesmo do problema a ser resolvido, o sistema dever prover ao usurio mecanismos de apoio, onde sejam sugeridos passos de desenvolvimento, bem como prover algum nvel de organizao que permita a este operar e trabalhar de

forma fcil e clara. O projeto da interface deve basear-se nas necessidades do usurio, ignorando os problemas que estas facilidades ao usurio iro criar ao desenvolvedor do sistema. Uma forma muito interessante e eficaz de verificar e validar o projeto e desenvolvimento da interface advem da resposta de diversas perguntas que podem ser feitas ao testador do programa, descritas no item 2. Por fim, pode-se concluir que a interface com o usurio j foi algo colocado em segundo plano, onde funcionando estava bom. Hoje em dia, j possivel exigir de um sistema, alm de preciso dos dados e segurana na gerencia dos dados, um nvel de amigabilidade que traga o usurio para dentro do sistema, inserindo-o no contexto do projeto e dando-lhe um maior controle e interatividade com o programa como um todo.

5. Bibliografia
[HEC93] HECKEL, Paul Software Amigvel: Tcnicas de projeto de Software Editora Campus Rio de Janeiro 1993 [NAN99] NANCI, Duncan A Study of the Impact of IT Infrastructure Flexibility Kent State University 1999 [SAN98] SANDMAN, Thomas E. Decision Forest Enhancement Evaluation MIS Department, School of Business, CSUS Sacramento, CA 1998 [MCQ97] MCQUILLEN, Nancy L. Toward Learning Systems University of Colorado at Boulder 1997 [CHU94] CHUNG, H. Michael A Analysis of Inductive Decision-Making Models Department of Information Systems School of Business Administration California State University at Long Beach Long Beach, CA 1994