modulo i 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 I

"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 I 1.1 - Introdução ao Conceito de Usabilidade. Essa tal de usabilidade... Mas afinal o que vem a ser isso? 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. Difícil? Nem tanto. Para chegar ao que hoje, muitos consideram como uma ciência, foram 20 anos de história. Aqui vai um breve resumo para que vocês entendam. Antes, um detalhe importante: quando mencionamos interface, levem em consideração que nos referimos genericamente a interfaces baseadas tanto em software como em hardware, mesmo que o surgimento do termo esteja associado à indústria de software. Ok? Podemos mensurar e testar a usabilidade de um hardware a partir de princípios semelhantes às interfaces de sistemas. Cert o? Então, vamos lá. Anos 80 Usabilidade parece algo novo, da era pontocom, mas não é. Surgiu nos anos 80, quando a informática pessoal “colocava suas manguinhas de fora”, com a eclosão das poderosas Microsoft e Apple. Naquela época, os desenvolvedores de software davam suas cambalhotas para realizar pesquisas e testes que garantissem interfaces mais “amigáveis”. Isso mesmo! Mais “amigas do usuário”. Usabilidade era então um termo de ergonomia, que indicava a adequação da interface software aos padrões cognitivos do ser humano. Enfim, usabilidade era muito mais uma conversa de acadêmicos para acadêmicos, do que um jargão de mercado. Mas os caras da MS e da Apple (que acreditavam no boom do computador pessoal) queriam e precisavam vender, então... De adequação à norma de qualidade. No começo dos anos 90, entraram em cena nas empresas as certificações e práticas de qualidade total. Quem estava no mercado de trabalho em 93, 94, viveu essa “febre”. Cultura organizacional, posicionamento voltado para o cl iente, 5S e mais uma meia dúzia de termos e expressões eram mandatórias: quem não soubesse significados e aplicações era potencialmente um desempregado. 1991, o “ano” Lembram da corrida pelo certificado ISO 9000? Pois é, foi nessa onda que o temo usabilidade saiu das universidades e ganhou o mundo com a primeira norma de usabilidade: a ISO/IEC 9126, em 91. Um marco importante porque usabilidade passava a ser definida como qualidade de um produto a partir da experiência do usuário, ou seja “como um conjunto de atributos de software relacionado ao esforço necessário para seu uso e para o julgamento individual de tal uso por determinado conjunto de usuários”. A norma e o conceito evoluíram junto com o mercado de software e em 1998 a ISO/IEC FDC 9126-1 já incluía conceitos como portabilidade e garantias de manutenção. De 2000 até hoje. Portanto, hoje, em 2006, a definição mais oficial de Usabilidade é a descrita no componente do Standard de ISO 9241-11 (1998): “Usabilidade é a eficiência, eficácia e satisfação com a qual os públicos do produto alcançam objetivos em um determinado ambiente”. Sendo que: - Eficácia é a capacidade de executar tarefa de forma correta e completa. - Eficiência são os recursos gastos para conseguir ter eficácia, sejam eles tempo, dinheiro, produtividade, memória. - Satisfação é o conforto e aceitação do trabalho dentro do sistema. Particularmente, eu prefiro colocar os termos assim: - Eficácia (alguns consultores gostam do termo efetividade) é um conceito relacionado ao resultado final de um processo. Eficácia foca resultado. É eficaz, efetivo? Funcionou? Entrega o que promete? - Eficiência é um conceito relacionado ao processo que leva ao resultado. Foco no processo. Ë fácil, é difícil, é complicado, quantas etapas levam ao resultado?



- Satisfação é um conceito ligado ao conforto ergonômico, cognitivo e até mesmo, pasmem, afetivo e emocional do usuário. A interface é confortável? Oferece algo mais para o usuário? Respeita suas limitações e características culturais e individuais? Peraí... individuais? Sim, individuais. Pessoal, quando se trata de interface entra em jogo a “persona” do usuário. Usuário é uma palavra muito mais individualizante do que as tradicionais pesquisas de mercado delimitam. Mais para frente, vamos falar desse assunto, estabelecendo em nossos projetos o que são usuários primários, secundários, terciários e etc. Jakob Nielsen*, o papa. Gente, eu tenho que falar dele. Jakob Nielsen, renomado consultor mundial sobre o assunto odiado por uns e amado por outros, (vou deixar a lista de livros na bibliografia, não se preocupem) personalizou a definição acima, usando o conceito da curva de aprendizado, bem familiar para o pessoal de TI e Sistemas. Trocando miúdos, uma interface deve oferecer facilidade de aprendizado, eficiência de uso, facilidade de memorização, baixa taxa de erros e satisfação subjetiva. Na verdade, é uma forma jakobiana de falar tudo o que já foi mencionado antes. Mais abaixo, vamos colocar dois preceitos de Nielsen que são fortes candidatos a entrarem na próxima edição da norma ISO*.



Definições para ler, guardar, lembrar, ler de novo, colar no espelho... Vamos voltar ao primeiro parágrafo desse tópico. Lembrem-se de que: - Usabilidade é um único conceito que define as 3 propriedades principais de uma interface: eficácia (ou efetividade), eficiência e satisfação do usuário. Ou, usabilidade é um conceito associado a uma interface que se define a partir de três focos: resultado+processo+conforto do usuário. - Usabilidade é um conjunto de práticas. Práticas, processos e procedimentos de criação e produção de interfaces centradas na persona do usuário. Ou: centradas na experiência do usuário. E que práticas, processos, técnicas e etc são essas? É o que vamos tratar ao longo deste curso, pessoal. Vocês vão aferir se de fato estão trabalhando com práticas centradas na experiência do usuário, ou se estão projetando interfaces a partir de conceitos aleatórios - seus próprios modelos estéticos e mentais ou até a partir das exigências de quem assina o cheque para o projeto. - Usabilidade é um conjunto de preceitos que caracterizam interfaces com maior “fator” de usabilidade. São interfaces eficientes, eficazes e confortáveis. Exemplo de preceitos: estabelecer um máximo de três cliques para finalização de um processo, não utilizar pop-ups, dar feedback permanente ao usuário a cada interação com o sistema. Tudo isso são preceitos de usabilidade. Mas fiquem atentos: os preceitos podem mudar de acordo com a evolução tecnológica e à medida que o usuário se torna mais “intimo” do sistema. De 2006 em diante: Segurança da Informação e Flexibilidade Defendidos por Jakob Nielsen*, estes dois princípios devem ser incluídos no seu planejamento. É muito possível que eles façam parte da próxima edição da norma ISO... Portanto, vamos lá: Quando vocês adquirem um produto qualquer em lojas físicas ou virtuais, lendo as informações da embalagem, é muito comum encontrar especificações sobre segurança: se o produto é inflamável, se oferece algum tipo de risco quando manipulado por crianças, se pode se tornar tóxico ou oferecer risco à segurança e integridade física do consumidor em alguma situação ou contexto. Existem até leis, regulamentação, institutos de pesquisa e órgãos que fiscalizam essas questões para cada segmento de produtos: remédios, brinquedos, carros... Bom pessoal, as interfaces digitais também oferecem risco: vírus, quebra de privacidade e roubo de dados, por exemplo. Vou ci tar um exemplo bem claro que dispensa maiores explicações: Internet Banking. A segurança da informação tem dois pontos de vista que precisam ser visualizados: Segurança real x Segurança explícita para o usuário. - O usuário precisa se sentir seguro, os processos de senhas, de reenvio de senhas, informações criptografadas e tudo o mais que a aplicação necessitar devem ficar claros para o usuário. Se o procedimento de segurança não estiver claro e acessível ao entendimento do usuário, você poderá ter problemas em futuro próximo. Lembre-se de que o direito digital caminha a passos largos para se tornar uma matéria de lei específica. Isso vai mudar drasticamente o contexto legal da segurança digital. Na prática, implementem sistemas de segurança, observando o perfil do usuário e seu contexto de uso. Se necessário, realizem testes de usabilidade, envolvendo as rotinas de segurança. - Não basta que o sistema transmita segurança, ela precisa de fato estar presente no planejamento do seu site. Jamais cometa o erro de deixar a segurança apenas por conta de procedimentos efetuados pelo usuário, não minimize os riscos, não deixe a questão da segurança do seu site na mão da empresa de hosting. Soluções de segurança devem entrar no orçamento do seu projeto, criptografia, firewall, softwares que protegem o web server. Nada disso é luxo, há soluções para todos os bolsos. E se você está desenvolvendo uma loja digital, assegure-se de que seus parceiros de negócios oferecem ambientes seguros para transação de dados bancários e de cartão de crédito. Assegure-se, pois você responderá legalmente pelas conseqüências. Mesmo que não seja diretamente culpado pelo roubo de dados, por exemplo, poderá sofrer com o desgaste de imagem, fora o custo da defesa legal. Tecnicamente, existem dois aspectos que devem abranger seu planejamento de segurança digital: Segurança de Dados: dados bancários, pagamentos, CPF, dados pessoais e de cartão de crédito devem trafegar em ambiente seguro, com recursos de criptografia. Os cuidados com senha e cadastros devem ser comunicados ao usuário. Não delegue procedimentos cr íticos de segurança a seu usuário. Cuide dos servidores e das aplicações que rodam neles, verifique firewalls e anti -vírus. Mantenha o programa de anti-vírus atualizado. Lembre-se de que bugs e vulnerabilidades são descobertas todos os dias. É impossível delegar essa tarefa para seu usuário*, manter sistemas e aplicações atualizados é função é sua. Seu servidor é responsabilidade sua, mesmo que tenha contratado uma máquina dedicada junto a um Data Center.



* Deixe visível sua política de segurança e privacidade. Informe o usuário, deixe que ele conheça as rotinas e procedimentos do seu canal. Deixe claro que tipo de informações a equipe do site pode enviar por email. Mantenha uma equipe de suporte e ajuda ao usuário.

Privacidade: newsletter, email marketing, a estratégia comercial não sobrevive em ambiente online sem o famoso “assine nossa newsletter”. Entre Spam e marketing de permissão existe uma distância muito sutil para ser percebida pelo usuário. No marketing de permissão deve haver o tratamento correto da persona do usuário, ele deve ser tratado como indivíduo, como cidadão, como cliente e como convidado especial. Isso significa que ele deve ser tratado pelo nome e deve ter a opção de receber ou não informações adicionais ao serviço que assin ou, como promoções e propagandas de parceiros, por exemplo. Outra questão é não compartilhar, com outros sites ou empresas, dados e cadastros de seus clientes, não comercializar dados. E deixar isso visível e explícito para o usuário. Quando permitimos que outros utilizem nossa base dados de clientes há riscos bem claros: a base de dados pode sair do ambiente seguro que desenvolvemos e não há como garantir que nossa política de segurança e privacidade* seja cumprida por outrem. Ora pessoal, é simples: posso estar permitindo que o usuário acesse um ambiente que não aquele desenvolvido e garantido pelos meus recursos de segurança, concordam? Assim, eu ponho em jogo a confiança e a credibilidade que o usuário depositou no meu site e no meu serviço. * Novamente: Deixe visível sua política de segurança e privacidade. Informe o usuário, deixe que ele conheça as rotinas e procedimentos do seu canal. Deixe claro que tipo de informações a equipe do site pode enviar por email. Mantenha uma equipe de suporte e ajuda ao usuário. Concluindo: Oferecer um ambiente seguro para todos os seus usuários - primário, secundário e terciário – é sim uma questão de usabilidade, que deve ser tratada sob o ponto de vista de quem utiliza a aplicação, e não apenas sob o ponto de vista da tecnologia, das estatísticas abstratas de ameaças virtuais e de invasões de hackers. Se existem procedimentos de segurança críticos a serem efetuados por usuários, esses procedimentos podem e devem ser testados e homologados em laboratórios de usabilidade. Lembrem-se: usabilidade é uma instância da qualidade do serviço ou produto comercializado! Flexibilidade das interfaces Flexibilidade é um conceito muito aplicado por Jakob Nielsen*. Quando projetamos uma interface em ambiente Web, a navegação d o usuário até o resultado desejado pode e deve ser delimitada, mas não deve ser excessivamente engessada. Isso quer dizer que outros caminhos cognitivos e a cooperação entre tarefas têm que ser levada em conta. O usuário deve ter mais de uma opção de seqüência de tarefas ou “caminhos” até a finalidade da navegação. Essa finalidade pode ser uma informação ou o término de um processo como uma compra online, por exemplo. Devemos ter em mente que o usuário pode utilizar diversos pontos de partida até a finalidade e que as interfaces evoluem tal como a nossa língua e a nossa cultura. O meio digital é dinâmico. Quando criamos as interfaces, partimos de um caminho principal, depois de construído o caminho principal, projetamos os atalhos, desvios e novas vias de acesso. Vamos flexibilizando a navegação, aumentamos as opções, oferecemos novos recursos, mas efetivamente não perdemos o foco. Resumindo: flexibilizar uma interface é flexibilizar a navegação através da qual chegamos ao nosso objetivo. Podemos notar que a flexibilização é um preceito de usabilidade muitíssimo relacionado ao ambiente Web onde o dinamismo do meio digital é preponderante para o c iclo de vida dos projetos. 1.2 - Importância da Usabilidade em diferentes contextos e momentos do negócio Para simplificar, vamos analisar dois momentos do negócio, a saber:

1. Planejamento e concepção do produto, solução ou projeto. 2. Após o lançamento do produto, solução ou projeto.



1 – Usabilidade na fase de Planejamento: Como especialista em usabilidade, tenho um sonho: a usabilidade assimilada como aspecto estratégico, tático e fator de sucesso para produtos e serviços, passando a fazer parte do composto de marketing e ocupando um capítulo especial nos manuais assinados pelos papas da mercadologia. Basta que deixemos de nos focar pura e simplesmente na concepção da interface. Vamos nos focar na Experiência do Usuário que faz parte de um público-alvo que por sua vez faz parte de um grupo de consumidores. Na experiência do usuário com o produto ou serviço que desejamos lançar, partindo:

Do resultado (finalidade de uso). Eficácia ou efetividade.

Do processo (etapas para atingir a finalidade de uso). Eficiência.

Da satisfação do usuário (valor agregado oferecido ao usuário e conforto dos processos). Lembram-se das definições? Então voltemos ao cenário de projetos para a Internet. Sabemos que os projetos Web são multidisciplinares, ou seja, envolvem profissionais de formação e experiência diversa, principalmente na fase inicial. Prestem muita atenção a isso. Diversidade de profissionais significa diversidade de modelos mentais. Modelos mentais e culturas organizacionais diferentes podem gerar uma grande miopia em relação aos aspectos estratégicos do projeto. Uma simples frase resume essa situação de miopia: “eu produzo um site para os meus padrões cognitivos e estéticos, não para os padrões cognitivos e estéticos do meu cliente ou usuário”. É aí que a usabilidade entra como um fator vital de convergência e manutenção do foco nos resultados. Para isso, servem as metodologias de usabilidade. Através delas, eu mudo drasticamente a perspectiva de sucesso do meu projeto, porque o ponto de partida do planejamento passa a ser neutro, uma perspectiva que pode ser vislumbrada por todos os envolvidos: a perspectiva do usuário final, que está inserida no contexto do meu negócio. Parece simples, não? Mas não é. No auge das pontocom, muita gente apontava o Business Plan como Santo Graal do sucesso na Web. Sim, o plano de negócios é fundamental, mas sozinho não resolve os problemas e não aponta as inconformidades de um projeto no quesito interface com o usuário. Estejam certos de que metodologias de usabilidade no planejamento delimitam e amarram pontos estratégicos do projeto. Está ce ntrado na sua experiência de uso! Vantagens? Muitas, qualitativas e quantitativas. Relacionamos as principais:

Criamos um ponto de convergência fundamental para todos os profissionais envolvidos.

Criamos uma documentação de desenvolvimento e planejamento factíveis para todos os envolvidos no desenvolvimento do projeto.

Criamos um ponto de vista isento: não é a visão do cliente, não é a visão da equipe de desenvolvimento. É a opinião do client e, do usuário.

Eliminamos os conflitos de modelos mentais.

Elegemos prioridades.

Dimensionamos com grande precisão a verba e os esforços a serem investidos no projeto.

Auxiliamos decisivamente no dimensionamento da infra-estrutura de hardware e conectividade para o projeto.

Apontamos antecipadamente onde podem surgir os gargalos da infra-estrutura de hardware, conectividade e sistemas.

Eliminamos retrabalho nas fases seguintes de produção: criação de layout, recorte e programação.

Diminuímos em pelo menos 30% o tempo de desenvolvimento.

Dimensionamos os recursos a serem empregados na fase de pós-lançamento e administração do projeto. Resumindo: as chances de sucesso de um projeto desenvolvido com metodologias de usabilidade são muito maiores. Isso é válido para qualquer momento do seu negócio, quando um projeto em ambiente online é implementado. 2 – Usabilidade nas fases de pós-lançamento e durante o ciclo de vida do negócio, produto/serviço ou projeto: Depois do lançamento: haja o que eu houver, não perca o foco no usuário. Após o lançamento do projeto, diversos “momentos” podem surgir. Desde a mais simples aferição de metas e resultados para futuros re-investimentos e correções de rumo, até a necessidade de localizar problemas dos mais diversos. Aqui entram em pauta os famosos testes e as



análises heurísticas de usabilidade. Muito importante é reforçar que aqui já conhecemos bem melhor o nosso usuário e que há variáveis que nos permitem focar os testes. Após o lançamento, o usuário real irá validar nosso planejamento. Mas entram aqui outros fatores... O universo está em constante mutação e como não poderia deixar de ser, tudo dentro dele muda também. As interfaces Web evoluem e os hábitos dos usuários se modificam. Aplicar testes nos momentos em que precisamos fazer correções de rumo é de suma importânci a. Não pense que pode substituí-los através de questionários, por exemplo. É hora de aferir as variáveis que o usuário não pode, digamos, “deturpar”. Além de medir o desempenho ao longo do tempo, testes e análises de usabilidade podem nos indicar como podemos diversificar e flexibilizar nossa interface. Criar novos processos, deixar a navegação do usuário mais livre, realocar links internos, revalidar a taxonomia (nome e hierarquia dos botões). Também existe um fator de exaustão estética, muito conhecido pelos publicitários: a mente do usuário cria filtros e obstáculos cognitivos. Ou seja, a mente não reaprende processos já automatizados e ao mesmo tempo bloqueia mensagens subliminares. Difícil, não? Ao mes mo tempo em que bloqueia o novo, o usuário não aceita mais o antigo. Vantagens de se trabalhar com testes e análises de usabilidade no decorrer do “ciclo de vida do projeto”:

Aferição de resultados: atingimos nossas metas?

Validação de novas estratégias.

Dados precisos para reengenharia do projeto.

Dados precisos para redirecionamento da estratégia e do projeto

Descoberta de novos usuários (não previstos no planejamento inicial).

Correção e localização de problemas na interface ou no sistema.

Dados que possibilitam a mensuração do ROI do projeto.

Resumindo: se você quer uma medida de ROI para seu projeto Web, seja ele qual for, uma intranet, portal, extranet, aplicativo, comércio eletrônico, enfim... Qualquer projeto implementado em ambiente WWW, faça análises através de metodologias de usabilidade. Valide seus investimentos e recursos empregados através da Análise e Teste de Usabilidade. Encerrando os tópicos teóricos do nosso curso, vamos passar à parte prática. A partir de agora, vamos montar um briefing e um planejamento de projeto, utilizando técnicas de usabilidade. Esse é o nosso próximo passo.



3- Implementando metodologias de usabilidade na fase de Briefing e Planejamento da solução

Como um projeto nasce e é desenvolvido a partir de conceitos de usabilidade.

Digamos que nós realmente vamos montar um briefing user centered ( briefing centrado no usuário) do nosso projeto que vai se somar às informações sobre o negócio, mercado e etc. E esse briefing user centered começa com um procedimento que chamamos Levantamento e Análise de Requisitos do Projeto. Certo? Assim, começamos a definir todas as variáveis que entrarão em nossa análise. As variáveis que vão compor nosso cenário. Preste atenção a estes termos: cenário, cena. Daqui para frente, utilizaremos uma série de termos que são muito familiares para os profissionais que constroem roteiros e story boards para filmes, por exemplo. No Levantamento e Análise de Requisitos do Projeto entram:

Definição de usuários Primários Secundários Terciários

Análise do Contexto de Uso

Definição de Benchmarks para o projeto

Análise de Tarefas

Análise do Legado

Definição de Requisitos do Sistema Vejam que em muitos casos, vocês não necessariamente seguirão uma ordem: definição de usuários, depois Contexto de Uso e etc. Por questões metodológicas ou circunstanciais, o benchmark pode iniciar o projeto, ou a Análise do Legado. Se vocês trabalharem nessa ordem, contudo, garanto que verão o planejamento deslanchar muito bem. As informações vão chegar no momento certo e nas etapas corretas, gerando um fluxo de documentação muito conciso e que atende a todo o escopo de profissionais que participam do projeto. Neste ponto, preciso fazer uma observação: muitos especialistas em usabilidade e design podem divergir e inverter a ordem dos procedimentos. Há profissionais que preferem levantar os requisitos do sistema (recursos tecnológicos) primeiro, por exemplo. Não necessariamente incorrem em erros por isso. Mas no nosso curso especificamente, vou colocar as coisas linearmente. Além de considerar o modelo ideal para projetos reais, acredito que também o seja para o aprendizado da metodologia e sua assimilação. Aqui, vamos “vestir a camisa” do usuário, ou seja, partimos da ótica que o usuário terá sob o sistema e sua interface. Se delimitarmos tecnologias e recursos como primeira etapa, por exemplo, corremos alguns riscos. O principal deles é começar a planejar tudo a partir de recursos tecnológicos disponíveis para o projeto. Errado propriamente não está, mas a tecnologia disponível pode muito bem entrar como uma restrição lá no final do planejamento. Nesse caso, buscamos uma solução ou uma conciliação – uma saída para o impasse. E em 90% dos casos, é sempre possível encontrá-la, sem que o projeto deixe os parâmetros fundamentais de usabilidade de lado ou, em outras palavras, deixe de partir da perspectiva da experiência do usuário. Ou pode acontecer que os recursos tecnológicos determinem não uma restrição, mas exatamente o seu contrário. Vamos supor que ao pesquisar soluções de tecnologia, eu descubra que existem recursos perfeitamente viáveis para expandir ou flexibilizar meu projeto que eu inicialmente desconhecia. É uma possibilidade factível e realmente ocorre em muitos casos. Bem, mas vamos ao que interessa: Pessoal, resumindo, através das metodologias de usabilidade, eu consigo:

Um planejamento bem feito vai determinar o que eu quero/devo fazer e o que eu posso fazer no meu projeto.

Planejamento bem feito significa documentação concisa, fluxo de informação eficiente entre a equipe e um projeto super bem amarrado e sinérgico.

Entendido? Então, vamos explicar parte por parte como montamos o nosso Briefing User Centured



Definição de usuários Usuário primário? Ë o Protagonista da nossa cena, do nosso cenário. Ë o cliente. O usuário primário é aquele que potencialmente vai utilizar o sistema e lidar com suas interfaces. Primeiro, definimos um segmento e depois a persona. Na persona, entram características como modelos mentais, parâmetros culturais, hábitos, restrições (até físicas) e limitações (pouco, médio ou nenhuma familiaridade com interfaces tecnológicas, por exemplo). Estamos criando um personagem, literalmente. Aqui, é importante uma observação: nas pesquisas de mercado tradicionais, não há pesquisa ou levantamento de modelos mentais, por exemplo. Na definição de usuário, estamos um passo a frente. Então, não confundam o escopo que as pesquisas tradicionais apresentam (perfil de consumidor ou público-alvo - importante mas não suficiente para se tratar de usabilidade) com o perfil de usuário Usuário Secundário. Nosso coadjuvante, fundamental para o ciclo de vida do projeto. Quem administra o sistema? Publica informações, atualiza o site, colabora ou gerencia processos para que o usuário primário encontre informações atualizadas exatamente onde deveriam estar. Quem é a pessoa por detrás do sistema? Quem responde emails, recebe o feedback dos usuários e mantém as rotinas em dia? É ele, o usuário secundário. Pode ser um editor, gerente de conteúdo, webmaster, pode ser uma equipe ou pode ser apenas um estagiário. Não importa, sem ele o avião não vai para a pista e não decola. As interfaces de administração, bem como suas rotinas vão determinar todos os recursos que devem ser empregados no seu gerenciamento. O trabalho não termina na homologação do site. Ao contrário: é aí que ele começa. O desenvolvimento das interfaces de colaboração e gestão DEVE passar pelo mesmo planejamento de arquitetura da informação, design e infra-estrutura tecnológica aplicado à interface do usuário primário. Sem feedback gerencial, seu projeto está condenado à morte prematura. Site não atualizado é abandonado pelo usuário primário. O usuário secundário é fundamental no ciclo de vida das iniciativas o nline. Pode e deve ser incluído nos testes de usabilidade. Usuário Terciário. Surpresa, “põe água no feijão, temos visita!” O usuário terciário dificilmente aparece assim de cara, na fase de planejamento. Assim como mapeá-lo e diferenciá-lo do usuário primário não é tão fácil. O usuário terciário é aquele visitante que pode se tornar bem freqüente no seu site, assinar sua newsletter, utilizar seus serviços, mas estar completamente fora do perfil previsto pela equipe de planejamento. Para que vocês entendam, aí vai um exemplo bem comum. Vamos supor a seguinte situação hipotética: eu desenvolvo um portal vertical para uma empresa de convênios de saúde voltado à comunidade médica em geral, oriunda de várias especialidades, com serviços, notícias, dicas e promoções. Como parte da minha estratégia voltada a esse público, mantenho todo conteúdo de notícias e newsletter abertos a médicos que não atendem pelo convênio, deixando o acesso restrito através de senha e login apenas o conteúdo de serviços e relacionamento operacional. Quem é o meu usuário primário? Membros da comunidade médica, afiliados ou não à empresa de convênios. Quem é o meu usuário secundário? A equipe de administração do site, que elabora as newsletters, atualiza todas as informações, dá suporte e atende as solicitações feitas através do portal. Quem é meu usuário terciário? O elemento surpresa. Baseando-se no fato de que a internet é um território aberto e livre, inclusive aos sistemas de busca, vamos supor que após 6 meses do lançamento do portal, eu descubra no meu cadastro de newsletter, pessoas comuns, pessoas com boa cultura, profissionalmente atuantes em áreas de saúde adjacentes à medicina, terapeutas, fisioterapeutas e etc. Estes serão os meus usuários terciários, que eu poderei considerar no ciclo de vida do meu projeto. Esses usuários devem ser diferenciados como uma comunidade específica. Podem ser tratados como importantes formadores de opinião, mas não pertencem à comunidade médica, propriamente. Os objetivos de comunicação são diferentes, portanto é importante diferenciá-los. Pois é óbvio que não posso tomar decisões estratégicas baseadas no feedback deles. Análise do Contexto de Uso Mantenham uma coisa em mente: não se fala em usabilidade de sistemas e interfaces digitais sem 3 variáveis fundamentais: usuário, contexto de uso da interface e cenário.



“Contexto de uso” e “Cenário”: o que seriam? São todos os fatores externos à interface em si que determinam e influenciam a interação do usuário com a dita cuja. Vamos lá: O Cenário é a infra-estrutura tecnológica, fundamental para que a interação com o nosso sistema aconteça:

Tipo (s) de conexão (s) utilizada (s) pelo usuário;

Hardware, suporte ou interface dura: computador, PDA, celular e etc;

Softwares: navegador e sistema operacional, recursos presumidos na máquina do usuário;

Infra-estrutura do sistema: toda a infra contratada ou adquirida para hospedar as aplicações;

Plataforma e recursos escolhidos para desenvolver e suportar (operacionalizar) a estratégia online;

Local de onde o usuário acessa o sistema e a interface (casa, trabalho, telecentro, Lan House e etc);

O Contexto é a situação ambiental imediata e a motivação do usuário:

Motivação, a tarefa principal ou objetivo que motiva o usuário a acessar o sistema (ler notícias, acessar serviços específicos, fazer compras, consultar saldos e etc).

Periodicidade do acesso: quantas vezes por dia, semana ou mês, o usuário provavelmente acessará o sistema.

Horário em que o usuário provavelmente acessará o sistema.

Duração e complexidade da tarefa principal, por quanto tempo o usuário permanecerá no sistema, executando uma tarefa-chave (finalizando uma compra, consultando informações e etc).

Respondidas as questões acima, eu tenho um contexto bem definido que pode, eventualmente, ser testado através de um protótipo, mas principalmente estabelecer metas de usabilidade. Pessoal, recapitulando, primeiro eu defino meus usuários primários e secundários, depois os coloco em um contexto bem delimitado de uso que, por sua vez, está dentro de um “cenário”. Vale aqui uma observação: usuários primários e secundários estão inseridos em contextos diferentes. Embora o cenário possa ser comum a ambos, já que é a plataforma tecnológica que “suporta” o sistema. Lembrem-se de que o usuário terciário é o elemento surpresa. Não vamos contextualizar sua interatividade com o sistema, antes que ele se apresente. Caso estejamos falando de uma reengenharia do projeto, aí sim, o usuário terciário ganha um capítulo especial, talvez até ocupando um espaço maior em nossas estratégias. É possível encontrar e delimitar estes perfis de acesso pelas ferramentas de auditoria de sites.



Definição de benchmarks para o projeto: O que é um benchmark? Eu respondo “devolvendo” a pergunta: Para que reinventar a roda? Afinal, podemos aprender muito com os erros e acertos alheios. O benchmark é um estudo comparativo entre estratégias semelhantes que nos levam às seguintes conclusões:

Pontos fracos e fortes da concorrência (como posso enfrentar a concorrência, quais as ameaças e os riscos do segmento).

Identificação de oportunidades (para inovar, preencher espaços, desejos e necessidades dos usuários).

Quais os erros que eu não posso/devo cometer em meu projeto? O benchmark pode ou não se focar em quesitos de usabilidade. Pode ser um estudo comparativo de modelos de negócios, por exemplo. Assim, o benchmark pode ser feito antes da definição de usuário e contexto. Pode ser feito como start up para o planejamento. Contudo, se o foco é o desenvolvimento de um projeto online centrado na experiência do usuário, a seqüência em que nos propomos a executá-lo neste curso é esta: definição de usuários e contextos antes, benchmark depois. A razão desta escolha é simples: eu quero identificar quais as melhores práticas de usabilidade entre iniciativas online semelhantes à minha. Eu posso inclusive, realizar testes de usabilidade com interfaces semelhantes a que eu desejo desenvolver. Através do benchmark, eu realinho meu planejamento. O processo é muito simples e lógico: eu monto o processo reverso ao planejamento: faço uma decupagem em estratégias que já foram implementadas e se encontram em operação. Posso fazer isso, com lojas virtuais, por exemplo. Ficou claro? Resumindo:

Eu vou testar usuários e contextos em laboratório (testes de usabilidade) semelhantes ao que eu planejei no meu projeto. Ou: Eu vou planejar uma análise heurística (uma análise feita por especialistas em usabilidade, sem testes com usuários em laboratório) de interfaces em condições semelhantes àquela planejada por mim.

O benchmark auxilia na construção do cenário de uso e pode redefinir e validar todo o planejamento anterior. (contexto e cenário - condições e situações ambientais, bem como motivação).



Análise de Tarefas: Bom, digamos que este é o ponto crucial do nosso planejamento. Vamos agora ver na prática como funciona a aplicação das definições de usabilidade. Para isso, definimos no máximo 3 tarefas que o usuário tem que completar em um dado número de etapas e num certo limite de tempo para que o nosso sistema atinja suas metas de usabilidade. Qual é a tarefa fundamental do nosso projeto? A tarefa que o define, qu e marca seu objetivo estratégico e de comunicação? Exemplo: Projeto: livraria virtual Macro-tarefa: usuário finalizar compra de livros, pesquisando, selecionando, efetuando seu cadastro e finalizando a compra em ambiente totalmente online, sem o auxílio de telefone ou catálogo impresso. Vejam que para o usuário completar a tarefa, ele deverá completar com sucesso pelo menos 4 sub-tarefas:

Pesquisar título, autor ou área de interesse;

Guardar os títulos escolhidos numa “cesta de compras”.

Efetuar ou atualizar cadastramento de dados bancários e/ou cartão de crédito.

Confirmar recebimento de senha (proveniente do cadastramento) e finalizar a compra, emitindo comprovante. Nós vamos então estruturar uma árvore de tarefas, marcando cada ponto completado para o usuário. A cada tarefa, devem ser previstas mensagens de erro e de acerto. A cada tarefa é necessário prever o cancelamento da operação, falhas no sistema e na conexão, bem como desistência do usuário. A análise de tarefas é feita através de um fluxograma e assemelha-se a um Mapa de Navegação. Cada tarefa deverá conter as condições de eficiência, eficácia e satisfação do usuário. Insisto: feedbacks do sistema têm que ser mapeados e previstos nessa fase. Também podemos prever onde haverá uma flexibilização das tarefas. No nosso exemplo, vamos supor que o usuário se “lembre” de que deseja pesquisar e comprar mais um item. Ele deve voltar ao sistema de pesquisa antes de fechar a compra, sem perder o que já selecionou. Tarefas críticas com relação à segurança de dados também devem ser previstas no nosso fluxograma de tarefas, como, por exemplo, o consagrado: “esqueci minha senha”, teclados virtuais, frases lembretes e etc. Tudo, mas tudo mesmo, deve ser mapeado nessa fase. Ainda no nosso exemplo: minha livraria poderia, hipoteticamente, oferecer uma revista eletrônica literária, outras lojas, enfim. Mas enfim: repare que eu defini o processo de compra finalizado como fundamental para estabelecer metas de usabilidade e as características de um projeto centrado na experiência do usuário.



Análise do Legado A análise do legado é uma etapa fundamental quando, por exemplo, estamos criando um canal para informações pré-existentes. Muito comum no caso da reengenharia de portais, na criação de extranets e intranets corporativas com grande fluxo de informação que já existe. De que maneira esse conteúdo legado (pré-existente) entra no projeto, sem desviar a proposta principal, sem atrasos consideráveis no cronograma? Bem, temos aqui dois desafios:

O primeiro deles é incorporar o conteúdo legado no projeto novo. O segundo é transferir toda uma lógica de arquivamento para o sistema novo.

Isso pode afetar a usabilidade do sistema? Pode. Fundamentalmente. Em primeiro lugar, por pior que seja um sistema antigo, toda a estrutura cognitiva do usuário já se adaptou a ela. A aceitação do novo, por melhor que ele possa parecer, gera uma nova curva de aprendizado, uma espécie de reorganização mental para os grupos de usuários. A adaptação ao novo implica em vencer uma resistência interna. Do ponto de vista metodológico, vamos então inserir no nosso planejamento centrado no usuário uma técnica conhecida como CARD SORTING (CS). Muitos outros autores e especialistas vão colocar o CS em outros pontos do projeto. Às vezes, bem no início. O CS, resumidamente, é uma técnica de classificar e organizar o conteúdo. Não necessariamente uma técnica para conteúdos pré-existentes, mas muito eficiente quando existe um legado significativo que deve nortear o projeto. O CS também é fundamental para validar taxonomias, ou seja, a nomenclatura dos links de um site. Os nomes que constam do menu e indicam links. Como nós aplicamos o CS? Existe o CS aberto e o CS fechado. Particularmente o CS aberto, considero quase como um brainstorming. Recomendo, na maioria dos casos o CS fechado. Card Sorting Aberto Aqui, nós trabalhamos com um grupo maior de usuários primários e secundários. O grupo é selecionado (normalmente um número bem maior, em torno de 10 ou mais usuários). O analista de usabilidade informa os usuários do escopo do teste: nomear o conteúdo que entrará no planejamento do novo sistema e classificá-lo em categorias. Reunidos os usuários em pequenos grupos, numa sala de teste, distribuímos cartões em branco. Os usuários devem “nomear” o c onteúdo, agrupando-os e anotando essa classificação em uma tabela. É como organizar uma estante. Feito isso, eles devem atribuir nomes a esses grupos. O analista recolhe então os cartões e tabelas com as nomenclaturas e classificações anotadas pelos grupos. O resultado é compilado (existem softwares especiais para isso). Nós teremos então um resultado estatístico e um mapeamento de como o grupo de usuários primários e secundários organiza o con teúdo legado. Podemos então, planejar os links e a inserção do conteúdo no novo sistema, com estes dados.



Card Sorting Fechado No CS fechado, o especialista em usabilidade e o arquiteto de informação criam as nomenclaturas e pedem aos usuários que apenas organizem o conteúdo dentro dessa classificação apresentada. O resultado é compilado estatisticamente e da mesma forma, cria-se um mapeamento da classificação do conteúdo legado. Através do Card Sorting, colocamos a informação no local determinado estatisticamente como mais lógico pelo grupo de usuários. O Card Sorting nos permite avaliar o impacto do legado sob o sistema novo. E organiza a forma como a informação pré-existente entrará na estrutura nova. Resumindo:

No CS aberto, eu permito que o grupo de usuários crie todo o sistema de classificação do conteúdo, inclusive nomeando as categorias de conteúdo (nome dos links). No CS fechado, eu crio as categorias de links, dou nome a estes links e peço que os usuários apenas distribuam e atribuam nomes para o conteúdo dentro dessas categorias que eu, como AI ou profissional de usabilidade, criei.

Quando utilizar o Card Sorting? Para planejar ou para validar o planejamento feito. Quando houver um grande fluxo de informações a serem assimilados pelo novo sistema e pela nova interface. Quando houver polêmica e miopia com relação à classificação e entrada de novos conteúdos no site.

Casos em que o Card Sorting pode “salvar” um projeto: Grandes intranets e extranets; Ferramentas que disponibilizam o cruzamento de informações; Sites e aplicações com grande fluxo de atualizações e armazenamento de informações; Quando houver a assimilação, em portais pré-existentes, de novos departamentos e modelos de negócios que impactarão e criarão redundância de informações no projeto como um todo.



Definição de Requisitos do Sistema: Pessoal, finalmente. Depois que o nosso usuário foi exaustivamente “estudado e testado” quanto às suas preferências, nós podemos validar os requisitos tecnológicos do sistema e sua interface. Nós vamos, então, projetar toda a infra necessária para que o nosso projeto se torne realidade. Essa decisão, normalmente, é tomada anteriormente em algum aspecto como, por exemplo, a plataforma de desenvolvimento. O que nós vamos fazer agora é gerar uma documentação completa que vai validar tudo o que fizemos anteriormente. O trabalho de planejamento é exatamente isso: eu coloco uma peça e ajeito as demais. O que são os requisitos do sistema? É todo o produto conclusivo (documentação) dos procedimentos que realizamos anteriormente:

Definição de usuários, do contexto de uso, cenários, tarefas principais do usuário, absorção do legado e recursos tecnológicos validados para que o sistema suporte toda a estratégia.

Com a definição dos Requisitos de Sistemas nós temos agora; UM ESCOPO COMPLETO. Um escopo completo é composto de: Descrição da estratégia; Requisitos do sistema; Objetivos e metas da estratégia. Podemos, então, iniciar o desenvolvimento do nosso sistema e a criação das nossas interfaces. O próximo passo é mostrar a vocês um exemplo completo do Escopo com base na experiência do usuário.



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

1. A primeira definição oficial de usabilidade aplicada pela comunidade internacional de web designers e especialistas em 1991 foi

“...conjunto de atributos de software relacionado ao esforço necessário para seu uso e para o julgamento individual de tal us o por

determinado conjunto de usuários”.

2. O componente do Standard de ISO 9241-11 descreve usabilidade como sendo a eficácia, eficiência e satisfação com a qual os

públicos do produto alcançam objetivos em um determinado ambiente.

3. Eficácia diz respeito ao conforto do usuário ao completar a tarefa de maneira completa e correta.

4. Na eficácia, o foco é no processo, na eficiência, o foco é no resultado.

5. Em 1988, a definição mais oficial para Usabilidade é a descrita no componente do Standard de ISO 9241-11 (1998).

6. Jakob Nielsen descreveu seis heurísticas básicas fundamentais para que um site atinja seus objetivos de usabilidade.

7. Os preceitos universais de usabilidade não mudam nunca. Nem com a evolução tecnológica.

2- Assinale a alternativa falsa:

1. O usuário não só precisa interagir com o sistema em ambiente seguro, como também se sentir seguro, através de avisos e

sinalizações.

2. Privacidade do usuário deve ser uma preocupação do especialista em usabilidade, ainda que esta questão não seja citada em muitos

manuais, livros e na própria norma ISO.

3. O benchmark pode, na grande maioria dos casos, substituir o Card Sorting na definição da hierarquia dos menus.

4. Flexibilizar a navegação é dar mais de uma opção ao usuário para encontrar o conteúdo desejado.

5. Na primeira fase da Internet, quando houve a chamada “bolha pontocom”, a usabilidade ainda não era um termo incorporado aos

projetos online.

6. O ROI da usabilidade é bem melhor aferido se investimos em planejamento centrado no usuário desde o início.

7. Pesquisas de marketing e opinião podem substituir testes de usabilidade porque fornecem, através de uma amostragem bem maior,

todos os elementos e dados que os testes e análises heurísticas.

3- Fazem parte da análise de requisitos do projeto as seguintes etapas, exceto:

1. Definição de Usuários Primários.

2. Análise do contexto de uso.

3. Card Sorting

4. Protótipo de papel

5. Análise de tarefas

6. Definição de Benchmarks

7. Análise do Legado

4- Dentre os exemplos abaixo, assinale aquele que claramente define um usuário secundário:

1. Gerente de conteúdo.

2. Usuários de Blogs.

3. Usuários do Orkut.

4. Administradores de listas de discussão.

5. Usuários de intranets corporativas.

6. Um cliente que “paga” pela construção e manutenção do site.

7. Usuário de webmails como Yahoo e hotmail.



5- Assinale as frases em que há uma correta relação entre causa e efeito.

1. A motivação do usuário para acessar o sistema junto com as características da infra-estrutura tecnológica disponível é o fator

determinante e principal causador dos problemas mais sérios de usabilidade.

2. O benchmark sozinho, como um processo de engenharia reversa isolado de outros fatores, pode induzir a erros no planejamento

online, pois não leva necessariamente em consideração o contexto e a periodicidade de uso, sendo, portanto, superficial se

comparado a um teste com usuários.

3. Um erro na análise de tarefas não compromete o mapa de navegação porque são processos diferentes e separados.

4. O Card Sorting pode salvar um projeto onde existe um grande volume de conteúdo legado e muita informação a ser publicada, por

isso é fundamental aplicá-lo em grandes intranets e extranets corporativas.

5. Em sites com ferramentas de busca muito eficientes é desnecessário o Card Sorting, já que ele só é válido na construção de menus.

6. A descrição do cenário completo de uso não é suficiente para iniciar o projeto, pois ela ainda não inclui testes de usabilidade.

7. Entender e mapear a interação do usuário secundário durante todo o ciclo de vida dos projetos online é indispensável porqu e ele

será responsável pela renovação do conteúdo e feedback humano aos usuários primários e terciários.

modulo i arquiteturainformacaousabilidade_thaiscampas

Technology