Designer-de-Interacao.pdf

DESIGN DE INTERAÇÃO

Professor Esp. Ricardo Francisco de Pierre Satin

GRADUAÇÃO

Unicesumar

Reitor Wilson de Matos Silva Vice-Reitor Wilson de Matos Silva Filho Pró-Reitor de Administração Wilson de Matos Silva Filho Pró-Reitor de EAD Willian Victor Kendrick de Matos Silva Presidente da Mantenedora Cláudio Ferdinandi NEAD - Núcleo de Educação a Distância Direção Operacional de Ensino Kátia Coelho Direção de Planejamento de Ensino Fabrício Lazilha Direção de Operações Chrystiano Mincoff Direção de Mercado Hilton Pereira Direção de Polos Próprios James Prestes Direção de D esenvolvimento Dayane Almeida

C397 CENTRO UNIVERSITÁRIO DE MARINGÁ . Núcleo de Educação a Distância; SATIN, Ricardo Francisco de Pierre.

Design de Interação. Ricardo Francisco de Pierre Satin. (Reimpressão revista e atualizada) Maringá-Pr.: UniCesumar, 2016. 157 p. “Graduação - EaD”. 1. Design. 2. Usabilidade. 3. EaD. I. Título. ISBN 978-85-8084-560-0 CDD - 22 ed. 005.3 CIP - NBR 12899 - AACR/2

Ficha catalográfica elaborada pelo bibliotecário João Vivaldo de Souza - CRB-8 - 6828

Direção de Relacionamento Alessandra Baron Gerência de Produção de Conteúdo Juliano de Souza Supervisão do Núcleo de Produção de Materiais Nádila de Almeida Toledo Coordenador de Conteúdo Danillo Xavier Saes Design Educacional Fernando Henrique Mendes Rossana Costa Giani Iconografia Amanda Peçanha dos Santos Ana Carolina Martins Prado Projeto Gráfico JaimeJhonny de Marchi Junior José Coelho Arte Capa André Morais de Freitas Editoração Thayla Daiany Guimarães Cripaldi Revisão Textual Jaquelina Kutsunugi, Keren Pardini, Maria Fernanda Canova Vasconcelos, Nayara Valenciano, Rhaysa Ricci Correa e Susana Inácio Ilustração Thayla Daiany Guimarães Cripaldi

Viver e trabalhar em uma sociedade global é um grande desafio para todos os cidadãos. A busca por tecnologia, informação, conhecimento de qualidade, novas habilidades para liderança e solução de problemas com eficiência tornou-se uma questão de sobrevivência no mundo do trabalho. Cada um de nós tem uma grande responsabilidade: as escolhas que fizermos por nós e pelos nossos fará grande diferença no futuro. Com essa visão, o Centro Universitário Cesumar – assume o compromisso de democratizar o conhecimento por meio de alta tecnologia e contribuir para o futuro dos brasileiros. No cumprimento de sua missão – “promover a educação de qualidade nas diferentes áreas do conhecimento, formando profissionais cidadãos que contribuam para o desenvolvimento de uma sociedade justa e solidária” –, o Centro Universitário Cesumar busca a integração do ensino-pesquisa-extensão com as demandas institucionais e sociais; a realização de uma prática acadêmica que contribua para o desenvolvimento da consciência social e política e, por fim, a democratização do conhecimento acadêmico com a articulação e a integração com a sociedade. Diante disso, o Centro Universitário Cesumar almeja ser reconhecida como uma instituição universitária de referência regional e nacional pela qualidade e compromisso do corpo docente; aquisição de competências institucionais para o desenvolvimento de linhas de pesquisa; consolidação da extensão universitária; qualidade da oferta dos ensinos presencial e a distância; bem-estar e satisfação da comunidade interna; qualidade da gestão acadêmica e administrativa; compromisso social de inclusão; processos de cooperação e parceria com o mundo do trabalho, como também pelo compromisso e relacionamento permanente com os egressos, incentivando a educação continuada.

Diretoria de Planejamento de Ensino

Seja bem-vindo(a), caro(a) acadêmico(a)! Você está iniciando um processo de transformação, pois quando investimos em nossa formação, seja ela pessoal ou profissional, nos transformamos e, consequentemente, transformamos também a sociedade na qual estamos inseridos. De que forma o fazemos? Criando oportunidades e/ou estabelecendo mudanças capazes de alcançar um nível de desenvolvimento compatível com os desafios que surgem no mundo contemporâneo.

Diretoria Operacional de Ensino

O Centro Universitário Cesumar mediante o Núcleo de Educação a Distância, o(a) acompanhará durante todo este processo, pois conforme Freire (1996): “Os homens se educam juntos, na transformação do mundo”.

Os materiais produzidos oferecem linguagem dialógica e encontram-se integrados à proposta pedagógica, contribuindo no processo educacional, complementando sua formação profissional, desenvolvendo competências e habilidades, e aplicando conceitos teóricos em situação de realidade, de maneira a inseri-lo no mercado de trabalho. Ou seja, estes materiais têm como principal objetivo “provocar uma aproximação entre você e o conteúdo”, desta forma possibilita o desenvolvimento da autonomia em busca dos conhecimentos necessários para a sua formação pessoal e profissional. Portanto, nossa distância nesse processo de crescimento e construção do conhecimento deve ser apenas geográfica. Utilize os diversos recursos pedagógicos que o Centro Universitário Cesumar lhe possibilita. Ou seja, acesse regularmente o AVA – Ambiente Virtual de Aprendizagem, interaja nos fóruns e enquetes, assista às aulas ao vivo e participe das discussões. Além disso, lembre-se que existe uma equipe de professores e tutores que se encontra disponível para sanar suas dúvidas e auxiliá-lo(a) em seu processo de aprendizagem, possibilitando-lhe trilhar com tranquilidade e segurança sua trajetória acadêmica.

R O T U A

Professor Esp. Ricardo Francisco de Pierre Satin Graduado em Computação pela Universidade Estadual de Maringá (UEM) e MBA em Gerenciamento de Projetos pela FCV. Profissional certificado em gerenciamento de serviços de T.I. (ITIL) e, profissional certificado em gerenciamento de projeto pelo P.M.I. (profissional PMP). Trabalha com desenvolvimento de sistemas desde 1998 e, desde 2005, atua como gerente de projetos e possui ainda certificado PMP(Project Management Professional)..

APRESENTAÇÃO

DESIGN DE INTERAÇÃO SEJA BEM VINDO! Olá, caro(a) aluno(a)! É com prazer que apresento a você o livro que fará parte da disciplina de Design de Interação. Sou o professor Ricardo Francisco de Pierre Satin e preparei com muita dedicação este material para que você possa adquirir os conhecimentos necessários sobre esta matéria tão relevante. Asseguro-lhe que um dos itens de maior relevância no desenvolvimento de um novo produto é como se dará seu processo de interação. Meu objetivo ao escrever este livro foi trazer maior clareza a esta difícil tarefa de produzir sistemas que sejam realmente utilizados por nossos caros usuários. Neste tempo que tenho trabalhado na área de tecnologia da informação, posso assegurar-lhe que vi vários projetos interessantes, sistemas que se propunham a solucionar problemas graves, nunca “saírem da gaveta” por negligenciarem este aspecto tão importante que é tratado nesta disciplina. Comprometo-me a trazer para você informações que avalio ser transformadoras à sua forma de desenvolver sistemas, itens que tenho observado ao longo dos anos no desenvolvimento dos sistemas e os quais tenho levado aos meus clientes. Sendo assim, uma coisa quero pedir em troca: o seu empenho para este intenso trabalho. No decorrer das suas leituras, procure interagir com os textos, fazer anotações, estabelecer com suas atividades diárias, responder às atividades de autoestudo, anotarcorrelações suas dúvidas, complementar seus estudos com as indicações de leitura e realizar novas pesquisas sobre o assunto. Tenho certeza de que não será possível esgotar este tema apenas com este livro e por isso conto com sua pesquisa. Tendo a certeza de que terei sua dedicação, quero começar questionando-o(a): qual o segredo do sucesso no desenvolvimento de sistemas? O segredo é fazer algo de qualidade que seja útil, simples e usual. Espere encontrar nesta disciplina informações que vão lhe ajudar nos seguintes quesitos: como tornar sua aplicação mais usual e mais interativa, garantindo simplicidade e proporcionando uma visão de maior qualidade aos seus produtos. E para isso, começaremos na unidade I a entender mais sobre o que é design e interação, vamos estudar como ele pode contribuir para o sucesso da solução que você está propondo, vamos entender alguns tipos de design e para isso vamos navegar um pouco sobre a história computação. começar a ver quais osque critérios devem ser observados parada a criação de um Vamos bom design, vamos entender estes que critérios envolvem uma equipe competente e multidisciplinar, ou seja, não espere fazer tudo sozinho! Um bom design é trabalho de equipe. Caminhando para a unidade II, vamos entender mais um pouco sobre um dos componentes de maior relevância dentro do processo de design e interação, que é a interação humano-computador, vamos dar uma passada pelo processo de construção de interfaces e vamos entender um pouco sobre seu processo de evolução até sua chegada aos dias atuais. Não ficará de fora a compreensão sobre como as pessoas

APRESENTAÇÃO interagem com tais objetos, este é um critério importantíssimo ao qual você deve estar atento para que possa produzir sistemas com boa usabilidade, seja no desenvolvimento de soluções desktop, baseadas na web, ou móveis. Já na unidade III, vamos nos aprofundar nos fatores humanos envolvidos no processo de interação, quais os elementos psicológicos, qual a importância da memória (e seu funcionamento) no processo de construção de um bom design. Vamos também avaliar se é possível predizer se nosso padrão de design e interação está atingindo seus objetivos ou não, sendo a adoção de padrões de análise uma forma de avaliar este quesito. Assim, nesta unidade, iremos estudar o modelo GOMS juntamente com os modelos mentais. Entrando na unidade IV, vamos conhecer um pouco mais sobre o mundo da coleta e definição dos requisitos. Tão importante quanto entender mais sobre o funcionamento do ser humano em sua interação com o computador é conseguir mapear as necessidades de forma assertiva. Vamos avaliar algumas técnicas e ferramentas importantes, e você verá como poderão lhe apoiar em seu trabalho diário. E, por último, mas não menos importante, temos a unidade V, nela vamos entender um pouco mais sobre como podemos assegurar que estes requisitos se transformem em um sistema que seja útil, usual, simples e que agreguem valor ao seu usuário. Vamos relembrar um pouco sobre os modelos de desenvolvimento de software, desde os mais mais recentes e entender como alguns o processo design está inserido emclássicos cada umaos deles. É compromisso meu apontar riscosde que você possa estar correndo na escolha de um modelo ou outro para desenvolvimento, então, esteja atento! Uma vez que você tenha escolhido o melhor modelo de desenvolvimento de sistemas para sua necessidade, que possa contribuir para que um bom design seja construído, vamos entender como tudo isto pode ser mais bem controlado e, para isso, vamos ter uma breve visão de como o gerenciamento de projetos pode apoiarlhe a “blindar” o desenvolvimento da solução. Vamos entrar com um pouco mais de detalhes, validando como as metodologias ágeis podem apoiar o processo de design e, para isso, vamos entender como o processo de desenvolvimento proposto pelo Scrum nos auxiliará. Este material tem por objetivo principal expor assuntos pertinentes ao processo de design e interação, espero que sua leitura seja agradável e que, de alguma maneira, os tópicos abordados no decorrer dos seus estudos contribuam com sua vida pessoal e profissional. Antes de iniciar a leitura da primeira unidade, grave e reflita sobre o que Dale Carnegie nos tem a dizer. “Mantenha a mente aberta à mudança o tempo todo. Dê boas-vindas a ela. Corteje-a”. Tenha uma ótima e agradável leitura! Professor Ricardo

SUMÁRIO

UNIDADE I

CONCEITUANDO DESIGN E INTER AÇÃO 15

Introdução

17

Um Bom e um Mau Design

21

Histórico do Design de Interação

34

Equipe Multidisciplinar

39

Considerações Finais

UNIDADE II

ENTENDENDO MAIS SOBRE CRITÉRIOS DE USABILIDADE 43

Introdução

44

Interface/Interação Humano-Computador (IHC)

54

Interação Humano-Computador e Interface Humano-Computador são Sinônimos?

59

Como as Pessoas Interagem Com Objetos?

65

Usabilidade

70

Usabilidade na Web

75


SUMÁRIO

UNIDADE III

ENTENDENDO MAIS SOBRE OS FATORES HUMANOS ENVOLVIDOS 79

Introdução

80

A Psicologia da Interface Humano-Computador

89

Mecanismos da Percepção Humana

90

O Modelo Goms

93

Modelos Mentais

99


UNIDADE IV

IDENTIFICANDO AS NECESSIDADES E ESTABELECENDO OS REQUISITOS 103

Introdução

104

O Quê, Quem, Quando, Onde, Como e Por Quê?

108

O Que são Requisitos?

115

Como Coletá-los?

121

Como Interpretá-los e Analisá-los

127


SUMÁRIO

UNIDADE V

COLOCANDO TUDO ISTO PARA RODAR 131

Introdução

132

Entendendo sua Abordagem Junto aos Modelos de Produção de Software

138

Entendendo Design como Parte do Escopo de um Projeto

143

Entendendo seu Benefício no uso Conjunto com Metodologias Ágeis

152


155 157

CONCLUSÃO REFERÊNCIAS


CONCEITUANDO DESIGN E INTERAÇÃO

E D A D I N U

I

Objetivos de Aprendizagem ■ Compreender o que significa design de interação. ■ Entender a importância de um bom design. ■ Avaliar o que é um bom ou mau design. ■ Entender melhor o histórico da evolução do design de interação e quais os elementos envolvidos.

Plano de Estudo A seguir, apresentam-se os tópicos que você estudará nesta unidade:

■ Um bom e um mau design ■ Histórico do design de interação ■ Equipe multidisciplinar

INTRODUÇÃO Caro(a) aluno(a), já nesta primeira unidade você estudará um assunto muito interessante que contribuirá e muito com sua prática no desenvolvimento de sis-

. 8 9 9 1 e d o ir e r e v fe e d 9 1 e d 0 1 6 . 9 i e L e l a n e P o ig d ó C o d 4 8 1 . t r A . a d i b i o r p o ã ç u d o r p e R

temas. Para começar, quero refletir contigo sobre com o que em seu cotidiano você está envolvido, o que em seu dia a dia exige algum grau de interação? Avalie por alguns instantes, o que, em um dia normal, acaba exigindo algum grau de interação de sua parte: acredito que acilmente poderá listar elementos como teleone celular, computador, agenda eletrônica, erramenta de e-mail, erramentas de editoração de textos ou planilha, controle remoto (aqui você pode elencar uma infinidade deles, seja da televisão, do som do carro, do ar condicionado, do portão eletrônico...), máquina de rerigerantes, caé, caixa eletrônico, guichê eletrônico de venda de passagens, um sistema inormatizado de biblioteca, site de notícia, revista eletrônica ou em ormato convencional (impresso), otocopiadora, redes sociais, calculadora, rádio, videogame, erramentas de localização, painel de um veículo... É impressionante a quantidade de elementos que de alguma orma possuem um grau de interação conosco em um dia qualquer de nossas vidas, não é verdade? Por avor, quero lhe pedir uma segunda avaliação da lista acima: quais são realmente áceis e agradáveis de utilizar? É muito provável que esta grande lista seja sintetizada em um restrito grupo. Por que isto acontece? Caro(a) aluno(a), agora vamos avaliar outra situação, pense em alguma ocasião em que algum dos dispositivos acima tenha lhe causado algum tipo de transtorno, seja ele qual or, pense naquele dia que chegou atrasado ao trabalho devido ao ato de o alarme do despertador não ter disparado no horário que você “jurava” que tinha ajustado, pense no tempo que você gastou para azer o programa de gravação de CDs uncionar para copiar aquela música, ou gravar aquele filme. Volto à pergunta que fiz no parágrao anterior,por que isto acontece? Existe algo que está em nosso oco de controle que podemos azer a respeito dos casos mencionados acima? Muitas vezes, bens de consumo que são objetos de desejo estão ao nosso alcance financeiro, ainda mais devido ao momento econômico que vive o nosso país. Bens estes que estão tão próximos e tão longe ao mesmo tempo do nosso uso.

Introdução

I

Lembro-me de quando minha mãe comprou seu primeiro multiprocessador de alimentos (cerca de 20 anos atrás), era seu sonho aposentar tantos eletrodomésticos que tinha em casa e, em fim, desrutar da praticidade de ter tudo em um só lugar. Também me lembro de sua rustração ao tentar usar este produto pela primeira vez e ver que não seria tão prático como imaginava, não seria tão simples como aparentava ser e que não substituiria todos os antigos eletrodomésticos como supunha inicialmente. Acredito que até hoje deva estar em alguma prateleira acumulando poeira ou talvez tenha sido descartado, ato é que teve pouco ou nenhum uso. Existe uma lacuna muito grande entre o produto e seu eetivo uso. Preece (2005, p. 24) afirma: Muitos produtos que requerem a interação dos usuários para a realização de suas tarefas (p.ex.: comprar um ingresso pela Internet, fotocopiar um artigo, gravar um programa da TV) não foram necessariamente projetados tendo o usuário em mente; foram tipicamente projetados como sistemas para realizar determinadas funções. Pode ser que funcionem de maneira eficaz,do olhando-se perspectiva de engenharia, mas geralmente os usuários mundo realdaé que são sacrificados. O objetivo de design de interação consiste em redirecionar essa preocupação, trazendo a usabilidade para dentro do processo de design. Essencialmente isso significa desenvolver produtos interativos que sejam fáceis, agradáveis de utilizar e eficazes – sempre na perspectiva do usuário.

Nesta unidade, quero tratar contigo do que é design de interação, vamos avaliar as principais dierenças entre um bom e um mau design, e é objetivo meu que você possa ter condições de avaliar isto cotidianamente de orma a desenvolver seus sistemas ocando sob este aspecto de tamanha relevância para o sucesso ou racasso de um produto.

©shutterstock


R e p r o d u ç ã o

p r o ib id a . A r t . 1 8 4 d o C ó d i g o P e n la e L e i 9 . 6 1 0 d e 1 9 d e fe v e r e ir o d e 1 9 9 8 .

k c to s r e t t u h s ©


UM BOM E UM MAU DESIGN Há aqueles que dizem que design pode ser uma questão de “gosto”, predileção... Vamos ler juntos e ver se temos sua opinião modificada no final deste livro. Designs que permitem uma boa interação têm mudado a vida das pessoas, médicos estão podendo azer diagnósticos mais precisos, crianças estão evoluindo cada vez mais em nível de aprendizado, artistas estão conseguindo explorar mais seu lado criativo, vemos pilotos terem mais segurança para realizar seu trabalho e acompanhamos esta evolução chegar até nós, motoristas. Alguns veículos mais modernos já têm saído de ábrica com opcionais que permitem muito mais segurança aos motoristas, itens como visão noturna, projeção de comandos em dispositivos de tela de orma que o motorista não tenha que tirar o oco da estrada já está disponível e garantem uma maior segurança. Em contrapartida, vemos alguns exemplos de experiências perturbadoras e desastrosas, interações não planejadas adequadamente gerando rustração, medo, alhas que podem colocar a vida de pessoas em risco, gerar prejuízo financeiro, prejudicar o aprendizado, entre outras coisas.

Seus produtos acabam por causar uma boa impressão para seus usuários quando estão em uso?


TABLETS CAEM NO GOSTO DAS CRIANÇAS; SERÁ A NOVA BABÁ ELETRÔNICA? Por Bruno Romani Com pouco mais de dois anos de existência, o tablet caiu no gosto de meninos e meninas e muitas vezes tem uma função conhecida por “babá eletrônica”, antes ocupada pela TV. Em diversos países pesquisas mostram o quanto a criançada gosta do aparelho. Na Inglaterra, em levantamento da Duracell, 12% dos entrevistados com idades entre cinco e 16 anos disseram querer ganhar um tablet de presente. Bonecos e bonecas (7%) e bichos de pelúcia (5%) ficaram bem atrás. Só o celular (14%) vem à frente. Nos Estados Unidos, já no Natal do ano passado, 44% das crianças entre seis e 12 anos queriam ganhar um iPad de presente, apontou o instituto Nielsen. A tela sensível ao toque dos dedos (chamada de “touch screen”) é um convite ao uso. Há centenas de vídeos no YouTube com crianças se divertindo com o poder do próprio toque. Além disso, o tablet junta tudo o que os outros eletrônicos trazem. Tem vídeos, tchau TV. Tem jogos, adeus, videogame. E internet, até mais computador. MOUSE X CA DARÇO

A intimidade com tablets pode ser só mais uma característica da Geração Z, crianças que nasceram depois da popularização da internet. Uma pesquisa da empresa AVG feita em dez países, como Estados Unidos, França e Japão, mostra que a ligação com tecnologia começa cedo. Entre dois e cinco anos, há mais crianças que sabem jogar games (58%) do que nadar (20%) e amarrar cadarço (11%). Nessa idade, sabem usar um mouse (69%), abrir a internet (25%) e utilizar aplicativos (19%). É cedo para tanta tecnologia? A “Folhinha” reflete sobre isso neste caderno especial sobre o uso de tablets na infância. Disponível em: . Acesso em: 15 dez. 2015.

Baseado nisto, você pode me perguntar: Mas qual a preocupação central do design de interação? Segundo Preece (2005, p. 24) temos: “É desenvolver produtos interativos que sejam utilizáveis, o que genericamente significa produtos áceis de aprender, eficazes no uso, que proporcionem aos usuários uma expe-


riência agradável. Para evoluirmos mais sobre este assunto, baseando-nos em Preece (2005), vamos avaliar dois bons exemplos de produtos sobre o critério design de interação, um simples controle de mensagem pessoal. Você já deve ter visto uma secretária eletrônica, tenho por convicção que, se você nunca usou uma, ao menos deve ter visto uma em uncionamento, seja no trabalho, na casa de algum conhecido ou, com certeza, em algum filme. Apesar de “ultrapassada”, quem sabe você ainda tenha uma em sua casa e talvez você a mantenha em uso por alguns dos elementos que vamos analisar na sequência. Como vimos, talvez nem todos tenham uma secretária eletrônica em casa, mas com toda certeza a maioria das pessoas, senão todas, devem ter um aparelho celular. Uma das experiências mais rustrantes que tenho é acessar mensagens de voz que são deixadas em minha caixa postal quando alguém tenta alar comigo e não estou acessível no momento. Para escrever este livro, fiz uma experiência bastante simples, que oi deixar uma mensagem em minha caixa de entrada e comparar como seria se estivesse recebendo a mesma mensagem em uma secretaria eletrônica. Estabeleci alguns critérios simples que terão a unção de comparar como seria o processo de obtenção da inormação em ambos os aparelhos.

©shutterstock


I

CELULAR VOICEMAIL

Saber se tenho uma mensagem pendente de avaliação.

SECRE TÁRIA ELE TRÔNICA Tal informação não é disponibilizada facil- Sinal visual vermemente, vai depender do tipo de aparelho lho piscando. e até da operadora que estiver contratada. No meu caso, ao ligar o aparelho recebi um SMS informando que recebi ligações enquanto estava inacessível. Também recebi um informativo do Voice Mail, cerca de um minuto depois, que tinha uma nova mensagem. Após isto, passou a aparecer no meu celular um sinalizador informando que tenho mensagem pendente de avaliação.

No critério acima, julgo mais simples e mais rápido o formato da secretária eletrônica, apesar de o modelo apresentado pelo celular ter sido bastante simples. Saber a quantidade de

Aqui começamos um ponto importante. A primeira interaCerca de um minuto para saber “quantas” ção é informar o mensagens pendentes para leitura havia. O número de mensa-

mensagens pendentes de leitura.

tempo para “pular” mensagens até chegar à desejada foi enorme. Outra opção que avaliei foi a de “apagar” mensagens, em que o tempo para executar a ação é muito maior que na execução na secretária eletrônica manual.

gens pendentes. O Processo de “pular” sem ter que ouvir toda mensagem é muito mais rápido e prático.

O tempo de interação é muito maior, e ainda a falta de usabilidade, comparada com o formato antigo (secretária eletrônica), é muito grande. Outro ponto para a secretária tradicional. Fonte: Elaborado pelo Autor

Então vamos todos jogar ora nossos modernos aparelhos e voltar ao uso de secretárias antigas? Não precisamos ser radicais, apenas vamos procurar aprender, com este rico exemplo, como um mau design pode comprometer a satisação dos usuários. Este é um exemplo simples, vemos que o processo todo pode ser: ■ Irritante. ■ Conuso.




■ Ineficiente, exige muitos passos para TAREFAS BÁSICAS. ■ É diícil de utilizar. ■ Não permite saber rapidamente se há mensagens, quantas e como trocar a sequência (pular) entre elas. ©shutterstock


■ Dependendo do aparelho ou operadora, pode ficar mais diícil ainda o uso, pois os procedimentos não são tão óbvios. Se compararmos com nossa velha amiga secretária eletrônica, vemos: ■ Utiliza elementos ísicos amiliares que indicam visualmente, de orma rápida, aquilo que precisamos saber. ■ É esteticamente ácil e agradável de utilizar. ■ Requer ações de apenas um passo para realizar tareas importantes. ■ Design simples, mas elegante. ■ Oerece menos uncionalidade e permite a qualquer um ouvir asmensagens.

HISTÓRICO DO DESIGN DE INTER AÇÃO Caro(a) aluno(a), para seu sucesso profissional, é importante que você seja conhecedor de diversas áreas ligadas à sua carreira escolhida. Sou deensor de que você, para ser um bom (boa) profissional, necessita ser especialista em um assunto, mas precisa ter um bom conhecimento (generalista) em diversas áreas relacionadas ao assunto que domina.


I

Quantos passos seus usuários precisam dar para utilizar seus produtos? Em se tratando de sistemas, quantos passos o usuário precisa dar para extrair uma simples informação? Aquilo que é realmente importante para seu usuário está acessível rápida e intuitivamente como o sinalizador de mensagem da secretaria eletrônica? Considere quem irá utilizar seus sistemas, onde farão uso dele. Entenda que tipo de atividades as pessoas estarão realizando e em que condições quando estiverem interagindo com seus produtos.

Fazendo uma analogia com a medicina, é importante que sejamos especialistas em uma área, que tenhamos total conhecimento em um determinado assunto como um médico cardiologista, entretanto, é relevante que tenhamos um conhecimento geral de outras áreas da medicina para que possamos exercer com mais segurança nossa profissão. Desta orma, para que seja um bom desenvolvedor, é importante ter um conhecimento “interessante” sobre as regras de negócio que estarão por você sendo desenvolvidas, da mesma orma, é importante ter um bom conhecimento sobre os elementos de arquitetura que devem ser observados no seu desenvolvimento, pois assim poderá prever possíveis impactos de desempenho e disponibilidade de sua aplicação. Quando alamos de design de interação não é dierente. Até este ponto, você já deve ter percebido que existem vários elementos relacionados ao sucesso da satisação dos nossos usuários com nossos produtos. No decorrer deste livro, ficará mais claro assim como você poderá mapeá-los e tratar de orma que não seja um problema. ©shuterstock




Para o sucesso em design de interação, desde o início é conhecido que se trata de uma área multidisciplinar. Preece (2005, p.28) afirma: “A importância de se entender

. 8 9 9 1 e d o ir e r e v fe e d 9 1 e d 0 1 6 . 9 i e L e l a n e P o ig d ó C o d 4 8 1 . t r A . a d i b i ro p o ã ç u d o r p e R

como os usuários agem e reagem a situações e como se comunicam e interagem acarretou o envolvimento de pessoas de disciplinas dierentes, como psicólogos e sociólogos, em questões reerentes ao design de interação”. Muitas vezes, pessoas dierentes reagem de orma distinta a um mesmo estímulo. Ou ainda pior, uma mesma pessoa pode reagir de orma distinta a um mesmo estímulo em situações dierentes! Como já trabalhamos neste livro, muitos produtos são criados sem avaliar a pessoa que irá usar este. Nos primórdios da computação, o mais ©shutterstock importante era o hardware, o meio pelo qual a interação se daria com estes equipamentos pouco importava (pois na grande maioria das vezes, qualquer tipo de interação só se dava por meio dos próprios engenheiros que projetavam estes equipamentos). Sendo assim, muitas vezes o que víamos era algo muito parecido com um painel repleto de chaves e luzes piscando que, para qualquer usuário nos dias de hoje, daria arrepios, mas para eles que haviam projetado e interagiam com o “sistema” tinha total sentido, significado e atendia à sua necessidade de interação. Apenas no final da década de 70 e início da década de 80 é que o design de interação oi algo que começou a ser de ato considerado com o advento das estações de trabalho e com o surgimento dos monitores. Quando alamos de projetar sistemas que sejam manipulados por pessoas, vamos alar ortemente de Design e Interação. O campo interdisciplinar mais conhecido e que será tratado nos próximos módulos deste livro é a interação humano-computador (IHC). Este campo está bastante ocado no design, na avaliação e na implementação de sistemas computacionais interativos para uso humano e com o estudo de enômenos que aetam este grupo. Histórico do Design de Interação

I


© Metamorfose Digital

Até início dos anos 90, seu oco (IHC) era projetar interaces para um único usuário. A grande maioria dos sistemas produzidos até então tinham oco no trabalho centralizado. Com o aumento da necessidade de trabalho em grupo, de interação entre elementos, da separação de trabalho, com a descentralização das tareas e das ações surgiu um novo elemento, outro campo interdisciplinar que envolve o processo de design e interação, que é o CSCW, em inglês, computer suported cooperative work. Outros campos relacionados a design de interação incluem atores humanos, ergonomia, psicologia, ciência cognitiva... E vamos tratar com mais detalhes nos próximos módulos. A figura da página a seguir nos dá uma visão mais clara do conjunto de elementos envolvidos no processo de Design e Interação.

©shutterstock



Figura 1 – Mapa mental sobre os elementos envolvidos no design de interação


Fonte: Adaptação de Preece (2005, p. 29)

A seguir, um breve resumo das áreas mais relevantes descritas na figura 1. ELEM ENTO Ciência da Computação

IN FLUÊNCIA Quando falamos de ciência da computação, estamos falando exatamente da área que estuda todos os avanços tecnológicos. Provê avanços que permitam que novas soluções sejam criadas, seja através do desenvolvimento de uma nova linguagem ou novas ferramentas que possam ser utilizadas por design para prover melhores soluções ao usuário final.

Psicologia Cognitiva

A psicologia é parte importante no processo de Design e Interação, entender o comportamento humano, os padrões deste é parte fundamental para um bom design. Tem sido muito importante suas pesquisas ligadas à percepção, atenção, memória, aprendizagem, solução de problemas. Como as pessoas trabalham, se organizam como equipe, como utilizam computadores. Estimular a aprendizagem e aperfeiçoar o desempenho humano.

Psicologia Social

Seu principal foco é estudar o comportamento humano e como isto pode influenciar em nosso objeto de estudo. A tecnologia acaba por gerar um impacto interessante no comportamento humano, extrair o melhor é necessário para a redução de conflitos e criação de um ambiente colaborativo.


I

ELEM ENTO Fatores Humanos / Ergonomia

IN FLUÊNCIA Maximizar a segurança, eficiência, confiabilidade e desempenho do usuário, tornando as tarefas mais fáceis e aumentar o sentimento de conforto e satisfação. São quesitos de grande relevância para um bom design ser considerado.

Tamanho de que tela,precisamos tamanho depensar fonte,quando númerofalamos de clicks,neste são alguns itens assunto... Que podem ser critérios importantes para aceitação do usuário ou não frente ao sistema. Ciências Sociais Não existe envolvimento direto no desenvolvimento do design, mas sim com a transferência desta tecnologia. Entender o que acontece com as pessoas enquanto elas se comunicam entre si ou com máquinas. Analisar este processo antes, durante e depois. É de extrema importância quando existe a necessidade de trabalho cooperativo através do uso de sistemas computacionais. Engenharia de Software

A engenharia de software é peça fundamental na construção de aplicações que estejam antenadas a um bom design de interação. Dará o subsídio para que uma ideia saia do papel e vire um sistema.

Fonte: Preece (2005)



Quantas telas de sistema que desenvolvemos hoje em dia são vistas por nossos usuários exatamente iguais aos painéis de manipulação dos grandes mainframes dos primórdios da computação?


A EVOLUÇÃO DOS COMPUTADORES Por Renan Hamann Você sabia que computadores já chegaram a pesar 30 toneladas e custar dois milhões de dólares? Conheça mais sobre a história da informática. Não é segredo que o seu computador atual é fruto de uma evolução que levou décadas para chegar onde está – e ainda está muito longe de chegar ao seu final. Se pensarmos que cerca de dez anos atrás os processadores ainda nem conheciam os núcleos múltiplos, imaginar as máquinas que inauguraram a informática é uma tarefa ainda mais complicada. Você sabia que no início da década de 1950 já existiam computadores? Logicamente eles não se pareciam nem um pouco com o que temos hoje, mas já realizavam alguns cálculos complexos em pouquíssimo tempo. De lá para cá, elementos desapareceram, componentes foram criados e parece até que estamos falando de assuntos totalmente desconexos. Então se prepare para conhecer um pouco mais sobre essa magnífica história. Para facilitar a leitura, atendemos às divisões de alguns autores especializados no assunto separamos história daa importante informática evolução em gerações. Agora aproveite para aprenderemais ou paraa conhecer dos computadores.

AS GIGANTES VÁLVULAS DA PRIMEIRA GERAÇÃO Imagine como seria sua vida se você precisasse de uma enorme sala para conseguir armazenar um computador. Logicamente isso seria impossível, pois os primeiros computadores, como o ENIAC e o UNIVAC eram destinados apenas a funções de cálculos, sendo utilizados para resolução de problemas específicos. Por que problemas específicos? Os computadores da primeira geração não contavam com uma linguagem padronizada de programação. Ou seja, cada máquina possuía seu próprio código e, para novas funções, era necessário reprogramar completamente o computador. Quer mudar o problema calculado? Reprograme o ENIAC.

Esses computadores gigantescos ainda sofriam com o superaquecimento constante. Isso porque em vez de microprocessadores, eles utilizavam grandes válvulas elétricas, que permitiam amplificação e troca de sinais, por meio de pulsos. Elas funcionavam de maneira correlata a uma placa de circuitos, sendo que cada válvula acesa ou apagada representava uma instrução à máquina. Com poucas horas de utilização, essas válvulas eram queimadas e demandavam substituição. Por isso, a cada ano eram trocadas cerca de 19 mil delas em cada máquina. Sim, 19 mil válvulas representavam mais do que o total de componentes utilizados por um computador ENIAC. Como você pode perceber, esses computadores não saíam baratos para os proprietários.

TRANSISTORES E A REDUÇÃO DOS COMPUTADORES As gigantes máquinas não estavam sendo rentáveis, pelos constantes gastos com manutenção. A principal necessidade era substituir as válvulas elétricas por uma nova tecnologia que permitisse um armazenamento mais discreto e não fosse tão responsável pela geração de calor excessivo, evitando superaquecimentos. Foi então que os transistores (criados em 1947 pela empresa Bell Laboratories) passaram a integrar os painéis das máquinas de computar. Os componentes eram criados a partir de materiais sólidos conhecidos como “Silício”. Exatamente, os materiais utilizados até hoje em placas e outros componentes, extraídos da areia abundante. Existia uma série de vantagens dos transistores em relação às válvulas. Para começar: as dimensões desses componentes eram bastante reduzidas, tornando os computadores da segunda geração cem vezes menores do que os da primeira. Além disso, os novos computadores também surgiram mais econômicos, tanto em questões de consumo energético, quanto em preços de peças.

Para os comandos desses computadores, as linguagens de máquina foram substituídas por linguagem Assembly. Esse tipo de programação é utilizado até hoje, mas em vez de ser utilizado para softwares ou sistemas operacionais, é mais frequente nas fábricas de demais hardware, lharcomponentes com instruções diretas.por trabaEm vez das 30 toneladas do ENIAC, o IBM 7094 (versão de maior sucesso dessa segunda geração de computadores) pesava apenas 890 Kg. E por mais que pareça pouco, essa mesma máquina ultrapassou a marca de 10 mil unidades vendidas. Curiosidade: os computadores dessa segunda geração foram inicialmente desenvolvidos para serem utilizados como mecanismos de controle em usinas nucleares. Um modelo similar pode ser visto no desenho “Os Simpsons”, mais especificamente no posto de trabalho deHomer, técnico de segurança na Usina Nuclear.

MINIATURIZAÇÃO E CI RCUITOS INTEGRADOS O emprego de materiais de silício, com condutividade elétrica maior que a de um isolante, mas menor que a de um condutor, foi chamado de semicondutor. Esse novo componente garantiu aumentos significativos na velocidade e eficiência dos computadores, permitindo que mais tarefas fossem desempenhadas em períodos de tempo mais curtos.

Com a terceira geração dos computadores, surgiram também os teclados para digitação de comandos. Monitores também permitiam a visualização de sistemas operacionais muito primitivos, ainda completamente distantes dos sistemas gráficos que conhecemos e utilizamos atualmente. Apesar das facilidades trazidas pelos semicondutores, os computadores dessa geração não foram reduzidos, sendo que um dos modelos de mais sucesso (o IBM 360, que vendeu mais de 30 mil unidades) chegava a pesar mais do que os antecessores. Nessa época (final da década de 1970 e início da década de 1980) os computadores passaram a ser mais acessíveis. Outro grande avanço da terceira geração foi a adição da capacidade de upgrade nas máquinas. As empresas poderiam comprar computadores com determinadas configurações e aumentar as suas capacidades de acordo com a necessidade, pagando relativamente pouco por essas facilidades.

MICROPROCESSADORES: O INÍCIO DOS COMPUT ADORES PESSOAIS Enfim chegamos aos computadores que grande parte dos usuários utiliza até hoje. Os computadores da quarta geração foram os primeiros a serem chamados de “microcomputadores” ou “micros”. Esse nome se deve ao fato de eles pesarem menos de 20 kg, o que torna o armazenamento deles muito facilitado. Você consegue imaginar qual o componente que tornou possível essa redução das máquinas? Acertou quem disse que foram os microprocessadores. O surgimento dos pequenos chips de controle e processamento tornou a informática muito mais acessível, além de oferecer uma enorme gama de novas possibilidades para os usuários. Em 1971, já eram criados processadores com esse novo formato, mas apenas na metade da década começaram a surgir comercialmente os primeiros computadores pessoais. O Altair 8800 podia ser comprado como um kit de montar, vendidos por revistas especializadas nos Estados Unidos. Foi com base nessa máquina que Bill Gates e Paul Allen criaram o “Basic” e inauguraram a dinastia Microsoft.

A IMPORTÂNCIA DA APPLE Na mesma época, os dois Steves da Apple (Jobs e Wozniac) criaram a empresa da Maçã para se dedicarem a projetos de computação pessoal facilitados para usuários leigos. Assim surgiu o Apple I, projeto que foi

primeiramente apresentado para a HP. Ele foi sucedido pelo Apple II, após uma injeção de 250 mil dólares pela Intel. Essa segunda versão dos computadores possuía uma versão modificada do sistema BASIC, criada também pela Microsoft. O grande avanço apresentado pelo sistema era a utilização de interface gráfica para alguns softwares. Também era possível utilizar processadores de texto, planilhas eletrônicas e bancos de dados. Essa mesma Apple foi responsável pela inauguração dos mouses na computação pessoal, juntamente com os sistemas operacionais gráficos, como o Macintosh. Pouco depois a Microsoft lançou a primeira versão do Windows, bastante parecida com o sistema da rival.

E OS CICLOS TORNAM SE CLOCKS Até a terceira geração dos computadores, o tempo de resposta das máquinas era medido em ciclos. Ou seja, media-se um número de ações em curtos períodos de tempo para que fosse possível saber qual fração de segundo era utilizada para elas. Com os microprocessadores, já não era viável medir as capacidades dessa forma. Por isso surgiram as medidas por clocks. Esta definição calcula o número de ciclos de processamento que podem ser realizados em apenas um segundo. Por exemplo: 1 MHz significa que em apenas um segundo é possível que o chip realize 1 milhão de ciclos. Grande parte dos computadores pessoais lançados nessa época eram alimentados por processadores da empresa Intel. A mesma Intel que hoje possui alguns dos chips mais potentes, como o Intel Core i7. Como você pode saber, estas máquinas são muito leves e puderam ser levadas a um novo patamar.

NOTEBOOK S: A QUARTA GERAÇÃO PORTÁ TIL Considerando o progresso da informática como sendo inversamente proporcional ao tamanho ocupado pelos componentes, não seria estranho que logo os computadores transformassem-se em peças portáteis. Os notebooks surgiram como objetos de luxo (assim como foram os computadores até pouco mais de dez anos), sendo caros e de pouca abrangência comercial. Além dos notebooks, temos também os netbooks disponíveis no mercado. Estes funcionam de maneira similar aos outros, mas geralmente possuem dimensões e configurações menos atraentes. Ganham pontos pela extrema portabilidade e duração das baterias utilizadas, sendo certamente um degrau a mais na evolução dos computadores.

Hoje, o preço para se poder levar os documentos, arquivos e programas para todos os lugares não é muito superior ao cobrado por desktops. Mesmo assim, o mercado ainda está longe atingir o seu ápice. Quemde sabe qual será o próximo passo da indústria?

MÚLTIPLOS NÚC LEOS: A QUINTA GERAÇÃO? Ainda estamos em transição de uma fase em que os processadores tentavam alcançar clocks cada vez mais altos para uma fase em que o que importa mesmo é como podem ser melhor aproveitados esses clocks. Deixou de ser necessário atingir velocidades de processamento superiores aos 2 GHz, mas passou a ser obrigatório que cada chip possua mais de um núcleo com essas frequências. Chegaram ao mercado os processadores que simulavam a existência de dois núcleos de processamento, depois os que realmente apresentavam dois deles. Hoje, há processadores que apresentam quatro núcleos, e outros, utilizados por servidores, que já oferecem oito. Com tanta potência executando tarefas simultâneas, surgiu uma nova necessidade.

PROCESSAMENTO VERDE Sabe-se que, quanto mais tarefas sendo executadas por um computador, mais energia elétrica seja consumida. Para combater essa máxima, as empresas fabricantes de chips passaram a pesquisar formas de reduzir o consumo, sem diminuir as capacidades de seus componentes. Foi então que nasceu o conceito de “Processamento Verde”. Por exemplo: os processadores Intel Core Sandy Bridge são fabricados com a microarquitetura reduzida, fazendo com que os clocks sejam mais curtos e menos energia elétrica seja mesmo tempo, esses processos são mais eficazes.e Logo, a realização degasta. tarefasAo com esse tipo de componente é boa para o usuário também para o meio ambiente. Outro elemento envolvido nessas conceituações é o processo de montagem. As fabricantes buscam, incessantemente, formas de reduzir o impacto ambiental de suas indústrias. Os notebooks, por exemplo, estão sendo criados com telas de LED, muito menos nocivos à natureza do que LCDs comuns. .....

Não sabemos ainda quando surgirá a sexta geração de computadores. Há quem considere a inteligência artificial como sendo essa nova geração, mas também há quem diga que robôs não fazem parte dessa denominação. Porém, o que importa realmente é perceber, que ao longo do tempo, o homem vem trabalhando para melhorar cada vez mais suas máquinas. Quem imaginava, 60 anos atrás, que um dia seria possível carregar um computador na mochila? E quem, hoje, imaginaria que 60 anos atrás seria necessário um trem para carregar um deles? Hoje, por exemplo, já existem computadores de bolso, como alguns smartphones que são mais poderosos que netbooks. Disponível em: . Acesso em: 25 jan. 2016.

I

©shutterstock

EQUIPE MUL TIDISCIP LINAR Antes de nos aproundamos neste tema, vamos voltar um pouco ao tópico anterior. Se pensarmos que os primeiros computadores começaram exigindo uma simples e limitada orma de interação em que a única maneira de manipulação era um painel de chaveamento com manipulação restrita aos engenheiros, hoje exigir um conjunto tão extenso de itens de análise e verificação parece algo exagerado, mas na verdade não é. Devemos imaginar que a área de sofware é apenas uma que exige a necessidade de interação (como pudemos ver no início da primeira unidade) e, a partir do momento que saio de algo de uso restrito (como eram os computadores no seu advento) e trago para algo de uso comum, é mais do que uma expectativa de que temas relacionados a design sejam considerados, é uma premissa. Para tanto, nesta perspectiva, precisamos entender que o desenvolvimento de soluções vai exigir uma orte interação entre diversas pessoas em uma equipe. Ter diversas pessoas pensando no mesmo assunto significa que surgirão muito mais ideias, muito mais métodos novos de se azer as coisas, designs muito mais criativos e srcinais. Bem, nem tudo é um “mar de rosas”, precisamos entender que todo este conjunto de criatividade, srcinalidade e afins tem seus aspectos nem tão positivos assim, como: 1. Custo: ter uma equipe multidisciplinar como a proposta requer mais pessoas para meu projeto, mais pessoas representam maior investimento, maior investimento vai exigir um valor maior na revenda do




meu produto que talvez o torne inviável. Tenho acompanhado várias empresas que atuam no desenvolvimento de sistemas e são raras aquelas que mantêm uma equipe multidisciplinar, o que tenho visto com mais requência naquelas que estão procurando cuidar destes atores é ter membros da equipe que buscam conhecimento nestas áreas rela-


cionadas e com issoopção estão mais preparados para lidar com(generalistas) estas demandas. Outra que tenho verificado é empresas que criam comitês de avaliação que são acionados durante uma ase do projeto em que o processo de design é mais exigido. Por exemplo: uma empresa que possui alguém da área de psicologia trabalhando no RH pode compartilhar ©shutterstock esta pessoa durante uma ase do projeto, assim há contribuição e redução de custos andando de mãos dadas. O grande segredo está em compartilhamento de recursos de orma gerenciável. 2. Conflito: é praticamente impossível que duas pessoas pensem da mesma orma, quando são de áreas dierentes. que é importante para umainda podemais não ser importante para outro... cadaOser humano cresce e vê o mundo com um filtro que vem sendo ormado desde sua criação, apesar de um grande conjunto de atores que podemos classificar de verdades universais, ainda assim, cada um tem a liberdade de escolha para decidir o que quer de sua vida , assim como para analisar as coisas. Um simples exemplo de como duas pessoas podem divergir de opinião pode ocorrrer com relação à beleza. Quando temos pessoas de áreas dierentes trabalhando em um mesmo projeto, é importante ter em mente que divergências de opinião vão surgir, é natural e extremamente produtivo que isto ©shutterstock ocorra. Saber gerenciar isto é o segredo para extrair o que cada visão tem de melhor e, com isto, construir algo que seja definitivamente satisatório para o usuário final.


I

3. Comunicação: devemos entender que quanto maior o número de pessoas envolvidas no processo maior é o número de canais de comunicação que teremos que gerenciar. Para poder melhor exemplificar isto, vamos imaginar que a equipe é ormada por apenas duas pessoas, neste caso existe apenas um canal de comunicação que precisa ser de gerenciado (justamente entre osde dois elementos). Quando o número pessoas aumenta, o número canais cresce consideravelmente, veja o exemplo a seguir. R e p r o d u ç ã o

p r o ib id a . A r t . 1 8 4 d o C ó d i g o P e n

Fonte: Elaborado pelo autor

A órmula é bastante simples,(n² - n) / 2 , sendo n = número de pessoas que azem parte da minha equipe. Outro ponto importante para nossa avaliação é o ruído que pode haver na comunicação entre as pessoas.

Quais recursos de sua empresa poderiam ser melhor aproveitados para construir uma equipe multidisciplinar gerenciável!


la e L e i 9 . 6 1 0 d e 1 9 d e fe v e r e ir o d e 1 9 9 8 .

Toda comunicação se dá de uma maneira ormal ou inormal e ocorre por meio de um canal (e-mail, carta, teleone, ala...). Esta orma de comunicação e este canal são suscetíveis a ruídos, ou seja, alhas de


interpretação por uma das partes. Acredito que você já tenha participado de uma brincadeira na época do colégio chamada “teleone sem fio”, em que um grupo de pessoas ficam reunidas em fila e um conteúdo (uma pequena história) é contada e passada a cada participante que está participando da brincadeira. Geralmente, a mensagem que chega até o último elemento desta fila é bem dierente da que oi srcinalmente mencionada ao primeiro. Este é um simples, mas prático, exemplo de como a inormação se perde no meio de uma comunicação, e imagine como isto pode repercutir negativamente no processo de design de uma solução! Cada vez mais as empresas têm se preocupado com a maneira como Design tem contribuído, ou não, para o bom andamento das vendas de suas empresas. Recordo-me de um cliente que investiu pesado na criação de um novo produto. A área de marketing teve um orte envolvimento com a área comercial da empresa para a criação de uma campanha de lançamento que despertasse o interesse dos atuais consumidores e novos. Posso dizer que o objetivo oi alcançado, no dia do lançamento deste novo produto vários clientes acessaram o site da empresa para garantir a compra do produto, contudo, muitos deles ficaram rustrados pelo ato de não conseguirem finalizar suas compras.


I

Perceba como a informação pode se perder e como é importante cuidar de que todos estejam realmente falando a mesma língua! Quais são seus cuidados para que a solicitação de seu cliente chegue ao final da cadeia de comunicação e não se perca?

Junto com o lançamento do novo produto, a empresa julgou que seria importante colocar “no ar” seu novo e-commerce. O que parecia uma boa ideia logo se transormou em um pesadelo. O tempo para que novos clientes e atuais conseguissem se adaptar ao novo sistema não oi tão rápido assim, azendo com que muitos desistissem de realizar a compra do novo produto pela dificuldade de interação com o novo site.

Novo formato de interação, novo formato de comunicação projetado pela Google– Google Glasses. . Acesso em 25 jan. 2016

Visão de futuro da Microsoft para nosso formato de interação – como será o futuro! . Acesso em 25 jan. 2016




CONSIDERAÇÕES FINAIS No decorrer desta primeira unidade, estudamos sobre a importância do design de interação e pudemos entender como ele é relevante na vida das pessoas e qual


sua relação com o sucesso ou racasso de diversos produtos. Um dos pontos mais importantes está no ato de que produtos têm que ser criados pensando em quem irá realmente usá-los no seu cotidiano. Inelizmente, vimos que muitas vezes criamos produtos e esquecemos deste detalhe undamental, não é de se admirar que tantos e tantos produtos são criados e não chegam a sair da “gaveta”. Estamos vivendo mais do que a era da internet, estamos vivendo na era da comunicação mobile, e isto representa que qualquer pessoa em qualquer lugar é um cliente potencial. Significa também que a alha ou a alta de um design adequado/apropriado será um ator preponderante para o sucesso ou racasso dos negócios. Avaliamos nesta unidade como oi o processo de evolução da computação, como inicialmente os critérios de interação eram limitados, pois a necessidade de interação homem-máquina era restrita. Com o crescimento da computação pessoal, a partir do final da década de 70, vimos um crescimento do interesse nesta área. Começamos a estudar a necessidade de envolvimento de uma equipe multidisciplinar na construção de produtos e o mesmo se aplica para a criação de sistemas. Um dos maiores limitadores é o alto custo da manutenção de uma equipe como esta, mas ressaltei também que devemos procurar com criatividade, planejamento e gerenciamento usar os melhores recursos que temos à nossa disposição e assim prover para nossos clientes a melhor solução possível. Na próxima unidade, darei mais detalhes sobre os critérios de usabilidade e quais atores devem ser considerados com maior atenção durante o processo de construção de um projeto de interaces com o usuário, elemento este que é componente do processo de design e interação.


1. Na realidade das empresas de sistemas de sua região, quais opções você avalia que poderiam ser consideradas para que os elementos relacionados a design de interação fossem considerados no desenvolvimento

de seus produtos?

2. Quando falamos de uma equipe multidisciplinar para a construção de soluções, quais os elementos (pessoas) que você avalia imprescindí-

veis para sua empresa?

3. Descreva como foi o processo de evolução da computação das últimas décadas e como a necessidade de interação evoluiu neste período.


ENTENDENDO MAIS SOBRE CRITÉRIOS DE USABILIDADE

E D A D I N U

II

Objetivos de Aprendizagem ■ Entender a importância do bom desenvolvimento de uma interface para propiciar a interação humano-computador. ■ Avaliar como as pessoas interagem com objetos e como isto pode ser utilizado em meu processo de desenvolvimento de design e interação. ■ Compreender o que é usabilidade e sua aplicação no desenvolvimento de aplicações WEB.


■ O que é interface e Interação Humano-Computador (IHC) ■ Como as pessoas interagem com objetos ■ Usabilidade ■ Usabilidade na WEB

INTRODUÇÃO Caro(a) aluno(a), nesta segunda unidade, vamos evoluir sobre os conceitos de design e interação, só que agora vamos nos aproundar especificamente sobre


o componente que classifico mais importante, que é a interação humano-computador (IHC). Vamos tratar sobre os princípios de usabilidade que tornam as aplicações mais áceis de usar e vamos explorar os conceitos ligados a aplicações tradicionais (desktop) baseadas na internet assim como aplicações móveis. Nosso universo competitivo exige que cada vez mais açamos mais com menos, ou seja, sejamos mais produtivos, mais ágeis, açamos produtos com maior qualidade, tudo isto sem que haja necessidade de incharmos as organizações. Recordo-me de uma empresa que estava em processo de expansão e que, como parte do processo, decidiu pela troca do sistema de gestão que utilizava por outro mais atual. Esta empresa, apesar de lucrativa, era bastante ineficiente em seu setor administrativo, precisando de uma quantidade relativamente grande de uncionários para que todo processo de retaguarda (controle financeiro, estoque, fiscal, contábil...) pudesse ser executado. Um dos principais beneícios que a empresa teve na troca do sistema oi o ganho de agilidade nas atividades diárias de sua equipe. Este ganho de agilidade estava intimamente relacionado aos beneícios que a usabilidade do novo sistema trouxe à empresa. Ser mais rápido, mais intuitivo, acilitar o aprendizado são ortes princípios de usabilidade que a interação humano-computador deve cuidar. Recordo-me de outra grande empresa que era obrigada a manter uma equipe de treinamento para requentemente capacitar novos colaboradores da empresa no sistema que utilizava. Não vejo nada de errado em uma empresa ter uma equipe como esta, na verdade pode até se tornar um dierencial competitivo rente às concorrentes se esta estiver ocada, por exemplo, na melhoria do conhecimento dentro da empresa, otimização de processos, apoiar áreas a reduzir o tempo de trabalho em rotinas operacionais, apoiar na extração de inormações para tomada de decisões estratégicas. O que não poderia ocorrer, contudo, era a manutenção de uma equipe como aquela, pois o sistema que possuía era tão complexo que dificultava o aprendizado de um colaborador novo.

Introdução

II

Veja como alhas de design podem custar caro para empresas e pode ser ainda pior se avaliarmos o critério cliente. Como vimos na unidade anterior, empresas podem estar deixando de fidelizar clientes e de realizar novas vendas pelo simples ato de ser diícil navegar em seu site/sistema. Recordo-me de uma vez que desisti de comprar um livro no site de uma editora e optei por comprar em outra, pagando um rete maior, pelo simples ato de não aguentar mais começar a azer o pedido “tudo de novo”, pois requentemente alguma coisa inesperada acontecia e me azia perder todos os dados já inseridos. R e p r o d u ç ã o

INTERF ACE/INTERAÇÃO HUMANO COMPUT ADOR IHC Primeiramente precisamos dierenciar uma coisa da outra. Interace humanocomputador não é a mesma coisa que interação humano-computador. Podemos resumir que a interace humano-computador é um dos meios pelo qual ocorre a interação humano-computador. De acordo com Rocha (2003), quando o conceito de interace surgiu era ocado em prover um meio de comunicação de hardware e o sofware com o qual o homem e computador poderiam se comunicar. Com o passar do tempo, este conceito evoluiu, vimos que há necessidade de atenção em aspectos como capacidade cognitiva e emocional dos usuários durante este processo de comunicação. Precisamos prover interaces que possam dar maior poder ao usuário final, mas este poder tem que ser de ácil aplicação. Um bom exemplo são os pacotes de edição de texto ou planilhas eletrônicas. Quando migrei a versão do meu Office 2003 para o Office 2007, tive um pequeno choque com a mudança dos locais dos ícones e uncionalidades, mas rapidamente me adaptei. Minha primeiraimpressão oi de rejeição, já estava acostumado com as teclas de atalho, com o local onde as uncionalidades estavam. Exatamente no dia em que atualizei a versão, precisei utilizar o Excel, tratava-se de algo urgente, precisava entregar uma planilha para meu chee. A




©shutterstock

minha primeira impressão oi ruim, em um primeiro acesso não encontrava mais nada! Aos poucos me adaptei e consegui tirar proveito dos beneícios que a nova interace propiciou. Conheço pessoas que até hoje têm dificuldade com a nova interace, pois como o uso da erramenta é básico, as mudanças e evolução não lhe trouxeram nenhum proveito, apenas conusão por mudar de lugar “aquilo que já uncionava” pereitamente. Quando tratamos de interace, temos que tomar este cuidado, não gerar apercepção ao usuário de que tudo que oi eito oi estragar o que já uncionava antes. Antes de continuar, precisamos entender um pouco sobre como oi a evolução deste ormato de interação até chegar os dias atuais. No início, na época dos primeiros computadores, a interace de comunicação entre homem e computador se dava por meio de chaves e mostradores. O uso de cartões perurados oi um avanço neste ormato de comunicação até chegar às primeiras ormas de interace via linha de comando, em que, mediante de instruções digitadas, operações eram disparadas. As primeiras interaces orientadas por menu eram bem simples, textuais, como uma orma de organizar hierarquicamente as operações possíveis. Este oi um passo undamental para o estabelecimento de um conceito de que homem e máquina necessitam, para “conversar”, de uma interace de comunicação, esta que começa a se estabelecer como sendo uma “tela de sistema”. Hoje, usamos ormas de interace que evoluíram deste ormato.


II

Os primeiros computadores Macintosh da Apple estabeleceram um conceito que é quase impossível de desassociar de interace homem-computador, que é uma interace baseada em ícones, menus, barras de rolagem, cursores que mudam de ormato. São, sem dúvida, um avanço no que diz respeito do ormato de interação, mas IHC é bem mais do que isto.



Este ormato de interace utilizado pelaApple é também ortemente diundido pela Microsof em suas versões do sistema operacional Windows, cujo nome é uma metáora que az alusão à acilitação do trabalho a ser executado pelo usuário.


É evidente que o usuário em uma operação em que tem que transerir parte de um texto, digitado inicialmente em uma página para outra página do documento, azendo uso do


comando copiar e colar não vai azer uso de nenhum recurso que venha a “colar” fisicamente o texto, mas é uma menção a algo que estamos acostumados no dia a dia de que tem o objetivo de acilitar o entendimento do que se espera que seja eito com tal instrução. ©shutterstock

Que recursos você tem usado para facilitar a compreensão do usuário para usar seu sistema de forma mais eficiente?


A HISTÓRIA DA INTERFACE GRÁFICA Por Felipe Arruda A forma como os humanos interagem com os computadores sempre foi uma preocupação dacomando, indústria da algumasem décadas, essa interação passouque da linha de eminformática. modo texto,Durante para desktops três dimensões e softwares aceitam comandos por voz ou gestos com o propósito de facilitar e tornar mais intuitiva a utilização das máquinas. Como boa parte das tecnologias existentes, a ideia de uma Interface Gráfica do Usuário (GUI) começou muito tempo antes de possuirmos a tecnologia necessária para implementá-la. Uma das primeiras pessoas a pensar nessa possibilidade foi o engenheiro, inventor e político Vannevar Bush. O que transformou Bush em um pioneiro da área foi a percepção de que os meios de armazenamento de informações não estavam mais comportando tantos dados. A máquina imaginada por Bush, chamada de Memex, era capaz não apenas de armazenar tanta informação, como também de relacioná-las e oferecer uma maneira fácil de procurá-las em meio a tantos dados. O pai do mouse e da interface gráfica

Inspirado pelo trabalho de Vannevar Bush, o engenheiro elétrico Douglas Engelbart visualizou a possibilidade de usar computadores para aumentar o intelecto humano, em vez de substituí-lo. Ele acreditava que, com informações dispostas em uma tela, o usuário poderia se organizar de maneira gráfica e pular de uma informação para outra, sempre que necessário. Como no caso do Memex, as ideias de Engelbart estavam muito à frente de sua época. Em 1962, até mesmo interfaces em modo texto, com comandos sendo executados em tempo real, eram consideradas como “de outro mundo”, já que os mainframes da época eram operados com cartões perfurados e demoravam horas ou dias para entregarem o resultado do processamento. Em 1968, depois depesquisas, conseguir Engelbart um financiamento para suas e sua equipe demonstraram o potencial dos computadores e de alguns dispositivos de entrada. Entre os “periféricos”, estava uma caixa retangular, com três botões na parte de cima e conectada ao computador por um cabo: era um dos

primeiros modelos de mouse da história, inventado pelo próprio Engelbart e construído por um dos engenheiros da equipe. Os softwares desenvolvidos para esse computador ainda não trabalhavam com o conceito de janelas, como nas interfaces atuais.

Janelas: cada um no seu quadrado

Com o surgimento da Smalltalk, linguagem de programação e ambiente de desenvolvimento que possuía uma interface gráfica diferenciada, a GUI começou a ganhar aspectos mais modernos, em 1974. A grande inovação foram as janelas, que possuíam bordas e barras de títulos que permitiam a identificação e o reposicionamento delas. O conceito de ícones também surgiu na mesma época, assim como o menu de contexto. No mesmo período, também foram apresentadas as barras de rolagem, as caixas de diálogo e os botões de opções (radio buttons).

A chegada da Apple

Outro passo importante na história das interfaces gráficas foi dada pela startup criada por Steve Jobs e Steve Wozniak, em 1976. Com a contratação de ex-funcionários da Xerox, a Apple pode iniciar o desenvolvimento do computador pessoal Lisa, em 1978. A equipe de desenvolvedores trabalhou em uma interface baseada em ícones, em que cada um deles indicava um documento ou uma aplicação. Além disso, a equipe criou a primeira barra de menu desdobrável (pull-down), que hospedava todos os menus logo nas primeiras linhas da tela. O mouse, que havia se aconsagrado com três botões, passou ter apenas um no Lisa e, como a interface exigia pelo menos duas ações para cada ícone, uma para selecionar e outra para executar o programa ou arquivo, foi criado o conceito de duplo clique.

Outras interfaces da época

A VisiCorp era uma das empresas que também estava trabalhando em interfaces gráficas para computadores pessoais. Responsável pela planilha eletrônica VisiCalc, a empresa lançou uma interface para PCs, em 1983, mas que não chegou a fazer muito sucesso. Além do preço alto e de exigir muito recurso de hardware, a VisiOn, como era chamada, também teve alguns retrocessos, como deixar de usar ícones e eliminar o cursor do mouse. Outra interface que surgiu na década de 80 foi a Tandy DeskMate, da Tandy Computers, e a GEM, que fornecia uma interface gráfica para o DOS e era tão parecida com a interface do computador Lisa que a Apple chegou a processar os fabricantes. Em 1986, a Berkeley Softworks lançou a GEOS, interface para computadores Commodore 64 e Apple, que tinha uma aparência parecida com a da GEM. Mais tarde, essa GUI foi portada para PCs e, com isso, acabou se tornando uma concorrente para a Microsoft, que havia anunciado a primeira versão do Windows em1983. Vale a pena lembrar que, no começo, a Microsoft trabalhava como uma empresa terceirizada para a Apple e, por isso, testou os modelos em fase Beta dos

Macs. Isso serviu de inspiração para a criação da sua interface gráfica e, durante o lançamento do Windows 2.0, a empresa chegou até a ser processada pela Apple. Em 1987, também surgiu um novo conceito no mundo das GUIs: o Dock. A responsável pela criação foi a empresa Acorn Computers, que desenvolveu a Arthur, interface que também foi a primeira a usar fontes com anti-aliasing, mesmo em modo de 16 cores. Já a NeXTSTEP, em 1988, foi a interface que introduziu uma aparência 3D aos seus componentes, além de ter sido a primeira a usar o botão em forma de “X” para fechar janelas. Na mesma época, também surgiu a primeira versão gráfica do OS/2, projeto colaborativo Microsoft e IBM 1.1 paraera desenvolver umàsistema que pudesse substituir o MSDOS.entre A interface da versão muito similar do Windows 2.0. No fim dos anos 80, muitas interfaces gráficas começavam a surgir para as estações Unix. Essas GUIs eram executadas sobre um sistema gráfico e com suporte à rede, conhecido como X. Mais tarde, esse sistema também se tornou a base dos ambientes gráficos do Linux. Uma das novidades do X Window System foi o fato de poder habilitar o foco em uma janela posicionando o mouseapenas sobre ela, sem clicar. Atualmente, muitos projetos gráficos ainda fazem uso do X, com o KDE e o GNOME, que teve sua terceira versão lançada nesta semana.

As interfaces mais recentes

Durante os anos 90, apenas duas empresas resistiram à “peneira” do mercado: a Microsoft e a Apple. As demais entraram em falência ou foram adquiridas por outras companhias. O Windows ganhou muita popularidade com as versões 3.0, em 1990, e 3.1, em 1992. Apesar de ainda não ter alguns recursos simples, que já estavam implementados no Macintosh, foram vendidas milhões de cópias dessas versões do sistema da Microsoft. Mais tarde, com a chegada do Windows 95, a empresa de Bill Gates se consolidou como a líder do mercado e detentora de um dos softwares mais famosos até hoje. Quando o cenário já parecia ter se estabilizado, eis que surge uma novidade: o BeOS, sistema operacional da Be Incorporated, com uma interface em que a barra de título lembrava a do Smalltalk, ocupando apenas parte de toda a extensão das janelas. Um versão open source do BeOS continua em desenvolvimento, sob o nome de Haiku. A Apple também inovando e lançou continuou a interface Aqua, para o novo sistema operacional da empresa, o Mac OS X. Além da aparência nova, uma das principais novidades da Aqua era o fato de que as janelas podiam ser redesenha-

das rapidamente, de maneira imperceptível aos olhos, quando movidas ou redimensionadas. Outras inovações ficaram por conta dos efeitos de animação executados durante o ato de minimizar programas. Em versões mais recentes, a empresa também adicionou o conceito de Exposé, que mudou a forma como as pessoas alternavam entre os softwares abertos na área de trabalho. A Microsoft também continuou inovando. Com o lançamento do Windows Vista, pudemos ver a estreia do Aero, responsável pelos efeitos visuais de sombra e transparência da Área de trabalho. Com o Windows 7, a interface foi aprimorada, ganhando suporte a telas touchscreen e multitouch, além de apresentar uma barra de ferramentas totalmente reformulada e o Aero Shake, que permite interação com as janelas ao “sacudilas”. O Windows 7 também ganhou efeitos 3D, semelhantes aos proporcionados pelo Compiz, no Linux. O próprio Compiz acabou se inspirando no Exposé, da Apple, para fornecer um efeito semelhante sobre o X Window System. Os recursos 3D parecem ser a última cartada das interfaces gráficas, que agora começam a se adaptar aos novos dispositivos portáteis operados por toques na tela,e com os dedos. Outro recurso que está ganhando força é o chamado Desktop Semântico, que trabalhará não apenas com os arquivos, mas também com o conteúdo e a informação contextual ao manipular esses arquivos. Disponível em: . Acesso em: 25 jan. 2016.

II

INTERAÇÃO H UMANO COMPUT ADOR E I NTERFACE HUMANO COMPUT ADOR SÃO SINÔ NIMOS? Por algum tempo interação humano-computador pode até ser considerada como um sinônimo de interace humano-computador, especialmente se avaliarmos que é por meio de interaces que ocorre qualquer tipo de troca de inormação entre homem e máquina. Com o passar do tempo, pesquisadores perceberam que existem outros atores que estão intimamente relacionados a esta interação entre homem e máquina. É ato que os computadores existem com a finalidade de executar tareas ou apoiar nos processos diários dos serem humanos, eles existem para enriquecer nosso trabalho, nos dar mais poder, auxiliar nos processos de decisão e por aí vai. É outro ato que nós, seres humanos, temos limitações e capacidades das mais diversas, unir o melhor dos dois mundos (homem e máquina) é algo que os pesquisadores têm procurado encontrar há um bom tempo. O termo Interação Humano-Computador (IHC) oi adotado em meados dos anos 80 como o meio pelo qual esse estudo está sendo direcionado. Desta orma, vemos que os estudos vão mais além que a análise de interace. Segundo Rocha (2003), uma das melhores definições de IHC é a disciplina preocupada com o design, avaliação e implementação de sistemas computacionais interativos para uso humano e com o estudo dos principais enômenos que o rodeiam. Conorme podemos ver em Rocha (2003, p.15) IHC trata do design de sistemas computacionais que auxiliem as pessoas de forma a que possam executar suas atividades produtivamente e com segurança. IHC tem, portanto, papel no desenvolvimento de todo tipo de sistema, variando dos sistemas de controle de tráfego aéreo onde segurança é extremamente importante, até sistemas de escritório onde produtividade e satisfação são os parâmetros mais relevantes, até jogos, onde o envolvimento dos usuários é o requisito básico.

Apesar de não ser uma tarea ácil, é algo que tem que ser priorizado dentro das empresas de sistemas. Vejo muitas empresas gastarem tempo e dinheiro controlando as ases de desenvolvimento de um novo produto, utilizando as melhores técnicas de controle de projeto, deendendo o escopo com “unhas e dentes”,




gerenciando o prazo das entregas, sendo completamente profissionais no desenvolvimento e comprometimento do que tem que ser entregue ao cliente, contudo, esquecem de levantar o escopo de interação necessário para que suas erramentas sejam atrativas aos usuários. Nas próximas unidades, pretendo trazer mais inor-


mações para você de maneira que esteja protegido do problema descrito acima. Como comecei no parágrao anterior, não se trata de uma tarea ácil, outros desafios que existem e devem ser considerados são o aumento da capacidade de processamento cada vez maior dos equipamentos e a disponibilidade de recursos (som, imagem, textos, realidade virtual...) cada vezmais ilimitados. Projetar soluções que considerem estes recursos, as limitações humanas e que orneçam feedback de qualidade ao usuário, de orma que este se sinta “empodeirado“ e não conuso, é um desafio e tanto. Seguir padrões já estabelecidos, obedecer as tendências é sempre uma boa orma de ajudar nossos usuários a se “sentir em casa” quando precisam utilizar nossos sistemas.

Quando o Office 2007 oi lançado, ele ditou a tendência para diversos outros sistemas que vieram a seguir. É inegável que muitos usuários de sistemas comerciais passam a maior parte do tempo manipulando suítes como o Office, suas tareas diárias exigem uma orte necessidade de interação com erramentas de edição de texto, planilhas eletrônicas ou clientes de e-mail. É natural que, com o uso requente de aplicações como estas, os usuários se tornem ágeis e, consequentemente, procurem por outras erramentas que tenham um padrão similar de interação. Recordo-me que nesta época houve um grande “alvoroço” nas empresas de sistemas procurando dar ormatos de interação que se assemelhassem ao Office 2007. O que elas estavam azendo é uma prática muito interessante que tem por objetivo tornar o aprendizado dos usuários mais ácil.

Entenda que existe uma diferença grande entre seguir uma tendência e plagiar o que está sendo lançado, cuidado com isto!


II

Atualmente vemos o mesmo ocorrendo com o lançamento do Windows 8 e, na verdade, o próprio Windows 8 seguindo uma tendência que oi criada pela Apple, que oi o novo ormato de interação disponibilizado para seus aparelhos celulares. Aprendi dirigir carro em um veículo básico, popular, desde lá dirigi vários veículos desde mais simples até de maior luxo e todos eles sem grandes problemas. Se pegarmos a indústria automotiva como exemplo, percebemos que temos muito a aprender com eles. Você não encontrará um veículo que se comporte de orma dierente de outro, na verdade o que você vai encontrar é uma gama de uncionalidades que estarão disponíveis em um modelo e nooutro não, mas dificilmente você encontrará uma uncionalidade em um veículo que se comporte de orma dierente em outro. Vamos pegar um simples exemplo, o controle de marcha ré. Na indústria brasileira, me recordo agora de dois ormatos de acionamento desta marcha em um veículo com câmbio mecânico, agora, quando vamos para câmbio automático, é praticamente um padrão. Se você usou este tipo de recurso em um veículo de uma montadora alemã, americana ou asiática, não terá dificuldades no uso de uma outra qualquer. Vemos que praticamente todos os dispositivos básicos são iguais, o que geralmente muda é a disposição no painel, mas sem grandes mudanças também. O que muda é o design, o acabamento.... está aí o dierencial. Como seria se nossos sistemas se comportassem da mesma orma? Imagine você como se tornaria mais ácil a vida de nossos usuários! Como auxiliaríamos seu processo de aprendizado, como seria mais simples sua execução de tareas e, com certeza, como ele se sentiria mais satiseito ao usar um sistema como este.

Suas aplicações estão preparadas para trabalhar com o Windows 8?




Afinal de contas, o objetivo da IHC é produzir sistemas que saiam realmente da gaveta. Que sejam úteis, utilizáveis, seguros, uncionais, que agreguem poder e valor ao usuário. Podemos dizer que sistemas como este são aceitáveis e, conorme definido


por Nielsen (1993), podemos ter dois tipos de aceitabilidade: aceitabilidade social e prática. Quando ambas são positivas, podemos dizer que um sistema apresenta uma aceitabilidade geral e, com isto, há grandes chances deste produto ter sucesso real. Vamos entender um pouco mais sobre estes dois itens. 1. Aceitabilidade social. Está intimamente relacionada à orma como a sociedade que é aetada pelo sistema vê seu uso. Tenho dois bons exemplos que quero compartilhar contigo.

Acredito que ninguém aceita muito bem chegar em um banco e ficar preso em sua porta giratória, não é? Apesar de entendermos o motivo de sua aplicação, é constrangedor passar por uma situação como esta. Desenvolvi alguns anos atrás um sistema para uma empresa que passaria a controlar o acesso às suas dependências. Com a entrada em uncionamento deste novo sistema, todas as pessoas que circulavam nas dependências da empresa deveriam estar devidamente identificadas e, para alguns setores, haveria necessidade de registro de sua circulação. Este registro orçava que houvesse uma abordagem a estas pessoas para saber onde estavam indo. Como não era algo usual na empresa, houve uma grande rejeição no início do uso. Ninguém questionava os motivos pelo qual os registros eram gerados, todos entendiam que se tratava da própria segurança da empresa e de seus uncionários, mas era algo que gerava desconorto nas pessoas.

E se você concentrar seus esforços buscando o diferencial competitivo em outros quesitos...!?


II

Está aqui um dos maiores motivos de insucesso nos sistemas, a alta de aceitação social. Boas ideias podem racassar se a sociedade não “comprar” a ideia. 2. Aceitabilidade prática: estamos alando da aceitação do custo da erramenta (este é um muito importante dentro das organizações), confiabilidade no critério produto, compatibilidade com outros sistemas existentes ou versões anteriores de seu produto, segurança das inormações, segurança no ornecedor do produto (credibilidade)... este princípio de aceitação leva à definição de outro conceito denominado “useulness”. “Usefulness” se reere ao ato de um sistema poder ser utilizado para atender a um objetivo, sanar um problema, atender a uma necessidade. Na essência, só existe a necessidade de usar um sistema de inormação se há um problema que precisa ser resolvido, e é aqui que entra este conceito que estamos estudando e que ele nos leva a pensar em duas novas classificações, que é a Utilidade e a Usabilidade. Um sistema só“útil” vai terpara utilidade para or azer uso dele o mesmo or realmente resolver o quem problema que existe, ouse“útil” para atender a uma necessidade que tenha surgido, podemos dizer que um sistema tem utilidade quando este az o que realmente se propõe a azer. Um sistema antivírus é útil quando este, realmente, protege seu computador de sistemas maliciosos.

Um sistema só vai ser usável (ter usabilidade) quando os usuários conseguem, realmente, azer uso das uncionalidades propostas pelo sistema, e este é um conceito CHAVE para IHC. Em resumo, podemos dizer que um sistema, para ter sucesso, precisa ser socialmente aceito, precisa ter aceitaçãoprática dentro da empresa, necessita ser útil e realmente utilizável pelos usuários finais. A alta de um dos quatro elementos acima pode sacramentar a “morte” de sua aplicação! É papel da IHC garantir a boa integração entre os elementos acima.





©shutterstock

COMO AS PESSOAS INTER AGEM COM OBJETOS? Certamente você já deve ter parado por alguns instantes rente a uma porta e pensou: puxo, empurro ou deslizo? Os eletrodomésticos têm tantos recursos que diícil é azer ele ser útil. Outro dia estava observando minha sogra utilizar pela primeira vez sua nova máquina de lavar roupas, levou cerca de uma hora até conseguir azer a máquina uncionar e, finalmente, lavar sua roupa. É ato, como já conversamos no início deste livro, que os produtos não são criados pensando exatamente em seu uso pelos compradores, as inovações surgem a cada momento, o número de novos produtos lançados no mercado cresce a cada ano, mas o número de rustração rente ao uso também. É possível evitar isto e, antes de entrar mais detalhadamente em usabilidade, quero conversar contigo sobre a orma como as pessoas interagem com os mais diversos objetos, e isto inclui sistemas! Norman (1998) estabeleceu quanto princípios bastante simples que devemos observar, são eles: 1. Visibilidade Outro dia um possível cliente que assistia uma apresentação comercial soltou uma rase que me chamou atenção, ele disse: “Tudo isso?”.

Como as Pessoas Interagem com Objetos?

II

Ele se reeria ao número de opções que existiam no menu de um sistema que estava sendo apresentado. É óbvio que contornamos inormando que todas aquelas opções estavam visíveis naquele momento pois precisávamos mostrar tudo o que o sistema tinha para oerecer, mas, na verdade, lá no undo percebi que o sistema tinha uma coisa negativa para oerecer que era a dificuldade de achar a inormação.

O conceito de visibilidade ala justamente sobre isto, deixe visível só aquilo que é importante e vai ser utilizado. Outra característica importante da visibilidade é que ela deve ornecer ao usuário a maneira como deve ser operado aquilo que está disponível para ele. Visibilidade deve ser usada para distinguir as coisas dentro de um sistema. Visibilidade deve dar ao usuário ácil acesso a um conjunto de recursos desejado por ele. A Visibilidade deve dar clareza ao usuário se o resultado que se esperava alcançar com a execução de uma tarea oi alcançado ou não. Como em um carro, ao pisar no acelerador para atingir a velocidade de 60 km/hr, devo ter a inormação clara, por meio do velocímetro, se isto oi atingido ou não. Um dos maiores inimigos da visibilidade é a estética. Muitas vezes por quesitos estéticos, mensagens ou inormações são omitidas dificultando assim a vida dos usuários. Imagine como seria mais ácil se uma “seta” estivesse em toda porta para deixar mais clara a direção de abertura desta! Dentro de visibilidade, existe um critério ao qual temos que estar atentos, que é a determinação de como aquele objeto deveria ser usado. A isto chamamos Affordance (mostre o caminho para o usuário). Quando pensamos


©shutterstock



em um vidro, logo vem à nossa mente que este deve ser utilizado para trazer visibilidade ao local; quando pensamos em madeira, esta nos remete à sustentação; quando pensamos em uma poltrona, somos impelidos a lembrar que podemos azer uso desta para nos sentar. O mesmo critério tem que ser um produto quando estamos projetando. Cada elemento depensado uma telaem de sistem a deve ser avaliado sobre o que ele lembra sobre seu uso. Quando colocamos um botão, remetemos a ideia de algo que deve ser pressionado, e por aí vai. . 8 9 9 1 e d o ir e r e v fe e d 9 1 e d 0 1 6 . 9 i e L e l a n e P o ig d ó C o d 4 8 1 . t r A . a d i b i o r p o ã ç u d o r p e R

2. Bom modelo conceitual Quando projetamos sistemas, precisamos levar isto em consideração, ele nos permite prever oeeito das ações. A ideia por trás disto é que, mesmo que nunca tenhamos operado um sistema como este anteriormente, possamos prever o que vai acontecer, executar e então aprender.

Um bom modelo conceitual az uso de vários elementos com orte Affordance é claro, procurando torná-los quase óbvio. Podemos pegar como um bom exemplo um relógio analógico. Mesmo que você nunca tenha mexido em um relógio como este antes, com certeza você conseguirá azer uso dele. Geralmente, é dotado de um único botão por meio da qual você pode ajustar as horas do relógio e também ajustar o calendário. O botão é

k c to rs tt e u h s ©

dotado de orte Affordance, pois você já associa a ideia de que ele está ali para ser girado, pressionado ou, quando muito, puxado (sua posição, muitas vezes ao lado do “quadrado” com o calendário é um outro bom exemplo de indução de que “é ali” que você tem que interagir).


© sh

u tt e

rs to c

k

II

Agora, se avaliamos um relógio digital, é desesperador o número de opções que este possui, e o número limitado de meios de interação que requer uma combinação grande entre estes elementos (“aperte o botão da direita e gire o da esquerda” ou ainda “acesse ‘n’ menus para ter acesso à opção desejada”). Com certeza, não é um bom exemplo de “bom modelo conceitual”. Já devo ter me deparado com diversas telas de sistema que são piores que relógios digitais. Em evereiro de 2012 estava apoiando um projeto e, ao testar o sistema gerado por este projeto, fiquei horrorizado. Com certeza, não oi observado nenhum modelo conceitual, nada era óbvio, e como resultado disto, este projeto ficou mais quatro meses em processo de maturação até ter condições de ser oertado ao público. Perceba o impacto que uma má avaliação de design pode gerar para uma empresa! 3. Bons mapeamentos

Nada mais natural para um bom processo de aprendizado do que ter uma boa correlação entre aquilo que acontece no mundo real dentro de um sistema. Um bom mapeamento nada mais é do que isto, mapear as entidades em seu correto uncionamento. No caso de sistemas, mapear o uncionamento da interace com os controles/execuções que se espera que ela aça.

Uma analogia com veículos, quando estamos dirigindo e queremos virar à direita, basta virar o volante para esta direção. Um bom mapeamento está em identificar qual objeto devo manipular para ter o resultado esperado e qual deve ser o estímulo/dado que devo aplicar. Recordo-me que, em 2012, chegou até mim uma nova interace de conciliação bancária produzida por minha equipe. Simplesmente todos os princípios de mapeamento oram desconsiderados, novamente, mais retrabalho e atraso na entrega. 4. Feedback

O feedback é algo que deve ser dado ao usuário após cada interação realizada, este precisa ser inormado se o que esperava que osse eito




realmente o oi e, caso a resposta seja negativa, o que precisa ser eito de um modo dierente para ter sucesso da próxima vez.


Este de comunicação é muito alhotipo na maioria dos sistemas de inormação. Quando interagimos com sistemas mais complexos, a coisa fica ainda pior. Vamos avaliar uma situação que já se tornou corriqueira para a maioria das empresas, que é a emissão de uma nota fis©shutterstock cal eletrônica. Para poder nivelar o conhecimento, a seguir, vou trazer uma breve descrição do seu uncionamento e então vamos avaliar como a alta de eedback torna diícil o trabalho das pessoas que interagem com sistemas como este. Desde 2009, o governo brasileiro passou a exigir que as empresas deixem de usar papel na impressão de seus documentos fiscais e passe a usar o ormato eletrônico com autenticação do governo para a emissão de suas notas fiscais. Cada estado tem um cronograma próprio até que todos os contribuintes estejam azendo uso apenas desta orma de venda (a chamada nota fiscal eletrônica). O processo por trás de uma venda com nota eletrônica é relativamente simples: 1. A empresa gera o cadastro da nota fiscal e, antes de realizar qualquer tipo de impressão que a oficialize, envia para aprovação da receita estadual que valida se: a. A empresa emissora está autorizada a azer a emissão daquele tipo de documento. b. O cliente que está realizando a compra não tem algum tipo de bloqueio que o impeça de azer compras. c. Se o conteúdo das inormações estão coerentes.


II

2. Passando pela validação acima, é retornada uma sinalização da Secretaria da Fazenda do Estado para o Emissor e então: a. A numeração para este documento é gerada (pois oi autorizada pelo fisco à venda). b. Um documento auxiliar que comprova a autorização é impresso. c. A transação é finalizada. Parece algo bastante simples, não é? Na verdade é, entretanto, existe um conjunto de variáveis que podem comprometer todo este trabalho. Vamos pensar em um exemplo: seu cliente está na sua rente, você acaba de azer uma venda e então manda a nota para autorização junto a Secretaria da Fazenda Estadual. Permita-me trazer algumas variáveis novas para sua análise: 1. O que acontece se o sistema da receita estadual sair do ar? 2. O que acontece se a empresa que está emitindo a nota ficar com a internet ora do ar? 3. O que acontece se o cliente tiver alguma restrição? 4. O que acontece se o emissor estiver com alguma restrição? 5. O que acontece se o ... Chega, vou parar por aqui! Acredito que seja suficiente para poder ilustrar nosso exemplo. Na maioria das vezes, se qualquer problema acontecer nos passos acima, a pessoa que está emitindo a nota (geralmente o aturista da empresa) fica em uma saia justa. Dificilmente ele terá certeza do que aconteceu. Ele precisa muito de feedback da aplicação para saber o que está acontecendo e, se precisar tomar alguma outra ação para que a venda seja eita, qual será? Precisamos dar o caminho a seguir para o usuário. Já ouvi relatos que disseram que se a impressão não saísse em um intervalo de até um minuto, eles deveriam ligar para o suporte da empresa. Por que aziam isto? Era a única inormação que tinham em mãos para poder trabalhar! Perceba como a alta de eedback pode comprometer o trabalho dentro da empresa? É imprescindível que seja possível identificar o que aconteceu com cada operação que oi realizada dentro de um sistema. É de undamental importância




que seja dado ao usuário a possibilidade de aprender com o que errou para que assim não passe mais por isso, quando este comete umequívoco. É undamental para o sucesso de uma aplicação que seja possível ter as inormações necessárias onde quer que ela esteja dentro dos sistemas. Segundo Norman (1988), vivemos o chamado paradoxo da tecnologia. A tecnologia que tem potencial para tornar nossas vidas mais simples e agradáveis acaba, por sua vez, tornando mais complexa e cheia de rustração. . 8 9 9 1 e d o ir e r e v fe e d 9 1 e d 0 1 6 . 9 i e L e l a n e P o ig d ó C o d 4 8 1 . t r A . a d i b i o r p o ã ç u d o r p e R

USABILIDADE Prezado(a) aluno(a), independente de você ter ou preerir um celular da Apple ou da Samsung, o ato é que tanto o IPhone quanto ao Galaxy são dois ótimos exemplos de usabilidade. São áceis de usar, são intuitivos, como vimos no tópico anterior, eles realmente respeitam a orma como as pessoas interagem com os objetos. O principio é que qualquer pessoa que possa tocar algo possa interagir com os dois aparelhos acima. Relatos de crianças com pouca idade se divertindo e conseguindo jogar em dispositivos como estes são muitos e estão espalhados pela internet. Tenho certeza de que você deve ter relatos de amigos ou amiliares nesta situação.

©shutterstock

Usabilidade

II

O que torna dispositivos como este um sucesso pode azer com que minha aplicação também prospere. Para entendermos como isto é possível, vamos avaliar o que Nielsen (1993) ala sobre o assunto: ■ Sua melhor tentativa não é boa o suficiente. Se tem uma pessoa capacitada para encontrar alhas em sistema, este é o usuário. Invista em teste e qualidade de sofware o quanto você puder, mas saiba, ele ainda vai encontrar alhas que sua equipe não oi capaz de encontrar. Esta mesma verdade cabe para usabilidade. Se você acha que sabe de tudo que passa pela cabeça do usuário, você se engana. Se você acha que sabe realmente a orma como o usuário vai operar o sistema, está mais enganado ainda. Por mais que você se esorce, por mais que você aça o seu melhor, esteja preparado para um redesign. Vamos entender nas próximas unidades como podemos reduzir este risco e tornar este trabalho mais seguro. ■ Usuário está sempre certo. Se quisermos melhorar como profissionais e como pessoas, temos que estar abertos a receber eedback a todo momento, ainda mais com relação aos nossos designs. O que percebo é que muitas vezes, nosso orgulho próprio ala mais alto e dificulta nossa capacidade de análise, muitas “reclamações” apresentadas pelo usuário são válidas e devem ser consideradas para a construção de um produto melhor.

Erros recorrentes, reclamação recorrente, são sinais de que posso ter alhado no design que oi criado para aquela aplicação, ou aquele grupo de usuários. Lembre-se, a “jaca não cai longe do pé”, dê ouvidos e avalie sinceramente. ■ Usuário não está sempre certo.

O outro extremo também é perigoso, achar que o usuário sabe o que realmente precisa pode ser um tiro no pé. Na maioria das vezes o que o usuário solicita é o que ele quer e não o que ele realmente precisa, precisamos agir como agem os médicos, acredito que você não tenha conseguido trocar a decisão de um médico que lhe receitou um medicamento cujo gosto não lhe agradava, uma vez que este é o que lhe curaria.




Temos que manter o equilíbrio entre as duas partes, nem tanto ao céu, nem tanto ao inerno, precisamos usar o melhor das duas experiências, o segredo é trabalhar em equipe (design e usuário). ■ Usuários não são designers.


Quando comecei a trabalhar em uma empresa que ornecia sistemas de gestão empresarial achei genial a orma como as interaces do sistema eram flexíveis. O usuário poderia manipular literalmente todos os campos, poderia customizar como quisesse, aos poucos aquela visão de beneício se transormou em problema. Usuários iniciantes não azem isto, na verdade eles têm até “medo” de que, ao mexer em algo, pare de uncionar, então esta prática que é muito bem-vinda para usuários mais avançados, para os iniciantes é ruim. ■ Designers não são usuários. Precisamos ter em nossas mentes que aquilo que eu aço rotineiramente me leva a achar que é ácil. Certamente um contador experiente não tem dificuldades na geração e análise um balanço assim entrecomo um administrador de empresas nade avaliação de umcontábil, fluxo de caixa, tanto, aquilo que para mim pode ser trivial (pois já adquiri conhecimento e prática suficiente) pode não ser trivial para outra pessoa. Com o design é a mesma coisa, a pessoa que está criando a interace já está influenciada sobre sua própria orma de interagir, operar, ato que a leva a ter uma avaliação equivocada da complexidade do que está criando. ■ Menos é mais.

Quantas pessoas já andaram pelas ruas em época de campanha eleitoral? Inelizmente nossa região não possui nenhuma lei que impeça a utilização em massa de cartazes de propaganda e por muitas vezes temos ruas completamente lotadas de propaganda, tornando até diícil encontrar um estabelecimento comercial. Quantas pessoas já utilizaram as uncionalidades de criação de “macro” em editores de texto? Ou então opções de autorresumo, programação, mas estas uncionalidades estão lá, muitas vezes, poluindo da mesma orma que os cartazes em época eleitoral. Por vezes vejo relatórios serem criados para alguns clientes que saem com quase todos os campos que existem nas tabelas de banco de dados dis-

Usabilidade

II

poníveis para que o usuário possa azer a configuração de visibilidade de campos, e o que ocorre no final é que o que o usuário precisa é somente conseguir filtrar por data e empresa, mas eu o presenteio com outros 120 campos que nunca serão utilizados por ele (mas estão lá, vai que um dia ele precisa! Este meu pensamento está errado, o cliente quer simplicidade). ■ Help não ajuda. É melhor o usuário conseguir usar sem ter que usar um help, e o design deve usar isto como um requisito básico. Na grande maioria das vezes, os usuários não acessam ajuda de sistema ou, quando acessam, ficam perdidos pela própria dificuldade de utilização deste. Algumas vezes percebo que alguns designs utilizam como “desculpa” para a negligência na criação de uma solução o ato de existir uma boa documentação (manuais, ajudas...) para o usuário, contudo, uma coisa não pode influenciar a outra. Nielsen (1993) agrupou alguns dos principais elementos de usabilidade em cinco grupos, são eles: 1. Facilidade de aprendizagem Quando comecei a trabalhar como designer gráfico, tinha aproximadamente dezoito anos, na época devo ter investido cerca de um mês deestudo em uma erramenta que era a mais utilizada na época para esta unção.

Esta erramenta não é exatamente um bom exemplo de acilidade de aprendizado! Se os sistemas levassem este quesito em consideração, muitas escolas que ornecem treinamento em erramentas, como as voltadas para engenharia ou arquitetura, teriam que encontrar outras ormas de ganhar dinheiro! Segundo Nielsen, é o atributo mais importante que um sistema deve ter

Ter menos opções torna minha decisão mais rápida, minha interação mais precisa e gera maior satisfação!




em sua classificação de usabilidade. Inclusive, pode ser um item que leve a pessoa a deixar de usar seu sistema e passando a usar outro!

Como o aprendizado vem com o uso, podemos avaliar como sendo o tempo que o usuário leva para atingir um certo nível de proficiência na execução de suas tareas. 2. Eficiência


A eficiência é mensurada com usuários já experientes, aqueles que já utilizam a erramenta há um tempo. Pode ser eita uma comparação, considerando a mesma tarea e o tempo gasto e economizado pelos dois sistemas. 3. Facilidade de relembrar Esta é uma característica de grande importância para usuários casuais, ou seja, aqueles que não azem uso da erramenta o tempo todo. Um bom exemplo é o sistema de declaração de imposto de renda, você az isto uma vez por ano e é importante que quando necessite azer uso, não perca tempo precisando relembrar como usar o sistema. 4. Erros Quando alamos de erros não estamos alando de alhas catastróficas que açam o usuário perder o trabalho executado, isto é inaceitável e nem merece tratamento aqui neste livro. Quando alamos de erros, estamos nos reerindo a engano, ou seja, um caminho que o usuário acabou pegando errado e que necessita de orientação para proceder. Deve ser de ácil contorno promover eedback ao usuário, de orma que aprenda e não cometa mais este equívoco. Não pode existir muitas ocorrências como esta, caso contrário, isso é um sinal de que sua aplicação está com problemas de usabilidade.

Quanto tempo leva para que seus usuários consigam aprender e utilizar seu sistema?

Usabilidade

II

5. Satisação subjetiva Isto é azer com que o usuário se sinta satiseito em usar o sistema, deve trazer para o usuário prazer em usá-lo. Este é um critério muito valorizado para aplicações como jogos. Ninguém tem que jogar, joga porque gosta, porque quer. É esta mesma sensação que os sistemas convencionais devem provocar em seus usuários. Um outro ponto que tem total impacto na usabilidade e, consequentemente, na satisação do usuário, é o quanto este se sente amiliarizado ao uso. Um novato não será um novato para sempre, precisamos preparar nossos produtos para quando este se tornar um especialista. Uma boa abordagem é prover meios distintos de interação onde, na medida que o usuário se sente mais conortável com certos meios de interação, possa evoluir para outros.

USABILIDADE NA WEB No final de 2011 havia cerca de 555 milhões de sites em todo mundo, em 1982, tínhamos 315 sites. Segundo a pesquisa de setembro/2012 Ibope NetRatings, somos 83,4 milhões de internautas no Brasil, assumimos a 5ª posição mundial em conectividade, cerca de 51 milhões de internautas são ativos, ou seja, acessam requentemente à rede. Em 2008, 8,2 bilhões oram gerados em operações de compra on-line, em 2009, mesmo com a crise, esta cira saltou para 10,6 bilhões e, em 2010, 1/3 de toda venda realizada no varejo do Brasil já era eita pela internet (um montante de 14,8 bilhões). Mesmo com todos estes números avoráveis, apenas 20% dos internautas brasileiros realizam compra pela internet, aqueles que não realizam esta operação não o azem por não considerar uma operação segura (69%) ou porque não confiam na qualidade do produto (26%). Estes números dão uma ideia do tamanho do potencial que este mercado tem e também trazem uma reerência sobre a necessidade de qualidade que estas





©shutterstock

aplicações precisam ter. Segundo Rocha (2003), dados de 1998 apontam para uma perda de três bilhões de dólares por causa de um design mau eito. Como abocanhar esta enorme atia do mercado? Um bom design pode ser uma das peças deste enorme quebra-cabeça. Quando alamos de aplicações tradicionais, como sistemas comerciais, o usuário muitas vezes não tem acesso ao sistema, quando muito, acaba por passar por uma experiência de apresentação do produto em que não é ele quem opera o sistema. Assim, ele passa por uma situação em que compra primeiro (paga) para depois usar. No caso de soluções web, como um e-commerce, a equação é invertida, o usuário vai acessar ao sistema, vai tentar tirar as dúvidas que tem quanto ao produto que anseia comprar e depois, só depois disto, vai optar ou não pela compra. Assim, claramente vemos que qualquer problema de usabilidade pode azer com que o usuário simplesmente desista de comprar o produto desejado por meio de sua erramenta e opte por comprar de outro. Em um mercado tão competitivo como é o varejo, o preço das mercadorias são muito semelhantes, então não podemos correr o menor risco de perder uma venda por uma alha de design. Segundo Rocha (2003), uma análise realizada pela IBM revelou que as duas opções mais utilizadas de seu site era a busca e a opção de ajuda. Isto oi um indício de que um problema de design estava ocorrendo e oi iniciado um processo de redesign que custou milhões de dólares e envolveu centenas de pessoas. Em evereiro de 1999, entrou no ar a nova versão do site, semanas depois oi constatado que houve uma queda de 84% na utilização da ajuda do site, em contrapartida,

Usabilidade na Web

II

um aumento de 400% no aturamento. Se avaliarmos o site da Google, veremos que ele é praticamente o mesmo desde o seu lançamento. Seu oco esta na simplicidade, e com isto a capacidade de manter um bom relacionamento com seus clientes (usuários que utilizam seu serviço de busca). No design para web existem basicamente duas vertentes, uma de abordagem artística e outra de abordagem na solução de um problema do cliente. Se pudermos ter uma mistura destas duas coisas, maravilha, caso contrário, o que se espera de um site é que os usuários possam realizar rapidamente tareas que sejam úteis. Segundo Rocha (2003) e Nielsen (1999), alguns princípios básicos devem ser seguidos para garantir um bom design web, são eles: 1. Clareza da arquitetura da inormação. A inormação deve estar estruturada e equilibrada, é undamental que o usuário possa discernir o que é prioritário e secundário no site. Esta divi-

são de inormações é undamental para que o usuário possa se encontrar e ter suas dúvidas sanadas. 2. Facilidade de navegação. Um ótimo medidor é que este consiga acessar qualquer inormação em no máximo 3 cliques, esta métrica é uma ótima reerência para que tenhamos as inormações bem arquitetadas dentro do site. 3. Simplicidade. Se, ao acessar um site, você conseguir responder perguntas como: Onde estou? O que posso ter de beneício com este site? Há algum dierencial nele? É o que você precisa para garantir que as inormações necessárias para que o cliente possa navegar estejam disponíveis. 4. A relevância do conteúdo. Na WEB o que mais cativa seus clientes é a relevância dos conteúdos, não necessariamente por imagens.




5. Manter a consistência. As coisas têm que acontecer sempre do mesmo jeito! Uma tela de cadastro se comporta igual independente do que está sendo cadastrado, este é um orte princípio de usabilidade que retira a ansiedade dos clientes.


6. Tempo suportável. O tempo de resposta que estudos apontam ser aceitável para que uma página web esteja disponível está entre 10 e 15 segundos. Perceba a importância desta inormação e os detalhes que precisam ser cuidados, independente: ■ Da velocidade da internet do cliente. ■ Do equipamento que este esteja usando. ■ Do tipo de acesso, se por dispositivo móvel ou não.

Devemos cuidar para que este tempo mínimo não extrapole e, assim, percamos o interesse do usuário em se manter conectado em nosso site. 7. Foco nos usuários. Nada impede que um usuário altere o curso de sua navegação e vá para outro site, o que vai azer ele se manter fiel a mim é o respeito a itens como estes que acabamos de estudar. Não imagine que usar uma tecnologia ou outra vai prender atenção dele em seu site, isto para ele é pouco ou nada relevante, o que vale para ele é ter acesso rápido e ácil à inormação que busca. Conorme Rocha (2003, p. 39), temos: Pessoas são extremamente dirigidas a um objetivo quando usam a Web. Elas têm alguma coisa específica que querem fazer e não toleram nada que dificulte atingir esse objetivo. Portanto, o princípio mestre do design para a Web é “sair do caminho” de forma a que o usuário possa fazer o que quer da maneira mais rápida possível.

Usabilidade na Web

NÚMERO DE USUÁRIOS DE INTERNET CRESCE 11% EM JANEIRO DE 2012 Por R7 O número de usuários ativos da internet brasileira voltou a crescer em janeiro, segundo levantamento dode Ibope Nielsen Dasforam 63,5 usuários milhões de pessoas com acesso em casa ou no local trabalho, 47,5Online. milhões ativos em janeiro. O crescimento foi de 2% em relação ao mês anterior e de 11,2% sobre os 42,7 milhões de janeiro de 2011. A maior parte desse crescimento vem ocorrendo em residências. Entre janeiro de 2011 e janeiro de 2012, o número de usuários ativos domiciliares passou de 34,2 milhões para 39 milhões, ou 14% de expansão. O total de brasileiros com acesso em qualquer ambiente (domicílios, trabalho, escolas, lan houses ou outros locais) foi de 78,5 milhões de pessoas no terceiro trimestre de 2011. A categoria com maior crescimento mensal do número de usuários únicos em janeiro foi a de sites do governo. A audiência dos sites governamentais passou de 22,3 milhões de usuários únicos em dezembro para 25,3 milhões em janeiro. A evolução de 13% foi resultado da maior procura em janeiro por informações sobre o Enem, o Prouni e as inscrições unificadas em instituições públicas de ensino superior. Nos sites de governo, também cresceu a busca por informações sobre tributos. Outros sites que também registraram forte crescimento da audiência em janeiro foram os de carreiras, os mapas e guias locais, as páginas de ofertas de pacotes de viagens, de hotéis e de companhias aéreas e os classificados de imóveis. Na comparação com janeiro de 2011, acumulam o maior crescimento percentual as categorias Automóveis, com 27% de evolução no número de usuários únicos, e Viagens, com expansão de 22%. Também seguiram em crescimento sites de vídeos, buscadores, e-mail, compras coletivas e sites sociais. A publicidade na internet também começou 2012 em alta. Em janeiro, foram veiculadas mais de 6.000 campanhas de 2.124 diferentes anunciantes. Na comparação com janeiro de 2011, o crescimento do número de campanhas foi de 39%. O número de peças publicitárias em formato display passou de 20 mil e representou um aumento de 69% em relação ao mesmo período do ano anterior. Disponível em: . Acesso em: 26 jan. 2016.

Evolução do formato de interação com o Windows, sistema operacional mais popular. . Acesso em 26 jan. 2016

Apesar de ser trecho de um filme, é bastante interessante como os modelos de interface podem parecer simples dependendo do nível do usuário. . Acesso em 26/01/2016

CONSIDERAÇÕES FINAIS . 8 9 9 1 e d o ir e r e v fe e d 9 1 e d 0 1 6 . 9 i e L e l a n e P o ig d ó C o d 4 8 1 . t r A . a d i b i o r p o ã ç u d o r p e R

Caro(a) aluno(a), vimos no decorrer desta segunda unidade o histórico da evolução das interaces de computador, também vimos que sua história se mistura um pouco com os conceitos de interação homem-computador. Vimos como nós, humanos, interagimos com objetos e como precisamos estar atentos a este item para que nossos produtos orneçam uma boa capacidade de interação. Foi possível notar também como a internet tem se diundido em nosso país e que cada vez mais pessoas estão azendo uso dela cotidianamente. Vimos que hoje a rede mundial já é responsável por uma grande parcela das vendas no varejo e que um mau design pode ser crucial para o insucesso de uma empresa. Na próxima unidade, vamos aprender mais sobre os atores que envolvem a interação humana, quais os elementos envolvidos, qual sua importância, como podemos tirar proveito disso de maneira a produzir bons designs.


1. Como a criação de helps pode ser uma armadilha para a concepção de um bom design de interação? 2. Dentre os aspectos da interação humana com objetos, quais você classifica como mais importantes? 3. Dentre os elementos relacionados à usabilidade para sistemas para internet, quais os que você avalia como mais importante? 4. Para o desenvolvimento de soluções desktop, como podemos fazer uso dos princípios de usabilidade que aprendemos? Foque nos tópicos relacionados à facilidade de aprendizado e tratamento de erros e descreva como você pode colocar isto em prática em suas aplicações.


ENTENDENDO MAIS SOBRE OS FATORES HUMAN OS ENVOLVIDOS

E D A D I N U

III

Objetivos de Aprendizagem ■ Entender quais são os fatores humanos envolvidos no processo de design e interação. ■ Avaliar como podemos tirar proveito do entendimento do funcionamento da memória humana para o processo de design. ■ Compreender como podemos avaliar e otimizar o design desenvolvido.


■ A psicologia da interface humano-computador ■ Mecanismos da percepção humana ■ O Modelo GOMS ■ Modelos mentais

INTRODUÇÃO Caro(a) aluno(a), é de undamental importância que possamos entender mais como se dá o processo de interação homem x máquina, como é que um influencia


ou recebe influência de outro. Precisamos entender como as capacidades ísicas e cognitivas humanas intererem no design de um novo produto. Hoje, a psicologia cognitiva tem sido uma orte aliada na análise de como comportamentos humanos e seus processos mentais influenciam no processo de interação com qualquer tipo de produto. Fatores motores, visuais, perceptivos e cognitivos são de undamental importância para um bom projeto de design e interação, para isto vamos avaliar um modelo bastante aceito que é o GOMS ( Goals, Operations, Methods and Selection Rules) este é um modelo que tenta caracterizar os vários processos cognitivos subjacentes à realização de uma determinada tarea. Este é um modelo preditivo, que permite análise qualitativa e quantitativa a respeito da perormance humana em interação com computadores. Não podemos esquecer que muitos dos atores humanos envolvidos têm caráter ergonômico, precisamos pensar muito bem sobre os seguintes aspectos: quem irá usar e em que condições se dará seu uso. Pense que sistemas que são desenvolvidos para o uso de pilotos de testes ou aeronautas necessitam avaliar claramente estes aspectos, caso contrário, vidas serão colocadas em risco. Talvez você não desenvolva sistemas que coloque vidas em jogo, mas tenha certeza de que, mesmo assim, critérios como este estão intimamente relacionados com a satisação dos usuários, conorme vimos nas unidades anteriores. Talvez o item ergonômico mais importante seja o relacionado à ergonomia cognitiva, que nada mais é que a adequação das interaces aos mecanismos e modelos mentais humanos. Quando alamos de modelos mentais, precisamos trazer à memória metáoras de interace e como isto pode simplificar o uso por parte de nossos usuários.

Introdução

III


©shutterstock

A PSICOLOGIA DA I NTERFACE HUMANO COMPUTADOR Existe uma relação dialética entre os conceitos de interace e a natureza humana, podemos dizer que as duas disciplinas mais envolvidas neste processo são a Ciência da Computação e a Psicologia. Segundo Rocha (2003), a acilidade com que palavras da linguagem da interace podem ser lembradas, como o tipo deontes e caracteres aetam a legibilidade e a velocidade com que lemos inormações na tela são exemplos simples de como nossa interação com o computador pode ser aetada pelo uncionamento de nossos mecanismos perceptuais motores e de memória. Da mesma orma que um engenheiro da computação cuida para que o processamento dos dados ocorram o mais otimizados possíveis em termos de memória, processamento, devemos pensar da mesma orma quando criamos uma interace de comunicação entre homem e máquina. Existe um modelo chamado MPIH (Modelo do Processador de Inormação Humana), de acordo com Cardet al. (1983), que tem por objetivo ajudar a prever a interação usuário-computador. Este modelo é estabelecido obedecendo a um conjunto de memória e processadores e um conjunto de princípios pelo qual se dão as operações. Três subsistemas azem parte e interagem com o MPIH, são eles:

ENTENDENDO MAIS SOBRE OS FATORES HUMANOS ENVOLVIDOS


1. SP (sistema perceptual). 2. SM (sistema motor). 3. SC (sistema cognitivo).


A figura ao lado nos ajuda a compreender como este modelo unciona. O primeiro passo é identificar o que está acontecendo à nossa volta, isto se dá pela captura, por meio de nossos órgãos de sentido, da inormação sensorial. Tanto na imagem acima quanto na maioria dos sistemas de inormação os principais órgãos que são acionados são da visão e audiFonte: Baseado em Rocha (2003) ção. Sistemas de segurança poderiam trabalhar com outros sentidos como o olato, e sistemas especialistas tratariam com certeza de itens relacionados ao tato. A inormação captada pelo processador perceptual (PP) vai paranossa memória de trabalho (MT), também chamada de memória de curta duração (MCD), esta parte da memória aciona parte da memória de longa duração (MLD) com intenção de detectar se aquele estímulo já é conhecido. O princípio por trás do modelo MHIP é o que chamamos de reconhece-age do processador cognitivo (PC), existem autores que afirmam a existência de “gatilhos de memória” que são acionados nestes momentos em busca de algo já conhecido anteriormente. Estes “gatilhos” acionam nosso processo motor (PM) nos colocando em ação. O sistema perceptual (SP) também é responsável por acionar dentro do nosso mecanismo de memória o que chamamos de memória de imagem visual (MIV) e também nossa memória de imagem auditiva (MIA). Após um estímulo e o processamento eito pela MCD e/ou MLD, uma representação é fixada/demonstrada nestes dois dispositivos de saída (MIV ou MIA).


III

Quantos mais padronizados forem as imagens ou sons emitidos pelo sistema, mais fácil se tornará o processo de interpretação da memória humana.

Vamos para um exemplo bastante simples quepode nos ajudar a entender melhor esta relação. Certamente, você já deve ter colocado a mão em uma panela que está quente e sabe o que isto vai lhe causar, uma vez que é provável que já tenha passado por uma experiência como esta ou alguma outra que lhe tenha gerado algum trauma. Recordo-me da ocasião em que ui andar de moto pela primeira vez com meu tio, quando ainda era criança. Após darmos um longo passeio, desci pelo lado errado da moto, encostei minha perna no escapamento e, por estar quente, tive uma grande queimadura em minha perna. No momento que ui descer da moto, meu sistema perceptor (SP), naquele momento, não identificou perigo algum em sua pesquisa à memória de curta duração (MCD) nem na memória de longa duração (MLD) e como resposta meu processador cognitivo (PC) confirmou a ação que deveria descer, logo meu processo motor (PM) assim o ez. Após esta experiência, sempre que precisei andar de moto novamente, e oram poucas, ao chegar perto do momento de subir e/ou descer do veículo, meu sistema perceptor (SP) imediatamente, ao acionar minha memória de trabalho (MT), tem como resposta colocada na memória de imagem visual (MIV) a cena do meu erimento, ato que az com que meu sistema cognitivo (SC) acione meu sistema motor (SM) com a ação de: não aça nada, só depois é que o SC aciona meu sistema motor (SM) de orma que minha ação seja descer. Perceba quantos elementos estão envolvidos em uma simples ação como esta. Ainda com relação ao exemplo acima, é provável que tal ocorrência seja uma das responsáveis por não ser muito adepto a andar de moto, agora, traga isto para nosso desenvolvimento de sistemas. Este mesmo mecanismo de memória será acionado e uncionará desta orma para todos os estímulos que orem dados ao usuário. Imagine que o usuário tenha tido algum tipo de experiência ruim com algum padrão de interace, mensagens transmitidas pelo sistema, cores, volume




de inormações na tela, tudo isto pode disparar uma ação de aversão do cliente. Agora que entendemos um pouco a relação quanto ao uso da memória, vamos entender um pouco mais de cada um dos três subsistemas que azem parte e interagem com o modelo MPIH. 1. O Sistema Perceptual


É o sistema perceptual que é responsável por capturar as sensações do mundo ísico detectadas pelos sistemas sensoriais do nosso corpo e transormar em representações internas. Dentre os sistemas sensoriais humanos, vamos alar do visual. Parece que a ação de ver é algo simples, mas na verdade ela envolve um conjunto enorme de subsistemas (visão central, visão periérica, movimento dos olhos, movimento da cabeça) que são de grande complexidade. Nosso raio de visão parece grande, mas nem tudo é “realmente visto”, ou melhor, interpretado. De nosso raio de visão que é relativamente grande, apenas algo em torno de dois graus é realmente “visto” (capturado para análise), a isto chamamos de região óvea. Nossos olhos estão em contínuo movimento e a fixação da visão ocorre quando algo que nos interessa ou é importante é detectado. Esta movimentação é requente e podemos dizer que na média o tempo gasto para que algo que é de interesse tenha nossa atenção tomada e visão fixada é de 230 ms. Após esta fixação, há o tempo médio de análise que varia de pessoa para pessoa, mas podemos dizer que pode variar de 70 a 700 ms. Esta variação tão grande se dá pela complexidade da tarea que está sendo executada, se estamos lendo um conteúdo que é de nosso conhecimento, o tempo gasto para que a inormação seja interpretada é relativamente menor se comparado com assuntos ao qual não estamos tão amiliarizados. O tempo que uma pessoa leva para ler um texto está intimamente relacionado com o quanto uma pessoa é capaz de captar a cada vez que sua visão é fixada sob o texto. Segundo Rocha (203), considerando o tempo de fixação de 230 ms, se uma pessoa a cada vez que fixa a visão sobre um texto consegue captar umaletra, a sua média de leitura será de 52 palavras por minuto (considerando uma média de 5 letras por palavra). Se a cada fixação ela conseguir captar umapalavra, sua média


III

de leitura será de261 palavras por minuto. Se a cada fixação de visão a pessoa conseguir captar uma frase, seu tempo de leitura será de652 palavras por minuto (uma média de 2,5 palavras por rase). Um ©shutterstock ator que pode impactar este tempo de leitura é a complexidade do assunto que está sendo proposto, a dificuldade gerada pelo nosso processo cognitivo pode ser uma limitante para a leitura. Uma vez que há o reconhecimento, captação da palavra, este é analisado pela memória de trabalho (MT), e uma representação visual aparecerá na MIV, ou na MIA se or auditivo. Segundo Rocha (2003), este elemento é aetado por suas propriedades ísicas, como intensidade, cor, orma. Segundo Preece (2005, p. 102), temos: Talvez a descoberta mais conhecida em psicologia (certamente a de que a maioria dos estudantes lembra, mesmo muitos anos após ter terminado seus estudos) é a teoria de George Miller (1956), segundo a qual 7 +- 2 porções de informações podem ser armazenadas na memória de curta duração (MCD) de uma só vez (parafraseando o autor: ou seja, informações que foram percebidas pela primeira vez). ...podemos ter vários elementos como números, letras, palavras, comandos. De acordo com a teoria de Miller, portanto, a capacidade de memória imediata das pessoas é muito limitada. Elas conseguem lembrar apenas de algumas palavras, números ou símbolos que ouvira ou viram. Se você não está familiarizado com este fenômeno, experimente fazer o seguinte exercício: leia a primeira sequência de números apresentada a seguir (ou peça que alguém e leia para você), esconda-a e tente lembrar do maior número possível de itens, repita o mesmo procedimento com as outras sequências. 3,12,6,20,9,4,0,1,19,8,97,13,84 gato, casa, papel, sorriso, pessoa, vermelho, sim, número, sombra, vassoura, chuva, planta, lâmpada, chocolate, rápido, um, moeda, jato t,k,s,y,r,q,x,p,a,z,l,b,m,e De quantos você lembrou corretamente em cada lista? Entre 5 e 9, como sugere a teoria de Miller?




... Você pode agora estar pensando, “Ok, isto é interessante mas o que tem haver com design e interação?”. Bem, esta teoria cinquentenária não apenas tem seu lugar na psicologia; ela também causou grande impacto em IHC. Infelizmente por razões erradas. Muitos designers ouviram falar e leram a respeito desse fenômeno e pensaram “Ah, eis aqui algo de psicologia que posso aplicar no design de interface”. Você concorda com eles? Se sim, como a capacidade das pessoas de lembrar apenas de 7+-2 porções de informações pode ter alguma utilidade no design de interação? . 8 9 9 1 e d o ir e r e v fe e d 9 1 e d 0 1 6 . 9 i e L e l a n e P o ig d ó C o d 4 8 1 . t r A . a d i b i ro p o ã ç u d o r p e R

De acordo com pesquisas realizadas por Bob Bailey (2000), vários designers foram levados a acreditar nas seguintes recomendações, criando até mesmo interfaces com bases nelas: Tenha somente sete opções em um menu. Apresente apenas sete ícones em uma barra de menus. Nunca faça uma lista com mais do que sete marcadores. Coloque somente sete botões no topo de uma página web. Coloque somente sete itens nas opções de um menu.

Quanto menos informações estiverem nas telas do sistema, menor o tempo de leitura que será necessário ao usuário, o que torna seu processo mais ágil. Quanto mais simples forem os termos utilizados, mais fácil será o processo de interpretação pelo usuário. Quanto melhor organizada as informações estiverem na tela, reduzindo a necessidade de trocados entre os subsistemas dacabeça), visão (visão pe-o riférica, movimento olhos, movimento da maiscentral, rápido visão se dará processo de análise do usuário. Um bom design precisa avaliar as formas de apresentação das informações. Por Exemplo: como seria melhor representado um campo de preenchimento obrigatório em um cadastro?


III

Todas estão erradas. Por quê? A razão é que são todos itens que podem ser vistos e revistos e que não precisam ser recuperados pela memória de curto prazo. Não aparecem na tela e depois desaparecem exigindo que o usuário lembre deles antes de decidir qual selecionar. Se você tivesse de encontrar no conjunto de palavras que apresentamos anteriormente, um item alimentício que as pessoas desejam, você encontraria sem problema? Não, apenas iria olhar a lista até que reconhece aquele chocolate que responde a tarefa e o selecionaria – bem como as pessoas fazem quando interagem com menus, listas e tabelas – independente destas conterem três ou trinta itens. O que se exige dos usuários aqui não é lembrar o máximo possível de itens, apenas os vendo ou ouvindo uma única vez em sequência mas olhar para um conjunto deles até que se reconheça o que se quer, uma tarefa um tanto diferente. Além disto, existem pesquisas em psicologia que podem ser mais bem aplicadas ao design de interação.

2. O Sistema Motor Você pode estar imaginando, qual o motivo de me atentar ao sistema motor do ser humano quando se ala de design e interação? Bem, a resposta é bem simples, veja comigo. Acabamos de avaliar no item anterior como é relevante nossa atenção com o que exigimos que nossos usuários leiam nos produtos que disponibilizamos, agora precisamos avaliar o tempo que será exigido de interação do usuário com nosso sistema por meio de digitação, cliques, sempre lembrando que há envolvimento direto entre o que está sendo produzido pelo nosso sistema motor e o que está sendo interpretado pelo nosso sistema perceptor. Após o processamento perceptual e cognitivo, finalmente temos o pensamento transormado em ação, logo temos nosso sistema motor em movimento. Uma das principais ormas de interação dos usuários com os sistemas inormatizados se dá por meio do teclado. Estudos mostram que um novato pode levar até 1000 ms enquanto uma pess oa com maior experiência pode levar em torno de 60 ms para interagir via teclado. Pensando que um processo de digitação envolve duas operações (apertar e soltar; clicar e soltar quando via mouse), temos em média o tempo de 140 ms para cada toque/clique para um usuário avançado. Nossos sistemas precisam levar em consideração o número de inormações que precisam ser inseridas pelo


©shutterstock



Quanto tempo leva um usuário iniciante para realizar uma operação corriqueira em seu sistema? Você já avaliou que a possível rejeição dele para usar seu sistema pode ser esta demora? Quantas informações precisam ser preenchidas para que um relatório seja gerado? Quantos cliques precisam ser dados para que uma informação seja extraída? . 8 9 9 1 e d o ir e r e v fe e d 9 1 e d 0 1 6 . 9 i e L e l a n e P o ig d ó C o d 4 8 1 . t r A . a d i b i o r p o ã ç u d o r p e R

usuário final. Além disto, precisamos avaliar qual o tipo de usuário que estará interagindo com o sistema. Como verificamos, quanto mais inormações, mais tempo necessário para que o processo seja finalizado, quanto mais inexperiente o usuário ou quanto maior o número de cliques, maior será a demora, e por aí vai. 3. O Sistema Cognitivo Podemos dizer que nosso sistema cognitivo envolve o processo de aprendizado, recuperação de atos e resolução de problemas. Quando alamos de interaces de interação com sistemas, o ideal é que ele uncione meramente como um conector do sistema perceptual e gerador de saídas para o sistema motor. Nosso sistema cognitivo trabalha ortemente com nossa memória de curta duração (MCD) e nossa memória de longa duração (MLD). Aquilo que está sendo necessário para a operação que está sendo trabalhada é armazenado em nossa MCD, já aquilo que virou aprendizado, aquilo que necessita de armazenamento, será gravado na MLD. ©shutterstock Podemos dizer também que a MCD é ormada por pedaços de inormações, estes que têm como srcem a MLD. Na memória de longa duração (MLD), podemos ter inormações que, uma vez ativada e presente na MCD, podem se transormar no elo que outras inormações correlacionadas sejam recuperadas.


III

Nossos sistemas precisam apresentar opções que auxiliem, rapidamente, nosso cognitivo a recuperar uma informação já armazenada!

Certamente você já deve ter se deparado com alguma situação em que precisou se lembrar de alguma coisa e não conseguiu, até que alguém disse uma palavra que lhe ez recuperar todo o conteúdo. Isso acontece quando estamos tentando nos lembrar do nome de um filme, uma música e por aí vai. A memória de longa duração (MLD) armazena toda gama de conhecimento que o usuário oi acumulando em sua vida, toda inormação pode ser recuperada pela memória de curta duração (MCD) e não há como apagar uma inormação que já esteja registrada na MLD, entretanto, a recuperação pode apresentar alhas quando associações não são encontradas ou quando houver intererência entre conteúdos que estejam armazenados. Quando alamos de processo cognitivo, estamos alando de algo que também pode ser medido, assim como o reconhecimento de um caractere ou o tempo de digitação deste. O processo como um todo pode variar entre 25 e 170 ms. Segundo Rocha (2003), há um exercício interessante para compreendermos a ação de nossos mecanismos perceptuais, motores e cognitivos: imagine que você está dirigindo em direção à determinada localidade e alguém pede para você ir explicando cada ação sua durante essa tarea. A rota é conhecida e o tráego está calmo. A partir de certo ponto, aparece uma interrupção na rota e você tem que desviar do caminho usual, buscando um caminho desconhecido. O tráego agora está conuso e nervoso... como fica a sua tarea? Enquanto você conhece a rota não precisa colocar muito esorço cognitivo no que está azendo e, então,

Permitir associar tarefas novas com algo que já seja de conhecimento prévio do usuário pode permitir que informações importantes de sua MLD sejam recuperadas e auxilie na execução do que está por fazer!




“alar sobre” é ácil. Quando a situação muda, você passa a ter que se concentrar mais para descobrir para onde ir – mais processamento cognitivo é necessário – e você para de alar. Não é muito dierente a problemática de um usuário que está realizando uma tarea e agora precisa mudar rapidamente, estava azendo uma venda e agora precisa passar para uma devolução da venda, mas é algo que não está acostumado a azer!


MECANISMOS DA PERCEPÇÃO HUMANA Para que haja uma boa utilização do sistema proposto é necessário que o usuário interaja com ele e, para isto, é necessário que ele “perceba” todos os detalhes que azem parte deste processo.

Existem várias teorias que tentam explicar o mecanismo da percepção humana, duas delas são a construtivista e a ecologista. Na teoria construtivista, acredita-se que nossa visão do mundo é ormada ativamente por inormações obtidas no ambiente somadas ao conhecimento previamente armazenado. Nesta teoria, a inormação é construída envolvendo o processo cognitivo. Nela, ao recebermos uma inormação (estímulo), iremos recorrer ao processo damemória descrito anteriormente nesta unidade para que seja significada. Na teoria ecologista, a percepção é um processo direto que envolve a detecção de inormações do ambiente e não requer qualquer processo de construção ou elaboração. Esta teoria trabalha com a ideia de que objetos carregam certas características que dirigem nossa percepção sobre eles. Quando ©shutterstock

Mecanismos da Percepção Humana

III

alamos sobre Affordance no tópico sobre usabilidade nas unidades anteriores, estamos alando da utilização prática de elementos da teoria ecologista! Apesar de dierentes, podemos explorar ambos no desenvolvimento de nossas soluções!

Conhecendo os mecanismos humanos de memória, principalmente a capacidade de nossa memória de curta duração, podem-se criar recursos na interace que nos poupem de ter que lembrar detalhes necessários à interação, ao mesmo tempo em que nos liberem para ocupar a memória com inormação relevante. R e p r o d u ç ã o

O MODELO GOMS Segundo Rocha (2003), temos que o modelo GOMS veio ornecer um modelo de engenharia para a perormance humana, capaz de produzir predições quantitativas a priori ou em um estágio anterior ao desenvolvimento de protótipos e teste com usuários. Ele prevê o tempo de execução, tempo de aprendizado, erros etc, identificando partes da interace associadas a essas previsões, de orma a orientar o redesign. O significado desta sigla GOMS é (G) Meta, (O) Operadores, (M) Métodos, (S) Regras de Seleção. Este modelo trabalha com a seguinte premissa: “os usuários agem racionalmente para conseguirem alcançar suas metas”. Os componentes básicos que compõem este modelo são: ■ Metas: as metas representam o que o usu-

ário deseja azer com o sistema. As metas também servem para estabelecer pontos de controle, até onde o usuário chegou com sucesso caso tenha que voltar e começar o processo novamente. Para ©shutterstock



ficar mais claro, vamos usar como exemplo uma situação de venda. A meta será realizar a venda do produto “X” para um novo cliente. ■ Quando alamos de uma situação em que o usuário poderá voltar racionalmente a um ponto no passado e recomeçar,imagine que, por restrições financeiras, a venda com cheque não possa ser concretizada para o cliente, ele pode voltar até o ponto onde se inorma a orma de pagamento do cliente e escolher uma nova modalidade de pagamento, sem haver perda.


■ Para que esta meta seja possível de ser realizada, o usuário utilizará os próximos três elementos abaixo. ■ Operadores: são elementos perceptíveis, cognitivos e motores, cuja ação é estritamente necessária para que a meta seja alcançada. Seguindo o mesmo exemplo acima, estamos alando de selecionar no menu a opção de lançamento de uma nova venda, de clicar na opção “novo pedido”, selecionar o produto “X” da lista de itens disponíveis, são todas as ações que o sofware permite que o usuário aça. ■ Métodos: são todos os procedimentos necessários para conseguir realizar a tarea, são sequências bem aprendidas de submetas e operadores que permitem realizar a tarea. ■ Seguindo o exemplo acima, para que a meta vendas seja alcançada, preciso estar apto a incluir itens no meu pedido de venda (método), estar apto a adicionar parcelas na minha venda (método), e perceba que para cada método destes serão necessárias várias interações com operadores de seleção, botões, e por aí vai. ■ Regras de seleção: se reere às estruturas de controle utilizadas no processo, em geral são regras do tipo “se-então”. Elas se dão pela experiência na tarea ou por treinamento. No nosso caso acima, o usuário poderia azer todo processo de venda usando apenas teclas de atalho para transitar entre os possíveis conjuntos de inormações (cliente, itens do pedido, vencimentos...) ou azer uso de interação com o mouse e teclado. Quantitativamente podemos chegar a um tempo gasto para que cada operação seja realizada, assim como ao tempo necessário para que métodos sejam realizados. Podemos chegar a uma medida da qualidade em que métodos são realizados, exemplo, métodos que exigem muito tempo de interação estão mais propensos

O Modelo Goms

III

a gerar dificuldade de aprendizado nos usuários, logo teriam menor qualidade. Um bom acompanhamento do usuário permitirá avaliar suas reações, seus sentimentos expressos nesta ase e, assim, poderia tomar ações mais seguras. Existem opções em que o mapeamento das reações/emoções dos usuários ao uso da erramenta pode ser capturado por meio do que é chamado de uso de aplicações com apoio de “ trekking glasses”. O usuário utiliza uma espécie de óculos, este está conectado a um programa de computador que tem o objetivo de mapear alterações na pupila do usuário. Geralmente quando nos deparamos com algo que nos chateia ou algo que gostamos muito, nossa pupila se dilata e, desta orma, podemos medir a relação emocional da pessoa com o produto. Outra técnica que pode ser utilizada em conjunto é o mapeamento da dilatação dos poros, quando recebemos algum tipo de estímulo (positivo ou negativo) isto pode ser mapeado por esta análise. Para isso, existem aparelhos que podem mensurar este tipo de ocorrência, que uncionam semelhante a pequenas luvas que serão utilizadas por nossos usuários enquanto estiverem manipulando nossos produtos. Perceba que recursos tecnológicos como os apresentados, associados com os demais elementos propostos pelo modelo GOMS, podem nos dar maior segurança em nosso processo de análise. O modelo GOMS está relacionado à abordagem geral de análise das tareas, desta orma, enatiza os procedimentos que o usuário deve aprender para realizar com eficiência o sistema. Quando descrevemos estes procedimentos podemos quantificar as etapas assim como seu aprendizado, isto também permite antever possíveis alhas de design e também permite uma avaliação da qualidade do produto que está sendo desenvolvido. Outras duas erramentas bastante simples que podem ser utilizadas no mapeamento das reações geradas aos nossos usuários no momento da interação são: 1. Mapeamento de palavras: nesta técnica, é apresentado um grupo de palavras que descrevem os mais variados sentimentos e pede-se que o usuário relacione quais estavam inseridas na operação que estava azendo. 2. Mapeamento de sentimentos: de você já deve ter visto imagens contendo




um rosto sorrindo e a intensidade do sorriso vai diminuindo até que o último rosto se parece com o de alguém que está triste. Bem, esta erramenta de associação é bastante simples e pode ser utilizada para que o usuário ligue o sentimento gerado com a operação que oi realizada.


MODELOS MENTAIS Os modelos mentais são explicados pela Psicologia Cognitiva com respeito a sua estrutura e unção no raciocínio humano e no entendimento da linguagem. São representações analógicas ou combinações de analogias e proposicionais, estão muito relacionados a imagens, mas não se limitam a isto. Segundo Rocha (2003), modelos mentais são acionados quando nos é reque-

rida necessidade de criar inerências ou previsões a respeito de um determinado assunto. Acho pouco provável que você “saiba de cabeça” (ou seja, tenha conhecimento específico sobre o assunto armazenado) sobre a quantidade de janelas que tem em sua casa. Este é um ótimo exemplo onde podemos azer uso de um modelo mental para recuperação de uma inormação. É provável que você se imagine caminhando pela casa verificando os cômodos existentes e assim contando as janelas. Precisamos ter em nossas mentes que o entendimento das pessoas sobre os elementos que irão demandar interação é raco, impreciso e incompleto (cheios de buracos), e a habilidade de executar modelos mentais é limitada pelo seu sistema perceptivo e cognitivo. Para que as metas (conorme modelo GOMS) sejam atingidas, você irá precisar de um conjunto de métodos e operações, talvez pela sua alta de habilidade, irá lançar mão de modelos mentais que lhe ©shutterstock

Modelos Mentais

III

auxiliarão no processo de obtenção da inormação. Imagine um programador que, baseado em uma lista de elementos inormados, se depara com a necessidade de contar quantos destes elementos têm uma característica “x”. Imagine que este programador não conheça bem a linguagem, na verdade seja um novato. Ele não sabe da existência dos comandos de interação ainda, ou melhor, ainda não está 100% amiliarizado com ela, mas sabe que, por meio de um modelo mental, ele pode encontrar a resposta para solucionar este problema. Em um ambiente real, se esta lista de elementos osse pessoas e se a característica desejada osse aquelas que usam camisa vermelha, acredito que um bom modelo partiria da lógica de organizar todas estas pessoas em uma fila e então percorrer esta contando o número de ocorrências encontradas. Agora que meu modelo está pronto, basta buscar na linguagem de programação qual o recurso disponível que me permite realizar tal operação. Modelos mentais ajudam nossos usuários de sistema a pensar em operações que necessitam azer. Pode ser que um usuário nunca tenha eito um processo de vendas, pode ser que este seja apenas um operador financeiro desta, mas se este racionalizar poderá imaginar quais serão os passos necessários que devem ser realizados para que a venda seja realizada para um cliente. Estas situações nos mostram que usuários acabam desenvolvendo dois tipos de modelos mentais principais, o estrutural e o uncional. No modelo mental estrutural, é assumido que o usuário tenha conhecimento (inormação disponível para uso em memória) sobre como um arteato unciona.

Nossos sistemas precisam seguir modelos/padrões de interação que ajudem o usuário a associar tais interações a modelos mentais de como ele deve funcionar. E então, teremos certeza de que ele poderá realmente fazer uso disto fazendo uso de seus modelos funcionais!




Se eu pedir para que você descreva como um televisor, ou máquina de lavar ou um carro unciona, é provável que você não tenha todos os detalhes técnicos, mas você conseguirá dar várias inormações sobre como é o uncionamento de algum dos arteatos acima. Este modelo é ormado nas pessoas conorme sua vivência.


O modelo mental uncional tem como base que o usuário tem o conhecimento de como usar a máquina. Voltando ao exemplo do carro, você desenvolve o modelo estrutural sobre o uncionamento do veículo e agora tem a ideia de como usar este para se locomover. Podemos mensurar se nossos sistemas estão propiciando que nossos usuários açam uso de modelos mentais, uma boa abordagem é acompanhar testes destes usuários. Precisamos ter em nossas mentes que, avaliando os princípios de modelos mentais, podemos acompanhar um usuário operando um sistema em busca de alcançar suas metas, este acompanhamento pode ser eito solicitando que este ale em “voz alta” sobre sua interação com osistema. Esta avaliação pode nos dar pistas sobre se o modelo mental da pessoa que está sendo avaliada é um modelo válido e se nosso sistema está propiciando que esta consiga realizar suas operações. Lembre-se, modelos mentais são ótimos para avaliação quando: 1. Usuário é novato no sistema. 2. Usuário não interage com aquele tipo de operação (um comprador tendo que realizar processo de vendas). Qualquer sistema computacional será mais simples se tiver um bom modelo conceitual, é nossa tarea construir um modelo que seja adequado ao uso do arteato. Não podemos esquecer que nós, como designs, temos também um modelo mental sobre como as coisasacontecem, e este modelogeralmente está ortemente

Modelos mentais apoiam nossa antecipação frente a problemas!

Modelos Mentais

III

contaminado por nossa grande habilidade de utilização de sistemas ou capacidade de abstração. Nem sempre, na verdade quase nunca, em se tratando de sistemas, resolvemos os problemas da mesma orma que o usuário final. O usuário final irá interagir com as uncionalidades criadas, com a orma que o sistema responde, ajudas de sistema, tudo isto orma o que chamamos de aparência ísica do sistema pelo qual o usuário interage. Esta imagem ísica deve ser consistente com o que o usuário tem de modelo mental para que tal tarea seja realizada. Este cuidado mostra a importância de um trabalho conjunto para que os sistemas sejam mais atrativos e realmente usuais aos nossos usuários.




INTRODUÇÃO DE COMO FUNCIONA A M EMÓRIA HUMANA? Por Richard C. Mohs, PHD Quanto mais se sabe sobre a memória, melhor se compreende como melhorá-la. Neste artigo você terá uma visão geral básica como sua memória funciona e de que maneira os efeitos do envelhecimento afetamde sua capacidade de lembrar. O primeiro choro de seu filho, o gosto dos biscoitos de polvilho da sua avó, o cheiro da brisa do oceano. São esse tipos de memórias que formam a experiência contínua de sua vida - elas oferecem uma percepção de personalidade. São elas que fazem você se sentir confortável com pessoas e lugares familiares, conectam seu passado com seu presente e oferecem uma estrutura para o futuro. De certa maneira, é nosso conjunto de memórias coletivas - nossa “memória” como um todo - que nos torna quem somos. A maioria das pessoas fala sobre a memória como se ela fosse parte de seu corpo. Mas a memória não existe da mesma forma que o corpo - não é algo que se pode tocar. É um conceito que se refere a um processo de lembranças. No passado, muitos especialistas ficavam satisfeitos em descrever a memória como um tipo de pequeno gabinete de arquivo para pastas de memórias individuais em que as informações eram armazenadas. relacionavam a memória um supercomputador neural preso ao couro cabeludoOutros humano. Porém, atualmente, osaespecialistas acreditam que a memória é muito mais complexa e difícil de se compreender - e que ela não está localizada em um determinado local do cérebro por ser um processo que ocorre em todo o cérebro. Você se lembra do que comeu no café da manhã de hoje? Se a imagem de um grande prato de ovos fritos e bacon surgiu na sua mente, você não a pescou de algum corredor neural fora de rumo. Em vez disso, essa memória foi o resultado de um poder construtivo incrivelmente complexo (um poder que cada um de nós possui) que remontou impressões de memória dispersas a partir de um padrão de células distribuídas em todo o cérebro parecido com uma rede. Sua memória é realmente formada por um grupo de sistemas em que cada um tem um papel diferente na criação, no armazenamento e na lembrança dessas memórias. Quando o cérebro processa as informações normalmente, todos esses sistemas diferentes trabalham perfeitamente em conjunto para fornecer um pensamento coeso. O que parece ser uma única memória é, na verdade, uma construção complexa. Se pensar em um objeto - digamos, uma caneta - o cérebro lembra do nome do objeto, seu formato, sua função, o som que faz quando desliza sobre o papel. Cada parte da memória do que é uma “caneta” vem de uma região diferente do cérebro. A imagem inteira dessa uma caneta é ativamente reconstruída pelo cérebro a partir de muitas áreas diferentes. Os neurologistas estão apenas começando a entender como as partes são remontadas em uma peça coerente.

Se você estiver andando de bicicleta, a memória de como operar a bicicleta surge a partir de um conjunto de células cerebrais. A memória de como ir de um lugar a outro vem de outro bloco, a memória de regras de segurança ao se andar de bicicleta vêm de outro e aquele sentimento de apreensão que se tem quando um carro faz uma curva perigosamente perto de você, vem de um outro bloco. Ainda assim, você nunca está consciente dessas experiências mentais separadas, nem que elas estão todas vindo de partes diferentes de seu cérebro porque elashá trabalham harmoniosamente juntas.você Na verdade, os especialistas nos dizem que não uma distinção sólida entre como lembra e como você pensa. Isso não significa que os cientistas descobriram exatamente como o sistema funciona. Eles ainda não compreendem exatamente como você se lembra ou o que ocorre durante a lembrança. A pesquisa sobre como o cérebro organiza as memórias e onde essas memórias são adquiridas e armazenadas tem sido, por décadas, uma busca interminável entre os pesquisadores. Ainda assim, há informações suficientes para fazer algumas suposições. O processo da memória começa com a codificação, em seguida, passa para o armazenamento e, eventualmente, pela recuperação. Disponível em: . Acesso em: 26 jan. 2016.

O que são modelos mentais: Dica s para delegar e liderar. . Acesso em: 26 jan. 2016.

CONSIDERAÇÕES FINAIS . 8 9 9 1 e d o ir e r e v fe e d 9 1 e d 0 1 6 . 9 i e L e l a n e P o ig d ó C o d 4 8 1 . t r A . a d i b i o r p o ã ç u d o r p e R

Prezado(a) aluno(a), nesta unidade entendemos um pouco mais sobre como unciona o processo da memória humana e como isto aeta o processo de interação humano-computador. Entendemos também como unciona o processo sensorial humano, como os elementos de visão e movimento são tão importantes e podem ser trabalhados para a construção de um bom design. Também vimos como podemos medir se os nossos esorços para a construção de um bom modelo de interação está sendo alcançado, vimos como o modelo GOMS pode nos apoiar na validação com o usuário e se estamos no caminho certo. Outro ponto abordado oi a importância de como a correlação com bons modelos mentais pode apoiar o processo de aprendizado do usuário, auxiliando na utilização do sistema e reduzindo sua curva de aprendizado. Na próxima unidade, vamos entender como podemos estabelecer os requisitos necessários para que tudo o que estudamos até aqui possa ser transormado em um sistema realmente atrativo para o usuário.

CONSIDERAÇÕES FINAIS

1. Baseado no que vimos nesta unidade, como os fatores de funcionamento da memória devem nos influenciar no desenvolvimento de

designers?

2. Como podemos avaliar se nosso design permite uma boa interação com o usuário? 3. Quais recursos podem ser utilizados para que uma boa correlação a modelos mentais do usuário possam ser utilizados?


IDENTIFICANDO AS NECESSIDADES E ESTABELECENDO OS REQUISITOS

E D A D I N U

IV

Objetivos de Aprendizagem ■ Entender a importância dos requisitos no processo de design e interação. ■ Avaliar como podemos coletá-los de forma mais segura. ■ Compreender como podemos usá-los na construção de soluções.


■ O quê, quem, quando, onde, como e por quê? ■ O que são requisitos? ■ Como coletá-los? ■ Como interpretá-los e analisá-los?

INTRODUÇÃO Caro(a) aluno(a), talvez a tarea mais complexa que há no processo de design e interação seja o processo de identificação de necessidades dos usuários e então


o estabelecimento de requisitos. Já vimos nas unidades anteriores que designers não são usuários e nem usuários são designers, este antagonismo é importante para que possamos entender a necessidade de um trabalho conjunto. Semelhante a uma consulta médica, se o profissional da área da saúde não conseguir extrair as inormações necessárias de seu paciente, não conseguirá avaliar os sinais passados por este e nem conseguirá azer o uso correto das erramentas (exames) que tem ao seu dispor, é provável que o tratamento não seja eficiente e o paciente continue com o problema. Você pode me perguntar, como é possível um médico com tantos recursos acima não chegar a um diagnóstico conclusivo? Isto é alta de competência? Não diria isto de orma direta, mas suponho estar relacionado à ausência de todas as competências necessárias em extrair as inormações do paciente e, para isto, teria que ser um pouco psicólogo, entender um poucosobre o uncionamento humano. Nós da área de tecnologia da inormação passamos pelo mesmo problema. Quando estamos de rente a um cliente para a construção de um novo produto, que irá demandar um novo design ou estamos avaliando a necessidade de um redesign, somos como médicos na rente de um paciente e precisamos extrair o máximo de inormações para um diagnóstico correto do que precisa ser construído. Dierente do que muitos podem imaginar, a identificação das necessidades não é só uma questão de experiência, e sim um conjunto de técnicas e erramentas que podem nos apoiar. É inegável que uma das principais erramentas para

este processo é sim a experiência, ter vivenciado situações semelhantes anteriormente, isto ará com que se vá à raiz do problema mais rapidamente. Nesta unidade, vamos entender mais como este processo pode ser realizado, como as necessidades podem ser identificadas, mapeadas e tratadas se tornando ontes de apoio na construção de sistemas. Vamos estudar o que azer com estes requisitos que estarão sendo construídos e, na próxima unidade, vamos avaliar um pouco como este processo está envolvido no ciclo de desenvolvimento de sofware. Introdução

IV

O QUÊ, QUEM, QUANDO, ONDE, COMO E POR QUÊ? Ao analisar o título, tenha calma, pois não vamos estudar aqui

nenhuma erramenta como a 5W2H ou algo do gênero, entretanto, são estas algumas das inormações relevantes as quais precisamos atentar no levantamento das necessidades para nossos sistemas. Vamos avaliar cada uma destas alternativas:


1. O que estamos tentando alcançar com esta atividade de design? Conorme Preece (2005, p. 222):

©shutterstock

São dois os motivos, o primeiro consiste em entender o máximo possível os usuários, seu trabalho e o contexto desse trabalho, de forma que o sistema em desenvolvimento possa fornecer-lhes suporte na realização de seus objetivos. Chamamos isso de “identificação de necessidades”. A partir daí, nosso segundo objetivo consiste em produzir, a partir das necessidades identificadas, um conjunto de requisitos estáveis que formem uma base sadia para se pensar o design. Isso não é necessariamente um documento nem um conjunto de prescrições rígidas, mas você precisa estar certo de que os requisitos não se alterarão radicalmente durante o tempo de se realizar o design e de se ter o feedback das ideias.

O que estamos procurando azer é ter um norte, um horizonte para onde ir e assim garantir que o trabalho de design não será perdido.

©shutterstock



©shutterstock

2. Quem são os elementos envolvidos neste processo? . 8 9 9 1 e d o ir e r e v fe e d 9 1 e d 0 1 6 . 9 i e L e l a n e P o ig d ó C o d 4 8 1 . t r A . a d i b i o r p o ã ç u d o r p e R

Caro(a) aluno(a), entenda que quanto mais pessoas estiverem envolvidas neste processo melhor. É undamental que o usuário se sinta envolvido, lembre que o que será criado por você será utilizado por ele, logo, é imprescindível que ele se sinta parte da construção desta nova obra. Outro ponto importante é, como vimos noutras unidades deste livro, nossa visão do mundo não é necessariamente a mesma visão que o usuário tem, logo, é undamental o envolvimento da equipe de design e do usuário

final para que ambos possam conceber os melhores requisitos de design.

©shutterstock

3. Quando esta tarea se torna necessária? Vamos alar, na próxima unidade, um pouco mais a respeito do ciclo de vida de um sistema, lá ficará mais claro onde esta etapa se encaixa, mas precisamos entender que o ideal é que esta etapa anteceda o desenvolvimento de qualquer interace de interação com o sistema, evitando assim retrabalho.


IV

©shutterstock

4. Onde é o melhor lugar para que esta tarea aconteça?

Esta é uma tarea de design que não tem um lugar fixo para ocorrer, podemos pensar que o melhor lugar para realizar isto é em nosso estúdio de desenvolvimento, outros podem pensar que o melhor é “na casa do cliente”, sou adepto de que um misto dos dois deve ser observado. Quando estamos no colégio, é menos trabalhoso estar com o proessor ao nosso lado, desta orma podemos ir tirando dúvidas à medida que elas surgem enquanto azemos nossos trabalhos, não é verdade? Tenho por convicção que este é um bom ormato de trabalho a ser cadenciado junto com o cliente.



©shutterstock

5. Como é que podemos levantar estas inormações? Esta é a órmula de um milhão de dólares! Como mencionei na introdução desta unidade, existem várias técnicas e erramentas que podem ser utilizadas com intuito de trazer maior segurança para que as inormações que sejam realmente relevantes tenham sido mapeadas, mas não existe uma órmula que traga 100% de certeza.


Uma das erramentas mais importantes é a experiência. Um design experiente é capaz de antever possíveis problemas que um design menos experiente e, sendo assim, propor soluções de contorno. Vamos mais a rente nesta unidade tratar de um tópico somente ligado a isto, como podemos levantar nossos requisitos! Então, vamos esmiuçar este assunto juntos mais a rente. . 8 9 9 1 e d o ir e r e v fe e d 9 1 e d 0 1 6 . 9 i e L e l a n e P o ig d ó C o d 4 8 1 . t r A . a d i b i o r p o ã ç u d o r p e R

k c o t s r e t t u h s ©

6. Por que esta é uma tarea relevante? Estudos recentes mostram que cerca de 60% dos problemas que acabam levando projetos de novos produtos ao racasso estãorelacionados ao controle de escopo, a figura abaixo oi retirada da pesquisa do PMSurvey de 2012, uma iniciativa de entidades ligadas a gerenciamento de projetos.

Fonte: PMSurvey 2012


IV

Esta pesquisa nos mostra como é importante este quesito para o sucesso de nossos sistemas, escopo mal identificado torna o projeto mais caro (pois na maioria das vezes exige novas implementações, um redesign) e com isso, geralmente, alterações de escopo levam o projeto a apresentar um grande atraso, tudo isto impacta na aceitação do usuário final e, por conseguinte, no sucesso ou não do produto.


O QUE SÃO REQUISITOS? Requisito é um mapeamento do que é que se espera que um sistema apresente. É como se osse uma espécie de declaração do que ele deve ter ou de como deveria operar. Em um requisito também podemos ter a declaração do que não esperar que um produto aça. Por exemplo: quando você compra um aparelho de som, você terá em sua declaração de requisito quais os ormatos de mídia que ele irá reproduzir para você (este é o escopo do que seu produto é capaz de azer). Em outro caso, podemos também ter a declaração de quais as mídias que este seu aparelho não estará apto a reproduzir (isto também é uma definição de requisito). O objetivo do requisito é que seja completo o suficiente para que o desenvolvimento possa ser realizado e que possamos validar com nosso cliente se o que está sendo entregue é realmente o que oi solicitado. Em contrapartida, devemos ter em mente que nossa definição derequisito não pode ser tão trabalhosa que leve tanto ou mais tempo que o próprio desenvolvimento. É necessário haver um equilíbrio, pois evitar ambiguidade e itens omissos não quer dizer “escrever um livro”. Já vi os dois extremos acontecerem, uma vez, em um projeto que acompanhei, os requisitos que oram desenvolvidos oram tão detalhados, ©shutterstock



tão detalhados que quase o mesmo tempo de desenvolvimento oi gasto para que os requisitos ossem eitos. O resultado disto oi a criação de uma enorme documentação, trabalhosa de receber manutenção, que oi deixada de lado muitas vezes no desenvolvimento.


O outro você pode imaginar, várias e várias vezes nos deparamos com requisitos que, quando muito, possuem uma linha. Linha esta que tem que ter a diícil tarea de dar ao desenvolvedor a clareza do que necessita ser eito, a tranquili dade de que impactos não serão gerados e quais critérios serão usados pelo cliente para dar como entregue tal atividade. O produto gerado por ambos os casos são sistemas mais caros e qualidade duvidosa. Conorme Preece (2005), o processo de identificação de requisitos não é tarea ácil, imagine a construção de um website, este pode ter como requisito que o tempo de download de uma página não pode ser superior a 5 segundos, este mesmo website pode ter como requisito que seja atrativo para o público adolescente. Esta inormação (ser atrativo para o público adolescente) é algo que o levará a pesquisar e identificar quais requisitos precisam ser atendidos para que isto aconteça. Agora um ponto que precisamos avaliar é: quais tipos de requisitos precisamos levantar? Você pode se perguntar agora... “mais essa?” Justamente para que possamos direcionar nossos levantamentos, a engenharia de sofware az este tipo de divisão. A engenharia divide tradicionalmente naquilo que chamamos de requisitos uncionais e requisitos não uncionais. ■ Requisitos uncionais

Os requisitos uncionais servem para descrever quais as uncionalidades que um sistema deve ter. Exemplo 01: vamos avaliar um processador de texto. Para este processador de texto podemos dizer que deve apresentar várias opções de estilos de ormatação. Podemos quebrar ainda mais esta uncionalidade e mencionar que este pode apresentar ormatação por parágrao, por caractere e por documento. Ainda podemos quebrar ainda mais e mencionar que este deve ter condições de apresentar 40 opções de onte, estas podem ter a possibilidade de alteração de tamanho


IV

©shutterstock

e cor, apresentar a possibilidade de aplicação de negrito, itálico e sublinhado. Estas seriam algumas das características básicas uncionais que poderíamos listar para um produto como este. Exemplo 02: vamos avaliar um sistema de compras pela web. Este pode apresentar a uncionalidade que permite o usuário pesquisar os produtos desejados; uma vez listados os produtos, é interessante que o usuário possa alterar a orma de visualização podendo classificar por preço, relevância etc., até que se chegue à possibilidade de selecionar o produto desejado de maneira que possa obter maiores detalhes sobre ele. Uma vez selecionado o produto para compra, este pode ser adicionado a um carrinho de compras. Um item relevante é que os requisitos uncionais, como vimos nos dois exemplos acima, são os itens que exigem maior interação com o usuário, logo estes necessitam de atenção especial do design. ■ Requisitos não uncionais Existe na literatura uma quantidade grande de classificações para requisitos não uncionais, abaixo vamos tratar os de maior relevância no processo de design e interação. Para os casos abaixo, vamos adotar como exemplo os listados no tópico anterior (sistema processador de texto e vendas pela web). ■ Requisitos técnicos Avaliando a situação de um sistema processador de texto, um critério importante é avaliação de qual arquitetura é necessária para seucorreto uncionamento. Há poucos anos, nossas preocupações voltavam-se para a dúvida de se




o produto rodaria na arquitetura PC, Mac, Unix; como a explosão de vendas de dispositivos móveis e com a enorme aceitação dos usuários com o uso deSmartphones e Tablets,


vemos estes dois itens impactando diretamente no nosso processo de desenvolvimento. Podemos dizer que nossas aplicações devem ser móveis, ou seja, rodar independente da arquitetura e dispositivo que a estejam hospedando. ©shutterstock Um outro critério técnico interessante é a quantidade de recursos necessários para que aplicação possa operar. É verdade que cada vez mais equipamentos poderosos estão nas casas de nossos usuários potenciais, mas também é verdade que não existem recursos ilimitados. Atenção quanto à necessidade de processamento, memória, armazenamento,link de comunicação, são muito importantes para o projeto de uma nova aplicação. Nos dias atuais, um quesito técnico dos mais importantes é exigência de que as aplicações sejam móveis e que possam rodar tanto em sistemas operacionais da Apple (IOS) quanto no Android. ■ Requisitos de dados

Quando alamos de dados, é relevante pensar na necessidade de disponibilidade destes. Muitas empresas investem pesado em sistemas de replicaçãopara garantir que todos os dados sejam acompanhados em tempo real em suas matrizes. Um ponto importante a ser avaliado é: que tipo de inormação é estratégico ter em tempo real? Que tipo de inormação é aceitável trabalhar com um atraso? Qual o tamanho deste atraso de orma que não comprometa a operação? Respostas a perguntas como estas podem ajudar a empresa a economizar e simplificar o processo de desenvolvimento de sofware. Outro ponto reere-se ao armazenamento das inormações. Muitas empresas têm um certo ©shutterstock


IV

“apego” natural aos dados que são gerados e, por elas, nunca eles seriam removidos. Como disse anteriormente, estamos vivendo em uma época em que os avanços tecnológicos têm sido significativos, mas não existem recursos ilimitados. Até que ponto ter toda movimentação da empresa por 20 anos é relevante? Até que ponto é relevante criar estruturas de resumo e replicação de dados para garantir maior agilidade no acesso e gravação dos dados? Estas questões são relevantes e podem modificar completamente o escopo do desenvolvimento de uma solução. Acompanhei o projeto da criação de um produto que teria que uncionar “no meio do nada”. A finalidade do produto não vem ao caso, mas se destina a um público que literalmente fica em regiões bastante isoladas. Muitas vezes: ■ sem acesso à internet; ■ sem servidores de banco de dados; ■ sem acesso a rede. Como garantir que as inormações geradas por esta aplicação sejam consistidas em um único ponto de análise, por exemplo, em uma matriz? Como garantir que esta aplicação tenha condições de uncionar em ambientes tão inóspitos? Como garantir que esta aplicação não tenha perda deuncionalida des caso seja utilizada em um ambiente tradicional (com acesso à rede, internet). Pois bem, é um bom exemplo de requisito de dado que necessita ser atendido. Pense que tal requisito não seja identificado inicialmente no seu projeto e só venha ser diagnosticado após parte do produto estar pronto? Simplesmente você corre o risco de ter perdido tudo que ez! ■ Requisitos ambientais ou contexto de uso Quando alamos de requisitos ambientais ou de contexto de uso, estamos alando de requisitos relacionados às condições em que se espera que o produto interativo uncione. Podemos pensar em quatro aspectos, são eles: ■ Ambiente ísico: Como é o ambiente ísico onde este produto estará inserido: é um local





©shutterstock

sujo, é um local com pouco ou muita iluminação? É um local ventilado? É um local barulhento? As pessoas que manipularão o sistema necessitam usar algum tipo de vestimenta de proteção, luvas... (pois pode dificultar). É um local com muitas pessoas? É um local reservado ou público onde o sistema estará em uso. Veja quantas questões importantes podemos avaliar antes que o design seja projetado? Perceba como podemos inviabilizar o desenvolvimento de uma aplicação se esta não or projetada avaliando critérios como este. ■ Ambiente social:

Um dos principais pontos diz respeito à localização ísica das pessoas envolvidas no uso da erramenta. Elas estarão fisicamente próximas? Existe necessidade de colaboração no trabalho que estão executando? Em caso positivo, isto necessita ser síncrono ou assíncrono? Como se dará o meio de comunicação entre elas? ■ Ambiente organizacional:

Quando um sistema em hierárquica uma empresa, precisamos pensar como estacolocamos empresa está organizada e tecnicamente. Qual a estrutura técnica existente na empresa (uncionários e equipamento), esta empresa tem um histórico de apoio organizacional à implantação de projetos e a investimentos em tecnologia? Critérios como estes são importantes para o bom dimensionamento do trabalho a ser eito.


IV

■ Ambiente técnico: Quais tecnologias serão utilizadas? Com que tipo de tecnologia ou aplicativo há necessidade de manter compatibilidade? Quais limitações tecnológicas estão sendo impostas (necessidade de aproveitar parque de máquinas da empresa – sem demanda de investimento). ■ Requisitos de usuário

Trata-se da identificação de tipos de usuários com os quais vamos nos deparar para uso de nossa aplicação. Estaremos lidando com usuários novatos ou especialistas? Estaremos lidando com usuários requentes ou ocasionais? Estas duas simples perguntas influenciam, e muito, o ormato de direcionamento do design de nossas aplicações.


Estes usuários irão evoluir no uso da erramenta? Caso a resposta seja positiva, nossa ©shutterstock

aplicação deve ter a possibilidade de ajustar os perfis de interação mediante aprendizado do usuário. ■ Requisitos de usabilidade

Aqui identificamos as metas de usabilidade e as medidas associadas para o uso do produto. Quão eficiente, eficaz e segura necessita ser a orma de interação com o sistema? É de extrema importância avaliar este quesito em separado para prover uma maior aderência rente à necessidade do público para o qual será disponibilizado o produto. ©shutterstock



COMO COLE TÁ LOS? Agora que ficou mais claro o que é um requisito, qual sua importância e os dierentes tipos de requisitos que devem estar em nossa mente quando ormos


trabalhar neste assunto? É chegado o momento de colocar a mão na massa e começar o processo de coleta de requisitos. O propósito da ase de coleta de requisitos é estabelecer e reunir inormações suficientes para o bom trabalho do projeto. Entenda que existem situações onde você já terá em mãos um conjunto de requisitos de orma macro que o cliente já tenha lhe disponibilizado, entretanto, isto não tira de você a responsabilidade de realizar esta ase do projeto mediante a coleta mais detalhada para garantir um bom entendimento. Existe um vasto conjunto de técnicas e erramentas que nos apoiam no processo de coleta de requisitos. O que vamos começar a estudar são algumas destas técnicas que julgo que podem nos apoiar com mais segurança.

©shutterstock

■ Log de dados Quando a tarea é substituir um sistema já em uso, esta é uma erramenta bastante interessante. Um sistema legado geralmente traz consigo um conjunto muito grande de uncionalidades, relatórios e aspectos de usabilidade que precisam ser considerados.

Não é uma única técnica que você usará em seu processo de coleta, e sim um conjunto delas, esteja atento àquelas que melhor se encaixam em sua necessidade.

Como Coletá-Los?

IV

Apesar de não ser uma tarea simples, é uma erramenta poderosa que consiste na habilitação de logs de operação dentro do sistema. A ideia é registrar o que está realmente sendo utilizado, com que requência e qual a perormance de uso. Podemos estabelecer estes logs por meio de programação direta no código-

onte do sistema antigo ou por meio de erramentas de monitoramento do usuário. Quando esta última é a opção a ser utilizada, uma boa escolha é atrelar seu uso a usuários chaves (conorme os perfis identificados) e assim extrair o máximo de inormação quanto ao uso e ormato de interação de cada indivíduo. ■ Engenharia reversa Também é uma erramenta poderosa que permite avaliar com maiores detalhes o que está implementado. Número de relacionamentos, dependências e uncionalidades críticas. Com uma erramenta como esta, é possível avaliar o número de exportações fiscais que uma aplicação possui e, assim, minimizar o impacto de que alguma destas rotinas não estejam no escopo mapeado para o desenvolvimento e para este cliente. É uma erramenta de avaliação bastante técnica, envolve contribuição direta da equipe de T.I. do cliente. ■ Questionários Quantas vezes você respondeu algum tipo de questionário? Pois bem, esta erramenta, apesar de parecer ultrapassada, é muito poderosa e extremamente atual. Hoje em dia, com a possibilidade de aplicação de ormulários de pesquisa on-line, a acilidade de consolidar as inormações para análise é ainda maior. O segredo desta erramenta é identificar o que você realmente precisa saber. Algumas inormações relevantes que podem ser questionadas são: ■ Quais os recursos mais utilizados no sistema? Qual a requência de uso? ■ Quais inormações que julga relevantes não estão presentes nestes recursos? Quais estão e não julga relevante? ■ Qual o tempo de interação necessário para que estas inormações sejam levantadas? ■ Uma listagem completa de todas as atividades realizadas rotineiramente




(ter a requência e tempo exigido). ■ Com quais sistemas a pessoa necessita de interação para realizar as tareas? Que uncionalidades são utilizadas? ■ Quais as rotinas mais críticas que você executa? Qual atraso tolerado?


Perceba que a lista de inormações acima é simples e tem apenas objetivo didático. Para seu projeto, você precisa avaliar quais inormações relevantes precisa levantar e então aplicar aos seus usuários. Esta é uma erramenta que pode ser muito bem utilizada com outra técnica, a de entrevista. Perceba que inormações que julgar relevante ou polêmica, podem azer parte de um ormulário de pesquisa a ser enviado para um grupo de pessoas. ■ Entrevista Esta técnica é muito importante e apresenta bons resultados quando é utilizada no início dos levantamentos de requisito (quando você ainda não tem nada identificado com certeza) ou quando você já tem vários itens mapeados e deseja checar as inormações. A técnica de entrevista apresenta bons rendimentos quando cadenciada mediante um questionário de perguntas, que tem por objetivo acilitar a extração das inormações pertinentes. Esta técnica deve ser aplicada com bastante cuidado, pois pode trazer a ideia de que consome muito tempo e não é interessante, entretanto, desde que com o recurso de um questionário descrito acima e com um orte controle de tempo, pode ser bastante otimizada. Um ato inegável é que todo ser humano gosta de se sentir valorizado e quanto mais pessoas você puder ouvir em seu processo de coleta de requisitos melhor, pois este sentimento de valorização será transmitido a elas, com toda certeza, e com isto você ganhará uma cooperação mais ácil. ■ Grupo de estudos específicos/oficinas

Muito utilizada quando um requisito é polêmico ou complexo, esta é uma ótima erramenta que também deve ser muito bem cadenciada com relação ao tempo. Uma boa estratégia é trabalhar em ormato de brainstorm, listar as ideias Como Coletá-Los?

IV

para elucidação dos requisitos e, após isto, um plano de ação pode ser elaborado para que os pontos conflituosos sejam esclarecidos. Um ponto importante é a utilização de oficinas direcionadas ao entendimento do requisito. Uma vez acompanhei um caso como este que apresentou bastante sucesso. Havia uma certa dificuldade em conseguir encerrar a coleta dos requisitos de um módulo de produção em uma empresa e a técnica adotada oi esta. O Analista conduziu de orma que um ambiente semelhante ao caso real osse simulado e, analisando passo a passo (como se o processo de produção estivesse realmente acontecendo), oi possível então a compreensão da necessidade. ■ Observação natural Se trata de um processo relativamente simples, mas muito produtivo, ainda mais se já houver algum entendimento do escopo que necessita ser criado por parte da equipe de desenvolvimento. Trata-se literalmente de acompanhar e visualizar na prática como é realizado o trabalho com o sistema que será substituído. Esta é uma experiência muito rica a qual recomendo a todos que incluam em seus processos de coleta. Esta é uma ótima experiência que nos auxilia no processo de identificação das necessidades de design para o novo sistema. ■ Estudo de documentação Existem duas ótimas alternativas que muitas vezes são negligenciadas no processo de coleta de requisitos. Uma delas é a solicitação de um processo de catalogação de documentos por parte do usuário. Neste processo, ele cataloga para a equipe de projetos todos os documentos e interaces por meio do qual interage com o sistema. É um processo que pode parecer moroso, mas na verdade não é, e os beneícios para um bom mapeamento do escopo são enormes. Junto com esta catalogação (que necessita serestudada pela equipe doprojeto), há uma segunda alternativa que é o estudo de manuais, documentos operacionais e documentos metodológicos utilizados pela empresa atualmente. Documentos de normas e procedimentos internos das empresas geralmente são ricas ontes de consulta que precisam ser levadas emconsideração no processo de coleta de requisitos. Muito do que se espera que os sistemas açam estão lá, e




critérios preciosos de perormance e usabilidade também podem ser mapeados lá. Estas técnicas apoiam e muito o processo de coleta de requisitos, o trabalho conjunto delas é ainda mais poderoso e como podemos ver em Preece (2005, p.231): Rudman e Engelbeck (1996) descrevem como utilizaram técnicas diferentes a fim de estabelecer os requisitos para uma interface gráfica complexa em uma empresa de telefonia e como diferentes métodos proporcionaram o entendimento de requisitos diferentes. Cinco técnicas distintas foram utilizadas. . 8 9 9 1 e d o ir e r e v fe e d 9 1 e d 0 1 6 . 9 i e L e l a n e P o ig d ó C o d 4 8 1 . t r A . a d i b i o r p o ã ç u d o r p e R

1. A observação no local permitiu-lhes entender a natureza dos negócios atuais. 2. A prototipação participativa, isto é, o envolvimento ativo dos stakeholders no design de um protótipo permitiu-lhes tirar vantagem do conhecimento dos empregados. 3. Entrevistas que visavam o entendimento dos negócios anteriores da empresa permitiram-lhes entender a natureza complexa do domínio mais amplo. 4. Entrevistas que visavam a entender as sequências de decisões dos empregados possibilitaram-lhes criar diálogos para oferecer suporte à negociação entre as partes. 5. Ensaios com protótipos utilizando cenários simulados também ajudaram a criar diálogos para oferecer suporte à negociação entre as duas partes. A diferença entre as terceira e quarta técnicas se dá no foco do questionamento e na notação utilizada para captar dados. Na terceira técnica, os entrevistadores procuraram entender o domínio da aplicação e capturaram informações utilizando redes semânticas, especificamente projetadas para representar tal informação. Na quarta técnica, as árvores de decisão foram utilizadas para se entenderem as metas, os pontos de decisão e ascom opções são levantadas em conta pelos empregados quando lidam um que cliente.

Conorme podemos ver acima, a utilização das técnicas tende a trazer melhor resultado, entretanto, isto não significa que é uma regra nem quem tenha que aplicar todas em meu processo de coleta para garantir que tudo ocorra bem. Para apoiar no processo de seleção da melhor técnica, segue o comparativo abaixo adaptado de Preece (2005).

Como Coletá-Los?

IV

TÉCNIC A

Questionários

Entrevista

BOAPARA TIP O DE DADOS Responder Dados a questões quantiespecífitativos e cas. qualitativos.

Explorar questões.

Grupo de esColetar tudos específi- vários cos/oficinas pontos de vista.

Observação natural

Estudo de documentação

VANTAGE NS

DESVANTAGENS

Pode atingir várias pessoas com poucos recursos.

O design é crucial. O Índice de resposta pode ser baixo, as respostas podem não ser o que você deseja.

Alguns dados quantitativos, mas mais qualitativos.

O entrevistador pode guiar o entrevistado se necessário. Encoraja o contato entre desenvolvedores e usuários.

Requer tempo. Ambientes artificiais podem intimidar o entrevistado.

Alguns dados quantitativos,

Ressalta áreas de consenso e conflito. Encoraja o contato

Possibilidade de dominarem certos tipos de personalidade.

mas mais qualitativos.

entre desen-e volvedores usuários.

Entender Qualitao contexto tivo. da atividade do usuário.

Observar o Requer muito tempo. trabalho real Grandes quantidades oferece perde dados. cepções que outras técnicas não podem oferecer.

Aprender sobre procedi-

Não compromete o tempo dos usuários,

mentos, regulamentações e padrões.

Qualitativo.

O trabalho diário será diferente dos procedimentos documen-

exceto quando tados. utilizado recurso de catalogação.




TÉCNIC A

Log de dados


Engenharia reversa

BOAPARA TIP O DE DADOS EntenQuantider os tativo. recursos realmente usados pelos usuários.

Identificar os recursos implementados que não surgiram em outras formas de catalogação.

Quantitativo.

VANTAGE NS

DESVANTAGENS

Não gera Requer desenvolviimpacto ao mento. usuário final. Identificação dos reais pontos de atenção na implementação. Conhecimento Requer grande envolaprofundado vimento técnico. da estrutura do sistema atual.

Fonte: Adaptado de Preece (2005)

Em resumo, conheça o trabalho que você tem a azer e escolha as melhores armas que você pode carregar para poder vencer este combate que é a coleta de requisitos com qualidade!

COMO INTERPRETÁ L OS E ANALISÁ LOS Quanto antes o processo de análise or iniciado melhor, as inormações reerentes à catalogação estará mais presente na memória, acilitando o processo de interpretação. A primeira avaliação a ser eita é com os próprios envolvidos no processo de catalogação, avaliando os resultados obtidos com a aplicação das erramentas e identificar as expectativas para o processo de análise. O próximo passo é iniciar um processo de catalogação de todos os arteatos Como Interpretá-Los e Analisá-Los

IV

relevantes transormando-os em requisitos de sistema (requisitos uncionais e não uncionais), em que uma análise de dados mais abrangente irá trazer mais detalhes à interpretação inicial dos requisitos. Técnicas dierentes e notações existem para a investigação de aspectos dierentes do sistema, os quais, por sua vez, arão surgir requisitos distintos. Por exemplo, requisitos uncionais tradicionalmente são analisados e documentados utilizando-se diagrama de fluxo de dados, diagramas de estado, diagramas de workflow. Requisitos de dados podem ser expressos utilizando-se diagramas de entidade-relacionamento. Se o desenvolvimento deve apresentar uma abordagem orientada a objetos, então requisitos de dados e uncionais são combinados em diagrama de classes, com comportamentos expressos em diagramas de estado e diagramas de sequência entre outros. Como você pode ver, existem vários diagramas que podem ser utilizados para nos levar a representação do que oi levantado, entretanto não é objetivo deste livro descrever o uncionamento deles. O que vamos ver na sequência são quatro técnicas que apresentam um oco centrado no usuário e que são utilizadas para entender os objetivos e as tareas de cada usuário. Seu resultado serve de apoio para ases seguintes do desenvolvimento, são as seguintes técnicas: Cenários, Casos de uso, Casos de uso essenciais e Análise de tareas. Para que as tareas dos usuários possam ser documentadas de orma que seja acilitada a interpretação e análise do que necessita ser eito, uma ótima alternativa é a construção de cenários. A construção de cenários se dá, inicialmente, por meio da

apresentação textual que é compilada baseada nos itens coletados do cliente, de como os processos uncionam. Para acilitar nossa compreensão, imagine que estamos desenvolvendo um processo de e-commerce e, para isto, coletamos ©shutterstock IDENTIFICANDO AS NECESSIDADES E ESTABELECENDO OS REQUISITOS



O foco da construção de cenários está nas tarefas do usuário!

todos os requisitos necessários pelo cliente. Existem vários cenários que podem ser gerados como parte da construção desta solução, podemos construir cenários reerentes a: 1. Processo de venda com sucesso. . 8 9 9 1 e d o ir e r e v fe e d 9 1 e d 0 1 6 . 9 i e L e l a n e P o ig d ó C o d 4 8 1 . t r A . a d i b i o r p o ã ç u d o r p e R

2. Processo de venda com alha. 3. Processo de venda com pagamento com cartão de crédito. 4. Processo de pesquisa de produtos. Entenda que a ideia por trás da construção de cenários é levantar os macros processos que arão nosso sistema operar de orma que possam ser desenvolvidos, testados e validados pelo cliente em sua etapa de entrega. A construção de cenário pode ser representada graficamente e uma ótima erramenta para isto são os diagramas de sequência. Outra alternativa é o diagrama de caso de uso, que tem como ênase a interação entre usuário e sistema. Casos de uso oram srcinalmente introduzidos na comunidade orientada a objetos, embora seu oco seja especificamente a interação entre o usuário e o sistema, o peso ainda está bastante concentrado na perspectiva do usuário e não no sistema. O termo cenário também é utilizado na construção de casos de uso, representando um caminho a ser seguido no caso de uso, isto é, um conjunto particular de condições. Um caso de uso é associado a um ator, e é o objetivo deste ator, ao utilizar o sistema, que o caso de uso deve retratar. Na retratação deste tipo de técnica, existem dois principais cursos demonstrados, um é o curso normal (aquele definido como sendo o caso corriqueiro que o usuário optaria ao utilizar o sistema), e os cursos alternativos, outras ormas de interação com o sistema. No caso de uso, as interações do ator com o sistema são retratadas como ações a serem realizadas. No caso de um sistema web, a representação do caso de uso teria que o ator (no caso um cliente) pode: consultar um produto, consultar

Como Interpretá-Los e Analisá-Los

IV

status de sua compra, realizar uma compra. Esta é uma ótima técnica, mas apresenta suas limitações e é para tratar estas limitações, assim como as limitações da construção de cenários, que a técnica de casos de uso essenciais oi criada. Conorme Preece (2005, p. 249), temos:

Os cenários constituem histórias concretas que se concentram em atividades reais e específicas. Podem, portanto, obscurecer questões mais amplas voltadas a uma visão organizacional mais abrangente. Por outro lado, os casos de uso tradicionais contêm certas hipóteses, inclusive o fato de que há uma tecnologia com a qual se interage, e também suposições sobre a interface com o usuário e o tipo de interação a ser projetada. Os casos de uso essenciais representam abstrações de cenários, isto é, representam um caso mais geral do que o cenário abrange e tentam evitar as suposições de um caso de uso tradicional. Um caso de uso essencial é uma narrativa estruturada em três partes: um nome que expressa intenção geral do usuário, uma descrição em passos das ações dos usuários e das responsabilidades do sistema. Essa divisão entre responsabilidades do sistema e do usuário pode ser muito útil durante o design conceitual, quando se considera a alocação de tarefas e o escopo do sistema, é isto, o que está sob responsabilidade do usuário e do sistema.

Esta opção, como dita pelo autor, é interessante sob o aspecto de que deixa bastante claro o que se espera que o sistema aça e o que se espera que o usuário aça.




10 DICAS PARA COLETAR REQUISITOS Por Diego Nei, MBA, PMP Os requisitos do projeto são uma parte de fundamental importância para a definição não só adochance escopo, também dossucesso objetivos requisitos nãodeisão claros, domas projeto não ter oudo terprojeto. apenas Quando sucesso os parcial (por que xou de atender a necessidade do cliente, por exemplo) é muito maior. Os requisitos são determinados pelas partes interessadas do projeto, todas elas ou as mais importantes e ativas. 1. Use questionários para coletar os requisitos. Gere perguntas sobre os aspectos do

projeto, de forma a conseguir das partes interessadas a maior quantidade de informações possíveis. As perguntas devem começar com aspectos gerais e abordar mais e mais detalhes ao decorrer do questionário. Esta forma de coleta é muito boa para partes interessadas que não têm muita disponibilidade para reuniões ou estão em ambientes virtuais. 2. Colete requisitos para o escopo do projeto. O escopo do projeto é o que o projeto

precisa/almeja realizar. Alguns exemplos: Projeto A – Otimização do setor financeiro, Projeto B –os Curso Elaboração ternas são alvosdenesta etapa. de Projetos. Seu patrocinador e partes interessadas in3. Colete requisitos para o escopo do produto. O escopo do produto é o que o projeto

vai entregar ao cliente ao final da sua duração. Exemplos: Projeto A – Processos Financeiros otimizados, Projeto B – Planos de Curso, Apostila de Elaboração de Projetos. Seu cliente e o usuário final são os alvos desta vez. 4. Elabore uma matriz de rastreabilidade de requisitos. Nesta tabela você deve asso-

ciar os requisitos às partes interessadas, recursos, atividades, entregas, pacotes de trabalho e quaisquer outras informações que você achar pertinentes, de forma a facilitar o acompanhamento e assegurar que os requisitos estão sendo observados, respeitados e cumpridos; 5. Leve em consideração que os requisitos mais importantes podem não vir dos stakeholders mais importantes. Em um exemplo bruto, o faxineiro do prédio pode sa-

ber uma coisa nenhum dos membros da diretoria Procure sempre ao menos de perguntar aosque stakeholders de menor impacto ou nãosabe. diretamente envolvidos sua percepção do projeto (mesmo que de uma forma que não revele que se trata de fato de uma coleta de requisitos). 6. Round 1… Fight! Se em algum momento, dois ou mais stakeholders decidirem que

é um bom momento para brigar sobre requisitos e isso atrapalhar as reuniões, não tenha medo de encerrar a reunião e utilizar a técnica Delphi para chegar a uma decisão

comum sem sacrificar as reuniões de planejamento. 7. Jogos de Poder. Existem situações onde a parte interessada A passa requisitos, mas

é a parte interessada B quem tem poder de decisão para aprovar se o requisito entra ou não no projeto. Defina bem cedo uma matriz de priorização de partes interessadas, de forma a identificar quem tem prioridade sobre quem, bem como elabore o mais cedo possível um plano de gerenciamento de requisitos onde deve constar o processo a ser adotado quando um requisito crítico é identificado por uma parte interessada de menor importância. Se valer de opiniões especializadas nessa hora é sempre uma boa idéia. 8. Escreveu não leu… Exercite a técnica da retroalimentação no processo de comuni-

cação para validar os requisitos. Inclua no seu plano de gerenciamento de comunicações o processo de que sempre que um pacote de trabalho estiver para ser iniciado ou concluído, o processo de comunicação deve revisar os requisitos com as partes interessadas envolvidas e com o cliente/usuário final. Desta forma, requisitos que não estão aderentes com o objetivo e o escopo podem ser identificados a tempo. 9. Informal. Muitos requisitos não podem ser coletados dentro do ambiente formal de

trabalho. Marque um almoço com algumas partes interessadas e converse sobre o projeto de maneira aberta e despretensiosa. Muito da visão daquela parte interessada vai surgir desta forma e você vai poder conferir se os requisitos estão batendo. 10. Pesquisa! Recorra aos famosos ativos de processos organizacionais! Dependendo

do nível de maturidade da empresa, lá você pode encontrar não só as lições aprendidas geradas para projetos anteriores como uma base de dados de requisitos… Ou um PMO que possa lhe informar onde encontrar essa informação… Ou um grupo de gerentes de projetos que podem lhe dar uma dica… Ou um punhado de técnicos que trabalharam em um projeto parecido… Ou nada. Mas procure lá!

Técnica Delphi: “Um grupo seleto de especialistas responde questionários e fornece comentários a respeito das respostas de cada rodada de coleta de requisitos.” (PMBoK 4ª Edição, p. 108). Esta técnica permite que as idéias sejam expostas sem a interferência dos outros participantes e que posteriormente, quando reunidos, as mesmas sejam avaliadas com mais imparcialidade uma vez que ninguém sabe o certo quem deu cada idéia em específico. Ativos de Processos Organizacionais: Os ativos de processo são todos os documentos, arquivos, processos e conhecimento disponível para uso da instituição. O PMBoK diz: “[...] incluem qualquerenvolvidas um ou todos os ativos relacionados processos, quaisquero ou todas as organizações no projeto e que podem serausados parade influenciar sucesso do projeto. Estes ativos incluem planos formais e informais, políticas, procedimentos e diretrizes, [...] bases de conhecimento das organizações, como lições aprendidas e informações históricas.” (PMBoK 4ª Edição, p. 32). Disponível em: . Acesso em: 26 jan. 2016.

Entenda sobre engenharia de requisitos. . Acesso em: 26 jan. 2016.

.

Entenda mas sobre análise de requisitos. . Acesso em: 26 jan. 2016.


CONSIDERAÇÕES FINAIS Nesta unidade, entendemos a importância da identificação dos requisitos de um sistema a ser desenvolvido, tivemos a oportunidade de avaliar melhor o que é, quem são as pessoas envolvidas neste processo, quando devemos estar atento a este item, onde este processo deve ser eito, técnicas que nos auxiliam a realizar o processo de coleta e detalhamento dos requisitos. Também tivemos a oportunidade de verificar os dierentes tipos de requisitos que existem, qual a sua importância para um bom processo de design e como eles intererem na qualidade do produto final. A identificação dos requisitos de um sistema não é uma tarea ácil, por isto passamos por várias técnicas que têm por objetivo auxiliá-lo neste processo. Vimos como podemos compor o trabalho de levantamento (unindo técnicas) para garantir maior aderência à necessidade do cliente. Além disso, estudamos algumas das ormas mais comuns de interpretação de maneira que a necessidade catalogada do cliente possa ser transormada em uma solução que venha agregar valor ao usuário final.

Na última unidade deste livro, vamos entender um pouco mais sobre os modelos de desenvolvimento de sistema e como eles podem influenciar no processo de design e interação, vamos passar pelos processos mais significativos do projeto de um novo sistema e vamos abordar quais cuidados devemos tomar nestas etapas.


1. Agora que você aprendeu sobre a importância do processo de coleta e detalhamento de requisitos, como você espera colocar isto em prática no seu trabalho para produzir um design mais adequado? 2. Na sua opinião, como que o processo de coleta de requisitos pode prejudicar o estabelecimento de um design novo? 3. Quais os passos que precisamos dar para uma boa coleta/identificação dos requisitos?


COLOCAN DO TUDO IS TO PARA RODAR

E D A D I N U

V

Objetivos de Aprendizagem ■ Entender a importância das abordagens de desenvolvimento de sistemas e como podem impactar no processo de design. ■ Aproveitar os benefícios da abordagem de desenvolvimento selecionada para o processo de design. ■ Assegurar maior qualidade ao processo de design ao trabalhar com conceitos de projetos. ■ Extrair os benefícios para o processo de design ao trabalhar com metodologias de projeto ágeis.


■ Entendendo sua abordagem junto aos modelos de produção de software ■ Entendendo o design como parte do escopo de um projeto ■ Entendendo seu benefício no uso conjunto com metodologias ágeis

INTRODUÇÃO Caro(a) aluno(a), fico satiseito de você ter chegado na unidade final deste livro, espero que tenha aproveitado bastante e que possamos entender como colo-


car isto tudo em prática. Como disse Franklin Delano Roosevelt: “existe muitos modos de ir para rente, mas apenas um de ficar parado”. Espero que sua escolha seja de seguir e com entusiasmo redobrado! Até aqui nós estudamos a importância, para o sucesso ou para o racasso, que um bom design de interação tem para um produto que está sendo desenvolvido. Vimos que design de interação é muito mais do que telas bonitas e teoricamente atraentes, vimos que é uma disciplina que envolve elementos de várias áreas, é realmente uma disciplina multidisciplinar. Vimos abordagens que podem ser usadas por empresas para reduzir o alto custo que uma estratégia como esta pode nos acarretar. Vimos também um componente muito importante que é a interação humano-computador, passamos pelos conceitos de interace e verificamos sua evolução. Estudamos os conceitos relacionados à interpretação humana e também passamos pelos elementos de memória humana e vimos como estes itens podem impactar no processo de desenvolvimento de uma nova solução. Na unidade anterior, vimos a importância da documentação da necessidade de nossos clientes, levando em conta todos os atores humanos descritos nas unidades anteriores, pontuamos algumas das técnicas mais importantes que podem auxiliá-lo nesta diícil tarea e, agora, chega o momento de começar o desenvolvimento deste novo produto. Precisamos entender um pouco mais sobre os modelos de desenvolvimento de sofware e como o processo de design e interação pode/deve se encaixar em cada um deles. Precisamos entender que design é um elemento importantíssimo do escopo a ser mapeado e, para isto, muitos riscos estão envolvidos, e nada melhor do que encarar isto como parte de um projeto de desenvolvimento de uma nova aplicação. Nos tempos atuais, uma das metodologias mais diundidas de gerenciamento de projetos é o Scrum, uma metodologia ágil que tem recursos enomenais que podem apoiar este processo de design oerecendo maior segurança a nossos

Introdução

V

clientes, dando maiores garantias de que ele, de ato, vai receber algo que se enquadre em suas necessidades.

ENTENDENDO SUA ABOR DAGEM JUNTO AOS MODELOS DE PRODUÇÃO DE SOFT WARE Não é objetivo deste livro lhe ensinar os vários modelos de produção de sistemas, para isso você tem a disciplina de engenharia de sofware, que lhe dará toda undamentação para isto, entretanto é importante esta correlação com esta área tão relevante devido às necessidades em comum. Segundo Pressman (2006), alguns dos principais modelos são: Modelos Prescritivos, Modelos em Cascata, Modelos Incrementais de Processo, Modelos Evolucionários de Processo de Sofware, Modelos Especializados em Processo e o Processo Unificado. Vamos entender um pouco mais sobre estes modelos e onde se encaixa o processo de design em cada um. ■ Modelos Prescritivos

Modelos prescritivos tem este nome, pois prescrevem um conjunto de ações e tareas que devem ser levados em consideração para o desenvolvimento de um sistema. Temos que entender que não significa que ele seja estático, eles podem ser adaptados à pessoa, ao problema e ao projeto. Podemos dizer que todos os demais modelos que veremos a seguir são prescritivos. Se você trabalha em uma empresa que tem umcheck-list que deve ser seguido para o desenvolvimento de uma solução, provavelmente você deve estar trabalhando em uma empresa que trabalha com este modelo no desenvolvimento de sistemas. Segundo Pressman (2006, p. 55) temos: O modelo prescritivo de software tem sido aplicado durante muitos anos em um esforço de trazer ordem e estrutura para o desenvolvimen-

COLOCANDO TUDO ISTO PARA RODAR



to de software... todos realizam o mesmo conjunto de atividades genéricas de arcabouço: comunicação, planejamento, modelagem, construção e implantação.

Quando uma empresa trabalha com modelos que se enquadram neste processo,


certamente o design estará sendo considerado no item comunicação, e só na ase de construção é que os trabalhos realmente começam. Cuidados no planejamento e modelagem precisam ser tomados para garantir que os requisitos uncionais e não uncionais tenham sido levantados levando em consideração os aspectos retratados neste livro. ■ Modelos em Cascata O modelo em cascata requer um bom entendimento dos requisitos e que estes fluam linearmente até a ase de implantação. A construção de sistema que ujam a características como esta devem nos levar a pensar na utilização de outro modelo. Segundo Pressman (2006, p. 55) temos: O modelo em cascata sugere uma progressão linear das atividades de arcabouço que é frequentemente inconsistente com as realidades modernas (por exemplo: modificações contínuas, sistemas evolutivos, prazos apertados) do mundo de software. No entanto, ele tem aplicabilidade em situações onde os requisitos são bem definidos e estáveis.

©shutterstock

Entendendo sua Abordagem Junto aos Modelos de PRodução de Software

V

O design deve estar inserido na ase de comunicação, ase esta na qual é eita a iniciação do projeto e estabelecidos os requisitos. Como supõe pouca alteração no que se espera que seja desenvolvido, pouca interação ocorre com o cliente, onde somente na ase de implantação este volta a ver aquilo que solicitou na primeira ase. Isto é um risco enorme, ato que pode colocar em risco todo desenvolvimento.



Fonte: Elaborado pelo autor.

■ Modelos Incrementais de Processo Quando alamos de desenvolvimento de sistemas, Pressman (2006, p.39) define bem como: “Há muitas situações em que os requisitos iniciais do sofware são razoavelmente bem definidos, mas o escopo global do esorço de desenvolvimento elimina um processo puramente linear”. Neste cenário, o modelo incremental é uma boa alternativa no desenvolvimento de soluções. Ele combina elementos do modelo em cascata trabalhando com iteração. O modelo incremental trabalha com a ideia de entregas parciais, com a ideia de que conorme uncionalidades estejam em condições de serem usadas, estas podem ser disponibilizadas ao usuário. Pense na criação de um sistema de vendas pela internet. Assim que o cadastro de clientes esteja finalizado, este poderia ser entregue para o cliente começar atualizar sua base cadastral. Uma comparação do modelo incremental com a prototipação, que é uma abordagem do modelo evolucionário que estudaremos a seguir, permite verificar que no modelo incremental soluções prontas para uso são liberadas ao cliente.



Segundo Pressman (2006, p. 55), “modelos incrementais do processo de sofware produzem o sofware como uma série de versões de incrementos”. O processo de design é muito mais participativo neste modelo de trabalho, perceba que como as entregas ocorrem mais rapidamente, o eedback do cliente é muito


mais rápido, exigindo avaliação se nosso modelo mental aplicado ao desenvolvimento da aplicação condiz com o que é o realmente posto em prática. Há um risco neste modelo que é o momento da validação do usuário do design criado, apesar de iterações serem constantes e o desenvolvimento ser relativamente mais curto, há um tempo entre o requisito finalizado e a primeira entrega eita que tem que ser cuidado. ■ Modelos Evolucionários de Processo de Sofware

Os modelos evolucionários permitem a produção de versões de sofware cada vez mais completas a cada interação. A prototipação é uma ótima erramenta dentro do modelo evolucionário, ela permite que quando o cliente tem uma necessidade razoável, mas não tem todos os detalhes, o desenvolvimento de um protótipo pode ser o primeiro passo a ser dado rumo ao desenvolvimento da solução completa. Aqui começa o trabalho do design, este processo praticamente coloca este profissional como o primeiro elemento junto com o analista de negócios na rente do cliente. Este processo de prototipação é uma das melhores estratégias que existem para garantir um bom design e interação. Entenda que o protótipo gerado pode ser um protótipo que “rode” ou não, não existe uma obrigatoriedade quanto a isto, e um critério interessante é que este protótipo pode ser utilizado como parte pela equipe de desenvolvimento, reduzindo assim seu trabalho. ©shutterstock


V

Outra técnica interessante que é preciso validar é o modelo espiral, ele é definido por Pressman (2006, p. 45) como: O modelo espiral é uma abordagem realista do desenvolvimento de sistemas e softwares de grande porte. Como o software evolui à medida que o processo avança, o desenvolvedor e o cliente entendem melhor e reagem aos riscos de cada nível evolucionário.

O modelo espiral permite uma melhor iteração entre as ases de desenvolvimento, acilitando assim a construção de soluções mais robustas e seguras. O Design é parte integrante de qualquer ase do ciclo do projeto e acilita e muito a obtenção do eedback do cliente. Segundo Pressman (2006, p. 55) temos: Modelos evolucionários de processo reconhecem a natureza iterativa da maioria dos projetos de engenharia de software e são projetadas para acomodar as modificações. Modelos evolucionários como o modelo espiral e de prototipagem, produzem produtos de trabalho incrementais (ou versões de software que funcionem) rapidamente. Esses modelos podem ser adotados serem– aplicados ao longo de todas atividades de engenharia depara software desde o desenvolvimento deasconceitos até a manutenção do sistema no longo prazo.

■ Modelos Especializados em Processo

Esta é uma estratégia de desenvolvimento que tem muitas características dos modelos estudados até aqui. Este modelo de desenvolvimento trabalha com conceito de criação de pequenos sistemas reutilizáveis, que podemos classificar de componentes. Estes componentes são acilmente ligados a outros sistemas, logo, perceba a necessidade de uma boa e clara adequação de design neste aspecto! Outra erramenta, além da baseada em componentes, é a utilização de métodos ormais para a definição das regras de utilização provadas matematicamente. Esta erramenta, apesar de dar uma ótima reerência sobre o que tem que ser eito sistemicamente e de ser uma maravilhosa onte de checagem, verificando se as uncionalidades estão conorme desejadas, deixam muito a desejar quando o ponto de avaliação é design. Então, bastante cuidado deve ser tomado em soluções que optem pelo modelo de desenvolvimento baseado em métodos ormais, pois um risco alto é corrido sobre design e interação.




Segundo Pressman (2006, p. 55), temos: Aqui, o modelo baseado em componentes enfatiza a reutilização e a montagem de componentes. O modelo de métodos formais encoraja uma abordagem com base na matemática para o desenvolvimento e a verificação do sistema. O modelo orientado a aspectos acomoda preocupações transversais que cobrem toda a arquitetura do sistema.

■ Processo Unificado Segundo Pressman (2006, p. 55), temos: . 8 9 9 1 e d o ir e r e v fe e d 9 1 e d 0 1 6 . 9 i e L e l a n e P o ig d ó C o d 4 8 1 . t r A . a d i b i o r p o ã ç u d o r p e R

O Processo Unificado é um processo de software “orientado por casos de uso, centrado na arquitetura, iterativo e incremental”. Projetado como um arcabouço para métodos e ferramentas UML. O processo unificado é um modelo incremental no qual cinco fases são definidas: (1) uma fase de concepção que engloba tanto a comunicação com o cliente quanto atividades de planejamento, enfatiza o desenvolvimento e refinamento dos casos de uso como modelo principal; (2) uma fase de elaboração que engloba atividades de comunicação com o cliente e modelagem com foco na criação de modelos e análise de projeto com ênfase definiçãoque de classes representações arquiteturais; (3) uma fase de na construção refina eeentão traduz o modelo de projeto para componentes de software implementados; (4) uma fase de transição que transfere o software do desenvolvedor para o usuário final para testes beta e de aceitação; (5) uma fase de produção em que contínuo monitoramento e suporte são conduzidos.

Com certeza é um processo bastante robusto mas que existe uma gama muito grande de arteatos e pode não ser aplicável a qualquer tipo de projeto. Como se trata de um processo iterativo e incremental o design se encaixa em cada etapa, mas o eedback do usuário é relativamente mais longo se comparado com outros métodos.


V

ENTENDENDO D ESIGN COMO PARTE DO ESCOPO DE UM PROJETO Prezado(a) aluno(a), vimos no decorrer deste livro a importância do design e estudamos várias técnicas ligadas à coleta de requisitos e sua transormação para que, como resultado, tenhamos um produto que seja aderente às necessidades do cliente. No tópico anterior, vimos os dierentes modelos de desenvolvimento de sofware, desde os mais clássicos aos mais modernos, e agora, neste penúltimo tópico do livro, quero alar a respeito da maneira como podemos “blindar” ainda mais nossas aplicações de orma que sejam bem-sucedidas. Dentro da própria engenharia de sofware, um item que é de undamental importância para

que um produto seja bem-sucedido é encará-lo como um projeto. Um projeto de sofware envolve o planejamento do que necessita ser eito, o monitoramento e controle das etapas que conduzem o projeto ao seu término, cuidados para que as entregas sejam bem-sucedidas (finalização do projeto ou etapa). ©shutterstock Não é objetivo deste livro detalhar todo processo de gerenciamento de um projeto, mas sim trazer alguns pontos undamentais que possam contribuir para que, uma vez detectada a necessidade do cliente, esta se transorme em algo realmente útil. Então, a primeira coisa que quero definir contigo é: O que realmente é um projeto?. Conorme o Guia PMBOK em sua 4ª edição, temos a seguinte definição de projeto: “Um projeto é um esorço temporário empreendido para criar um produto, serviço ou resultado exclusivo”. Perceba que a ideia por trás de um projeto está justamente em dar a você as condições necessárias para que um produto seja desenvolvido. Existem várias




metodologias de gerenciamento de projetos que, assim como as de desenvolvimento de sofware listadas acima, lhe oerecem um guia para que um sistema seja desenvolvido, estas oerecem um guia de boas práticas para que você possa fluir por todas as etapas de desenvolvimento cuidando de todos os atores que


estão envolvidos nesta diícil tarea de prover soluções. Vou apresentar agora alguns pontos que julgo relevantes conorme estabelecido pelo Project Management Institute(PMI) e agrupados em seu guia de conhecimentos sobre gerenciamento de projetos, o PMBOK, que está em sua 4ª edição. No próximo tópico, vou retratar alguns aspectos relevantes sobre uma metodologia ágil e como ela pode apoiar também em nosso processo de design. O desenvolvimento de sistemas é algo que não é só ir programando que uma hora sai o que o cliente quer! Nenhum dos modelos que estudamos acima se baseia no princípio da tentativa e erro, apesar do ciclo de iteração propiciar isto, nenhum modelo sugere um desenvolvimento sem nenhum tipo de ormalização. Para apoiar esta ormalização é que uma metodologia de gerenciamento de projetos se encaixa muito bem. Seguindo o que o PMI considera relevante a ser considerado no desenvolvimento de qualquer projeto (inclusive de sofware), temos os seguintes itens: ■ Integração Esta área cuida para que todas as outras oito áreas de conhecimento abaixo estejam sendo realizadas. Um dos maiores cuidados de um gerente de projeto é garantir a integração, ou seja, garantir que tudo esteja acontecendo conorme planejado.

©shutterstock

■ Escopo Aqui entra todo processo de coleta, definição e análise do escopo do que deve ser eito e do que não deve ser eito no projeto. Esta é a área de conhecimento que trabalha firmemente com os modelos de desenvolvimento de sofware que vimos no tópico anterior.

©shutterstock


V

■ Tempo Está aqui o conjunto de conhecimento para procurar prover ao projeto erramentas que podem ajudar na estimativa e controle

©shutterstock

dos projetos. ■ Custo R e p r o d u ç ã o

Temos aqui um conjunto de erramentas e técnicas que apoiam o controle dos custos do projeto. ■ Qualidade

©shutterstock

Como medir? Como assegurar a qualidade? O objetivo desta área de conhecimento é apoiar que a construção do projeto tenha como saída um sistema com os padrões de qualidade acordado entre as partes. ©shutterstock

■ Recursos Humanos


Envolve o bom gerenciamento de todos os recursos envolvidos na construção de um projeto. Quem são os mais adequados? Que capacitações eles precisam? Perceba que existe uma relação interessante com design e interação, pois poderia estar aqui todo processo de capacitação necessário à equipe de desenvolvimento para estarem aptos a aplicar os undamentos ensinados neste livro! ©shutterstock



Desenvolver sistemas não é só levantar o que o cliente quer e ir programando e validando?

■ Comunicação


É como cuidar e garantir uma comunicação assertiva entre todos os stakeholders (qualquer pessoa que de alguma orma é aetada direta ou indiretamente com o projeto) do projeto. ■ Riscos

©shutterstock

Identificar antecipadamente os riscos envolvidos no projeto, o cliente deseja que seu aplicativo rode em plataorma desktop, web e móvel? Isto pode ser um risco para o projeto

dependendo de nossa plataorma de desenvolvimento. Quais as possíveis respostas que posso dar a este risco? O processo de desenvolvimento tem muitos riscos envolvidos e muitos deles têm impacto direto no design de nossas aplicações. ©shutterstock

■ Aquisições Cuida para que todo processo de aquisição necessária ao projeto ocorra de orma ética e transparente, de orma que não gere comprometimento às outras atividades e áreas envolvidas. Dentre as nove áreas de conhecimento acima, julgo as ©shutterstock mais críticas: Escopo, Tempo, Custo e Qualidade e, por isso, vou lhe apresentar alguns detalhes complementares. Devemos pensar nesta área de escopo com muito carinho. Já vimos em outro tópico deste livro que uma das principais razões para o insucesso de projetos é um mau gerenciamento do escopo.


V

Vimos também em outros tópicos a importância da coleta eanálise dos requisitos do cliente. Uma boa avaliação dos requisitos uncionais e especialmente dos não uncionais traz subsídios para uma boa identificação de qual escopo deve ser contemplado na criação da solução. A razão do escopo bem definido e controlado é tão importante que impacta diretamente nos critérios de custo, tempo e qualidade. Acompanhei um projeto certa vez cujo escopo uncional oi totalmente concluído no prazo que oi estabelecido em contrato, entretanto os itens de escopo relacionados a requisitos não uncionais, dentre eles de usabilidade, não oram contemplados com a mesma eficiência. Critérios de ergonomia nãooram atendidos, e uma série de atores fizerem com que a aceitação do produto osse mínima. Tivemos que voltar para a ase de planejamento e realizar os ajustes necessários. Perceba que, para que isto tenha chegado a acontecer, houve duas grandes alhas: 1. Mapeamento do escopo e controle – especialmente dos ligados a requisitos não uncionais. 2. Falha de iteração entre as ases no modelo de desenvolvimento escolhido para aquele projeto. Uma certeza existe, alhas quando ocorrem nunca é por um único critério, mas tenha certeza de que um bom gerenciamento do escopo pode aumentar em muito suas chances de sucesso. Quando alamos de qualidade, estamos alando diretamente de satisação do cliente, estamos alando de critérios de usabilidade, satisação e vários outros que vimos desde a Unidade I deste livro. Não vou mencioná-los aqui novamente, mas você pensar neles e enquadrá-los em um gerenciamento da qualidade pode azer com que seu sistema atenda aos critérios estabelecidos por ambas as partes. Em resumo, quero que entenda que os princípios de gerenciamento de projetos associado a um modelo de desenvolvimento de sofware adequado, com atenção redobrada aos quesitos de design e interação abordados neste livro, podem trazer a você uma maneira de “blindar” o processo de criação de um novo sistema e potenciar aceitação dele rente ao mercado.




©shutterstock


ENTENDENDO SEU BENEFÍCIO NO USO CONJUNTO COM METODOLOGIAS ÁGEIS Caro(a) aluno(a), uma das metodologias ágeis mais utilizadas no momento é Scrum e a escolhi para ser tema deste tópico devido à sua grande aceitação, sua ótima implementação de características que os modelos iterativos, incrementais e evolucionários oerecem, assim como sua crescente utilização no mercado de desenvolvimento de sistemas. Hoje, já é uma das principais metodologias utilizadas pelas empresas para gerenciar seus projetos e, dentre as metodologias ágeis, é a mais utilizada (conorme pesquisa - PMSurvey de 2012).

Fonte: PMSurvey 2012

O Scrum trabalha ortemente com os conceitos de entrega parcial, desenvolvimento iterativo e agilidade no desenvolvimento que trazem uma percepção de valor agregado pelo cliente muito orte. Quem já passou pelo processo de construir sua casa própria sabe como é um processo demorado (geralmente entre 5 a 9 meses) e também bem estressante. O processo de construção de casa é um processo que é completamente eito em

Entendendo seu Benefício no Uso Conjunto com Metodologias Ágeis

V

cascata (se ormos azer uma analogia aos modelos de desenvolvimento). Você paga, vê a obra acontecendo, mas só no final é que poderá receber as chaves e eetivamente desrutar do novo lar. Você não consegue azer uso de sua casa até que tudo acabe. Voltando a analogia com o modelo cascata, você não consegue usar o sistema até que ele seja entregue. Pense que o sistema pode levar os mesmos de 5 a 9 meses como o caso da casa, pense na ansiedade que é passada pela parte do contratante. Na construção da casa você pode ir e ver as etapas sendo entregue (aterro, undação, acabamento ...), quando alamos de sistema nem sempre isto é possível de se azer. Você pode chegar com um calhamaço de papel após três meses de trabalho para o contratante e dizer: “tome, esta é a undação de seu sistema, os requisitos estão prontos”, dessa orma, dificilmente ele vai ficar eliz... pois não é algo palpável. O que ele quer ver mesmo é uma “telinha”, algo que ele possa “mexer” e ver se está conorme ele “imaginava”. Voltando para o caso da construção, imagine que você pudesse entregar a churrasqueira de orma que o dono da casa já possa receber seus parentes para uma conraternização antes do término da casa? Ele terána parte rontal toda uma estrutura inacabada, mas, com pouco tempo de construção, valor oi agregado. É este o propósito que o Scrum tem para oerecer, ao menos é sua promessa, que, com pouco tempo de projeto, algo palpável possa ser finalizado e entregue para uso, assim como os modelos incrementais o azem.

Fonte: .




A imagem acima representa o clico de desenvolvimento com o Scrum, assim como os seus principais elementos. Vamos na sequência entender mais de cada um deles. 1. Product Backlog

Aqui temos o que é conhecido que deve ser eito. Todo esorço necessário para que o projeto seja desenvolvido está definido no Product Backlog.


Para que estes itens estejam classificados, há necessidade direta de envolvimento no levantamento dos requisitos necessários para o sistema e aqui começa o desafio do Design para prover uma solução que em curto espaço de tempo já esteja em uso. O máximo de inormações sobre requisitos uncionais e não uncionais deve ser levantado de orma bastante dinâmica. O nível de ormalização é definido pela equipe e cliente. É comum que requisitos sejam definidos em quadros, desenhos em papel etc., interações que permitam o bom entendimento do que é necessário azer e que não gastem muito tempo. Fotos de quadros com o desenho (protótipo) do que se espera ser eito é comum (ainda mais se o cliente estiver na oto dando um “OK” de aprovação!). 2. Sprint Backlog

Uma vez que o que necessita ser eito está definido, o próximo passo é quebrar em Sprints. Sprints são períodos curtos de tempo, suficientemente grandes para que algo de valor seja entregue, mas no contexto geral bastante curto. Em média, tenho visto a ragmentação dos sprints em uma ou duas semanas, tempo mais que suficiente para que algo seja desenvolvido e entregue ao cliente para uso.

O Sprint Backlog serve para ornecer ao cliente uma noção de tempo, uma espécie de cronograma de quando aquilo que é conhecido e priorizado pelo cliente será entregue. 3. Sprint

Os Sprints são as ações de trabalho em si. É nela que a equipe de desenvolvimento estará ocada, direcionando seus esorços para que, como

Entendendo seu Benefício no Uso Conjunto com Metodologias Ágeis

V

resultado de seu trabalho, uma uncionalidade seja liberada. É aqui que está um bom envolvimento do Design. Para entender melhor como isto é possível, vamos analisar como é o ciclo de trabalho dentro da Sprint. A primeira macro atividade a ser realizada dentro da Sprint é o que se chama de Sprint Planning um. Nesta reunião, toda equipe está reunida com intenção de ter todo entendimento do que deve ser desenvolvido. Nesta reunião, a presença do cliente é importante (ou de um seu representante), e CRITÉRIOS para umbom design devem/podem ser observados. O próximo passo é a equipe se reunir no que é chamado Sprint Planning dois, em que o atendimento das necessidades do cliente será tratado! Perceba que outra vez uma boa interação do design é importante, ainda mais que requisitos não uncionais são oco desta reunião. As demais interações que a equipe terá durante o desenvolvimento da Sprint não são relevantes para nosso estudo, exceto a entrega da uncionalidade para

o cliente. Esta entrega ocorre no que é chamado de Review, ou seja, o cliente irá verificar (receber) aquilo que pediu que osse eito. Perceba que neste exato momento critérios de usabilidade, validações quanto aos modelos mentais podem ser eitas pela simples observação de uso da erramenta por parte da equipe. 4. Work increment o the sofware

Como resultado final de nosso desenvolvimento, teremos a liberação para uso em escala por parte dos demais usuários, haja vista que este oi validado e aprovado. Perceba que este é um clico de interação rápido e que propicia ácil eedback por parte do cliente, sendo assim, um bom acompanhamento por parte do responsável pelo design e interação em todo este ciclo é undamental. Baseado nisto, classifico que o Scrum é uma ótima erramenta que, se bem usada por parte da equipe, pode auxiliar e muito no processo de soluções que tenham uma boa interação por meio da construção de um bom design.




MODELO DE DESENVOLVIMENTO DE SOFTWARE Por Bruno Stain Hoje em dia nos deparamos com várias metodologias para o desenvolvimento de um projeto, mas temos os modelos de desenvolvimento, que falando em um modo de herança seriam os pais das metodologias. Os modelos de desenvolvimento são divididos em três partes principais, o desenvolvimento em Cascata, Iterativo e Incremental. O desenvolvimento em cascata é o mais tradicional dos três, por parecer ser mais simples e organizado, porém durante o desenvolvimento do projeto podem ocorrer inúmeras falhas decorrentes desse modelo Cascata, por isso veio os métodos Iterativo e Incremental, com a ideia de substituir o modelo Cascata e acabar com as suas falhas, mas como nada é perfeito eles também têm as suas falhas, mas vamos conhecer um pouco de cada e entender qual pode ser a melhor opção na hora de desenvolver um software.

MODELO EM CASC ATA O modelo cascata tornou-se muito conhecido na década de 70 e é comentado na maioria dos livros de engenharia de software. Nesse modelo as atividades do processo de desenvolvimento são estruturadas em uma cascata onde a saída de uma etapa é a entrada para a próxima etapa. As suas principais atividades são:

■ Estudo de Viabilidade ■ Análise e Especificação de Requisitos ■ Design da Arquitetura ■ Design Detalhado ■ Codificação e Testes de Unidades ■ Integração e Testes do Sistema ■ Entrega e Instalação ■ Manutenção Existem variações desse modelo apresentando, porém, a principal característica comum é um fluxo linear e sequencial de atividades semelhantes a descritas anteriormente. O modelo Cascata é criticado por ser linear, rígido e monolítico. Inspirados em modelos de outras atividades de engenharia, este modelo argumenta que cada atividade apenas deve ser iniciada quando a outra estiver terminada e verificada. Ele é considerado monolítico por não introduzir a participação de clientes e usuário durante as atividades do

desenvolvimento, mas apenas o software ter sido implementado e entregue. Não existe como o cliente verificar antecipadamente qual o produto final para detectar eventuais problemas.

Vantagens: ■ Torna o processo de desenvolvimento estruturado; ■ Tem uma ordem sequencial de fases; ■ Cada fase cai em cascata na próxima e cada fase deve estar terminada antes do início da seguinte; ■ Todas as atividades identificadas nas fases do modelo são fundamentais e estão na ordem certa; ■ Esta abordagem é atualmente a norma e provavelmente permanecerá por um tempo, mas temos o desenvolvimento ágil chegando com muita força na maioria das empresas de grande porte; Desvantagens: ■ Não fornece feedback entre as fases e não permite a atualização ou redefinição das fases anteriores; ■ ■

Não suporta modificações nos requisitos; Não prevê a manutenção;

■

Não permite a reutilização;

■

É excessivamente sincronizado;

■

Se ocorrer um atraso todo o processo é afetado;

■

Demora muito para ser entregue o software;

MODELO ITERATIVO E INCREMENTAL Desenvolvimento Incremental é uma estratégia de planejamento estagiado em que várias partes do sistema são desenvolvidas em paralelo, e integradas quando completas. Não implica, requer ou pressupõe desenvolvimento iterativo ou em cascata – ambos são estratégias de retrabalho. A alternativa ao desenvolvimento incremental é desenvolver todo o sistema com uma integração única. Desenvolvimento Iterativo é uma estratégia de planejamento de retrabalho em que o tempo de revisão e melhorias de partes do sistema é pré-definido. Isto não pressupõe desenvolvimento incremental, mas funciona muito bem com ele. Uma diferença típica é que a saída de um incremento não é necessariamente assunto de um refinamento futuro, e seu teste ou retorno do usuário não é utilizado como entrada para planos de revisão ou especificações para incrementos sucessivos. Ao contrário, a saída de uma ite-

ração é examinada para modificação, e especialmente para revisão dos objetivos das iterações sucessivas. A idéia básica por trás da abordagem iterativa é desenvolver um sistema de software incremental, permitindo ao desenvolvedor tirar vantagem daquilo que foi aprendido durante a fase inicial de desenvolvimento de uma versão do sistema. O aprendizado ocorre simultaneamente tanto para o desenvolvedor, quanto para o usuário do sistema.

VANTAGENS DO MODELO IT ERATIVO ■ Baseia-se fortemente na participação e uma boa comunicação entre desenvolvedores e usuários. ■ Há um grande envolvimento do utilizador e do cliente cliente. Isto leva a mal-entendimentos por causa das divergências entre os desenvolvedores e usuários que rapidamente podem ser superados. Porque há resultados mais rápidos e “tangíveis”, os usuários também serão capazes de dar um melhor feedback; ■ Os resultados mostrados permitirá que os usuários tenham confiança em um bom resultado; ■ A cada ciclo do sistema os usuários e cliente poderão utilizar o sistema diretamente, eles são os “testadores” no processo de desenvolvimento e eles estarão iteragindo com o sistema durante o desenvolvimento; ■ Os riscos podem ser melhor administrados por pequenos pedaços do sistema a serem desenvolvidos em pequenos espaços de tempo;

■ Os sistemas complexos são mais claros e menos complexos para implementá-los aos poucos, sem a necessidade de começar a implementação do zero; ■ Ao fim de cada iteração pode-se ter um feedback para ter noção de como está o projeto, mesmo se não estiver de acordo ainda há tempo para mudanças, com o modelo Cascata isso não é possível; ■ Alterações nos requisitos podem ser rapidamente incorporadas no processo de desenvolvimento.

DESVANTAGENS DO MODELO ITE RATIVO Durante o processo de desenvolvimento necessita-se adaptar e refinar o sistema, com isso pode ser que no final saia totalmente diferente da ideia srcinal; Pode acontecer na continuação do trabalho o surgimento de muitos requisitos novos, esse sistema nunca irá terminar. Isso é chamado de aumento de escopo; Gerentes que estão acostumados com a forma linear do desenvolvimento de um software pode ter alguns problemas na hora de ir para uma forma mais flexível;

Inexperiência com a forma de trabalhar do modelo Iterativo pode levar a problemas posteriores, por isso é necessário certo conhecimento para começar a usar esse modelo;

Vantagens do Modelo Incremental ■

As versões são fornecidas após cada iteração do modelo incremental;

■ O Modelo Incremental inclui o uso do software pelo usuário para que as mudanças sejam feitas de acordo com o mesmo; ■ Esse modelo não afeta o lado financeiro, porque ele prove o “core” do software que o cliente precisa, o que vai ajudar o cliente a manter o negócio da mesma forma, sem alterações no lado financeiro; ■ É flexível e fácil de gerenciar processo mais administráveis e fazer um software melhor com uma melhor estrutura; ■ Melhor gerenciamento de riscos, porque você pode confirmar o resultado com o cliente depois de cada versão do sistem e sempre verificar se estão fazendo o que está de acordo com o plano ou não, e corrigi-los na próxima versão do software; ■

Os testes são simples;

Desvantagens do Modelo Incremental ■ Cada fase de uma iteração é rígida e não se sobrepõem uns aos outros; ■ Podem surgir problemas relativos à arquitetura do sistema, porque nem todos os requisitos estão reunidos na frente de todo o ciclo de vida do software. ■

O modelo Incremental precisa ser relativamente pequeno.

Há uma década, vem se tentando encontrar um processo ou metodologia previsível e repetível que melhore a produtividade e qualidade. Alguns tentaram sintetizar e formalizar a tarefa aparentemente incontrolável de escrever um software. Outros aplicaram técnicas de gerenciamento de projeto na escrita de software. Sem o gerenciamento de projeto, projetos de software podem facilmente sofrer atraso ou estourar o orçamento. Como um grande número de projetos de software não atendem suas expectativas em termos de funcionalidades, custo, ou cronograma de entrega, ainda não existe um modelo de processo perfeito para todas aplicações. Disponível em: . Acesso em: 26/01/2012.

PRINCÍPIOS POR TRÁS DO MANIFESTO ÁGIL Nós seguimos estes princípios: Nossa maior prioridade é satisfazer o cliente através da entrega contínua e adiantada de software com valor agregado. Mudanças nos requisitos são bem-vindas, mesmo tardiamente no desenvolvimento. Processos ágeis tiram vantagem das mudanças visando vantagem competitiva para o cliente. Entregar frequentemente software funcionando, de poucas semanas a poucos meses, com preferência à menor escala de tempo. Pessoas de negócio e desenvolvedores devem trabalhar diariamente em conjunto por todo o projeto. Construa projetos em torno de indivíduos motivados. Dê a eles o ambiente e o suporte necessário e confie neles para fazer o trabalho. O método mais eficiente e eficaz de transmitir informações para e entre uma equipe de desenvolvimento é através de conversa face a face. Software funcionando é a medida primária de progresso. Os processos ágeis promovem desenvolvimento sustentável. Os patrocinadores, desenvolvedores e usuários devem ser capazes de manter um ritmo constante indefinidamente. Contínua atenção à excelência técnica e bom design aumenta a agilidade. Simplicidade, a arte de maximizar a quantidade de trabalho não realizado, é essencial. As melhores arquiteturas, requisitos e designs emergem de equipes auto-organizáveis. Em intervalos regulares, a equipe reflete sobre como se tornar mais eficaz e então refina e ajusta seu comportamento de acordo. Disponível em: . Acesso em: 26/01/2016.

V

Os aspectos retratados nas primeiras unidades deste livro podem ser tratados neste momento! Como podemos aplicar o Modelo GOMS nesta reunião com o cliente para garantir uma melhor usabilidade de nosso sistema?

Construindo resultados com gerenciamento de projetos – Ricardo Vargas. . Acesso em 26/01/2016

Metodologias ágeis . Acesso em 26/01/2016

CONSIDERAÇÕES FINAIS Caro(a) aluno(a), chegamos ao final da última unidade, aqui estudamos como as metodologias de desenvolvimento de sistemas, sejam elas mais tradicionais, sejam elas mais contemporâneas (ágeis), podem influenciar o processo de design e interação. Vimos em cada uma delas os principais pontos de atenção que necessitamos ter para um bom design, também vimos a importância da interação entre as metodologias de desenvolvimento com metodologias de gerenciamento de projetos. Quando alamos de metodologia de gerenciamento de projetos, avaliamos os principais processos envolvidos onde, os principais estão ligados ao escopo, tempo, custo e qualidade. Estudamos também sobre metodologias de gerenciamento de projetos ágeis, onde abordamos o Scrum como reerência, vimos seu ciclo de vida e os principais pontos onde o processo design e interação pode ser inserido com maiores possibilidades de aproveitamento dos beneícios desta metodologia. Espero que o conteúdo trabalhado nesta unidade, assim como os demais tratados no decorrer deste livro, possa auxiliá-lo na diícil tarea de produzir sistemas com a melhor usabilidade que seus usuários possam precisar.




1. Quais as diferenças entre o modelo de desenvolvimento em cascata e o incremental? Em qual deles o processo de design pode se mais prejudicado? 2. Como as metodologias de gerenciamento de projetos ágeis podem apoiar no processo de interação da equipe de desenvol-

vimento com o cliente e obter um melhor design?

3. Quais modelos de desenvolvimento de sistema estão presentes no Scrum?

CONCLUSÃO

Neste livro procurei levar a você conhecimentos acerca do processo de design e interação que julgo relevantes para seu processo de aprendizado. Para compreendermos melhor este processo, começamos na Unidade I entendendo sobre a importância de um bom design de interação, vimos como podemos classificar um bom e um mau design. Tivemos a oportunidade de estudar alguns maus exemplos e espero que você tenha tirado dicas importantes sobre como não cair nestes erros. Na sequência, entendemos na Unidade II os princípios de interação humano-computador, entendemos sua estreita relação com o projeto de interfaces e pudemos avaliar o processo de evolução do sistema de interface desde os primórdios até os dias atuais. Estudamos também sobre os critérios de usabilidade e como este quesito pode influenciar em uma boa interação com aplicações que desenvolvemos. Na Unidade III estudamos sobre alguns dos fatores humanos envolvidos neste processo de interação, vimos como o ser humano interage com objetos e quais os pontos cruciais desta relação, avaliamos como mensurar uma boa interação e partimos para o processo de coleta de requisitos. Já na unidade IV, estudamos a importância de um bom mapeamento dos requisitos de sistema, entre eles os não funcionais (que impactam completamente no trabalho de um bom design), estudamos ferramentas e como tirar melhor proveito para um bom mapeamento. Para finalizar, na unidade V, vimos como colocar a mão na massa, como podemos transformar estes requisitos em produtos, produtos estes que estarão aderentes às necessidades dos usuários e que devem seguir um modelo de desenvolvimento que otimize o trabalho de design, para isto estudamos alguns dos principais modelos de desenvolvimento e seu relacionamento com gerenciamento de projeto, de forma que este trabalho seja melhor controlado. Vimos como último item da nossa unidade como as metodologias ágeis, em seu ciclo de vida, podem apoiar sua empresa na construção de um design que seja realmente usual, simples e que agregue valor ao usuário final. Prezado(a) aluno(a), vimos que um bom design é processo fundamental para que um produto possa ser aceito, independente da finalidade deste produto, seja ele um sistema para aplicações web, desktop ou móbile. É claro que, dependendo da plataforma, cuidados adicionais devem ser tomados para que seu público-alvo possa ter boas experiências ao usar seu produto. Entenda que a forma como você constrói seu produto, a forma que você permite que seus usuários interajam com ele, tudo isto está intimamente relacionado a experiências que você irá proporcionar ao seu usuário ao fazer uso de seu produto. É importante falarmos que estas experiências irão gerar uma enormidade de sentimentos em seus usuários e, o mais importante, está em suas mãos controlar que tipo de sentimento você deseja despertar neles.

CONCLUSÃO

Caso seu produto seja muito complicado, ele pode dificultar o aprendizado e, essa experiência pode acabar por gerar um bloqueio, consequentemente uma rejeição e até uma não aceitação do produto. Em contrapartida, caso seu produto gere uma experiência positiva, sentimentos de aceitação serão gerados no usuário e, com toda certeza, você terá ganho um parceiro. Enfim, entenda que está em suas mãos desenvolver produtos focados no usuário que sejam úteis, simples e que agreguem valor, entenda que produtos com ótima usabilidade estarão sempre na frente de outros e isto pode ser fator preponderante para seu sucesso. Finalizando, espero que tenhamos chegado à mesma conclusão, que design não é questão de gosto, é na verdade uma necessidade que impacta diretamente no sucesso de um produto.

REFERÊNCIAS

KRUG, Steve. Não Me Faça Pensar. 2. ed. Rio de Janeiro: Alta Books, 2006. NIELSEN, J. Usability Engineering. Cambridge, MA: Academic Press, 1993. NIELSEN, J. Design Web Usability. Indianapolis, Indiana, USA: New Riders Publish, 1999. NIELSEN, J.; ROGERS, Y.; SHARP, H. Design de Interação: Além da Interação Homem-Computador. Porto Alegre, RS: Artmed, 2005. NORMAN, D. A. The Psychology of Everyday Things. New York: Basic Books, 1988. NORMAN, Donald. O Design do Dia-a-Dia. 1. ed. Rio de Janeiro: Rocco, 2006. PREECE, Jennifer. Design de Interação, Além da interação homem-computador . Porto Alegre: Bookman, 2005. PRESSMAN, R. S. Engenharia de Software. São Paulo: Makron Books, 2011. ROCHA, Eloisa Vieira da; BARANAUSKAS, Maria Cecília Calani. Design e Avaliação de Interface Humano-Computador. Campinas, SP: NIED/UNICAMP, 2003. WILLIAMS, Robin. Design para quem não é Designer. São Paulo: Ed. Calis, 2006.

Designer-de-Interacao.pdf

Recommend Documents