Modulo ii arquiteturainformacaousabilidade_thaiscampas

Thais Campas – A.I. Sr./ UX expert

UPA member 8922 – since 2004 – [email protected] – 5511 9498-9803 *todos os direitos reservados

Arquitetura da Informação e Usabilidade

Módulo II

"O arquiteto de informação é o indivíduo capaz de organizar padrões

inerentes aos dados, tornado clara sua complexidade, e capaz de criar estruturas ou planejamento de informações que permitam aos outros

encontrarem seus caminhos pessoais para o conhecimento."

Richard Wurman

Thais Campas Arquiteta de Informação e Designer de Interação Sênior Consultora em Usabilidade e Projetos Centrados no Usuário



Módulo II II – Usabilidade e Arquitetura da informação O que é Arquitetura da Informação (A.I.) e tudo o que ela pode fazer por você (e por seu projeto, é claro). O que é A.I.? Planejamento, criação, desenvolvimento... Como atua, até onde atua e qual é exatamente a função de Arquiteto de Informação no projeto Web? Vamos começar a responder esta pergunta, invertendo a questão, ou seja, o que um arquiteto de informação não é e não faz. Um arquiteto de informação ou profissional de A.I. (como é jargão no mercado) não é:

Operador de Power Point;

Estagiário de Design ou Redação;

Bibliotecário;

Editor ou redator-chefe;

Jornalista ou publicitário;

Webwriter;

Programador;

Webdesigner;

Diretor de Arte;

Designer Industrial;

Gerente de Projeto;

Etc.... Se você é um desses profissionais, não se assuste, não desista do curso e nem amaldiçoe o professor. Simplesmente leia a explicação até o final. O arquiteto de informação é um profissional que atua durante todo o ciclo de vida do seu projeto Web. Ele ou ela, e seu trabalho obviamente, são o elo perdido que faltava entre planejamento, criação (redação e design de interface), desenvolvimento e manutenção de um site ou Web Application. A documentação gerada pela A.I. é pertinente e bem fundamentada em todos os requisitos do projeto, a saber: estratégia de negócios, sistemas e infra-estrutura e, sobretudo, na experiência do usuário. A.I. dialoga com todos os componentes e profissionais da equipe envolvida no projeto. A.I. surgiu da necessidade de se produzir uma documentação multidisciplinar e universal que possa ser entendida por todos os “profissionais Web”, por assim dizer. Portanto, não interessa propriamente a sua formação acadêmica ou profissional (se é jornalista, designer, analista de sistemas ou programador). O Arquiteto de Informação é um profissional com conhecimento multidisciplinar necessário a um projeto executado em ambiente tecnológico. Portanto, para sites e aplicações em ambiente Web: O Arquiteto de informação é um estrategista, um profissional de planejamento, um projetista de interfaces (não um designer), um profissional de criação e um profissional de desenvolvimento, com conhecimentos de programação de interface (linguagens de programação entre interface gráfica e linguagens avançadas para acesso a banco de dados via Internet, por exemplo) e às vezes conhecimento em linguagens mais avançadas, mais raro. Você pode imaginar que nós estamos exagerando. Mas em países como os EUA, onde Arquitetos de Informação são profissionais tão imprescindíveis a um projeto quanto redatores e designers, por exemplo, as universidades têm se dedicado a elaborar currículos de graduação e pós-graduação em Arquitetura da Informação, com o intuito de atender a uma demanda crescente de qualificação gerada pelo mercado de TI e Internet.



A dificuldade e a grande polêmica giram em torno justamente da multidisciplinaridade tanto das matérias acadêmicas envolvidas quanto do conhecimento legado e das habilidades que o candidato a um curso desses deve apresentar. Não há nem mesmo um consenso sobre a questão de A.I. ser um currículo de graduação ou pós-graduação. A Universidade de Austin, no Texas, por exemplo, elaborou um programa de graduação em A.I. Traduzindo para a realidade brasileira, seria algo como um Bacharelado de quatro ou cinco anos em Arquitetura da Informação. A grade de disciplinas vai desde psicologia cognitiva até lógica de programação em computadores, passando por técnicas de taxonomia e gestão do conhecimento. Amplo, não? Pois é, este currículo está em discussão junto à comunidade acadêmica. Quem se habilita? Para começar, os candidatos teriam que comprovar um perfil fora do escopo tradicional... E possuir fluência em várias áreas do conhecimento formal. Imagine um filósofo/sociólogo/psicólogo programando computadores... É por aí. Mas enfim: você que deseja enveredar pelos universos e escopos da A.I. pode ser um:

Operador de Power Point;

Estagiário de Design ou Redação;

Bibliotecário;

Editor ou redator-chefe;

Jornalista ou publicitário;

Webwriter;

Programador;

Webdesigner;

Diretor de Arte;

Designer Industrial;

Gerente de Projeto;

Etc...

Só tem um porém. Você terá que dominar uma série de técnicas e tecnologias que nós já citamos por alto anteriormente e, principalmente, terá que transitar com desenvoltura entre a equipe presente durante todo o ciclo de vida do seu projeto Web. E se você acha que acabou... Não pára por aí, não. Agora é que vamos falar do diferencial da profissão: o Arquiteto de Informação tem uma função muito estratégica: introduzir no projeto as variáveis geradas pela experiência do usuário. Ou seja, garantir que o projeto atenda suas metas de usabilidade. Afinal, como dissemos no Módulo I, a experiência do usuário reflete um novo ponto de vista sobre a interface produzida. Esse ponto de vista cria uma perspectiva diferente da perspectiva do gestor e do desenvolvedor. O usuário primário é, nesse caso, um avaliador “isento” e de certa forma muito mais objetivo da interface. Ora, ele vai usá -la e atestar sua eficiência, sua eficácia, sua capacidade de satisfazê-lo, sua flexibilidade e sua segurança. O usuário está fora da problemática de produção e desenvolvimento, contexto do negócio e tudo o mais. Percebem? E quem harmoniza essas variáveis do usuário com a documentação e se assegura de que isso foi devidamente assimilado no projeto e compreendido pela equipe é, voilá, o nosso amado profissional de Arquitetura da Informação. Entendido? Falar em Arquitetura da Informação sem falar em Usabilidade é como não associar macaco com banana. Impossível. Bom, explicada a função estratégica de A.I. no projeto Web, vamos mostrar como operam as principais metodologias de A.I. Vocês agora vão aferir e comprovar o que vimos no Módulo I sobre a definição de usabilidade: Usabilidade é, ao mesmo tempo, um conceito, um conjunto de práticas e também um conjunto de preceitos a ser seguido por designers de interfaces. Antes, uma observação sobre as nomenclaturas aqui apresentadas: utilizaremos termos que a comunidade desenvolvedora brasileira, digamos, consagrou. Essas nomenclaturas - que se referem às metodologias que vamos detalhar – podem sofrer variações de empresa para empresa ou de região para região. Como ainda não há uma formalização de A.I. como uma área de conhecimento científico específica, as designações mudam e não raro se adequam ao repertório de jargões de diretores de arte e profissionais de criação das agências on-line. Portanto, o que deve ficar claro para vocês é o escopo da metodologia, não a sua nomenclatura. Ou seja: procurem entender o que é, quando usar e o porquê de sua aplicação nas diversas fases do projeto.



2-1 - Matriz de Escopo ou Mapa Estrutural É aqui que tudo começa: quais as Key Features do meu projeto? Pessoal, eu vou utilizar aqui a designação de Matriz de Escopo por achá-la mais adequada, pois o que nós temos aqui não é bem um mapa, mas uma espécie de check list pormenorizado do projeto. A Matriz de Escopo detalha todas as minhas Key Features, que vêm a ser as funcionalidades principais do site ou aplicação que estou planejando. Por isso ela é tão importante. O projeto começa aqui e normalmente é o primeiro documento apresentado ao cliente para discussão e aprovação. Rigorosamente, eu devo detalhar todas as funcionalidades da minha aplicação, MAS, o que se propõe aqui é que através do detalhamento organizado na Matriz de Escopo, eu possa definir a hierarquia de importância na ordem de execução do projeto. Determino assim as funcionalidades estratégicas do meu projeto, o núcleo, o foco do desenvolvimento: o que eu devo fazer antes e o que faço depois. Assim como o que é imprescindível em cada fase do projeto. Em termos de documentação, não tem segredo: a Matriz de Escopo é uma grande planilha. Nela eu insiro e atualizo as variáveis e parâmetros para cada funcionalidade do meu site ou aplicação. Realmente, se eu quisesse eleger um Bombril da Arquitetura da Informação (mil e uma utilidades) seria a Matriz de Escopo. Então é muito simples (função da matriz de escopo):

Analisando a matriz de escopo eu documento as minhas Key Features, funcionalidades essenciais e estratégicas sem as quais o projeto perde o seu foco.

Bom, que variáveis ou parâmetros eu documento na Matriz de Escopo? Aquelas que atendem às questões mais comuns a todos os projetos e outras específicas que suprem condições do meu projeto. Muitos Arquitetos utilizam uma planilha padrão, contendo a definição da funcionalidade, quem será especificamente envolvido no desenvolvimento daquela funcionalidade, bem como horas de trabalho envolvidas de cada membro da equipe no desenvolvimento daquela funcionalidade, quais os recursos necessários (acesso a Banco de Dados, animação em flash, criptografia e etc) e estágio de implantação. Não raro, a Matriz de Escopo é um forte aliado do Arquiteto na prestação de contas à Gerência de Projetos e Gerência de Atendimento. Mas atenção, quando ela assume esse papel tão semelhante a uma planilha de controle, sofre uma atualização constante e é preciso tomar cuidado para que não degenere e se torne um mero cronograma. Aliás, é uma documentação muito apreciada pelos Gerentes de Projeto e até incorporada à rotina deles para controle de cronogr ama. Por isso, aqui vai uma dica: você pode transformá-la num registro histórico de ocorrências do projeto. Você pode marcar as alterações solicitadas no escopo do projeto, marcando datas em que foram definidas, bem como descrição da mudança. Enfim, tenha em mente que a Matriz de Escopo é o check list do Arquiteto de Informação. Matriz de Escopo e Card Sorting – Quem surgiu primeiro – o ovo ou a galinha? Bom, aqui voltamos à discussão do Módulo I: Card Sorting aberto ou fechado? Carda Sorting antes ou depois da Matriz de Escopo? Pessoal, o dia-a-dia dos projetos de Internet depende muito da natureza e particularidade dos objetivos de cada um deles. Não existe uma fórmula pronta. Faça antes ou faça depois. Você pode realizar um Card Sorting como pontapé inicial de um planejamento, antes da Matriz de Escopo.



Vamos supor que eu esteja desenvolvendo uma ferramenta em ambiente Web, cujo cruzamento de informações gera uma tomada de decisão, ou seja, o resultado do cruzamento de dados leva a um resultado que fará com que o usuário tome uma decisão. Suponha também q ue estamos partindo do zero, não sabemos sequer como organizar o conteúdo disponível para popular esses dados que serão cruzados. Nesse caso o Card Sorting, aberto, vem antes da Matriz de Escopo. No Card Sorting aberto, são os usuários quem determinam as categorias principais e até a taxonomia do meu projeto (nomenclatura de links). Nesse caso, do Card Sorting Aberto pode nascer uma Matriz de Escopo para o meu planejamento.

Eu posso também propor e definir uma ordem inicial para o conteúdo, com categorias principais e, taxonomia, e pedindo aos usuários que organizem tudo tendo como base a pertinência da informação com cada uma das categorias e sua nomenclatura. Daí, temos o Card Sorting Fechado determinando a Matriz de Escopo. Num terceiro exemplo, temos o Card Sorting validando uma Matriz de Escopo. Lembrem-se de que eu posso categorizar e atribuir nomes na Matriz de Escopo e verificar através de testes se a proposta é coerente com as expectativas e modelos mentais do meu usuário primário. O Card Sorting funciona, então, como um teste de usabilidade? Sim, definitivamente. Concluindo, o que queremos mostrar com esses três exemplos é que não há uma ordem pré-determinada para a produção de Matriz de Escopo e testes de Card Sorting. O bom senso é mandatório para definir quando e se vamos aplicar o Card Sorting, especialmente requisitado em projetos envolvendo muita informação, cruzamento de dados e inteligência na apresentação dos resultados. 2-2 – O Wireframe – regras de apresentação e comportamento de elementos Após a validação ou homologação da Matriz de Escopo com ou sem o Card Sorting, nós temos dois caminhos a seguir: Mapa de Navegação ou Wireframe. Diria para vocês que na maioria das vezes, nós elaboramos um primeiro mapa bem simples logo após a Matriz de Escopo e vamos mexendo nele durante a produção dos Wireframes. No caso de portais, posso afirmar que isso acontece em 90% dos casos. Então, vamos falar sobre Wireframes e depois falamos sobre Mapa de Navegação. Ok? Saibam que em alguns casos a situação pode se inverter. Por exemplo, nas aplicações onde o usuário executa uma seqüência de tarefas. Daí o Mapa ganha uma função estratégica especial pois ele será fundamental para que você visualize a flexibilização da navegação do usuário. Bom, particularmente, eu prefiro produzir um primeiro Mapa baseado na Matriz de Escopo e só então iniciar a criação dos Wireframes. Mas vamos lá. O Wireframe é uma maquete do site ou aplicação que vamos desenvolver. A essa altura do projeto, nós já temos um planejamento muito bem fundamentado, executamos a Análise de Requerimentos do Projeto, produzimos a Matriz de Escopo com ou sem um Card Sorting. Enfim, podemos visualizar quase tudo que o site terá como recurso e como Key Feature. Neste momento, o Arquiteto de Informação vai começar a trabalhar em sintonia com a equipe de criação, responsável pela Direção de Arte e com editores e redatores, se for o caso de um projeto essencialmente editorial. No Wireframe, vamos distribuir a informação e o conteúdo, bem como planejar as telas de tarefas e mensagens de erro do sistema, desde a tela principal de acesso para o usuário primário até a última etapa de navegação. Também vou definir as vias de acesso e flexibilização da navegação. Entendem porque não fechamos o Mapa logo no início? Porque é muito complicado você flexibilizar (permiti r que o usuário utilize atalhos intuitivos) apenas com a representação abstrata do fluxo de navegação. O Mapa é uma abstração necessária, porém insuficiente para que você planeje detalhes.



Então, de posse de todo o meu planejamento, começo a visualizar a INTERFACE, vou dispor os elementos nas telas, saber exatamente quantas etapas e que informações daremos ao usuário em cada uma delas. Partam sempre da ação principal para os detalhes. Ao rever cada link, vocês precisam validar as mensagens do sistema. NORMA de Usabilidade (espetem na geladeira ou no monitor do computador):

O sistema deve responder a toda e qualquer ação do usuário com a sua interface. Esse feedback deve ser de preferência visual: isso inclui a mudança de cor dos botões e links até as caixas de texto e mensagens de erro e confirmação de operação do sistema.

Até onde vai o trabalho do arquiteto e começa o do Diretor de Arte ou Designer? Bom, pessoal, como tudo que nós temos dito a vocês, depende. Depende da natureza do projeto e das suas restrições e objetivos estratégicos. Há projetos em que a experiência estética é importante e permite um “delírio criativo” por parte dos Designers e Diretores de Arte. Em 2003, a Macromedia investiu boa parte de seus esforços em implantar interfaces RIA (Rich Internet Application), baseadas em linguagem Action Script, plataformas dinâmicas para acesso a banco de dados e interfaces gráficas com os recursos multimídia do Flash. Sem dúvida, o resultado era e é bastante interessante e encantou os designers mais arrojados, mas não desbancou o velho e bom HTML com seus botões e links super leves. O RIA não decolou. Foram poucos os cases de RIA com grande repercussão. Eu diria que, apesar de fatores tecnológicos importantes como carregamento lento no primeiro acesso - um problemas de usabilidade - há um fator que ficou mascarado na história tão pouco brilhante do RIA. Esse fator era justamente a navegação pouco flexível que demandava um planejamento de A.I. fechadíssimo em cima de Wireframes e Requerimentos do Projeto. Um site em RIA não permite que você altere elementos do projeto tão facilmente quanto o faria em uma interface HTML. E em 2003, A.I. ainda era um assunto, digamos, “de elite” junto à comunidade de desenvolvedores brasileiros. Talvez, se o RIA nascesse agora, essa história pudesse ser um pouco diferente. Mas enfim, voltando ao Wireframe, nós vamos (na falta de um termo mais universal e simples) rascunhar nossas telas, determinando qual o espaço e quais os recursos de programação de interface serão colocados no projeto. Aqui, o trabalho é constantemente validado junto à equipe de desenvolvimento. Após a produção de cada link, eu volto ao Mapa de Navegação principal e vou detalhando o fluxo que planejei inicialmente. Se o profissional de A.I. tiver um conhecimento razoável de recursos de interface, poderá fazer uma grande diferença junto à equipe de criação. O Arquiteto pode determinar ou influir nas tecnologias que serão utilizadas: existência de frames, botões em flash, fotos e i lustrações, tipos de Menus, disposição de área para publicidade on-line. O Arquiteto de Informação é o grande articulador da Equipe envolvida no Projeto. Notaram como o Arquiteto de Informação, embora não seja um Gerente de Projetos, articula com toda a equipe? Perceberam porque ele é essencialmente o “advogado de defesa” do usuário primário durante todo o ciclo de vida do projeto e, não raro, defende o trabalho da Equipe Desenvolvedora junto ao cliente? Ele é o grande fiscal de Usabilidade, que deve garantir a aplicação dos princípios heurísticos e dos dados coletados e compilados em testes. É o grande Aliado da Gerência de Projetos, por ser também alguém que zela pela qualidade do Projeto. Bem, vamos a alguns exemplos de Wireframe. Normalmente, é desenvolvido em Power Point e Visio, duas ferramentas da Microsoft, por dois motivos: a produtividade é muito maior do que em programas gráficos comuns como Corel e Photoshop, além de ambos gerarem arquivos em formatos universais. No caso do Visio, você poderá salvar seu arquivo em GIF ou JPEG. Dá para abrir no Browser, sem problemas. Porém, lembre-se de manter o arquivo editável (original) em seu computador. Pessoal, faço aqui uma ressalva importante:

Wireframe não é layout. Wireframe é documentação.



Tenho visto muitos desenvolvedores apresentarem modelos de Wireframe que são praticamente propostas de layout. Não façam isso. Além de tolher as possibilidades da Direção de Arte, a produtividade ficará comprometida pela dificuldade de atualizaçã o da documentação a cada vez que uma modificação ou alteração for solicitada pelo cliente. Essa é uma herança do meio offline que deve ser deixada no passado ou para a mídia tradicional, à medida do possível. Vocês ficarão malucos se insistirem em produzir Wireframes com requintes e cuidados de layout (botões e testeiras produzidas em programas gráficos, por exemplo).

(APRESENTAÇÃO de modelos de Wireframe) 2-3- Mapa de Navegação O Mapa de Navegação é, na verdade, um fluxograma de navegação, elaborado com um critério específico. Ele mostra o “caminho” do usuário de link para link. Lembrem-se de que vocês estão lidando com documentação eletrônica, então é preciso ser pragmático com o tamanho do Mapa e com o nível de detalhamento. Afinal, um documento ilegível não serve para nada. Portanto, não vá gerar um mapa do tamanho de um outdoor. Faça o mapeamento por níveis. Também não é preciso fazer constar todos os atalhos possíveis para o usuário. Vale o bom-senso e a experiência nessa hora. Como todo mapa que você está acostumado a consultar, o Mapa de Navegação necessita de legendas que identifiquem e expliquem a sinalização e que possibilitem a toda a equipe a compreensão da documentação. O cliente também deve ser capaz de assimilar e acompanhar esse conteúdo, por mais técnico que seja. Muitas vezes, isso é uma exigência para homologar as etapas do projeto. E é um fator de qualidade na prestação do serviço de desenvolvimento. Tecnologiquês é coisa do passado. Procure ser claro e explícito na sua documentação. Cada caso é um caso Vocês já devem estar cansados de ouvir a mesma ladainha, mas... Novamente: não há critério fechado para a sinalização de um Mapa de Navegação, vai depender da natureza do seu projeto. Aqui vão alguns exemplos e sugestões contextualizadas em situações bem comuns:

Você pode sinalizar no Mapa todas as áreas de acesso restrito por login e senha.

Você pode sinalizar áreas de conteúdo dinâmico, com acesso a banco de dados de notícias por exemplo.

Você pode sinalizar áreas com acesso a conteúdo multimídia.

Você pode sinalizar áreas criptografadas, com recursos de segurança de dados (remessa de dados bancários e cartão de crédito). Enfim, quanta informação importante você pode gerar para a equipe e que faz, sim, parte da documentação de A.I. Não se esqueça de legendar o seu Mapa, colocando no rodapé ou em algum local bem visível toda a legenda de sinalização utilizada. Afinal de contas, a documentação também está sujeita a normas de usabilidade, ou seja, ela também tem que ser eficaz. Para efeito de deixar bem explícito, vou propor para vocês um mapeamento de navegação baseado em uma norma heurística de usabilidade, muito defendida por Jakob Nielsen e que tem um embasamento científico dentro das disciplinas cognitivas. O cérebro humano funciona como um supercomputador com características bem particulares: tem uma grande, enorme capacidade de armazenar informação, mas com uma memória de curto prazo (memória RAM do PC que a gente tanto conhece) bem pequenininha. Por conta desse aspecto, o usuário comum tem memória curta, ele ou ela não toleram uma cadeia muito longa de informações até o objetivo final. Na prática, nós devemos planejar nossas interfaces com no máximo três escalas até o objetivo final da navegação. Claro, muitas vezes é impossível porque a tarefa executada pelo usuário é complexa. Mas digamos que nós devemos perseguir essa meta de usabilidade, que trocando em miúdos corresponde a não planejar mais que três clicas até o objetivo final, principalmente nas Key Features.



Certo? Bom, neste curso nos vamos um pouco mais longe que Nielsen e vamos mapear essas etapas no nosso Mapa de Navegação. O detalhe aqui é que não vou mapear apenas clicks, mas as etapas de associação da informação. Nós vamos mapear a cadeia de informações que o usuário segue até a informação desejada. Não interessa se ele vai clicar em um menu ou botão, isso é um ato motor. O que me interessa como Profissional de A.I. é: quantas associações dentro dessa cadeia se fazem necessárias até a informação ou feedback do sistema, não importa, para que o usuário primário da interface chegue até o objetivo de navegação?

Perguntem-se: Quantas associações eu preciso fazer até a informação ou resultado final?

Fazendo isso, nós podemos aplicar um controle de qualidade na experiência do usuário. Qual seria então a metodologia utilizada? Vamos usar um método de cores para classificar os níveis de acesso ou associação da cadeia de informações que o fluxo de navegação do projeto está propondo. Confiram o exemplo abaixo. A complexidade do projeto (um portal com vários sub níveis) pode determinar a necessidade de se criar vários sub tons, mas simplificando, temos cinco cores, sendo que dois tons de cinza (seria um mapeamento até o sexto nível). Bem simples, para que vocês entendam.



Suponhamos que eu parta do nível azul (digitando a URL e acessando) – vejam como eu sinalizo a essa seqüência, em particular, até o sexto nível: >Primeiro Nível

>> Segundo Nível >>>Terceiro Nível >>>> Quarto Nível >>>>> Quinto Nível >>>>>> Sexto Nível

Primeiro Nível

Terceiro Nível

Segundo Nível

> Marcado pela cor azul, o primeiro nível de acesso apresenta quase nenhuma dificuldade para a maioria dos usuários. Basta acessar a web e digitar a URL corretamente.

>> Marcado pela cor verde, o segundo nível de acesso representa a primeira opção escolhida pelo usuário ou imposta pelo sistema. Até aqui, o desafio é escolher entre links e funcionalidades expostos num menu principal.

>>> Marcado pela cor vermelha, o terceiro nível de acesso representa o objetivo final de navegação em projetos convencionais quando, por exemplo, o sistema não exige nenhuma forma de login.

Quarto Nível

>>>> Marcado pela cor laranja, o quarto nível de acesso representa uma etapa de navegação importante, após o conteúdo final alcançado. Em projetos convencionais, são recursos como imprimir, enviar, guardar, por exemplo.

Quinto Nível

>>>>> Marcado pela cor cinza chumbo, o quinto nível de acesso já não é memorizado pelo usuário com facilidade, por isso deixamos para o quinto nível conteúdos e funcionalidades agregadas ao escopo principal, como um subnível para assinatura de uma revista ou outro serviço que não seja estrategicamente importante para ser colocado no primeiro ou segundo nível.

Sexto Nível

>>>>>> Marcado pela cor cinza claro, o sexto nível de acesso representa links de saída ou encerramento de serviços do sistema.



Ou ainda: >Nível da URL ou interface principal

>> Links do Menu principal da Come >>> Interfaces e telas que partem do link principal ou Menu de Segundo Nível >>>> Conteúdos restritos, resultados de busca e cesta de compras. >>>>> Processo internos e conteúdos de busca refinada. >>>>>> Mensagens de Resposta do Sistema De modo geral, obedecendo a normas de usabilidade, a cor VERMELHA, nos sinaliza um nível crítico do acesso. O usuário comum com uma experiência mediana em interfaces tecnológicas, só memoriza até este nível quando retorna a um site. Não custa repetir: não se trata de cliques (uma ação motora), mas sim a cadeia de informações relacionadas que é um processo mental. É isso que interessa no seu projeto. Conte as associações, não apenas os cliques. Três Idéias, três Informações, três tarefas --------------------- Ótimo nível de usabilidade >idéia 1 >> idéia 2 >>> idéia 3 = capacidade de memorização do usuário mediano (com alguma experiência em interfaces tecnológicas) Vamos ver um Mapa, na prática, utilizando o critério apresentado:



Repare que utilizamos uma numeração link 1.2.1.2... Também utilizamos uma estrutura muito específica de visualização com links indicando onde temos um sublink encaixado em outro sublink, onde há mais de uma oportunidade ou possibilidade de navegação OU resposta do sistema. Tudo isso pode e deve constar do Mapa de Navegação. Na prática, nos atualizamos constantemente o Mapa, a cada vez que introduzimos um novo elemento ou fechamos uma nova proposta de Wireframe. Não deixem de efetuar a atualização dos arquivos de documentação. Na hora de negociar, por exemplo, um estouro de horas por conta de mudanças e ocorrências, esse historio pode ser um argumento valioso. Lembrem-se: o que não se documenta, fica perdido na poeira do tempo e na bagunça de arquivos com nomes semelhantes e versões diferentes armazenadas em máquinas diferentes. O que não se documenta, não existe. Aí vai um exemplo com outras marcações e legendas:



Observem as legendas nesse caso: veja que o Mapa mostra exatamente até onde deve haver criptografia e acesso fechado, por exe mplo. Quando eu defino uma seqüência de tarefas, tenho que determinar se o acesso permanece fechado ou a criptografia continua. Pode parecer excesso de meticulosidade, mas não é. Quando nós homologarmos o site pronto junto com o cliente, temos um instrumento poderoso de validação da entrega de cada recurso do projeto. Bom, para encerrar este tópico, mais dois últimos pontos a abordar sobre fluxo de navegação: O primeiro deles é que em projetos grandes ou mesmo em pequenos, porém com nível grande de detalhamento, vocês podem produzir Mapas contemplando os níveis de acesso. Assim o Mapa principal conteria até o quarto nível, por exemplo. A partir daí você poderá montar micro Mapas, que esmiúcem até mesmo as mensagens de erro e sucesso do sistema. O segundo ponto é o aspecto que eu quero chamar atenção de vocês e deixar muito, muito fixado neste curso. Quando você aprende a dirigir, tem que pensar em cada etapa que deve cumprir: ligar o carro, baixar o freio de mão, pisar na embreagem, engatar a primeira... E por aí vai. Passado um tempo, essa tarefa torna-se automática. É como se o seu cérebro criasse atalhos e seqüências lógicas, sem que precise resgatar e “entender” o fluxo de tarefas para dirigir seu carro. Pois bem, quando somos alfabetizados ocorre algo semelhante, a palavra passa a ser a imagem de um signo que nos diz algo. Esse é o processo de alfabetização, há de fato um certo automatismo no processamento da linguagem. Também é assim com os sinais visuais e etc. Pessoal, com as interfaces é a mesma coisa. Quanto mais rápido o usuário automatiza o processo, mais ele se aproxima do pouco esforço na realização da interação. Isso nos leva a uma série de desafios associados à usabilidade de hardwares e softwares. Quanto maior e mais longa a curva de aprendizado, mais o processo de automatismo fica distante e menos usabilidade o seu projeto terá. No módulo III, nós vamos investigar uma série de fatores que devemos levar em consideração quando planejamos uma interface. Para cada variável do projeto, vocês verão que existe uma série de conclusões científicas de aplicação muito prática e que podem nos orientar na busca deste estado-da-arte em Usabilidade. 2-4 – Prototipação Pessoal, vocês podem prototipar uma interface ou parte delas, no nosso caso aqui, de duas formas: em papel ou de fato desenvolvendo a aplicação e testando. Quando prototipamos uma interface e/ou sistema, é porque vamos de alguma maneira testá-la, em geral com usuários. De qualquer forma, a prototipação tem que ser feita após o Wireframe e sua conseqüente validação. Não se investe tempo e dinh eiro em prototipação, sem Wireframes homologados. O paper prototyping (prototipação em papel) é um teste com usuário que necessita de um profissional que atua como monitor e que faz o “papel” do sistema. Ao invés do usuário clicar, ele aponta para a opção desejada e o monitor então mostra a tela resultante daquela escolha. Particularmente, acho o paper prototyping muito, muito restrito, pois não há paralelo cognitivo entre papel e a tela de um computador. Mas, em alguns casos, funciona, pelo menos para demonstrar e aferir as preferências estéticas do usuário. É planejado da mesma forma que um teste de usabilidade comum, com seleção de usuários, funcionalidades a serem testadas e etc. Mas não há como driblar a influência do profissional que monitora o teste. Muitos usuários chegam a sentir uma pressão psicológica, sentem que estão fazendo um teste de Q.I. ou personalidade. Aí, o resultado fica comprometido. O relatório é compilado igualzinho a um teste c om o sistema real. Também não há ações motoras por parte do usuário, que se assemelhem a uma interatividade real. Acho muito restrita a aplicação desta metodologia, mas é importante que vocês saibam que podem contar com este recurso. Na prototipação, digamos real, do sistema, com interfaces via browser, o teste é feito da mesma forma como se o sistema estivesse pronto. As exigências são as mesmas, mas neste caso não temos uma figura humana monitorando, pois o sistema responde.



Vocês podem optar por um protótipo sem caracterização estética. Eu penso que o protótipo é fundamental para as aplicações que funcionam como um software. Interfaces de Internet Banking são candidatas fortíssimas à prototipação. Softwares e aplicações para celulares então, nem se fala. Se esse for o caso: inclua no orçamento de desenvolvimento uma prot otipação. Não titubeie. As versões beta de softwares são protótipos avançados e sua distribuição não deixa de ser um teste de usabilidade em larga escala. Se o protótipo apontar erros estratégicos, poderemos voltar atrás e economizar alguns dígitos em verbas equivocadas de marketing, lançamento e etc. A prototipação é a última chamada para corrigir erros ou miopias que as outras metodologias, por algum motivo, não identificaram. 2-5 – Testes Finais Pessoal, quando temos o site pronto, não fizemos protótipo, ou até fizemos e tudo ficou ok, podemos ainda aplicar análises heurísticas e testes com usuários. Lembram do Módulo I? Vamos reconstruir o contexto, testar os usuários conforme planejamos e aferir se de fato atingimos a meta de Usabilidade. Vamos exemplificar: Meta de Usabilidade do Projeto: Nível ótimo na avaliação de 90% dos usuários nas seguintes funcionalidades: Cesta de Compras, Livro de Receitas e Cadastramento para newsletter, mesmo utilizando conexão gratuita (discada). Meta (nível ótimo) alcançada para cada uma das funcionalidades: Cesta de Compras: 70% Livro de Receitas: 80% Cadastramento: 50% Conclusão: atingi minha meta? Não. Quais as causas e ações a serem tomadas para reverter a situação? Tudo isso um Relatório de Usabilidade pode e deve responder. Veja, eu posso super detalhar o teste. O exemplo é bem resumido, mas contem os elementos principais: contexto, key features, usuários primários. QUEM executa. O QUE executa. EM QUE condições executa e QUANTO TEMPO leva para executar Lembram-se do Módulo I? Eu tenho cenário fechado. A usabilidade só existe a partir de contexto e personagens. Uma aplicação que deve ser acessada via conexão discada jamais pode ser testada num ambiente com conexão de alta velocidade. Prestem atenção a esses detalhes de suma importância. Caso contrário, o resultado do seu teste será truncado. Bom, é isso pessoal. Nos vemos no próximo Módulo.



PERGUNTAS - MÓDULO II (teste seus conhecimentos!) 1- Assinale a alternativa verdadeira:

1. Não se pode começar uma Matriz de Escopo sem antes realizar um Card Sorting Fechado.

2. Somente o Card Sorting aberto é considerado um teste de usabilidade.

3. Ao construir um Mapa de navegação, é necessário inserir absolutamente toda a sinalização de recursos empregados em cada link

dentro de uma padronização internacionalmente conhecida

4. O primeiro nível de acesso do site é a segunda página clicada pelo usuário a partir da principal.

5. Os níveis de acesso são exatamente a mesma coisa que o número de cliques executados pelo usuário.

6. O paper prototyping (prototipação em papel) pode substituir totalmente o teste com protótipos em interface digital como os

protótipos em HTML, por exemplo.

7. A distribuição de versões beta de softwares e aplicativos a usuários avançados e/ou formadores de opinião são, de certa forma,

testes de usabilidade em larga escala (com um número grande de usuários).

2- Assinale a alternativa falsa:

1. O protótipo em papel tem muitas limitações e restrições, pois necessita da mediação do aplicador do teste.

2. O protótipo digital não requer caracterização estética, mas deve ser fiel ao planejamento até a sua produção.

3. O protótipo não necessita ser desenvolvido com totalidade das funcionalidades, mas a key features devem obrigatoriamente fazer

parte dele.

4. O wireframe pode em alguns casos assimilar a direção de arte, muitas vezes até substituindo o protótipo com caracterização

estética.

5. Um profissional de A.I. pode ser oriundo de variadas áreas profissionais e campos de conhecimento distintos entre si, como di retores

de arte e bibliotecário, por exemplo.

6. A arquitetura da informação surgiu da necessidade de se criar uma área multidisciplinar que produza uma documentação acessível a

toda a equipe de projeto.

7. O profissional de A.I. precisa corrigir a documentação do projeto a cada modificação ou alteração, marcando as mudanças e

arquivando os documentos anteriores ao longo do período de desenvolvimento.

3- Fazem parte da documentação de A.I. os seguintes elementos, exceto:

1. Definição de Usuários.

2. Matriz de Escopo.

3. Relatórios de Usabilidade.

4. Mapa de Navegação.

5. Wireframe.

6. Protótipos.

7. Plano de marketing.

4- Um arquiteto de informação deve possuir os seguintes conhecimentos, exceto:

1. Noções de linguagens de programação para internet.

2. Card Sorting fechado.

3. Programação de mainframes.

4. Aplicativos básicos da MS como Power Point e Excel.

5. Webwriting.

6. Noções sobre gestão do conhecimento e marketing online.

7. Conhecimento sobre infra-estrutura de T.I. para Internet.



5- Assinale a frase em que há uma relação equivocada entre causa e efeito.

1. O arquiteto de informação não precisa ser exatamente um especialista em usabilidade porque são campos que embora sejam

convergentes, permanecem com atribuições muito distintas.

2. O arquiteto de informação não pode atuar como especialista em usabilidade no projeto em que está desenvolvendo a

documentação de A.I. pois seria o mesmo que um redator acumular o cargo de revisor dentro de um grande jornal.

3. Key features corretamente determinadas aumentam o ROI do projeto porque focam o desenvolvimento e o investimento em testes

de usabilidade nas funcionalidades essenciais ao objetivo estratégico do projeto.

4. Como não há uma formalização ou currículo oficial de A.I. no Brasil, qualquer pessoa pode se habilitar ao cargo, mesmo que não

possua nenhum conhecimento tecnológico.

5. Sites com boas ferramentas de busca não necessitam de planejamento de A.I., já que não a construção de menus complexos.

6. O Card Sorting fechado só deve ser aplicado depois do Card Sorting aberto, pois um processo depende completamente do outro.

7. O RIA criado pela Macromedia não decolou porque apesar da boa usabilidade, os programadores não estavam familiarizados com a

nova técnica e criavam fontes com muitos bugs.

Modulo ii arquiteturainformacaousabilidade_thaiscampas

Technology

Transcript of Modulo ii arquiteturainformacaousabilidade_thaiscampas