modulo iv 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 IV

"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 IV IV - Usabilidade na fase de Lançamento/Pós-lançamento do projeto 4.1 – Introdução Ok. Missão cumprida. A equipe de desenvolvimento terminou o trabalho e o projeto foi lançado com todas as expectativas propiciadas pelas metas de sucesso que vocês estabeleceram lá no planejamento. Lembram-se? Pois bem, agora é a prova dos nove. Muita água já rolou e é hora de aferirmos se o rumo do barco foi mesmo correto. Há um ponto crítico ao qual devemos prestar uma atenção especial: é quando saímos do wireframe para o design e programação. Ajustes de direção de arte e eventuais questões técnicas que não foram levantadas nos Requisitos do Sistema podem exigir correções inesperadas e afetar sensivelmente as metas do projeto. Portanto, chegamos ao ponto em que devemos fazer um balanço da fase de desenvolvimento e PRINCIPALMENTE, da documentação de A.I. e sistemas. Fique atento: é necessário atualizar e conferir as datas de alteração das documentações. NORMA DE OURO: Não jogue nada fora. Não apague nada. Rascunhos reprovados, mapas e wireframes posteriormente alterados duas, três ou mais vezes – nada, absolutamente nada, vai fora. O que não está escrito e documentado fatalmente se perderá, ou seja, é um elo perdido no tempo. E acreditem: vocês precisarão resgatar dados importantes em algum momento específico do ciclo de vida do projeto. 99,99% de chance. O histórico de criação e produção é um tesouro em se tratando de usabilidade. E mais, um histórico bem documentado e arquivado permite que vocês troquem membros ou a própria equipe que trabalha no projeto sem que as metas ou a identidade do projeto se percam ou mesmo se “personalizem” de acordo com a mudança da equipe que o administra. Fazendo isso, vocês estão trabalhando com metas de usabilidade, com certeza. E é por isso que defendo desde o primeiro módulo que vocês façam dos preceitos e das práticas de usabilidade uma filosofia de trabalho para todas as horas e necessidades. Portanto, providências a tomar logo após a homologação do projeto:

A - Revejam toda a documentação, revisando datas e certificando-se da metodologia correta de arquivamento da mesma. Essa metodologia é livre, vocês podem criar ou utilizar uma que já conheçam. O importante é que seja eficaz, apontando fases, datas e motivação das alterações. Dica: criar um critério para nomear arquivos baseada em datas. B – Marquem PRINCIPALMENTE o histórico de modificações nos mapas de análise de tarefas e navegação. A cada nova modificação, documentem quem solicitou, quem executou, a razão e a data da solicitação, bem como as conseqüentes alterações nos wireframes. O Mapa de Navegação e o Mapa com a Análise de Tarefas são verdadeiros guias para os administradores e futuros gestores. Se vocês não arquivarem corretamente estes documentos, correm um risco sério de, numa futura reengenharia, serem obrigados a realizar um mapeamento reverso do projeto. Vocês vão gastar pelo menos 30% das horas totais previstas para reengenharia ou redesign na tarefa de recuperar o mapeamento. C - Terceira providência: redigir o MANUAL de ATUALIZAÇÃO do projeto para os usuários secundários, lembram-se deles? Descrevam neste documento a periodicidade, normas, procedimentos, contatos técnicos, enfim: tudo, absolutamente tudo que for necessário ao controle da identidade do projeto. Se vocês não observarem este aspecto, todas as metas de usabilidades irão por água abaixo. Sem identidade, sem meta de usabilidade. Ok?

4.2 – Usabilidade na fase de lançamento/ pós-lançamento

4.2.1 - Acompanhamento e análise dos indicadores de desempenho Organizaram a documentação do projeto? Ok, prontos para fase 2! Quais os meus indicadores de desempenho das metas de usabilidade que estabeleci ao longo do meu planejamento? Essa é a primei ra questão que devo saber responder. Levando em consideração que eu posso ter estabelecido variáveis muito particulares baseadas nas características essenciais de meus usuários primários e secundários e de acordo com a missão e objetivo principal do meu projeto, eu posso ap ontar para vocês “n” indicadores de desempenho que podem ser tanto quantitativos quanto qualitativos ou ainda ambos ao mesmo tempo.



Mas não é só isso. Não basta definir variáveis, é preciso que elas sejam mensuráveis e de preferência haja uma ferramenta ou metodologia de mensuração. Roteiro: O que estou mensurando, quando e como será mensurado? Bem lógico e apropriado, não? Então para fechar a explicação, vamos a um exemplo bem direto: indicativo de sucesso para um site de comércio eletrônico. Vou mensurar semanalmente o número de compras finalizadas por usuários únicos no meu site. Do conjunto de compras não finalizadas, vou analisar a causa: abandono do processo, falha no sistema e etc. É possível faze-lo? Sim. Como? Através de um aplicativo instalado no servidor como o WebTrends, por exemplo. Vamos supor que eu tenha colocado como meta a finalização de 90% das cestas de compra a partir de certo ponto da tarefa. Se eu mensurar 40% de compras fechadas dentre as compras iniciados vou necessariamente encontrar um problema de usabilidade? Sim e não. Pode indicar que o desempenho está abaixo do planejado? Sim, pode. O indicador “compra finalizada por usuário único” pode não ser suficiente para apontar um problema de usabilidade, mas pode levantar uma suspeita ou motivar um teste com usuários. O acompanhamento dos indicadores de desempenho de um site exige uma análise completa do contexto de todo o projeto, mas é uma arma poderosa para levantar a suspeite de algo pode estar errado com a meta de usabilidade. Junto com a análise de desempenho, façam análises heurísticas e periódicas e, sobretudo, estimulem o usuário a opinar. Utilize ferramentas de relacionamento como cadastros e newsletters no caso de sites, principalmente. Portanto, pessoal, mais um check-list para colar na geladeira:

Quantifique suas metas de usabilidade para cada usuário. Se não o fez antes, faça agora.

Certifique-se de que possui ferramentas para mensurar e acompanhar metas de usabilidade.

O que vai mensurar, em que periodicidade e como.

Cruze dados de análise de desempenho do projeto como um todo, com as metas de usabilidade.

Cheque as suspeitas com testes heurísticos antes de partir para testes com usuários.

Fique de olho nas falhas técnicas (problemas no sistema).

Escreva uma documentação com normas e procedimentos de acompanhamento das metas e inclua no Manual de Atualização. Vocês podem ser extremamente detalhistas em seus acompanhamentos. Podem cruzar ações de marketing com efeitos na infra-estrutura do site. Todo dado pode ser útil e levar a uma conclusão mais completa e precisa, SE e somente SE vocês estabelecerem MÉTODOS e CRITÉRIOS de análise. Entendido? Fiquem atentos para não meramente especular sobre resultados, o que é bastante comum quando se trata de evocar estatísticas em nome de uma conclusão pretensamente científica. Só cruzem dados quando tiverem certeza do que estão fazendo. Bem, também devo enfatizar que as metas quantitativas, isto é, aquelas que podem ser expressas numericamente, devem ter uma base contextual bem fundamentada. Como vocês chegaram a estes números ou índices? O que está embasando a formulação dessas metas do ponto de vista qualitativo? Percebam que vocês fecham o ciclo de um “raciocínio de usabilidade”, ao criar um acompanhamento extremamente criterioso e que deve ser sempre questionado à medida que o ciclo de vida do projeto evolui.

Vocês estão finalmente criando uma estratégia de usabilidade completa. Ou seja: abrange todo o ciclo de vida do seu projeto. Pessoal, de que forma podemos organizar ou “tabelar” a evolução desses indicadores? Simples, podemos criar tabelas comparativas, gráficos mostrando a evolução das métricas, relatórios e até as famosas apresentações em power point (vocês podem apresentar a seus clientes, por exemplo). Aconselhamos que você faça dessa documentação um adendo importante do Manual de Atualização, pois, por sua vez, ele centraliza todos os procedimentos relacionados à rotina do seu projeto.



Logo abaixo, mostraremos um roteiro básico de como organizar toda essa informação sobre indicadores de desempenho que vocês podem sofisticar ou adaptar de acordo com a necessidade. Reparem que vocês vão resgatar muita informação do planejamento. Vamos lá:

1. Descrição do Cenário de Uso (que você já elaborou no planejamento). 2. Aspectos críticos dos Requisitos de Sistemas que podem interferir na questão da usabilidade. 3. Descrição dos Usuários (primários e secundários - essa informação também está documentada no seu planejamento). 4. Descrição das tarefas fundamentais ou key features que cada usuário ou grupo de usuários primários e secundários deve executar

atribuindo-se uma medida de desempenho (em geral estabelecemos um tempo ideal para a execução da mesma). 5. Método, ferramenta ou procedimento de aferição da métrica escolhida. 6. Quem é responsável pela avaliação dos indicadores de desempenho. 7. Periodicidade da avaliação. 8. Relatórios Conclusivos e tipo de documentação a ser arquivada – tabelas, gráficos, textos, o que vocês acharem produtivo.

Última observação: interfaces HC e interfaces Sociais pressupõem heurísticas específicas e, principalmente, metas de usabilidade igualmente específicas. Portanto, estabeleçam essa diferenciação em suas respectivas documentações.

4.2.2 – Mensuração do ROI (return on investiment)

Lá vem ele: o tal do ROI, que em bom português significa nada mais nada menos que retorno sobre investimento. O ROI pode ser uma métrica, resultado de uma fórmula matemática com variáveis palpáveis e indicativas sobre o negócio. O pessoal acostumado com a linguagem de negócios e administração está bem familiarizado com o termo. Voltando ao nosso caso, a usabilidade pode influenciar essas variáveis ou até se tornar uma delas. Mas, em poucas palavras, o que vai ser provado mesmo é o quanto valeu a pena fazer o projeto acontecer e quão acertada foi a iniciativa de ter uma estratégia de usabilidade no seu planejamento.

Fez diferença?

Valeu à pena?

O projeto trouxe muito mais retorno em termos de resultados práticos e mensuráveis com uma estratégia de usabilidade?

Como eu posso ou pude aferir isso (ao longo do projeto e no momento atual do ciclo de vida do meu projeto)?

Uma forma bem comum de mostrar que a usabilidade traz resultados é mostrar o quanto ela pode corrigir rumos e prevenir decisões erradas. Isso é bem visível quando realizamos testes com usuários. Eles nos mostram, muitas vezes com sugestões espontâneas durante as entrevistas com os especialistas, o que pode ser melhorado ou até um novo ponto de vista sobre a interface testada, idéias e observações fora do escopo que ascendem uma luz no fim do túnel, por assim dizer. MAS... como simplesmente corrigir não é exatamente o que queremos mostrar como vantagem essencial ou ROI principal da estratégia de usabilidade bem implementada... Podemos e devemos afirmar que uma estratégia de usabilidade articulada, criativa, assertiva, pode revelar ou dar origem a grandes “sacadas” por parte dos desenvolvedores ou gestores do projeto. Ou seja, o fator usabilidade pode ser a grande virada dentro de um projeto inicialmente pobre em diferenciais inovadores (é o chamado ROI obtido pela identificação e implementação de diferenciais competitivos). Vamos aos exemplos para deixar essa questão clara como água cristalina da fonte? A seguir analisamos duas situações básicas – na primeira o ROI é obtido através de uma ação corretiva desencadeada por um teste de usabilidade com usuários primários e, na segunda, o ROI é a descoberta de um valor que é agregado ao projeto.

ROI - resultado corretivo: Site de comércio eletrônico com desempenho abaixo do esperado. Relatório de visitação do site não aponta suspeita de quedas de conexão ou falhas no sistema. Cenário aferido: usuários iniciam processo de compra, mas não o finalizam. O resultado do teste de usabilidade feito com usuários primários mostra que botões mal posicionados fazem com que a maioria deles “feche” o “sistema” de forma involuntária, sem que haja informação explícita sobre como retomar o processo. Feita a correção, o índice de “perdas” de processos de compra é reduzido em 90%. Logicamente, o resultado financeiro do s ite será bem melhor. Observem que se após uma simples correção, o faturamento crescer x reais, então eu tenho um ROI bem claro apontado como um crescimento no faturamento. Nesse caso um retorno sobre o investimento no teste de usabilidade e na correção feita.



Vamos supor, se todo o processo corretivo custou 14 mil reais, o site vendia 20 mil reais por mês e após as modificações passa a vender 40 mil, no primeiro mês, a consultoria de usabilidade já se pagou e ainda deu “lucro”. Dobrou o faturamento. Vejam que é um exemplo beeem simples, mas igualmente elucidativo. Muitas vezes, vocês vão encontrar situações mais complexas, com múltiplas variáveis problemáticas aliadas aos erros de projeto mais comuns: infra-estrutura tecnológica insuficiente ou inadequada e até certa miopia com relação a aspectos mercadológicos. Mas em termos práticos, é isso aí.

ROI – diferencial competitivo: Protótipo de MP3 player a ser lançado no mercado. Vocês gostariam de saber se o design, a proposta de interface do software embutido agrada e exatamente como os usuários vão utilizá-lo: ligar o aparelho no som do carro, ligar no computador, baixar as músicas via computador ou usar como dispositivo pessoal. Vocês querem testar as situações de uso do aparelho e aferir algo mais sobre este contexto de uso. A decisão é fazer um teste monitorado com grupos de usuários, deixando os aparelhos com potenciais compradores durante um período maior de tempo, como se fosse um test drive. Os usuários vão relatar experiências utilizando o aparelho livremente porém em toda a sua potencialidade. Após a realização do teste e entrega dos relatórios, vocês descobrem que os usuários gostariam de utilizar o mesmo aparelho para gravar conversas, aulas e entrevistas e transferi-las para seus computadores pessoais. O novo recurso é então implementado com as devidas correções no planejamento estratégico e transforma o nosso MP3/ gravador em sucesso de vendas . Reparem que o produto ganhou um novo recurso e um novo apelo. A experiência com o teste de usabilidade revelou um nicho, uma oportunidade a ser explorada. Qual é o ROI neste caso? Qual é o ROI da descoberta de um novo nicho, algo que o usuário deseja e influirá definitivamente na escolha de um produto e consequentemente em sua competitividade? Claríssimo: um produto de sucesso que venderá muito mais e trará muito mais retorno financeiro. Se eu vendesse três mil aparelhos no primeiro mês sem o recurso de gravação de voz, com o recurso eu atendi um público maior, vendi 6 mil. O ROI, neste caso, corresponde ao incremento de 100% nas vendas do nosso tocador/gravador de MP3.

Pois bem pessoal, os exemplos são simples, não? Mas para lá de eficazes em definir retorno sobre investimento. Nos dois casos, investir em usabilidade, testes, estratégias e tudo mais, determinou um ganho financeiro ou evitou uma perda. Porém... Há casos em que o ROI não é tão tangível e nem repercute financeiramente de maneira tão explícita. Vocês podem, com técnicas de usabilidade, melhorar a produtividade de uma intranet, utilizar testes com usuários ou análises heurísticas para selecionar outros fornecedores na área de tecnologia da informação. O ROI aqui é qualitativo, ganho de qualidade, produtividade e satisfação. Não achamos que o ROI necessite de uma documentação e uma mensuração tão constante nas rotinas do projeto quanto o acompanhamento dos indicadores de desempenho. Mas é extremamente válido como histórico e como um argumento consistente e decisivo no momento em que seja preciso justificar, para gestores e clientes, a utilização de uma metodologia centrada na experiência do usuário, seja ela qual for. ROI: neste caso, usem e abusem dos dados que tiverem, sem contra-indicação.

4.2.3 – Emissão final da documentação de Arquitetura da Informação do Projeto (A.I.) Roteiro essencial deve preservar o histórico do projeto. O que deve conter a documentação final de A.I. de um projeto centrado na experiência do usuário? Toda a matriz do planejamento, que consiste em:

Fase I: Estudo&Levantamento, Criação&Planejamento:

1. Brainstorming e Bechmarking com apresentação de Idéias e Benchmarks; 2. Compilação de pesquisas de mercado ou levantamentos estratégicos***; 3. Escopo do projeto, contendo sua definição e delimitações (sinopse); 4. Objetivo estratégico e motivação principal do processo de desenvolvimento; 5. Cenário de Uso;



6. Descrição dos usuários primário, secundário e, se possível, terciário; 7. Contexto de uso do aplicativo que será desenvolvido (não existe usabilidade sem contexto de uso!!!!!!); 8. Funcionalidades essenciais ou Key Features (funcionalidades inerentes aos objetivos estratégicos do projeto), com textos descritivos

e detalhados; 9. Requisitos do Sistema – descritivo técnico da infra-estrutura, plataformas e tecnologias necessárias para viabilizar o

desenvolvimento, lançamento e funcionamento do projeto. 10. Descritivo das metas de usabilidade para usuários primários e secundários.

*** aqui vale uma observação rápida sobre o Card Sorting: muitos procedimentos de CS acontecem nessa fase pois é uma metodologia que ajuda a definir prioridades já que afeta a disposição das categorias de informação. Nesse caso, compilem os dados e os coloquem como um relatório final, junto a “estudos e levantamentos”. Vocês devem estar imaginando: “mas isso faz parte do planejamento de marketing... Pesquisa de mercado? Isso é marketing”. Ë isso mesmo pessoal, lembrem-se de que a documentação de A.I. é a documentação universal do projeto que integra as equipe que trabalham em um projeto Web. A documentação de A.I. é, por assim dizer, o fiel da balança, uma documentação que precisa ser entendida por toda a equipe envolvida: gestores, gerentes, designers, programadores... Enfim, todo mundo que trabalha no projeto, colaborando em algum momento. Confidencialidade em acordos e parcerias. Acordos de Confidencialidade: é muito importante falar deles pois estamos manipulando informações estratégicas, cujo conteúdo não deverá jamais “vazar” para a concorrência ou para quem não interesse. Vocês devem tratar a documentação de A.I. como um documento su jeito aos contratos de confidencialidade – os tão conhecidos Non Disclosure Agreement (s) ou NDA(s). Levem isso a sério e arquivem todos os NDA(s). Eles devem ser exigidos formalmente, inclusive, para usuários que participem de testes. Em geral, os brasileiros tratam este importante dispositivo legal de proteção intelectual com certa displicência, mas em países onde os direitos autorais e brigas por patentes levam empresas a acordos milionários, o NDA é indispensável ao início dos trabalhos. Formato dos documentos: vocês são livres para escolher o formato dos documentos, desde de que atendam o que foi pedido acima. Prefiram formatos universais, softwares específicos para criar planilhas e fluxogramas em geral geram arquivos com formatos não aceitos por qualquer PC que rode num sistema operacional mais comum. Pessoalmente, nunca fujo do MS Office. Análise de tarefas: na documentação final a análise de tarefas entra junto com mapas e wireframes. Protótipos e Testes com Protótipos: também entram na segunda parte da documentação. Versão 1.0, ; 1.1; 1.1.2 e etc.... Guardem “pastas” separadas atribuindo nomenclaturas do tipo:

ProjetoH_versão1.0_30setembro2006. ProjetoH_versão2.0_31outubro2006.

Isso – claro - se houver realmente versões e não simples modificações. Guardem também as atas de reuniões e elaborem documentos de homologação (para quem não estiver familiarizado com o termo, homologar é o mesmo que aprovar). Pessoal, observe que eu não menciono cronogramas, ok? Isso faz parte do escopo da Gerência de Projetos - uma documentação e metodologia de projetos incluem o que estamos produzindo, mas não vamos abordar esse ponto, por não ser o objetivo do curso e, portanto, não perder o foco. Cuidado com o excesso de documentação, não exagerem. Documentação Final de A.I. é uma compilação da matriz do planejamento, não uma enciclopédia! Tem gente que exagera e acaba se perdendo em descritivos sem nenhuma utilidade. Não caiam na armadilha da burrocracia corporativa recorrente.



Fase II: Projeto&Protótipo:

1. Matriz de Conteúdo ou Matriz de Escopo; 2. Análise de Tarefas/ ***; Mapa de Navegação; 3. Wireframes; 4. Propostas de leiaute; 5. Protótipo funcional ou paper prototyping (protótipo de papel); 6. Relatório dos testes de usabilidade e análises heurísticas; 7. Validação das metas de usabilidade (descritivo consolidado).

*** mais uma observação sobre o Card Sorting que pode entrar como uma metodologia de validação nesse estágio do Mapa de navegação.

Acredito que esse item ficará mais claro com exemplos, mas é sempre bom relembrar.

A Matriz de Escopo ou Conteúdo é mais comumente construída como uma tabela. Essa tabela deve conter a descrição de todos os links e sublinks do site, ou no caso de uma aplicação, uma tabela com o nome das tarefas e sua descrição. Especificamente em web applications (softwares desenvolvidos em ambiente Web), a Matriz de conteúdo vai auxiliar na Análise de Tarefas, ajudando a roteirizar detalhadamente as

tarefas que o usuário executará.

Recomendamos que a Matriz de Escopo ou Conteúdo contenham elementos que vocês considerem particularmente importantes para um determinado projeto. Vocês podem, por exemplo, documentar as horas de produção ou programação de cada funcionalidade. Podem detalhar essas horas, indicando horas de design, horas de programação, de gerência de projetos e etc. Podem, também, indicar quem são os

responsáveis pelo conteúdo dos links descritos e com que periodicidade eles devem ser atualizados.

Enfim, não existem modelos engessados de Matriz de Conteúdo, mas adaptações de acordo com cada situação. Analisem que tipo de informação vocês podem vir a necessitar no futuro. Gestores e equipe de atualização mudam de tempos em tempos e a identidade do projeto tem que permanecer, pois é justamente dela que partem as novas idéias e os novos rumos. Vamos mostrar a lguns exemplos de Matriz de

Escopo ou Conteúdo, para que vocês possam sentir o quanto este tipo de documentação pode ser ajustado às situações:

EXEMPLO A:

Na Matriz abaixo, foi apresentado todo o serviço e detalhamento dos serviços e consultorias envolvidos no projeto, além do tipo de recursos

de sistema e interface que, neste caso, nosso portal vertical disponibilizará para seus usuários.

Funcionalidade Descrição Metodologias Envolvidas Recursos Tecnológicos

Total de Horas de produção do projeto

HOME

Página Principal com chamada para notícias, cadastro para Newsletter, banner interativos e busca de arquivos e links no site.

Arquitetura da Informação; Planejamento Editorial; Conceito Visual (Webdesign); Espaço para Ações Promocionais; Revisão e Webwriting; Manual de Atualizaçao.

Tratamento de Imagens; Montagem HTML; JavaScript; Recursos de Flash; Programação Dinâmica com acesso a Banco de Dados

60

Links e Conteúdos Institucionais

Link(s) estático(s) que partem da HOME com conteúdos em texto e imagens sobre Missão, Visão e Objetivos.

Arquitetura da Informação; Planejamento Editorial; Conceito Visual (Webdesign); Revisão e Webwriting; Manual de Atualizaçao.

Tratamento de Imagens; Montagem HTML; JavaScript; Recursos de Flash.

20



Biblioteca de Arquivos para Download

Link(s) Dinâmico(s) que partem da Home para download de arquivos de texto e imagem (fotos).

Arquitetura da Informação; Planejamento Editorial; Conceito Visual (Webdesign); Revisão e Webwriting; Manual de Atualizaçao.


60

Links Úteis

Link(s) Dinâmico(s) que partem da Home para indicação de sites, portais e fontes diversas na Internet sobre o assunto abordado no portal. Sugerimos que haja um uso estratégico, com espaços promocionais definidos que possam ser negociados em termos comercias, parcerias de conteúdo e comentários e cunho editorial.

Arquitetura da Informação; Planejamento Editorial; Conceito Visual (Webdesign); Espaço para Ações Promocionais; Revisão e Webwriting; Manual de Atualizaçao.


60

Enquetes

Link Dinâmico que pode partir da HOME ou permanecer nela localizada. A decisão de seu posicionamento e recursos agregados pode ser decidida a partir do grau de importância de seus relatórios. O link pode aceitar desde uma pesquisa simples até um questionário completo, motivado por uma estratégia promocional.

Arquitetura da Informação; Planejamento Editorial; Conceito Visual (Webdesign); Espaço para Ações Promocionais; Revisão e Webwriting; Relatórios; Manual de Atualizaçao.


40



EXEMPLO B: Na Matriz abaixo, foi feita uma apresentação diferente, por tarefas de desenvolvimento. Esse tipo de Matriz também é interessante e se integra bem aos documentos de gerência de projeto. Este descreve horas de planejamento e desenvolvimento e fornece o valor das horas em termos financeiros, supondo que o valor da hora de trabalho = 51 reais. Vejam como a documentação de A.I. é importante

até como uma planilha de investimento. Reparem como a documentação de A.I. pode ser versátil!

Etapa de Trabalho Descrição: Planejamento: Desenvolvimento: Total: Valor (horas trabalhadas):

Home

Página de entrada do site - deverá expor todas as opções de navegação para o usuário. 8

18 x (R$51,00) R$ 918,00

Conteúdo Institucional

Dados gerais sobre a Instituição. 8

24 x (R$51,00) R$ 1.224,00

Cadastro, Transações e Mailing

Comunicação centralizada, a cadastro, com e acesso a quaisquer transações com a Empresa.

50 180 x (R$51,00) R$ 9.180,00

Produtos e Serviços

Acesso aos serviços e produtos do Empresa- preparação de toda a estrutura tecnológica para prestar serviços online. 20 80

100 x (R$51,00) R$5.100,00

Conteúdo Editorial

Acesso a todos os conteúdos do Empresa, incluindo conteúdo da Revista da Empresa, seja qual for o formato ou a origem. Preparação para newsletter. 30

100 x (R$51,00) R$5.100,00

Busca Avançada

Campo para busca direta por palavra-chave ou grupo relacionado. 40

140 x (R$51,00) R$ 7.140,00

Sistema de Publicação e Administração

Sistema de Administração do Site com recursos de Colaboração. 70

220 x (R$51,00) RS11.220,00

*Manual de Atualização

Padronização, planejamento e documentação do projeto editorial e R$ 3.000,00



tecnológico. Senhas, serviços, parceiros e procedimentos.

Total de horas 236 546

782 x (R$51,00) R$ 42.015,00

EXEMPLO C: Na Matriz abaixo, repare o detalhamento do conteúdo dos links que fornece várias orientações para a produção de um wireframe. Esta Matriz de escopo pode ser facilmente adaptada para um Manual de Atualização, informando, por exemplo, instruções para atualização do

conteúdo de um portal de vendas, que deve ser constantemente alterado de acordo com promoções e campanhas sazonais.

Funcionalidade Descrição Banners Atualização Depto/ Responsável

HOME

Página Principal com espaço para produtos em promoção e novidades. Espaço para banner de fornecedores e campanha de promoção de vendas da loja. Deve também chamar para cadastramento e disponibilizar um espaço para mecanismo de buscas no site.

01 banner grande horizontal Até 06 banners pequenos.

Diária ou de acordo com promoção de vendas e campanhas sazonais.

Depto de Comunicação e Mkt Renata Abrantes [email protected] 011 3333-3333 (ramal 246)

Produtos e Serviços

Página que expõe as categorias de produtos e serviços. Pode conter espaço para chamadas e breves sinalizações para o usuário além da busca e banners, embora o espaço para propaganda seja menor que na home..

01 banner grande horizontal. Até 02 banners pequenos

Diária ou de acordo com promoção de vendas e campanhas sazonais.

Depto de Vendas e Depto de Comunicação e Mkt. Murilo Alves [email protected] 011 3333-3333 (ramal 192) Renata Abrantes [email protected] 011 3333-3333 (ramal 246)

Cadastro

Cadastro de usuários, em 3 etapas. Deve informar quais dados são indispensáveis e deixar clara a política de privacidade da empresa. Não esquecer de perguntar sober o envio de emails com promoções da loja (opt in, opto ut)

01 banner grande horizontal. Quando necessário.

Depto de Comunicação e Mkt Renata Abrantes [email protected] 011 3333-3333 (ramal 246)

mailto:[email protected]






Minhas Compras

Cesta de compras do usuário. Este link é estratégico e deve ser protegido por senha, a ser enviada ao usuário no momento do cadastramento. As compras devem ficar armazenadas, de modo que o usuário possa interrompê-las e finaliza-las depois. Isso é particularmente importante no caso de problemas na conexão ou no sistema de compras do site.

01 banner grande horizontal. Verificação diária para atualizar avisos aos cadastrados.

Depto de Vendas e Depto de Comunicação e Mkt. Murilo Alves [email protected] 011 3333-3333 (ramal 192) Renata Abrantes [email protected] 011 3333-3333 (ramal 246)

Fale Conosco

Deve conter todas as informações de contato da empresa, inclusive telefones e suporte. Ë importante deixar ao usuários opções de ajuda e de contatos com a empresa em caso de necessidade de suporte técnico à finalização da compra. Neste link, também podemos disponibilizar dados de contato para serviços de pós-venda.

01 banner grande horizontal. .

Verificação diária para atualizar avisos aos clientes.

Depto de Vendas / Depto de Comunicação e Mkt e Depto de suporte Murilo Alves [email protected] 011 3333-3333 (ramal 192) Renata Abrantes [email protected] 011 3333-3333 (ramal 246) Catarina Cortez [email protected] 011 3333-3333 (ramal 240)

Percebam como podemos criar Matrizes de Escopo específicas que atendem as nossas necessidades no ponto do ciclo de vida em qu e estamos com relação ao projeto. A cada momento, vamos precisar discriminar variáveis diferentes: conteúdo entregue ou não; conteúdo interno ou conteúdo de fornecedor, link dinâmico ou estático, presença de banners ou não; administração por interface específica ou não, nomes e

contatos dos responsáveis pela atualização, e por aí vai.

Bom, vamos falar agora sobre Análise de Tarefa e Mapa de Navegação.

Estes documentos estão sujeitos a várias alterações durante o ciclo de vida do projeto. Eles, em geral, são desenvolvidos inicialmente de forma bem engessada, isto é, condicionam o usuário a um roteiro com opções bem mais limitadas. E é normal que seja assim. Primeiro engessamos, depois flexibilizamos a interface. Se há um excesso de flexibilização logo no início, vários problemas de usabilidade podem surgir ocasionados pela falta de controle na produção das interfaces. Então, não estranhem o fato de que essa documentação vai ser bastante alterada durante ao longo do projeto.

Como emissão final, vocês devem guardar a documentação mais recente. É comum haver alterações após testes de usabilidade em protótipos e até alterações em leiautes e wireframes sem que a documentação anterior, o mapa de navegação, tenha sido alterada. Não permitam que isso aconteça. Uma única alteração desencadeia a atualização de toda a documentação emitida anteriormente à interface ou wireframe modificado. Ok? Ficou claro?








Esse aspecto precisa estar bem entendido e assimilado. Caso contrário, quando procurarem o auxílio do planejamento de A.I ., vocês vão obter um resultado desastroso e ficarão perdidos sem saber se o mapa contem ou não as mudanças que o projeto sofreu até a emissão f inal dos documentos.

O segredo aqui é documentar sempre, atualizar sempre. O que não se escreve e não se guarda, não existe.

Bom, vamos lá. Dois exemplos, um de Mapa de Navegação e outro de Análise de tarefas:

Exemplo 1 (Mapa de Navegação)

Pessoal, este é um mapa bem simples de uma intranet corporativa. Este mapa deve fazer parte de uma documentação final de A.I. Atualizado

com a versão final, obviamente.



Exemplo 2 (Análise de Tarefas)

Esta é o esquema de Análise de Tarefas de uma aplicação. Veja a sinalização de cores como é importante, a tarefa é divida em 3 etapas, distribuídas ao longo de um processo de customização e personalização da interface de um sistema que controla a automação de uma residência.

As mesmas observações feitas para o Mapa de Navegação valem aqui. Com bastante rigor, pois aqui há a questão do suporte ao usuário. Será absolutamente necessário que a Análise de Tarefas esteja atualizada em seus mínimos detalhes ou não haverá condição de treinar uma equipe de suporte. E muito menos, futuros testes de usabilidade. Os testes de usabilidade se utilizam de documentos como esse. Então , fiquem

atentos.

Depois dos Mapas, temos os Wireframes. Os wireframes também precisam ser atualizados de acordo com o leiaute que foi homologado pelo gestor do projeto ou cliente. Muitas vezes, são feitas mudanças no leiaute que não são repassadas para emissão final da documentação de A.I. Não permitam que isso aconteça.

Nesse ponto, vale abordar o assunto: wireframe não é leiaute. É um projeto de interface. Portanto, não construam wireframes que comprometam a liberdade da direção de arte. O arquiteto de informação deve trazer sugestões funcionais para os leiautes, mas deixar livre a

criação da identidade visual.

Vamos a um exemplo que mostra o wireframe e como ficou a proposta de leiaute.



WIREFRAME:



LEIAUTE:



Reparem que existem diferenças entre o leiaute e o wireframe. Isso é bastante comum quando a direção de arte e o design começam a estabelecer soluções estéticas para a interface. Não se assustem, portanto, com alterações. Para que elas não afetem questões de usabilidade, é preciso um manter as metas iniciais sempre em discussão, como pontos fundamentais a serem seguidos. Documentem todos os leiautes apresentados, pode ser um arquivo de power point, e junte a eles um documento de homologação que pode ser uma cartinha. Pode parecer exagero, mas é bom manter um documento de homologação, uma cartinha de “aceite” do responsável pela aprovação das etapas de produção do projeto. O restante da documentação é composta pelos protótipos, se houver, e pelos relatórios dos testes e análises de usabilidade. Mantenha um documento com METAS de USABILIDADE DO PROJETO, tal como a cartinha de homologação. Afinal, se as empresas documentam Missão, Visão e tudo mais, porque não documentar metas de usabilidade... Fica aqui a sugestão. Fase III: Manual de Atualização:

1. Projeto Editorial, se for o caso; 2. Análise de Tarefas/ Mapa de Navegação finais; 3. Informações sobre atualização – periodicidade, tipo de conteúdo e gestores/colaboradores; 4. Informações e manuais técnicos de sistemas de atualização e toda infra-estrutura envolvida; 5. Manual de Marca; 6. Regras para utilização de espaço publicitário; 7. Regras de suporte ao usuário; 8. Normas de atualização; 9. Normas de Usabilidade; 10. Informações sobre senhas e usernames. 11. Relatórios periódicos de visitação.

Bom, pessoal. Vocês são livres para elaborar o Manual de Atualização no formato que acharem mais confortável e racional para consulta. Podem imprimir ou mantê-lo em formato eletrônico. Podem ainda, manter um diretório com vários documentos, sem reunir tudo em um mesmo documento. Enfim, é preciso estar atento às características e necessidades de cada projeto. O Manual de Atualização é particularmente interessante e essencial aos projetos centrados na experiência do usuário porque nesses projetos há uma padronização imposta pelas metas de usabilidade e pela importância da fase de planejamento. Mais uma vez, devemos ressaltar o quanto é importante manter a identidade do projeto, não permitindo que a troca de equipes durante o processo, afete de maneira inesperada os resultados de usabilidade. Quando se perde o controle, fica muito difícil manter o compromisso com qualquer tipo de meta. E perde-se, portanto, todo o esforço feito em direção a um resultado consistente. Na queremos aqui fechar as portas para as oportunidades e para a renovação. Muitas vezes, uma variável externa e fora do controle da equipe afeta fundamentalmente os rumos de um projeto, as vezes, bastante tempo após o lançamento do mesmo. Já citamos aqui a presença do usuário terciário, aquele que aparece de surpresa e acaba por reivindicar um “espaço” para si. Este tipo de usuário pode até, em alguns casos, substituir o usuário primário. Recomendamos, então que se façam novas avaliações de usabilidade para aferir oportunidades que possam estar sendo perdidas junto a um público até então “desconhecido”.



Recapitulando o roteiro da documentação final de A.I. Fase I: Estudo&Levantamento, Criação&Planejamento:

Brainstorming e Bechmarking com apresentação de Idéias e Benchmarks;

Compilação de pesquisas de mercado ou levantamentos estratégicos;

Escopo do projeto, contendo sua definição e delimitações (sinopse);

Objetivo estratégico e motivação principal do processo de desenvolvimento;

Cenário de Uso;

Descrição dos usuários primário, secundário e, se possível, terciário;

Contexto de uso do aplicativo que será desenvolvido (não existe usabilidade sem contexto de uso!!!!!!);

Funcionalidades essenciais ou Key Features (funcionalidades inerentes aos objetivos estratégicos do projeto), com textos descritivos e detalhados;

Requisitos do Sistema – descritivo técnico da infra-estrutura, plataformas e tecnologias necessárias para viabilizar o desenvolvimento, lançamento e funcionamento do projeto.

Descritivo das metas de usabilidade para usuários primários e secundários.

Fase II: Projeto&Protótipo:

Matriz de Conteúdo ou Matriz de Escopo;

Análise de Tarefas/ Mapa de Navegação;

Wireframes;

Propostas de leiaute;

Protótipo funcional ou paper prototyping (protótipo de papel);

Relatório dos testes de usabilidade e análises heurítsticas;

Validação das metas de usabilidade (descritivo consolidado).

Fase III: Manual de Atualização:

Projeto Editorial, se for o caso;

Análise de Tarefas/ Mapa de Navegação finais;

Informações sobre atualização – periodicidade, tipo de conteúdo e gestores/colaboradores;

Informações e manuais técnicos de sistemas de atualização e toda infra-estrutura envolvida;

Manual de Marca;

Regras para utilização de espaço publicitário;

Regras de suporte ao usuário;

Normas de atualização;

Normas de Usabilidade;

Informações sobre senhas e usernames.

Relatórios periódicos de visitação. Para o “formato” dessa documentação, algumas dicas: Documentação de Projeto tem que ser universal. Acessível e compreensível por todos os envolvidos. Dessa forma:

Escolham formatos de gravação e salvamento de arquivos universais, e que de preferência estejam integrados ao pacote padrão do Office da MS. Gravem imagens em gif* ou jpeg* – elas podem ser abertas no Internet Explorer, ou qualquer outro navegador, mesmo em máquinas que operem com outros sistemas operacionais que não o Windows. Básico, mas muita gente se esquece disso, causando atrasos e confusões na emissão da documentação, geração de muitos arquivos com nomes diferentes e que não “carregam” em todas os computadores.



Para produzir documentação, evitem softwares complicados que exijam aprendizado específico. Existem programas para montar Mapas de Navegação, alternativas para o Viso (MS) e há até quem prefira usar o Corel Draw e Photoshop para montar wireframes. PADRONIZEM. Não queremos aqui fazer apologia da Microsoft e suas ferramentas, nem de nenhuma outra empresa como Adobe ou Macromedia. Mas, é aquela história: o designer usa uma ferramenta, o programador usa outra e o gerente de projetos uma terceira. A bagunça é inevitável. Embora não pareça, há um retrabalho considerável causado por esse tipo de desorganização. Definam um roteiro para a documentação já no início do projeto, como vai ser o processo de arquivamento e troca entre a equipe e como vão ser “nomeados” os arquivos: “wire_HOME_Projetox_versao1.ppt “ Vocês podem inserir a data, por exemplo, “wire_HOME_ProjetoX_versao1_06maio06.ppt”. E por aí vai. Local no servidor, nome das pastas, senhas de acesso aos arquivos e etc. Lembrem-se que as normas de usabilidade em um projeto centrado na experiência do usuário leva em consideração o usuário secundário que são vocês, pessoal! Se não estiverem presentes em todo o ciclo de vida do projeto, pelo menos no desenvolvimento vocês vão atuar. Pensem nisso. Considerem-se como usuários secundários no tempo em que estiverem trabalhando no mesmo. Ok? Outra coisa importantíssima: a emissão final da documentação de A.I. não acontece no final do planejamento e sim um pouco antes do lançamento ou um pouco depois. Isso porque é preciso documentar alterações de leiaute e alterações no sistema que podem ter ocorrido durante o desenvolvimento. Tudo, tudo devidamente registrado como já disse antes.

O que não está escrito e documentado não existe. 4.2.4 – Validação de Objetivos e Metas do Projeto

Preparem-se, após o lançamento, para a validação das metas iniciais de usabilidade. Aquelas metas que vocês estabeleceram lá na fase d e planejamento com contexto, cenário e etc. O que vai ser importante a partir de agora – e que vocês não poderiam mensurar adequadamente

antes - é uma nova variável de usabilidade: a freqüência de uso.

E o que seria isso, exatamente? Trata-se da freqüência ou periodicidade com que o usuário lida ou interage com a interface/ sistema que acabamos de lançar. A freqüência de uso pode determinar ou apontar desde inadequações até problemas de usabilidade e acessibi lidade que

permaneciam ocultos aos testes com protótipos, por exemplo.

Vou dar algumas razões para que isso aconteça. A primeira delas refere-se ao processo de aprendizagem e criação de rotinas na mente do usuário. Uma vez que o usuário domine os recursos de um sistema, ele o “estressará”. Ou seja, se no início, uma interface engessada era razoavelmente confortável, a freqüência de uso vai exigir uma flexibilização da interface, vai exigir “atalhos”, tendendo a se tornar menos lógica

e mais intuitiva. Interessante, não?

E por que isso acontece? Acontece porque existe um sistema mental de associações que se traduz na forma como a mente humana opera e trabalha a informação para criar um repertório de conhecimento, que por sua vez possui uma sintaxe muito específica e pessoal . É o chamado

“modelo mental”.

Trocando em miúdos, cada ser humano possui um processo de linguagem interno que gera uma espécie de pré-conhecimento. Esse pré-conhecimento vai atuar sobre a forma como cada usuário interage, absorve e armazena novas informações, atuando nos processos de aprendizagem. Reparem que é um processo de retro-alimentação.

Se vocês ainda têm dúvida, vamos dar um exemplo definitivo: observem o desenvolvimento de uma criança. Por que as crianças aprendem rápido, pessoal? Por que, no caso do aprendizado de novos idiomas, quanto mais velho mais difícil? Por que as pessoas idosas são teimosas?

Por que, conforme a idade avança, maior é a resistência ao novo ou as novidades?

Porque o repertório mental ou a chamada “experiência de vida” atua filtrando vigorosamente e pré -rotulando toda o estímulo considerado

“inédito”, “estranho” ou simplesmente “desconhecido”.

Pessoal, o repertório e o pré-conhecimento são tão fortes na mente humana que chegam a “moldar” a percepção da realidade do indivíduo.

Por isso, a periodicidade da exposição do usuário ao processo de interação é tão importante e só vai poder entrar como variável agora, depois do lançamento, quando o nosso projeto passará a fazer parte do repertório ou pré-conhecimento dos nossos usuários.



Então, será o momento de validação das nossas metas e objetivos. Se vocês optarem por realizar testes de usa bilidade neste momento (logo

após o lançamento) recomendamos que façam testes levando em consideração a freqüência de uso.

Outra coisa muito importante: testem as funcionalidades das Interfaces Sociais e da IHCs, separando-as metodologicamente. Se houver a possibilidade de estabelecer metas e objetivos diferenciados para ambas, melhor ainda. Na hora de validá-las podemos estabelecer testes

diferentes com metodologias diferentes. Ou até, escolher se vamos testar ambas ou apenas uma.

Fica aqui sugestão de executar testes de monitoração durante períodos mais longos, ou seja, eleger usuários “beta testers” baseados em perfis que atendam o planejamento inicial e fazer com relatem suas experiências metodicamente. Se for um pouco antes do lançamento, porém, executem os testes em laboratório já com a interface e sistemas prontos.

Até aqui, já teorizamos bastante e introduzimos o conceito de freqüência de uso, como uma variável importante para a usabilidade NESTE ponto do ciclo de vida do projeto. No próximo tópico, vamos discriminar que testes ou análises podem ser utilizados para a fase de Controle da

Solução onde já há uma razoável decorrência de prazo após o lançamento do projeto.

4.2 – Usabilidade na fase de Controle da Solução Reparem, pessoal, quantas variáveis nós já introduzimos até aqui. A última delas, a freqüência de uso. Nesse momento do Ciclo de Vida do Projeto teremos a “prova dos nove”, quando o usuário vai estabelecer uma relação rotineira ou não com a interface/sistema que desenvolvemos e lançamos. Até aqui, tudo se resumia a uma proposta de experiência centrada no usuário que construímos com bases metodológicas bem seguras: descrevemos grupos de usuários, cenário e contexto de uso. Estabelecemos os requisitos do sistema e realizamos testes e prototipação. Tudo muito bem construído e estabelecido como objetivos e metas. Ok. Só que agora, temos o fator tempo. Vamos falar então especificamente sobre a validação disso tudo. Hora da onça beber água.

4.2.1 - Testes de Validação

Os testes de validação de metas de usabilidade vão ocorrer por dois motivos e essas metas em podem ser qualitativas ou quantitativas. Lembrem-se da definição de IS e IHC, ok? Também é necessário que vocês estabeleçam rotinas de verificação de resultados que são esperados pelos gestores do projeto. Na maior parte das vezes, o resultado do negócio é determinante para que se busque algum tipo de análise ou teste

que por sua forneça dados concretos e comprobatórios do sucesso ou fracasso das metas de usabilidade.

Assim sendo, a realização de um teste pode ser motivada pela detecção de um problema que em geral é aferido após um resultado financeiro ou estratégico medíocre, vendas fracas, visitação aquém do esperado e etc. Neste caso, nunca proponham ou preparem um teste sem que

existam resultados que o justifiquem.

Nunca contrate um teste sem encomendar antes uma análise de usabilidade que deve levar em conta o seu planejamento inicial. Uma simples ou nem tão simples assim, análise de usabilidade feita por especialistas pode ser mais adequada e tão ou mais eficaz para explicar a falta do cumprimento de metas e objetivos. Sempre levem em consideração: Planejamento Inicial x Realidade Atual.

Outra motivação para testes na fase de controle é a detecção de oportunidades e a exploração de novos nichos que podem redirecionar o projeto. Também é baseada em resultados consistentes. Vamos testar o que? Por quê? Temos mais visitas do que esperávamos, há um novo concorrente no mercado e desejamos nos diferenciar na busca pela preferência e pela hoje tão controvertida fidelidade do usuário. Ou ainda: queremos saber como a introdução de um recurso tecnológico inovador vai impactar no nosso projeto, neste momento.

Certo? Queremos ressaltar, nessa fase de controle, a importância da Análise antes que se aplique um Teste. Um teste mal aplicado, com relatórios que não respondem a uma dúvida concreta pode facilmente desmoralizar metodologias de usabilidade perante um gestor que esteve distante do processo de desenvolvimento, com resultados desconectados ao problema e pífios em termos de apontar novas ações,

oportunidades ou correções. E pior, podem mascar problemas que não tem origem na concepção da interface.

O uso da infra-estrutura, erros e bugs do sistema são variáveis a serem seriamente consideradas. Uma análise correta da situação pode indicar o rumo da investigação. Pensem nisso.



Vamos agora montar uma seqüência básica de planejamento para testes de controle e validação.

Roteirinho básico:

Analisar resultados (qualitativos ou quantitativos);

Realizar análise de acordo com o planejamento inicial;

Defina quais usuários vai analisar/testar (primários ou secundários);

Defina quais interfaces vai analisar/testar (IS ou IHC);

Realizar Análises de Usabilidade se for o caso, cruzando dados com o planejamento inicial;

Agregar a variável “freqüência de uso” aos testes;

Agregar variáveis tecnológicas aos testes;

Elaborar relatórios;

Propor soluções;

Implementar soluções;

Monitorar resultados após implementação das soluções;

Revalidação de novas metas se for o caso, após a implementação das soluções.

Testes de Usabilidade a serem aplicados na fase de controle da solução:

CS fechado;

Testes em laboratório, tarefas monitoradas com roteiro e tempo de observação bem definidos;

Teste com usuários beta testers;

Testes em laboratório com benchmarks ou cases concorrentes para definir preferências de usuários;

Testes com usuários para mensurar o impacto da inserção de novos recursos tecnológicos – pode ser feito através de promoções online, onde o usuário baixa um aplicativo, por exemplo, e o testa gratuitamente emitindo sua opinião sobre mesmo;

Pesquisas de opinião;

Algumas sugestões ou orientações de quando aplicá-los:

CS fechado: o Reclamação de usuários (conteúdos difíceis de achar ou acessar); o Análise de Usabilidade aponta problemas com taxonomia dos links; o Identificação de categorias de usuários terciários; o Implementação de flexibilização da navegação ou da execução de tarefas; o Reengenharia/ redesign/ reestruturação de conteúdo ou tarefas; o No caso de projetos editoriais: aquisição de novos colaboradores ou integração a outras publicações online; o Integração do legado (integração de dados e informações mais antigas aos sistemas novos que agora estarão

disponíveis em versão online).

Testes em laboratório, tarefas monitoradas com roteiro e tempo de observação bem definidos: o Resultados abaixo do esperado, vendas baixas (interrupção do processo de compra online, baixa visitação no site); o Reclamação direta e formal de usuários quanto à usabilidade; o Implementação de novos recursos em aplicações já existentes; o Reengenharia/ redesign/ reestruturação de conteúdo ou tarefas.

Teste com usuários beta testers: o Implementação de novos recursos; o Implementação ou integração com outros aplicativos ou serviços; o Testar novos recursos tecnológicos; o Excelente método para testar interfaces sociais e novos produtos.



Testes em laboratório com benchmarks ou cases concorrentes para definir preferências de usuários: o Pesquisar a concorrência; o Identificar nichos que a concorrência não preencheu; o Identificar perda de espaço, preferência e visitação; o Pesquisar a implementação de novos recursos tecnológicos na concorrência.

Testes com usuários para mensurar o impacto da inserção de novos recursos tecnológicos – pode ser feito através de promoções online, onde o usuário baixa um aplicativo, por exemplo, e o testa gratuitamente emitindo sua opinião sobre mesmo:

o O famoso: “faça o download da versão beta. Basta se cadastrar.”

Pesquisas de opinião: o Assemelha-se a uma pesquisa de mercado. Não chega a ser um teste, mas está longe de ser uma análise. Este vai

mais à fundo na questão da qualificação e identificação do usuário. Utilizado para validar usuários primários e terciários.

Há muitas outras aplicações desses testes e situações que podemos citar, mas estas são principais motivações para a realização de testes com usuários. Para exemplificar bem o que seria um estudo de usabilidade após o lançamento e durante uma fase de controle, vamos citar uma circunstância bem interessante e extremamente comum nos dias de hoje: a da reengenharia de conteúdo para grandes portais, sejam eles verticais (segmentados) ou horizontais (UOL, IG, Terra e etc). Reparem como hoje é bem mais difícil encontrar um conteúdo na net. Ou filtrar as informações relevantes e confiáveis. Ao mesmo tempo as interfaces sociais dos grandes portais amadurecem e proliferaram na forma de blogs, fotoblogs, videoblogs... Ou seja, a IS estimulou a produção de conteúdo por parte dos usuários e a informação circulante em meio digital multiplicou-se exponencialmente. Ao mesmo tempo, as IS expõem vulnerabilidades relativas às questões críticas de privacidade e segurança. Complicado, não? Tudo isso gera uma demanda para testes e análises de usabilidade em nível bem mais profundo, pois os gestores querem respostas para perguntas curtas, porém complexas que envolvem análise comportamental do usuário, estudo de modelos mentais e por aí vai. Por isso, recomendamos a vocês que não sigam receitas prontas de testes. Nem toda mulher pode vestir o manequim da Angelina Jolie. Nem todo homem pode vestir as roupas do Brad Pitt. Em termos de mídia, mercado, consumo e etc, nunca o INDIVÍDUO foi uma variável tão importante e relevante quanto agora, na Era da Informação.

Num passado bem recente (anos 90) era suficiente segmentar, hoje é preciso segmentar, customizar e personalizar. Portanto, entramos definitivamente na Era da Usabilidade, a Era da Persona.



4.3 – Usabilidade na fase de Evolução do Projeto

Bom pessoal, aqui a usabilidade entra como um fator de pesquisa criativa, de respaldo à inovação. É o momento da célebre frase: “O desafio da tecnologia é entregar o que promete”. Se antes nós validávamos nosso planejamento, é novamente hora de enfrentar o “papel em branco”. É hora de um novo briefing, de inovar e diferenciar-se da concorrência. Afinal o que seria do iPod e do Google se ambos não evoluíssem!? E do

Windows, então?

Vamos nos focar, assim, no que mais eu posso oferecer aos meus usuários. Como a usabilidade pode nos ajudar a tomar decisões e definir novas metas que influenciam significativamente nos retornos financeiros e na proteção ao investimento inicial que foi feito no projeto, lá atrás, quando comecei a rascunhá-lo?

Em muitos casos, já vamos encontrar benchmarks de sucesso. Portanto, é a hora da engenharia reversa em iniciativas de sucesso, ou seja, de destrinchar as interfaces que agradam ao usuário. Isso é feito reconstruindo-se a documentação de A.I. a partir da interface real que já está em

uso. No caso de um site, a reconstrução, por exemplo, do seu Mapa de Navegação.

É também o momento de estudar as grandes tendências do mercado de tecnologia da informação e comunicação. E é, principalmente, o momento de atentar para a utilização especifica que os usuários já deram às interfaces e recursos disponíveis na maioria das aplicações, dispositivos e interfaces. Fazendo isso, vamos encontrar quais os conceitos que irão nortear e influenciar definitivamente no avanço

tecnológico e no amadurecimento do uso das interfaces. Estamos, então, em busca de macro-tendências.

Vamos aos exemplos bem atuais:

Mobilidade – a mobilidade é uma necessidade básica do ser humano. Imagine carregar suas informações pessoais e profissionais consigo e ainda utilizar a mesma interface para comunicar-se? É o caso dos celulares com diversos recursos. E que agora ainda agregam o entretenimento, como fotos, vídeo e música? Sem fio, levinho e acessível financeiramente, e ainda vem com serviço agregado da operadora

que pode ser escolhida de acordo com preferências e capacidade de pagamento. Tudo isso pessoal, se resume a um conceito: mobilidade.

Globalização da informação – o Orkut e o Youtube que o digam. Tudo resultado da evolução das interfaces sociais. A internet não tem fronteiras e o mundo virou uma grande biblioteca que precisa ser organizada. O Google já se candidatou. Alguém mais se habilita? Além disso, as funções de mídia e comunicação pessoal estão se fundindo. Um resultado prático disso no mundo dos negócios é a recente batalha entre operadoras de telefonia celular e emissoras de TV, no Brasil: quem é o dono da receita publicitária sobre o conteúdo informativo e de

entretenimento transmitido para os aparelhinhos multimídia?

Mídia Pessoal – Aqui entra a necessidade de armazenar a informação que hoje trafega na Web com a maior faci lidade e a informação que é produzida pelo próprio usuário. A convergência das mídias para o protocolo IP faz com que dispositivos pessoais possam exibir conteúdos que antes eram apreciados coletivamente, como no caso da televisão.

Conclusão: vocês deverão identificar macro-tendências que os possibilitem analisar variáveis de usabilidade à luz desses grandes conceitos.

4.3.1 – Evolução da Matriz de Atualização

Aqui não há muito para se estender. Todo o feedback de um projeto deve ser utilizado como matéria-prima para inovar. A atualização do conteúdo e dos serviços de um site jamais pode ser feita ao sabor dos ventos. Vale uma dica de ouro. A principal variável que irá atuar é o

usuário terciário. Lembram-se? O chamado “fator surpresa”. Sua identificação pode determinar aspectos de inovação bem interessantes.

Outra norma corrente é que a Matriz de Atualização tem que ser revista a cada seis meses, é preciso que haja uma evolução do projeto editorial, mesmo quando falamos de lojas online. Uma boa pista é mensurar a visitação e as entradas nos links que estão expostos na página

principal, a chamada home.

Pode também acontecer de aferirmos a formação de comunidades que se constituíram em torno da nossa proposta. Quanto mais vocês se

comunicarem com seus usuários, mais elementos terão para fundamentar e justificar mudanças.



Novamente, um check-list básico para que vocês se comuniquem com seus usuários e identifiquem quando e quais mudanças devem

implementar:

Mantenham monitoração do acesso ao site, links preferidos e horários de acesso;

Atualização do cadastro de usuários anual;

Newsletter periódica;

Implemente mídias alternativas como podcasting e recursos como RSS;

Respeitem políticas de privacidade;

Mantenham uma equipe profissional para conteúdos informativos e estratégicos;

Mantenham uma grade periódica de atualização do conteúdo do site;

Renovação diária da Home;

Mantenham uma padronização, fidelidade ao projeto editorial sem, no entanto, ficar resistente às inovações e aos novos fornecedores de conteúdo;

Atualizem o Manual de Atualização a cada mudança;

Ofereçam conteúdos personalizados e atendem às necessidades dos usuários terciários que forem identificados;

Incrementem interfaces sociais que favoreçam a formação de comunidades;

Criem regras para a entrada de novos conteúdos e links, principalmente em grandes portais e não se esqueçam de documentá-las no Manual de Atualização;

Monitorem as ações da concorrência.

Cuidados especiais com os seguintes aspectos:

Conteúdos que nada tem a ver com os objetivos editoriais e/ou estratégicos do site – não agreguem nada simplesmente por agregar;

Não deixem que o usuário terciário tome conta da atenção de vocês, a ponto de se colocar como usuário primário acima dos objetivos do planejamento inicial – a menos, claro, que isso seja uma decisão refletida e bem embasada com a estipulação de novas metas;

Evitem que grandes portais inicialmente voltados a usuários externos de uma corporação acabem se tornando grandes extranets de grandes corporações que gerenciam internamente seu conteúdo.



4.3.2 – Mensuração periódica de ROI

O ROI deve ser mantido tal como foi descrito no início deste módulo. Entendam que retorno sobre o investimento é o que se ganha além do que investido, após o payback do investimento, o que vier é lucro. Então, se investimos em estratégias de usabilidade para promover a

inovação ou incremento da estratégia existente, qual o retorno? O retorno é todo o lucro após o payback.

E assim sempre:

Mantenham ferramentas de controle, relatórios de visitação, número de vendas, de cadastros e etc;

Mantenham a observação das macro-tendências, como uma rotina periódica;

Cruzem as macro-tendências com resultados do negócio e análises de usabilidade já feitas para o projeto em questão.

Para dar mais uma dica, falamos bastante de conceitos, de tecnologias inovadoras, mas muitos de vocês vão perguntar como chegar a estas

conclusões.

Sejam observadores contumazes das tendências de consumo no que tange aos produtos e serviços que envolvem tecnologia. Novos hábitos, novos hits e manias da rede são material farto para apontar tendências e nichos reveladores. Mas, atenção, não os observem simplesmente como gadgets criando legiões de nerds fanáticos. Observem as alterações de comportamento, a evolução das interfaces: quem morre, quem

fica estagnado e quem fica, quem vence.

Vamos lá, leiam bastante, exaustivamente, canais que falem sobre tecnologia, com artigos e publicação de pesquisas. Por favor, nada de dizer amém para tudo. Tem que haver um componente crítico, certo? Fiquem atentos para não serem vítimas de releases em forma de matéria informativa. Também devem prestar atenção quando o canal se mostra tendencioso, sempre defendendo este ou aquele player de TI,

fanatizando-se por determinadas plataformas e por aí vai.

O mundo da tecnologia é cheio de fã clubes. É preciso ter muito cuidado para não se deixar contaminar o fanatizar pelas techs e cyber tribos

por aí. A listinha abaixo é para ser consultada periodicamente. Aos muito antenados, peço desculpas, mas a relação é bem básica mesmo.

www.tiinside.com.br;

www.webinsider;

http://tecnologia.uol.com.br/:

http://tecnologia.terra.com.br/

http://idgnow.uol.com.br/

http://pcworld.uol.com.br/

http://computerworld.uol.com.br/

http://cio.uol.com.br/

Bom, a lista é mínima, pessoal. Básico do básico, mas para quem está boiando, vindo de outras áreas como design, marketing e outras, pode ser uma boa fonte de informação.

Leiam, leiam, leiam. Pesquisem, pesquisem e pesquisem.

http://www.tiinside.com.br/

http://www.webinsider/

http://tecnologia.uol.com.br/

http://tecnologia.terra.com.br/

http://idgnow.uol.com.br/

http://pcworld.uol.com.br/

http://computerworld.uol.com.br/

http://cio.uol.com.br/



4.3.3 – Revisão Periódica das Metas

Pois é, pessoal, chegamos ao último item do nosso curso. Como último item a ser discutido, temos a revisão periódica de metas. Nosso

conselho é rever metas a cada ano.

Em se tratando de tecnologia, a “validade” do planejamento estratégico é bem mais curta. E vocês terão que cruzar macro-tendências com variáveis como modelo mental e freqüência de uso. Ë realmente desafiante.

Bom, quando efetivamente devemos revisar nossas metas de usabilidade?

Quando temos uma mudança de foco e a descoberta de um nicho importante de usuários.

Quando promovemos algum tipo de reengenharia ou redesign da interface;

Quando introduzimos um novo serviço ou recurso;

Quando alteramos nosso plano de negócio ou metas de negócio;

Quando erros de usabilidade comprometeram criticamente a imagem de um site, portal ou loja online.

Quando a concorrência afeta de maneira crucial o planejamento estratégico do negócio.

Quando há a necessidade de re-investimento no projeto;

Quando a correção do erro afetará investimentos já agendados e programados.

Vale o mesmo que já dissemos antes: mantenha o monitoramento. Sem recursos de monitoramento, vocês não serão capazes de mensurar

metas e muito menos de revê-las.



CONCLUSÃO

Usabilidade como o grande fator humano da inovação.

Bom, gente, missão cumprida. Cabe agora a vocês aplicarem tudo o que aprenderam e atuar criativamente em suas respectivas carreiras. Não necessariamente como “profissionais de usabilidade”, mas como profissionais de tecnologia, comunicação e mídia online capazes de criar estratégias centradas no usuário, com grande sucesso de metas e a partir de uma variável realmente humana.

Nunca tive como objetivo neste primeiro curso ensinar a aplicar testes, mas ajudar vocês a criar um raciocínio focado na experiência do usuário. Que vocês como criadores tenham uma visão crítica sobre suas criações. Que vocês trabalhem com um planejamento consistente em pé de

igualdade e integrado com as metodologias de planejamento de negócio.

Tenham em mente que:

A usabilidade tem que ser um fator de inovação e de criatividade, não o contrário.

A usabilidade tem que ser vista como um aspecto fundamental para o sucesso de um empreendimento online tal e qual o planejamento do

negócio em si.

A usabilidade tem que ser vista como um componente rotineiro da metodologia de projetos online e desenvolvimento de produtos de tecnologia, não como um luxo acessível somente aos grandes projetos.

Usabilidade não pode ser vista simplesmente como correção do erro. Usabilidade é o tiro certeiro.

E, para fechar, uma última mensagem da Tia Thais para seus queridos alunos:

Nunca, mas nunca mesmo, se esqueçam de que a tecnologia existe somente em função do ser humano. De suas necessidades, desejos e

particularidades. Ok?

Leiam, estudem e evoluam. Este curso é apenas o primeiro passo.

Beijocas e boa sorte a todos!

Thais Campas Passos

Arquiteta de Informação Sênior e especialista em usabilidade

Membro do Grupo Fundador a UPA Brasil e membro da UPA Internacional desde 2004.



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

1. Implementar metodologias de usabilidade desde o início do projeto evita o retrabalho, a perda de foco e processos de reengenharia

que acontecem mais cedo do que seria necessário, principalmente em projetos que não partem da experiência do usuário.

2. Não é necessário arquivar todo o histórico de modificações e correções do projeto dentro da documentação de A.I. Bastam apenas

os primeiros documentos elaborados e os últimos.

3. Não é necessário ter metas de usabilidade logo no lançamento do projeto.

4. Não é preciso diferenciar metas de usabilidade para interfaces IS e para IHC.

5. O Manual de Atualização do site não faz parte da documentação final de A.I., sendo considerado um documento a parte.

6. A matriz de escopo apresentada na documentação final tem que ser rigorosamente a mesma do início do projeto.

7. A análise de tarefas e sua respectiva documentação são desnecessárias para futuros testes de usabilidade.

2- Assinale a alternativa falsa:

1. Existem diferenças fundamentais entre o wireframe e os esboços de leiaute, feitos pelos designers. Por isso é tão importante fazer as

devidas atualizações no wireframe se houver alterações significativas no leiaute que irá para a montagem final.

2. Manuais técnicos de sistemas de atualização podem ficar de fora do Manual de Atualização.

3. Em matéria de A.I. e gestão de projetos, o que não se documenta se perde ao longo do tempo, ou ainda melhor: o que não está

escrito não existe.

4. O Manual de Atualização deve conter as normas de usabilidade do projeto, além da análise de tarefas além do mapa de navegação

em sua versão final.

5. A partir do lançamento do projeto, entra uma nova variável de usabilidade em todo o processo: a freqüência de uso.

6. Modelo mental pode ser entendido como um pré-conhecimento que opera através de uma sintaxe específica, e que faz com que as

pessoas organizem suas idéias de forma intuitiva, mostrando uma organização de pensamentos muito particular quando navegam

na Internet. Fato que pode ser muito bem percebido durante testes de usabilidade com usuários.

7. Testes de usabilidade na fase de controle da solução devem necessariamente levar em conta as variáveis de freqüência de uso.

3- Fazem parte do roteiro de básico de testes de controle e validação, exceto:

1. Definição de Usuários primários e terciários.

2. Definição de interfaces IS e IHC a serem testadas.

3. Agregar a variável “freqüência de uso” aos testes de usabilidade.

4. Cruzar dados e metas com o planejamento inicial.

5. Monitorar resultados após eventuais correções.

6. Revalidar metas após eventuais correções ou mudança de estratégia.



4- Nos casos relacionados abaixo, devemos aplicar CS fechado, exceto:

1. Redundância taxonômica normalmente aferida pela queixa dos usuários.

2. Reengenharia ou reestruturação do conteúdo.

3. Integração de conteúdo legado.

4. Identificação de usuários terciários importantes e/ou estratégicos.

5. Estudo para mudanças de cor no leiaute do site.

6. Aquisição de novos parceiros de conteúdo e novos colaboradores.

7. Conteúdos difíceis de achar ou acessar, normalmente uma reclamação de usuários.

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

1. As interfaces sociais proliferam na internet e estimulam uma grande produção de conteúdo por parte dos usuários, tornando muito

mais difícil, nos dias de hoje encontrar e separar o conteúdo confiável da mera exposição de idéias e do puro entretenimento.

2. A proliferação das interfaces sociais é um grande estímulo para que os gestores de projetos online invistam em estratégias de

usabilidade, pois assim podem obter uma análise comportamental do usuário bem mais profunda.

3. Mobilidade, globalização e mídia pessoal são tendências fundamentais para entender os fatores humanos na Internet, por isso é

imprescindível agregá-los em testes e estudos de usabilidade, influenciando as conclusões dessas análises.

4. O ROI de uma estratégia de usabilidade nunca pode ser mensurado numericamente, porque a usabilidade gera retornos, mas a

maioria deles ainda é absolutamente intangível.

5. A usabilidade pode ser uma grande aliada dos processos de inovação, pois prova que os fatores humanos que afetam os projetos

online podem ser monitorados através de testes e estudos que analisam o comportamento do usuário.

6. Devemos rever nossas metas e padrões de usabilidade periodicamente, pois a concorrência pode afetar de maneira crucial nossa

estratégia inicial, identificando oportunidades de oferecer serviços online bem melhores que os nossos, a partir da simples

identificação da insatisfação dos nossos usuários.

7. O desafio da tecnologia é entregar o que promete, por isso na fase de evolução do projeto devemos ter em mente aquilo que

podemos ou não efetivamente oferecer aos usuários.

modulo iv arquiteturainformacaousabilidade_thaiscampas

Technology