ads:
Guilhermo Almeida dos Reis
Centrando a Arquitetura de Informação no usuário
Dissertação apresentada à Escola de Comunicação e
Artes da Universidade de São Paulo para obtenção do
título de Mestre em Ciência da Informação.
Área de concentração: Cultura e Informação.
Orientadora: Prof
a
. Dr
a
. Sueli Mara Soares Pinto Ferreira
São Paulo
2007
ads:
Livros Grátis
http://www.livrosgratis.com.br
Milhares de livros grátis para download.
Centrando a Arquitetura de Informação no usuário
2
Reis, Guilhermo Almeida dos
R375c Centrando a Arquitetura de Informação no usuário /
Guilhermo Almeida dos Reis. -- São Paulo : G. A. Reis, 2007.
250 p.
Dissertação (Mestrado) - Escola de Comunicações e
Artes / USP, 2007.
Orientador: Profª. Drª. Sueli Mara Soares Pinto Ferreira.
Bibliografia
1. Arquitetura da informação 2. Websites - Design
3. Websites - Usabilidade 4. Design Centrado no Usuário
5. Interação homem-computador 6. Sense-making
I. Ferreira, Sueli Mara Soares Pinto II. Título.
CDD 21.ed. – 004.2
004.65
ads:
Folha de Aprovação
3
Folha de Aprovação
Guilhermo Almeida dos Reis
Centrando a Arquitetura de Informação no usuário
Dissertação apresentada à Escola de Comunicação e
Artes da Universidade de São Paulo para obtenção do
título de Mestre em Ciência da Informação.
Área de concentração: Cultura e Informação.
Aprovado em: ___ / ___ / ___
Banca Examinadora
Prof. Dr. ________________________________________________________________________
Instituição: _______________________________ Assinatura: _____________________________
Prof. Dr. ________________________________________________________________________
Instituição: _______________________________ Assinatura: _____________________________
Prof. Dr. ________________________________________________________________________
Instituição: _______________________________ Assinatura: _____________________________
Centrando a Arquitetura de Informação no usuário
4
Dedicatória
5
Para Eliza,
que buscou sua felicidade
muito além dos campos de algodão.
Para Clarice,
que sempre teve a felicidade a sua frente,
na máquina de costura.
E para Priscilla,
que me ensinou que a felicidade
está em viver essa dicotomia.
Centrando a Arquitetura de Informação no usuário
6
Agradecimentos
7
Agradecimentos
A Deus, que sempre nos surpreende quando compreendemos um pouco mais a sua
criação.
A minha mãe, por me despertar o gosto pelos estudos e por me ensinar a me
importar com o próximo.
Ao meu pai, que me despertou a paixão pelos computadores e me aconselha em
tudo.
A Mylene Melly, que me iluminou novos caminhos e acreditou que eu podia
percorrê-los.
A Sueli Mara Ferreira, por me mostrar uma nova visão do mundo, pela paciência e
pela orientação que dedicou a esse trabalho.
A Simone Weitzel, pela sua hospitalidade e por me ajudar com as entrevistas no
Rio de Janeiro.
A minha esposa Priscilla, pelo amor, apoio, as exaustivas revisões e pela paciência,
paciência, paciência, paciência, paciência, paciência, paciência, paciência, paciência, paciência, paciência, paciência, paciência,
Ao Eduardo, que me mostra porque vale evoluir.
E aos meus familiares, amigos e a todos que me apoiaram e colaboraram para a
realização desse trabalho.
Centrando a Arquitetura de Informação no usuário
8
Resumo
9
REIS, Guilhermo Almeida dos. Centrando a Arquitetura de Informação no usuário.
São Paulo, 2007. Dissertação (Mestrado) – Escola de Comunicação e Artes, Universidade
de São Paulo.
Resumo
O presente trabalho analisa as metodologias de projetos de arquitetura de
informação de websites sob o foco das abordagens de Design Centrado no Usuário da
Ciência da Informação e da Interação Humano-Computador.
A metodologia adotada foi uma revisão da literatura, para formular um quadro de
referência para análise das metodologias de projetos de arquitetura de informação, e duas
pesquisas de campo. A primeira pesquisa foi quantitativa, baseada em um questionário on-
line, e teve por objetivo levantar o perfil do arquiteto de informação das listas de
discussões brasileiras. A segunda pesquisa foi qualitativa e seguiu a abordagem do Sense-
making tendo como objetivo levantar as dificuldades, técnicas e metodologias encontradas
nos projetos de arquitetura de informação de websites.
Como resultado a revisão da literatura foi formulado um quadro de referência
composto de cinco fases (Pesquisa, Concepção, Especificação, Implementação e
Avaliação) no qual os princípios das abordagens de Design Centrado no Usuário são
aplicados nas duas fases iniciais, sendo que na primeira é aplicada a abordagem da Ciência
da Informação, e na segunda a abordagem da Interação Humano-Computador.
A primeira pesquisa de campo retratou um profissional jovem, que vive nos
grandes centros metropolitanos, com formação predominante na área de Humanas e que
desenvolveu seus conhecimentos sobre Arquitetura de Informação de maneira autodidata.
Quase metade deles não segue qualquer metodologia nos seus projetos e, entre os que
seguem, a maioria utiliza uma metodologia própria.
A segunda pesquisa mostrou que os arquitetos de informação experientes adotam
uma metodologia nos seus projetos e dedicam mais atenção as três primeiras fases do
quadro de referência (Pesquisa, Concepção e Especificação). As metodologias vistas na
Centrando a Arquitetura de Informação no usuário
10
prática não seguem a abordagem de Design Centrado no Usuário da Ciência da
Informação, pois raramente são feitas pesquisas com usuários. Com relação a abordagem
da Interação Humano-Computador, ela é pouco seguida porque os contratantes
desconhecem a importância dos testes de usabilidade e porque os arquitetos não dominam
as técnicas desses testes mais adequadas à Arquitetura de Informação. Com relação às
dificuldades enfrentadas nos projetos foram identificados três focos: o contratante, o
próprio trabalho de Arquitetura de Informação e o contexto tecnológico em que o websites
está inserido, sendo o primeiro o mais citado.
Conclui-se que as metodologias de projetos de arquitetura de informação precisam
evoluir na adoção das abordagens de Design Centrado no Usuário, para que consigam
produzir websites que satisfaçam plenamente os usuários, e nas formas de avaliar os
resultados, para verificar se os objetivos dos projetos foram plenamente alcançados.
Palavras–chave: Arquitetura da informação, Websites – Design, Websites – Usabilidade,
Design Centrado no Usuário, Interação homem-computador, Sense-making.
Abstract
11
REIS, Guilhermo Almeida dos. Centering the Information Architecture in the user.
São Paulo, 2007. Dissertation (Master in Information Science) – Escola de Comunicação e
Artes, Universidade de São Paulo.
Abstract
The study analyzes information architecture projects methodologies of websites
under the focus of User Centered Design approaches of Information Science and Human-
Computer Interaction .
The adopted methodology were a literature review, to formulate a theoric model to
analyze information architecture project methodologies, and two researches. The first one
was a quantitative research, based on an on-line questionnaire which aims map the profile
of information architects in Brazilian discussion lists. The second one was a qualitative
research, in which the Sense-making approach was applied to map the difficulties,
techniques and methodologies found in information architecture projects of websites.
As result the revision of literature review a theoric model with five phases was
formulated (Research, Conception, Specification, Implementation and Evaluation) in
which the approaches of User Centered Design should be applied in the two initial phases,
in the first one should be applied the approach of Information Science and in the second
one the approach of Human-Computer Interaction.
The first research showed a young professional, that lives in the great metropolitan
centers, which is often graduated in Human area and developed their knowledge of
Information Architecture in an autodidactic way. Almost half of them doesn't follow any
methodology in their projects and, most of the ones that follow uses theirs own
methodology.
The second research showed that seniors information architects adopt a
methodology in theirs project and they dedicate more attention to the first three phases of
the theoric model (Research, Conception and Specification). The methodologies found in
practice don't follow the User Centered Design approach of Information Science, because
Centrando a Arquitetura de Informação no usuário
12
they rarely make researches with users. The Human-Computer Interaction approach is
little following because the clients are not convinced of the importance of usability tests
and because information architects don't really know the techniques of usability tests more
appropriate to information architecture projects. It were identified three focuses of
difficulties faced in the projects: the clients, the own work of Information Architecture and
the technology context in that the websites is inserted.
It concludes that the methodologies of information architecture projects need to
increase in the adoption of User Centered Design, to produce websites that fully satisfy the
users, and in ways to evaluate the results of the projects, to verify if its objectives had been
reached.
Key-words: Information Architecture, Web Design, Websites – Usability, User Center
Design, Human-Computer Interaction, Sense-making.
Résumé
13
REIS, Guilhermo Almeida dos. Centré l’ Architecture d’ Information à l’utilisateur.
São Paulo, 2007. Dissertation (Maître) – Escola de Comunicação e Artes, Universidade de
São Paulo.
Résumé
Le travail présent analyse les méthodologies de projets d'architecture d'information
des site Web sous le centre des approches de Design centré à l'Utilisateur de la Science de
l'Information et de l'interaction de l' homme-machine.
La méthodologie adoptée a été une révision de la littérature, à fin de formuler un
tableau de référence pour faire l’analyse des méthodologies, et deux recherches. La
première recherche a été quantitative et basé sur un questionnaire connecté avec l'objectif
d’ identifier le profil l'architecte d'information des listes de discussions brésiliennes, et la
deuxième recherche a été qualitatif, dans le lequel l'approche de Sense-Making a été
appliquée pour identifier les difficultés, techniques et méthodologies trouvé dans les
projets d'architecture d'information des site Web.
Le résultat de la révision de la littérature a été un tableau de la référence composé
de cinq phases (Recherche, Conception, Spécification, Mise en oeuvre et Évaluation) dans
lequel les principes des approches de Design centrés à l'Utilisateur devraient être
appliqués dans les deux phases débutants, dans la première phase ils devraient être
appliqués à l'approche de la Science de l'Information et dans le deuxième phase l’approche
de l’ interaction de l’ homme-machine.
La première recherche a montré un jeune professionnel qui vie dans les grands
centres métropolitains, avec formation prédominante des sciences humaines et qu'il a
développé leur connaissance sur Architecture d'Information dans un chemin autodidacte.
Presque demi d'eux ne suit pas toute méthodologie dans leurs projets et, parmi ceux qu'ils
le font, la plupart des usages utilise une propre méthodologie.
La deuxième recherche a montré que les architectes expérimentés d'information
adoptent une méthodologie dans ses projets et ils consacrent plus d'attention aux premières
Centrando a Arquitetura de Informação no usuário
14
trois phases de l'image de la référence (Recherche, Conception et Spécification). Les
méthodologies vues ne suivent pas l'approche de Design centré à l'Utilisateur de la Science
de l'Information, parce que rarement des recherches avec les utilisateurs sont faites.
Concernant l’ approche de l'interaction homme-machine, elle est très peu suivi parce que
les contractant partis ne connaissent pas de l'importance de l'usage teste et les architectes
ne dominent pas les techniques de ceux tests plus appropriées à l'Architecture
d'Information. Par rapport aux difficultés trouvées dans les projets ont été identifiées trois
points focaux: le contractant parti, le propre travail d'Architecture d'Information et le
contexte technologique où les site Web sont insérés, en étant le premier le plus mentionné.
Il a conclu que les méthodologies de projets d'architecture de besoin de
l'information pour développer dans l'adoption des approches de Design centrées à
l'Utilisateur á fin de qu'ils réussissent à produire des site Web pour satisfaire
complètement les utilisateurs.
Mots-clés : Architecture d’information, Websites – Design, Websites – Utilisabilité,
Design Centré à l'Utilisateur, Interaction l’homme - machine, Sense-making.
Sumário
15
Sumário
Capítulo 1 Introdução 25
1.1 Objetivos da Pesquisa 28
1.1.1 Objetivo Geral 28
1.1.2 Objetivos Específicos 28
1.2 Justificativa 28
1.3 Metodologia 29
1.3.1 Revisão da Literatura 29
1.3.2 Levantamento do perfil do arquiteto de informação das listas de discussão
brasileiras 30
1.3.2.1 Variáveis de estudo 30
1.3.2.2 Amostragem 32
1.3.2.3 Coleta de Dados 33
1.3.2.4 Análise dos dados coletados 34
1.3.3 Levantamento das dificuldades, técnicas e metodologias encontradas nos
projetos de arquitetura de informação de websites 34
1.3.3.1 Amostragem 39
1.3.3.2 Coleta de Dados 40
1.3.3.3 Análise dos dados coletados 42
Capítulo 2 Design Centrado no Usuário 45
2.1 O Design Centrado no Usuário na Interação Humano-Computador 49
2.2 O Design Centrado no Usuário na Ciência da Informação 53
2.3 Síntese 58
Capítulo 3 Arquitetura de Informação de websites 59
3.1 O que é Arquitetura de Informação de websites? 62
3.1.1 Um exemplo 66
3.1.2 Por que a Arquitetura de Informação é importante? 67
3.1.3 A multi-disciplinariedade da Arquitetura de Informação 69
3.2 Os componentes da arquitetura de informação para Web 71
3.2.1 Sistema de Organização 73
3.2.1.1 O que é categorizar? 74
3.2.1.2 Dificuldades para organizar informação na Web 79
Centrando a Arquitetura de Informação no usuário
16
3.2.1.2.1 Ambigüidade 80
3.2.1.2.2 Heterogeneidade 80
3.2.1.2.3 Diferenças de Perspectiva 81
3.2.1.2.4 Políticas internas 82
3.2.1.2.5 Estética 83
3.2.1.3 Esquemas de organização da informação 83
3.2.2 Sistema de Navegação 86
3.2.2.1 Por que as pessoas se perdem ao navegar em um hipertexto? 87
3.2.2.1.1 Esquemas ou modelos de ambientes genéricos 87
3.2.2.1.2 Mapas espaciais cognitivos 88
3.2.2.2 Dificuldades em projetar o sistema de navegação 90
3.2.2.3 Flexibilidade X Confusão 93
3.2.2.4 Navegação Social 93
3.2.2.5 Elementos do Sistema de Navegação 94
3.2.3 Sistema de Rotulação 98
3.2.3.1 O que são rótulos? 99
3.2.3.2 Dificuldades no projeto do sistema de rotulação 101
3.2.3.2.1 Conseguir falar na linguagem do usuário 101
3.2.3.2.2 Superar a ausência de feedback 102
3.2.3.2.3 Eliminar ambigüidades 102
3.2.3.2.4 Manter a consistência 103
3.2.3.3 A padronização dos rótulos 105
3.2.3.4 Ícones como rótulos 105
Capítulo 4 Investigação teórica das metodologias de projetos de
arquitetura de informação de websites 107
4.1 Princípios para metodologias de projeto de arquitetura de informação de
websites 111
4.2 Análise das metodologias de projeto de arquitetura de informação de
websites 117
4.2.1 A fase de Pesquisa 123
4.2.1.1 Variáveis de pesquisa 124
4.2.1.1.1 Grupo de variáveis de pesquisa sobre a empresa 125
4.2.1.1.2 Grupo de variáveis de pesquisa sobre o usuário 128
4.2.1.2 Técnicas empregadas na fase de Pesquisa 130
4.2.1.2.1 Técnicas para pesquisa do grupo de variáveis sobre a empresa 130
4.2.1.2.2 Técnicas para pesquisa do grupo de variáveis sobre o usuário 131
4.2.2 A fase de Concepção 134
4.2.2.1 Técnicas da fase de Concepção 138
Sumário
17
4.2.2.1.1 Técnicas para a definição dos conceitos 138
4.2.2.1.2 Técnicas para a avaliação dos conceitos 141
4.2.3 A fase de Especificação 143
4.2.3.1 Sitegrama e Fluxo das Transações 145
4.2.3.2 Wireframe 146
4.2.3.3 Vocabulário Controlado 148
4.2.4 A fase de Implementação 150
4.2.5 A fase de Avaliação 152
4.3 Síntese 154
Capítulo 5 Investigação empírica da metodologia de projetos de
arquitetura de informação de websites 157
5.1 Resultado do levantamento do perfil do arquiteto de informação das
listas de discussão brasileiras 157
5.1.1 Interesse em Arquitetura de Informação 158
5.1.2 Perfil Demográfico 159
5.1.3 Escolaridade 161
5.1.4 Aprendizado de Arquitetura de Informação 166
5.1.5 Grau de experiência 167
5.1.6 Empresas, cargos e forma de contratação 168
5.1.7 Atividades executadas 171
5.1.8 Existência de uma metodologia de projetos de arquitetura de informação 173
5.1.9 Síntese dos resultados encontrados 175
5.2 Resultado do levantamento das dificuldades, técnicas e metodologias
encontradas nos projetos de arquitetura de informação de websites 176
5.2.1 Análise da metodologia adotada pelos entrevistados 177
5.2.1.1 Análise das fases do quadro de referência na metodologia dos entrevistados 181
5.2.1.1.1 Análise da fase de Pesquisa na metodologia dos entrevistados 187
5.2.1.1.2 Análise da fase de Concepção na metodologia dos entrevistados 190
5.2.1.1.3 Análise da fase de Especificação na metodologia dos entrevistados 194
5.2.1.1.4 Análise da fase de Implementação na metodologia dos entrevistados 195
5.2.1.1.5 Análise da fase de Avaliação na metodologia dos entrevistados 196
5.2.2 Análise das dificuldades dos entrevistados nos projetos de arquitetura de
informação 197
5.2.2.1 Análise das dificuldades dos entrevistados na fase de Pesquisa 201
5.2.2.2 Análise das dificuldades dos entrevistados na fase de Concepção 204
5.2.2.3 Análise das dificuldades dos entrevistados na fase de Especificação 210
Centrando a Arquitetura de Informação no usuário
18
5.2.2.4 Análise das estratégias adotadas 213
5.2.3 Síntese dos resultados encontrados 215
Capítulo 6 Considerações finais 219
Capítulo 7 Referências 229
Anexo I Questionário da pesquisa on-line 241
Anexo II Roteiro da entrevista individual 245
Sumário
19
Lista de Tabelas
Tabela 1 - Principais listas de discussão brasileiras sobre Arquitetura de Informação___ 32
Tabela 2 - Categorias utilizadas para análise das metodologias dos entrevistados______ 44
Tabela 3 - Categorias utilizadas para análise das dificuldades enfrentadas pelos
entrevistados ___________________________________________________________ 44
Tabela 4 - Problemas mais comuns nos websites (VIVIDENCE RESEARCH, 2001) __ 69
Tabela 5 - Elementos do Sistema de Navegação________________________________ 94
Tabela 6 - Distribuição dos profissionais por estado e cidade de naturalidade e
residência_____________________________________________________________ 160
Tabela 7 - Cursos de graduação, especialização e mestrado dos profissionais ________ 163
Tabela 8 - Instituições de ensino citadas pelos profissionais _____________________ 165
Tabela 9 - Outras formas como os profissionais desenvolveram seus conhecimentos _ 167
Tabela 10 - Distribuição dos profissionais por tipo de empresa ___________________ 169
Tabela 11 - Tipo de empresa e forma de contratação dos profissionais _____________ 169
Tabela 12 - Nome dos cargos dos profissionais _______________________________ 170
Tabela 13 - Outras atividades relacionadas a Arquitetura de Informação citadas pelos
profissionais___________________________________________________________ 172
Tabela 14 – Classificação das outras atividades nas fases do quadro de referência ____ 173
Tabela 15 - Características dos entrevistados _________________________________ 177
Tabela 16- Adoção de metodologia nos projetos de arquitetura de informação pelos
entrevistados __________________________________________________________ 181
Tabela 17 - Análise da fase de Pesquisa nas metodologias dos entrevistados ________ 189
Tabela 18- Análise da fase de Concepção nas metodologia dos entrevistados________ 193
Tabela 19 - Análise da fase de Especificação nas metodologias dos entrevistados ____ 195
Tabela 20 - Análise da fase de Implementação nas metodologias dos entrevistados ___ 196
Tabela 21 - Análise da fase de Avaliação nas metodologias dos entrevistados _______ 197
Tabela 22 - Dificuldades dos entrevistados nos projetos de arquitetura de informação _ 198
Centrando a Arquitetura de Informação no usuário
20
Tabela 23 – Classificação das dificuldades pelo foco das questões dos entrevistados___199
Tabela 24 - Classificação das dificuldades nas fases do quadro de referência _________200
Tabela 25 - Classificação das dificuldades nas fases do quadro de referência e pelo
foco das questões dos entrevistados _________________________________________200
Tabela 26 - Análise das dificuldades dos entrevistados na fase de Pesquisa __________204
Tabela 27 - Análise das dificuldades dos entrevistados na fase de Concepção ________209
Tabela 28 - Análise das dificuldades dos entrevistados na fase de Pesquisa__________213
Tabela 29 - Classificação das estratégias pelo foco das questões dos entrevistados ____215
Lista de Figuras
21
Lista de Figuras
Figura 1 – O Triângulo Sense-Making - adaptada de FERREIRA (1997) e CHEUK
(1999)_________________________________________________________________ 37
Figura 2 - Mapas da linha de trem Yamanote em Tóquio (WURMAN, 1991)_________ 67
Figura 3 – Disciplinas que colaboram na formação do corpo teórico da Arquitetura
de Informação (ROSENFELD, 2001) ________________________________________ 70
Figura 4 - Esquemas de organização da Informação_____________________________ 85
Figura 5 - Fases do projeto de um website (MELLY, 2003)______________________ 109
Figura 6 - Metodologias de projetos de arquitetura de informação de websites _______ 118
Figura 7 - Análise das metodologias nas fases do quadro de referência _____________ 122
Figura 8 - Atividades que compõem a fase de Concepção _______________________ 137
Figura 9 - Metodologia de projetos de arquitetura de informação do entrevistado 1 ___ 182
Figura 10 - Metodologia de projetos de arquitetura de informação do entrevistado 2__ 183
Figura 11 - Metodologia de projetos de arquitetura de informação do entrevistado 3 __ 184
Figura 12 - Metodologia de projetos de arquitetura de informação do entrevistado 4 __ 185
Figura 13 - Metodologia de projetos de arquitetura de informação do entrevistado 5 __ 186
Figura 14 – Questionário on-line - Instruções para o preenchimento _______________ 242
Figura 15 - Questionário on-line - Perguntas comuns a todos os entrevistados _______ 242
Figura 16 - Questionário on-line - Perguntas exclusivas aos profissionais___________ 243
Centrando a Arquitetura de Informação no usuário
22
Lista de Gráficos
23
Lista de Gráficos
Gráfico 1 - Quantidade de mensagens postadas nas principais listas de discussão
brasileiras sobre Arquitetura de Informação (janeiro a junho – 2006)_______________ 33
Gráfico 2 - Interesse dos entrevistados sobre Arquitetura de Informação ___________ 158
Gráfico 3 – Distribuição dos entrevistados por sexo e interesse ___________________ 159
Gráfico 4 - Distribuição dos profissionais por sexo e faixa de idade _______________ 159
Gráfico 5 – Distribuição dos entrevistados por sexo e estado civil_________________ 160
Gráfico 6 - Grau de instrução dos entrevistados _______________________________ 161
Gráfico 7 - Área de formação dos profissionais _______________________________ 162
Gráfico 8 - Área de formação dos profissionais: Graduação x Pós-Graduação _______ 164
Gráfico 9 - Formas como os profissionais desenvolveram seus conhecimentos sobre
Arquitetura de Informação________________________________________________ 166
Gráfico 10 - Distribuição dos profissionais pelos anos de trabalho com Internet______ 167
Gráfico 11 - Distribuição dos profissionais pelos anos de trabalho com Arquitetura
de Informação _________________________________________________________ 168
Gráfico 12 - Porcentagem do tempo de trabalho dedicado à Arquitetura de
Informação____________________________________________________________ 168
Gráfico 13 - Distribuição dos profissionais por tipo de cargo e tempo de dedicação a
Arquitetura de Informação________________________________________________ 170
Gráfico 14 - Atividades de Arquitetura de Informação que os profissionais já
fizeram_______________________________________________________________ 171
Gráfico 15 - Quantidade de profissionais que seguem uma metodologia nos projetos
de arquitetura de informação ______________________________________________ 174
Gráfico 16 - Metodologia adotada nos projetos de arquitetura de informação ________ 174
Centrando a Arquitetura de Informação no usuário
24
Introdução
25
Capítulo 1
Introdução
Cinco exabytes (5.000.000.000.000.000.000 bytes) de informação nova foram
produzidos no mundo em 2002! Para se ter uma idéia do que isso significa imagine que um
byte equivale a uma letra em uma página datilografada. Cinco exabytes equivalem então a
uma pilha de livros que vai do Sol a Plutão. Se for dividida pela população da Terra, cabe a
cada habitante uma pilha de livros com 8 metros de altura. E, ainda mais surpreendente, a
quantidade de informação nova produzida no mundo cresce a uma taxa de 30% ao ano!
Estes dados, de um estudo da University of California at Berkeley (2003), retratam
o fenômeno da explosão da produção e distribuição de informação que revoluciona o
mundo no final do século passado e início deste novo. Nunca se produziu e se distribuiu
tanta informação na história da humanidade. “Uma edição do The New York Times em um
dia de semana contém mais informação do que o comum dos mortais poderia receber
durante toda a vida na Inglaterra do século XVII” (WURMAN, 1991, pág. 36).
A Internet, a grande rede mundial de computadores, é o maior símbolo desse
fenômeno. Conectando tudo e todos, esta rede é o meio de comunicação que mais rápido se
expande na história, impregnando-se na vida da nossa sociedade contemporânea. Segundo
pesquisa da NETCRAFT (2007) existem atualmente mais de 108 milhões de websites na
Centrando a Arquitetura de Informação no usuário
26
Internet oferecendo seus serviços e conteúdos informativos a todo o mundo. CASTELLS
(2003) cita que “A Internet é o tecido de nossas vidas neste momento. Não é futuro. É
presente. Internet é um meio para tudo, que interage com o conjunto da sociedade e, de
fato, apesar de tão recente em sua forma societária (...) não precisa de explicação, pois já
sabemos o que é Internet”.
Esta explosão da informação causa um visível desconforto na maioria das pessoas.
Bombardeada por incontáveis notícias, artigos, e-mails, relatórios, filmes e websites a
mente humana não consegue absorver toda a informação necessária à sobrevivência do
trabalhador moderno. Esse excesso de informação gera a síndrome da fadiga da
informação, batizada pelo psicólogo britânico Davis Lewis, é caracterizada por tensão,
irritabilidade e sentimento de abandono causado pela sobrecarga de informação a que o ser
humano está exposto (ANTUNES, 1998; SATO e HASHIMOTO, 2004).
Preocupado com a ansiedade que a informação provoca, Richard Wurman presidiu,
em 1976, a conferencia nacional do American Institute of Architects cujo tema era “The
Architecture of Information”. Nesta conferência foi proposta a criação de uma nova
disciplina chamada de Arquitetura de Informação, para combater esse sentimento de
ansiedade, resultado da distância entre o que compreendemos e o que deveríamos
compreender. O objetivo da Arquitetura de Informação é organizar a informação de forma
que seus usuários possam assimilá-la com facilidade.
A Arquitetura de Informação proposta por WURMAN começou baseada na mídia
impressa, principalmente na produção de guias, mapas e Atlas. Atualmente a área que mais
vem sendo explorada por essa disciplina é a organização de websites.
Dentre os diversos tipos de problemas que podem afetar o uso de um website,
chama a atenção os relacionados com a organização das suas informações. Falhas nessa
organização provocam nos seus usuários confusão, frustração ou até mesmo a ira,
dificultando o uso do website e repercutindo diretamente no retorno do investimento.
ROSENFELD e MORVILLE (2002) citam que a incapacidade de encontrar uma
informação é um dos fatores que mais desagradam os usuários, e pesquisas do NIELSEN
NORMAN GROUP (2001) aponta que 27% das causas de insucesso das vendas de um
Introdução
27
website de comércio eletrônico são porque o usuário simplesmente não conseguiu
encontrar o item que procurava.
No projeto de um website, a elaboração da arquitetura de informação é uma das
suas etapas iniciais, sendo responsável por definir toda a organização, a estrutura do
website sobre a qual as demais partes irão se apoiar (projeto gráfico, redação,
programação, etc.). Erros nessa etapa inicial, se não forem observados e corrigidos de
imediato podem ser difíceis e caros de corrigir nas etapas seguintes. PRESSMAN (1995,
pág. 28) cita a respeito do projeto de desenvolvimento de qualquer software (inclusive
websites) que “uma mudança quando solicitada tardiamente num projeto, pode ser mais do
que a ordem de magnitude mais dispendiosa da mesma mudança solicitada nas fases
iniciais.”
Dessa forma aplicar uma metodologia aos projetos de arquitetura de informação de
websites é de suma importância para evitar erros e minimizar riscos. MORROGH (2003,
pág. 117) cita que “se o processo para gerenciar o design de ambientes de informação não
for explícito, as chances de falhas aumentam. Portanto, o gerenciamento do design de
ambientes de informação é mais eficiente e efetivo quando segue um método”.
A Arquitetura de Informação se propõe a organizar a informação para satisfazer as
necessidades informacionais dos seus usuários. Para tanto duas disciplinas que estudam o
design centrado no usuário podem auxiliar a melhorar a metodologia e a qualidade do
produto final dos projetos de arquitetura de informação de websites: a Ciência da
Informação e a Interação Humano-Computador. A Ciência da Informação colabora com
seus estudos de usuários e necessidades de informação e pode auxiliar a compreende-los
melhor. Já a Interação Humano-Computador colabora com suas análises de usabilidade que
possuem técnicas para validar com usuários a eficácia e eficiência das soluções.
Centrando a Arquitetura de Informação no usuário
28
1.1 Objetivos da Pesquisa
1.1.1 Objetivo Geral
Estudar as práticas de projetos de arquitetura de informação de websites com
profissionais brasileiros que atuam na área para verificar o grau de aderência das
metodologias de projetos dessa natureza com as propostas teóricas.
1.1.2 Objetivos Específicos
1- Realizar um estudo bibliográfico sobre as dificuldades e as metodologias de
projetos de arquitetura de informação de websites.
2- Analisar a forma de trabalho dos arquitetos de informação no Brasil para
descobrir suas dificuldades e quais metodologias e técnicas utilizam para superá-las.
1.2 Justificativa
A Arquitetura de Informação de websites ainda é um campo novo. Existe pouca
teoria e raros congressos internacionais sobre o mesmo, e no Brasil o assunto é pouco
tratado no meio acadêmico. Porém já é grande a procura sobre o tema pelos profissionais.
Na Web o crescimento explosivo da informação não está sendo acompanhado da
melhora dos métodos para organizar as informações por ela apresentada. São poucos os
autores que tratam o tema com profundidade científica.
Ferramentas para identificar e localizar informação relevante não cresceram em
efetividade na mesma taxa explosiva que a quantidade de informação disponível.
Consequentemente, nossa habilidade para encontrar, revisar e usar informação é
limitada e também contribui para os sentimentos de sobrecarga de informação.
Desenvolver ferramentas de gerenciamento de informação que sejam fáceis de usar
e mais sofisticadas é um fato importante para ajudar a aliviar o problema da
sobrecarga da informação. (MORROGH, 2003, pág. 99)
Introdução
29
Dessa forma, esse trabalho se justifica ao contribuir para a consolidação de uma
metodologia de projetos de arquitetura de informação de websites e assim auxiliar na
conceituação teórica que o tema necessita. Pretende-se também que ele auxilie no
desenvolvimento e melhora dos métodos de organização da informação específicos para o
ambiente Web.
1.3 Metodologia
O objetivo desse trabalho é investigar as dificuldades, técnicas e metodologias
empregadas na prática pelos arquitetos de informação brasileiros e confrontá-las com as
recomendações teóricas para avaliar sua aplicabilidade. Para tanto foram realizadas uma
revisão da literatura e duas pesquisas de campo
1.3.1 Revisão da Literatura
O objetivo da revisão da literatura foi compreender o que é Arquitetura de
Informação de websites, as dificuldades dos projetos de arquitetura de informação e as
metodologias existentes tendo como foco o Design Centrado no Usuário nas visões de
Ciência da Informação e da Interação Humano-Computador. Essa revisão foi respaldada
em autores consagrados sobre esses temas.
Especialmente no caso da Arquitetura de Informação, devido a pouca literatura
existente, fez parte dessa revisão artigos publicados em websites destinados a profissionais
da área. Como a literatura disponível em língua portuguesa sobre o tema é escassa e restrita
a artigos técnicos, foram consultados autores estrangeiros, especialmente os norte-
americanos, onde o tema está mais difundido. O período pesquisado foram os últimos 11
anos (1995 a 2006), que abrangem desde os primeiros trabalhos de aplicação dos conceitos
de Arquitetura de informação ao design de websites.
Como resultado, essa revisão de literatura caracterizou o que é Arquitetura de
Informação e quais os seus componentes, identificou as metodologias de projetos
existentes e as comparou de modo a produzir um quadro de referência para análise das
pesquisas de campo.
Centrando a Arquitetura de Informação no usuário
30
1.3.2 Levantamento do perfil do arquiteto de informação das listas de
discussão brasileiras
A primeira pesquisa de campo teve como objetivo levantar o perfil sócio-
demográfico dos arquitetos de informação e o grau de experiência desses profissionais. Ela
também teve a função de identificar e selecionar arquitetos de informação experientes para
participarem da segunda pesquisa.
Foi necessário realizar essa pesquisa porque não foram encontrados dados sócio-
demográficos traçando o perfil da população dos profissionais que trabalham com
Arquitetura de Informação de websites no Brasil que permitisse identificar uma amostra
para a segunda pesquisa. Por ser tratar de um campo novo de trabalho, provavelmente
ainda não existam muitas informações disponíveis sobre o perfil desses profissionais.
A pesquisa foi realizada com membros de listas de discussão brasileiras sobre
Arquitetura de Informação, nas quais estão presentes tanto arquitetos de informação quanto
pessoas interessadas no tema. A coleta de dados foi feita por meio de um método
quantitativo utilizando um questionário on-line.
1.3.2.1 Variáveis de estudo
As variáveis de estudo dessa pesquisa de levantamento do perfil dos arquitetos de
informação foram divididas nos seguintes grupos:
• Interesse em Arquitetura de Informação: busca evidenciar se o foco do
entrevistado é voltado para pesquisa (atividade acadêmica, desenvolvimento
profissional, etc.) ou para atividade profissional (atua como profissional no
desenvolvimento de projetos de arquitetura de informação de websites). O
grupo de entrevistados que manifestou interesse em atividade profissional
foi denominado “profissionais”. Os entrevistados puderam manifestar os
dois interesses.
• Perfil Demográfico: mostra as características básicas dos entrevistados:
sexo, idade, estado civil, naturalidade e residência.
Introdução
31
• Escolaridade: descreve a formação acadêmica dos entrevistados: grau de
instrução, nome dos cursos acadêmicos realizados, área de formação e
instituição de ensino. Esse grupo de variáveis foi pesquisado apenas com os
profissionais.
• Aprendizado de Arquitetura de Informação: indica a forma com que os
profissionais desenvolveram seus conhecimentos sobre Arquitetura de
Informação.
• Grau de experiência: aponta os anos de trabalho do profissional na área e a
sua dedicação à Arquitetura de Informação.
• Empresas, cargos e forma de contratação: descreve o tipo de empresa
onde os profissionais trabalham, seus cargos e a relação trabalhista que
possuem.
• Atividades executadas: mostra quais das atividades relacionadas à
Arquitetura de Informação os profissionais já desenvolveram.
• Existência de uma metodologia de projetos de Arquitetura de
Informação: indica a adoção de uma metodologia por parte dos
entrevistados nos seus projetos de Arquitetura de Informação.
O Anexo I desse trabalho mostra como as questões do questionário on-line se
relacionaram com as variáveis descritas acima.
Centrando a Arquitetura de Informação no usuário
32
1.3.2.2 Amostragem
A amostra foi composta pelos participantes das principais listas de discussão
brasileiras sobre Arquitetura de Informação
1
. A Tabela 1 mostra essas listas.
Tabela 1 - Principais listas de discussão brasileiras sobre Arquitetura de Informação
Lista de discussão AIfIA-pt Arquitetura de Informação Arquitetura de Informação (BR)
Descrição
Debate assuntos relacionados ao
campo de estudo da Arquitetura de
Informação e à profissão de
arquiteto de informação.
Discute a Arquitetura de
Informação e a profissão de
arquiteto de informação no Brasil.
Hospedada no website Orkut
(www.orkut.com) .
Discute a Arquitetura de
Informação.
Também hospedada no website
Orkut (www.orkut.com).
Data de criação
março/2003 abril/2004 abril/2004
Quantidade de
membros
em junho/2006
370 1865 923
URL
http://lists.ibiblio.org/mailman/listinf
o/aifia-pt
http://www.orkut.com/Community.a
spx?cmm=38740
http://www.orkut.com/Community.a
spx?cmm=48720
Uma análise dessas comunidades mostra que existe um percentual elevado de
pessoas que pertencem a todas elas. Dois fatores levam a essa conclusão:
• As duas comunidades hospedadas no Orkut possuem muitos tópicos
idênticos, postados pelos mesmos usuários.
• A comunidade Arquitetura de Informação hospedada no Orkut incentiva, na
sua descrição, seus membros a participarem da lista de discussão AIfIA-pt.
Apesar de ter poucos membros, a quantidade de mensagens postadas na lista de
discussão AIfIA-pt é significativamente maior que as outras listas, como mostra o
Gráfico 1. Assim sua comunidade foi a população alvo dessa pesquisa, ou seja, o universo
pesquisado foram seus 370 membros.
1
Foi postada uma mensagem na comunidade AifIA-pt indagando aos seus membros se conheciam outras
listas de discussão brasileiras sobre Arquitetura de Informação além das três investigadas nessa pesquisa.
Ninguém citou outra lista com essa característica.
Introdução
33
Gráfico 1 - Quantidade de mensagens postadas nas principais listas de discussão brasileiras
sobre Arquitetura de Informação (janeiro a junho – 2006)
0
50
100
150
200
250
300
AIfIA-pt
124 77 59 92 270 128
Arquitetura de Informação
5 4 12 6 4 12
Arquitetura de Informação (BR)
5 5 5 4 7 4
janeiro/06 fevereiro/06 março/06 abril/06 maio/06 junho/06
1.3.2.3 Coleta de Dados
A coleta de dados foi realizada por meio de um questionário on-line disponibilizado
na Web. A escolha desse instrumento de pesquisa foi decorrente das suas vantagens
intrínsecas, que, segundo GIL (1999), são:
• Possibilidade de atingir grande número de pessoas, mesmo que estejam
geograficamente dispersas.
• Baixo custo de pessoal.
• Conveniência para o entrevistado responder o questionário no momento e
local que julgar mais apropriado.
• Não exposição dos entrevistados à influência das opiniões e do aspecto
pessoal do entrevistador.
Optou-se por divulgar o questionário de forma on-line porque a Web faz parte do
cotidiano dos arquitetos de informação, público alvo dessa pesquisa.
O questionário foi composto na sua maior parte de questões fechadas, o que
facilitou sua tabulação. Questões abertas foram utilizadas apenas para o entrevistado
esclarecer sua resposta, caso não encontrasse uma opção que o atendesse. Para verificar a
eficiência desse instrumento de pesquisa foi realizado um pré-teste com dois membros das
Centrando a Arquitetura de Informação no usuário
34
listas de discussão para verificar a compreensão das questões. Os devidos ajustes foram
feitos no questionário e a versão utilizada na pesquisa está apresentada no Anexo I.
Todos os membros das três comunidades citadas foram convidados a participar da
pesquisa. O primeiro convite foi feito através da postagem de uma mensagem nas três
comunidades convidando seus membros a participarem. Como questionários não oferecem
garantias de que a maioria das pessoas o responderá (GIL, 1999), foram feitos dois outros
convites por e-mail no decorrer da pesquisa apenas aos membros da AIfIA-pt que ainda
não haviam respondido a pesquisa porque essa é a única comunidade que divulga o
endereço de e-mail dos seus participantes.
1.3.2.4 Análise dos dados coletados
Os dados obtidos com as questões fechadas da pesquisa foram analisados segundo
fórmulas estatísticas simples como média, porcentagem e histogramas para se quantificar
as respostas e levantar correlações entre as variáveis pesquisadas. Foram empregadas
planilhas eletrônicas para produzir as tabelas e os gráficos utilizados na análise.
Para as questões abertas, as respostas foram classificadas e a quantidade de citações
de cada categoria foi quantificada. Como nas questões fechadas, foram elaborados gráficos
e tabelas para análise. Os resultados dessa pesquisa estão apresentados no capítulo 5.
1.3.3 Levantamento das dificuldades, técnicas e metodologias encontradas
nos projetos de arquitetura de informação de websites
O objetivo da segunda pesquisa de campo foi conhecer as dificuldades, técnicas e
as metodologias vivenciadas pelos arquitetos de informação brasileiros durante um projeto
da arquitetura de informação de um website e avaliar a aplicação na prática do quadro de
referência proposto na investigação teórica. Pretendeu-se com essa pesquisa avaliar se os
problemas e recomendações teóricas dos diversos autores levantados na revisão da
literatura são aplicados na prática do dia-a-dia.
Para realizá-la foi utilizada a técnica de pesquisa qualitativa de entrevistas em
profundidade derivada da abordagem do Sense-Making, que se destina a estudar as
Introdução
35
necessidades de informação que os usuários enfrentam em uma determinada situação e
como fazem para superá-la.
A escolha de uma metodologia qualitativa foi adotada porque o objetivo dessa
pesquisa foi conhecer em detalhes as dificuldades que os arquitetos de informação
enfrentam nos seus projetos e quais técnicas utilizam para superá-las. Foi escolhida a
abordagem do Sense-Making porque:
• Permite recriar com riqueza de detalhes a situação na qual ocorreu a
dificuldade.
• Utiliza as próprias palavras do entrevistado para explicar o significado de
cada situação.
• É uma metodologia utilizada com sucesso na área de Biblioteconomia e
Ciência da Informação.
A abordagem do Sense-Making utilizada nessa pesquisa começou a ser
desenvolvida pela Profa. Dra. Brenda Dervin e colegas em 1972 na Ohio State University,
nos Estados Unidos, e somente em 1983 foi publicado o primeiro documento contento toda
a sua base filosófica, conceitual, teórica e metodológica. (FERREIRA, 1997).
Tradicionalmente a abordagem do Sense-Making tem sido vastamente aplicada em
questões de pesquisas relacionadas com o uso de informação e de sistemas de informação
por seres humanos. Ela não é apenas um modelo de busca de informação, é também um
modelo de metodologia para estudar busca e uso da informação (WILSON apud CHEUK e
DERVIN, 1999) e que consiste em “um conjunto de premissas conceituais e teóricas e um
conjunto de metodologias relacionadas para avaliar como as pessoas criam sentido dos
seus mundos e como elas usam a informação e outros recursos nesse processo” (DERVIN
e NILAN, 1986, pág. 20). Sua função é entender como as pessoas satisfazem suas
necessidades de informação e esse conhecimento pode ser aplicado no design dos sistemas
de informação tornando-os mais eficazes (DERVIN, 1997).
Essa abordagem pode também ser usada num sentido ainda mais amplo. Segundo
DERVIN (1992, pág. 67) “a abordagem metodológica que é chamada de Sense-Making é
Centrando a Arquitetura de Informação no usuário
36
uma abordagem para estudar a construção que os seres humanos fazem para criar sentido
de suas experiências”.
FERREIRA (1997, pág. 17) resume da seguinte forma os pressupostos básicos que
embasam a abordagem do Sense-Making:
a) a realidade não é completa nem constante, ao contrário é permeada de
descontinuidades fundamentais e difusas, intituladas “vazios” (gaps).
Assume-se que esta condição é generalizável porque as coisas na
realidade não são conectadas e estão mudando constantemente.
b) a informação não é algo que exista independentemente e externamente
ao ser humano, ao contrário é um produto da observação humana.
c) desde que se considera a produção de informação ser guiada
internamente, então o Sense-Making assume que toda informação é
subjetiva.
d) busca e uso da informação são vistas como atividades construtivistas,
como criação pessoal do sentido do ser humano.
e) focaliza em como indivíduos usam as observações tanto de outras
pessoas como as próprias para construir seus quadros da realidade e os
usa para direcionar seu comportamento.
f) o comportamento dos indivíduos pode ser prognosticado com mais
sucesso com a estruturação de um modelo que focalize mais suas
situações de mudança do que atributos denominados características de
personalidades ou demográficas.
g) pesquisa por padrões, observando mais do que assumindo conexões
entre situações e necessidades de informação, entre informação e uso.
h) considera-se a existência de compreensões universais da realidade que
permitem prognósticos e explicações melhores do que seria possível
obter nas abordagens positivistas tradicionais
2
.
2
Grifos da autora.
Introdução
37
Na abordagem do Sense-Making a informação é, segundo DERVIN apud
FERREIRA (1997, pág. 18), “aquilo que informa”, ou seja, o que ajuda o indivíduo a
superar os obstáculos no seu caminho, buscando novos conhecimentos, quando seu quadro
de referências interno, não consegue resolve-lo. Surge então uma necessidade de
informação e sua solução é obtida pela informação.
Metaforicamente é como se o indivíduo estivesse se movendo sempre em frente,
caminhando através do espaço-tempo. De repente ocorre-lhe uma situação onde seu
conhecimento não é capaz de superar o obstáculo que aparece a sua frente devido a lacunas
no seu quadro de referências interno provocando a necessidade de informação. Para
transpor este obstáculo e atingir seu objetivo o indivíduo precisa adquirir um novo
conhecimento e para tanto ele planeja e executa uma estratégia de busca de informação. Ao
encontrar a informação, ele a utiliza solucionando seu problema (DERVIN 1992). Esta
metáfora, chamada de Triângulo do Sense-Making é ilustrada na Figura 1.
Figura 1 – O Triângulo Sense-Making - adaptada de FERREIRA (1997) e CHEUK (1999)
Situação
Situação
Lacuna
Lacuna
Uso
Uso
Ponte ou Estratégia
Situação
Situação
Situação
Situação
Lacuna
Lacuna
Uso
Uso
Uso
Uso
Ponte ou Estratégia
O Triangulo do Sense-Making ilustra bem todos os elementos que reunidos
determinam o quadro de um estudo de necessidades de informação:
• Situação: Descreve o contexto espacial e temporal no qual ocorre a
necessidade de informação. É o momento em que o indivíduo “pára de
caminhar” porque seu senso interno se esgotou e um novo senso precisa ser
criado.
Centrando a Arquitetura de Informação no usuário
38
• Lacuna: Trata-se da dúvida do indivíduo, da questão propriamente dita. É a
falta de compreensão (conhecimento) ou a compreensão parcial de algo que
o obrigou a “parar”.
• Uso: É a ação que o indivíduo pretende executar empregando o
conhecimento que necessita.
• Ponte ou Estratégia: É o caminho cognitivo e construtivista percorrido
pelo indivíduo para encontrar a informação que necessita transpondo a
lacuna.
Analisando individualmente as situações, características, pensamentos e ações de
cada pessoa, um estudo na abordagem do Sense-Making tenta chegar a padrões comuns à
maioria. Nota-se, que no aparente caos apresentado por um indivíduo em seu caminho
cognitivo e construtivista, existe uma padronização que pode ser compartilhada com
outros.
Vale observar que a metáfora do Sense-Making é apenas uma forma de ordenar o
processo cognitivo dos seres humanos quando buscam uma informação.
É importante enfatizar que o Triangulo do Sense-Making é uma ferramenta meta-
teórica altamente abstrata e não é assumido como uma fotografia da realidade. Ele
não assume que toda criação de sentido (ex. buscando informação) é dotada de
propósito e seja linear. Nem assume que a criação de sentido requer recursos
além da própria pessoa, ou até o uso consciente de recursos. Apesar de que, ter
propósito, linearidade e busca consciente é o que os pesquisadores esperam de um
estudo de Sense-Making. (CHEUK, 1999)
A abordagem do Sense-Making foi escolhida como metodologia para essa pesquisa
porque ela permite detectar quais são os problemas (lacunas) que os arquitetos de
informação enfrentam em seus projetos (situações) e que procedimentos (estratégias)
utilizam para superá-los.
Introdução
39
1.3.3.1 Amostragem
Dentre os 93 entrevistados que responderam ao questionário on-line, 5 profissionais
compuseram a amostra da pesquisa de levantamento das dificuldades, técnicas e
metodologias encontradas em projetos de arquitetura de informações de websites. Foram
selecionados aqueles com maior experiência, ou seja, com maior tempo de trabalho na área
e que dedicam o maior percentual de seu tempo de trabalho a Arquitetura de Informação.
Segundo ALRECK e SETTLE (apud FERREIRA, 1995, pág. 86) “uma amostra
aparentemente pequena é perfeitamente aceitável quando a pesquisa: (a) requer muito
esforço do informante e produz volume relativamente grande de informação; (b) focalizar
mais nos padrões estabelecidos entre as respostas do que nos itens observados
individualmente". Como ambos os casos se aplicaram à técnica de coleta de dados desta
pesquisa, considerou-se o tamanho da amostra suficiente.
Os seguintes critérios de seleção foram adotados para selecionar a amostra dessa
pesquisa:
• Participantes que atuam como profissionais em projetos de arquitetura
de informação: Como essa pesquisa visa compreender o trabalho dos
profissionais foram selecionados apenas os entrevistados que declararam ter
interesse profissional na área.
• Profissionais com naturalidade brasileira e residência no Brasil: O
objetivo da pesquisa é compreender o trabalho dos arquitetos de informação
brasileiro dentro da realidade brasileira.
• Profissionais com tempo de experiência de trabalho com Arquitetura de
Informação acima da média (5 anos ou mais) e que dedicam mais de
50% do seu tempo de trabalho para a Arquitetura de Informação: Esse
é o critério que definiu os arquitetos de informação experientes.
• Apenas um representante por empresa: Esse critério foi utilizado para
que a amostra tivesse maior diversidade. Nos casos de empresas com mais
Centrando a Arquitetura de Informação no usuário
40
de um profissional com condições de participar foi selecionado aquele que,
pelo nome do seu cargo, possui uma função de coordenação ou gerência
porque normalmente possui uma visão mais abrangente.
• A amostra precisa conter profissionais de mais de uma cidade: Para que
a amostra não fosse regionalizada foram selecionados profissionais de São
Paulo e do Rio de Janeiro, as cidades com maior concentração de
entrevistados na pesquisa de levantamento do perfil dos arquitetos de
informação das listas de discussão brasileiras. Nenhum profissional das
outras cidades atendeu aos demais critérios.
1.3.3.2 Coleta de Dados
Para coletar os dados nessa pesquisa foram realizadas entrevistas em profundidade
seguindo o roteiro apresentado no Anexo II e pré-testado. O roteiro inicia-se com algumas
perguntas de identificação do entrevistado com o objetivo de criar empatia com ele,
deixando-o a vontade para responder as questões das partes seguintes. Em seguida o roteiro
apresenta várias questões divididas em três fases:
• Fase I – Levantamento da metodologia
O objetivo das questões dessa fase foi identificar se o entrevistado adota uma
metodologia nos seus projetos de arquitetura de informação e descrevê-la criando um
ambiente propício para as questões da segunda fase. Para tanto foi solicitado que ele
descrevesse, utilizando cartões post-it, cada atividade que executa e a seqüência em que
elas aparecem ao longo do projeto. Essa descrição foi feita livremente pelo entrevistado,
sem inferências por parte do entrevistador.
• Fase II – Análise das dificuldades de um projeto
Nessa segunda fase do roteiro, o objetivo foi identificar as dificuldades que os
entrevistados enfrentaram em um projeto real e como as superaram. Para isso foi utilizada
a técnica de entrevistas de micro-momento da linha do tempo (micro-moment time line
interview), um método qualitativo que permite reconstruir com detalhes todo o caminho
Introdução
41
percorrido pelo entrevistado ao enfrentar uma situação no tempo-espaço. Justifica-se esta
escolha porque este é o método que melhor deriva dos conceitos teóricos da abordagem do
Sense-Making (DERVIN, 1992).
Esta técnica é baseada em entrevistas individuais e solicita a cada entrevistado que
descreva passo a passo tudo o que ocorreu em uma situação. Cada passo é analisado
separadamente para determinar os componentes do triângulo do Sense-Making, que
caracterizam a representação da necessidade de informação (a situação, a lacuna, o uso e a
estratégia). Com essas questões é possível identificar a tentativa do entrevistado em buscar
alguma informação, aprender algo, compreender melhor, ou fazer sentido da realidade.
No âmbito dessa pesquisa, a situação escolhida é um projeto de arquitetura de
informação do qual o entrevistado participou e que seguiu todas as atividades da
metodologia que descreveu na fase II. As lacunas foram as grandes dificuldades que
enfrentou no decorrer do projeto. Os usos foram a importância de superar cada dificuldade
na visão do entrevistado. As estratégias foram a maneira como o entrevistado superou a
dificuldade e as facilidades que teve no decorrer do projeto.
O micro-momento da linha do tempo tem se mostrado uma técnica bastante
versátil, já tendo sido aplicada a grande variedade de indivíduos em diferentes contextos,
como usuários de bibliotecas ou de sistemas multimídias buscando informações, doadores
de sangue em situação de doação, crianças e problemas de relacionamento com shows de
TV, entre outros. (DERVIN, 1983; FERREIRA, 1995). A técnica também é versátil com
relação à forma empregada para abordar os diferentes contextos vivenciados pelos
indivíduos.
• Fase III – Comparação da metodologia do entrevistado com o quadro
de referência proposto
Na terceira e última parte da pesquisa, o entrevistado foi convidado retomar o
desenho da sua metodologia feito na fase I da pesquisa e compará-lo com o quadro de
referência formulado na investigação teórica por meio de perguntas estimuladas.
Centrando a Arquitetura de Informação no usuário
42
No Anexo II está o roteiro da entrevista individual utilizado com as questões de
cada uma das fases identificadas. Foram realizadas duas entrevistas em caráter de pré-teste
para avaliar a compreensão do roteiro e a forma de aplicá-lo.
1.3.3.3 Análise dos dados coletados
As entrevistas com os arquitetos de informação foram filmadas e para analisá-las
foi utilizada a técnica de análise de conteúdo.
Esta técnica de análise vem sendo progressivamente utilizada para codificar
questões de pesquisas abertas e descrever tendências em contextos de comunicação
(AGARWAL apud FERREIRA, 1995). Ela também é sugerida por DERVIN (1992) para
analisar as entrevistas da técnica do micro-momento da linha do tempo como uma forma
de sistematizar os resultados e eliminar a subjetividade.
A análise de conteúdo é, segundo BARDIN (2000, pág. 42), “um conjunto de
técnicas de análise das comunicações visando obter, por procedimentos, sistemáticos e
objetivos de descrição do conteúdo das mensagens, indicadores (quantitativos ou não) que
permitam a inferência de conhecimentos relativos às condições de produção/recepção
(variáveis inferidas) destas mensagens”.
Trata-se de um processo no qual o material textual é analisado e categorizado
conforme seu conteúdo e a partir desta categorização é possível fazer inferências
respondendo as questões da pesquisa. A execução desse processo envolve três fases
distintas: pré-análise, descrição analítica e interpretação inferencial.
Na fase de pré-análise todo o material a ser analisado é organizado com o objetivo
de “tornar operacionais e sistematizar as idéias iniciais, de maneira a conduzir a um
esquema preciso do desenvolvimento das operações sucessivas, num plano de análise”
(BARDIN, 2000, pág. 95). Nessa fase escolhem-se os documentos que serão analisados,
formulam-se os objetivos e hipóteses, definem-se os indicadores e prepara-se o material.
Na fase de descrição analítica submete-se o material a procedimentos de
classificação e categorização executando-se as regras definidas na fase anterior
Introdução
43
(TRIVINÕS apud ABDALLA, 2003). Trata-se da fase mais longa de todo o processo
porque envolve realizar muitas operações normalmente intelectuais.
Por fim na fase de interpretação inferencial os resultados brutos são tratados de
maneira a serem significativos e válidos utilizando operações estatísticas. Neste momento
o pesquisador pode propor inferências e interpretar os resultados conforme os objetivos e
hipóteses previamente definidos (BARDIN, 2000).
No caso específico dessa pesquisa, a pré-análise consistiu em assistir os vídeos das
entrevistas para transcrever suas principais partes, organizar as anotações realizadas
durante a entrevista e registrar a metodologia de cada entrevistado desenhada com os
cartões post-it.
Na descrição analítica as entrevistas foram analisadas visando identificar as
situações, sentimentos, dificuldades e metodologias mencionadas para a criação de
categorias de análise. Depois cada entrevista foi analisada em profundidade para classificá-
la nessas categorias. Para facilitar a análise, as categorias foram organizadas em grupos
baseados no quadro de referência.
A Tabela 2 mostra as categorias de análise referentes às fases I e III do roteiro da
entrevista, seus grupos e as respectivas questões do roteiro que as originaram. Essas
categorias foram utilizadas para analisar as metodologias dos entrevistados.
A Tabela 3 apresenta as categorias de análise referentes a fase II do roteiro da
entrevista e também as respectivas questões do roteiro que as originaram. Essas categorias
foram utilizadas para analisar as dificuldades enfrentadas pelos entrevistados nos seus
projetos e estão divididas em grupos que correspondem aos componentes do triângulo do
Sense-Making (situação, lacuna, uso e estratégia).
Por fim, a interpretação inferencial consistiu em avaliar a quantidade de citações
das respostas dos entrevistados em cada categoria de análise, que foram organizadas em
tabelas para interpretação. Como a amostra da pesquisa é pequena não foram realizadas
análises estatísticas.
Centrando a Arquitetura de Informação no usuário
44
Tabela 2 - Categorias utilizadas para análise das metodologias dos entrevistados
Grupo
Categoria de análise
Questões do roteiro
Adoção de uma metodologia nos projetos de arquitetura de informação 8
Documentação dos procedimentos
14
Motivos para a falta de documentação dos procedimentos
14
Concordância com a seqüência das atividades da metodologia
13
Motivos para concordar com a sequencia das atividades da metodologia 13
Atividades ausentes na metodologia
15
Quantidade de projetos que seguem todas as atividades da metodologia 16
Motivos para alguns projetos não seguirem todas as atividades da
metodologia
17
Existência da fase de Pesquisa
7, 8, 9, 10, 11, 12, 37
Atividades na metodologia que correspondem a fase de Pesquisa 7, 8, 9, 10, 11, 12, 37
Profissionais que participam da fase de Pesquisa 7, 8, 9, 10, 11, 12
Participação do Arquiteto de Informação na fase de Pesquisa 7, 8, 9, 10, 11, 12
Variáveis pesquisadas 7, 8, 9, 10, 11, 12
Técnicas empregadas
7, 8, 9, 10, 11, 12
Fontes de informação
7, 8, 9, 10, 11, 12
Realização de pesquisas diretas com o usuário
7, 8, 9, 10, 11, 12
Qualidade das informações obtidas na fase de Pesquisa 7, 8, 9, 10, 11, 12
Existência da fase de Concepção
7, 8, 9, 10, 11, 12 38
Atividades na metodologia que correspondem a fase de Concepção
7, 8, 9, 10, 11, 12 38
Profissionais que participam da fase de Concepção
7, 8, 9, 10, 11, 12
Técnicas empregadas
7, 8, 9, 10, 11, 12
Documenta os conceitos e regras definidos para o website
7, 8, 9, 10, 11, 12
Freqüência de aplicação de testes de usabilidade nos projetos 7, 8, 9, 10, 11, 12, 42
Motivos para não aplicar testes de usabilidade nos projetos
7, 8, 9, 10, 11, 12, 42
Freqüência de aplicação de testes de Card Sorting nos projetos 7, 8, 9, 10, 11, 12, 42
Motivos para não aplicar testes de Card Sorting 7, 8, 9, 10, 11, 12, 42
Freqüência de aplicação de testes com Protótipos de Papel nos projetos 7, 8, 9, 10, 11, 12, 42
Motivos para não aplicar testes com Protótipos de Papel 7, 8, 9, 10, 11, 12 38, 42
Existência da fase de Especificação
7, 8, 9, 10, 11, 12, 39
Atividades na metodologia que correspondem a fase de Especificação
7, 8, 9, 10, 11, 12, 39
Profissionais que participam da fase de Especificação 7, 8, 9, 10, 11, 12
Documentos produzidos
7, 8, 9, 10, 11, 12
Existência de templates dos documentos 7, 8, 9, 10, 11, 12
Existência da fase de Implementação
7, 8, 9, 10, 11, 12 40
Atividades na metodologia que correspondem a fase de Implementação
7, 8, 9, 10, 11, 12, 40
Profissionais que participam da fase de Implementação 7, 8, 9, 10, 11, 12
Existência da fase de Avaliação
7, 8, 9, 10, 11, 12 41
Atividades na metodologia que correspondem a fase de Avaliação
7, 8, 9, 10, 11, 12, 41
Motivos para a não existência da fase 41
Fase de Implementação
Fase de Avaliação
Adoção de metodologia
nos projetos de
arquitetura de
informação
Fase de Pesquisa
Fase de Concepção
Fase de Especificação
Tabela 3 - Categorias utilizadas para análise das dificuldades enfrentadas pelos entrevistados
Grupo Categoria de análise Questões do roteiro
Fase no quadro de referência 19,20,21
Atividade em que ocorreu a dificuldade 19,20,21
Dificuldade
19,20,21
Motivos que geraram a dificuldade
22
Foco da questão 21
Uso
Importância de superar a dificuldade 23
Estratégia utilizada para superar a dificuldade
26,27,28,33,35,36
Grau de superação da dificuldade
24,25
Satisfação do Entrevistado
29,3
Satisfação do Contratante
31,32
Expectativa do que ajudaria superar a dificuldade 34
Estratégia
Situação
Lacuna
Design Centrado no Usuário
45
Capítulo 2
Design Centrado
no Usuário
Duas disciplinas, a Interação Humano-Computador e a Ciência da Informação,
vêm, nas últimas décadas, aprofundando os estudos sobre usuários, suas necessidades, seus
comportamentos e as tarefas que desempenham ao interagir com sistemas. Essas duas
disciplinas desenvolveram abordagens diferentes, mas complementares, para o design de
sistemas centrados no usuário, criando fundamentos teórico-metodológicos e diversas
técnicas próprias.
Tanto a abordagem de Design Centrado no Usuário da Interação Humano-
Computador quanto a da Ciência da Informação tem como princípio entender
profundamente as necessidades do usuário para construir sistemas que as atendam
plenamente. Assim conceituar necessidade é fundamental para compreender essas
abordagens.
O conceito de necessidade remete tanto a autores da Ciência da Informação, que se
referem a serviços e produtos de informação, como também de outras áreas, como a
Centrando a Arquitetura de Informação no usuário
46
ciência do Marketing, que tem por objetivo maior descobrir e atender necessidades através
da oferta e troca de produtos de valor (KOTLER, 1998).
Necessidade é um estado de ausência, de falta, um estado no qual alguém está
carente de algo básico e inerente a sua condição de vida. KOTLER (1998, pág. 27) afirma
que “necessidade humana é um estado de privação de alguma satisfação básica”. Entende-
se por satisfação básica as exigências que surgem das situações ou condições de vida,
como por exemplo, alimento, vestuário, abrigo, segurança, sentimento de posse ou auto-
estima.
LINE (1974) conceitua necessidade como a informação que um indivíduo precisa
ter, algo que irá favorecer sua pesquisa. Semelhante a definição do Marketing, é o que
suprirá seu estado de privação.
Junto com o conceito de necessidade surge o conceito de cliente, que o Marketing
define como o ser (pessoa, empresa, instituição, etc.) que está vivenciando um ou mais
estados de privação e por isso possui uma ou mais necessidades.
É importante observar que uma necessidade nasce das características da condição
de vida do cliente e por isso não pode ser criada por nenhuma entidade externa, como uma
empresa que lança novos produtos (KOTLER, 1998). Os seres humanos, por exemplo,
sempre tiveram a necessidade de se comunicar a longas distâncias porque vivem em
comunidades geograficamente distantes. Atualmente isso é resolvido com telefones
celulares, e-mails e diversas outras tecnologias de telecomunicações. Porém os seres
humanos já utilizaram, para atender essa mesma necessidade, o telégrafo, o correio e até
mesmo mensageiros a pé.
O objeto capaz de satisfazer uma ou mais necessidades, como o celular no exemplo
anterior, é definido como produto. Outros exemplos são um hambúrguer, uma calça, um
hotel ou até mesmo uma igreja. É comum a idéia de que um produto está associado a um
bem físico e tangível, porém essa é uma definição simplista do termo. Como o mais
importante em um produto é a sua capacidade de atender as necessidades, existem
inúmeros casos de produtos que não possuem um bem físico associado, como, por
Design Centrado no Usuário
47
exemplo, uma agência de viagens ou um website. Neles o benefício é entregue e a
necessidade é atendida sem que qualquer bem físico seja fornecido.
Segundo HOOLEY e SAUNDERS (1996, pág. 26) “os clientes não compram
produtos; eles compram o que o produto faz por eles.” Aos clientes interessa os benefícios
que obtém do uso do produto e não as suas características físicas ou técnicas. KOTLER
(1998, pág. 28) cita uma frase jocosa que ilustra bem a importância do benefício em um
produto: “Um carpinteiro não compra uma furadeira; compra um furo”.
Devido ao fato de que os benefícios vêm do uso do produto e não das suas
características físicas, uma mesma necessidade pode ser atendida por uma infinidade de
produtos, cada qual empregando uma tecnologia diferente na solução do mesmo problema.
HOOLEY e SAUNDERS (1996) ilustram isso citando o exemplo de um jardineiro que
deseja o gramado baixo. Ele pode comprar um cortador de grama ou sementes de uma
espécie que não cresce. PORTER (1986) inclusive recomenda que as empresas apliquem
esse olhar nos seus planejamentos estratégicos para descobrir produtos que possam
substituir os que fabricam e assim encontrar concorrentes ocultos.
O próprio sentimento de satisfação do cliente com um produto vem dos benefícios
que ele obtém com seu uso. Esse sentimento é resultante da diferença entre a expectativa
do cliente e o desempenho percebido com o uso. Se o cliente tinha uma expectativa maior
que o desempenho percebido fica insatisfeito, se sua expectativa era igual ao desempenho
fica satisfeito e se o desempenho superar suas expectativas fica altamente satisfeito ou
encantado (KOTLER, 1999).
Os únicos árbitros do grau de perfeição do atendimento proporcionado pela
organização são os próprios clientes. A qualidade dos bens e serviços oferecidos
no mercado será julgada pelos clientes com base no grau da qualidade de
atendimento das suas necessidades e desejos. Do ponto de vista dos clientes, um
produto ou serviço de qualidade é aquele que satisfaz a “adequação à finalidade”,
e não aquele que oferece um luxo desnecessário.
(HOOLEY e SAUNDERS, 1996, pág. 25)
Centrando a Arquitetura de Informação no usuário
48
Uma maneira comumente utilizada para aumentar a satisfação do cliente é criar
produtos que atendam a várias necessidades. Biscoitos vitaminados com alto valor
nutritivo, margarinas que previnem doenças cardíacas e sabonetes com hidratantes são
alguns exemplos de produtos que atendem mais necessidades que o seu propósito básico.
A convergência de tecnologias em dispositivos móveis é outro exemplo. O telefone celular
integrado com câmera fotográfica, filmadora, MP3 player e agenda eletrônica é outro
exemplo de produto que atende a um amplo conjunto de necessidades e com isso aumenta
a satisfação de seus clientes.
Outros dois conceitos importantes para se compreender o que é necessidade são
desejo e demanda.
LINE (1974) define desejo como aquilo que o cliente gostaria de ter. Já KOTLER
(1999) define desejo como a vontade do cliente em utilizar um produto específico e
conhecido para atender as suas necessidades. Por exemplo, uma pessoa precisa de abrigo,
segurança e status social (necessidades) e deseja uma casa de três dormitórios e duas vagas
de garagem em um condomínio fechado (desejo). Os desejos são continuamente moldados
por forças e instituições sociais. Devido ao seu caráter tangível, é comum os clientes
manifestarem seus desejos e não suas necessidades.
Segundo KOTLER (1999), demanda é o desejo por um produto específico somado
a vontade e capacidade de comprá-lo. Para LINE (1974) demanda é aquilo que o indivíduo
manifesta querer, aquilo que ele solicita. Esse autor ainda acrescenta a definição de uso,
como aquilo que o indivíduo realmente utiliza. Na definição desses dois autores existe uma
relação causa-efeito, de forma que um uso é decorrente de uma demanda, de um desejo e
de uma necessidade.
Da vontade e capacidade de compra do cliente nascem os mercados e a relação
custo-valor do produto. Custo é o quanto o cliente precisa dar em troca do produto, quanto
paga por ele. Valor é a estimativa que o produto tem em satisfazer o seu conjunto de
necessidades. Quanto menor o custo e maior o valor, maior é a vontade do cliente em
comprar o produto.
Design Centrado no Usuário
49
Segundo ALMEIDA e OLIVEIRA (2002), o projeto bem sucedido de um website
nasce do conhecimento profundo dos seus usuários (seus clientes) e das suas necessidades.
Quanto maior o conjunto de necessidades que o website suprir, maior será a fidelização de
seus usuários. Dessa forma as metodologias de projetos de arquitetura de informação
precisam ter o mesmo olhar de quem está construindo um produto para atender as
necessidades de seus clientes.
Foi da preocupação com as necessidades dos usuários que surgiram as abordagens
de Design Centrado no Usuário tanto da Interação Humano-Computador quanto da
Ciência da Informação, que estão apresentadas a seguir.
2.1 O Design Centrado no Usuário na Interação Humano-Computador
Nascida como um subconjunto das teorias de ergonometria e interface homem-
máquina, as teorias sobre a Interação Humano-Computador (IHC) visam compreender
como ocorre o diálogo entre homens e computadores. Sua preocupação central é a
usabilidade das interfaces computacionais e, enquanto disciplina, ela se ocupa do design,
avaliação e implementação de sistemas de computação interativos para uso humano e com
o estudo dos principais fenômenos que cercam esses sistemas. (PREECE apud
MARTINEZ, 2002).
O campo da Interação Humano-Computador começou a se desenvolver com o
advento dos computadores pessoais nos anos 70, que reduziram drasticamente o custo
dessas máquinas tornando-as muito mais acessíveis. Antes dessa década, os computadores
eram muito mais caros que o custo das horas das pessoas que o operavam, o que restringia
seu uso apenas a engenheiros, técnicos e cientistas especializados em computação. A partir
da década de 70, com a invenção do primeiro computador pessoal, e mais tarde, nos anos
80, com a invenção do mouse e das interfaces gráficas, os computadores se popularizaram
passando a ser acessados por pessoas das mais diversas áreas de conhecimento. Para esses
novos usuários, leigos em informática, os computadores precisaram se tornar mais simples
e fáceis de usar, ou seja, com maior usabilidade (GARCIA, 2003).
Centrando a Arquitetura de Informação no usuário
50
Usabilidade é conceito chave na Interação Humano-Computador. A norma
ISO 9241-11 (apud USABILITY NET, 2003) a define como a capacidade na qual um
produto pode ser usado por usuários específicos para alcançar objetivos específicos com
efetividade, eficiência e satisfação num contexto específico de uso. É importante destacar a
preocupação que a usabilidade tem em restringir sua medição para casos específicos de
uso do sistema (“usuários específicos”, “objetivos específicos”, “contexto específico de
uso”). Se um sistema pretende atender qualquer usuário, com qualquer objetivo e em
qualquer ambiente dificilmente conseguirá atender a todos com a mesma usabilidade.
Segundo MARTINEZ (2002) para um mesmo usuário, o mesmo produto pode apresentar
diferentes características de usabilidade quando utilizado em ambientes diferentes ou com
objetivos diferentes.
Essa especificidade pode ser notada nos cinco atributos associados à usabilidade,
distintos e por vezes conflitantes, definidos por NIELSEN (1993):
• Facilidade de aprendizagem: Capacidade com que um usuário começar a
interagir rapidamente com o sistema logo na primeira vez que o utiliza.
• Eficiência de uso: Grau de produtividade atingido pelo usuário depois que
aprendeu a utilizar o sistema.
• Facilidade de memorização: Retenção, capacidade do usuário de voltar a
utilizar o sistema após certo tempo sem precisar aprendê-lo novamente.
• Baixa taxa de erros: Medida do quanto o usuário pode ser induzido ao erro
pelo sistema e o quanto pode se recuperar do mesmo.
• Satisfação subjetiva: Medida do quanto o usuário se sente feliz de estar
utilizando o sistema.
Normalmente não é possível privilegiar todos os atributos simultaneamente
[refere-se a esses 5 atributos de NIELSEN]. Às vezes os atributos podem não ser
compatíveis, implicando em que se tenha que priorizar um deles em detrimento de
outros. (...) Por isso, deve-se analisar o contexto do projeto e estabelecer os
Design Centrado no Usuário
51
objetivos de usabilidade a serem atingidos
3
e quais os atributos a serem
priorizados. Assim, se estabelece uma ordem de prioridade para os atributos de
modo a atender o público e a aplicação. (MARTINEZ, 2002, pág. 18)
Segundo MARCUS (2002) a melhoria da usabilidade em interfaces computacionais
traz diversos benefícios como:
• Economia nos custos e nos tempos de desenvolvimento;
• Redução dos erros dos usuários e dos custos de manutenção, redesign,
suporte (help-desk), treinamento e documentação;
• Aumento da satisfação do usuário, do volume de transações, das vendas, do
tráfego, do tamanho da audiência, do market share, das taxas de sucesso, da
eficiência e da produtividade;
• Retenção de clientes e atração de mais consumidores.
Na Web, objeto de estudo desse trabalho, a importância da usabilidade é maior que
nos softwares tradicionais. NIELSEN (2000) explica que os usuários na Internet
experimentam a usabilidade de um website antes de se comprometerem a usá-lo e a gastar
seu dinheiro com ele. Ocorre que, se o usuário não se sentir satisfeito com a usabilidade do
website, ele o abandona causando perda da receita financeira. No software tradicional isto
não ocorre porque o usuário primeiro compra o software para depois utilizá-lo. Assim, o
fabricante tem sua venda garantida mesmo em casos de insatisfação do cliente.
A preocupação com a construção de interfaces com alta usabilidade é o tema
central da Interação Humano-Computador e é de onde surgem as principais críticas dessa
disciplina aos processos de design tradicionais da Engenharia de Software, que são
“principalmente orientados ao produto, com foco na funcionalidade do sistema, geralmente
voltados ao desenvolvimento de grandes sistemas de software e oferecem pouca relação
entre o designer e as necessidades do usuário” (MARTINEZ, 2002).
3
Grifos da autora.
Centrando a Arquitetura de Informação no usuário
52
A literatura de IHC é permeada por críticas contundentes ao modelo de
implementação de interfaces existentes hoje, e à vitimização do usuário de
sistemas interativos. As descrições da relação entre homem e computador
encontradas em Cooper (1995, 1999), Norman (1990, 1993) e Nielsen (2000) são
sempre dramáticas e ricas em exemplos da dificuldade existente em se interagir
com os artefatos tecnológicos presentes no mundo, sejam eles maçanetas, relógios
ou computadores propriamente ditos. (MARQUES, 2002, pág. 24)
Para atingir seus objetivos a Interação Humano-Computador desenvolveu
fundamentos teórico-metodológicos para o design de interfaces computacionais centradas
no usuário. RUBIN (apud MARTINEZ, 2002, pág. 20) aponta os três princípios básicos
desses fundamentos:
1. Focalizar desde o começo no usuário e nas tarefas realizadas por ele, em
um determinado ambiente (não adianta saber quais funções o software tem
que executar sem saber quem é o usuário e porque precisaria dessas
funções).
2. Medidas empíricas da usabilidade do produto observando a interação do
usuário com ele (testes com usuários realizando tarefas representativas).
3. Utilizar um processo de design iterativo, com refinamentos sucessivos
(onde o design pode ser modificado após as fases de prototipação ou
testes), e análise de custo-benefício.
A partir desses princípios a Interação Humano-Computador desenvolveu e vem
aprimorando metodologias para projetos de Engenharia de Software como o modelo
estrela (HIX apud MARTINEZ, 2002) no qual todo o processo de design é centrado na
avaliação da usabilidade, de modo que várias medições da eficiência e eficácia do uso do
sistema para realizar as tarefas do usuário são feitas ao longo do projeto. Nessas
metodologias, a avaliação da usabilidade é realizada em todas as fases do projeto e não
apenas no final com o produto acabado como sugerem os processos de design tradicionais
da Engenharia de Software.
Design Centrado no Usuário
53
Na literatura são encontradas diversas recomendações de uso nos projetos de
Arquitetura de Informação das técnicas de avaliações de usabilidade provenientes da
Interação Humano-Computador (REISS, 2000; ROSENFELD e MORVILLE, 2002;
DIJCK, 2003; SAPIENT apud MORROGH, 2003; WODTKE, 2003; BUSTAMANTE,
2004). As técnicas mais citadas por esses autores seguem a abordagem da Discount
Usability de NIELSEN (1994) e estão detalhadas no capítulo 4.
Essa abordagem tem por objetivo reduzir o custo e o tempo de elaboração dos
testes de usabilidade e, para tanto, emprega métodos qualitativos e baseados em três
técnicas: avaliação heurística, construção de protótipos parciais para avaliar cenários e
testes com o usuário “pensando em voz alta”. A vantagem dessa abordagem é que suas
técnicas permitem avaliar a usabilidade de uma interface computacional nas fases iniciais
do projeto, como ocorre nos projetos de arquitetura de informação. Nesse momento
poucos recursos foram investidos e a correção dos erros é mais simples.
2.2 O Design Centrado no Usuário na Ciência da Informação
Desde meados do século passado a Ciência da Informação vem aprimorando seus
fundamentos teórico-metodológicos de forma a compreender melhor os padrões de
comportamento de busca de informação dos seres humanos para elaborar o design de
sistemas de informação de modo a fazer com que tais sistemas atendam melhor seus
usuários.
Os estudos de usuários, necessidades e usos da informação da Ciência da
Informação começaram no final da década de 1940 com a apresentação dos trabalhos de
Bernal e Urquart, que procuravam compreender o modo como cientistas e técnicos
buscavam informação e como utilizavam a literatura nas suas respectivas áreas. Desde
então tais estudos tornaram-se um objeto recorrente nessa ciência buscando encontrar uma
teoria e metodologia para suportá-los. SILVA e colab. (2002, pág. 132) citam que “a
caracterização da necessidade de informação é um campo clássico da Ciência da
Informação e da Biblioteconomia”. Apesar de ser um campo muito estudado, essas autoras
afirmam que ainda não existe consenso sobre a forma mais indicada para realizá-los.
Centrando a Arquitetura de Informação no usuário
54
Esses estudos atravessaram uma mudança de paradigma ao longo dos últimos 60
anos. Segundo FERREIRA
(1997), durante esse período os estudos de necessidade e uso
da informação evoluíram de uma abordagem centrada no sistema para uma abordagem
centrada no usuário, chamadas respectivamente de abordagem tradicional e abordagem
alternativa. Essa mudança de paradigma nasceu da preocupação dos novos pesquisadores
em compreender os aspectos cognitivos e comportamentais dos usuários quando estão
buscando informação (DERVIN e NEGAM, 1986).
Segundo DERVIN e NILAN
(1986), os estudos baseados na abordagem tradicional
têm as seguintes características:
• A informação é vista como algo objetivo, com significado constante e que
possui absoluta correspondência com a realidade.
• O usuário é um receptor passivo dessa informação objetiva. O papel dos
sistemas de informação é disponibilizar pacotes informacionais nas mãos
desse usuário. O usuário é um mero informante das características do
sistema. As reais necessidades que o motivaram a buscar a informação e o
uso que fará dela não são objetos de estudo.
• O objetivo desses estudos é encontrar mecanismos para descrever o
comportamento do usuário de uma forma trans-situacional, ou seja, que se
aplica idealmente a qualquer situação. Apenas as dimensões externas e os
comportamentos são observados.
• As perguntas formuladas nesses estudos têm como foco o sistema de
informação. Pesquisa-se quem o usa, quanto e como usa, mas não se
pesquisa para que ele é usado. Variáveis demográficas e sociográficas são
empregadas para descrever o uso desses sistemas, a satisfação do usuário e
as barreiras ao seu acesso. As perguntas mais comuns são: “Quem usa?”,
“O que usa?”, “Quando usa?”, “Onde usa?”.
• Utiliza-se técnicas quantitativas de pesquisa
Design Centrado no Usuário
55
Para FERREIRA (1997, pág. 6), de acordo com as revisões publicadas pelo
ARIST, os estudos da abordagem tradicional possuem os seguintes problemas
teórico-metodológicos:
i. Falta uniformidade conceitual nas pesquisas, termos como
informação, necessidade de informação e uso da informação tem
sido utilizado indiscriminadamente;
ii. Faltam definições e pressupostos claros para focalizar variáveis e
gerar questões de pesquisa e,
iii. Ausência de metodologias específicas, abrangentes e com rigor
científico.
A partir da década de 70 surgiram críticas aos paradigmas da abordagem
tradicional porque ela não considera as necessidades do usuário ao buscar a informação.
Para o usuário, a informação é uma ferramenta que resolve seus problemas porque lhe
transmite o conhecimento que lhe falta para realizar suas necessidades. Compreender estas
necessidades é entender a causa que o motivou a buscar informações. WILSON (2000)
confirma isto ao afirmar que uma pessoa começa um processo de busca de informação
simplesmente para atender suas necessidades, que são motivadas por fatores fisiológicos,
emocionais ou cognitivos, todos externos ao sistema de informação. Esse autor enfatiza
essa visão construtivista da informação ao sugerir que o termo “necessidade de
informação” seja substituído pelo termo “busca de informação para satisfazer
necessidades”.
Para DERVIN e NILAN (1986), a partir dessa preocupação em entender a
necessidade de informação mudou-se o paradigma da abordagem tradicional, trazendo
uma nova visão aos pesquisadores. Nessa nova visão, o usuário de um sistema de
informação passa a ser observado como um cliente e o seu comportamento e os seus
processos cognitivos tornam-se o foco dos estudos. Opondo-se a abordagem tradicional, a
abordagem alternativa possui uma visão mais holística do usuário, estudando suas
necessidades e a maneira como ele interage com o mundo para satisfazê-las. É essa visão
holística que se alinha com o conceito de necessidade do Marketing.
Centrando a Arquitetura de Informação no usuário
56
Ainda segundo esses autores, estudos que seguem a abordagem alternativa
caracterizam-se por:
• Ver a informação como algo construído pelos seres humanos através de
processos cognitivos internos do indivíduo.
• Considerar os usuários seres ativos que estão constantemente construindo
significado para as informações que encontram. Seres livres (dentro das
limitações dos sistemas) para criar a partir do sistema e das situações que
escolherem
• Buscar compreender como as pessoas constroem sentido e formar uma
visão holística de suas experiências. Focam-se no usuário, em entender suas
situações particulares de uso de informação e no que ocorre antes e depois
das suas interações com o sistema.
• Formular perguntas na pesquisa que nascem dos usuários, da visão que eles
têm do sistema de informação e de como e porque eles o utilizam.
Perguntas comuns são: “Por que alguém usa?”, “O que acha que o sistema
oferece de útil?”, “Como os usuários definem suas necessidades em
diferentes situações?”, “Como eles apresentam suas necessidades ao
sistema?”, “Como os usuários fazem uso do que o sistema oferece?”.
• Utilizar técnicas qualitativas de pesquisa
A abordagem alternativa tem sido pesquisada por diversos autores em diferentes
vertentes. FERREIRA (1997) cita as seguintes, consideradas as mais expressivas:
a) Abordagem de “Valor Agregado” de Robert Taylor – User-Values
ou Value-Added
b) Abordagem do “Estado de Conhecimento Anômalo” de Belkin e
Oddy – Anomalous State-of-Knowledge
Design Centrado no Usuário
57
c) Abordagem do “Processo Construtivista” de Carol Kuhlthau –
Constructive Process Approach
d) Abordagem “Sense-Making” de Brenda Dervin
Ainda segundo FERREIRA (1997, pág. 15), “enquanto as abordagens de Taylor,
Kuhlthau, Belkin e Oddy e têm contribuído com argumentos conceituais e teóricos
profundos para o paradigma alternativo dos estudos de usuários, DERVIN vai além
apresentando um método bastante elucidativo para mapear necessidades de informação sob
a ótica do usuário”.
O trabalho da Arquitetura de Informação, segundo ROSENFELD e MORVILLE
(2002) consiste em compreender e atender três dimensões de variáveis. A primeira são os
usuários, suas necessidades, tarefas, hábitos e comportamentos. A segunda são as
características do conteúdo que será apresentado (objetivo, uso, volume, formato,
estrutura, governança, dinamismo). Por fim a terceira são as especificidades do contexto
de uso do sistema de informação (objetivo do website, cultura e política da empresa,
restrições tecnológicas, localização, etc.).
Assim, das abordagens oferecidas pela Ciência da Informação, a abordagem
alternativa é a que melhor espelha o trabalho da Arquitetura de Informação. A sua visão
situacional se alinha com a preocupação da Arquitetura de Informação em entender o
contexto de uso da informação. A sua preocupação em compreender holisticamente a
experiência do usuário vai ao encontro da necessidade que a Arquitetura de Informação
tem de conhecer seus usuários, suas motivações e seus comportamentos. Por fim a sua
idéia de que a informação é algo construído pelo usuário se alinha com a preocupação da
Arquitetura de Informação em compreender detalhadamente os conteúdos que oferece aos
seus usuários e que usos fazem deles.
A abordagem tradicional se opõe a tudo isso. Sua característica trans-situacional
não é capaz de oferecer meios para explicar a contextualização, as influências que cada
situação de uso traz para a compreensão da informação. A sua visão passiva do usuário
não é capaz de explicar a maneira com que ele procura informação na Web e constrói
significado ao utilizá-la. A navegação na Web é um ato interativo e construtivo
Centrando a Arquitetura de Informação no usuário
58
representado na escolha “por qual link seguir” feita pelo próprio usuário. E por último, sua
visão da informação como algo objetivo, com significado constante não traduz o fato de
que diferentes grupos de usuário têm necessidades, compreensões e usos diferentes para a
mesma informação.
2.3 Síntese
Tanto a abordagem de Design Centrado no Usuário da Interação Humano-
Computador quanto da Ciência da Informação buscam conhecer e atender o usuário tendo-
o no centro das decisões ao realizar o design de seus sistemas. Porém cada uma dessas
abordagens possui princípios próprios, mas que se complementam.
A Interação Humano-Computador tem como foco compreender como o usuário
executa suas tarefas ao interagir com as interfaces computacionais e por isso apresenta
uma visão mais operacional, voltada principalmente ao uso do sistema. Através das suas
avaliações de usabilidade, essa disciplina busca mapear as dificuldades dos usuários nas
suas tarefas para tornar o uso das interfaces computacionais mais fácil e intuitivo.
A Ciência da Informação, de forma complementar, buscam compreender toda a
situação e o comportamento do usuário na sua busca de informação, antes, durante e
depois da sua interação com o sistema. Por isso essa ciência apresenta uma visão mais
holística do usuário, de suas necessidades e de como ele se relaciona com o mundo, fruto
de um pensamento mais reflexivo.
Essas duas disciplinas podem trazer importantes contribuições para a Arquitetura
de Informação, fornecendo técnicas e fundamentação teórica para a sua metodologia de
projetos. A abordagem da Interação Humano-Computador pode contribuir com técnicas
para identificar as tarefas dos usuários e avaliar seu uso do website. Já a abordagem de
Design Centrado no Usuário da Ciência da Informação pode contribuir com técnicas para
realizar pesquisas mais abrangente sobre os usuários e suas necessidades.
Arquitetura de Informação de websites
59
Capítulo 3
Arquitetura de Informação
de websites
Nascida em 1969, graças a programas de pesquisa científica e militar nos Estados
Unidos, a Internet é uma grande rede com milhões de computadores conectados que se
impregnou na vida da nossa sociedade contemporânea. Entre todos os serviços oferecidos
por essa rede, o mais popular é o Word Wide Web (apelidado de WWW ou Web), que
permite o acesso fácil a um sistema de páginas de hipertexto multimídia hospedadas em
milhões de computadores espalhados por todo o mundo. Cada uma destas páginas de
hipertexto é denominada de webpage (ou página web) e o lugar virtual na rede onde estão
hospedadas é denominado website (ou simplesmente site). Cada website e cada webpage
são identificados por meio de um endereço eletrônico virtual denominado URL (Uniform
Resource Location) e são acessados por meio de softwares específicos, os browsers.
Distribuídos gratuitamente, os browsers são fáceis de usar e popularizaram o uso da
Internet porque permitem que um usuário comum consiga navegar pelas webpages através
de uma interface gráfica simples, baseada em janelas e com o uso de um mouse.
O crescimento da Web a transformou em um gigantesco ambiente informacional.
Segundo a NETCRAFT (2007) atualmente existem mais de 108 milhões de websites e
Centrando a Arquitetura de Informação no usuário
60
surgem mais de um milhão de novos websites todos os meses. Porém sua grande
flexibilidade e seu crescimento desordenado tornaram a Web um sistema extremamente
desorganizado e heterogêneo se comparado a outros sistemas de informação. Sua
diversidade de conteúdos, formatos e audiência complicam muito a tarefa de indexar e
procurar informação nela.
A rede é como uma imensa biblioteca vandalizada. Alguém destruiu o catálogo e
removeu capas, índices, etc. de centenas e milhares de livros, rasgou-os e
espalhou o que sobrou... “Surfar”
4
é o processo de peneirar essa massa
desorganizada na esperança de cruzar com fragmentos úteis de texto e imagem
que podem ser relacionados a outros fragmentos. A rede é ainda pior que uma
biblioteca vandalizada porque milhares de fragmentos desorganizados são
adicionados diariamente pelos milhões de excêntricos, sábios e pessoas com tempo
em suas mãos e que lançam suas mensagens sem filtro no ciberespaço.
(GORMAN apud MORROGH, 2003, pág. 99)
Em meados do anos 90, com os grandes investimentos das empresas para
desenvolver seus websites e novos negócio na Web, a forma de desenvolvimento de
websites evoluiu para metodologias formais e multi-disciplinares. Foi nesse momento que
surgiram as primeiras tentativas de aplicar conceitos de Arquitetura de Informação no
design de websites com o objetivo de melhorar a organização das suas informações. Em
1994, Louis Rosenfeld e Peter Morville, ambos com formação em Ciência da Informação
e Biblioteconomia, fundaram a Argus Associates, a primeira empresa dedicada
exclusivamente a trabalhar com Arquitetura de Informação na Web. A ação pioneira da
Argus logo foi seguida por outras empresas especializadas em projetos de websites como a
Sapient, Scient, Viant, Agency.com, IXL, marchFIRST, Rare Medium, Zefer, Luminant e
Razorfish. Todas elas adotaram formalmente a Arquitetura de Informação como uma
disciplina necessária para a execução de seus projetos.
4
Surfar é uma gíria utilizada entre os usuários de Internet que significa navegar, percorrer as páginas de
hipertexto na web.
Arquitetura de Informação de websites
61
O termo Arquitetura de Informação, porém, surgiu bem antes da popularização da
Internet. Ele foi criado por WURMAN, em 1976, para denominar seu trabalho de tornar a
informação mais compreensível. Sua motivação foi a oferta explosiva de informação,
característica do nosso mundo moderno, que provoca nos usuários uma sensação de
distanciamento entre o que se compreende e o que se deveria compreender.
Essa sensação de distanciamento desperta nos usuários um sentimento de angústia,
de ansiedade provocado pela excessiva oferta de informação. O psicólogo britânico Davis
Lewis batizou os efeitos físicos, psicológicos e sociais da sobrecarga da informação sobre
um indivíduo de síndrome da fadiga da informação. Alguns dos seus efeitos são estresse,
tensão, distúrbios de sono, problemas digestivos, dificuldade de memorização,
irritabilidade e sentimento de abandono (ANTUNES, 1998).
A sobrecarga de informações, por causar distração e atraso em decisões, também
afetaria organizações (...), tornando-as menos eficientes e lucrativas. Isso pode
representar um grave problema, principalmente considerando-se que tal situação
pode tornar os funcionários ainda menos aptos a receber informação, agravando-
a cada vez mais, de maneira cíclica. (SATO e HASHIMOTO, 2004, pág. 12)
A Arquitetura de Informação surgiu para combater esse sentimento de ansiedade
com propósito de “organizar os padrões inerentes dos dados e criar a estrutura ou mapa da
informação de forma a permitir que outros encontrem seus próprios caminhos para o
conhecimento tornando o complexo claro” (WURMAN, 1997, pág. 16). Seus conceitos
foram inicialmente aplicados na organização de materiais gráficos, como guias, mapas e
Atlas, mas se espalharam por diversos outros campos, que vão desde a organização do
layout de museus até a estruturação de imagens radiográficas para uso médico
(WURMAN, 1997).
Em 1998, ROSENFELD e MORVILLE publicaram a primeira edição do livro
Information Architecture for the World Wide Web. A segunda edição foi publicada em
2002 e a terceira em novembro de 2006. Apelidado nas listas de discussão da área de livro
do “urso polar” (a capa tem o desenho desse animal), esse livro marca o início da
Arquitetura de Informação na Web e rapidamente se tornou a principal referência sobre o
assunto.
Centrando a Arquitetura de Informação no usuário
62
A primeira conferência internacional sobre Arquitetura de Informação da American
Society for Information Science (ASIS) ocorreu em abril de 2000 com o nome Defining
Information Architecture (Definindo a Arquitetura de Informação). Desde então a ASIS
realiza anualmente o IA Summit, a mais importante conferência internacional sobre o
tema.
Em 2002 surgiu a primeira comunidade formal de profissionais de Arquitetura de
Informação, o Asilomar Institute for Information Architecture (AIfIA) que, em 2005,
mudou seu nome para Information Architecture Institute. Contando com mais de 1000
membros em 60 países, esse instituto “é uma organização sem fins lucrativos composta
por voluntários e dedica-se ao avanço e promoção da Arquitetura da Informação.”
(INFORMATION ARCHITECTURE INSTITUTE, 2005).
A Argus Associates encerrou suas atividades em março de 2001, junto com várias
das empresas citadas devido a estratégias de negócios imaturas que não conseguiram
atravessar a explosão da bolha da Internet. Mas os conceitos da Arquitetura de Informação
continuam a ser fundamentais no design de websites.
A Arquitetura de Informação recentemente emergiu como uma importante meta-
disciplina preocupada com o design, a implementação e a manutenção de espaços
digitais de informação para seres humanos acessarem, navegarem e usarem... O
termo tem sido utilizado por vários anos para descrever o mix de competências
requeridas para produzir recursos de informação que aumentam as habilidades
humanas de localizar informação.
(JOURNAL OF AMERICAN SOCIETY FOR INFORMATION SCIENCE &
TECHNOLOGY apud MORROGH, 2003, pág. 107)
3.1 O que é Arquitetura de Informação de websites?
Diante da complexidade do hipertexto torna-se necessário planejar e estruturar as
informações visando acessibilidade pelos usuários. Assim como no labirinto o Fio
de Ariadne marca o caminho para a volta de Teseu após matar o Minotauro, a
Arquitetura da Informação procura mapear o labirinto imprimindo certo grau de
Arquitetura de Informação de websites
63
ordem ao hipertexto. É um campo de trabalho bastante definido e seu alcance não
vai além do site, não se propondo a “organizar” a rede como um todo. É tanto
uma referência para o objetivo que se pretende atingir como para a saída. Permite
uma caminhada – ou navegação – que pode ser feita, mas também abre a
possibilidade de trilhar múltiplos caminhos que levem a um mesmo objetivo.
(LARA FILHO, 2003)
Apesar da sua evolução, a Arquitetura de Informação ainda segue a definição
criada originalmente por WURMAN: trata de organizar a informação para torná-la clara.
Na Web, esse objetivo se mantém: criar as estruturas de organização da informação
apresentada por um website para que o usuário consiga encontrar e compreender as
informações que necessita e desempenhar suas tarefas com facilidade.
No projeto de websites, a Arquitetura de Informação é responsável por definir a
estrutura, o esqueleto que organiza as informações sobre o qual todas as demais partes irão
se apoiar. WEST (2001) cita que “Arquitetura de Informação é a prática de projetar a
infra-estrutura de um website, especialmente a sua navegação”. SHIPLE (2001) afirma
que “Arquitetura de Informação é a fundação para um ótimo webdesign. Ela é o esquema
[blueprint] do website em cima do qual todos os outros aspectos são construídos – forma,
função, metáfora, navegação, interface, interação e design visual”. Por fim BELTON
(2003, pág. 143) cita que a “Arquitetura de Informação está atualmente emergindo como
uma disciplina que se preocupa com o desenvolvimento de abordagens sistemáticas para a
organização e apresentação de informação on-line”.
A Arquitetura de Informação não se preocupa apenas com a organização da
informação, mas também com a sua apresentação. Ela cria no website um ambiente de
informação por onde o usuário pode se mover (navegar) para, como em uma biblioteca,
encontrar as informações que precisa de forma organizada.
A idéia da criação de um ambiente pelo qual o usuário se move faz com que
autores como BELTON (2003), CHIOU (2003) e MORROGH (2003) comparem a
Arquitetura de Informação com a Arquitetura, usando esta última como metáfora para
explicá-la. Em ambas o objetivo é balancear forma e função para criar um novo espaço,
um novo ambiente que seja útil, agradável e que atenda as necessidades dos seus usuários.
Centrando a Arquitetura de Informação no usuário
64
Atender as necessidades de informação dos usuários é o grande objetivo da
Arquitetura de Informação e é o que justifica a sua preocupação em seguir abordagens de
Design Centrado no Usuário. DIJCK (2003, pág. 3) mostra isso ao citar que “o trabalho
principal do arquiteto de informação é organizar a informação em um website para que os
usuários consigam encontrar as coisas e alcançar seus objetivos". TOUB (2000, pág. 2)
corrobora ao afirmar que “Arquitetura de Informação é a arte e a ciência de estruturar e
organizar ambientes de informação para ajudar as pessoas a satisfazerem suas
necessidades de informação de forma efetiva”.
Na definição de TOUB se observa a dicotomia entre “ciência” e “arte” da
Arquitetura de Informação. No seu lado “ciência”, a Arquitetura de Informação busca criar
um corpo teórico para embasar as suas técnicas. Porém a quantidade de variáveis
envolvidas nos projetos é tão grande que, na prática, é impossível não ter decisões
subjetivas, fazendo dela também uma “arte” (MORVILLE, 2005).
O objetivo de realizar o design de estruturas informacionais com o propósito de
facilitar a busca de informação pelo usuário e a dicotomia entre “ciência” e “arte” também
é visto na definição do INFORMATION ARCHITECTURE INSTITUTE (2005) sobre o
que é Arquitetura de Informação:
1. O design estrutural de ambientes de informação compartilhados.
2. A ciência e a arte de organizar e rotular websites, intranets, comunidades
on-line e softwares para dar suporte à usabilidade e facilidade de
encontrar informação.
3. Uma comunidade de práticas emergentes, focada em trazer princípios do
design e arquitetura para o ambiente digital.
Por fim o livro do urso polar (ROSENFELD e MORVILLE, 2002) une todos esses
conceitos e define Arquitetura de Informação como:
1. A combinação dos esquemas de organização, rotulação e navegação
dentro de um sistema de informação.
2. O design estrutural do espaço informacional para facilitar a completude
das tarefas e o acesso intuitivo ao conteúdo.
Arquitetura de Informação de websites
65
3. A arte e a ciência de estruturar e classificar websites e intranets para
ajudar as pessoas a encontrar e gerenciar informação.
4. Uma disciplina emergente e uma comunidade de prática focada em trazer
princípios do design e arquitetura ao espaço digital.
Segundo ROSENFELD e MORVILLE (2002), a Arquitetura de Informação busca
compreender e atender três dimensões de variáveis para organizar a informação. A
primeira dimensão são os usuários, suas necessidades, hábitos e comportamentos. A
segunda dimensão são as características do conteúdo que será apresentado (volume,
formato, estrutura, governança, dinamismo, etc.). Por fim a terceira dimensão são as
especificidades do contexto de uso do sistema de informação (objetivo do website, cultura
e política da empresa, restrições tecnológicas, localização, etc.).
Esse trio, usuário-conteúdo-contexto, e suas interdependências são únicos para
cada website. O papel do arquiteto é conseguir balanceá-lo para que a informação certa
seja acessada pela pessoa certa no momento certo. É uma aplicação moderna das leis da
biblioteconomia de Ranganathan (apud GOMES e colab., 2006): “Livros são para Uso”,
“Para cada Leitor, seu Livro”, “Para cada Livro, seu Leitor”, “Poupe o tempo do Leitor” e
“A Biblioteca é uma organização em crescimento”.
Um projeto de arquitetura de informação produz, como produto final, documentos
que especificam toda a organização informacional do website (DIJCK, 2003) com duas
características básicas:
• Registrar as regras de classificação, ordenação, navegação, rotulação e
busca do website;
• Demonstrar a aplicação dessas regras nos conteúdos e serviços do website,
gerando mapas de navegação (sitegramas e fluxos de navegação), esquemas
das páginas (wireframes) e o vocabulário controlado.
A documentação das regras registra o modelo mental do projetista e é utilizada
para manter a consistência nas manutenções futuras. A documentação da aplicação das
regras demonstra sua viabilidade para os conteúdos e transações do website no contexto
Centrando a Arquitetura de Informação no usuário
66
do projeto e formam a especificação técnica necessária para os responsáveis pela sua
implementação (webdesigners, redatores, programadores, etc.).
Por ser um campo novo, as definições apresentadas sobre a Arquitetura de
Informação e seus produtos ainda não são permanentes e expressam apenas parte das
atribuições de um arquiteto de Informação (INFORMATION ARCHITECTURE
INSTITUTE, 2005). Segundo REISS (2000) o primeiro IA SUMMIT foi uma boa
demonstração da dificuldade de definir esse campo. Esse evento teve por objetivo
construir essa definição, porém não conseguiu que seus 400 participantes chegassem a um
consenso sobre o que é Arquitetura de Informação e o que exatamente um arquiteto de
informação faz.
3.1.1 Um exemplo
O exemplo a seguir, extraído do livro Ansiedade de Informação do WURMAN
(1991, pág. 286) ilustra o trabalho de um arquiteto de informação. Trata-se de um mapa
elaborado para a mídia impressa, mas que apresenta de forma simples os conceitos da
Arquitetura de Informação.
Na figura a seguir estão duas versões do mapa da linha férrea de Yamanote, que
circunda a cidade de Tóquio. O mapa da esquerda está em escala real e mostra todas as
curvas que o trem faz ao longo do seu trajeto. O mapa a direita é o resultado do trabalho
de um arquiteto de informação que o redesenhou para os usuários dessa linha. Apesar de
mais abstrato, o segundo mapa é mais eficiente que o primeiro para quem utiliza a linha
Yamanote. Passageiros de trem estão num contexto onde não lhes importa quais são as
curvas que o trem faz entre as estações simplesmente porque eles não têm nenhum
controle sobre o movimento do trem, não conseguem pará-lo, direcioná-lo nem subir ou
descer entre as estações. Para eles a informação que interessa é a seqüência e a
identificação das paradas.
O mapa da direita apresenta exatamente e somente isso. Sua forma circular
também enfatiza que o trem circunda toda a cidade. E como o Palácio Imperial é um
importante ponto de referência em Tóquio, ele esta destacado. O desenho do mapa
Arquitetura de Informação de websites
67
também se assemelha com o símbolo do Yin Yang, que traz uma forte identificação
cultural para os povos orientais.
Figura 2 - Mapas da linha de trem Yamanote em Tóquio (WURMAN, 1991)
3.1.2 Por que a Arquitetura de Informação é importante?
Para que todo o investimento feito na produção de um website tenha retorno é
necessário que o mesmo seja fácil de aprender e usar.
Com cerca de 10 milhões de websites na Web em janeiro de 2000 (...), os usuários
nunca tiveram tantas opções. Por que devem desperdiçar seu tempo em websites
confusos, lentos ou que não satisfaçam às suas necessidades? Realmente, por quê?
Como resultado dessa quantidade esmagadora de opções e facilidade de ir para
outros websites, os usuários da Web demonstram uma notável impaciência e
insistência na gratificação instantânea. Se não conseguirem descobrir como usar
um website em aproximadamente um minuto, concluem que não vale a pena gastar
seu tempo. E saem. (NIELSEN, 2000, pág. 10)
A organização das informações é um dos principais problemas que afeta o uso dos
websites. Pesquisas do NIELSEN NORMAN GROUP (2001) apontam que 27% das
Centrando a Arquitetura de Informação no usuário
68
causas de insucesso das vendas de um website de comércio eletrônico são porque o
usuário simplesmente não conseguiu encontrar o item que procurava.
Falhas na organização dificultam a utilização de um website porque, ao não
encontrar a informação que deseja, o usuário fica confuso, frustrado e irritado, o que faz
com que ele não alcance seus objetivos, repercutindo diretamente no retorno do
investimento (ROSENFELD e MORVILLE, 2002).
Categorização tem conseqüências. Uma seção com um rótulo confuso num website
de referências médicas pode impedir o médico de encontrar uma nova pesquisa
que salvará a vida de alguém. Um website de uma universidade mal organizado
desencoraja um estudante pobre que pode pensar que não existem ajudas
financeiras para estudar lá, e uma loja virtual confusa resulta em perda de vendas.
(WODTKE, 2003, pág. 118)
MORVILLE (2004) cita que a Arquitetura de Informação afeta diretamente os
custos de encontrar uma informação e de não encontrá-la, os custos de construção e
manutenção dos websites, os custos de treinamentos de funcionários e até a valorização da
marca.
Estudo do IDC (FELDMAN e SHERMAN, 2001) aponta que, internamente nas
empresas, os custos relativos à busca de informação inexistente, a falhas em encontrar
informação existente ou para recriar informação não encontrada é da ordem de 15 milhões
de dólares.
Enquanto os custos de não encontrar informação são enormes, eles estão
escondidos dentro da empresa, e por isso eles são raramente percebidos como
tendo impacto nos resultados finais. Decisões são geralmente problemas
informacionais. Se elas são tomadas com informação pobre ou errônea, elas
colocam a vida da empresa numa aposta.
(FELDMAN e SHERMAN, 2001, pág. 9)
Por fim, a Tabela 4, que resume uma pesquisa da VIVIDENCE RESEARCH
(2001) realizada com 69 websites sobre seus problemas mais comuns, mostra a
importância da Arquitetura de Informação. Nota-se que a Arquitetura de Informação é
Arquitetura de Informação de websites
69
responsável por cinco dos sete grandes problemas mais comuns nos websites: resultados
de busca mal organizados, arquitetura de informação pobre, home-page desorganizada,
rótulos confusos e navegação inconsistente.
Tabela 4 - Problemas mais comuns nos websites (VIVIDENCE RESEARCH, 2001)
Problema
Percentual de websites
Como este problema afeta o usuário
* Resultados de busca
mal organizados
53% - Frustração
- Perda de tempo
* Arquitetura de
informação pobre
32% - Confusão
- Caminhos sem saída
- Uso excessivo dos botões voltar e avançar do browser
- Força o usuário a usar o mecanismo de busca
Desempenho lento 32% - Interrupção constante na experiência de compra
- Frustração
* Home-Page
desorganizada
27% - Cria desinteresse
- Perda de tempo
* Rótulos confusos 25% - Confusão
- Erros
- Uso excessivo dos botões voltar e avançar do browser
- Força o usuário a usar o mecanismo de busca
Processo de registro
invasivo
15% - Usuários são apenas números
- Visitante se sente ressentido
- Perda de tempo e esforço para entrar com os dados
* Navegação
inconsistente
13% - Caminhos ineficientes
- Força o usuário a se focar na navegação, não no uso.
- Perda da estabilidade percebida
- Funcionalidades úteis não são encontradas
* Os problemas destacados são relacionados com a Arquitetura de Informação.
3.1.3 A multi-disciplinariedade da Arquitetura de Informação
Segundo LATHAM (2002), definir um corpo teórico é um aspecto fundamental
para qualquer profissão se legitimar. Para esse autor, a falta de um corpo teórico faz com
que o profissional comece cada novo problema sem uma referência, o que coloca seu
trabalho mais próximo de um artesão que de um especialista.
No seu atual estágio de evolução, a Arquitetura de Informação ainda é um campo
novo, que busca se definir e formar seu corpo teórico. Para tanto está utilizando uma
abordagem multi-disciplinar, como mostra o diagrama das disciplinas relacionadas com o
design de sistemas de informação na Web proposto por ROSENFELD (2001) e
apresentado na Figura 3. Disciplinas com corpos teóricos já estabelecidos fornecem
ferramentas, técnicas, experiência e credibilidade para as novas disciplinas como a
Arquitetura de Informação. Essas novas disciplinas unificam os métodos e técnicas em
uma nova forma de pensar.
Centrando a Arquitetura de Informação no usuário
70
Figura 3 – Disciplinas que colaboram na formação do corpo teórico
da Arquitetura de Informação (ROSENFELD, 2001)
LATHAM (2002) aponta esse caráter multi-disciplinar ao sugerir cinco áreas
chaves para a formação do arquiteto de informação: organização da informação, designer
gráfico, ciência da computação, usabilidade e comunicação.
A GSIS-UTA, Graduate School of Library and Information Science at the
University of Texas at Austin, ao avaliar o currículo de seu curso de Arquitetura de
Informação, examinou o currículo de seis respeitadas universidades que oferecem cursos
de especialização nessa área e encontrou, apesar das diferenças de nomenclatura, sete
áreas fundamentais para a formação do arquiteto de informação (MORROGH, 2003). São
elas:
• Sistema de Informação / Gerenciamento / Organização
• Busca e recuperação da informação
• Gerenciamento de banco de dados
• Metodologia de pesquisa / Estatística
• Interação Humano – Computador
• Rede de Computadores
• Gerenciamento de Projetos
Arquitetura de Informação de websites
71
O motivo da multi-disciplinariedade da Arquitetura da Informação vem da riqueza
de aplicações que esse novo campo está encontrando na sua evolução (WURMAN, 1997)
e dos diferentes públicos com que o arquiteto de informação se relaciona durante um
projeto (DIJCK, 2003).
O arquiteto de informação deve agir como um mediador entre cliente, usuário,
áreas de negócio, designers gráficos e programadores. Ele irá dirigir uma grande
variedade de atividades desde a análise de conteúdo até pesquisas de focus group
e modelagem de webpages. O arquiteto de informação efetivo tem um arsenal de
habilidades técnicas misturadas com uma eficiente comunicação interpessoal, que
coloca ele no centro de uma complexa teia de comunicação entre diferentes visões
e idéias. O arquiteto de informação desempenha o papel de um diplomata
mantendo a coesão entre os membros do time e assegurando que o projeto
permaneça no prazo e alcança seus objetivos.
(EWING e colab., 2002)
3.2 Os componentes da arquitetura de informação para Web
ROSENFELD e MORVILLE (2002) dividem a arquitetura de informação de um
website em quatro grandes sistemas interdependentes, cada um composto por regras
próprias e aplicações. Juntos eles reúnem todos os elementos de interação do usuário com
o ambiente informacional do website e servem de modelo para organizar o trabalho do
arquiteto. São eles:
• Sistema de Organização (Organization System): Define o agrupamento e
a categorização de todo o conteúdo informacional.
• Sistema de Navegação (Navegation System): Especifica as maneiras de
navegar, de se mover pelo espaço informacional e hipertextual.
• Sistema de Rotulação (Labeling System): Estabelece as formas de
representação, de apresentação, da informação definindo signos para cada
elemento informativo.
• Sistema de Busca (Search System): Determina as perguntas que o usuário
pode fazer e o conjunto de respostas que irá obter.
Centrando a Arquitetura de Informação no usuário
72
Vale notar que a divisão da arquitetura de informação nesses quatro sistemas é
apenas conceitual e destina-se a organizar o trabalho do arquiteto de informação. Todos
esses sistemas apresentam uma grande interdependência de modo que os problemas de um
deles normalmente afetam os demais. Apesar disso, analisá-los separadamente facilita a
busca das dificuldades de projetá-los porque cada um deles é conceituado com bases
teóricas advindas disciplinas diferentes.
Outros autores como WODTKE (2003), DIJCK (2003), SHIPLE (2001) e
BRINCK e colab. (2002) confirmam que o design dos três primeiros sistemas é
responsabilidade do arquiteto de informação, porém não citam o sistema de busca.
Juntos, os sistemas de organização, de navegação e de rotulação fornecem os
elementos necessários para o usuário executar a navegação pelas categorias e reúnem os
principais elementos de interação do usuário. Esses três sistemas formam a imagem do
sistema, que cria o modelo mental do funcionamento do website. Alterar esses sistemas
envolve a reorganização, reclassificação e readequação de todo o conteúdo, além de que
obriga o usuário a reaprender a utilizar o website.
O sistema de busca, ao contrário, pode ser visto como uma peça modular, que se
encaixa a qualquer momento no website. Essa modularidade é tão evidente que diversos
websites de busca, como o Google e Yahoo!, possuem serviços e tutoriais mostrando
como utilizá-los para criar o sistema de busca em qualquer website. Além disso, efetuar
ajustes no sistema de busca pós-projeto é relativamente simples e barato quando
comparado com os outros três sistemas, sendo inclusive uma prática recomendada para
melhorar a sua usabilidade (ROSENFELD e MORVILLE, 2002).
Desta forma, esse trabalho está focado apenas nos sistemas de organização, de
navegação e de rotulação porque esses são os sistemas mais importantes para se projetar a
estrutura de organização da informação de um website. O design do sistema de busca não
será considerado
5
.
5
Para mais informações sobre o design do sistema de busca veja ROSENFELD e MORVILLE, 2002, cap 8.
Arquitetura de Informação de websites
73
A seguir estão apresentados os principais fundamentos teóricos e as dificuldades
do projeto desses três sistemas.
3.2.1 Sistema de Organização
Os sistemas de informação possuem uma característica em comum e que justifica
todo o trabalho de Arquitetura de Informação: localizar informação em um espaço
organizado é mais fácil que em um espaço desorganizado. WODTKE (2003, pág. 89) cita
que “é um fato simples que quando você tem certa quantidade de coisas, você tem que
organizá-las. Do contrário, você não consegue achar nada.” LIMA (2003, pág. 83) afirma
que “a informação estruturada é mais fácil de ser recuperada do que a informação
desorganizada”.
Um website, como qualquer outro sistema de informação, precisa que as suas
informações estejam organizadas para que o usuário consiga encontrar facilmente o que
deseja. Websites desorganizados são verdadeiros jogos de caça-palavras que obrigam o
usuário a encontrar a informação que deseja no meio da bagunça causando-lhe frustração e
irritação. Ao acessar um website, o usuário quer resolver seus problemas, alcançar seus
objetivos e concluir suas tarefas. Não quer ser desafiado por um jogo de passatempo.
O sistema de organização é o componente da arquitetura de informação que tem
por função definir as regras de classificação e ordenação das informações que serão
apresentadas e aplicá-las categorizando
6
todos os conteúdos oferecidos (ROSENFELD e
MORVILLE, 2002). Seu principal desafio é organizar a informação de forma a torná-la
facilmente compreensível e que ajude o usuário a encontrar o que precisa para atingir seu
objetivo.
Porém categorizar informação envolve vários aspectos cognitivos e sócio-culturais
que tornam esse trabalho bastante subjetivo.
6
Segundo Lima (2003, pág 82) “muitos autores consideram os termos categorização e classificação como
sinônimos (Gardner, 1996; Jacob & Shaw, 1991; Smith & Medin, 1981).” Nesse trabalho esses termos
também são considerados sinônimos.
Centrando a Arquitetura de Informação no usuário
74
3.2.1.1 O que é categorizar?
Categorizar é agrupar entidades (objetos, idéias, ações, etc.) por semelhança. Essa
é uma habilidade natural que a mente humana usa para compreender o mundo ao seu
redor. JACOB e SHAW (1998, pág. 155) definem que “categorizar é o processo cognitivo
de dividir as experiências do mundo em grupos de entidades, ou categorias, para construir
uma ordem dos mundos físico e social em que o indivíduo participa.” MARKMAN (apud
JACOB e SHAW, 1998, pág. 155) complementa dizendo que “categorização é um
mecanismo cognitivo fundamental que simplifica a interação do indivíduo com o
ambiente: ela não apenas facilita o armazenamento da informação, mas também reduz a
demanda da memória humana”.
A preocupação da humanidade com a categorização remonta aos tempos de
Aristóteles e suas teorias sobre a classificação dos seres (LIMA, 2003). Na visão
aristotélica, uma categoria é um conjunto abstrato onde todos os elementos dentro desse
conjunto possuem propriedades em comum e os elementos fora dele não possuem tais
propriedades. “As categorias de Aristóteles, isso deve ser notado, estavam arranjadas em
uma maneira hierárquica, na crença de que existia uma hierarquia perfeita para o mundo –
tudo o que teríamos de fazer seria encontrá-la” (TAYLOR, 1999, pág. 174). Um dos
melhores exemplos contemporâneos de aplicação dessa teoria é o sistema de classificação
dos seres vivos utilizado na Biologia que os divide nas categorias hierárquicas Reino, Filo,
Classe, Ordem, Família, Gênero e Espécie.
Segundo TAYLOR (1999), essa teoria de Aristóteles, também chamada de teoria
clássica da categorização, permaneceu inalterada até meados do século XX quando
estudos de diversos autores a contestaram. LAKOFF (1990, pág. 6) cita que “essa teoria
clássica não era resultado de estudos empíricos. Ela nem era um assunto de maior debate.
(...) De fato, até muito recentemente, a teoria clássica das categorias não era nem
considerada como uma teoria. Ela era considerada em muitas disciplinas não como
hipóteses empíricas, mas como uma inquestionável e definitiva verdade”.
Arquitetura de Informação de websites
75
Segundo LAKOFF (1990) a teoria clássica possui duas implicações básicas:
1. As categorias são definidas apenas pelas propriedades comuns a todos seus
membros. Assim nenhum membro pode ser considerado um melhor
exemplo da categoria que os demais.
2. As categorias são definidas apenas pelas propriedades inerentes de seus
membros. Dessa forma, elas devem ser independentes de quem estiver
categorizando, ou seja, elas não devem ser influenciadas pelos movimentos
do corpo humano, pela neurofisiologia humana e pelas capacidades
humanas de percepção, aprendizado, lembrança e comunicação. Fatores
sócio-culturais também não devem influenciar a formação das categorias.
A partir da década de 50 diversos estudos começaram a contestar a teoria clássica
estabelecendo uma quebra de paradigma. Sintetizando LAKOFF (1990) e TAYLOR
(1999) temos um breve histórico desses estudos:
Wittgenstein, em 1953, propõe a idéia de semelhanças familiares (family
resemblances), na qual uma categoria pode ser formada não por um conjunto de
propriedades em comum, mas porque seus membros se assemelham. Esse autor cita como
exemplo a categoria “jogo” e afirma que nessa categoria não existe nenhum conjunto de
propriedades comum e exclusivas a todos os seus membros.
Austin, em 1961, estende os conceitos de Wittgenstein ao analisar o significado
das palavras. Esse autor descobre que nomeamos entidades diferentes pelo mesmo nome
porque elas possuem similaridade, ou seja, são parcialmente idênticas, indo contra a teoria
clássica (Ex: pé da montanha, pé da mesa, pé da pessoa. Apesar de todos terem “pé” não
estão na mesma categoria). Em outros casos as entidades estão na mesma categoria, mas
não possuem propriedades em comum. (Ex: bola, chuteira e juiz estão todos na categoria
futebol).
Zadeh , em 1965, cria a fussy set theory (teoria dos conjuntos confusos), na qual
aponta que em algumas categorias existe uma graduação na associação dos elementos. A
categoria “senador”, por exemplo, é muito bem definida (uma pessoa é senador ou não).
Centrando a Arquitetura de Informação no usuário
76
Mas categorias como “ricos” e “altos” possuem graduação porque existem pessoas mais
ricas e mais altas que outras. Nas categorias com graduação cada elemento tem uma
probabilidade de pertencer à categoria.
Lounsbury, em 1964, ao estudar o sistema de parentesco dos índios americanos
constatou a influência da cultura e da língua na formação das categorias. Contrariando a
teoria clássica, esse pesquisador constatou que o que parece definido e distinto em uma
cultura e língua não é percebido da mesma forma em outra cultura e língua.
Berlin e Kay, em 1969, em estudos sobre cores constataram que algumas línguas
utilizam menos termos para expressar as cores que os onze termos básicos do inglês e
também do português (preto, branco, vermelho, amarelo, azul, verde, marrom, roxo, rosa,
laranja e cinza). Nas línguas que utilizam menos termos, apesar de seus falantes
conseguirem diferenciar todas as onze as cores, não as expressam com nomes diferentes.
Algumas línguas, por exemplo, possuem apenas quatro termos básicos para as cores, onde
os três primeiros são equivalentes ao preto, branco e vermelho e o último é uma união do
amarelo, do azul e do verde.
Kay e McDaniel, em 1978, estenderam os estudos de Berlin e Kay e descobriram
que os termos usados para as cores em cada língua não são obras do acaso e sim
influenciados pela fisiologia humana. Esses autores aplicaram a fussy set theory em
estudos neurofisiológicos sobre a visão e encontraram as causas para diferentes culturas
nomearem as cores de formas diferentes.
Brown, em 1965, iniciou os estudos sobre categorias de nível básico (basic-level
categories). Ele observou que, apesar de todos os possíveis nomes para alguma entidade
existentes em uma hierarquia de categorias, há um nome em particular, em um nível em
particular, com um “status superior”. Por exemplo, um “cachorro” não é apenas um
“cachorro”. Ele pode ser também um “quadrúpede”, um “mamífero”, um “animal” se
olharmos para categorias superiores; ou um “cão de caça”, um “labrador” se olharmos
para categorias inferiores. Mas a categoria “cachorro” se parece mais com seu nome
natural. Esse “nome natural” é o que Brown definiu como categoria de nível básico porque
é o que se aprende mais cedo e é nele que as ações são distintas, as coisas são nomeadas
primeiramente, os nomes são mais curtos e usados com mais freqüência. Os demais níveis,
Arquitetura de Informação de websites
77
superiores ou inferiores, são “realizações da imaginação” (“achievements of the
imagination”).
Berlin e associados, em 1969 a 1977, estenderam a noção de categorias de nível
básico ao mostrar que existe um nível universal no qual os seres humanos nomeiam as
coisas. Esse nível, por exemplo, para plantas e animais é algo semelhante ao nível do
gênero. Conforme o grau de relacionamento de uma cultura com uma determinada
categoria pode haver influências que provocam alterações nesse nível universal. Culturas
urbanas, por exemplo, possuem categorias menos precisas para árvores que culturas rurais
porque as árvores participam menos da vida dos habitantes das cidades. Esse estudo
sugere que alguns níveis básicos de categorias surgem da maneira como o ser humano se
relaciona com elas e são os mesmos através das culturas.
A maior ruptura dos paradigmas da teoria clássica veio dos trabalhos de Rosch
(TAYLOR, 1999). Essa pesquisadora constatou que, ao contrário da teoria clássica,
categorias podem ter protótipos, itens que são melhores exemplos que os demais. Ela cita
como exemplo que as pessoas consideram o pardal um exemplo melhor de pássaro que o
avestruz e o pingüim.
Outra descoberta de Rosch é que a capacidade humana influencia a formação das
categorias. Por exemplo, para um homem com 1,70 metros de altura existem muito mais
pessoas altas no mundo que para um homem com 1,90 metros de altura, como indica a
fussy set theory. A experiência de vida também influencia na categorização. Um exemplo
são as categorias Ad Hoc, categorias feitas por um impulso de momento. Diferentes
pessoas colocam diferentes coisas na categoria “coisas que deve levar ao acampar”
conforme suas experiências, aonde vão, como acampam, etc.
Essas mudanças de paradigma na teoria da classificação influenciaram a
Biblioteconomia e a Ciência da Informação, especialmente na construção dos sistemas de
classificação.
Os primeiros sistemas de classificação, muitos dos quais utilizados até hoje,
inspiraram-se na teoria clássica de Aristóteles e criaram enormes hierarquias de categorias.
Centrando a Arquitetura de Informação no usuário
78
Exemplos são o Dewey Decimal Classification (1976), a Classificação Decimal Universal
(1885) e a Classificação da Biblioteca do Congresso Norte-Americano (1900).
Esses sistemas baseados na teoria clássica são mais adequados à preservação de
acervos do que a transferência de informação e conhecimento porque retratam bem apenas
relações do tipo gênero-espécie e dificultam a criação de novos conceitos a partir da união
de conceitos anteriores. Relações não hierárquicas como causa-efeito, produto-produtor e
agente-instrumento não são bem representadas nesses sistemas. (LARA, 2001)
Outros sistemas de classificação, que permitem retratar relações não hierárquicas,
surgiram quebrando o paradigma da teoria clássica de que existe uma única hierarquia
perfeita para mundo. O sistema de classificação por facetas (faced classification) ou multi-
dimensional proposto por Ranganathan
7
foi o primeiro passo nesse sentido. Esse sistema
classifica os assuntos segundo cinco dimensões de categorias diferentes chamadas de
facetas.
A noção de faceta é primordial para o desenvolvimento da teoria da classificação
já que, ao admitir a possibilidade de abordar diversos pontos de vista, começa a
se desvincular dos padrões de divisão do conhecimento calcados exclusivamente
nos sistemas filosóficos. A teoria da classificação começa a se desenvolver
aproximando-se da Lógica e, ao mesmo tempo, das necessidades mais concretas
dos usuários. Esse momento enuncia uma alteração de ênfase nos processos
tradicionais da Biblioteconomia, quando a preservação cede espaço para a
preocupação em transferência da informação. (LARA, 2001, parte I, pág. 14)
Outra importante evolução são os tesauros, linguagens documentárias cuja ênfase
são os objetivos e os conceitos. A Lingüística e a Lógica tem papel fundamental na
construção dos tesauros para criar suas redes lógico-semânticas que compreendem
7
O conceito de faced classification (classificação por facetas) ou classificação multi-dimensional surgiu
pela primeira vez nos trabalhos de Ranganathan para criar o Colon Classification (1933), onde ele propôs
um sistema com 5 dimensões básicas para classificação da informação: personalidade (foco ou assunto mais
específico), material, energia (atividade, processo ou operação), espaço (lugar) e tempo. (TAYLOR, 1999)
Arquitetura de Informação de websites
79
relações hierárquicas, associativas e de equivalência entre conceitos e estabelecer seu
sistema de significação.
Os tesauros constituem o primeiro instrumento documentário de representação
que trabalha com a noção de controle do vocabulário. São resultado do
reconhecimento de que operamos no universo da linguagem, o que significa dizer
que a transferência da informação está atrelada a sistemas de significação. O
controle é aqui entendido não sob a perspectiva da padronização, mas como o
mecanismo através do qual se busca estabelecer a interação dos sistemas com os
seus públicos. Sob esse aspecto, pode-se afirmar que são os tesauros os
instrumentos que com maior propriedade podem ser nomeados como linguagens
documentárias, já que se caracterizam pela preocupação de realizar efetivamente
a atividade de mediação.
(LARA, 2001, parte II, pág. 6)
Os sistemas de classificação, seja os baseados nas teorias clássicas ou os que a
contestam, possuem vasta aplicação atualmente. Seus usos abrangem a organização de
bibliotecas físicas e on-line, a Web semântica, o processamento de linguagem natural entre
outros
8
.
3.2.1.2 Dificuldades para organizar informação na Web
Observando os aspectos cognitivos da teoria da categorização elencados
anteriormente é possível compreender as dificuldades que os autores (WURMAN, 1991;
ROSENFELD e MORVILLE, 2002; WODTKE, 2003; DIJCK, 2003; BUSTAMANTE,
2004) apontam ao se organizar informação em websites. Essas dificuldades afetam
diretamente o design do sistema de organização e estão sintetizadas a seguir.
8
Maiores detalhes sobre os sistemas de classificação e suas aplicações fogem do escopo desse trabalho.
Centrando a Arquitetura de Informação no usuário
80
3.2.1.2.1 Ambigüidade
Como visto, a classificação de informações se baseia na linguagem humana, que é
naturalmente ambígua. “Um mesmo vocábulo pode ter múltiplas interpretações
dependendo do contexto onde é apresentado” (BUSTAMANTE, 2004).
A comunicação é equívoca. Somos limitados por uma língua na qual as palavras
podem significar uma coisa para uma pessoa e algo bem diferente para outra. Não
existe uma forma certa de se comunicar. Pelo menos em sentido absoluto, é
impossível partilhar nossos pensamentos com os outros, pois jamais serão
compreendidos de forma exatamente igual. (WURMAN, 1991, pág. 110)
A ambigüidade dificulta o design do sistema de organização em dois níveis: na
escolha de um rótulo (nome) que traduza eficientemente o conceito da categoria e na
definição de quais elementos pertencem a ela (ROSENFELD e MORVILLE, 2002). Nesse
ponto os sistemas de organização e de rotulação se relacionam porque a mudança de um
rótulo pode alterar todo o conceito de uma categoria obrigando a readequar os dois
sistemas.
3.2.1.2.2 Heterogeneidade
O conteúdo da Web é naturalmente heterogêneo. Ele mistura diversos tipos de
conteúdos (textos, imagens, vídeos, sons, etc.) em uma infinidade de formatos (html, pdf,
ppt, swf, js, etc.). Além disto, o nível de granularidade no acesso a informação também é
heterogêneo. Ao contrário das bibliotecas físicas, um website pode indexar ao mesmo
tempo um livro, um de seus capítulos, uma de suas tabelas, a coleção a que pertence ou até
as livrarias onde está a venda (BUSTAMANTE, 2004).
Essa heterogeneidade dificulta a criação de um sistema de organização único que
atenda a todo o website. Por isso é comum se dividir um grande website em pequenos sub-
sites, cada qual com uma organização diferente atendendo diferentes necessidades.
Arquitetura de Informação de websites
81
A natureza heterogênea dos websites torna difícil impor qualquer sistema único de
organização estruturada do seu conteúdo. Geralmente não faz sentido classificar
documentos em diferentes níveis de granularidade lado a lado. Um artigo e uma
revista devem ser tratados diferentemente. Da mesma forma, não deve fazer
sentido manusear vários formatos ao mesmo tempo. Cada formato tem suas
características únicas e importantes. Por exemplo, nós precisamos conhecer certas
coisas sobre imagens, como o formato do arquivo (GIF, TIFF, etc.) e resolução
(640 x 480, 1024 x 768, etc.). É difícil e muitas vezes errado tentar usar uma
abordagem que sirva para todos ao organizar a heterogeneidade do conteúdo de
um website. Esta é uma bandeira fundamental de muitas iniciativas empresariais
de taxonomia. (ROSENFELD e MORVILLE, 2002, pág. 53)
3.2.1.2.3 Diferenças de Perspectiva
Como visto anteriormente, toda organização de informação é afetada pela
perspectiva do seu criador, sua cultura e pela sua visão de mundo. WITHROW (2003)
afirma que “de um usuário para outro, as categorias podem diferenciar-se
significativamente. Algumas categorias são formadas com base em semelhanças visuais
(...), enquanto outras categorias podem ser baseadas num conjunto de regras para inclusão
e exclusão (...). Diferenças culturais, socialização e efeitos cohort (diferenças baseadas no
local onde alguém nasceu) também afetam o processo de categorização, criando mais
diversidade em como as categorias são formadas”.
WODTKE (2003) corrobora apontando que as experiências de vida e cultura de
quem está organizando a informação influenciam diretamente as categorias criadas.
Cada categorizador trás seu conhecimento de vida e prejulgamentos ao processo.
A categoria Religião do sistema decimal Dewey tem nove subdivisões, sete das
quais são sobre cristianismo. O resto das religiões do mundo está amontoado em
uma única subseção: Outras. Línguas têm nove subseções; sete delas cobrem
línguas européias. Olhando o sistema decimal Dewey podemos dizer a você em
que parte do mundo Melvil Dewey cresceu.
Centrando a Arquitetura de Informação no usuário
82
Durante o projeto, o arquiteto precisa evitar que suas perspectivas influenciem o
design do sistema de organização. ROSENFELD e MORVILLE (2002) afirmam que se
deve buscar construir um sistema que reflita as perspectivas do usuário, caso contrário
estará sacrificando a compreensão da informação.
Outro ponto a se notar é que diferentes usuários podem possuir diferentes
perspectivas, conforme seus interesses e conhecimento sobre o assunto do website. Essas
diferenças de perspectiva são importantes porque permitem criar várias formas de
organização que atendam a diferentes necessidades. “Cada forma de organizar cria nova
informação e nova compreensão” (WURMAN, 1991, pág. 78).
O arquiteto de informação, porém, precisa ter um cuidado especial com a
quantidade de diferentes perfis de usuário que pretende atender porque quanto mais perfis
existirem maior é a complexidade do sistema de organização e de navegação (DIJCK,
2003).
3.2.1.2.4 Políticas internas
A própria maneira com que a informação é organizada sempre destaca alguns de
seus atributos enquanto outros ficam escondidos. Assim, por traz das decisões que
resultam no modelo de organização não existe apenas a preocupação de atender o usuário.
Existem também decisões políticas que visam resolver conflitos de interesse.
Supermercados, por exemplo, são organizados de forma a destacar a função de cada
produto e ofuscar os seus fabricantes. Se o supermercado alterar sua forma de organização
para privilegiar os fabricantes pode aumentar a força da marca deles e consequentemente
aumentar-lhes o poder de barganha.
Devido ao poder inerente da organização da informação em formar entendimento
e opinião, o processo de design da arquitetura de informação de websites e
intranets pode envolver um forte fator político oculto. (ROSENFELD e
MORVILLE, 2002, pág. 54)
Balancear a influência das decisões políticas na organização da informação é uma
tarefa que requer muita sensibilidade. Ao mesmo tempo em que se deve trazer o foco das
Arquitetura de Informação de websites
83
discussões para as necessidades do usuário é preciso compreender e respeitar as razões por
traz de cada decisão política (ROSENFELD e MORVILLE, 2002).
3.2.1.2.5 Estética
Além de possuir uma organização compreensível, um website precisa ser
agradável, precisa ser bonito. Seus usuários precisam se sentir bem ao utilizá-lo. Segundo
NORMAN (2003), um design atrativo aumenta a usabilidade aparente da interface porque
faz com que seus usuários pensem de forma criativa e busquem novos modelos mentais
quando se deparam com erros. Um design pouco atrativo provoca o efeito inverso, limita a
criatividade da mente humana ao se deparar com um erro.
Porém a estética não deve prevalecer sobre a compreensão da informação. A forma
deve se adequar ao conteúdo e não o contrário. Esse é um erro comum conforme cita
WURMAN (1991, pág. 62):
Embora o papel dos artistas gráficos no fornecimento de informação seja
fundamental, a maior parte do currículo das escolas de artes gráficas preocupa-se
em ensinar aos alunos como fazer as coisas parecerem agradáveis aos olhos. Isto
é posteriormente reforçado pela profissão, que concede prêmios principalmente à
aparência e não à compreensibilidade ou mesmo à exatidão. Não existem Oscars,
Emmys ou Tonys para quem transforma gráficos e estatísticas em informação
compreensível.
WEST (2001) também reforça a importância do conteúdo prevalecer sobre a forma
em um website. Segundo esse autor “muitos designers terão idéias de um design ‘legal’
[cool] antes de fazer qualquer outra coisa. Para mim esse é um dos maiores erros que um
designer pode cometer. O design ‘legal’ vai vir, mas o conteúdo/informação é quem deve
ditá-lo”.
3.2.1.3 Esquemas de organização da informação
A solução apontada por diversos autores (WURMAN, 1991; REISS, 2000;
ROSENFELD e MORVILLE, 2002; BRINCK, GERGLE e WOOD, 2002; DIJCK, 2003;
Centrando a Arquitetura de Informação no usuário
84
BUSTAMANTE, 2004) para superar as dificuldades do design do sistema de organização
é a utilização de esquemas de organização.
Esquemas de organização são maneiras de se criar categorias a partir da semântica
(significado) dos conteúdos a serem categorizados. Cada esquema possui uma regra
simples que define a formação das suas categorias. A vantagem em utilizar esses
esquemas é que eles permitem que o usuário tenha rapidamente uma visão de como toda a
informação está organizada, dando-lhe consistência e previsibilidade (ROSENFELD e
MORVILLE, 2002; BUSTAMANTE, 2004).
Segundo WURMAN (1991) a quantidade de esquemas de organização existentes é
finita e pequena. Com isso é possível ao arquiteto de informação avaliar todos os possíveis
esquemas e escolher os mais adequados ao seu projeto.
A informação pode ser infinita, mas as formas de estruturá-la, não. E se você tiver
onde “pendurar” a informação, ela se tornará muito mais útil. Sua escolha será
determinada pela história que quer contar. Cada forma permitirá uma
compreensão diferente. Dentro de cada uma existem muitas variações, mas
reconhecer que as escolhas são finitas e limitadas torna o processo bem menos
intimidativo. (WURMAN, 1991, pág. 66)
Unindo-se as propostas de diversos autores (WURMAN, 1991; REISS, 2000;
ROSENFELD e MORVILLE, 2002; BRINCK, GERGLE e WOOD, 2002; DIJCK, 2003;
BUSTAMANTE, 2004) percebe-se o início da formação de um padrão nos esquemas de
organização de informação para websites. Unificando-se o trabalho desses autores é
possível identificar nove esquemas de organização divididos em dois grandes grupos, que
estão resumidos no diagrama apresentado a seguir.
Arquitetura de Informação de websites
85
Figura 4 - Esquemas de organização da Informação
Esquemas de
Organização
da Informação
Exata
Divide a informação em categorias bem
definidas e mutuamente exclusivas com
regras claras para incluir novos itens.
Indicado quando o usuário sabe
exatamente o que está procurando.
Ambígua
Divide a Informação em categorias
subjetivas. Baseia-se na ambigüidade
inerente da língua e na subjetividade
humana. Não possui regras claras de como
incluir novos itens.
Indicado quando o usuário não sabe
exatamente o que está procurando.
Alfabeto
Indicado para grandes conjuntos de Informação e
público muito diversificado.
Ex: Dicionários, Enciclopédias, Listas Telefônicas
Tempo
Indicado para mostrar a ordem cronológica de eventos.
Ex: Livros de História, Guias de TV, Arquivo de notícias
Localização
Compara informações vindas de diferentes locais.
Ex: Previsão do tempo, pesquisa política, Atlas de
anatomia
Seqüência
Organiza itens por ordem de grandeza. Indicado para
conferir valor ou peso a informação.
Ex: Lista de preços, Top musics
Assunto
Divide a informação em diferentes tipos, diferentes
modelos ou diferentes perguntas a serem respondidas
Ex: Páginas Amarelas, Editorias do jornal,
Supermercado
Tarefa
Organiza a informação em conjuntos de ações. Usado
muito em software transacionais. Raramente utilizado
sozinho na Web.
Ex: Menu aplicativos Windows (Editar, Exibir, Formatar)
Público Alvo
Indicado quando se deseja customizar o conteúdo para
cada público-alvo.
Ex:Lojas de departamento
Metáfora
Utilizado para orientar o usuário em algo novo baseado
em algo familiar. Normalmente limita muito a
organização.
Ex:Desktop de um computador
Hibrido
Reúne 2 ou mais esquemas anteriores. Normalmente
causa confusão ao usuário.
Esquemas de
Organização
da Informação
Exata
Divide a informação em categorias bem
definidas e mutuamente exclusivas com
regras claras para incluir novos itens.
Indicado quando o usuário sabe
exatamente o que está procurando.
Ambígua
Divide a Informação em categorias
subjetivas. Baseia-se na ambigüidade
inerente da língua e na subjetividade
humana. Não possui regras claras de como
incluir novos itens.
Indicado quando o usuário não sabe
exatamente o que está procurando.
Alfabeto
Indicado para grandes conjuntos de Informação e
público muito diversificado.
Ex: Dicionários, Enciclopédias, Listas Telefônicas
Tempo
Indicado para mostrar a ordem cronológica de eventos.
Ex: Livros de História, Guias de TV, Arquivo de notícias
Localização
Compara informações vindas de diferentes locais.
Ex: Previsão do tempo, pesquisa política, Atlas de
anatomia
Seqüência
Organiza itens por ordem de grandeza. Indicado para
conferir valor ou peso a informação.
Ex: Lista de preços, Top musics
Assunto
Divide a informação em diferentes tipos, diferentes
modelos ou diferentes perguntas a serem respondidas
Ex: Páginas Amarelas, Editorias do jornal,
Supermercado
Tarefa
Organiza a informação em conjuntos de ações. Usado
muito em software transacionais. Raramente utilizado
sozinho na Web.
Ex: Menu aplicativos Windows (Editar, Exibir, Formatar)
Público Alvo
Indicado quando se deseja customizar o conteúdo para
cada público-alvo.
Ex:Lojas de departamento
Metáfora
Utilizado para orientar o usuário em algo novo baseado
em algo familiar. Normalmente limita muito a
organização.
Ex:Desktop de um computador
Hibrido
Reúne 2 ou mais esquemas anteriores. Normalmente
causa confusão ao usuário.
Esses esquemas também podem ser combinados, apresentando ao usuário as
informações do website organizadas de várias formas numa estrutura multi-dimensional,
como a classificação facetada proposta por Ranganathan. Essas estruturas multi-
dimensionais são facilmente implementadas na Web graças à flexibilidade do hiperespaço
e oferecem ao usuário diversas formas de buscar a mesma informação acomodando
diversos modelos mentais. Além disso, elas possuem uma quantidade de termos menor no
seu vocabulário controlado, o que facilita a manutenção (MORVILLE, 2005).
Os esquemas de organização são apenas uma orientação ao arquiteto de
informação. Em um projeto, a decisão de qual esquema utilizar precisa ser validada com o
usuário, como sugerem as abordagens do Design Centrado no Usuário da Interação
Humano-Computador. Uma técnica bastante sugerida por vários autores para realizar essa
validação é a realização de testes de card sorting com o público-alvo do website (REISS,
2000; ROSENFELD e MORVILLE, 2002; DIJCK, 2003; WODTKE, 2003;
BUSTAMANTE, 2004). No capítulo 4 são apresentados mais detalhes sobre essa técnica.
Centrando a Arquitetura de Informação no usuário
86
3.2.2 Sistema de Navegação
O século XV foi marcado pelas grandes navegações portuguesas e espanholas, que
contornaram a África e a Índica e cruzaram o Atlântico descobrindo a América. Foi uma
época marcada pela coragem dos homens e pelo espírito de aventura. Mas para se navegar
por esses mares nunca d’antes navegados foi preciso muito mais que a mera força humana.
As grandes navegações só foram possíveis graças ao aperfeiçoamento das técnicas
de navegação e de diversos instrumentos de orientação náutica como a bússola, o
astrolábio, a basestilha e o quadrante. Esse salto tecnológico permitiu pela primeira vez
que os navegantes conseguissem se orientar com precisão em alto mar e assim ir muito
além da Taprobana
9
.
Da mesma forma que nos oceanos, um usuário, ao se mover no espaço hipertextual
de um website, precisa de orientação. Sem elementos que orientem seu caminho, ele não
consegue chegar ao seu destino e, literalmente, se perde. Fica a deriva no mar do
hiperespaço.
A navegação
10
nos hipertextos introduz uma questão já equacionada como o
problema clássico desses sistemas: o utilizador desorienta-se, perde-se no meio de
tanta informação, em suma, acontece-lhe aquilo a que Conklin chamou ‘perder-se
no hiperespaço’ MORGAD (1994)
Estar perdido, seja no mundo virtual, seja no mundo real, é uma sensação
angustiante. ROSENFELD e MORVILLE (2002) afirmam que o sentimento de estar
perdido é associado à confusão, frustração, insegurança, ira e medo. Um sistema de
navegação mal projetado afeta a usabilidade do website porque não orienta o usuário no
caminho que precisa seguir para alcançar seus objetivos, causando-lhe o sentimento de
estar perdido.
9
A Taprobana, cantada nos versos de Camões em Os Lusiadas, é o antigo Ceilão atual Sri Lanka.
10
Grifos da autora
Arquitetura de Informação de websites
87
3.2.2.1 Por que as pessoas se perdem ao navegar em um hipertexto?
Estar perdido no hipertexto é a situação na qual o usuário não compreende como a
informação está organizada, como encontrar o que está procurando ou até se a informação
que procura está disponível. ELM e WOODS (apud McKNIGHT e colab. , 1991, pág. 65)
descrevem essa situação como “o usuário não tem uma concepção clara dos
relacionamentos dentro do sistema ou, não conhece sua presente localização no sistema
relativo à estrutura mostrada e acha que é difícil decidir onde seguir dentro do sistema”.
A navegação em hipertextos é comumente comparada à navegação em espaços
físicos e é dessa analogia que surgem as principais explicações sobre os processos
cognitivos do usuário navegando em espaços hipertextuais. McKNIGHT e colab. (1991)
estudaram dois fenômenos cognitivos da navegação em espaços físicos e os aplicaram aos
espaços hipertextuais para entender as dificuldades do usuário ao navegar nesse novo
meio. São eles os esquemas ou modelos de ambiente genérico e a aquisição de mapas
espaciais cognitivos.
3.2.2.1.1 Esquemas ou modelos de ambientes genéricos
Os esquemas ou modelos de ambiente genéricos são esquemas pré-concebidos de
ambientes físicos que temos em nossa mente adquiridos através da experiência. Todos nós
possuímos, por exemplo, um modelo mental de como é uma cidade. Esperamos que ela
tenha casas, prédios, ruas, praças, esquinas, etc. Esses modelos existem em diversos níveis
de escala, desde o nível de países e continentes até o nível dos cômodos de uma casa
(McKNIGHT e colab. , 1991), e a função deles é criar estereótipos sobre a geografia de
um ambiente físico desconhecido, algo como “quem já viu uma cidade viu todas”. Esse
estereotipo inicia a criação do modelo mental do usuário e lhe fornece uma orientação
espacial básica para guiar seus comportamentos iniciais ao navegar no novo ambiente.
Porém esses modelos de ambientes genéricos são limitados. Eles não contêm as
características individuais do novo ambiente e por isso não oferecem conhecimento além
do que é visto com os próprios olhos. Não é possível extrair desses esquemas os detalhes
de uma rota dentro do novo ambiente (McKNIGHT e colab. , 1991).
Centrando a Arquitetura de Informação no usuário
88
Em documentos impressos em papel, como livros, jornais e revistas, já existe um
esquema genérico aceito sócio-culturalmente, o que facilita muito a navegação dos
usuários quando se deparam com um novo documento desse tipo. No caso dos livros, por
exemplo, os editores da Itália renascentista estabeleceram no início do século XVII uma
série de convenções para a publicação desses materiais, que originaram um esquema
genérico que permanece até hoje. Elementos como títulos, prefácio, introdução, sumário,
numeração das páginas, índice remissivo são alguns dos componentes desse esquema
(MORROGH, 2003). Através da experiência os usuários aprendem esses esquemas o que
lhes facilita prever a organização de qualquer livro.
Já nos hipertextos, não existe um esquema genérico tão bem definido quanto nos
ambientes físicos ou nos documentos em papel. Um dos motivos para isto é a história
recente dos documentos eletrônicos, o que justifica o baixo nível de conhecimento que o
público em geral tem dessa tecnologia.
Outro motivo que contribui para a inexistência de um esquema genérico é que o
modus opereandi adquirido pelo usuário ao utilizar um sistema em um computador nem
sempre se aplica em outros sistemas. A falta de padrões faz com que a manipulação da
informação varie de aplicação para aplicação, computador para computador, versão para
versão, e atualmente de website para website, dificultando a formação de modelos
genéricos (McKNIGHT e colab. , 1991).
Interfaces computacionais padronizadas tendem a diminuir esse tipo de problema.
O ambiente computacional criado pelos sistemas operacionais gráficos, por exemplo,
definiu padrões para menus, janelas, botões, caixas de textos, listas de opções e diversos
outros elementos de interface que juntos formam um ambiente consistente e permitem que
o usuário crie um modelo genérico do ambiente com maior facilidade. Na Web não existe
uma padronização com a mesma rigidez.
3.2.2.1.2 Mapas espaciais cognitivos
Mapas espaciais cognitivos são mapas internalizados na mente humana e que são
análogos à disposição física de um ambiente (TOLMAN apud McKNIGHT e colab. ,
1991). Eles são adquiridos através das interações do indivíduo com o ambiente e contêm
Arquitetura de Informação de websites
89
os detalhes da posição espacial de cada elemento permitindo que um indivíduo se localize
e trace rotas para se locomover.
A aquisição de um mapa espacial cognitivo envolve um processo mental de várias
etapas, que vai da identificação de marcos no ambiente até a formação na mente de um
mapa geográfico completo (ANDERSON & WIDCKENS apud McKNIGHT e colab. ,
1991).
Existem duas grandes vantagens em se ter um mapa espacial cognitivo de
qualquer ambiente, seja de uma cidade ou de um banco de dados. Primeiro existe
a oportunidade de planejar e usar atalhos para alcançar os locais desejados.
Segundo, e provavelmente mais importante, se o usuário / viajante se distrair de
alguma forma e se perder na rota, existe uma grande chance de recuperar seus
pontos de apoio e alcançar o destino pretendido, caso ele tenha um mapa espacial
cognitivo do ambiente ao invés de ter seu conhecimento simplesmente na forma de
uma rota. (EDWARDS e HARDMAN, 1993, pág. 92)
Mapas espaciais cognitivos não têm muita aplicação em documentos em papel,
porque todo o espaço informativo é acessível instantaneamente ao leitor. Navegar por um
livro é quase uma experiência de tele-transporte. Para alcançar uma página basta virar
algumas outras, de modo que o custo de seguir por uma rota errada é muito pequeno tanto
em termos de tempo quanto esforço justificando porque seus leitores não desenvolvem um
conhecimento de possíveis rotas (McKNIGHT e colab. , 1991).
No caso de hipertextos, ao contrário, os mapas espaciais cognitivos têm grande
importância na modelagem do processo mental do usuário que navega neles. EDWARDS
e HARDMAN (1993) afirmam terem descoberto evidências de que os usuários criam uma
representação cognitiva da estrutura hipertextual de modo a formar um mapa espacial
cognitivo com a visão geral do ambiente no hipertexto. Eles também notaram que um
maior conhecimento da estrutura do hipertexto diminui o sentimento de estar perdido e
aumenta a satisfação de uso do sistema.
Centrando a Arquitetura de Informação no usuário
90
3.2.2.2 Dificuldades em projetar o sistema de navegação
Da análise dos processos cognitivos do usuário é clara a analogia entre a
navegação no hipertexto e a navegação em ambientes físicos. Nota-se que em ambas o
objetivo é alcançar um destino fora do campo de visão do ponto de partida e, que para
alcançá-lo, o usuário/navegador se orienta através de pontos de referência que determinam
a sua posição espacial e a direção que deve seguir.
No mundo real, as referências já existem e fazem parte do ambiente. Árvores, rios,
montanhas, estrelas. É infinita a quantidade de pontos de referência que o mundo físico
oferece para orientar o navegador em sua trajetória. Porém, em um website, essas
referências não existem. Como as placas de uma rua, é necessário criar um sistema de
navegação que estabeleça pontos de referência e uma sinalização no ambiente virtual do
hipertexto para orientar o usuário no seu caminho.
Dessa forma, o sistema de navegação de um website tem duas funções básicas:
indicar ao usuário a sua localização e mostrar o caminho correto que precisa seguir para
chegar ao seu destino.
NIELSEN (2000) confirma estas duas funções do sistema de navegação e afirma
que, para exercê-las, existem três perguntas fundamentais que esse sistema precisa
responder a todo instante para o usuário: “Onde estou?”, “Onde estive?” e “Aonde posso
ir?”.
WODTKE (2003) sugere outras três perguntas fundamentais que também
confirmam as duas funções básicas do sistema de navegação: “Estou no lugar certo?”,
“Ele [o website] tem o que estou procurando?” e “Ele [o website] tem alguma coisa
melhor?”.
Por fim FLEMING (1998) propõe outras quatro questões para implementar as duas
funções básicas do sistema de navegação: “Onde estou?”, “Aonde posso ir?”, “Como
chego lá?” e “Como posso voltar para onde eu estava?”.
Com relação à primeira função básica do sistema de navegação, indicar para o
usuário a sua localização, a dificuldade está em criar no website uma composição
Arquitetura de Informação de websites
91
harmônica dos elementos de navegação para que os usuários consigam, a qualquer
instante, determinar a sua localização. NIELSEN (2000) afirma que existem dois níveis de
localização que o sistema de navegação precisa apresentar. O primeiro nível mostra a
posição do usuário em relação à Web como um todo e identifica em que website o usuário
está. O segundo nível posiciona o usuário em relação à estrutura interna do website. Esses
dois níveis de localização devem ser apresentados em todas as páginas porque nem sempre
o usuário entra no website através da home-page. É muito comum se utilizar um website
de busca (por exemplo o Google) para se descobrir as páginas que interessam dentro do
website e acessá-las. Dessa forma, a navegação pode começar por uma página interna
qualquer e não necessariamente pela sua Home-Page.
Já para a segunda função do sistema de navegação, mostrar o caminho correto, a
dificuldade está no projeto dos links visíveis na página. Cada link comunica, através de
seu rótulo, o que o usuário irá encontrar se clicar nele. A eficiência dessa comunicação
está diretamente ligada à capacidade do rótulo em resumir e contextualizar a informação
da página que aponta.
FLEMING (1999) afirma não existe uma receita simples para se elaborar um
sistema de navegação. Porém, essa autora cita uma lista de dez princípios básicos
observados em websites com sistemas de navegação de qualidade. São eles:
• Fácil de aprender: O sistema de navegação precisa ser fácil de aprender
porque se os usuários perderem muito tempo para entender como utilizá-lo,
ele irão abandonar o site.
• Ser consistente: Os usuários, após compreenderem como o sistema de
navegação funciona, passam a confiar nele. Um sistema consistente permite
que o usuário tenha previsibilidade sobre como será a resposta do sistema
antes de executar a ação.
• Prover feedback: O usuário espera que o sistema reaja a cada ação que
executar sobre a sua interface porque é através dessas reações que o usuário
consegue avaliar se o sistema executou a ação com sucesso. Por isso o
Centrando a Arquitetura de Informação no usuário
92
sistema de navegação precisa sempre dar feedback mostrando-lhe sua
posição espacial.
• Presente de diferentes formas conforme o contexto: Para decidir seus
movimentos o usuário precisa ver as possíveis rotas. Ser contextualizado é
apresentar para o usuário as rotas que lhe interessam conforme o ponto em
que se encontra no sistema.
• Oferecer alternativas: Usuários diferentes possuem diferentes estratégias
de navegação. O sistema de navegação precisa ser capaz de atender a esses
diferentes comportamentos.
• Economizar ações e tempo de utilização: Navegações longas causam
frustração no usuário. Por isso, o sistema de navegação precisa sempre
manter as rotas curtas e oferecer atalhos, especialmente para usuários
experientes.
• Apresentar mensagens visuais claras e no momento adequado: O
sistema de navegação precisa ter um visual claro e que guie o usuário em
detrimento da estética.
• Possuir rótulos compreensíveis: O sistema de navegação precisa usar
rótulos claros, sem ambigüidade, na linguagem do usuário e consistentes
com as informações apresentadas.
• Estar em sintonia com o propósito do website: A abordagem do sistema
de navegação depende muito dos objetivos do website e das experiências
do usuário, assim o design do sistema de navegação deve auxiliar o usuário
a seguir esses objetivos.
• Suportar os objetivos e comportamentos do usuário: O sistema de
navegação precisa auxiliar os usuários a executarem suas tarefas da forma
que estão acostumados a fazê-las.
Arquitetura de Informação de websites
93
Nota-se nesses princípios de FLEMING a preocupação de que o sistema de
navegação reflita os objetivos, as experiências e comportamentos do usuário, o que reforça
a preocupação em se seguir uma abordagem de Design Centrado no Usuário ao projetar
esse sistema.
3.2.2.3 Flexibilidade X Confusão
A principal característica do hipertexto é que cada página pode ter links apontando
para quantas e quais outras páginas se desejar. Não existem limites para a quantidade de
links que uma página de hipertexto pode ter. Assim, o arquiteto de informação tem uma
ferramenta extremamente flexível, que lhe dá a liberdade de montar as estruturas de
organização e os sistemas de navegação que desejar.
Porém, uma quantidade excessiva de links confunde o usuário. Segundo
GARRETT (2002b), o usuário, ao se deparar com uma nova página, percorre os olhos por
todos os links existentes tentando encontrar o que melhor atende sua intenção. Se uma
quantidade excessiva de links é apresentada, o esforço cognitivo para encontrar o link
correto é maior, aumentando a probabilidade de confusão.
Na prática, cabe ao arquiteto de informação enfrentar essa dificuldade balanceando
o grau de flexibilidade com o grau de confusão em cada página. Tipicamente, tarefas mais
críticas devem ter uma navegação com menos opções de modo que o usuário consiga focar
melhor sua atenção (ROSENFELD e MORVILLE, 2002).
3.2.2.4 Navegação Social
ROSENFELD e MORVILLE (2002) definem como navegação social (social
navigation), o valor derivado da observação da navegação de outros usuários. A idéia
consiste em apresentar para um usuário o que outros usuários com os mesmos interesses
encontraram ao navegar pelo website.
Talvez o exemplo mais famoso de navegação social está no filtro colaborativo da
livraria virtual Amazon (www.amazon.com). Nesse website, cada página que detalha um
produto possui uma lista de links chamada “Customers who bought this also bought”
Centrando a Arquitetura de Informação no usuário
94
(“Clientes que compraram isto também compraram”) na qual são apresentados produtos
que interessaram a outros usuários na mesma situação. SEYBOLD (2000) estima que
cerca de 10% dos pedidos feitos a Amazon vem dessas sugestões de links.
A navegação social tem grande valor porque cria correlações entre os conteúdos
baseadas nos interesses dos usuários e não nas suposições do arquiteto de informação. Por
isso é uma boa ferramenta para superar as dificuldades do projeto do sistema de
navegação, especialmente para se melhorar a contextualização. De fato, como aponta a
abordagem do Sense-Making, o aparente caos do caminho construtivista de um usuário
resulta uma padronização que pode ser compartilhada para auxiliar outros usuários em
seus processos de busca de informação.
3.2.2.5 Elementos do Sistema de Navegação
ROSENFELD e MORVILLE (2002) classificam os elementos que compõem o
sistema de navegação em dois subsistemas: o sistema de navegação embutido e sistema de
navegação suplementar. O primeiro é composto por elementos apresentados junto com o
conteúdo da página, e tem a função de contextualizar o usuário e oferecer flexibilidade de
movimento. O segundo é externo a hierarquia do website e provê caminhos
complementares para encontrar o conteúdo e completar as tarefas. A Tabela 5 detalha
esses elementos.
Tabela 5 - Elementos do Sistema de Navegação
Sistema de Navegação Embutido
Logotipo
Tem a função de identificar o
website e mostrar a sua posição
em relação à Web como um
todo. Como se pode entrar em
um website por qualquer página,
é importante que todas as
páginas contenham o logotipo
para que o usuário identifique
em que website se encontra.
LogotipoLogotipo
Logotipo presente em diversas página na loja virtual Submarino
(www.submarino.com.br)
Arquitetura de Informação de websites
95
Barra de Navegação Global
Barra com uma seqüência de
links para as áreas chaves do
website, as grandes categorias
do sistema de organização.
Categorias dos Produtos
Acompanhamento dos Pedidos
Ajuda e Listas de Compras
Categorias dos Produtos
Acompanhamento dos Pedidos
Ajuda e Listas de Compras
Barra de navegação global da loja virtual Submarino
(www.submarino.com.br)
Menu local
Sua função é estabelecer uma
navegação local, mostrando
links para páginas que estão
próximas na estrutura do
website à página que está
sendo visitada, como páginas
irmãs, filhas e pais.
Menu local da seção de DVDs da loja virtual Submarino
(www.submarino.com.br)
Bread Crumb
É uma lista de elementos (links)
separados por algum caractere
(normalmente > , : ou | ) ou
gráfico (normalmente uma seta
para a direita). Tem a intenção
de informar o usuário onde ele
se encontra na estrutura do
website e prover links
para os níveis hierárquicos
imediatamente superiores.
Bread Crumb no website Yahoo! (www.yahoo.com.br)
Centrando a Arquitetura de Informação no usuário
96
Cross Content
É uma lista de links relacionados
ao conteúdo da página atual.
Podem oferecer um nível maior
de profundidade ou atalhos para
grandes movimentos laterais.
Cross contents na loja virtual Americanas.com (www.americanas.com.br)
Sistema de Navegação Remoto
Mapa do Site
Tem a função de apresentar
toda a estrutura analítica do
website e permitir acesso direto
a qualquer página.
Mapa do site da Microsoft (www.microsoft.com.br)
Arquitetura de Informação de websites
97
Índice Remissivo
São listas de palavras chaves,
em ordem alfabética,
relacionadas ao conteúdo do
website. Assemelham-se aos
índices remissivos dispostos
no final dos livros.
Índice remissivo no website do Banco Itaú (www.itau.com.br)
A ausência de padronização dos elementos de interface é mais uma dificuldade no
projeto do sistema de navegação. Não existe ainda um esquema genérico para websites
como os existentes nos documentos impressos. Um esquema genérico determinaria um
conjunto de regras conhecidas e compartilhadas tanto pelo arquiteto de informação quanto
pelo usuário, o que estabeleceria uma sintaxe para a linguagem hipertextual da Web.
ENGEBRETSEN (apud NOCI e SALAVERRÍA, 2003) aponta que a ausência dessa
sintaxe desorienta o usuário e compromete a sua compreensão da informação apresentada.
Deve-se ter em conta que a falta de regras no hipertexto pode chegar ao ponto de
impossibilitar a comunicação. A novidade do hipertexto ocasiona todavia um
escassez de regras gramaticais e discursivas acordadas entre autor e leitor (...). Se
diante de um hipertexto o leitor ignora onde se encontra e como deve interpretar a
leitura seqüencial de certos nós, a informação adquirida pode carecer de completo
sentido para ele. Dito de outro modo: se o leitor desconhece a sintaxe de um
hipertexto é impossível que o consiga ler. (NOCI e SALAVERRÍA, 2003)
Inspirados principalmente nas teorias da Interação Homem-Computador, diversos
autores (ROSENFELD e MORVILLE, 2002; REISS, 2000; NIELSEN, 2000; WODTKE,
2002; INSTONE, 2003) propõem diretrizes e recomendações para o design de cada um
dos elementos do sistema de navegação. Não são regras exatas e sua aplicação ainda
dependem muito da experiência e bom senso do arquiteto de informação. Mas elas são
Centrando a Arquitetura de Informação no usuário
98
uma ferramenta de grande valia porque apresentam orientações para um bom design e
iniciam a criação dessa sintaxe para o hipertexto na Web.
Porém ainda está longe a consolidação dessa sintaxe. Criá-la envolve estabelecer
regras que detalhem como cada elemento do sistema de navegação deve se comportar em
cada possível situação do usuário. Além disso, essas regras precisam ser conhecidas e
compartilhadas tanto por projetistas quanto usuários, ou seja, precisam ser padrões
legitimados.
A flexibilidade, heterogeneidade e descentralização da Web enquanto mídia é
provavelmente o maior obstáculo para criar essa sintaxe. Sistemas operacionais gráficos,
por terem características opostas, conseguiram uma padronização maior de suas interfaces
e já possuem indícios de terem uma sintaxe. Na aplicações desenvolvidas para o Microsoft
Windows, por exemplo, é amplamente disseminado o uso comum de algumas teclas de
atalho (Ctrl-C, Ctrl-V, F1, etc.) e itens de menu (File ou Arquivo, Edit ou Editar, Format
ou Formatar, Help ou Ajuda, etc.)
A aplicação das diretrizes e recomendações existentes atualmente e o seu
aperfeiçoamento ao longo do tempo poderá criar a sintaxe para o hipertexto na Web.
3.2.3 Sistema de Rotulação
Se não agüenta a vara, peça cacetinho!
Quem já passou o carnaval na Bahia atrás dos seus famosos trios elétricos ouviu
essa frase inúmeras vezes. Mas o que ela significa? Antes de lhe atribuir qualquer
interpretação maliciosa, vale conhecer um pouco melhor o “dialeto local”. Segundo o
Dicionário de Bainês (LARIÚ, 1992) vara é um pão de sal de 200g e cacetinho é um pão
de sal pequeno, de apenas 50g. Assim a frase sugere apenas uma simples medida para
evitar desperdícios!
Arquitetura de Informação de websites
99
É claro que quando Bell Marques
11
grita esta frase do alto do seu trio elétrico, ele
aproveita a ambigüidade de interpretação que a frase sugere para brincar com os foliões
em festa. Essas formas criativas de comunicação, que exploram as particularidades da
língua, são excelentes para se fixar uma mensagem na mente do receptor e é um bom
artifício, intencionalmente usado por artistas e profissionais de comunicação.
Porém, na arquitetura de informação de um website, formas criativas como essas
tendem a ser especialmente prejudiciais à usabilidade. Um rótulo ou um ícone ambíguo
causa erros de interpretação e todo o trabalho efetuado na elaboração do sistema de
organização e navegação pode se perder simplesmente porque o arquiteto utilizou rótulos
que o usuário não compreende.
Devido à riqueza da língua, caracterizada pelas diferentes interpretações que cada
palavra tem e pelas diversas palavras que podem traduzir o mesmo conceito, construir o
sistema de rotulação é provavelmente a tarefa mais difícil em um projeto de arquitetura de
informação.
Projetar rótulos eficientes é talvez o aspecto mais difícil da arquitetura de
informação. A língua é simplesmente tão ambígua que você sempre sente que pode
melhorar um label. Sempre existem sinônimos e homônimos para se preocupar e
diferentes contextos influenciam nosso entendimento sobre o que um termo em
particular significa.
(ROSENFELD e MORVILLE, 2002, pág. 92)
3.2.3.1 O que são rótulos?
Um rótulo ou termo (em inglês utiliza-se a palavra label) é um símbolo lingüístico
utilizado para representar um conceito. O objetivo de um rótulo é comunicar o conceito
eficientemente, ou seja, comunicar o conceito sem ocupar muito espaço na página e sem
demandar muito esforço cognitivo do usuário para compreendê-lo. Nos websites os
11
Bell Marques é vocalista da banda Chiclete com Banana, que tradicionalmente se apresenta em trios
elétricos no carnaval de Salvador, Bahia.
Centrando a Arquitetura de Informação no usuário
100
rótulos são empregados nos títulos de páginas, nas opções do sistema de navegação, nos
links contextualizados dentro das páginas e nos meta-dados utilizados na indexação das
páginas para o sistema de busca. (ROSENFELD e MORVILLE, 2002)
Um rótulo pode ser textual (ou verbal), quando composto por uma ou mais
palavras, ou não textual, quando composto de imagens, sons ou gestos. Em websites, o
tipo mais comum de rótulos não textuais são os ícones, pequenas imagens que
representam conceitos.
Associar rótulos a conceitos é um ato natural dos seres humanos e que nos permitiu
criar as línguas e nos comunicarmos. Uma língua, numa visão simplificada, é apenas uma
relação de termos na qual atribuímos a cada conceito um símbolo (termo) que o
representa. No caso das línguas faladas esse símbolo é uma imagem acústica, é o som
pronunciado para cada palavra. Mais tarde, com a criação da escrita, surgiram os alfabetos
que traduziram essa imagem acústica em sinais gráficos.
Essa relação de termos que forma a língua é um produto social, o que permite que
ela seja utilizada como instrumento de comunicação por uma comunidade (SAUSSURE,
1995; DUBOIS e colab., 1993).
SAUSSURE (1995) define como signo lingüístico a combinação do conceito
(significado) e do símbolo que o representa (significante) e afirma que essa ligação entre
eles é arbitrária.
Assim, a idéia de “mar” não está ligada por relação alguma interior à seqüência
de sons m-a-r que lhe serve de significante; poderia ser representada igualmente
bem por outra seqüência, não importa qual; com prova, temos as diferenças entre
as línguas e a própria existência de línguas diferentes: o significado da palavra
francesa boeuf (“boi”) tem por significante b-ö-f de um lado da fronteira franco-
germânica, e o-k-s (Ochs) do outro. (SAUSSURE, 1995, pág. 81)
Esse autor ainda apresenta duas características opostas do signo: sua imutabilidade
e sua mutabilidade.
Arquitetura de Informação de websites
101
Embora, em uma língua qualquer, a escolha do significante que representa o
significado seja arbitrária, ela é imposta a comunidade praticante da língua tornando-a
imutável a cada um dos seus indivíduos. Existem quatro razões para essa imutabilidade: o
seu caráter arbitrário, a multidão de signos necessários para constituir qualquer língua, o
caráter demasiado complexo do sistema e a resistência da inércia coletiva a toda
renovação lingüística.
Porém o tempo, elemento que assegura a continuidade da língua, também atua
como um elemento que acumula as forças sociais que agem sobre ela para adequá-la a
realidade da massa falante. Essa ação do tempo em grandes dimensões é a causa da
diversidade geográfica de línguas e dialetos que temos no mundo e, em pequenas
dimensões, a causa da formação das gírias. Comunidades distantes geograficamente ou
socialmente introduzem diferentes inovações na língua, que, acumuladas ao longo do
tempo, geram sua mutabilidade.
A gíria, em especial, é um dialeto social empregado por uma determinada camada
da sociedade para se opor as demais. Seu objetivo é ser compreendida apenas pelos
membros do grupo. Para criar seus novos signos, a gíria utiliza metáforas, sinônimos
parciais e empréstimos de termos oriundos de outros dialetos e línguas estrangeiras
(DUBOIS et al., 1993).
3.2.3.2 Dificuldades no projeto do sistema de rotulação
As principais dificuldades no projeto dos sistemas de rotulação apontadas por
diversos autores (REISS, 2000; ROSENFELD e MORVILLE, 2002; WODTKE, 2003;
BUSTAMANTE, 2004) advém dos próprios mecanismos que formam as línguas e de toda
a sua subjetividade e ambigüidade. Essas dificuldades estão sintetizadas a seguir.
3.2.3.2.1 Conseguir falar na linguagem do usuário
A grande dificuldade no projeto de rótulos é conseguir utilizar a mesma linguagem
do usuário (ROSENFELD e MORVILLE, 2002). Um usuário comum normalmente vive
em um ambiente diferente do arquiteto, que o leva a conviver com gírias, expressões
Centrando a Arquitetura de Informação no usuário
102
técnicas e até dialetos diferentes (WODTKE, 2003). Compreender essa linguagem requer,
por parte do arquiteto, uma imersão no dia-a-dia do usuário.
Também é comum que a empresa (ou outra entidade que estiver contratando o
projeto do website) tenha sua linguagem própria interna, sua gíria, e queira utilizá-la na
criação dos rótulos. REISS (2000) acredita que não existe nenhuma organização que não
tenha inventado sua linguagem própria interna. Porém essa linguagem normalmente é
incompreensível para quem não vive a sua realidade interna de forma que deve-se evitar
utilizá-la ao elaborar o sistema de rotulação.
3.2.3.2.2 Superar a ausência de feedback
Numa conversa comum, os seres humanos dispõem de uma infinidade de recursos
de feedback que os auxiliam a verificar se a mensagem está sendo corretamente
assimilada. Alguns exemplos desses recursos de feedback são os gestos, o posicionamento
do corpo, a entonação de voz. Além disso, como a comunicação numa conversa ocorre de
forma síncrona, a qualquer momento pode-se fazer perguntas para solucionar as dúvidas
obtendo-se respostas de imediato (ROSENFELD e MORVILLE, 2002).
Num website, a comunicação entre o arquiteto e o usuário ocorre apenas através da
interface do website (a imagem do sistema) e de forma assíncrona. O pouco feedback que
o arquiteto recebe provém da medição do acesso às páginas (page views), e-mails de
dúvidas, sugestões e reclamações, e da análise do log do mecanismo de busca. E nenhum
destes feedbacks ocorre em tempo real.
Essa ausência de feedback torna difícil ao arquiteto de informação saber se e como
a imagem do seu sistema está sendo corretamente compreendida pelo usuário e, em caso
de erro, quais correções precisa fazer.
3.2.3.2.3 Eliminar ambigüidades
Como a linguagem humana é ambígua, ao procurar por um conteúdo em uma lista
de categorias, o usuário pode se deparar com duas ou mais categorias onde o item que
procura pode estar contido. Um smart phone, por exemplo, pode estar nas categorias
Arquitetura de Informação de websites
103
“telefone celular”, “computador de bolso (handheld)” e “câmera fotográfica”
simplesmente porque esse aparelho unifica essas três funções.
REISS (2000) recomenda, para evitar ambigüidades como essa, criar categorias
mutuamente exclusivas, sem intersecções. Porém na prática criar categorias com essas
características nem sempre é possível. Assim, uma alternativa sugerida por WODTKE
(2003) é duplicar os links. Coloca-se links para o mesmo conteúdo dentro de todas as
categorias que geram dúvidas.
Os quase-sinônimos, palavras que têm um significado muito próximo, são outro
tipo de ambigüidade. Muitas vezes a diferença de significado entre algumas palavras é tão
sutil que apenas os especialistas conhecem. Por exemplo, a diferença entre os rótulos
“Congresso” e “Conferência” é muito técnica e por isso desconhecida do público em geral.
Nesses casos, pode-se unir os dois rótulos em uma única categoria como em “Congressos
e Conferências”.
Websites grandes, que abrangem vários públicos-alvos e assuntos diferentes,
também podem ter problemas de ambigüidade causado por homonímias. Criar sub-sites
focados em poucos públicos-alvos e em poucos assuntos é uma maneira de resolver isso.
CAMPOS e colab. (2004) citam que problemas como homonímia e ambigüidades
reduzem-se muito quando se estreita a abrangência do assunto.
3.2.3.2.4 Manter a consistência
Ser consistente é talvez a mais importante diretriz da Usabilidade e se aplica
diretamente na criação dos rótulos de um website. Porém criar um sistema de rotulação
consistente é complexo porque essa consistência precisa ocorrer em diferentes níveis.
ROSENFELD e MORVILLE (2002) citam seis níveis nos quais essa consistência
precisa ser observada nos rótulos:
Centrando a Arquitetura de Informação no usuário
104
• Estilo: consistência no uso de caixa-alta e caixa-baixa e da pontuação.
• Apresentação: consistência na aplicação de fontes, cores, tamanhos de
letra e espaços em branco que reforçam o agrupamento dos labels.
• Sintaxe: uniformidade na sintaxe dos rótulos (grau, número, gênero, tempo
verbal, etc.). Usar, por exemplo, apenas verbos no infinitivo ou apenas
substantivos.
• Granularidade: equalização na especificação de cada rótulo evitando
misturar, no mesmo nível, rótulos com significado abrangente (ex:
Restaurantes) com rótulos com significado estreito (Ex: Cantinas italianas).
• Completude: cobrir completamente o escopo definido dos rótulos. Por
exemplo, se uma loja de roupas possui as categorias “calças”, “gravatas” e
“sapatos” sente-se a falta da categoria “camisas”, se uma interface possui
os comando “frente”, “trás” e “direita” sente-se a falta do comando
“esquerda”.
• Audiência: manter a consistência dos rótulos no vocabulário da audiência,
sem misturar rótulos de públicos diferentes. Por exemplo, não misturar
termos científicos com populares. Caso o website tenha mais de uma
audiência, deve-se considerar a criação de sistemas de rótulos diferentes
para cada uma.
Outro nível de consistência que precisa ser observado é a sinonímia. Qualquer
língua é repleta de sinônimos e quase sinônimos. “Farol” é sinônimo de “semáforo”,
“início” é quase sinônimo de “começo”. É preciso também manter a consistência no nível
dos sinônimos, tratando os mesmos conteúdos pelos mesmos nomes. O estreitamento do
escopo do website convergindo para poucos públicos-alvos e assuntos é uma saída para
resolver a inconsistência no nível da sinonímia (ROSENFELD e MORVILLE, 2002;
DIJCK, 2003).
Arquitetura de Informação de websites
105
3.2.3.3 A padronização dos rótulos
Da mesma forma que os elementos do sistema de navegação e pelos mesmos
motivos, utilizar rótulos padronizados é importante no design do sistema de rotulação.
Rótulos padronizados criam um nível de consistência entre os diferentes websites na
Internet permitindo que o usuário possa aplicar o modelo mental que desenvolveu para um
website em vários outros.
A Web já começa a criar alguns rótulos padrões para os websites, que nasceram do
mimetismo dos próprios desenvolvedores de websites. A seguir são listados alguns dos
rótulos padrões mais comum nos websites em inglês e suas traduções para o português
(ROSENFELD e MORVILLE, 2002; BUSTAMANTE, 2004):
• Main, Main Page, Home, Home-Page, Página Inicial.
• Search, Find, Busca, Buscar.
• Sitemap, Contents, Table of Contents, Index, Mapa do Site.
• Contact, Contact Us, Contact Webmaster, Feedback, Contate-nos, Fale
Conosco,
Entre em contato.
• Help, FAQ, Frequently Asked Questions, Ajuda, Dúvidas, Tire suas
Dúvidas.
• News, What’s New, Notícias, Últimas Notícias.
• About, About us, About < company name >, Who We Are, Quem Somos,
Sobre a <empresa>.
3.2.3.4 Ícones como rótulos
Ícones são pequenas imagens usadas para representar conceitos em substituição
aos os rótulos textuais. O advento dos sistemas operacionais gráficos trouxe os ícones para
as interfaces computacionais como um recurso para melhorar a sua usabilidade.
Segundo HORTON (1994), os ícones podem ser utilizados nas interfaces
computacionais para representar conceitos visuais e espaciais, para poupar espaço na tela,
para acelerar a localização de um rótulo, para obter reconhecimento imediato do conceito
Centrando a Arquitetura de Informação no usuário
106
pelo usuário, para melhorar a memorização da interface e para facilitar o uso para pessoas
com dificuldade de leitura (analfabetos, semi-analfabetos e estrangeiros).
A criação de um sistema de rotulação baseado em ícones é mais complexa que a de
rótulos textuais porque eles constituem uma linguagem muito mais limitada que os textos.
ROSENFELD e MORVILLE (2002) apontam essa limitação e afirmam que por causa dela
os ícones são usados tipicamente nos sistemas de navegação ou em sistemas de
organização pequenos porque a lista de opções é reduzida.
COOPER e REIMANN (2003) citam que os ícones são facilmente reconhecidos
pelos seres humanos, porém são menos precisos e claros. O ícone é ambíguo enquanto o
usuário não aprende seu significado, mas uma vez aprendido, ele não o esquece facilmente
e seu reconhecimento é mais rápido. Por isso os ícones são indicados para usuários
freqüentes.
As dificuldades vistas anteriormente para o projeto de sistemas de rotulação
baseados em rótulos textuais também se aplicam aos sistemas baseados em ícones. No
projeto de ícones precisa haver também um cuidado especial com o contexto em que as
imagens são apresentadas. HORTON (1994) aponta que uma mesma imagem pode ter
significados muito diferente conforme a situação em que é visualizada. Ícones ou textos
adjacentes, rótulos relacionados, janelas e outros objetos no ambiente onde o ícone é
apresentado são os principais elementos que criam contexto e interferem na interpretação
do ícone, podendo reforçar ou reverter totalmente seu significado.
Investigação teórica das metodologias de projetos de arquitetura de informação de websites
107
Capítulo 4
Investigação teórica
das metodologias de projetos
de arquitetura de informação
de websites
Poucos anos depois do surgimento da Web, houve em todo o mundo uma corrida
desenfreada das empresas para criar websites e negócios na Internet. Apelidada de “a
bolha da Internet”, essa corrida iniciou-se em 1995, quando a Netscape
12
fez seu IPO
13
, e
se estendeu até 2001, quando planos de negócio mal sucedidos provocaram a falência de
diversas empresas com negócios na Web. Porém, apesar das enormes perdas financeiras,
graças a essa “corrida do ouro” trilhões de dólares foram investidos na Internet, o número
12
A Netscape Network é uma empresa norte-americana pioneira que produziu o o Netscape Navigator, um
browser que foi lider de mercado no início da Web.
13
IPO é a sigla em inglês para oferta inicial pública de ações. Ela ocorre quando uma empresa emite ações
para serem negociadas em bolsas de valores.
Centrando a Arquitetura de Informação no usuário
108
de usuários da rede cresceu muito e novas tecnologias e websites conceituados foram
desenvolvidos e permanecem até hoje.
No início da bolha, era comum que os websites fossem desenvolvidos sem
qualquer metodologia. Um único profissional “faz tudo” chamado Webmaster conhecia as
principais ferramentas e linguagens de programação para Web e assumia sozinho todas as
etapas dos projetos de websites (LARA FILHO, 2003; MEMÓRIA, 2006). Essa prática
evoluiu e atualmente os projetos de websites seguem metodologias multi-disciplinares e
que envolvem diversas áreas do conhecimento e profissionais com diferentes habilidades
(DUYNE e colab. apud MEMÓRIA, 2006; MARTINEZ, 2002; GARRETT, 2003).
Segundo MEMÓRIA (2006), de forma geral, as atuais metodologias multi-
disciplinares de projetos de websites apresentam três grandes fases:
• Fase de Compreensão: na qual se pesquisa as necessidades dos usuários,
os objetivos do website e se define o escopo e requisitos do projeto.
• Fase de Concepção: na qual são definidas as regras de organização e
navegação, o estilo gráfico, a linha editorial e todos os demais elementos
que formam o modelo mental do website.
• Fase de Construção: na qual o conteúdo do website é redigido e
organizado, o design gráfico é finalizado, as páginas Web, o banco de
dados e os serviços são codificados e o website é disponibilizado para uso.
MELLY (2003) corrobora com essa divisão em fases e apresenta um diagrama
(Figura 5) no qual ilustra as principais atividades de um projeto de um website.
Investigação teórica das metodologias de projetos de arquitetura de informação de websites
109
Figura 5 - Fases do projeto de um website (MELLY, 2003)
Implementação
Implementação
Estratégia
Visão – Missão - Objetivos
Estratégia
Visão – Missão - Objetivos
Arquitetura de
Informação
Arquitetura de
Informação
Look & Feel
Look & Feel
Arquitetura + Projeto de IT
Arquitetura + Projeto de IT
Conteúdo
Conteúdo
Back office infra-estrutura,
parcerias,etc
Back office infra-estrutura,
parcerias,etc
Integração
Integração
Testes
Testes
Aceite
Aceite
Publicação
Publicação
Gerenciamento de Projetos
Gerenciamento de Projetos
Boas Práticas / Guideline
Boas Práticas / Guideline
Modelo de negócios
Modelo de negócios
Modelagem Conceitual
Modelagem Conceitual
Operação e Manutenção
Operação e Manutenção
Piloto
Piloto
Fase de Compreensão
Fase de Concepção Fase de Construção
Implementação
Implementação
Estratégia
Visão – Missão - Objetivos
Estratégia
Visão – Missão - Objetivos
Arquitetura de
Informação
Arquitetura de
Informação
Look & Feel
Look & Feel
Arquitetura + Projeto de IT
Arquitetura + Projeto de IT
Conteúdo
Conteúdo
Back office infra-estrutura,
parcerias,etc
Back office infra-estrutura,
parcerias,etc
Integração
Integração
Testes
Testes
Aceite
Aceite
Publicação
Publicação
Gerenciamento de Projetos
Gerenciamento de Projetos
Boas Práticas / Guideline
Boas Práticas / Guideline
Modelo de negócios
Modelo de negócios
Modelagem Conceitual
Modelagem Conceitual
Operação e Manutenção
Operação e Manutenção
Piloto
Piloto
Fase de Compreensão
Fase de Concepção Fase de Construção
A Moebius, também chamada de Web Progressiva ou P-Web, é outra metodologia
de projetos de websites desenvolvida por ALMEIDA e OLIVEIRA (2002) e focada mais
no detalhamento do público-alvo, do mercado, do produto e da concorrência para
estabelecer um planejamento estratégico.
Essa metodologia apresenta quatro fases: Entender, Planejar, Executar e Monitorar.
As três primeiras fases são semelhantes das fases de Compreensão, Concepção e
Construção das metodologias de MELLY (2003) e MEMÓRIA (2006). A quarta fase da
metodologia tem a função e acompanhar o desempenho do website e medir seus resultados
para executar melhorias e correções. “Na realidade, um projeto começa na prática após o
seu lançamento. É a partir desse ponto que os dados começarão a ser colhidos e
analisados; é a partir desse momento que todo o planejamento deve ser validado baseando-
se nos resultados que ele está proporcionando.” (ALMEIDA e OLIVEIRA, 2002, pág.
135).
No diagrama de MELLY (2003) é possível observar a presença da Arquitetura de
Informação como uma das atividades necessárias para o projeto de website. Ela está na
Centrando a Arquitetura de Informação no usuário
110
fase de Concepção por ser responsável pela definição da estrutura de organização das
informações, sobre a qual todas as demais partes do website irão se apoiar. Pelos mesmos
motivos, na metodologia Moebius a Arquitetura de Informação se localiza na fase
Planejar.
A Arquitetura de Informação inicia, segundo MELLY (2003), com o fim da
atividade Modelagem Conceitual, a qual teve a função de elaborar o planejamento
estratégico do website. Sua função é materializar as idéias e conceitos definidos nessa
modelagem criando as regras de organização e navegação do ambiente informacional do
website e o modelo de interação do usuário com esse ambiente.
Como visto no capítulo 3, o projeto da arquitetura de informação de um website
envolve diversas dificuldades para o design dos quatro sistemas que compões a arquitetura
de informação. A superação dessas dificuldades torna o projeto de arquitetura de
informação um problema complexo, requerendo uma metodologia para organizar o
trabalho do arquiteto e garantir a qualidade do seu produto final.
Se o processo para gerenciar o design de ambientes de informação não for
explícito, as chances de falhas aumentam. Portanto, o gerenciamento do design de
ambientes de informação é mais eficiente e efetivo quando segue um método.
(MORROGH, 2003, pág. 117)
Metodologia
14
é um conjunto de técnicas, métodos e padrões amparados por um
corpo teórico destinado a resolução de uma classe de problemas. Ela nasce da “reflexão
de um campo do conhecimento sobre si mesmo, enquanto prática teórica”
(IMMACOLATA, 2003, pág. 90), como vem ocorrendo com o campo da Arquitetura da
Informação.
14
O termo “metodologia” possui uma ambigüidade natural no sentido da palavra e por isso precisa ser
conceituado. Segundo IMMACOLATA (2003, pág. 93) “ocorre com a palavra ‘metodologia’ o mesmo que
ocorre com as palavras ‘comunicação’, ‘história’, ‘economia’ e outras, que são empregadas tanto para
indicar uma disciplina quanto o seu objeto de estudo”. Nesse trabalho a palavra “metodologia” é utilizada
para indicar o objeto de estudo, ou seja, o conjunto das técnicas, métodos e padrões.
Investigação teórica das metodologias de projetos de arquitetura de informação de websites
111
As primeiras discussões sobre uma metodologia para projetos de arquitetura de
informação de websites surgiram junto com a formulação desse campo no trabalho
pioneiro de ROSENFELD e MORVILLE. A primeira edição do “urso polar”
15
, publicada
em 1998, já continha os passos iniciais para formar essa metodologia. A segunda e a
terceira edição desse livro a aperfeiçoaram e o tornaram a referência mais citada na
literatura.
Diversos outros autores (SAPIENT apud MORROGH, 2003; BUSTAMANTE,
2004; WODTKE, 2003; DIJCK, 2003; REISS, 2000; SHIVA, 2000, WEST, 2001)
propuseram novas visões e incrementos para a metodologia de projetos de arquitetura de
informação, trazendo ferramental técnico e teórico de diversas disciplinas como a Ciência
da Informação, a Interação Humano-Computador e todas as demais que compõem o seu
caráter multi-disciplinar apresentado no capítulo 3.
Porém ainda não existe uma consolidação e comprovação de todas suas técnicas de
modo a formar um corpo teórico que caracterize a disciplina, o que faz do processo de
design de arquitetura de informação algo ainda bastante intuitivo (HAVERTY, 2002).
4.1 Princípios para metodologias de projeto de arquitetura de
informação de websites
Antes de iniciar uma análise das metodologias de projetos de arquitetura de
informação de websites é preciso levantar quais princípios regem essas metodologias de
modo a formar um quadro de referência para avaliar as metodologias propostas.
Uma característica marcante nos projetos de arquitetura de informação de websites
é o fato de serem processos de design (MORROGH, 2003). Essa característica, aponta
HAVERTY (2002), fica evidente no fato de que o trabalho de um arquiteto de informação
é um processo de criar soluções para problemas de design. BELTON (2003) corrobora
com esse conceito ao comparar a Arquitetura de Informação com a Arquitetura e propõe a
15
Apelido do livro Information Architecture for the Word Wide Web de ROSENFELD. & MORVILLE
publicado pela O’Reilly em 1998. A capa do livro tem uma foto desse animal.
Centrando a Arquitetura de Informação no usuário
112
adoção de uma abordagem de design na formação dos arquitetos de informação. Por fim a
definição de Arquitetura de Informação proposta pelo Information Architecture Institute
(2005) e por ROSENFELD e MORVILLE (2002) vistas no capítulo 3 também explicitam
essa característica.
Segundo CHIOU (2003) processos de design são processos criativos e de grande
esforço intelectual nos quais se faz um balanceamento entre forma e função para criar um
objeto útil e agradável aos usuários. FRIEDMAN (2003) concorda com essa definição ao
afirmar que design é um processo orientado ao objetivo de resolver problemas, atender
necessidades ou criar algo novo e útil. SIMON (apud FRIEDMAN, 2003, pág. 508)
também corrobora e cita que “o design é um processo de conduzir ações com o objetivo de
transformar situações existentes em situações preferidas”. Projetos de arquitetura de
informação possuem as características dos processos de design e por isso os conceitos
desses processos podem ser aplicados nos projetos de arquitetura de informação.
De fato, o próprio projeto do website como um todo também é um processo de
design e cada das fases que o compõem também são. Como em um fractal, onde o desenho
das partes é igual ao desenho do todo, tanto a visão macro do projeto do website quanto a
visão micro de cada uma das suas fases são processos de design.
Segundo MORROGH (2003) um processo de design possui basicamente quatro
fases:
• Análise: onde os usuários e o ambiente de uso do objeto são estudados e os
objetivos são definidos.
• Design Conceitual: onde as estratégias e as regras da solução são
definidas.
• Design e Desenvolvimento: onde as estratégias e regras são aplicadas
especificando, com suficiente riqueza, os detalhes do objeto a ser
construído.
• Implementação: onde o objeto é construído conforme a especificação.
Investigação teórica das metodologias de projetos de arquitetura de informação de websites
113
NEWTON (apud BELTON, 2003) propõe outra divisão ao processo de design,
adotada na Harvard School of Design nos anos de 1950 e 1960, e que também expressa a
visão de FRIEDMAN (2000). Segundo NEWTON (apud BELTON, 2003, pág. 145) o
processo de design possui três fases:
• Programação: a fase para reconhecer e delimitar o problema básico em
termos de necessidades humanas, e para decidir de forma geral que
conjunto de ações ou provisões são mais apropriados para produzir a
solução.
• Análise: na qual o designer analisa cuidadosamente as relações entre as
várias atividades envolvidas no problema e, por meio de sínteses visuais e
imaginativas, desenvolve a estrutura específica – a forma e a organização
específica – da solução física concreta que irá acomodar o complexo de
atividades.
• Representação e Implementação: para que a criação da sua imaginação
possa realmente existir, o designer prepara desenhos de trabalhos e outros
documentos de contratação e fornece supervisão e todas as diretivas para
os homens cujos esforços combinados resultarão na construção do produto
final, na obra do design.
Pode-se observar que, apesar das diferenças de nomenclatura, existe muita
semelhança entre as fases dos processos de design propostos por MORROGH (2003) e
NEWTON (apud BELTON, 2003) e até com as fases da metodologia de projeto de
websites proposta por MEMÓRIA (2006), MELLY (2003) e ALMEIDA e OLIVEIRA
(2002) vistas anteriormente.
Em todos esses casos o processo de design inicia com uma fase na qual o projetista
levanta e analisa as informações sobre os usuários, suas necessidades e o seu ambiente
para definir o escopo e os requisitos do projeto. MORROGH (2003) denomina essa fase
de “Análise”, NEWTON (apud BELTON, 2003) a denomina de “Programação”,
ALMEIDA e OLIVEIRA (2002) a denomina de “Entender” e tanto MEMÓRIA (2006)
quanto MELLY (2003) a denominam de “Compreensão”. Nenhum desses termos adotados
Centrando a Arquitetura de Informação no usuário
114
evidencia a principal ação executada nessa fase, que é pesquisar todas as informações
necessárias para compreender e delimitar o problema a ser resolvido. Assim utilizaremos o
termo Pesquisa para definir essa fase evidenciando essa ação.
No caso específico das metodologias de projetos de arquitetura de informação, as
abordagens de Design Centrado no Usuário da Ciência da Informação trazem uma
importante contribuição para a fase de Pesquisa porque possuem fundamentos teórico-
metodológicos e técnicas que podem ser empregadas nessa fase. Essas abordagens
propõem formar uma visão holística do usuário e buscam uma compreensão global das
suas situações de uso da informação antes, durante e depois das suas interações com o
sistema de informação (no caso o website). Essa proposta se alinha com o trio usuário-
conteúdo-contexto que, segundo ROSENFELD e MORVILLE (2006), a Arquitetura de
Informação busca compreender e atender.
Após a fase de Pesquisa, o processo de design possui uma fase eminentemente
criativa, na qual se concebe a visão macro, as linhas gerais, da solução. MORROGH
(2003) chama essa fase de “Design Conceitual”, NEWTON (apud BELTON, 2003) a
chama de “Análise” e ALMEIDA e OLIVEIRA (2002) a chamam de “Planejar”. MELLY
(2003) e MEMÓRIA (2006) utilizam o termo “Concepção”. Este último é o mais
adequado porque representa melhor a principal ação dessa fase: conceber a solução do
problema de design por meio da inventividade do projetista.
É na fase de Concepção que se tem a maior contribuição da abordagem de Design
Centrado no Usuário da Interação Humano-Computador na metodologia de projeto de
arquitetura de informação. Essa abordagem possui três fundamentos: focalizar no usuário
e nas suas tarefas desde o inicio do projeto, aplicar medidas empíricas da usabilidade e
utilizar um processo de design iterativo e interativo com refinamentos sucessivos. Esses
fundamentos e as técnicas deles decorrentes, especialmente as avaliações de usabilidade,
são ferramentas importantes para que o arquiteto de informação possa definir, validar e
refinar sua solução.
Após a fase de Concepção, o processo de design apresenta uma fase na qual a
visão macro da solução é detalhada em documentos e diagramas que explicam como
construir o objeto, que no caso dos projetos de arquitetura de informação é o próprio
Investigação teórica das metodologias de projetos de arquitetura de informação de websites
115
website. NEWTON (apud BELTON, 2003) denomina essa fase de “Representação”,
MORROGH (2003) a chama de “Design e Desenvolvimento”, ALMEIDA e OLIVEIRA
(2002) a chamam de “Executar” e tanto MELLY (2003) e quanto MEMÓRIA (2006)
utilizam o termo “Construção”. Como a principal ação nessa fase é especificar a
construção do objeto, utilizamos o termo Especificação para denominá-la.
Por fim, o processo de design termina com uma fase na qual o objeto especificado
é construído e disponibilizado para uso. ALMEIDA e OLIVEIRA (2002), MELLY (2003)
e MEMÓRIA (2006) denominam essa fase o mesmo termo da fase anterior porque esses
autores não a distinguem. MORROGH (2003) e NEWTON (apud BELTON, 2003)
distinguem essa fase da anterior e ambos utilizam o termo “Implementação” para
denominá-la. Distinguir as fases de Especificação e Implementação é importante nos
projetos de arquitetura de informação porque a construção do website normalmente não é
responsabilidade do arquiteto de informação e sim dos programadores e dos outros
membros do time do projeto. Utilizamos o termo Implementação para denominar a última
fase do processo de design porque é o que melhor representa a principal ação nessa fase:
construir o objeto conforme a especificação.
Um aspecto que merece destaque nos processos de design é que normalmente eles
não possuem uma fase de avaliação dos resultados destinada a analisar o produto final, o
objeto que foi construído. ALMEIDA e OLIVEIRA (2002) são os únicos autores que
possuem uma fase com esse objetivo na metodologia que propõem: a fase “Monitorar”.
Segundo FRIEDMAN (2003, pág. 514) “os designers freqüentemente terminam seu
envolvimento com o projeto antes que as falhas apareçam e os contratantes normalmente
não retornam ao designer original para reparar o trabalho”.
Após a implementação, o objeto resultante do processo de design está construído e
inicia-se seu uso. Nesse momento todas as estratégias e conceitos da solução definidos
durante o projeto e que produziram o objeto de design são colocados a prova e os erros e
acertos evidenciam-se. Assim, para buscar a melhoria da prática, a metodologia de
projetos de arquitetura de informação precisa preocupar-se em avaliar os resultados dos
projetos e registrar seus acertos e erros. Esses registros irão, ao longo do tempo, se
Centrando a Arquitetura de Informação no usuário
116
consolidar em boas práticas e recomendações de design. É o acúmulo desse conhecimento
que transformará a arte em ciência e o artesão em profissional.
A avaliação de resultados é também uma prática recomendada para qualquer
metodologia de projetos como forma de aperfeiçoamento constante da qualidade e da
técnica (PROJECT MANAGEMENT INSTITUTE, 2004) e, por isso, precisa estar
presente nas metodologias de projetos de arquitetura de informação. Para FRIEDMAN
(2003, pág. 521) é “a nossa interpretação e entendimento da experiência que conduz ao
conhecimento”.
Assim, as metodologias de projetos de arquitetura de informação necessitam ter
uma fase que complemente o processo de design e avalie os resultados do projeto.
Utilizamos o termo “Avaliação” para denominar essa fase de forma a evidenciar sua
principal ação.
Sintetizando os conceitos apresentados, temos os seguintes princípios que formam
o quadro de referência para análise das metodologias de projeto de arquitetura de
informação de websites:
• Possuir cinco fases distintas:
o Pesquisa: na qual são pesquisadas e analisadas as informações
sobre os usuários, suas necessidades e o seu ambiente para definir o
escopo e os requisitos do projeto.
o Concepção: uma fase eminentemente criativa, na qual se concebe a
visão macro da solução.
o Especificação: na qual a visão macro da solução é detalhada em
documentos e diagramas que explicam como construir o website.
o Implementação: na qual website é construído conforme
especificado e disponibilizado para uso.
o Avaliação: na qual o resultado do projeto é avaliado em função dos
seus objetivos iniciais para se registrar os acertos e erros.
• Aplicar na fase de Pesquisa os fundamentos e técnicas das abordagens de
Design Centrado no Usuário da Ciência da Informação de forma a buscar
Investigação teórica das metodologias de projetos de arquitetura de informação de websites
117
uma visão holística do usuário e uma compreensão global de suas situações
particulares de uso de informação, incluindo o antes e o depois de suas
interações com o website.
• Aplicar na fase de Concepção os fundamentos e técnicas do Design
Centrado no Usuário da Interação Humano-Computador de forma a
focalizar no usuário e nas suas tarefas desde o início do projeto a ter um
processo de design com um ciclo iterativo e interativo de definição,
validação e refinamento da solução utilizando avaliações de usabilidade.
4.2 Análise das metodologias de projeto de arquitetura de
informação de websites
Por ser um campo novo, ainda existe uma carência de literatura sobre metodologias
de projetos de arquitetura de informação de websites (BUSTAMANTE, 2004). Dentre as
metodologias encontradas na revisão bibliográfica três merecem destaques pelo seu grau
de detalhamento. Essas metodologias estão apresentadas na Figura 6 e são analisadas a
seguir.
Centrando a Arquitetura de Informação no usuário
118
Figura 6 - Metodologias de projetos de arquitetura de informação de websites
Investigação teórica das metodologias de projetos de arquitetura de informação de websites
119
A primeira metodologia, proposta por ROSENFELD e MORVILLE (2002), é a
mais completa e detalhada de todas. Esses autores, como já visto, são pioneiros no campo
da Arquitetura de Informação e a metodologia que propõem tem suas origens e
comprovação prática na pioneira Argus, a primeira empresa a trabalhar com Arquitetura
de Informação de websites.
Essa metodologia está dividida em 5 fases: Pesquisa (Research), Estratégia
(Strategy), Design, Implementação (Implementation) e Administração (Administration).
Para esses autores, um projeto de arquitetura de informação termina após a execução das
primeiras quatro fases. A quinta fase representa o gerenciamento do website e por isso se
destaca do projeto. As cinco fases juntas compõem, na visão desses autores, um programa
de Arquitetura de Informação, que tem o objetivo de definir, administrar e melhorar
continuamente a organização da informação do website.
A segunda metodologia, proposta pela empresa SAPIENT (2000) e documentada
por MORROGH (2003), possui um menor grau de detalhamento porque não descreve as
técnicas utilizadas em cada fase. Essa metodologia nasceu no ano 2000 como resultado da
fusão da metodologia da Sapient e de outras duas empresas desenvolvedoras de websites:
a Studio Archetype e a Adjacency
16
(SAPIENT, 2000).
A metodologia da SAPIENT (apud MORROGH, 2003) divide o projeto de
arquitetura de informação em 5 fases subdivididas em 19 atividades. Essas 5 fases são:
Descoberta (Discover), Definição (Define), Concepção (Concept), Design (Design) e
Implementação (Implement). Nessa metodologia existe também uma fase de Pré-Projeto
que antecede todas as demais e tem o objetivo de explicar aos profissionais da empresa
contratante (ou outra entidade que esteja contratando o projeto) o que é Arquitetura de
Informação e elaborar uma proposta informal de trabalho.
Explicar aos profissionais da empresa contratante como é o trabalho do arquiteto
de informação é uma forma interessante de divulgar esse novo campo, de despertar nesses
16
A Sapient adquiriu inicialmente a Studio Archteype em agosto de 1998 e depois a Adjacency em abril de
1999 (SAPIENT, 2000).
Centrando a Arquitetura de Informação no usuário
120
profissionais a importância da Arquitetura de Informação no design de websites e de
conseguir que eles se comprometam com o projeto. ROSENFELD e MORVILLE (2002)
também citam a importância dessa explicação e reservam uma atividade para isso dentro
da fase de Pesquisa (Research) na metodologia que propõem.
Diferente da metodologia de ROSENFELD e MORVILLE (2002), na metodologia
da SAPIENT (apud MORROGH, 2003) não existem uma fase destinada a administrar o
website. O motivo para isso é que a SAPIENT é uma empresa focada apenas na criação de
websites e não na sua operação no dia-a-dia.
Por fim a terceira metodologia é proposta por BUSTAMANTE (2004) e mostra um
grau de detalhamento das fases e técnicas intermediário em relação às duas propostas
anteriores. Porém esse autor não demonstra comprovação prática da efetividade da sua
metodologia. Trata-se apenas de uma coleção das “melhores e mais elementares práticas
que devem ser executadas para se obter um produto de sucesso e de qualidade”
(BUSTAMANTE, 2004, pág. 38).
A metodologia de BUSTAMANTE (2004) é a que apresenta a maior quantidade de
fases, 12 no total: Estudo da audiência e suas necessidades (Estudio de la audiência y sus
necessidades), Definição dos objetivos do website (Definición de los objetivos del sitio),
Determinação dos conteúdos e requerimentos funcionais (Determinación de los
contenidos y los requerimientos funcionalies), Definição da estrutura do website (Definir
la estructura del sítio), Desenho gráfico e visual (Diseño gráfico e visual), Definição e
criação de planos e protótipos (Definición y creación de plantillas y prototipos), Avaliação
e prova dos planos (Evalución y prueba de plantillas), Redesenho dos planos (Rediseño de
plantillas), Definição das estratégias de posicionamento (Definición de las estrategias de
posicionamiento), Criação do guia de estilo da arquitetura de informação e usabilidade
(Criación de la guía de estilo de arquitectura de información y usabilidad), Produção e
Implementação (Producción e implementación), e Avaliações (Evaluaciones).
Merece destaque nessa metodologia a presença de uma fase de Definição das
estratégias de posicionamento do website (Definición de las estrategias de
Investigação teórica das metodologias de projetos de arquitetura de informação de websites
121
posicionamiento). Na proposta de BUSTAMANTE (2004), um website também é visto
como um produto
17
que se lança no mercado e por isso precisa ter definidas suas
estratégias mercadológicas, como a publicidade e a promoção. Essa fase tem a mesma
função da modelagem conceitual na metodologia de projeto de websites proposta por
MELLY (2003) e vista na Figura 5.
As metodologias propostas por ROSENFELD e MORVILLE (2002) e SAPIENT
(apud MORROGH, 2003) não explicitam a necessidade de definir as estratégias
mercadológicas do website no projeto de arquitetura de informação porque esses autores
consideram que essa tarefa é atribuição dos gerentes e diretores da empresa contratante em
parceria com suas áreas de marketing. Para esses autores, cabe ao arquiteto de informação
compreender esse planejamento e utilizá-lo como um dos requisitos de projeto.
Outros autores (SHIPLE, 2001; DIJCK, 2003; WODTKE, 2003; WEST, 2001;
REISS, 2000) também propõem guias ou tutoriais para a execução de projetos de
arquitetura de informação de websites. Porém, apesar desses autores trazerem
contribuições importantes e que serão citadas no decorrer desse trabalho, eles não
apresentam uma metodologia completa e detalhada como as propostas de ROSENFELD e
MORVILLE (2002), SAPIENT (apud MORROGH, 2003) e BUSTAMANTE (2004). As
propostas desses autores limitam-se a descrever as três primeiras fases do processo de
design: Pesquisa, Concepção e Especificação.
Embora todas as metodologias, guias e tutoriais encontrados na literatura
apresentem várias diferenças, especialmente nas nomenclaturas e nos graus de
detalhamento das fases, métodos e técnicas, é possível identificar muitas semelhanças
entre elas quando analisadas segundo o quadro de referência formulado no início desse
capítulo. Na Figura 7 estão apresentadas as três metodologias vistas anteriormente com
suas fases classificadas nas cinco fases do quadro de referência. Em seguida cada uma das
fases do quadro de referência será analisada nessas três metodologias.
17
O conceito de produto utilizado por BUSTAMANTE (2004) é o mesmo definido no capítulo Capítulo 2 .
Centrando a Arquitetura de Informação no usuário
122
Figura 7 - Análise das metodologias nas fases do quadro de referência
Investigação teórica das metodologias de projetos de arquitetura de informação de websites
123
4.2.1 A fase de Pesquisa
A fase de Pesquisa é o momento no processo de design no qual os usuários, as
necessidades e o ambiente são estudados para se delimitar o problema a ser resolvido. Nas
três metodologias propostas podem ser observadas fases e atividades com esse objetivo,
como visto na Figura 7.
Na metodologia proposta por ROSENFELD e MORVILLE (2002), todo o trabalho
da fase de Pesquisa está concentrado numa fase que leva o mesmo nome (Pesquisa ou
Research). Para esses autores a fase de Pesquisa inicia o projeto de arquitetura de
informação e tem por objetivo entender completa e detalhadamente o problema a ser
resolvido e definir o escopo e as restrições do projeto. É o momento em que o trio usuário-
conteúdo-contexto é cuidadosamente estudado para se determinar todas as restrições que o
website precisa atender. A função dessa fase é “obter um entendimento de alto nível dos
objetivos e do contexto de negócio, da arquitetura de informação existente, do conteúdo e
da audiência futura” (ROSENFELD e MORVILLE, 2002, pág. 212).
Na metodologia proposta pela SAPIENT (apud MORROGH, 2003) existem duas
fases destinadas a executar a fase de Pesquisa: Descoberta (Discover) e Definição
(Define). A fase de Descoberta tem por objetivo entender o contexto e o escopo do
projeto. Trata-se de uma fase de planejamento, na qual é feita a transferência de
conhecimento da empresa para o arquiteto e se planeja a pesquisa que será executada na
fase seguinte.
O foco da fase de Definição é pesquisar e sintetizar as variáveis do projeto e definir
o problema e as oportunidades. Para isso são conduzidas pesquisas com o intuito de
entender o negócio da empresa, os usuários, suas necessidades, seus comportamentos e as
tecnologias que poderão ser utilizadas no website.
Por fim, na metodologia proposta por BUSTAMANTE (2004) temos a fase de
Pesquisa dividida em três fases: Estudo da audiência e suas necessidades (Estudio de la
audiência y sus necessidades), Definição dos objetivos do website (Definición de los
objetivos del sitio), Determinação dos conteúdos e requerimentos funcionais
Centrando a Arquitetura de Informação no usuário
124
(Determinación de los contenidos y los requerimientos funcionalies). As duas primeiras
fases têm o objetivo de pesquisar respectivamente o usuário e a empresa. A última fase
tem a função de avaliar os resultados das pesquisas realizadas nas duas fases anteriores
para sintetizar o escopo e os requisitos do projeto com relação aos conteúdos e
funcionalidades que deverão ser disponibilizados no website.
Outros autores (REISS, 2000; SHIPLE, 2001; DIJCK, 2003; WODTKE, 2003)
também evidenciam a importância da fase de Pesquisa e ressaltam os mesmos objetivos:
pesquisar o usuário e a empresa para definir os requisitos e restrições do website a ser
construído.
4.2.1.1 Variáveis de pesquisa
Observando-se as fases e atividades nas metodologias de ROSENFELD e
MORVILLE (2002), SAPIENT (apud MORROGH, 2003) e BUSTAMANTE (2004)
nota-se que todas elas pesquisam dois grandes grupos de variáveis. O primeiro grupo são
as variáveis sobre a empresa, que identificam seus objetivos e capacidades. O segundo
grupo são as variáveis sobre os usuários, que identificam como eles se segmentam, quais
são as suas necessidades, os seus comportamentos e as suas linguagens. Esses dois grupos
de variáveis também estão presentes nos trabalhos de REISS (2000), SHIPLE (2001),
DIJCK (2003) e WODTKE (2003).
A existência desses dois grupos de variáveis se justifica porque, conforme os
conceitos de necessidade apresentados no capítulo 2, um website é um produto
desenvolvido por uma empresa para atender as necessidades de seus clientes/usuários. Em
troca, como afirma REISS (2000), a empresa espera ser recompensada de forma tangível
(aumento de vendas, redução de custos, melhora na produtividade, etc.) ou intangível
(divulgação da marca, melhoria da imagem, etc.). Assim, esses dois grupos de variáveis
visam mapear a relação usuário-empresa que o website deverá atender. Esses dois grupos
estão detalhados a seguir:
Investigação teórica das metodologias de projetos de arquitetura de informação de websites
125
4.2.1.1.1 Grupo de variáveis de pesquisa sobre a empresa
As variáveis sobre a empresa formam o primeiro grupo de variáveis estudadas na
fase de Pesquisa e retratam os objetivos de negócio da empresa, as suas restrições e
capacidades, a sua organização e os seus processos internos. DIJCK (2003) cita que essas
variáveis têm influência direta nas decisões de design e por isso o arquiteto de informação
precisa estar familiarizado com elas.
A síntese do trabalho dos diversos autores (REISS, 2000; SHIPLE, 2001;
ROSENFELD e MORVILLE, 2002; DIJCK, 2003; WODTKE, 2003; SAPIENT apud
MORROGH, 2003; BUSTAMANTE, 2004) explicita quatro variáveis que compõem o
grupo de variáveis sobre a empresa. São elas:
• Proposta de valor ou Objetivo do negócio
Retrata a função principal, o propósito, a razão da existência do website e
determina a direção que o projeto deverá seguir e os resultados esperados.
Por ser fruto do planejamento estratégico, a explicitação da proposta de valor do
website é altamente dependente do grau de maturidade da empresa nessa área. Empresas
com baixo grau de maturidade não têm seus objetivos, restrições e públicos-alvos bem
definidos, o que dificulta o trabalho de pesquisa dessas informações.
Quando você insiste em falar sobre estratégia, os membros do time vão
frequentemente resistir, dizendo que eles “apenas querem fazer as coisas”. Não
desista – ter a estratégia discutida no início vai poupar tempo depois quando se
discutir as funcionalidades e detalhes do design. (DIJCK, 2003, pág. 24)
Cabe muitas vezes ao arquiteto de informações estimular a empresa a definir a
proposta de valor do website. BUSTAMANTE (2004) reserva na sua metodologia uma
fase exclusivamente para isso (fase Definição dos objetivos do website ou Definición de
los objetivos del sitio), na qual são aplicadas técnicas próprias da elaboração de um
planejamento estratégico.
Centrando a Arquitetura de Informação no usuário
126
A crítica a essa proposta de BUSTAMANTE vem do fato de que a elaboração de
um planejamento estratégico envolve técnicas e habilidades que não são próprias da
Arquitetura de Informação, o que pode produzir propostas de valor superficiais e mal
definidas. Segundo SOUZA (2001), propostas de valor mal definidas levam o projeto de
design de um website a resultados inesperados.
• Público-Alvo
No grupo de variáveis sobre a empresa, público-alvo é o grupo de pessoas que a
empresa espera que utilize o website. Podem existir vários públicos-alvos diferentes,
separados conforme seus objetivos, necessidades e comportamentos.
A determinação dos públicos-alvos do website é fundamental para garantir sua
usabilidade. Como visto, a norma ISO 9241-11 aponta que a usabilidade trata de facilitar o
uso de um produto para usuários específicos, não para qualquer usuário, porque criar um
produto com uma boa usabilidade para qualquer usuário é impossível na prática.
• Requisitos e Diretrizes de Implementação
Os requisitos e diretrizes de implementação são as variáveis que mapeiam o
contexto da empresa onde o website está inserido de forma a identificar a capacidade que
essa empresa tem de implementá-lo e administrá-lo. A SAPIENT (apud MORROGH,
2003) e WODTKE (2003) demonstram preocupação em pesquisar essas variáveis e
ROSENFELD e MORVILLE (2002) justificam a importância de pesquisá-las como forma
de garantir que o projeto do website seja viável de implementação.
No nosso mundo dos sonhos, nos gostaríamos de projetar nossa arquitetura de
informação independente da tecnologia, e um time de analistas de sistemas e
desenvolvedores de software construiria a infra-estrutura e as ferramentas que
suportariam nossa visão.
Investigação teórica das metodologias de projetos de arquitetura de informação de websites
127
No mundo real isso não ocorre com freqüência. Normalmente nós temos que
trabalhar com as ferramentas e a infra-estrutura que já existe. Isso significa que
nós precisamos avaliar o ambiente de IT [Information Technology ou Tecnologia
da Informação] bem no começo do projeto para que nossas estratégias e o nosso
design seja baseado na realidade. (ROSENFELD e MORVILLE, 2006, pág. 239)
Sintetizando os autores citados nota-se a existência de três variáveis que formam
os requisitos e as diretrizes de implementação:
• Requisitos Técnicos: determinam as tecnologias que serão utilizadas para
implementar o projeto e os sistemas computacionais com os quais o website
deverá se integrar. Abrangem as linguagens de programação (HTML,
Javascript, Flash, ASP, Java, etc.), especificações dos computadores dos
usuários e dos servidores (sistema operacional, browser, resolução do monitor,
etc.), ferramentas de desenvolvimento e operação do website (editores de
HTML, banco de dados, softwares de gerenciamento de conteúdos, etc.) e os
sistemas legados da empresa (ERP, CRM, etc.).
• Requisitos Operacionais: determinam os profissionais e máquinas que
atuarão na operação do website após sua implantação. Abrangem todos os
processos internos da empresa que surgirão ou se modificarão com o
nascimento do website (resposta de e-mails, atendimento a clientes,
manutenção e publicação dos conteúdos, entrega de pedidos, etc.).
• Diretrizes de Posicionamento: determinam como o website irá se comunicar
com o usuário e que imagem deve-lhe transmitir. Abrange as diretrizes de
comunicação da empresa e diretrizes de cores e uso de logotipos, tom de
linguagem, etc.
• Recompensa da empresa
A recompensa da empresa é a variável que determina o lucro da empresa com o
website, o retorno esperado. Trata-se da tradução da proposta de valor do website em
indicadores numéricos ou qualitativos que irão mensurar o desempenho e avaliar o sucesso
Centrando a Arquitetura de Informação no usuário
128
do website. Até mesmo empresas sem fins lucrativos ou organizações do terceiro setor
(ONGs) esperam alguma recompensa quando lançam um website (captar mais doações,
divulgar seus trabalhos, conquistar novos voluntários, etc.).
De forma genérica, esses indicadores versam sobre tempo (redução de prazo,
aumento da agilidade, etc.), dinheiro (redução de custo, aumento da receita, etc.) e
satisfação dos usuários (aumento da qualidade do serviço, diminuição de reclamações,
etc.) (REISS, 2003).
REISS (2000) e SOUZA (2001) são os autores que demonstram maior
preocupação em determinar esses indicadores. Para SOUZA (2001), esses indicadores
precisam ser determinados no início do projeto e comunicado a toda equipe para que todos
tenham clareza do objetivo que o website pretende alcançar.
REISS (2000) também cita a importância de determinar esses indicadores no início
do projeto, especialmente nos casos onde o website tem por objetivo melhorar uma
situação existente. Nesses casos os indicadores precisam ser mensurados antes e depois do
projeto para avaliar se a mudança que gerou melhorias.
4.2.1.1.2 Grupo de variáveis de pesquisa sobre o usuário
O segundo grupo de variáveis a serem estudadas na fase de Pesquisa são as
variáveis de pesquisa sobre o usuário, as quais tem a função de explicar quem é o usuário
do website, quais são suas necessidades, o seu comportamento e a sua linguagem. Trazer o
usuário para o centro das decisões do projeto é a proposta das abordagens de Design
Centrado no Usuário, sejam as da Ciência da Informação, sejam as da Interação Humano-
Computador. Daí a importância de pesquisar esse grupo de variáveis.
A informação obtida sobre os usuários no grupo de variáveis sobre a empresa
(público-alvo do website) acumula a experiência de relacionamento da empresa com seus
clientes e, por isso, merece ser respeitada. Porém essas variáveis podem ser influenciadas
pela cultura, paradigmas e políticas internas da empresa, o que pode dificultar o projeto do
sistema de organização e rotulação, como visto no capítulo anterior. Dessa forma, o grupo
Investigação teórica das metodologias de projetos de arquitetura de informação de websites
129
de variáveis sobre o usuário tem o objetivo secundário de comprovar a veracidade do
grupo de variáveis da empresa.
Outro fator que motiva a pesquisa do grupo de variáveis sobre o usuário é o fato de
que as informações que o arquiteto de informação precisa para o seu trabalho
normalmente não existem dentro da empresa (WODTKE, 2003).
Todos os autores levantados na literatura (REISS, 2000; SHIPLE, 2001;
ROSENFELD e MORVILLE, 2002; DIJCK, 2003; WODTKE, 2003; SAPIENT apud
MORROGH, 2003; BUSTAMANTE, 2004) demonstram preocupação em pesquisar o
usuário e cada um deles apresenta uma lista própria de variáveis de pesquisa, que estão
sintetizadas a seguir:
• Objetivos do usuário
Identifica as principais necessidades dos usuários que o website deverá atender. A
análise do objetivo do usuário está diretamente relacionada com a proposta de valor do
website, determinada no grupo de variáveis da empresa. Porém, como cita REISS (2000) e
SOUZA (2001), nem sempre essas variáveis estão alinhadas. A proposta de valor que a
empresa determina para o website pode não ser do interesse do usuário, daí a importância
de pesquisar essa variável.
Como um website pode ter mais de um público-alvo, é possível que existam vários
objetivos, provenientes de usuários distintos, que podem até serem conflitantes
(WODTKE, 2003). Assim pode ser necessário priorizar os usuários e seus objetivos.
• Experiência do usuário
Mapeia o caminho (tarefas e objetivos) que o usuário percorre para atender suas
necessidades e alcançar seus objetivos. A função dessa variável é mapear toda a
experiência do usuário na busca da realização do seu objetivo e mapear o ambiente em que
está inserido (REISS, 2000).
Centrando a Arquitetura de Informação no usuário
130
O mapeamento desse caminho influencia diretamente o design do sistema de
navegação porque aponta o caminho cognitivo com que o usuário está mais acostumado.
Ele retrata todas as etapas, todos os passos que o usuário percorre para alcançar seu
objetivo.
• Informações necessárias em cada etapa
Discrimina as informações que o usuário utiliza em cada passo no caminho que
percorre para alcançar seu objetivo. Essas informações irão compor o espaço
informacional do website.
• Linguagem do usuário
Indica os termos, os rótulos, que o usuário atribui as informações. Durante a
execução do seu processo de busca de informação, o usuário utiliza uma linguagem
própria na qual conceitos e símbolos se relacionam. A compreensão dessa linguagem irá
auxiliar a definir o sistema de rotulação
4.2.1.2 Técnicas empregadas na fase de Pesquisa
As técnicas sugeridas pelos autores (REISS, 2000; SHIPLE, 2001; ROSENFELD e
MORVILLE, 2002; DIJCK, 2003; WODTKE, 2003; SAPIENT apud MORROGH, 2003)
para a fase de Pesquisa são basicamente técnicas para pesquisar as informações que
delimitam os grupos de variáveis sobre a empresa e sobre o usuário. Essas técnicas estão
apresentadas a seguir.
4.2.1.2.1 Técnicas para pesquisa do grupo de variáveis sobre a empresa
Para a pesquisa do grupo de variáveis sobre a empresa, os autores (REISS, 2000;
SHIPLE, 2001; ROSENFELD e MORVILLE, 2002; DIJCK, 2003; WODTKE, 2003;
SAPIENT apud MORROGH, 2003) sugerem a realização de entrevistas com os
funcionários da empresa envolvidos com o projeto do website e a análise dos seu
relatórios internos.
Investigação teórica das metodologias de projetos de arquitetura de informação de websites
131
Segundo ROSENFELD e MORVILLE (2002), é responsabilidade dos gerentes e
diretores da empresa definir a proposta de valor do website, seus públicos-alvos e a
recompensa da empresa porque essas variáveis são decorrentes do planejamento
estratégico que esses profissionais elaboram para a empresa. A forma que esses autores
sugerem para iniciar os trabalhos de pesquisa das variáveis sobre a empresa é entrevistar
esses profissionais porque, além de serem a principal fonte dessas informações, envolve-
los no início ajuda a garantir o comprometimento deles ao longo projeto. Esse
comprometimento é importante porque, como visto no capítulo anterior, o design do
sistema de organização envolve dificuldades relacionadas às políticas internas da empresa
e são esses profissionais que têm poder e condições de resolvê-las.
WODTKE (2003) sugere também a consulta à área de marketing para obter
informações mais detalhadas sobre os públicos-alvos porque essa área tradicionalmente
conduz pesquisas sobre esses públicos. Relatórios internos da empresa, como os relatórios
de vendas, dúvidas, reclamações, etc., complementam e detalham os públicos-alvos
porque trazem muita informação sobre seus hábitos, interesses e necessidades. Porém,
como afirma essa autora, as informações obtidas com a área de marketing não são
suficientes para um projeto de arquitetura de informação porque elas normalmente
retratam os motivos que levam os vários públicos-alvos a comprar os produtos da empresa
e não como eles organizam as informações e quais linguagens utilizam.
Por fim ROSENFELD e MORVILLE (2002) sugerem como fonte de informação
para pesquisar essas variáveis entrevistas com os profissionais da empresa que atuam nas
áreas de informática, marketing e de todas as demais áreas relacionadas com o website
(SAC, vendas, assistência técnica, etc.) porque os profissionais dessas áreas conhecem os
detalhes da operação da empresa e os seus sistemas legados.
4.2.1.2.2 Técnicas para pesquisa do grupo de variáveis sobre o usuário
Para a pesquisa das variáveis sobre o usuário, os autores (REISS, 2000; SHIPLE,
2001; ROSENFELD e MORVILLE, 2002; DIJCK, 2003; WODTKE, 2003; SAPIENT
apud MORROGH, 2003) sugerem a realização do inventário de conteúdo, a análise das
estatísticas de acesso ao website, a análise do log do mecanismo de busca e a realização de
avaliações de usabilidade.
Centrando a Arquitetura de Informação no usuário
132
O inventário de conteúdo (content inventory) é uma técnica que consiste em obter
amostras dos conteúdos que serão disponibilizados no website e descrevê-los com meta-
dados. Trata-se de um método que mistura variáveis dos grupos da empresa e do usuário e
visa mapear e compreender todo o conjunto de informações que o arquiteto precisa
organizar (ROSENFELD e MORVILLE, 2002; WODTKE, 2003).
Para tanto nessa técnica é feita uma análise bottom-up (de baixo para cima)
empregando o “método da Arca de Noé”: coletar duas amostras de cada tipo de conteúdo
representativo. Como o objetivo da coleta é conhecer as propriedades dos conteúdos do
website, a coleta termina quando o arquiteto perceber que não está mais descobrindo
novidades e se sente capaz de inferir as propriedades de todos os demais conteúdos que irá
organizar (MORVILLE, 2002; FRASER, 2001).
A visão bottom-up do inventário de conteúdo coloca essa técnica mais próxima do
grupo de variáveis sobre a empresa porque se baseia mais nas informações que a empresa
dispõe e que nas requeridas pelos usuários.
Uma sugestão para complementar o inventário de conteúdo e aproximá-lo do grupo
de variáveis do usuário é acrescentar uma análise top-down (de cima para baixo),
levantando quais informações o website precisa apresentar a partir do mapeamento das
necessidades do usuário. Nem todos os passos do caminho que o usuário percorre para
alcançar seus objetivos podem estar sendo atendidos pelos conteúdos obtidos na análise
bottom-up. Assim a análise top-down irá trazer novos conteúdos para o website.
A análise top-down também pode ser aplicada aos conteúdos obtidos no inventário
bottom-up, de forma a verificar quais conteúdos encontrados se relacionam com cada
objetivo do usuário. Cada conteúdo disponibilizado em um website implica em custos para
a empresa, tanto de implementação quanto de manutenção. Dessa forma espera-se com
essa análise eliminar conteúdos “órfãos”, conteúdos que não se relacionam a nenhum dos
objetivos do usuário e consequentemente não trazem valor.
Investigação teórica das metodologias de projetos de arquitetura de informação de websites
133
A análise das estatísticas de acesso ao website consiste no uso de pacotes de
software, como o Google Analytics
18
, que produzem estatísticas dos usuários (da onde
vieram, quantos são novos, quantos são antigos, etc.) e das páginas exibidas (quantidade
de exibição, dia e horário de maior visitação, etc.). Com a análise dessas estatísticas é
possível identificar os conteúdos mais acessados no website auxiliando o design dos
sistemas de organização e navegação (ROSENFELD e MORVILLE, 2006; REISS, 2000).
Pacotes de softwares mais sofisticados permitem analisar o caminho que o usuário
percorreu ao longo do website (por quais página entrou, quais páginas visitou, em qual
página abandonou o website). Essas ferramentas produzem informações bastante ricas
sobre a navegação dos usuários, mas trazem mais informações sobre o uso do website e
que sobre os próprios usuários. Elas não explicam porque o usuário entrou no website, se
encontrou o que precisava e porque o abandonou. ROSENFELD e MORVILLE (2006)
citam que algumas empresas utilizam questionários on-line apresentados no momento que
o usuário abandona o website para obter essas informações.
A análise do log do mecanismo de busca é uma técnica sugerida por ROSENFELD
e MORVILLE (2002) que consiste em levantar as palavras chaves digitadas pelos usuários
ao utilizar o sistema de busca do website. Essa técnica permite revelar “problemas
relativos à falta de consistência entre a organização da informações e sua expressão no
sistema, por um lado, e a expectativa e interesse do usuário, por outro lado” (MELLY e
colab. , 2003). Ela traz informações ricas sobre que conteúdos os usuários buscam, quais
termos eles mais utilizam e como o website os supre, contribuindo diretamente para o
design dos sistemas de organização e de rotulação.
Com relação as avaliações de usabilidade, os autores (REISS, 2000; SHIPLE,
2001; ROSENFELD & MORVILLE, 2002; DIJCK, 2003; WODTKE, 2003; SAPIENT
apud MORROGH, 2003) propõem técnicas que seguem a Discount Usability proposta
por Nielsen (1994).
18
O Google Analytics é um software gratuito desenvolvido pela Google e acessível pela web que permite
mensurar quantas vezes uma página de um websit foi visitada de onde vieram seus usuários. Disponível em
http://www.google.com/analytics.
Centrando a Arquitetura de Informação no usuário
134
As técnicas mais sugeridas são o Card Sorting e os testes com protótipos de baixa
fidelidade como os protótipos em papel. Ambas se destinam a avaliar com o usuário
propostas de soluções sobre quais informações o website deve conter e como serão
organizadas. O Card Sorting apresenta essas hipóteses através de uma lista de conteúdos
que solicita ao usuário classificar e rotular. Já os testes com protótipos de baixa fidelidade
fazem isso por meio de telas prototipadas que simulam a navegação no website.
Essas técnicas são bastante eficientes e eficazes para se testar com usuários
propostas de design de qualquer interface computacional. Porém não são adequadas para
identificar as necessidades, os comportamentos e as informações que o usuário precisa por
serem focadas na avaliação do uso da interface. Dessa forma, essas técnicas são mais
adequadas nas fases seguintes do processo de design (Concepção e Especificação), na qual
o modelo mental do website será definido e precisa ser avaliado.
A fase de Pesquisa na metodologia de projetos de arquitetura de informação
precisa buscar técnicas voltadas a conhecer o usuário e as suas necessidades, ou seja,
precisa de técnicas que sigam os paradigmas da abordagem alternativa dos estudos de
usuários e necessidades da Ciência da Informação. BUSTAMANTE (2004) é o único
autor que sugere técnicas baseadas nessa abordagem. Esse autor indica o uso da
metodologia de identificação das necessidades de informação de usuários proposta por
DEVANDASON e LINGAM (1996), que foi construída com base nessas abordagens.
“Essa metodologia é recomendada pela sua simplicidade, clareza e facilidade de
aplicação” (BUSTAMANTE, 2004, pág. 39).
4.2.2 A fase de Concepção
A fase de Concepção é o momento no processo de design onde são definidas as
linhas gerais da solução. Trata-se da fase mais criativa do processo, na qual o produto final
começa a ser concebido. Nas metodologias de projetos de arquitetura de informação é
nessa fase que são definidas as regras dos sistemas de organização, de navegação, de
rotulação e de busca. É o início da criação do modelo mental do website.
Investigação teórica das metodologias de projetos de arquitetura de informação de websites
135
Todas três as propostas de metodologias de projetos de arquitetura de informação
(ROSENFELD e MORVILLE, 2002; SAPIENT apud MORROGH, 2003;
BUSTAMANTE, 2004) demonstram grande preocupação com essa fase e dedicam
atividades em suas metodologias exclusivamente para ela, como visto na Figura 7.
ROSENFELD e MORVILLE (2004, pág. 241) reservam na metodologia que
propõem a fase Estratégia (Strategy) para a fase de Concepção do quadro de referência.
Para esses autores, o objetivo da sua fase é produzir uma estratégia para a arquitetura de
informação do website, ou seja, “uma armação conceitual de alto nível para estruturar e
organizar um website ou intranet”. Essa estratégia cria as regras dos quatro sistemas que
compõem a arquitetura de informação do website e tem por objetivo prover um firme
senso de direção e escopo para prosseguir com confiança nas fases seguintes da
metodologia. Ela também facilita a discussão e o alinhamento entre os membros da equipe
de projeto.
A SAPIENT (apud MORROGH, 2003) dedica à fase de Concepção uma fase com
o mesmo nome (Concepção ou Concept). Nessa metodologia, as atividades que compõem
a fase de Concepção formam um ciclo interativo e iterativo de criação, avaliação e
refinamento dos conceitos destinado a criar a visão geral do site. Esse ciclo segue a
abordagem de Design Centrado no Usuário da Interação Humano-Computador.
O produto da fase de Concepção na metodologia da SAPIENT (apud MORROGH,
2003) é um documento que registra os conceitos criados, a visão macro do website. Na
metodologia de ROSENFELD e MORVILLE (2002) também há uma atividade que
produz um documento semelhante chamado Relatório Estratégico (Strategy Report). Esse
documento tem a função de materializar os conceitos e regras dos quatro sistemas, alinhar
a equipe de projeto e guiar as manutenções futuras do website.
A metodologia de BUSTAMANTE (2004) possui seis fases que formam a fase de
Concepção: Definição da estrutura do website (Definir la estructura del sítio), Desenho
gráfico e visual (Diseño gráfico e visual), Definição e criação de planos e protótipos
(Definición y creación de plantillas y prototipos), Avaliação e prova dos planos
(Evalución y prueba de plantillas), Redesenho dos planos (Rediseño de plantillas) e
Criação do guia de estilo da arquitetura de informação e Usabilidade (Criación de la guía
Centrando a Arquitetura de Informação no usuário
136
de estilo de arquitectura de información y usabilidad). As fases Avaliação e prova dos
planos e Redesenho dos planos formam o ciclo interativo e iterativo, que também atende
aos princípios do Design Centrado no Usuário da Interação Humano-Computador.
A fase Definição das estratégias de posicionamento (Definición de las estrategias
de posicionamiento) não foi classificada em nenhuma fase do quadro de referência porque
essa fase da metodologia de BUSTAMANTE (2004) tem por objetivo definir estratégias
mercadológicas para o website, como visto anteriormente. A definição dessas estratégias
não faz parte do escopo do trabalho do arquiteto de informação porque independem da
organização do website.
Devido a existência da fase Desenho gráfico e visual, nota-se na metodologia de
BUSTAMANTE (2004) uma mistura entre a Arquitetura de Informação e o Projeto
Gráfico. Segundo esse autor, os elementos criados nessa fase determinam o “look & feel”
do website e são de suma importância para o seu êxito. De fato é inegável a importância
que o projeto gráfico tem no sucesso de um website e o quanto ele se inter-relaciona com a
arquitetura de informação. Segundo NORMAN (2003) um design atrativo e agradável
aumenta a usabilidade aparente da interface. Porém a estética não deve prevalecer sobre a
compreensão da informação senão se terá um website bonito mas com baixa usabilidade.
BUSTAMANTE (2004) menciona também a importância de documentar os
conceitos definidos na fase de Concepção e reserva uma das fases da sua metodologia para
isso, a fase de Criação do Guia de Estilo de Arquitetura de Informação e Usabilidade
(Criación de la guía de estilo de arquitectura de información y usabilidad). Para esse
autor, a documentação dos conceitos é uma ferramenta de comunicação e alinhamento da
equipe de projeto.
O ponto comum nessas metodologias propostas assim como no trabalho de outros
autores (REISS, 2000; SHIPLE, 2001; DIJCK, 2003; WODTKE, 2003) é a presença do
ciclo interativo e iterativo de criação, avaliação e refinamento dos conceitos na fase de
Concepção.
Conforme a abordagem de Design Centrado no Usuário da Interação Humano-
Computador, as atividades que compõem esse ciclo devem ser repetidas várias vezes no
Investigação teórica das metodologias de projetos de arquitetura de informação de websites
137
projeto e não existe uma regra de quando terminar de repeti-las. A SAPIENT (apud
MORROGH, 2003) afirma que o ciclo termina quando a equipe de projeto avalia que a
arquitetura proposta está boa o suficiente. HIX (apud MARTINEZ, 2000) aponta que três
passagens por esse ciclo são suficientes para se obter uma versão satisfatória do design,
sendo que a maior parte dos dados vem da primeira passagem. Disponibilidade de tempo e
recursos influenciam diretamente na quantidade de passagens nesse ciclo (ROSENFELD e
MORVILLE, 2002).
Assim, sintetizando todos esses autores citados temos que a fase de Concepção é
responsável por definir os conceitos que formam a visão macro do website a ser criado.
Para tanto essa fase inicia-se com um ciclo interativo e iterativo de três atividades: criação
dos conceitos, avaliação dos conceitos e refinamento dos conceitos. Esse ciclo cria a visão
geral e as regras dos quatro sistemas que compõem a arquitetura de informação do website
(os sistemas de organização, de navegação, de rotulação e de busca). Depois de repetir
essas atividades várias vezes de modo que a solução atenda o escopo e todos os requisitos
do projeto, a fase de Concepção termina com uma atividade de documentação dos
conceitos, que registra as regras dos quatro sistemas e as comunica à toda equipe do
projeto. A Figura 8 ilustra essas quatro atividades que formam a fase de Concepção.
Figura 8 - Atividades que compõem a fase de Concepção
Criação
os conceitos
Criação
os conceitos
Refinamento os
conceitos
Refinamento os
conceitos
Avaliação os
conceitos
Avaliação os
conceitos
Documentação
os conceitos
Documentação
os conceitos
Criação
os conceitos
Criação
os conceitos
Refinamento os
conceitos
Refinamento os
conceitos
Avaliação os
conceitos
Avaliação os
conceitos
Documentação
os conceitos
Documentação
os conceitos
Centrando a Arquitetura de Informação no usuário
138
A seguir são apresentadas as principais técnicas sugeridas pelos autores citados
para a fase de Concepção.
4.2.2.1 Técnicas da fase de Concepção
Todos os autores citados (ROSENFELD e MORVILLE, 2002; SAPIENT apud
MORROGH, 2003; BUSTAMANTE, 2004; REISS, 2000; SHIPLE, 2001; DIJCK, 2003;
WODTKE, 2003) apresentam técnicas apenas para as atividades de definição e avaliação
dos conceitos na fase de Concepção. Não foram encontradas técnicas para o refinamento
dos conceitos. Para a atividade de documentação dos conceitos foram encontrados apenas
modelos da documentação a ser produzida, como o Relatório Estratégico (Strategic
Report) proposto por ROSENFELD e MORVILLE (2002).
As técnicas sugeridas para as duas primeiras atividades dessa fase estão
apresentadas a seguir.
4.2.2.1.1 Técnicas para a definição dos conceitos
A definição dos conceitos é uma atividade bastante criativa, na qual são concebidas
as regras dos quatro sistemas que compõem a arquitetura de informação do website. Nela
são exploradas todas as informações obtidas na fase de Pesquisa de modo a criar uma
visão geral de um modelo de organização capaz de acomodar todos os requisitos do
projeto.
As técnicas sugeridas para essa atividade são basicamente técnicas de estimulo à
criatividade, geração de idéias em time e de comunicação das idéias. Elas têm a função de
gerar sugestões e conceitos para compor as regras dos sistemas de organização, de
navegação, de rotulação e de busca. ROSENFELD e MORVILLE (2002) são os autores
que apresentam a lista mais completa de técnicas para essa atividade, que estão
sintetizadas a seguir:
Investigação teórica das metodologias de projetos de arquitetura de informação de websites
139
• Exploração de Metáforas
Técnica sugerida por SHIPLE (2001), ROSENFELD e MORVILLE (2002) e
BUSTAMANTE (2004) que consiste em fazer um mapeamento criativo de conceitos
novos em conceitos familiares. “Metáforas são uma ferramenta poderosa para comunicar
idéias complexas e gerar entusiasmo” (ROSENFELD e MORVILLE, 2002).
O uso de metáforas é recomendado por esses autores porque elas ajudam muito a
entender e organizar as informações de um website em um nível alto de abstração. Porém
as metáforas podem ser limitantes do processo criativo se seguidas a risca na
implementação. Segundo NIELSEN (2000), é difícil encontrar uma única metáfora que
consiga mapear exatamente todos os conteúdos e serviços que o website quer oferecer.
Elas podem também dificultar o crescimento do website porque novos conteúdos que
fazem sentido no contexto on-line podem não fazer sentido na metáfora e vice-versa.
• Personas
É a criação de arquétipos de usuários que servem de exemplos do público-alvo que
irá utilizar o website. Trata-se da criação de um personagem com nome, foto e a descrição
de suas habilidades, atitudes, restrições, experiências, comportamentos e objetivos
(ROSENFELD e MORVILLE, 2002; WODTKE, 2003).
Essa técnica foi desenvolvida por COOPER (1999) e se baseia em técnicas de
pesquisa de mercado. Sua função é materializar as abstrações sobre o público-alvo.
Personas ajuda você a entender para quem fazer o design e como agradar aquele
usuário – aquele ser humano. Humanizar a audiência é o grande benefício dos
personas. O “usuário” genérico se torna o ser humano específico “Sam”. Cada
momento que um membro do time pensa sobre as funcionalidades potenciais e diz
“usuários devem gostar disso” você pode apontar para o persona e perguntar “o
Sam vai usar isso?”. Os vagos “usuários” alvo do design e que são capazes de
qualquer coisa se tornam um consumidor específico com coisas que necessita e
usa, assim como coisas que não quer e não pode usar. Repentinamente, priorizar
funcionalidades se torna um trabalho fácil. (WODTKE, 2003, pág. 165)
Centrando a Arquitetura de Informação no usuário
140
• Cenários
São pequenas histórias que relatam como os usuários vão idealmente usar o
website. Eles descrevem o ambiente do usuário, que situação o motivou a utilizar o
website e como ocorreu toda a sua interação. São uma simplificação dos métodos de
análise de tarefas muito utilizados em estudos de usabilidade e funcionam como uma
ferramenta de design, de avaliação e de comunicação (SHIPLE, 2001; ROSENFELD e
MORVILLE, 2002; DIJCK, 2003; WODTKE, 2003; BUSTAMANTE, 2004).
O valor dos cenários é que eles relatam as funções do website em relação aos
objetivos do usuário, o que torna a discussão mais fácil e as decisões de design
mais acertadas. Cenários são especialmente úteis em combinação com personas:
os personas descrevem as motivações e objetivos, os cenários descrevem as tarefas
concretas. (DIJCK, 2003, pág. 66)
• Diagramas de Overview
São diagramas com uma visão geral e hierárquica da arquitetura de informação do
website, onde as idéias começam a tomar forma. Metáforas, personas e cenários são boas
ferramentas para estimular a criatividade e a colaboração, mas são caóticos e
desorganizados. Diagramas de overview organizam as idéias e criam uma visão mais
prática e factível (REISS, 2000; ROSENFELD e MORVILLE, 2002; WODTKE, 2003).
REISS (2000) e WODTKE (2003) sugerem também outros dois tipos de diagramas
que auxiliam no processo criativo do arquiteto de informação: mindmaps (representa a
associação de idéias) e o site path diagram (representa o caminho que os usuários,
representado por personas, percorrem no website).
• Mock-up das principais páginas
São esboços muito simplificados das páginas, especificando seus elementos
principais. Eles retratam os elementos necessários em cada página e por isso são menos
abstratos que os diagramas de overview. Sua função é visualizar e comunicar de forma
Investigação teórica das metodologias de projetos de arquitetura de informação de websites
141
clara as implicações da arquitetura de informação no nível da página (ROSENFELD e
MORVILLE, 2002; WODTKE, 2003).
4.2.2.1.2 Técnicas para a avaliação dos conceitos
Após desenvolver os conceitos e regras dos quatro sistemas que formam a
arquitetura de informação do website, a próxima atividade na fase de Concepção consiste
em avaliá-los para verificar se são factíveis de implementação. Para ROSENFELD e
MORVILLE (2002), a avaliação dos conceitos envolve a resposta a três perguntas:
• Atende as necessidades de negócio?
• É viável técnica e operacionalmente?
• É fácil de usar?
Segundo esses autores, as respostas das duas primeiras perguntas é obtida com os
profissionais da empresa que foram entrevistados na fase de Pesquisa. Como foram esses
profissionais que definiram a proposta de valor do website e os requisitos e diretrizes para
a implementação, eles são as pessoas mais adequadas para avaliar se a arquitetura de
informação proposta atende as necessidades de negócio e é viável técnica e
operacionalmente.
Para responder a terceira pergunta, “é fácil de usar?”, diversos autores sugerem a
realização de avaliações de usabilidade com técnicas provenientes da Interação Humano-
Computador (REISS, 2000; ROSENFELD e MORVILLE, 2002; DIJCK, 2003; SAPIENT
apud MORROGH, 2003; WODTKE, 2003; BUSTAMANTE, 2004). A seguir são
apresentadas as técnicas de avaliação de usabilidade utilizadas em projetos de arquitetura
de informação mais citadas na literatura:
• Análise Heurística
É um método de avaliação de usabilidade no qual especialistas em usabilidade
(inspetores) inspecionam as características da interface (especificações, protótipos ou o
produto final) e analisam se elas vão contra as heurísticas (princípios gerais) de
usabilidade. Sua função é avaliar se o website segue os princípios de um bom design e
Centrando a Arquitetura de Informação no usuário
142
consequentemente, se possui boa usabilidade. Esse método pode ser aplicado nos
primeiros esboços de telas do projeto para verificar se nenhuma heurística está sendo
desrespeitada. Com essa técnica é possível avaliar o design dos quatro sistemas da
arquitetura de informação (organização, navegação, rotulação e busca).
Ainda são poucos e preliminares os estudos de heurísticas específicas para a
Arquitetura de Informação de websites. Destacam-se as heurísticas para Arquitetura de
Informação (ROSENFELD, 2004a), as heurísticas para sistemas de busca (ROSENFELD,
2004b) e o Navigation Stress Test (INSTONE, 2004).
• Card Sorting
Método de teste com usuários para explorar como eles agrupam itens. Consiste em
entregar ao usuário uma pilha de cartões, cada um deles representando um conteúdo do
website, e solicitar que ele os organize. Seu objetivo é gerar a estrutura global da
informação ou avaliar uma estrutura já existente, por isso a técnica é indicada para auxiliar
o projeto dos sistemas de organização e rotulação. Variantes dessa técnica podem ser
usadas tanto para auxiliar a definir os esses sistemas quanto para validá-los.
MAURER e WARFEL (2004) é uma das melhores referências sobre o uso do card
sorting em projetos de arquitetura de informação. Esses autores descrevem a técnica e suas
variantes com detalhes.
• Protótipos em papel
Método de teste com usuário no qual são empregados protótipos da interface com
baixa fidelidade elaborados com desenhos em papel. Seu objetivo é avaliar, através de um
teste com usuários, os sistemas de organização, de navegação, de rotulação e de busca.
Serve também como uma ferramenta de comunicação para facilitar o entendimento do
design por toda a equipe do projeto.
É a técnica que apresenta os maiores avanços, com diversas variantes e casos de
aplicação documentados. SNYDER (2003) é uma das mais completas referências sobre
essa técnica.
Investigação teórica das metodologias de projetos de arquitetura de informação de websites
143
4.2.3 A fase de Especificação
A fase de Especificação tem a função de detalhar e documentar os conceitos
definidos na fase de Concepção produzindo uma especificação detalhada dos quatro
sistemas de organização, de navegação, de rotulação e de busca aplicada aos conteúdos
que o website irá oferecer. Nessa fase são produzidos os diversos documentos de
especificação da arquitetura de informação, como o sitegrama, os fluxos de navegação, os
wireframes e o vocabulário controlado.
A maioria dos autores pesquisados na literatura (REISS, 2000; SHIPLE, 2001;
ROSENFELD e MORVILLE, 2002; DIJCK, 2003; WODTKE, 2003; SAPIENT apud
MORROGH, 2003) também dedicam fases exclusivamente para a fase de Especificação
nas suas metodologias, guias e tutoriais. A exceção mais marcante é BUSTAMANTE
(2004) que não diferencia essa fase da fase de Concepção, como mostra Figura 7.
O que se nota na metodologia desse autor é uma grande mistura das fases de
Concepção e Especificação. De fato a fase de Especificação nada mais é que o
detalhamento dos diagramas (diagrama de overview e mock-up das páginas) produzidos na
fase anterior. Porém a separação em fases distintas reforça a importância de avaliar e
validar os conceitos antes de produzir uma extensa documentação reduzindo assim
possíveis retrabalhos.
Na metodologia proposta por ROSENFELD e MORVILLE (2002), é fase de
Design corresponde à fase de Especificação do quadro de referência, como visto na
Figura 7. Segundo esses autores, nessa fase são produzidos todos os documentos que
guiarão o trabalho dos profissionais responsáveis por implementar o website.
Design é onde você transforma uma estratégia de alto nível em uma arquitetura de
informação, criando esquemas detalhados, wireframes e meta-dados que serão
utilizados por designers gráficos, programadores, redatores e o time de produção.
É nessa fase tipicamente onde os arquitetos de informação fazem a maior parte do
trabalho, mas quantidade não significa qualidade. Uma fase de Design [fase de
Especificação] mal executada pode ruir a melhor das estratégias [fase de
Concepção].(ROSENFELD e MORVILLE, 2002, pág. 212).
Centrando a Arquitetura de Informação no usuário
144
SAPIENT (apud MORROGH, 2003) também denomina de Design a fase destinada
à fase de Especificação (Figura 7). Nessa fase, além da elaboração de uma documentação
detalhada da arquitetura de informação, são realizados mais testes com o usuário e é
revisto o documento que registrou os conceitos elaborados na fase de Concepção.
Ao se elaborar uma documentação detalhada da arquitetura de informação do
website, todos os conceitos definidos passam naturalmente por uma análise em cada um
dos seus casos de uso, o que pode causar alterações. Dependendo do impacto e da
importância dessas alterações, novos testes com usuários podem ser necessários para
validar as modificações nos conceitos, o que justifica a presença de uma atividade de
avaliação da usabilidade na fase de Especificação na metodologia da SAPIENT.
Outros autores (REISS, 2000; SHIPLE, 2001; DIJCK, 2003; WODTKE, 2003)
também dedicam bastante atenção à fase de Especificação e sugerem modelos de
documentos para essa fase, os quais têm a função de modelar o website provendo visões
múltiplas para diferentes audiências, semelhante as tradicionais ferramentas de
modelagem utilizadas na Engenharia de Software.
YOURDON (1990, pág. 83) aponta que existem três motivos básicos na
Engenharia de Software para a construção de modelos:
• Focalizar a atenção nas características mais importantes do sistema dando
menos atenção às menos importantes.
• Discutir modificações e correções nos requisitos do usuário com baixo
custo e mínimo risco.
• Verificar se o analista conhece corretamente o ambiente do usuário e
documentou de tal maneira que os projetistas e programadores podem
construir o sistema.
Esse autor também recomenda que se utilize modelos gráficos por três motivos:
conseguem englobar uma imensa quantidade de informações de forma concisa e
compacta, permitem que o sistema seja visualizado de forma subdividida e hierárquica e
têm redundância mínima.
Investigação teórica das metodologias de projetos de arquitetura de informação de websites
145
Modelos gráficos, como os utilizados na Engenharia de Software, se baseiam em
vocabulários visuais próprios. Vocabulários visuais são um conjunto de símbolos gráficos,
cada qual representando um conceito relevante ao sistema, e regras que definem quando e
como utilizar cada símbolo. Alguns exemplos de vocabulários visuais são os diagramas de
fluxo de dados (DFD), diagramas de entidade-relacionamento (ER) e os fluxogramas.
A maioria dos documentos propostos pelos diversos autores (REISS, 2000;
SHIPLE, 2001; ROSENFELD e MORVILLE, 2002; DIJCK, 2003; WODTKE, 2003) para
a fase de Especificação são modelos gráficos com vocabulários visuais próprios,
inspirados nos modelos da Engenharia de Software.
Existe bastante concordância entre os autores quanto aos principais tipos de
documentos necessários nessa fase: o sitegrama, o fluxo das transações, os wireframes e o
vocabulário controlado. Esses tipos de documentos estão descritos a seguir.
4.2.3.1 Sitegrama e Fluxo das Transações
O sitegrama (também chamado de mapa do site) e o fluxo das transações são os
documentos com maior nível de abstração entre os tipos de documentos de especificação
da Arquitetura de Informação. Juntos eles têm a função de apresentar uma visão geral do
website mostrando o relacionamento entre as páginas (REISS, 2000; ROSENFELD e
MORVILLE, 2002; WODTKE, 2003; DIJCK, 2003).
Provavelmente o sitegrama é o mais clássico dos documentos da Arquitetura de
Informação. Trata-se de um diagrama que representa a organização hierárquica do website
e que contém todas as páginas de conteúdo e a entrada de todas as transações (WODTKE,
2003). Normalmente são elaborados através de diagramas em árvore, especialmente para
se representar hierarquias. “Eles [os sitegramas] fornecem um significado para um grupo
de pessoas conversarem a respeito do website e terem uma representação visual dele”
(DIJCK, 2003, pág. 108).
O fluxo das transações é um diagrama que representa o modelo de interação do
usuário ao executar as transações do website. Contém todas as páginas das transações
incluindo mensagens de erro e sucesso. Para essa representação são utilizados fluxogramas
Centrando a Arquitetura de Informação no usuário
146
que indicam como ocorrem as transações entre as páginas (REISS, 2000; ROSENFELD e
MORVILLE, 2002; WODTKE, 2003; DIJCK, 2003).
Segundo GARRETT (2002), ambos os documentos são utilizados também como
ferramentas de comunicação com a equipe de projeto e por isso atendem os diferentes
propósitos dos diferentes profissionais:
• Arquitetos de Informação: usam para organizar as informações e
apresentar a hierarquia e a navegação entre as páginas do website.
• Diretores de Arte e Designers Gráficos: usam para definir o número de
tipos de telas e para desenhar graficamente os menus do website.
• Redatores e Produtores de Conteúdo: usam para compreender os
requisitos de conteúdo do website
• Programadores e Analistas: usam para definir os requisitos técnicos e a
modelagem do software e do banco de dados do website.
GARRETT (2002) é o autor da proposta de vocabulário visual para elaboração de
sitegramas e fluxo das transações mais popular e mais citada na literatura. Trata-se de um
conjunto de 22 símbolos diferentes que representam os principais conceitos de Arquitetura
de Informação e Design de Interação. Esse conjunto é independente de ferramentas (pode
ser utilizado em diversos softwares gráficos e até em desenhos a mão livre) e sua
descrição original já foi traduzida para diversos idiomas (chinês, japonês, russo, espanhol,
italiano, francês, alemão e português).
4.2.3.2 Wireframe
O wireframe é um diagrama que especifica uma página do website. Ele representa
uma página definindo seus elementos, a hierarquia entre eles, seus agrupamentos e suas
importâncias relativas. Seu objetivo é especificar a implementação da página e comunicar
o conteúdo e as funções de cada página para discussão com a equipe do projeto (REISS,
2000; ROSENFELD e MORVILLE, 2002; WODTKE, 2003; DIJCK, 2003).
Investigação teórica das metodologias de projetos de arquitetura de informação de websites
147
Um wireframe (ou esquema de página, como é chamado às vezes) é um esboço
básico de uma página individual, desenhado para indicar os elementos da página,
seus relacionamentos e suas importâncias relativas. Ele é muito parecido com a
armação que um escultor faz antes de adicionar barro: ele dá forma e prove
suporte. (WODTKE, 2003, pág. 284)
Segundo ROSENFELD e MORVILLE (2002), assim como o sitegrama e o fluxo
das transações, o wireframe é utilizado com diferentes propósitos pelos membros da
equipe de projeto:
• Arquitetos de Informação: usam para especificar cada página do website.
• Diretores de Arte e Designers Gráficos: utilizam para definir a linha
gráfica do website e o layout de cada página.
• Redatores e Produtores de Conteúdo: usam para especificar os conteúdos
das páginas.
• Empresa contratante: usa para validar se o conteúdo das páginas atende
aos requisitos do projeto.
O wireframe é o primeiro documento que começa a dar forma ao layout gráfico das
páginas, por isso ele pode ser um forte motivo de discussão entre o arquiteto de
informação e o designer gráfico. Apesar de não ser seu foco, o wireframe apresenta uma
sugestão de organização espacial para o layout da página, o que pode restringir a liberdade
criativa do designer gráfico. Assim WODTKE (2003) sugere que o wireframe seja fruto de
um trabalho de equipe, criado em conjunto pelo arquiteto de informação e pelo designer
gráfico. Esse tipo de abordagem minimiza divergências entre esses profissionais e produz
um wireframe com maior fidelidade em relação ao layout final da página. A elaboração de
layouts de alta fidelidade é mais custosa, porém eles são mais facilmente compreendidos,
especialmente por pessoas pouco familiarizadas com esse tipo de documento.
Não existe uma proposta de vocabulário visual para wireframes. Cada autor
(REISS, 2000; ROSENFELD e MORVILLE, 2002; WODTKE, 2003; DIJCK, 2003) tem
seu conjunto próprio de símbolos. O que se percebe de comum é a existência de três níveis
ou camadas diferentes na especificação do wireframe. A primeira camada é onde ocorre a
Centrando a Arquitetura de Informação no usuário
148
representação gráfica dos elementos. Nela os elementos são desenhados com o grau de
fidelidade escolhido para o projeto. A segunda camada identifica esses elementos e mostra
seus agrupamentos e hierarquias. Por fim, a última camada descreve os elementos, suas
funções e os detalhes da sua implementação.
4.2.3.3 Vocabulário Controlado
Vocabulário controlado é um instrumento bastante utilizado pela Ciência da
Informação em trabalhos de classificação. Trata-se de uma linguagem artificial, ou seja,
uma linguagem construída com base em um conjunto de regras prescritivas estabelecidas
anteriormente a sua utilização, e como toda linguagem artificial, não comporta exceções
(WERSIG apud CAMPOS e colab. , 2004).
Na Arquitetura de Informação a função dos vocabulários controlados é especificar
os rótulos que podem ser utilizados no website e os meta-dados utilizados na indexação do
sistema (ROSENFELD e MORVILLE, 2002).
ROSENFELD e MORVILLE (2002) e FAST e colab. (2003) indicam a existência
de quatro tipos de vocabulários controlados, que variam conforme o grau de complexidade
e o grau de relacionamento entre seus termos. Sintetizando esses autores, os tipos são os
seguintes:
• Anéis de Sinônimos (Synonym Rings): Trata-se de um conjunto de
palavras definidas como sinônimas para os propósitos de uma busca. É o
mais simples dos tipos de vocabulário controlado e se baseia em um único
tipo de relacionamento entre os termos, a equivalência ou sinonímia. Na
prática as palavras que compõem um anel de sinônimos nem sempre são
realmente sinônimas. Podem conter termos abrangentes, termos
específicos, termos científicos, termos populares, abreviações e até erros de
ortografia e digitação, porém, para os propósitos do website, todos os
termos são considerados sinônimos. A função dos anéis de sinônimos é
aumentar a relevância dos resultados das buscas feitas no website para os
diferentes tipos de usuários, mesmo que eles utilizem diferentes termos
para se referir ao mesmo conceito.
Investigação teórica das metodologias de projetos de arquitetura de informação de websites
149
• Arquivos de Autoridade (Authority Files): É um conjunto de termos
equivalentes como os anéis de sinônimos com a diferença que um dos
termos é definido como preferencial. A função dos arquivos de autoridade é
compreender as diferentes variantes da linguagem do usuário e traduzi-las
para os termos utilizados no website. Normalmente os termos preferenciais
se transformam nos rótulos utilizados nas páginas e no sistema de
navegação.
• Esquemas de Classificação: Trata-se de uma organização hierárquica de
termos preferenciais. Também chamados de taxonomias, esses esquemas
são utilizados para montar os menus hierárquicos do sistema de navegação
e para indexar a informação.
• Tesauro: É o tipo mais complexo de vocabulário controlado porque
contém três tipos de relacionamento entre os termos: equivalência,
hierarquia e associação. Sua função é criar uma rede semântica que
estruture todo o conhecimento. Os tesauros auxiliam na indexação dos
termos no mecanismo de busca, na construção dos menus hierárquicos, na
definição dos rótulos dos elementos nas páginas e na definição dos cross
contents.
A construção de vocabulários controlados é bastante trabalhosa, especialmente no
caso do tesauro, assim é comum utilizar vocabulários controlados prontos e apenas adaptá-
los às necessidades do website (ROSENFELD e MORVILLE, 2002).
Por ser um campo novo é comum que as pessoas, especialmente as sem
experiência com projetos de websites, não sejam familiarizadas com os documentos da
Arquitetura de Informação. Isso pode dificultar a compreensão dos documentos
ocasionando erros na fase de Implementação. Assim ROSENFELD e MORVILLE (2002)
recomendam, para minimizar tais erros, que a primeira apresentação desses documentos
para qualquer público seja feita em reuniões presenciais, de modo a solucionar dúvidas e
estabelecer uma melhor comunicação.
Centrando a Arquitetura de Informação no usuário
150
Já existem algumas ferramentas CASE
19
específicas para automatizar a elaboração
e manutenção dos documentos de Arquitetura de Informação, em especial para elaborar o
sitegrama, o fluxo das transações e os wireframes. Alguns exemplos são o Axure,
Elegance Tech, iRise, Serena, Simunication e Sofea (McDOWELL, 2006). Porém esses
softwares ainda são pouco difundidos. As ferramentas mais utilizadas pelos arquitetos de
informação para elaborar seus documentos de especificação são Microsoft Visio,
Microsoft Word, Microsoft Excel, Microsoft Power Point, Omni Graffle e Ilustrator
(ROSENFELD e MORVILLE, 2006b). A elaboração dessa documentação é a fase mais
trabalhosa nos projetos de arquiteto de informação, assim, a pesquisa, o desenvolvimento
e a difusão de ferramentas CASE que automatizem esse trabalho merece ser estimulada.
4.2.4 A fase de Implementação
A fase de Implementação é o momento em que o website é construído. Nessa fase
todas as especificações elaboradas na fase anterior são desenvolvidas e implementadas
transformando as idéias em realidade.
Nas propostas de metodologias de projeto de arquitetura de informação pouca
atenção é dedicada a essa fase. REISS (2000), SHIPLE (2000), WODTKE (2003) e
DIJCK(2003) não fazem quaisquer comentários sobre a fase de Implementação,
possivelmente porque essa fase não demanda grandes esforços criativos do arquiteto.
ROSENFELD e MORVILLE (2002) dedicam à fase de Implementação uma fase
com o mesmo nome (Implementação ou Implementation), como mostra a Figura 7, porém
também reservam poucos comentários a ela. Segundo esses autores, nessa fase os demais
profissionais envolvidos com o projeto (designers gráfico, redatores, programadores, etc.)
constroem o website seguindo as especificações. E já que “nenhum arquiteto consegue
antecipar tudo” eles advertem que dúvidas e problemas surgem durante o trabalho desses
profissionais e o arquiteto precisa solucioná-los. Porém se as fases anteriores foram
19
CASE é a abreviação de Computer-Aided Software Engineering ou Engenharia de Software auxiliada por
Computador. Essa denominação é utilizada para os programas de computador que engenheiros e analistas de
sistemas utilizam na modelagem de softwares.
Investigação teórica das metodologias de projetos de arquitetura de informação de websites
151
cumpridas corretamente, se os conceitos e as especificações foram bastante discutidos e
validados, não deverão surgir grandes problemas. Nenhuma técnica ou ferramenta é citada
por esses autores para essa fase.
Na metodologia de BUSTAMANTE (2004), a fase de Produção e Implementação
(Producción y Implementación) corresponde a fase de Implementação do quadro de
referência (Figura 7). Esse autor também dedica pouca atenção a essa fase, apenas cita que
seu êxito depende da qualidade das fases anteriores e que deve se prestar atenção aos
prazos, tempos de execução e ao cumprimento das especificações elaboradas. Ele também
não sugere nenhuma técnica ou ferramenta para essa fase.
Na metodologia da SAPIENT (apud MORROGH, 2003) a fase de Implementação
é dividida em duas fases, como aponta a Figura 7. A primeira fase, Validar e testar o
design (Validate and test the design), trata do acompanhamento da construção do website
propriamente dito, na qual o papel do arquiteto de informação é resolver conflitos, fazer
ajustes no design, atualizar a documentação, participar dos testes funcionais do website e
controlar a qualidade do projeto.
A segunda fase, Transferir Conhecimento (Transfer knowledge), é destinada a
difundir o conhecimento adquirido com o projeto. De um lado transfere-se o
conhecimento do arquiteto de informação aos profissionais que irão cuidar da
administração do website e das suas manutenções futuras. Do outro lado é elaborado um
estudo de caso do projeto, onde são incorporados os feedbacks de métricas de acesso, dos
clientes e dos usuários para registrar o conhecimento e passá-lo a outros arquitetos de
informação, que os aplicarão em novos projetos.
Apesar da pouca atenção dedicada pelos autores, o que se observa é que a função
do arquiteto de informação na fase de Implementação é acompanhar o trabalho de
construção do website para verificar se as suas especificações foram devidamente
seguidas. Nesse acompanhamento podem surgir dúvidas sobre os documentos que
precisam ser explicadas. Também podem surgir alterações em detalhes da especificação
que não se mostraram viáveis de implementação e por isso precisam ser modificadas. Se o
trabalho nas fases de Concepção e Especificação foi bem elaborado, é pequena a
Centrando a Arquitetura de Informação no usuário
152
probabilidade de surgirem mudanças nos conceitos definidos para o website e assim as
alterações serão pequenas e pontuais.
Não são citadas na literatura técnicas ou ferramentas para essa fase. Porém técnicas
de teste de software podem ser empregadas para validar se o website foi corretamente
implementado, especialmente as técnicas de testes funcionais
20
.
4.2.5 A fase de Avaliação
A fase de Avaliação em um projeto de arquitetura de informação, como visto
anteriormente, é importante para que o arquiteto aprenda com a experiência e melhore a
qualidade dos seus trabalhos futuros. Porém vários autores (REISS, 2000; DIJCK, 2003;
SAPIENT apud MORROGH, 2003; WODTKE, 2003) não dedicam quaisquer
comentários a essa fase.
ROSENFELD e MORVILLE (2002) fazem poucos comentários sobre a avaliação
de resultados. Na metodologia desse autores existe a fase de Administração
(Administration), que faz uma pequena menção sobre o tema. Nessa fase esses autores
sugerem a realização de análises sobre o website em produção através de testes com
usuários seguindo uma filosofia de melhoria contínua.
A SAPIENT (apud MORROGH, 2003) resume-se a citar que métricas de acesso ao
website e da aceitação do usuário são incluídas na documentação de encerramento do
projeto e passadas na fase transferência de conhecimento à outros arquitetos de
informação, porém não explica como são obtidas essas métricas. Não existe menção a uma
filosofia de melhoria contínua do website na metodologia da SAPIENT possivelmente
porque o trabalho dessa empresa termina com o lançamento do website.
20
Teste funcional é uma técnica de teste de software na qual é avaliada se todas as funcionalidades presentes
no software funcionam conforme o especificado, incluindo as regras de negócio (MOLINARI, 2003, pág.
161).
Investigação teórica das metodologias de projetos de arquitetura de informação de websites
153
BUSTAMANTE (2004) reserva a última fase da sua metodologia (Avaliações ou
Evaluaciones) para fase de Avaliação, na qual realiza a análise dos resultados do projeto.
Esse autor também reforça a importância dessas análises para melhorar continuamente a
organização do website e lhe dar um caráter dinâmico, que muda conforme as
necessidades dos usuários. Porém esse autor não cita técnicas para avaliar os resultados do
website.
SOUZA (2001) sugere uma técnica de mensuração de resultados de projetos de
webdesign que pode ser aplicada em projetos de arquitetura de informação. Nessa técnica
são criados indicadores a partir dos cenários de uso do website definidos na fase de
Concepção. Esses cenários retratam os objetivos do usuário e o caminho que percorrem
para alcançá-los, assim é mensurada a evolução dos usuários nas tarefas apontadas pelos
cenários e, através de testes de usabilidade, é analisado o impacto do design nessa
evolução
21
.
O método apresentado por SOUZA é bastante preciso, porém requer testes de
usabilidade quantitativos, com uma amostra de clientes suficientemente grande para gerar
indicadores estatisticamente confiáveis. Testes desse tipo costumam ter custo elevado
porque normalmente possuem um custo alto por entrevistado. Além disso, a técnica avalia
o design do website como um todo e não apenas a arquitetura de informação isoladamente.
A Arquitetura de Informação ainda precisa avançar nas técnicas de mensuração dos
resultados de seu trabalho. Embora seja difícil encontrar tais indicadores, eles são
importantes para melhorar a eficácia dos trabalhos e justificar sua importância.
O Information Architecture Institute (2003) possui uma iniciativa nessa área, na
qual está desenvolvendo um projeto para criar métricas para a arquitetura de informação
de um website através de questionários para medição da satisfação do usuário. Trata-se de
21
Um indicador comum para medir essa evolução do usuário nas tarefas apontadas nos cenários são os click-
throw ou taxas de conversão. Esse indicador mede o percentual dos usuários que acessaram uma
determinada página que seguiram para a página seguinte do cenário (SOUZA, 2001).
Centrando a Arquitetura de Informação no usuário
154
uma técnica semelhante aos questionários já existentes para mensurar a satisfação com a
usabilidade
22
.
Esses questionários possuem como ponto positivo o fato de apresentarem uma
medição quantitativa da usabilidade. Porém eles não apontam soluções para os problemas
e se baseiam apenas na satisfação dos usuários e não na observação de como
desempenharam as tarefas, o que pode trazer um componente subjetivo à análise.
Independente disso, um questionário como esse será um importante instrumento para
avaliar os resultados dos projetos de arquitetura de informação.
4.3 Síntese
Desenvolver uma metodologia eficiente para os projetos de arquitetura de
informação é imperativo para orientar e organizar o trabalho dos arquitetos, para reduzir o
caráter indutivo dos seus métodos e para a evolução desse novo campo. Porém a literatura
sobre metodologias de projetos de arquitetura de informação ainda é escassa. São poucos
os autores que se dedicam a esse trabalho e sugerem metodologias com todas as fases
necessárias a um projeto dessa natureza.
Foi possível observar nas sugestões de metodologias que todas podem ser
caracterizadas como processos de design porque todas apresentam as quatro fases
características desse tipo de processo: Pesquisa, Concepção, Especificação e
Implementação. Embora o autores dessas metodologias dedicam mais atenção as três
primeiras fases e fazem poucos comentários sobre a fase de Implementação.
Outro ponto carente nas metodologias analisadas é a fase de Avaliação. É possível
observar em algumas propostas a existência dessa fase, onde são sugeridas técnicas
oriundas da Usabilidade para mensurar os resultados dos projetos. Mas os autores dedicam
22
Alguns exemplos de questionários utilizados para medir a satisfação do usuário com a usabilidade de uma
interface computacional são o SUMI - Software Usability Measurement Inventory
(www.ucc.ie/hfrg/questionnaires/sumi/whatis.html), o WAMMI - Website Analysis and Measurement
Inventory (www.wammi.com/whatis.html) e o QUIS - Questionnaire for User Interaction Satisfaction
(http://www.lap.umd.edu/QUIS/).
Investigação teórica das metodologias de projetos de arquitetura de informação de websites
155
pouca atenção a essa fase como um todo e não apontam adaptações dessas técnicas para
mensurar atributos próprios da Arquitetura de Informação.
Outro ponto comum nas metodologias propostas é a influência da abordagem do
Design Centrado no Usuário da Interação Humano-Computador na Arquitetura de
Informação. O ciclo interativo e iterativo sugerido nessa abordagem está presente nas
metodologias assim como o emprego de técnicas de avaliação de usabilidade. Com certeza
a influência dessa abordagem melhora a qualidade dos projetos de arquitetura de
informação produzindo websites mais fáceis de usar.
Nota-se porém que a abordagem de Design Centrado no Usuário da Ciência da
Informação têm pouca influência nas metodologias de projetos sugeridas. Com exceção de
BUSTAMANTE (2004) nenhum outro autor emprega técnicas dessa abordagem nas suas
metodologias. A ausência desse tipo de abordagem leva a um conhecimento superficial
das necessidades de informação dos usuários e, consequentemente, a websites que não as
atendam completamente.
Centrando a Arquitetura de Informação no usuário
156
Investigação empírica das metodologias de projetos de arquitetura de informação de websites
157
Capítulo 5
Investigação empírica
da metodologia de projetos
de arquitetura de informação
de websites
Duas pesquisas de campo foram realizadas para elaborar a investigação empírica
das metodologias de projetos de arquitetura de informação como foi apresentado no
capítulo de introdução desse trabalho. Os resultados dessas duas pesquisas estão
apresentados a seguir.
5.1 Resultado do levantamento do perfil do arquiteto de informação
das listas de discussão brasileiras
A pesquisa para levantamento do perfil do arquiteto de informação brasileiro foi
realizada entre os dias 27 de abril e 19 de maio de 2006, seguindo a metodologia descrita
no capítulo 1. Foram obtidas 93 respostas, sendo que 91 foram consideradas válidas
porque dois entrevistados cuja naturalidade não era a brasileira foram descartados.
Centrando a Arquitetura de Informação no usuário
158
A maioria das respostas (54%) foram de membros da lista de discussão AIfIA-pt.
Não foi possível mensurar a quantidade de respostas que vieram das outras listas de
discussão porque elas não informam o endereço de e-mail dos seus participantes, que foi
utilizado para identificar univocamente os entrevistados.
5.1.1 Interesse em Arquitetura de Informação
O Gráfico 2 apresenta a distribuição das respostas à pergunta sobre o interesse do
entrevistado pela Arquitetura de Informação. Observa-se que é elevado o número de
pessoas interessadas em pesquisar esse campo (67% dos entrevistados), sendo que 26% de
todos os entrevistados não atuam como profissionais desenvolvendo projetos de
arquitetura de informação de websites.
Entre os entrevistados, 67 declararam que atuam como profissionais no
desenvolvimento de projetos de arquitetura de informação de websites. Esse grupo foi
denominado “profissionais” e, por serem o foco da pesquisa, a investigação sobre ele foi
mais aprofundada.
Entre os profissionais, mais da metade (55%) declarou ter também interesse em
pesquisar o campo da Arquitetura de Informação.
Gráfico 2 - Interesse dos entrevistados sobre Arquitetura de Informação
Apenas
Pesquisa
24
26%
Apenas
Profissional
30
33%
Pesquisa e
Profissional
37
41%
Investigação empírica das metodologias de projetos de arquitetura de informação de websites
159
5.1.2 Perfil Demográfico
Os homens predominam entre os profissionais de Arquitetura de Informação (57%
dos profissionais). As mulheres apresentam menos interesse em pesquisa que os homens
(74% dos entrevistados com interesse em pesquisa são homens). O Gráfico 3 apresenta a
distribuição dos entrevistados por sexo.
Gráfico 3 – Distribuição dos entrevistados por sexo e interesse
0%
20%
40%
60%
80%
100%
Feminino
35 29 16 10 19 6
Masculino
56 38 45 27 11 18
Total
entrevistados
Profissional Pesquisa
Pesquisa e
Profissional
Apenas
Profissional
Apenas
Pesquisa
Os profissionais são na sua maioria jovens, com idade média de 29 anos. Os
homens e as mulheres têm idade média muito próxima, com apenas 1 ano de diferença
(29 anos para as mulheres e 30 anos para os homens). A maioria das mulheres está
concentrada na faixa de 26-30 anos (62%), enquanto a maioria dos homens está distribuída
numa faixa maior, de 21 a 35 anos (79%). O Gráfico 4 apresenta a distribuição dos
entrevistados por faixa etária.
Gráfico 4 - Distribuição dos profissionais por sexo e faixa de idade
0
5
10
15
20
25
30
Feminino
5 18 4 2
Masculino
1 11 10 9 3 4
até 20 anos 21 a 25 anos 26 a 30 anos 31 a 35 anos 36 a 40 anos 41 a 45 anos
Centrando a Arquitetura de Informação no usuário
160
A maioria dos profissionais são solteiros (53% dos profissionais), porém essa
distribuição não se mantém em relação ao sexo. Entre os homens a predominância é de
solteiros (60% dos profissionais do sexo masculino), já entre as mulheres predominam as
casadas (59% das profissionais do sexo feminino). O Gráfico 5 mostra a distribuição dos
entrevistados por sexo e estado civil.
Gráfico 5 – Distribuição dos entrevistados por sexo e estado civil
0%
20%
40%
60%
80%
100%
Divorciado
1
Casado
14 17
Solteiro
23 12
Masculino Feminino
A maioria dos profissionais reside nos estados de São Paulo (46% dos
profissionais) e Rio de Janeiro (22% dos profissionais), os maiores centros econômicos do
país. Cerca de 21% dos profissionais são migrantes, sendo que a maioria dos migrantes
são mulheres (71% dos migrantes). São Paulo é o estado que recebeu a maior parte desses
migrantes (50% dos migrantes). Os profissionais residem em sua maioria nas capitais
(78% dos profissionais) e são naturais de capitais (71% dos profissionais). A Tabela 6
mostra a quantidade de profissionais por estado e cidade.
Tabela 6 - Distribuição dos profissionais por estado e cidade de naturalidade e residência
Naturalidade
Residência
São Paulo
Rio de Janeiro
Distrito Federal
Minas Gerais
Rio Grande do Sul
Paraná
Pernambuco
Bahia
Fora do Brasil
Total
Naturalidade
Residência
São Paulo
Rio de Janeiro
Distrito Federal
Minas Gerais
Rio Grande do Sul
Paraná
Pernambuco
Bahia
Total
Naturalida
de
Residência
São Paulo
Rio de Janeiro
Distrito Federal
Minas Gerais
Rio Grande do Sul
Fora do Brasil
Total
24 1 1
26
11
11
13 1 1
15
3 12 1
16
10 1
11
3 2
5
2 6
8
1 4
5
1 2
3
1 1 4
6
2
2
1 1 2
4
1 2
3
1
2
3
1
1
2
2
2
2
1
1
1 2
3
2
2
18
5
2
2
1
1
29
1 1
2
1
1
5
3
0
0
1
1
10
1
1
1
1
31
15
7
4
3
3
2
1
1
67
13
10
5
2
2
3
2
1
38
7
3
1
0
1
1
0
0
1
14
2
0
1
0
0
1
0
0
4
Profissionais - Estado Profissionais - Feminino - EstadoProfissionais - Masculino - Estado
São Paulo
Rio de Janeiro
Distrito Federal
Minas Gerais
Rio Grande do Sul
Total
Migrantes
Paraná
Pernambuco
Bahia
Espírito Santo
São Paulo
Rio de Janeiro
Distrito Federal
Minas Gerais
Bahia
Pernambuco
Total
Rio Grande do Sul
Paraná
Pernambuco
São Paulo
Rio de Janeiro
Distrito Federal
Minas Gerais
Migrantes
Espírito Santo
Total
Migrantes
Bahia
Investigação empírica das metodologias de projetos de arquitetura de informação de websites
161
Profissonal
Residência - Cidade
Masculino Feminino Total
Profissional
Naturalidade - Cidade
Masculino Feminino Total
São Paulo (capital) 8 16 24 São Paulo (capital) 6 13 19
Rio de Janeiro (capital) 8 4 12 Rio de Janeiro (capital) 9 2 11
Brasília (capital) 5 2 7 Brasília (capital) 5 3 8
Belo Horizonte (capital) 2 2 4 Belo Horizonte (capital) 2 4 6
Campinas 1 1 2 Niterói 2 1 3
Recife (capital) 2 2 Santo André 1 1 2
Niterói 2 2 Salvador (capital) 1 1 2
Jandira 1 1 Recife (capital) 2 2
Londrina 1 1 Guarulhos 2 2
Maricá 1 1 Vitória 1 1
Guarulhos 1 1 Bauru 1 1
Novo Hamburgo 1 1 Nova Friburgo 1 1
Porto Alegre (capital) 1 1 Pelotas 1 1
Curitiba (capital) 1 1 Petrolina 1 1
Cascavel 1 1 Londrina 1 1
Salvador (capital) 1 1 Ribeirão Preto 1 1
Santa Cruz do Sul 1 1 Assis Chateaubriand 1 1
Santo André 1 1 Duque de Caxias 1 1
São Bernardo do Campo 1 1 Santa Maria 1 1
Bauru 1 1 Campinas 1 1
Fora do Brasil - EUA
1
1
Arroio do Tigre
1
1
Total
38
29
67
Total
38
29
67
5.1.3 Escolaridade
Os profissionais apresentam grau de instrução superior (75% possuem graduação
completa ou mais e 40% já realizou ou está realizando algum curso de pós-graduação, seja
uma especialização ou mestrado). As mulheres possuem um grau de instrução superior aos
homens (93% das mulheres possuem graduação completa ou mais, contra 61% dos
homens). O Gráfico 6 apresenta a distribuição dos profissionais pelo grau de instrução.
Gráfico 6 - Grau de instrução dos entrevistados
0
5
10
15
20
25
Feminino
1 1 16 2 6 1 2
Masculino
4 11 7 5 6 3 2
2º grau
completo
Graduação
incompleto
Graduação
completo
Especialização
incompleto
Especialização
completo
Mestrado
incompleto
Mestrado
completo
Centrando a Arquitetura de Informação no usuário
162
Apesar de terem um grau de instrução maior, as mulheres têm menos interesse em
pesquisa que os homens, como visto no Gráfico 3.
A maioria dos profissionais com curso de graduação tem formação na área de
humanas (85% dos profissionais com graduação incompleta, completa ou mais),
especialmente nos cursos de jornalismo (21%), desenho industrial (18%) e publicidade e
propaganda (18%). Entre os profissionais com formação na área de exatas, a maioria fez
cursos relacionados com computação (78% dos profissionais com formação na área de
exatas). O Gráfico 7 e a Tabela 7 detalham os cursos e as áreas de formação dos
profissionais.
Gráfico 7 - Área de formação dos profissionais
0%
20%
40%
60%
80%
100%
Exatas
9 4 0
Humanas
53 22 8
Graduação Especialização Mestrado
Investigação empírica das metodologias de projetos de arquitetura de informação de websites
163
Tabela 7 - Cursos de graduação, especialização e mestrado dos profissionais
Área de formação
1
Curso
2
Total %
Humanas jornalismo 13 21%
desenho industrial 11 18%
publicidade e propaganda 11 18%
comunicacao 4 6%
biblioteconomia 3 5%
design digital (mídia digital e interafaces gráficas)
3
5%
arquitetura 2 3%
administracao e comercio exterior
1
2%
arquivologia 1 2%
desenho de moda 1 2%
educacao artistica 1 2%
letras - lingua portuguesa e literatura 1 2%
web design com enfase em comercio eletronico 1 2%
Exatas engenharia civil 2 3%
sistemas de informacao 2 3%
ciencia da computacao 1 2%
matematica 1 2%
processamento de dados 1 2%
tecnologo em websites 1 2%
Biológicas ciencias moleculares 1 2%
62 100%
Área de formação
1
Curso
2
Total %
Humanas design de interfaces 3 12%
marketing digital 3 12%
mba em marketing 3 12%
design grafico 2 8%
comercio eletronico 1 4%
design da informacao 1 4%
didatica e metodologia de ensino 1 4%
ergodesign e avaliacao de interfaces
1
4%
gestao de marcas 1 4%
gestao do design 1 4%
gestao estrategica da informacao 1 4%
gestao estrategica e qualidade 1 4%
jornalismo e praticas contemporaneas
1
4%
jornalismo multimidia 1 4%
mbkm - gestao do conhecimento e inteligencia empresarial
1
4%
Exatas analise de sistemas 2 8%
informatica aplicada 1 4%
tecnologias da informacao e recuperacao da informacao 1 4%
26 100%
Área de formação
1
Curso
2
Total %
Humanas
administracao com enfase em marketing
1
13%
comunicacao e cultura midiatica
1
13%
desenho industrial 1 13%
design 1 13%
gestao da informacao e da comunicacao em saude
1
13%
gestao do conhecimento e tecnologia da informacao
1
13%
mestrado em administracao 1 13%
tecnologia & sociedade 1 13%
8 100%
Total
Total
Especialização - Profissionais
Mestrado - Profissionais
1- A classificação dos cursos em áreas de formação não foi perguntada ao entrevistado, ela foi feita com base na
classificação de cursos em áreas adotada pela FUVEST (2006).
2- Informado em questão aberta.
Graduação - Profissionais
Total
Centrando a Arquitetura de Informação no usuário
164
Com relação aos cursos de pós-graduação, a área de humanas é maioria (85% dos
profissionais com especialização e 100% dos profissionais com mestrado). Nota-se
também que os profissionais buscam cursos de pós-graduação na mesma área de seus
cursos de graduação. A maioria dos profissionais com curso de especialização na área de
humanas também fez curso de graduação na área de humanas (95% dos profissionais com
curso de especialização na área de humanas), e a maioria dos profissionais com curso de
mestrado na área de humanas também fez graduação na área de humanas (88% dos
profissionais com mestrado na área de humanas). O Gráfico 8 mostra a relação entre os
cursos de graduação e pós-graduação dos profissionais.
Gráfico 8 - Área de formação dos profissionais: Graduação x Pós-Graduação
0%
20%
40%
60%
80%
100%
Graduação em Exatas
1 2 1
Graduação em Humanas
21 2 7
Especialização
Humanas
Especialização
Exatas
Mestrado Humanas
A diversidade de cursos de graduação entre os profissionais mostra que diferentes
disciplinas encontram eco na Arquitetura de Informação, comprovando o seu caráter
multi-disciplinar citado no capítulo 3. Porém cada profissional individualmente busca se
especializar na mesma área de conhecimento do seu curso de graduação, fazendo com que
ele próprio não tenham uma formação multi-disciplinar.
A formação dos profissionais é muito pulverizada entre as instituições de ensino no
Brasil. Nenhuma delas formou um número significativo de profissionais, como mostra a
Tabela 8.
Investigação empírica das metodologias de projetos de arquitetura de informação de websites
165
Tabela 8 - Instituições de ensino citadas pelos profissionais
Graduação
Especialização
Mestrado
Total
UNIVERSIDADE DE BRASILIA 6 6
MACKENZIE 3 1 4
UFRJ 3 1 4
ESPM 1 2 3
FACHA (FACULDADES INTEGRADAS HÉLIO ALONSO) 3 3
PUC-SP 2 1 3
UNICARIOCA 3 3
UNIVERSIDADE NORTE DO PARANA 1 1 1 3
ESCOLA DE DESIGN - UEMG 2 2
ESCOLA SUPERIOR DE DESENHO INDUSTRIAL / UERJ 1 1 2
FAAP 2 2
FACULDADE CASPER LIBERO 2 2
PUC-RJ 1 1 2
UFPE 1 1 2
UNI-BH 1 1 2
UNIP 1 1 2
UNISC - UNIVERSIDADE DE SANTA CRUZ DO SUL 1 1 2
UNIVERSIDADE ANHEMBI MORUMBI 2 2
USP 2 2
BELAS ARTES 1 1
CEFET -MG 1 1
CENTRO DE ENSINO UNIFICADO DE BRASILA 1 1
CENTRO UNIVERSITARIO BENNETT 1 1
CENTRO UNIVERSITARIO DO TRIANGULO (MG) 1 1
ECA/USP 1 1
EM SELECAO 1 1
ESAD/CEFET-RJ 1 1
ESCOLA DE CIENCIA DA INFORMACAO - UFMG 1 1
ESCOLA DE ENGENHARIA KENNEDY 1 1
ESCOLA NACIONAL DE SAUDE PUBLICA (ENSP/FIOCRUZ) 1 1
FACULDADE BRASILIA 1 1
FACULDADE DA CIDADE 1 1
FACULDADE IMPACTA DE TECNOLOGIA 1 1
FACULDADE MARISTA DO RECIFE 1 1
FACULDADE SANTA MARCELINA 1 1
FACULDADES OSWALDO CRUZ 1 1
FASP 1 1
FECAP 1 1
FTC - FACULDADE DE TECNOLOGIA E CIENCIAS 1 1
I-GROUP 1 1
I-GROUP, FECAP E EDUCARTS 1 1
METODISTA 1 1
POLI/USP 1 1
PONTOIFICIA UNIVERSIDADE CATOLICA DE MINAS GERAIS 1 1
SENAC COMUNICACAO E ARTES 1 1
UCPEL 1 1
UEL 1 1
UFES 1 1
UFPR 1 1
UNA - CIENCIAS GERENCIAIS 1 1
UNIABC 1 1
UNICAMP 1 1
UNIRONDON 1 1
UNIVERSIDADE CANDIDO MENDES (UCAM) 1 1
UNIVERSIDADE CATOLICA DE BRASILIA 1 1
UNIVERSIDADE DE BRASILIA E UNIVERSIDADE CATOLICA DE BRASILIA 1 1
UNIVERSIDADE FEDERAL DE MINAS GERAIS 1 1
UNIVERSIDADE FEDERAL FLUMINENSE (UFF) 1 1
UNIVERSIDADE GAMA FILHO 1 1
UNIVERSIDADE SANTA URSULA 1 1
UNIVERSIDADE SAO JUDAS TADEU 1 1
UNIVERSIDADE SAO MARCOS 1 1
UNOPAR 1 1
UTFPR
1
1
Total
62
26
8
96
Instituição de Ensino - Profissionais
1
Qtd de Profissionais
1- Informado em questão aberta.
Centrando a Arquitetura de Informação no usuário
166
Vale notar que é baixo o interesse das instituições de ensino brasileiras sobre a
Arquitetura de Informação. No diretório dos grupos de pesquisa no Brasil (CNPQ 2006)
foi encontrada apenas uma instituição acadêmica com linha de pesquisa sobre Arquitetura
de Informação. Trata-se do departamento de Ciências da Informação e Documentação da
Universidade de Brasília, que lançou em 2006 uma linha de pesquisa sobre o tema.
5.1.4 Aprendizado de Arquitetura de Informação
A maioria dos profissionais mencionou que desenvolveu seus conhecimentos sobre
Arquitetura de Informação de forma autodidata (58% dos profissionais). Até os que
responderam que desenvolveram seus conhecimentos de outras formas, diferentes das
apresentadas na questão fechada, citaram, na maioria, a forma autodidata. Entre os
profissionais que responderam que realizaram cursos sobre Arquitetura de Informação
(10% dos profissionais), não houve nenhum curso que se destacou (nenhum dos cursos
apresentou mais que duas respostas).
Esse número elevado de formação autodidata justifica o grande interesse dos
profissionais em pesquisar o campo da Arquitetura de Informação, como foi visto no
Gráfico 2. Porém aponta uma carência de cursos sobre o tema no Brasil, o que pode
acarretar uma má formação dos profissionais.
O Gráfico 9 e a Tabela 9 detalham as formas com que os Arquitetos de Informação
adquiriram seus conhecimentos.
Gráfico 9 - Formas como os profissionais desenvolveram seus conhecimentos sobre Arquitetura de Informação
Outro
7
10%
Fiz curso
sobre o
tema
7
10%
Aprendi da
empresa
15
22%
Autodidata
38
58%
Investigação empírica das metodologias de projetos de arquitetura de informação de websites
167
Tabela 9 - Outras formas como os profissionais desenvolveram seus conhecimentos
Qtd %
Autodidata 6 38%
Aprendi da empresa 3 19%
Fiz curso sobre o tema 3 19%
Graduação 3 19%
Especialização na PUC 1 6%
Total
16
100%
1- Classificação feita com base nas respostas da
questão aberta.
Citações
Profissional - Desenvolveu
conhecimento - Outro - Qual
1
5.1.5 Grau de experiência
Os profissionais possuem em média 7 anos de experiência de trabalho com Internet
e 4 anos de experiência com Arquitetura de Informação, comprovando o quão recente é
esse campo. A maior parte dos profissionais (40%) tem até 2 anos de experiência com
Arquitetura de Informação, o que mostra que a procura por esse novo campo vem
crescendo. O Gráfico 10 mostra a distribuição dos profissionais pelos anos de trabalho
com Internet e o Gráfico 11 mostra a distribuição dos profissionais pelos anos de trabalho
com Arquitetura de Informação.
Gráfico 10 - Distribuição dos profissionais pelos anos de trabalho com Internet
0
5
10
15
20
25
Qtd profissionais
1 9 18 14 21 2 2
até 2
anos
3 a 4
anos
5 a 6
anos
7 a 8
anos
9 a 10
anos
11 a 12
anos
13 anos
ou mais
Centrando a Arquitetura de Informação no usuário
168
Gráfico 11 - Distribuição dos profissionais pelos anos de trabalho com Arquitetura de Informação
0
5
10
15
20
25
30
Qtd profissionais
27 19 16 2 3
até 2 anos 3 a 4 anos 5 a 6 anos 7 a 8 anos
9 anos ou
mais
Mais da metade dos profissionais (55%) dedica até 50% do seu tempo de trabalho
para a Arquitetura de Informação, demonstrando que esses profissionais compartilham
outras funções. O Gráfico 12 apresenta a distribuição dos profissionais pela porcentagem
do tempo de trabalho dedicada à Arquitetura de Informação.
Gráfico 12 - Porcentagem do tempo de trabalho dedicado à Arquitetura de Informação
26% a 50% de
dedicação; 18;
27%
51% a 75% de
dedicação; 16;
24%
76% a 100% de
dedicação; 14;
21%
0 a 25% de
dedicação; 19;
28%
5.1.6 Empresas, cargos e forma de contratação
Com relação ao tipo de empresa onde trabalham, é maior a concentração de
profissionais que trabalham em agências que desenvolvem websites (46% dos
profissionais). Porém existe uma quantidade grande de profissionais que trabalham em
empresas cuja atividade principal não está diretamente relacionada com a Internet (Outros
– 34% dos profissionais). Provavelmente esses profissionais atuam na área responsável
Investigação empírica das metodologias de projetos de arquitetura de informação de websites
169
pelos websites dessas empresas. A Tabela 10 detalha a distribuição dos profissionais por
tipo de empresa.
Tabela 10 - Distribuição dos profissionais por tipo de empresa
Tipo de Empresa
1
Total %
Agência desenvolvedora de websites 31 46%
Outro (bancos, orgãos governamentais, empresas
estatais, instituições de ensino, etc.)
23 34%
Desenvolvedora de Software 7 10%
Portal de conteúdo (Ex: UOL Terra, Globo.com) 4 6%
Provedor de acesso
2
3%
Total
67
100%
1- O tipo de empresa não foi perguntado diretamente ao entrevistado. O
website de cada empresa foi visitado para identificar o seu tipo por meio do
nome da empresa e da URL informada.
Mais da metade dos profissionais possui grande vínculo com as suas empresas
(CLT, Sócio da empresa e Funcionário público), como mostra a Tabela 11.
Tabela 11 - Tipo de empresa e forma de contratação dos profissionais
Forma de Contratação
Total
%
CLT 33 49%
Consultor 12 18%
Terceirizado 11 16%
Sócio da empresa 4 6%
Cooperativa 2 3%
Free-lance 2 3%
Funcionário público 2 3%
Estagiario
1
1%
Total
67
100%
A maioria dos profissionais não tem o termo "arquiteto de informação" no nome
dos seus cargos (tipo de cargo Outros corresponde a 67% do total). Entre os profissionais
que possuem o termo “Arquiteto de Informação” no nome dos seus cargos, a maioria
(86%) dedica mais de 50% do seu tempo de trabalho às atividades relacionadas com a
Arquitetura de Informação, sendo que metade deles tem dedicação integral (76% a 100%
de dedicação).
O Gráfico 13 mostra da distribuição dos profissionais pelo tipo de cargo e na
Tabela 12 são apresentados todos os nomes dos cargos citados pelos profissionais.
Centrando a Arquitetura de Informação no usuário
170
Gráfico 13 - Distribuição dos profissionais por tipo de cargo e tempo de dedicação a Arquitetura de Informação
Tipo de Cargo
Outro
45
67%
Arquiteto de
Informação
22
33%
Tipo de Cargo e Dedicação à Arquiteura de Informação - Profissionais
0%
20%
40%
60%
80%
100%
0 a 25% de dedicação
19 0 19
26% a 50% de dedicação
18 3 15
51% a 75% de dedicação
16 8 8
76% a 100% de dedicação
14 11 3
Total Arquiteto de Informação Outro
Tabela 12 - Nome dos cargos dos profissionais
0 a 25% 26% a 50% 51% a 75% 76% a 100%
Total
arquiteto de informacao 3 3 6
arquiteto de informacao e designer de interfaces 1 1
arquiteto de informacao e designer de userinterface 1 1
arquiteto de informacao junior 1 1
arquiteto de informacao pleno 1 2 3
arquiteto de informacao pleno com enfase em planejamento 1 1
arquiteto de informacao senior 1 1
coordenador de arquitetura de informacao e usabilidade 1 1
coordenadora de ai 1 1
coordenadora de arquitetura 1 1
estrategia & inovacao (arquiteto de informacao e novos negocios) 1 1
gerente da area de solucoes, inovacoes e arquitetura da informacao 1 1
gerente de arquitetura de informacao 1 1
gerente senior, arquitetura de informacao 1 1
web designer / ai 1 1
Total
3
8
11
22
analista de produto 1 1
analista de produtos pleno 1 1
analista de sistemas 1 1
analista web senior 1 1
bibliotecario e gestor de conteudo 1 1
ceo 1 1
concept designer 1 1
coordenador de informacao 1 1
coordenadora de criacao 1 1
coordenadora de projetos web 1 1
desenvolvedor / analista de data intelligence 1 1
designer 5 5
designer de interacao 1 1
designer de interface 2 2
designer digital 1 1
designer/socia 1 1
diretor 1 1
diretor de tecnologia 1 1
diretora de projetos interativos 1 1
diretora executiva 1 1
docente 1 1
editor 1 1 2
editor de arte - projetos especiais / webdesigner 1 1
gerente de atendimento 1 1
gerente de contas 1 1
gerente de conteudo 1 1
gerente de projetos 2 1 3
planejamento 1 1
produtor executivo ii 1 1
professor assistente iii 1 1
programador visual web 1 1
redator pleno 1 1
socia 1 1
webdesigner 3 1 4
Total
19
15
8
3
45
Total
19
18
16
14
67
Dedicação à Arquitetura de Informação
Cargo - Profissionais
2
Tipo de
Cargo
1
1- A classificação dos tipos de cargos foi feita verificando se algum termo semelhante a"arquiteto de informação" aparece no nome do
cargo
2- Informado em questão aberta.
Arquiteto
de Informação
Outro
Investigação empírica das metodologias de projetos de arquitetura de informação de websites
171
5.1.7 Atividades executadas
Gráfico 14 - Atividades de Arquitetura de Informação que os profissionais já fizeram
0%
20%
40%
60%
80%
100%
Não fez
2 7 15 27 27 33 37 50
Já fez
65 60 52 40 40 34 30 17
Mapa do
Site ou
Sitegrama
Wireframe
Inventário
de
Conteúdo
Análise
Heurística
Teste de
Usabilidad
e
Protótipo
de Papel
Card
Sorting
Outras
A atividade de Arquitetura de Informação mais executadas pelos profissionais é a
elaboração dos documentos de especificação dos websites (sitegrama e wireframe), como
mostra o Gráfico 14. De fato a produção desses documentos é uma prática proposta pela
maioria dos autores (REISS, 2000; SHIPLE, 2001; ROSENFELD e MORVILLE, 2002;
DIJCK, 2003; WODTKE, 2003).
A maioria dos profissionais pesquisados (60%) já fez algum tipo de avaliação de
usabilidade, seja na forma analítica, por meio da a análise heurística, ou na forma
empírica, utilizando os testes de usabilidade. Os testes de Card Sorting e Protótipos em
Papel são pouco realizados, como mostra o Gráfico 14. Nota-se assim, que apesar da
maioria dos profissionais já terem realizado avaliações de usabilidade na forma empírica,
as técnicas recomendadas para os projetos de arquitetura de informação ainda são pouco
difundidas.
Entre as outras atividades que os profissionais informaram na questão aberta, as
mais citadas são: a formulação de estratégias ou visões macro da arquitetura de
informação dos websites, a elaboração de fluxos de navegação e a construção de
taxonomias e vocabulários controlados, como mostra a Tabela 13.
Centrando a Arquitetura de Informação no usuário
172
Tabela 13 - Outras atividades relacionadas a Arquitetura de Informação citadas pelos profissionais
Outras Atividades - Quais
1
Qtd de citações %
Estratégia e visão macro da arquitetura de informação 5 10%
Fluxo de navegação 4 8%
Taxonomia / Vocabulário controlado 4 8%
Benchmark 3 6%
Protótipos digitais / htm 3 6%
Análise de Tarefas 2 4%
Levantamento de Requisitos 2 4%
Modelo mental 2 4%
Acompanhamento da elaboração de propostas visuais 1 2%
Acompanhamento de implementação 1 2%
Análise de Resultados 1 2%
Análise técnica 1 2%
Árvore de Informação 1 2%
Avaliação cooperativa 1 2%
Classificação da informação 1 2%
Descrição técnica de telas 1 2%
Diagrama de bolas 1 2%
Entrevista com usuários 1 2%
Focus group 1 2%
Guidelines 1 2%
Levantamento de Conteúdo 1 2%
Lista de funcionalidades 1 2%
Lista de telas 1 2%
Mapeamento de padrões 1 2%
Personas 1 2%
Pesquisa qualitativa 1 2%
Posicionamento de elementos 1 2%
Protótipos Dinâmicos 1 2%
User Interaction Modeling 1 2%
Validação de sites 1 2%
Workflow de processos
1
2%
Total
48
100%
1- Informado em questão aberta.
Todas as atividades citadas na questão aberta foram classificadas nas cinco fases
do quadro de referência formulado na investigação teórica: Pesquisa, Concepção,
Especificação, Implementação e Avaliação. Dessa classificação nota-se que a maioria das
atividades correspondem as três primeiras fases : Pesquisa (31% das atividades citadas),
Concepção (33% das atividades citadas) e Especificação (27% das atividades citadas). A
Tabela 14 mostra a classificação dessas atividades nas fases do quadro de referência.
Investigação empírica das metodologias de projetos de arquitetura de informação de websites
173
Tabela 14 – Classificação das outras atividades nas fases do quadro de referência
Fases da metodologia
1
Outras Atividades - Quais
2
Qtd de citações %
Benchmark 3 6%
Análise de Tarefas 2 4%
Levantamento de Requisitos 2 4%
Análise técnica 1 2%
Avaliação cooperativa 1 2%
Entrevista com usuários 1 2%
Focus group 1 2%
Levantamento de Conteúdo 1 2%
Lista de funcionalidades 1 2%
Mapeamento de padrões 1 2%
Pesquisa qualitativa 1 2%
Total
15
31%
Estratégia e visão macro da arquitetura de informação 5 10%
Protótipos digitais / htm 3 6%
Modelo mental 2 4%
Classificação da informação 1 2%
Diagrama de bolas 1 2%
Personas 1 2%
Protótipos Dinâmicos 1 2%
User Interaction Modeling 1 2%
Workflow de processos 1 2%
Total
16
33%
Fluxo de navegação 4 8%
Taxonomia / Vocabulário controlado 4 8%
Árvore de Informação 1 2%
Descrição técnica de telas 1 2%
Guidelines 1 2%
Lista de telas 1 2%
Posicionamento de elementos 1 2%
Total
13
27%
Acompanhamento da elaboração de propostas visuais 1 2%
Acompanhamento de implementação 1 2%
Validação de sites 1 2%
Total
3
6%
Análise de Resultados 1 2%
Total
1
2%
48
100%
1- A classificação das outras atividades nas fases da metodologia foi feita com base no quadro de referência
montado na investigação teórica.
2- Informado em questão aberta.
Avaliação
Total
Pesquisa
Concepção
Especificação
Implementação
A classificação dessas atividades nas fases do quadro de referência corrobora com
a investigação teórica, que mostrou pouca dedicação dos autores as fases de
Implementação e Avaliação. Em especial, a baixa citação de atividades relacionadas à fase
de Avaliação (2% das atividades citadas) confirma que os profissionais pesquisados não
têm o hábito de analisar os resultados do seu trabalho.
5.1.8 Existência de uma metodologia de projetos de arquitetura de informação
Embora não seja a maioria, é alto o número de profissionais que afirmam não
seguir uma metodologia em seus projetos de arquitetura de informação (45% dos
profissionais), como mostra o Gráfico 15.
Centrando a Arquitetura de Informação no usuário
174
Gráfico 15 - Quantidade de profissionais que seguem uma metodologia nos projetos de arquitetura de informação
Não
30
45%
Sim
37
55%
Todos os entrevistados que manifestaram seguir uma metodologia foram
convidados a discriminá-las em uma questão aberta, cujas respostas foram classificadas. A
contagem das citações aponta que, entre os profissionais que adotam alguma metodologia,
67% seguem uma metodologia própria, 22% seguem uma metodologia que foi possível
encontrar referências na literatura e 10% segue uma metodologia que não foi possível
identificar porque as respostas não mencionaram uma metodologia ou um conjunto de
atividades. O Gráfico 16 apresenta a distribuição das metodologias citadas pelos
profissionais.
Gráfico 16 - Metodologia adotada nos projetos de arquitetura de informação
Outros
5
14%
Rosenfeld e Morville
1
3%
John Shiple
1
3%
Zachman e Peter
Morville
1
3%
Jesse James Garrett
1
3%
Christina Wodtke
1
3%
Moebius
3
8%
Indefinida
4
10%
Própria
25
67%
Entre as metodologias que foram possíveis encontrar referências na literatura
Moebius e Jesse James Garret, não são específicas de Arquitetura de Informação. A
primeira, como visto no capítulo 4 é uma metodologia para o desenvolvimento do website
Investigação empírica das metodologias de projetos de arquitetura de informação de websites
175
como um todo. A segunda é uma metodologia voltada para o design da experiência do
usuário com o website, e se restringe as fases de Pesquisa, Concepção e Especificação.
As outras quatro, Christina Wodtke, John Shiple, Rosenfeld e Morville, Zachman e
Peter Morville, se referem a metodologias de projetos de arquitetura de informação. As
três primeiras foram citadas na investigação teórica e a última, Zachman e Peter Morville,
se refere a um processo desenvolvido por um dos entrevistados na sua dissertação de
mestrado que une o framework para o design do sistema de informação de empresas de
Zachman e orientações de Peter Morville.
Intriga a baixa citação de Rosenfeld e Morville entre as metodologias de projetos
de arquitetura de informação porque o livro desses autores é o que apresenta a
metodologia mais completa e é o mais citado na literatura. O fato desse livro ainda não ter
sido traduzido para a língua portuguesa pode ser um dos fatores que justifique essa baixa
citação. Isso também pode indicar que a formação autodidata dos profissionais não é
eficaz, uma vez que o livro mais citado na literatura está entre as metodologias menos
citadas pelos entrevistados.
Com relação aos entrevistados que seguem uma metodologia própria, é possível
que elas tenham sido elaboradas com base nos autores de Arquitetura de Informação vistos
na investigação teórica. Mas, pela suas respostas, não houve maneira de confirmar isso.
5.1.9 Síntese dos resultados encontrados
A pesquisa de levantamento do perfil do arquiteto de informação das listas de
discussão brasileira retrata um profissional jovem, que vive nos grandes centros
metropolitanos do país e ainda está descobrindo seu campo de trabalho. É um profissional
com instrução superior, formação predominante na área de humanas e que desenvolveu
seus conhecimentos sobre Arquitetura de Informação de maneira autodidata.
Esse profissional tem alto vínculo empregatício nas empresas onde trabalham, mas
acumula outras funções, o que não lhe permite dedicação integral a Arquitetura de
Informação.
Centrando a Arquitetura de Informação no usuário
176
Entre as atividades que desempenha, o profissional de Arquitetura de Informação
se concentra mais naquelas classificadas nas três primeiras fases do quadro de referência
visto na investigação teórica (Pesquisa, Concepção e Especificação), em especial na
elaboração dos documentos de especificação da Arquitetura de Informação (sitegrama,
wireframes, etc.). Poucos profissionais acompanham a implementação dos seus projetos e
fazem avaliação dos seus resultados.
Quase metade dos profissionais não segue qualquer metodologia em seus projetos.
Entre os que seguem, a maioria utiliza metodologias próprias desenvolvidas com base em
suas experiências e estudos autodidatas.
Apesar de terem sido encontrados profissionais de várias disciplinas atuando na
área de Arquitetura de Informação, esses profissionais não tem uma formação multi-
disciplinar. Sua formação é predominantemente na área de Humanas e que continua nos
cursos de pós-graduação.
5.2 Resultado do levantamento das dificuldades, técnicas e
metodologias encontradas nos projetos de arquitetura de
informação de websites
A pesquisa de levantamento das dificuldades, técnicas e metodologias encontradas
nos projetos de arquitetura de informação de websites foi realizada entre os dias 15 de
agosto e 4 de setembro de 2006. Foram entrevistados 5 profissionais experientes que
atuam em projetos de arquitetura de informação, selecionados entre que responderam ao
questionário on-line. Os critérios de seleção desses profissionais e a metodologia
empregada nessa pesquisa estão descritos na introdução desse trabalho.
Entre os participantes do levantamento do perfil do arquiteto de informação,
apenas 6 atenderam a todos os critérios de seleção para essa segunda pesquisa. Todos eles
foram convidados por telefone a participar da pesquisa e apenas um recusou o convite.
Assim, a amostra final conteve 5 entrevistados cujas características estão descritas na
Tabela 15.
Investigação empírica das metodologias de projetos de arquitetura de informação de websites
177
Tabela 15 - Características dos entrevistados
Características Entrevistado 1 Entrevistado 2 Entrevistado 3 Entrevistado 4 Entrevistado 5
Residência
São Paulo-SP São Paulo-SP São Paulo-SP Rio de Janeiro-RJ Rio de Janeiro-RJ
Anos que trabalha com
Arquitetura de
Informação
6 5 6 6 7
Porcentagem do tempo
de trabalho dedicada à
Arquitetura de
Informação
51% a 75% 51% a 75% 51% a 75% 76% a 100% 51% a 75%
Grau de Instrução
Graduação
completo
Graduação
completo
Graduação
completo
Graduação
completo
Especialização
completo
Formação acadêmica
- Jornalismo - Jornalismo - Sistemas de
Informação
- Jornalismo - Desenho
industrial
(graduação)
- Ergodesign e
Avaliação de
Interfaces
(especialização)
Tipo de empresa
Agência
desenvolvedora
de websites
Agência
desenvolvedora
de websites
Desenvolvedora
de Software
Portal de conteúdo Agência
desenvolvedora
de websites
Como desenvolveu
seus conhecimentos
sobre Arquitetura de
Informação
- Autodidata - Autodidata - Autodidata - Aprendi na
empresa
- Autodidata
- Curso de
especialização
As entrevistas foram realizadas individualmente com duração média de 90 minutos
e foram filmadas para posterior análise. O entrevistador também fez anotações durante a
entrevista.
A seguir são apresentados os resultados encontrados. Primeiro são apresentadas as
metodologias adotadas pelos entrevistados, levantadas na fase I e III do roteiro de
entrevista. Depois são analisadas as dificuldades enfrentadas pelos entrevistados,
levantadas na fase II do roteiro.
5.2.1 Análise da metodologia adotada pelos entrevistados
Todos os entrevistados declararam que adotam uma metodologia de projetos de
arquitetura de informação nas empresas onde trabalham, porém apenas três entrevistados
têm os procedimentos de suas metodologia documentados. Na empresa dos outros dois
entrevistados, a metodologia de projetos de arquitetura de informação está apenas no
conhecimento tácito dos funcionários. Os motivos apontados para a inexistência de
Centrando a Arquitetura de Informação no usuário
178
documentação da metodologia são a falta de formalismo da empresa e a falta de tempo
para elaborar essa documentação.
E também todos os entrevistados declararam que concordam com a seqüência das
atividades das suas metodologias. Os motivos para isso são: evoluíram a partir da
experiência, a metodologia começa com visão macro vai para a visão detalhada, permite
ao arquiteto desenvolver argumentos palpáveis ao longo do projeto e as atividades têm
dependência uma das outras.
Metodologias que evoluíram da experiência são mais assertivas porque tiveram um
tempo de maturação que permitiu ajustar e comprovar seus métodos e técnicas com a
prática.
As metodologias que começam com uma visão macro e se aprofundam em uma
visão detalhada permitem que o arquiteto tenha uma compreensão holística da arquitetura
de informação no início do projeto e depois a esmiúce em cada componente do website.
Isso se alinha com um dos princípios necessários para as metodologias de projetos de
arquitetura de informação apontados na investigação teórica: ser um processo de design.
Como visto, um processo de design possui uma fase de Concepção, na qual se define a
visão geral e macro do produto final (no caso o website). Em seguida vem uma fase de
Especificação, que detalha e documenta essa visão geral para que possa ser implementada.
Por fim, percebe-se que a concordância dos entrevistados com suas metodologias
também ocorre porque elas os ajudam a desenvolver argumentos palpáveis e racionais
para justificar seus projetos. Tais argumentos são importante para mitigar os problemas de
política interna e facilita a negociação do arquiteto com os demais envolvidos.
As atividades que os entrevistados sentem falta nas suas metodologias são: testes
de usabilidade, especialmente as técnicas mais recomendadas para projetos de arquitetura
de informação (Card Sorting e protótipos em papel); estudos de cenário; análise de
funções; wireframes adequados a páginas muito dinâmicas e interativas (por exemplo, as
Investigação empírica das metodologias de projetos de arquitetura de informação de websites
179
que utilizam tecnologia RIA
23
); otimização para mecanismos de busca; preocupação com
acessibilidade e preocupação com a ferramenta de publicação do website.
A ausência dos testes de usabilidade corrobora com os resultados do levantamento
do perfil do arquiteto de informação apresentado anteriormente, no qual 40% dos
entrevistados responderam que nunca executaram esse tipo de teste.
Os estudos de cenário e a análise de função são atividades características da fase de
Concepção. Assim, essa ausência indica essa fase não é executada completamente.
A falta de adequação dos wireframes a páginas mais dinâmicas e interativas mostra
que esse tipo de documento ainda não evoluiu para atender a novas tecnologias de
desenvolvimento de interfaces na Web.
A ausência de uma atividade de otimização das páginas do website para
mecanismos de busca aponta que o design do sistema de busca tem menos importância
que os outros três sistemas que compõem a arquitetura de informação (sistemas de
organização, de navegação e de rotulação). Como visto no capítulo 3, esse sistema tem
menor interdependência que os demais, o que permite fazer seu design separadamente.
Por fim, a preocupação do arquiteto com a publicação do website mostra que o
projeto de arquitetura de informação não se limita a conhecer e definir a interface do
usuário. Faz parte do projeto analisar o ambiente interno da empresa e projetar meios para
que ela consiga operar adequadamente o website. Esses são os requisitos operacionais que
o arquiteto de informação precisa levantar na fase de Pesquisa e atender com seu projeto,
como visto na investigação teórica.
Segundo os entrevistados, a maioria dos projetos que conduzem segue todas as
atividades das metodologias que apresentaram. As exceções são:
23
RIA, ou Rich Internet Application, é uma forma de utilização do Macromedia Flash, uma linguagem de
programação web que permite criar websites com interfaces mais interativas.
Centrando a Arquitetura de Informação no usuário
180
• Projetos pequenos: Nesses projetos algumas atividades são fundidas ou
eliminadas por não fazerem parte do escopo de trabalho.
• Projetos com solução conhecida: são projetos nos quais existem padrões
já definidos para a interface do website, o que elimina parte do trabalho
criativo das fases de Concepção e Especificação.
• Projetos que utilizam tecnologia Flash: Projetos com essa tecnologia
normalmente não possuem sistema de busca, assim as atividades
relacionadas ao design desse sistema são eliminadas.
• Restrição de prazo: nem sempre os projetos dispõem do prazo necessário
para que o arquiteto execute todas as atividades que julga necessário.
• Resistência do contratante: o contratante não concorda com alguma das
atividades e a elimina do projeto.
Nota-se com essas respostas que as metodologias de projetos de arquitetura de
informação precisam ser flexíveis para se adaptarem a projetos com escopo pequeno, e
precisam oferecer atalhos suprimindo atividades para economizar tempo. Porém suprimir
uma atividade pode comprometer a qualidade do website. Dessa forma é importante que a
equipe de projeto e especialmente o contratante avaliem bem os ganhos e perdas da
atividade antes de decidir por suprimi-la.
A Tabela 16 detalha as respostas dos entrevistados com relação as metodologias
que adotam em seus projetos de arquitetura de informação.
Investigação empírica das metodologias de projetos de arquitetura de informação de websites
181
Tabela 16- Adoção de metodologia nos projetos de arquitetura de informação pelos entrevistados
Categorias de análise Entrevistado 1 Entrevistado 2 Entrevistado 3 Entrevistado 4 Entrevistado 5
Adoção de uma
metodologia nos
projetos de arquitetura
de informação
Sim Sim Sim Sim Sim
Documentação dos
procedimentos
Sim Sim Sim Não Não
Motivos para a falta de
documentação dos
procedimentos
--- --- --- - Falta formalismo
na empresa
- Falta tempo para
elaborar a
documentação
Concordância com a
seqüência das
atividades da
metodologia
Sim Sim Sim Sim Sim
Motivos para concordar
com a sequencia das
atividades da
metodologia
- Atividades
dependem uma das
outras
- Metodologia
começa com visão
do macro e vai para
visão detalhada.
- Metodologia
começa com visão
do macro e vai para
visão detalhada
- Permite ao
arquiteto
desenvolver
argumentos
palpáveis e
racionais
- Evoluiu a partir da
experiência
- Evoluiu a partir da
experiência
Atividades ausentes na
metodologia
- Teste de
usabilidade
- Estudos de
cenário
- Card Sorting
- Paper Prototype
- Wireframes
adequados para
tecnologia RIA
- Paper Prototype - Otimização para
mecanismo de
busca
- Preocupação com
Acessibilidade
- Preocupação com
a ferramenta de
publicação do
website
- Análise das
funções
Quantidade de projetos
que seguem todas as
atividades da
metodologia
10% 100% 60% 100% 60%
Motivos para alguns
projetos não seguirem
todas as atividades da
metodologia
- Projetos
pequenos
- Projetos com
solução conhecida
- Projetos
pequenos
- Projetos em Flash
- Projetos
pequenos
- Projetos com
solução conhecida
- Projetos pequenos - Restrição de
prazo
- Resistência do
contratante
5.2.1.1 Análise das fases do quadro de referência na metodologia dos entrevistados
Na fase I da pesquisa, todos os entrevistados foram convidados a desenhar suas
metodologias utilizando cartões post-it para representar as atividades e a seqüência delas.
Na fase III, os entrevistados compararam suas metodologias com o quadro de referência
proposto na investigação teórica, identificando cada atividade nas fases desse quadro.
A seguir estão apresentados os desenhos das metodologias de cada entrevistado
com suas atividades identificadas nas cinco fases do quadro de referência.
Centrando a Arquitetura de Informação no usuário
182
Figura 9 - Metodologia de projetos de arquitetura de informação do entrevistado 1
Wireframe
Especifica as páginas do
website. Aponta quais são os
elementos de interface
contidos na página, como
funcionam e qual a hierarquia
entre eles. Realiza
análises heurísticas.
Wireframe
Especifica as páginas do
website. Aponta quais são os
elementos de interface
contidos na página, como
funcionam e qual a hierarquia
entre eles.Realiza análises
heurísticas nessa etapa.
Wireframe
Especifica as páginas do
website. Aponta quais são os
elementos de interface
contidos na página, como
funcionam e qual a hierarquia
entre eles.Realiza análises
heurísticas nessa etapa.
Wireframe
Especifica as páginas do
website. Aponta quais são os
elementos de interface
contidos na página, como
funcionam e qual a hierarquia
entre eles.Realiza análises
heurísticas nessa etapa.
Wireframe
Especifica as páginas do
website. Aponta quais são os
elementos de interface
contidos na página, como
funcionam e qual a hierarquia
entre eles.Realiza análises
heurísticas nessa etapa.
Fluxo de navegação
Desenha a navegação do
usuário pelas transações do
website. É feito apenas em
websites com transações
mais complicadas.
(Ex: comércio eletrônico)
Reunião de briefing
Reunião na qual o contratante
apresenta o problema a ser
resolvido, o contexto no qual
está inserido e as restrições
do projeto.
Define os labels
Define os rótulos que serão
utilizados no website.
Testes informais de
usabilidade
Avalia empiricamente da
usabilidade da solução com
outras pessoas da empresa.
Permeia todo o processo de
produção dos
wireframes.
Testes de usabilidade
Avalia empiricamente a
usabilidade com usuários.
São realizadas com protótipos
elaborados a partir do layout
do website. Realizado apenas
quando contratado.
Infograma
Elabora o sitegrama do
website, com a organização
hierárquica das páginas.
Também é chamado
internamente de infra-
estrutura.
P
C E
C E
E C E E
C E
Legenda
Fase de Pesquisa
Fase de Concepção
Fase de Especificação
Fase de Implementação
Fase de Avaliação
Não identificado em
nenhuma fase
Arquiteto de informação
não participa da atividade
Arquiteto de informação
participa da atividade
P
C
E
I
A
Investigação empírica das metodologias de projetos de arquitetura de informação de websites
183
Figura 10 - Metodologia de projetos de arquitetura de informação do entrevistado 2
Centrando a Arquitetura de Informação no usuário
184
Figura 11 - Metodologia de projetos de arquitetura de informação do entrevistado 3
Briefing
Reunião na qual o contratante
apresenta o problema a ser
resolvido, o contexto no qual
está inserido e as restrições
do projeto.
Wireframes (alguns)
Elabora os wireframes das
principais páginas e submete
à aprovação do contratante.
Wireframes (todos)
Elabora os wireframes das
demais páginas do website.
Aponta quais são os
elementos de interface
contidos na página, como
funcionam e qual a
hierarquia entre eles.
Briefing para
o diretor de arte
Arquiteto de informação e
diretor de arte (designer
gráfico) definem em conjunto
o projeto gráfico do website,
que será utilizado para
produzir os wireframes.
Benchmark
Analisa os principais websites
concorrentes e similares para
ter referências para o projeto
de arquitetura de informação.
Análise heurística
Avalia, de forma analítica, a
usabilidade do website atual
para identificar seus pontos
positivos e negativos.
Modelo mental
identifica o padrão de
posicionamento dos principais
elementos de interface nos
websites concorrentes.
Documento de análise
Consolida em um documento
todo o trabalho das atividades
anteriores e o apresenta ao
contratante.
Requisitos
Define o escopo do projeto e
as suas restrições.
P
CP
CP CP
CP
CP
E
E
Legenda
Fase de Pesquisa
Fase de Concepção
Fase de Especificação
Fase de Implementação
Fase de Avaliação
Não identificado em
nenhuma fase
Arquiteto de informação
não participa da atividade
Arquiteto de informação
participa da atividade
P
C
E
I
A
Investigação empírica das metodologias de projetos de arquitetura de informação de websites
185
Figura 12 - Metodologia de projetos de arquitetura de informação do entrevistado 4
Reunião de briefing
Reunião na qual o contratante
apresenta o problema a ser
resolvido, o contexto no qual
está inserido e as restrições
do projeto.
Benchmark
Analisa os principais websites
concorrentes e similares para
ter referências para o projeto
de arquitetura de informação.
Lista de funcionalidades
Lista macro das
funcionalidades do website.
Auxilia a estimar o tamanho
do projeto.
Detalhar
os fluxos de navegação
Desenha a navegação do
usuário pelas transações do
website. Também descreve
cada página na visão do
usuário.
Wireframes
Especifica as páginas do
website. Aponta quais são os
elementos de interface
contidos na página, como
funcionam e qual a hierarquia
entre eles.
Linha gráfica
Elabora um esboço do layout
gráfico do website para
facilitar a sua visualização.
Acompanhamento
do lançamento
Acompanha a produção e o
lançamento do website.
Normalmente realizam testes
de usabilidade antes
disponibilizar o website
para os usuários.
Acompanhamento pós-
lançamento
Avalia os resultados do
projeto e planeja a
implementação de novas
funcionalidades.
Macro-arquitetura
Elabora um sitegrama raso do
website. Tem a função de
ilustrar o escopo, as seções e
a estrutura do website.
Tirar dúvidas
O arquiteto de informação tira
as dúvidas dos demais
profissionais ao longo do
desenvolvimento do website e
faz ajustes quando
necessário..
P
I
P
C CC
E
EI
A
Legenda
Fase de Pesquisa
Fase de Concepção
Fase de Especificação
Fase de Implementação
Fase de Avaliação
Não identificado em
nenhuma fase
Arquiteto de informação
não participa da atividade
Arquiteto de informação
participa da atividade
P
C
E
I
A
Centrando a Arquitetura de Informação no usuário
186
Figura 13 - Metodologia de projetos de arquitetura de informação do entrevistado 5
Proposta comercial
Semelhante ao briefing, é
uma reunião na qual o
contratante apresenta o
problema a ser resolvido, o
contexto no qual está inserido
e as restrições
do projeto.
Proposta comercial
Negocia o prazo, o custo do
projeto e as técnicas de
Arquitetura de Informação e
Usabilidade que serão
aplicadas.
Realiza
a alternativa escolhida
Acompanha o trabalho de
programação do website.
Entendimento do cenário
Entende o contexto do projeto
e define as técnicas de
Arquitetura de Informação e
Usabilidade que serão
utilizadas.
Benchmark
Analisa os principais websites
concorrentes e similares para
ter referências para o projeto
de arquitetura de informação.
Desenvolve as alternativas
Desenvolve diferentes
cenários para implementar a
arquitetura de informação do
website.
Wireframes
Especifica as páginas do
website. Aponta quais são os
elementos de interface
contidos na página, como
funcionam e qual a hierarquia
entre eles.
Mapa informacional
Elabora o sitegrama do
website, com a organização
hierárquica das páginas.
C E
I
P
P
C E
C E
Legenda
Fase de Pesquisa
Fase de Concepção
Fase de Especificação
Fase de Implementação
Fase de Avaliação
Não identificado em
nenhuma fase
Arquiteto de informação
não participa da atividade
Arquiteto de informação
participa da atividade
P
C
E
I
A
P
Investigação empírica das metodologias de projetos de arquitetura de informação de websites
187
A seguir as metodologias dos entrevistados são analisadas segundo as fases do
quadro de referência.
5.2.1.1.1 Análise da fase de Pesquisa na metodologia dos entrevistados
Conforme o quadro de referência, a fase de Pesquisa na metodologia de projetos de
arquitetura de informação é destinada a pesquisar e compreender a empresa contratante e
os usuários do website. Nessa fase é definido o escopo e os requisitos do projeto.
Todos os entrevistados declararam que possuem uma fase de Pesquisa nas suas
metodologias de projeto de arquitetura de informação e identificaram atividades que
correspondem a essa fase. A maioria dos entrevistados inicia a fase de Pesquisa com uma
atividade chamada “Reunião de Briefing”, na qual o contratante apresenta o problema a
ser resolvido, o contexto no qual está inserido e as suas restrições. Após essa reunião, a
maioria dos entrevistados realiza uma atividade chamada “Benchmark”, que tem a função
de avaliar websites concorrentes e semelhantes.
Os entrevistados citaram que normalmente participam da fase de Pesquisa nos seus
projetos, que é realizada com trabalho em equipe envolvendo profissionais das áreas de
atendimento, criação, tecnologia da informação, projeto gráfico e gerência de produto.
Apenas o entrevistado 1 declarou que não participa dessa fase e se limita a compreender as
informações que os outros profissionais levantaram na reunião de briefing com o
contratante.
A principal variável pesquisada nessa fase, segundo os entrevistados, são as áreas
internas da empresa e suas necessidades. As outras variáveis são as empresas concorrentes
e o perfil do usuário.
Segundo os entrevistados, as técnicas de pesquisa mais utilizadas são o benchmark
com websites concorrentes e similares e as reuniões exploratórias (entrevistas) com os
funcionários da empresa contratante. Também foi citado o uso, nessa fase, da análise
heurística para diagnosticar os problemas no website do contratante e dos concorrentes.
Apenas o entrevistado 4 citou o uso de pesquisas de focus group com usuários para
Centrando a Arquitetura de Informação no usuário
188
levantar o perfil deles. No caso dos demais entrevistados a pesquisa do perfil do usuário é
realizada com relatórios internos e entrevistas com os funcionários da empresa contratante.
A principal fonte de informação nessa fase citada pelos entrevistados são os
funcionários que representam a empresa contratante. Outras fontes de informação são:
websites de empresas concorrentes ao contratante, o próprio website do contratante e os
usuários do website. Apenas o entrevistado 4 respondeu que nessa fase realiza pesquisas
diretas com usuários (focus group). Esse entrevistado desenvolve websites apenas para a
empresa onde trabalha, não possui uma empresa contratante externa.
Por fim, três dos entrevistados declararam que as informações obtidas na fase de
Pesquisa são superficiais, especialmente as que se referem aos usuários Dos dois
entrevistados que declararam que a qualidade das informações obtidas é adequada, um
deles, o entrevistado 4, faz pesquisas diretas com o usuário. O outro, o entrevistado 3, atua
predominantemente no desenvolvimento de websites para o mercado financeiro, que é
altamente competitivo e regulamentado. Por isso a pesquisa de benchmark lhe é uma
técnica bastante rica em informações.
O que se observa com as respostas dos entrevistados é que a abordagem de Design
Centrado no Usuário da Ciência da Informação, não são utilizadas na fase de Pesquisa,
confirmando a investigação teórica. Os entrevistados se concentram na análise da empresa
contratante e dos seus concorrentes, e não realizam pesquisas diretas com o usuário, indo
contra os princípios dessa abordagem. Isso pode justificar a qualidade superficial das
informações obtidas.
A Tabela 17 apresenta as respostas dos entrevistados sobre a fase de Pesquisa.
Investigação empírica das metodologias de projetos de arquitetura de informação de websites
189
Tabela 17 - Análise da fase de Pesquisa nas metodologias dos entrevistados
Categorias de análise Entrevistado 1 Entrevistado 2 Entrevistado 3 Entrevistado 4 Entrevistado 5
Existência da fase de
Pesquisa
Sim Sim Sim Sim Sim
Atividades na
metodologia que
correspondem a fase de
Pesquisa
- Reunião de
briefing
- Reunião briefing
- Planejamento da
presença on-line do
contratante
- Briefing
- Benchmark
- Análise Heurística
- Modelo Mental
- Requisitos
- Documento de
análise
- Reunião de
briefing
- Benchmark
- Levantamento das
necessidades
- Entendimento do
Cenário
- Benchmark
Profissionais que
participam da fase de
Pesquisa
- Gerente de
Atendimento
- Diretor de Criação
- Diretor de
Tecnologia da
Informação
- Gerente de
Atendimento
- Gerente de
Planejamento
- Arquiteto de
Informação
- Analista de
Sistema
- Arquiteto de
Informação
- Gerente de
Produto
- Analista de
sistema
- Designer Gráfico
- Arquiteto de
Informação
Participação do
Arquiteto de Informação
na fase de Pesquisa
Não participa Participa Participa Participa Participa
Variáveis pesquisadas
- Áreas internas da
empresa e suas
necessidades
- Perfil do usuário
- Áreas internas da
empresa e suas
necessidades
- Perfil do usuário
- Áreas internas da
empresa e suas
necessidades
- Concorrentes
- Concorrentes
- Perfil do usuário
- Áreas internas da
empresa e suas
necessidades
- Concorrentes
Técnicas empregadas
- Reunião
exploratória com os
representantes do
contratante
- Reunião
exploratória com os
representantes do
contratante
- Benchmark de
websites
concorrentes e
similares
- Análise Heurística
do website do
contratante
- Mapeamento do
posicionamento de
elementos de
interface em
websites
concorrentes e
similares
- Benchmark de
websites
concorrentes e
similares
- Focus Group
- Benchmark de
websites
concorrentes e
similares
- Reunião
exploratória com os
representantes do
contratante
Fontes de informação
- Funcionários do
contratante
- Funcionários do
contratante
- Funcionários do
contratante
- Concorrentes
- Website do
contratante
- Concorrentes - Funcionários do
contratante
- Concorrentes
- Website do
contratante
Realização de
pesquisas diretas com
o usuário
Não Não Não Sim Não
Qualidade das
informações obtidas na
fase de Pesquisa
Superficial Superficial Adequada Adequada Superficial
Centrando a Arquitetura de Informação no usuário
190
5.2.1.1.2 Análise da fase de Concepção na metodologia dos entrevistados
A fase de Concepção, como visto na investigação teórica, é a fase mais criativa da
metodologia. Nela são definidas as linhas gerais da solução e as regras dos sistemas de
organização, de navegação, de rotulação e de busca.
Todos os entrevistados declararam possuir uma fase de Concepção nas suas
metodologias de projetos de arquitetura de informação e apontaram as atividades que a
compõem. Não existe uma uniformidade nos nomes dessas atividades porque cada
entrevistado adota nomes diferentes, que normalmente correspondem aos nomes dos
documentos produzidos.
No caso específico do entrevistado 3, não foi possível identificar atividades
exclusivas da fase de Concepção, fazendo com que essa fase se misture com a fase de
Pesquisa na sua metodologia. Ao se misturar essas duas fases, o arquiteto de informação
pode conceber idéias que não atendem a todos os requisitos do projeto porque as concebeu
antes definir completa e detalhadamente o problema a ser resolvido. Para minimizar isso,
o entrevistado 3 possui uma atividade chamada “Documento de Analise”, na qual
consolida todo o trabalho das atividades anteriores e ajuda a encontrar inconsistências.
Diferente da fase de Pesquisa, todos os entrevistados declararam que participam da
fase de Concepção. Porém eles contam com a ajuda do profissionais das áreas de Projeto
Gráfico e Tecnologia da Informação, que contribuem com sugestões para o projeto e
validam se as idéias concebidas são factíveis de implementação
As técnicas utilizadas nessa fase citadas pelos entrevistados são: esboço do
sitegrama, esboço de conteúdo, diagrama de conteúdo, benchmark, análise heurística,
mapeamento do posicionamento de elementos de interface em websites concorrentes e
similares, levantamento das funcionalidades e esboço da linha gráfica.
O benchmark, o mapeamento do posicionamento dos elementos de interface e o
levantamento das funcionalidades não são técnicas destinadas à geração de idéias, objetivo
da fase de Concepção. São técnicas destinadas ao levantamento de informações,
Investigação empírica das metodologias de projetos de arquitetura de informação de websites
191
característico da fase de Pesquisa. Isso mostra que outros entrevistados também não
separam claramente essas duas fases nas suas metodologias.
Por fim, três dos cinco entrevistados declararam que documentam os conceitos
desenvolvidos nessa fase. Essa documentação serve para registrar os conceitos que
determinaram o modelo mental do website e as regras dos quatro sistemas que compõem a
arquitetura de informação com o intuito de perpetuá-los nas manutenções futuras.
BUSTAMANTE (2004) menciona a importância de documentar os conceitos definidos na
fase de Concepção para melhorar a comunicação e alinhar a equipe do projeto.
A realização de testes de usabilidade ao longo do projeto é um dos princípios do
Design Centrado no Usuário na abordagem da Interação Humano-Computador, como
visto na investigação teórica. Dessa forma essa pesquisa procurou a avaliar a freqüência
com que esses testes realizados.
Pelas respostas, são poucos os projetos onde são realizados testes de usabilidade. O
principal motivo citado é que os entrevistados não conseguem convencer seus contratantes
da importância desses testes. Os outros motivos para não realizar testes de usabilidade são:
falta de estrutura em suas empresas para executá-los e projetos de porte pequeno. Apenas
o entrevistado 4 declarou que possui na sua empresa uma estrutura própria para realizar
testes de usabilidade, contando inclusive com um laboratório específico para isso.
A realização de testes de usabilidade aumenta o custo e o prazo do projeto de
arquitetura de informação. Porém, como cita MARCUS (2002), a realização desses testes
reduz os custos e o prazo de desenvolvimento do website como um todo e também reduz
seus custos de manutenção e redesign. Porém os contratantes dos entrevistados ainda não
conhecem essas vantagens. Citando as palavras da Entrevistada 2, “as pessoas preferem
errar e consertar a testar antes de colocar no ar. É padrão oferecer os testes de usabilidade
e os clientes [contratantes] recusarem.”
As técnicas de testes de usabilidade mais indicadas para a Arquitetura de
Informação, o Card Sorting e os testes com protótipos em papel, são pouco utilizadas.
Alguns dos motivos para isso são semelhantes aos motivos para não realizar testes de
usabilidade: falta de prazo nos projetos e não conseguir convencer o contratante da sua
Centrando a Arquitetura de Informação no usuário
192
importância. Outros motivos são: falta de domínio das técnicas, falta de confiança na
técnica de protótipos em papel e não enxergar a necessidade de aplicar a técnica.
A falta de domínio das técnicas demonstra que elas ainda não estão completamente
difundidas entre os profissionais, indicando ineficiências na formação autodidata.
Já falta de confiança na técnica dos protótipos em papel, citada pelo entrevistado 4,
ocorre porque ele acredita que o usuário precisa ter uma capacidade de abstração muito
grande para que os testes com protótipos de papel sejam efetivos. De fato essa é uma
restrição característica da técnica, mas, segundo SNYDER (2003), isso é superado ao se
convocar para realizar esse teste usuários com maior fluência no uso de computadores e da
Internet.
O entrevistado 3 declarou que não enxerga a necessidade de aplicar a técnica de
Card Sorting porque a fase de Pesquisa já lhe proveu informação suficiente para definir o
sistema de organização e de rotulação do website. Vale lembrar que esse entrevistado atua
predominantemente em projetos do mercado financeiro, no qual muitos rótulos são
definidos em normas regulatórias.
A Tabela 18 detalha as respostas dos entrevistados referentes à fase de Concepção.
Investigação empírica das metodologias de projetos de arquitetura de informação de websites
193
Tabela 18- Análise da fase de Concepção nas metodologia dos entrevistados
Categorias de análise Entrevistado 1 Entrevistado 2 Entrevistado 3 Entrevistado 4 Entrevistado 5
Existência da fase de
Concepção
Sim Sim Sim Sim Sim
Atividades na
metodologia que
correspondem a fase de
Concepção
- Infograma
- Wireframes
- Testes de
usabilidade
informais
- Testes de
usabilidade
- Criação do
conceito criativo
- Elaboração da
Macro-arquitetura
Não é definida. Se
mistura com a fase
de Pesquisa
- Macro-Arquitetura
- Lista de
Funcionalidades
- Linha Gráfica
- Mapa
informacional
- Wireframe
- Desenvolvimento
de alternativas
Profissionais que
participam da fase de
Concepção
- Arquiteto de
informação
- Arquiteto de
informação
-Designer gráfico
- Arquiteto de
Informação
- Analista de
Sistema
- Arquiteto de
Informação
- Analista de
sistema
- Designer gráfico
- Arquiteto de
Informação
Técnicas empregadas
- Esboço do
sitegrama
- Esboço dos
wireframes
- Reunião de
Brainstorming
- Diagrama de
conteúdo
(Diagrama de
bolas)
- Benchmark de
websites
concorrentes e
similares
- Análise Heurística
do website do
contratante
- Mapeamento do
posicionamento de
elementos de
interface em
websites
concorrentes e
similares
- Esboço do
sitegrama
- Levantamento de
funcionalidades
- Esboço da linha
gráfica
- Esboço do
sitegrama
- Esboço dos
wireframes
Documenta os
conceitos e regras
definidos para o
website
Não Sim Sim Não Sim
Freqüência de
aplicação de testes de
usabilidade nos
projetos
Raramente As vezes Não As vezes As vezes
Motivos para não
aplicar testes de
usabilidade nos
projetos
- Não conseguem
convencer o
contratante da
importância.
- Não conseguem
convencer o
contratante da
importância.
- Não possui
estrutura para fazer
testes de
usabilidade.
- Testes de
usabilidade são
feitos apenas para
projetos grandes.
Não respondeu a
questão.
Freqüência de
aplicação de testes de
Card Sorting nos
projetos
Não Não Não As vezes As vezes
Motivos para não
aplicar testes de Card
Sorting
- Nâo domina a
técnica
- Falta prazo nos
projetos
- Não enxerga a
necessidade de
aplicar a técnica
porque se sente
seguro com a
metodologia que
possui
Não cita Não cita
Freqüência de
aplicação de testes com
Protótipos de Papel nos
projetos
Não Não Não Não Raramente
Motivos para não
aplicar testes com
Protótipos de Papel
- Nâo domina a
técnica
- Falta prazo nos
projetos
- Não conseguem
convencer o
contratante da
importância.
Não cita - Não confia na
técnica
Não cita
Centrando a Arquitetura de Informação no usuário
194
5.2.1.1.3 Análise da fase de Especificação na metodologia dos entrevistados
A fase de Especificação é o momento na metodologia no qual se detalhada e se
documenta como o website deve ser implementado, como visto na investigação teórica. É
nessa fase que são produzidos os documentos de especificação da arquitetura de
informação do website: o sitegrama, o fluxo de navegação, os wireframes e o vocabulário
controlado.
A fase de Especificação também está presente na metodologia de todos os
entrevistados, que apontaram atividades específicas para essa fase. Não existe muita
uniformidade no nomes das atividades que compõem essa fase nas metodologias dos
entrevistados, com exceção da atividade “Wireframe”, citada por três entrevistados.
Observa-se, na metodologia dos entrevistados 1 e 5 que a fase de Especificação se
mistura com a fase de Concepção. De fato, a fase de Especificação tem a função de
detalhar e documentar os conceitos definidos na fase anterior, o que pode causar essa
mistura. Porém, a fase de Especificação normalmente demanda a elaboração de um
volume grande de documentos. Se os conceitos e as regras dos quatro sistemas
componentes da arquitetura de informação não estiverem bem definidos antes de iniciar a
fase de Especificação, as mudanças podem implicar em uma grande carga de trabalho para
realizar revisões.
O principal ator na fase de Especificação é o arquiteto de informação, responsável
por produzir todos os documentos. Porém, os entrevistados citam que os profissionais que
participaram da fase anterior continuam a participar dessa fase com as mesmas funções.
Os tipos de documentos produzidos nessa fase citado pelos entrevistados são os
mesmos tipos apontados na investigação teórica: os wireframes, o sitegrama e o fluxo de
navegação. Não foi citado o vocabulário controlado. O entrevistado 2 citou que produz
nessa fase um tipo de documento específico chamado dicionário conceitual que se trata de
um índice de todas as páginas do website com título, breve descritivo e palavras chaves.
Sua função é definir as metatags da página para os mecanismos de busca.
Investigação empírica das metodologias de projetos de arquitetura de informação de websites
195
Todos os entrevistados também declararam que possuem templates para todos os
tipos de documentos produzidos nessa fase. Ter esses templates é esperado uma vez que a
fase de Especificação é a fase que normalmente consome a maior quantidade de horas no
projeto e tais templates ajudam a aumentar a produtividade.
Na Tabela 19 estão as respostas dos entrevistados referentes à fase de
Especificação.
Tabela 19 - Análise da fase de Especificação nas metodologias dos entrevistados
Categorias de análise Entrevistado 1 Entrevistado 2 Entrevistado 3 Entrevistado 4 Entrevistado 5
Existência da fase de
Especificação
Sim Sim Sim Sim Sim
Atividades na
metodologia que
correspondem a fase de
Especificação
- Infograma
- Wireframe
- Fluxo de
navegação
- Define os labels
- Testes de
usabilidade
informais
- Testes de
usabilidade
Se mistura com a
fase de Concepção
- Detalhamento
- Dicionário
Conceitual
- Documento de
mensagens de erro
- Wireframes - Detalhar os fluxos
de navegação
- Wireframes
Não é definida. Se
mistura com a fase
de Concepção.
Profissionais que
participam da fase de
Especificação
- Arquiteto de
informação
- Analista de
Sistema
- Arquiteto de
informação
- Designer Gráfico
Arquiteto de
informação
- Arquiteto de
informação
- Analista de
Sistema
Arquiteto de
informação
Documentos
produzidos
- Sitegrama
(infograma)
- Wireframes
- Fluxo de
navegação (apenas
para websites com
transações
complicadas)
- Sitegrama
- Wireframes
- Fluxo de
navegação
- Dicionário
conceitual
- Sitegrama
- Wireframes
- Fluxo de
navegação
- Fluxo de
navegação
- Wireframes
- Sitegrama
- Wireframes
Existência de templates
dos documentos
Sim Sim Sim Sim Sim
5.2.1.1.4 Análise da fase de Implementação na metodologia dos entrevistados
A fase de Implementação, conforme visto na investigação teórica, cuida do
acompanhamento do trabalho das demais equipes envolvidas no projeto e responsáveis por
implementar o website. Nessa fase o arquiteto acompanha o trabalho desses profissionais
para apresentar seus documentos de especificação, responder a dúvidas, validar se o
website foi implementado conforme sua especificação e revisar sua documentação caso
necessário.
Centrando a Arquitetura de Informação no usuário
196
Dos cinco profissionais entrevistados, três citaram que possuem uma fase de
Implementação nas suas metodologias. Esses entrevistados identificaram as atividades que
correspondem a fase, nas quais não foi observada uniformidade nos nomes. Os dois
entrevistados que não identificaram atividades em suas metodologias que correspondam a
fase de Implementação declararam que executam a fase de maneira informal por meio de
acompanhamentos parciais e sob demanda.
Segundo os entrevistados, as áreas cujo trabalho é acompanhado pelo arquiteto de
informação são as mesmas que participaram das fases anteriores: projeto gráfico e
tecnologia da informação.
Nota-se, nas respostas dos entrevistados que existe pouca preocupação com a fase
de Implementação nas suas metodologias, confirmando a investigação teórica.
A Tabela 20 apresenta as respostas dos entrevistados sobre a fase de
Implementação.
Tabela 20 - Análise da fase de Implementação nas metodologias dos entrevistados
Categorias de análise Entrevistado 1 Entrevistado 2 Entrevistado 3 Entrevistado 4 Entrevistado 5
Existência da fase de
Implementação
Não Sim Não Sim Sim
Atividades na
metodologia que
correspondem a fase de
Implementação
--- - Homologação do
protótipo
--- - Tirar dúvidas
- Acompanhamento
do lançamento
- Realiza a
alternativa
escolhida
Profissionais que
participam da fase de
Implementação
- Arquiteto de
Informação
- Analista de
Sistema
- Designer Gráfico
- Arquiteto de
Informação
- Analista de
Sistema
- Arquiteto de
Informação
- Analista de
Sistema
- Designer Gráfico
- Arquiteto de
Informação
- Analista de
Sistema
---
5.2.1.1.5 Análise da fase de Avaliação na metodologia dos entrevistados
A fase de Avaliação cuida da avaliação dos resultados do projeto, conforme o
quadro de referência visto na investigação teórica. Nessa fase é avaliado se o website
atingiu os objetivos planejados para que os profissionais envolvidos tenham a
possibilidade de aprender com os próprios erros e melhorar sua forma de trabalho.
Essa fase é a menos citada pelos entrevistados. Quatro dos entrevistados
declararam que não fazem avaliação dos resultados dos seus projetos. “Larga o filho no
Investigação empírica das metodologias de projetos de arquitetura de informação de websites
197
mundo quando o site vai para o ar”, citou o entrevistado 1 para ilustrar a ausência dessa
fase na sua metodologia. Esse resultado confirma a investigação teórica, na qual se
observou que os autores dedicam pouca atenção à fase de Avaliação.
Apenas o entrevistado 4 declarou ter essa fase na sua metodologia e apontou uma
única atividade que lhe corresponde. Esse entrevistado, ao contrário dos demais, trabalha
em uma empresa que desenvolve seus próprios websites, o que lhe facilita o acesso a
informações para avaliar os resultados dos seus projetos.
O entrevistado 3 citou que a avaliação dos projetos fica a cargo da empresa
contratante e ele só têm acesso à essa avaliação caso a empresa resolva espontaneamente
apresentá-la. O entrevistado 2 citou que a empresa onde trabalha realiza avaliações dos
resultados dos projetos, mas isso é feito por outra área e apenas quando o contratante
solicita esse serviço. Não foi observada nenhuma atitude pró-ativa nos entrevistados para
efetuar uma avaliação dos seus projetos independente da vontade de seus contratantes.
A Tabela 21 mostra as respostas dos entrevistados referentes à fase de Avaliação.
Tabela 21 - Análise da fase de Avaliação nas metodologias dos entrevistados
Categorias de análise Entrevistado 1 Entrevistado 2 Entrevistado 3 Entrevistado 4 Entrevistado 5
Existência da fase de
Avaliação
Não Não Não Sim Não
Atividades na
metodologia que
correspondem a fase de
Avaliação
--- --- --- - Acompanhamento
pós-lançamento
---
Motivos para a não
existência da fase
Não cita
- A avaliação é feita
por outro
departamento da
empresa e apenas
quando contratado.
- Contratante faz a
avaliação.
--- Não cita
5.2.2 Análise das dificuldades dos entrevistados nos projetos de arquitetura
de informação
Na fase II da entrevista foi solicitado a cada entrevistado que escolhesse um
projeto de arquitetura de informação do qual participou e citasse as três principais
dificuldades que enfrentou durante esse projeto. Nem todos os entrevistados conseguiram
Centrando a Arquitetura de Informação no usuário
198
citar três dificuldades, assim, foram levantadas 13 citações, classificadas em 9 dificuldades
diferentes.
A dificuldade mais citada foi integrar o website com sistemas legados. Em seguida
foram mais citadas: evitar usar no website a linguagem e a organização interna da empresa
contratante e fazer o contratante compreender os documentos de especificação. A Tabela
22 apresenta essas dificuldades.
Tabela 22 - Dificuldades dos entrevistados nos projetos de arquitetura de informação
Dificuldade Qtd citações
Integrar o website com sistemas legados 3
Evitar usar no website a linguagem e a organização interna da
empresa contratante
2
Fazer o contratante compreender os documentos de
especificação
2
Atender vários decisores 1
Atender públicos-alvos diferentes 1
Definir o objetivo do site 1
Gerenciar um volume grande de documentos 1
Obter acesso as fontes de informação 1
Produzir um documento conciso e expor os pontos negativos
do website do contratante sem gerar antipatias
1
Total geral 13
Foi realizada uma análise das dificuldades quanto ao foco das questões
apresentadas pelos entrevistados, isto é, a identificação do núcleo central do problema
segundo suas próprias óticas. Nessa análise foram identificados três focos diferentes:
• Contratante: ocorre quando o foco recai em alguma habilidade essencial,
característica ou requisito do contratante do projeto. Esse foi o foco com
mais citações e contém quatro dificuldades diferentes.
• Próprio ao trabalho de Arquitetura de Informação: ocorre quando o
foco recai sobre alguma habilidade essencial, ferramenta necessária ou nas
condições de trabalho do entrevistado. Esse foi o segundo foco com mais
citações também com quatro dificuldades diferentes.
Investigação empírica das metodologias de projetos de arquitetura de informação de websites
199
• Contexto tecnológico: ocorre quando o foco recai nos requisitos técnicos
do projeto. Esse foi o foco com menos citações e contém uma dificuldade,
porém a mais citada na pesquisa.
Percebe-se nessa análise que o contratante é um forte ponto de dificuldade nos
projetos de arquitetura de informação. A Tabela 23 mostra as dificuldades classificadas
pelo foco das suas questões.
Tabela 23 – Classificação das dificuldades pelo foco das questões dos entrevistados
Foco da questão Dificuldade Qtd citações
Evitar usar no website a linguagem e a organização
interna da empresa contratante
2
Fazer o contratante compreender os documentos de
especificação
2
Atender vários decisores 1
Definir o objetivo do site 1
Atender públicos-alvos diferentes 1
Gerenciar um volume grande de documentos 1
Obter acesso as fontes de informação 1
Produzir um documento conciso e expor os pontos
negativos do website do contratante sem gerar antipatias
1
Contexto
tecnológico
Integrar o website com sistemas legados 3
13
Próprio ao trabalho
de Arquitetura de
Informação
Contratante
Total geral
Ao descrever suas dificuldades, os entrevistados indicaram em quais atividades das
suas metodologias elas ocorreram e com isso foi possível classificá-las nas fases do
quadro de referência.
A fase de Concepção é a que apresenta mais dificuldades diferentes e também a
dificuldade mais citada. Polemicas naturalmente surgem na fase de Concepção porque é
nela que se decide a solução do projeto, portanto é compreensível que apareçam mais
dificuldades.
A fases de Pesquisa apresentou mais dificuldades diferentes que a fase de
Especificação, mas ambas apresentam a mesma quantidade de citações. Não foram citadas
dificuldades nas fases de Implementação e Avaliação, o que demonstra a baixa
preocupação dos entrevistados com essas fases. A Tabela 24 mostra a classificação das
dificuldades nas fases do quadro de referência.
Centrando a Arquitetura de Informação no usuário
200
Tabela 24 - Classificação das dificuldades nas fases do quadro de referência
Fase Dificuldade Qtd citações
Definir o objetivo do site 1
Obter acesso as fontes de informação 1
Produzir um documento conciso e expor os pontos negativos
do website do contratante sem gerar antipatias
1
Integrar o website com sistemas legados 3
Evitar usar no website a linguagem e a organização interna da
empresa contratante
2
Atender públicos-alvos diferentes 1
Atender vários decisores 1
Fazer o contratante compreender os documentos de
especificação
2
Gerenciar um volume grande de documentos 1
13
Total geral
Pesquisa
Especificação
Concepção
Cruzando-se a fase em que ocorreram as dificuldades com o foco da questão
percebe-se que os focos do contratante e do próprio trabalho de Arquitetura de Informação
permeiam todas as fases, porém o foco do contexto tecnológico ocorre apenas na fase de
Concepção. Nessa fase é definida a solução macro do projeto, por isso é nela que as
restrições tecnológicas precisam ser resolvidas. A Tabela 25 mostra as dificuldades
classificadas pela fase do quadro de referência e pelo foco das questões.
Tabela 25 - Classificação das dificuldades nas fases do quadro de referência
e pelo foco das questões dos entrevistados
Fase Foco da questão Dificuldade Qtd citações
Contratante Definir o objetivo do site 1
Obter acesso as fontes de informação 1
Produzir um documento conciso e expor os pontos negativos
do website do contratante sem gerar antipatias
1
Contexto
tecnológico
Integrar o website com sistemas legados 3
Evitar usar no website a linguagem e a organização interna da
empresa contratante
2
Atender públicos-alvos diferentes 1
Próprio ao trabalho
de Arquitetura de
Informação
Atender vários decisores 1
Contexto
tecnológico
Fazer o contratante compreender os documentos de
especificação
2
Próprio ao trabalho
de Arquitetura de
Informação
Gerenciar um volume grande de documentos 1
13
Especificação
Próprio ao trabalho
de Arquitetura de
Informação
Concepção
Total geral
Pesquisa
Concepção
Investigação empírica das metodologias de projetos de arquitetura de informação de websites
201
A seguir todas as dificuldades estão analisadas conforme as fases do quadro de
referência.
5.2.2.1 Análise das dificuldades dos entrevistados na fase de Pesquisa
Os entrevistados citaram três dificuldades na fase de Pesquisa e nenhuma dessas
foi citada mais que uma única vez.
A primeira dificuldade apontada, definir o objetivo do website, teve como foco da
questão o contratante e ocorreu justamente porque o contratante não havia realizado um
planejamento estratégico para o website antes de iniciar o projeto de arquitetura de
informação. Para o entrevistado 4, que citou essa dificuldade, foi importante superá-la
para definir o escopo do projeto e alinhar toda a equipe confirmando a importância desse
planejamento visto na investigação teórica.
O entrevistado superou essa dificuldade participando da elaboração do
planejamento estratégico do website, embora não seja uma atribuição nem uma
especialidade de um arquiteto de informação. Isso foi possível porque esse entrevistado,
ao contrário dos demais, trabalha em uma empresa que desenvolve seus próprios websites
e assim teve acesso as informações e pessoas que participaram do desenvolvimento desse
planejamento estratégico.
Porém, apesar de ter conseguido superar a dificuldade, nem o entrevistado e nem o
contratante ficaram totalmente satisfeitos com a solução. Para superar essa dificuldade
completamente o entrevistado desejou ter mais prazo.
A segunda dificuldade, teve como foco da questão o próprio trabalho de
Arquitetura de Informação e ocorreu porque o entrevistado 3 não tinha acesso as fontes de
informação necessárias para realizar seu benchmark adequadamente. Essa dificuldade
exemplifica os problemas existentes para se levantar as informações na fase de Pesquisa.
Na situação citada pelo entrevistado, a dificuldade foi conseguir acesso a áreas restritas
dos websites dos concorrentes, mas em outras situações essa mesma dificuldade pode
ocorrer com outras fontes de informação.
Centrando a Arquitetura de Informação no usuário
202
O entrevistado conseguiu superar essa dificuldade utilizando senhas de acesso de
colegas de trabalho, amigos e parentes que coincidentemente eram usuários desses
websites. Com isso a dificuldade foi parcialmente superada porque nem todas as partes
dos websites dos concorrentes foram acessadas.
Essa estratégia mostra que criatividade e iniciativa são atributos que o arquiteto de
informação precisa ter na fase de Pesquisa para levantar as informações que necessita.
Embora o contratante tenha ficado plenamente satisfeito, o entrevistado ficou
parcialmente satisfeito porque sua dificuldade não foi totalmente superada. Para superá-la
o entrevistado desejou ter acesso aos websites dos concorrentes e imagens de todas as telas
desses websites.
Por fim, a última dificuldade também teve como foco da questão o próprio trabalho
do arquiteto de informação e retrata uma habilidade importante para esse profissional: o
domínio de técnicas para apresentação dos seus documentos, tanto na forma escrita quanto
na forma oral, de modo que consiga expor suas idéias de forma eficiente. A causa dessa
dificuldade foi o próprio entrevistado, que não gosta de escrever os relatórios de
apresentação do seu trabalho.
Para conseguir redigir um relatório objetivo, o entrevistado teve paciência,
determinação e contou com a ajuda da equipe de projeto, dividindo e direcionando a
confecção do relatório para pessoas com habilidade de escrita. Isso demonstra a
importância do trabalho em equipe nos projetos de arquitetura de informação porque
permite que profissionais diferentes complementem suas habilidades produzindo um
produto melhor.
Já para conseguir expor os pontos negativos do website do contratante, o
entrevistado usou de razão e sensibilidade para não gerar antipatias. Pelo lado da razão ele
justificou cada ponto negativo apontado. Pelo lado da sensibilidade, o entrevistado foi
polido e usou de eufemismos para não aumentar a dimensão dos problemas. Ele também
permitiu que o contratante explicasse a razão de um cada dos pontos negativos apontados,
uma atitude que não só criou mais empatia com o contratante como também permitiu ao
entrevistado conhecer mais detalhes dos problemas que enfrentaria ao longo do projeto.
Investigação empírica das metodologias de projetos de arquitetura de informação de websites
203
A abertura do contratante para ouvir críticas ao seu website e a paciência e
determinação do entrevistado também foram fatores que contribuíram para a superação
total dessa dificuldade e a satisfação total do contratante e do entrevistado. O entrevistado
desejou, para superar essa dificuldade, ter mais habilidade para escrita, poder produzir
duas versões do documento (completa e reduzida) e ter redatores na sua equipe de projeto.
A Tabela 26 descreve as dificuldades apontadas pelos entrevistados na fase de
Pesquisa. Cada coluna dessa tabela retrata uma dificuldade, analisada conforme os
componentes do triangulo do Sense-Making. Respostas que foram citadas por mais de um
entrevistado têm a quantidade de citações entre parênteses.
Centrando a Arquitetura de Informação no usuário
204
Tabela 26 - Análise das dificuldades dos entrevistados na fase de Pesquisa
- Entrevistado 4 - Entrevistado 3 - Entrevistado 2
Fase no quadro de
referência
Pesquisa Pesquisa Pesquisa
Atividades em que
ocorreu a
dificuldade
- Reunião de briefing - Benchmark - Documento de análise
Dificuldade
- Definir o objetivo do
site
- Obter acesso as fontes
de informação
- Produzir um
documento conciso e
expor os pontos
negativos do website do
contratante sem gerar
antipatias
Motivos que
geraram a
dificuldade
- Não foi realizado o
planejamento estratégico
do website antes do
projeto de Arquitetura de
Informação.
- A área restrita do
website dos
concorrentes é paga.
- Não gosta de escrever
o relatório
Foco da questão
- Contratante - Próprio ao trabalho de
Arquitetura de
Informação
- Próprio ao trabalho de
Arquitetura de
Informação
Uso
Importância de
superar a
dificuldade
- Para definir o escopo
do projeto
- Para alinhar toda a
equipe do projeto
- Para fazer o
benchmark
adequadamente
- Para conseguir
apresentar os problemas
do website
- Para fazer uma
apresentação objetiva
Estratégia utilizada
para superar a
dificuldade
- Focus group
- Pesquisa de
referências
- Reuniões com a equipe
de projeto
- Envolveu o contratante
com o projeto
- Encontrou colegas de
trabalho, amigos e
parentes com acesso as
fontes de informação.
- Dividiu o trabalho com
outros profissionais com
habilidade de escrita
- Paciência
- Determinação
- Eufemismo e polidez
na apresentação
- Justificou os pontos
negativos
- Solicitou ao contratante
que explicasse os
pontos negativos
Grau de superação
da dificuldade
- Sim, totalmente - Sim, parcialmente - Sim, totalmente
Satisfação do
Entrevistado
- Sim, parcialmente - Sim, parcialmente - Sim, totalmente
Satisfação do
Contratante
- Sim, parcialmente - Sim, totalmente - Sim, totalmente
Expectativa do que
ajudaria superar a
dificuldade
- Mais prazo - Acesso aos websites
dos concorrentes
- Ter imagens de todas
as telas dos websites
dos concorrentes
- Habilidade para
escrever
- Produzir duas versões
do documento (completa
e reduzida)
- Ter redatores na
equipe de projeto
Respostas citadas mais de uma vez possuem a quantidade de citações entre parenteses.
SituaçãoLacuna
Categorias de análise
Dificuldades
Entrevistados que
citaram a dificuldade
Estratégia
5.2.2.2 Análise das dificuldades dos entrevistados na fase de Concepção
Os entrevistados apontaram quatro dificuldades na fase de Concepção, sendo a
primeira delas a mais citada nessa pesquisa. São elas: integrar o website com sistemas
legados, evitar usar no website a linguagem e a organização interna da empresa
contratante, atender públicos-alvos diferentes e atender vários decisores.
Investigação empírica das metodologias de projetos de arquitetura de informação de websites
205
A primeira dificuldade, integrar com os sistemas legados, teve como foco da
questão o contexto tecnológico e ocorreu porque os sistemas computacionais com os quais
o website precisava se integrar não podiam ser modificados. Essa dificuldade foi citada
pelos entrevistados 1, 2 e 3 e superá-la era importante para melhorar a usabilidade e a
navegação do website.
De fato a integração com sistemas legados é uma dificuldade comum nos projetos
de arquitetura de informação, como visto na investigação teórica e faz parte dos requisitos
técnicos que o arquiteto de informação precisa atender. Ela surge quando existe a
necessidade de implementar nos websites transações que sensibilizem os sistemas
computacionais existentes na empresa do contratante. Como normalmente o custo e o
prazo para modificar esses sistemas são altos, o arquiteto precisa adaptar a sua solução
para que a construção seja viável. O problema apontado pelos entrevistados é que a
adaptação da solução sacrifica a usabilidade do website.
Para superar essa dificuldade os entrevistados utilizaram diversas ações: pesquisas
de boas práticas, pesquisas de outros websites cuja arquitetura de informação pudesse ser
utilizada como referência, análise heurística, envolvimento da área de tecnologia de
informação responsável pelo sistema legado, envolvimento do contratante com o projeto,
humildade e negociação.
Merece destaque a citação do entrevistado 3 quanto a ter uma atitude de humildade
para superar essa dificuldade. Por ter visão ampla e detalhada de todo o website e por
especificar o trabalho de todos os dos demais profissionais envolvidos é comum que o
arquiteto de informação assuma uma posição de liderança nos projetos. Mesmo assim cabe
a ele manter uma atitude de humildade e reconhecer a importância dos demais
profissionais, porque são eles que irão validar e implementar suas soluções. Se o arquiteto
for arrogante no trato com os demais membros da equipe de projeto terá muita dificuldade
ao negociar as suas soluções.
Todos os entrevistados citaram que suas estratégias superaram parcialmente a
dificuldade, uma vez que nem todas as soluções propostas puderam ser implementadas
completamente. Em todos os casos os contratantes ficaram totalmente satisfeitos e a
Centrando a Arquitetura de Informação no usuário
206
maioria dos entrevistados também, uma vez que as soluções que foram implementadas
tiveram uma boa relação entre custo e benefício.
Os desejos dos entrevistados para superar essa dificuldade foram: ter mais
referências, ter uma coleção de referências organizadas por tema, mais conhecimento e
verba para a área de tecnologia de informação e até mesmo um novo sistema legado.
A segunda dificuldade apontada na fase de Concepção, citada pelos entrevistados 2
e 4, foi evitar usar no website a linguagem e a organização interna da empresa. Essa
dificuldade teve como foco da questão o contratante e surgiu porque o contratante queria
utilizar a sua linguagem e organização própria da sua empresa nos sistemas de
organização e rotulação, um problema comum no design desses sistemas, como visto no
capítulo 3. Superar essa dificuldade foi importante para se criar rótulos compreensíveis
aos usuários, para melhorar a usabilidade e a navegação do website e para definir regras
claras para os sistemas que compõem a arquitetura de informação.
Essa dificuldade foi superada com negociação, pesquisa de boas práticas, pesquisas
de referência e uma atitude de tentar entender o problema do contratante, mas explicando-
lhe os problemas de usabilidade decorrentes das suas sugestões. Os entrevistados também
citaram que foram favorecidos por um contratante envolvido com o projeto.
Os dois entrevistados conseguiram, com suas estratégias, superar essa dificuldade,
embora apenas um deles a superou totalmente. Em ambos os casos o contratante ficou
totalmente satisfeito. Quanto a satisfação dos entrevistados um ficou totalmente satisfeito
e o outro ficou parcialmente. Apenas um desejo foi citado para essa dificuldade: que o
contratante não esqueça dos argumentos do entrevistado para que em novos projetos não
tenha que ocorrer essa mesma dificuldade.
A terceira dificuldade, apontada apenas pelo entrevistado 1, foi atender a públicos-
alvos diferentes. Essa dificuldade teve como foco o próprio trabalho de Arquitetura de
Informação e foi motivada pelos requisitos do projeto, nos quais definiu-se que o website
deveria atender a três públicos-alvos com necessidades diferentes. Essa é uma dificuldade
característica do sistema de organização, como visto no capítulo 3, e superá-la foi
importante para que cada público-alvo pudesse encontrar sua respectiva seção no website.
Investigação empírica das metodologias de projetos de arquitetura de informação de websites
207
Para superar essa dificuldade o entrevistado realizou estudo de cenários com
propostas de organização e rotulação do website e depois as validou com testes de
usabilidade. Ele também contou com um prazo adequado e um ambiente favorável para
seguir a sua metodologia.
Como resultado a dificuldade foi totalmente superada e o contratante ficou
totalmente satisfeito. O entrevistado ficou parcialmente satisfeito porque acredita que a
solução final do projeto não foi melhor que nenhum dos cenários propostos. O contratante
juntou elementos dos diversos cenários que, na opinião do entrevistado, não resultaram em
uma solução melhor.
O entrevistado não citou nenhum desejo para ajudá-lo a superar essa dificuldade,
apenas desejou que em projetos semelhantes possa também ter prazo adequado.
Por fim a última dificuldade da fase de Concepção, citada apenas pelo entrevistado
5, foi a de ter que atender vários decisores no seu projeto. Essa dificuldade também teve
como foco da questão o contratante e foi motivada pela dificuldade foi a ausência de uma
pessoa única por parte da empresa contratante que participasse de todas as discussões do
projeto e tivesse poder de decisão. Segundo o entrevistado não havia no projeto uma
definição clara de papéis e responsabilidades entre os profissionais da empresa contratante
e com isso muitas pessoas com visões diferentes sobre o projeto participavam do processo
decisório tornando-o demorado.
Essa dificuldade retrata o problema que as políticas internas da empresa podem
causar nos projetos de arquitetura de informação. Como visto no capítulo 3, conflitos de
interesse resultantes da disputa política interna da empresa podem afetar negativamente o
design do sistema de organização.
A estratégia adotada para superar essa dificuldade por parte do entrevistado foi
exigir que o contratante definisse uma pessoa para ser o ponto focal do projeto e atribuísse
a ela poder para decidir que solução deveria ser implementada. O envolvimento do
contratante com o projeto e da equipe de desenvolvimento também ajudaram o
entrevistado porque criaram um ambiente favorável para implementar essa estratégia.
Assim a dificuldade foi totalmente superada e tanto o entrevistado quanto seu contratante
Centrando a Arquitetura de Informação no usuário
208
ficaram totalmente satisfeitos. Para superar essa dificuldade o entrevistado desejou que ele
próprio tivesse discernimento para saber como proceder em situações difíceis e que o
contratante fosse aberto a mudanças.
A Tabela 27 descreve as dificuldades apontadas pelos entrevistados na fase de
Concepção. Cada coluna dessa tabela retrata uma dificuldade, analisada conforme os
componentes do triangulo do Sense-Making. Respostas que foram citadas por mais de um
entrevistado têm a quantidade de citações entre parênteses.
Investigação empírica das metodologias de projetos de arquitetura de informação de websites
209
Tabela 27 - Análise das dificuldades dos entrevistados na fase de Concepção
- Entrevistado 1
- Entrevistado 2
- Entrevistado 3
- Entrevistado 2
- Entrevistado 4
- Entrevistado 1 - Entrevistado 5
Fase no quadro de
referência
Concepção Concepção Concepção Concepção
Atividades em que
ocorreu a
dificuldade
- Wireframe e Fluxo de
navegação
- Elaboração da macro-
arquitetura
- Requisitos e
Documento de análise
- Elaboração da macro-
arquitetura
- Macro-arquitetura
- Infograma - Mapa informacional,
Wireframes e Desenvolve
as alternativas
Dificuldade
- Integrar o website com
sistemas legados (3)
- Evitar usar no website
a linguagem e a
organização interna da
empresa contratante (2)
- Atender públicos-alvos
diferentes
- Atender vários
decisores
Motivos que
geraram a
dificuldade
- Sistemas legados que
não podem ser
modificados. (3)
- Contratante deseja
utilizar no website a
linguagem e organização
da sua
empresa (2)
- Haviam três públicos-
alvos com necessidades
distintas que o website
precisava atender
Não havia um
representante único do
contratante para tomada
de decisão
Foco da questão
- Contexto tecnológico - Contratante - Próprio ao trabalho de
Arquitetura de
Informação
- Contratante
Uso
Importância de
superar a
dificuldade
- Para melhorar a
usabilidade das
transações (3)
- Para melhorar a
navegação no website.
- Para definir regras
claras para os sistemas
de organização,
navegação e rotulação
- Para melhorar a
usabilidade das
transações.
- Para criar rótulos
compreensíveis ao
usuário
Para melhorar a
navegação no website.
- Para cada público-alvo
encontrar sua respectiva
seção no website
- Para definir qual cenário
implementar
Estratégia utilizada
para superar a
dificuldade
- Pesquisa de
boas práticas (2)
- Pesquisa de
referências (2)
- Análise heurística
- Envolvimento de
Tecnologia de
Informação desde o
início do projeto
- Envolvimento do
contratante com o
projeto
- Humildade
- Negociação
- Negociação (2)
- Atitude de tentar
entender a posição da
outra parte
- Envolvimento do
contratante com o
projeto
- Explicar os problemas
de usabilidade
decorrentes das
sugestões do
contratante
- Pesquisa de
boas práticas
- Pesquisa de
referências
- Estudo de cenário
- Prazo adequado
- Ambiente favorável
para seguir a
metodologia de projetos
de arquitetura de
informação
- Teste de usabilidade
- Envolvimento do
contratante com o projeto
- Equipe de
desenvolvimento
- Exigiu do contratante a
definição de um
representante único
Grau de superação
da dificuldade
- Sim, parcialmente (3) - Sim, totalmente
- Sim, parcialmente
- Sim, totalmente - Sim, totalmente
Satisfação do
Entrevistado
- Sim, totalmente (2)
- Sim, parcialmente
- Sim, totalmente
- Sim, parcialmente
- Sim, parcialmente - Sim, totalmente
Satisfação do
Contratante
- Sim, totalmente (3) - Sim, totalmente (2) - Sim, totalmente - Sim, totalmente
Expectativa do que
ajudaria superar a
dificuldade
- Mais referências
- Coleção de referências
organizadas por tema
- Mais conhecimento na
área de Tecnologia de
Informação
- Mais verba para a área
de Tecnologia de
Informação
- Novo sistema legado
- Que o contratante
nunca mais esqueça os
argumentos do arquiteto
de informação
- Mais prazo (não nesse
projeto, mas nos
próximos)
- Discernimento para
saber como proceder em
situações difíceis
- Contratantes abertos a
mudanças
Respostas citadas mais de uma vez possuem a quantidade de citações entre parenteses.
Lacuna Situação
Entrevistados que
citaram a dificuldade
Estratégia
Categorias de análise
Dificuldades
Centrando a Arquitetura de Informação no usuário
210
5.2.2.3 Análise das dificuldades dos entrevistados na fase de Especificação
Para a fase de Especificação, os entrevistados citaram apenas duas dificuldades,
ambas relacionadas com a produção dos documentos característicos dessa fase. São elas:
fazer o contratante entender os documentos de especificação e gerenciar um volume
grande de documentos.
A primeira dificuldade teve como foco da questão o contratante e foi motivada por
dois fatores que retratam uma dicotomia presente na interpretação dos documentos de
especificação da arquitetura de informação.
O primeiro fator apontado é a dificuldade das pessoas em interpretar os
documentos de Arquitetura de Informação por não estarem familiarizadas com eles. Como
visto no capítulo 4 por ser um campo novo é comum o arquiteto se deparar com pessoas
que não conhecem o objetivo de cada tipo de documento, como são organizados e o
vocabulário visual utilizado. Por isso essas pessoas precisam de treinamento para
interpretar tais documentos, uma vez que não são documentos de uso comum. Assim,
muitas vezes o arquiteto de informação precisa alfabetizar seu leitor.
Essa foi a estratégia adotada pelo entrevistado 5. Ele analisou o perfil do
contratante e lhe explicou sua metodologia e cada tipo de documento produzido. Ele
também contou com o envolvimento do contratante com o projeto e dessa forma a
dificuldade foi superada, satisfazendo totalmente ele e o contratante. Esse entrevistado não
desejou nada para auxiliá-lo a superar essa dificuldade. Apenas desejou que em próximos
projetos possa novamente ter contratantes bastante envolvidos.
O outro fator apontado que motivou a dificuldade de compreensão dos documentos
de especificação da arquitetura de informação é que o leitor pode não ter a capacidade de
abstração necessária para entender os documentos de especificação. Os documentos
elaborados na fase de Especificação, por serem uma modelagem do website, não são uma
representação realista do produto final. Eles são focados nas características relacionadas à
organização da informação e dão menos atenção as demais. Além disso, nem sempre é
possível retratar no papel toda a interatividade da Web, como foi citado pelo entrevistado
2, no levantamento da sua metodologia (veja Tabela 16).
Investigação empírica das metodologias de projetos de arquitetura de informação de websites
211
Para compreender tais documentos é necessário que o leitor tenha uma capacidade
de abstração que não é comum a pessoas sem experiência com projetos na Web. O
arquiteto ao se deparar com pessoas desse tipo precisa ter flexibilidade para produzir seus
documentos de uma forma que permita aos seus leitores compreende-los. Assim, muitas
vezes o arquiteto precisa criar uma linguagem para seu leitor.
O entrevistado 2 não conseguiu fazer com que seu contratante compreendesse os
documentos de arquitetura de informação com níveis mais altos de abstração (o sitegrama
e o fluxo de navegação). Assim, para contornar essa dificuldade, ele adaptou para o
contratante a sua forma de elaborar a documentação e acabou por fazê-la toda em
wireframes, os quais possuem um nível mais baixo de abstração. Os wireframes
representam o website de forma mais realista que o sitegrama e o fluxo de navegação,
porém são mais demorados para serem produzidos.
A estratégia resultou em um contratante totalmente satisfeito, mas o entrevistado
ficou insatisfeito com a solução porque o projeto avançou no prazo planejado e produziu
uma documentação extensa e difícil de gerenciar. O seu desejo para superar essa
dificuldade foram dois: fazer o contratante entender os documentos com nível mais alto de
abstração ou conseguir saber, antes de iniciar um projeto, se o contratante possui
capacidade de abstração para compreender esses documentos de modo que possa prever
nos seus projetos mais horas para a produção de wireframes se for necessário.
A segunda dificuldade apontada na fase de Especificação, gerenciar um volume
grande de wireframes, também foi citada pelo entrevistado 2 e foi decorrente da sua
dificuldade anterior. Essa dificuldade teve como foco o próprio trabalho de arquitetura de
informação e ocorreu porque o grande volume de wireframes produzidos tornou o trabalho
de gerenciá-los muito difícil já que a cada revisão muitos documentos eram afetados.
Como visto na investigação teórica, bons documentos de especificação possuem
redundância mínima justamente para facilitar o trabalho de revisão. Nos documentos de
Arquitetura de Informação, a diminuição da redundância se consegue utilizando o
sitegrama e o fluxo de navegação, para representar os relacionamentos e a navegação entre
as páginas nas diversas situações de uso do website. Os wireframes são utilizados apenas
para especificar páginas modelo.
Centrando a Arquitetura de Informação no usuário
212
Como no caso citado, o entrevistado teve de fazer wireframes de todas as páginas
do website, a documentação ficou muito redundante e volumosa e cada revisão exigia que
diversos pontos do documento fossem alterados.
Segundo o entrevistado a dificuldade não foi superada. A utilização de um
software com múltiplos templates facilitou a produção dos wireframes, mas não resolveu o
problema. Também trabalharam na produção desses wireframes arquitetos com diferentes
perfis (juniores, plenos e seniores), o que permitiu reduzir um pouco o custo total do
projeto. O entrevistado ficou parcialmente satisfeito com a solução, mas seu contratante
ficou totalmente satisfeito porque recebeu os wireframes de todas as páginas do site.
O desejo do entrevistado para superar essa dificuldade reflete um apontamento
feito na investigação teórica: os arquitetos de informação são carentes de ferramentas
CASE que automatizam o trabalho de produção dos seus documentos.
A Tabela 28 descreve as dificuldades apontadas pelos entrevistados na fase de
Concepção. Cada coluna dessa tabela retrata uma dificuldade, analisada conforme os
componentes do triangulo do Sense-Making. Respostas que foram citadas por mais de um
entrevistado têm a quantidade de citações entre parênteses.
Investigação empírica das metodologias de projetos de arquitetura de informação de websites
213
Tabela 28 - Análise das dificuldades dos entrevistados na fase de Pesquisa
- Entrevistado 5 - Entrevistado 2 - Entrevistado 2
Fase
Especificação Especificação Especificação
Atividades em que
ocorreu a
dificuldade
- Mapa informacional e
Wireframes
- Detalhamento - Detalhamento
Dificuldade
- Gerenciar um volume
grande de documentos
Motivos que
geraram a
dificuldade
- Contratante não
conhece a metodologia
de Arquitetura de
Informação e os
documentos de
especificação
- Contratante não tem
capacidade de abstração
para entender os
documentos de
especificação de alto
nível (sitegrama e fluxos
de navegação)
- Executar as revisões
foi trabalhoso porque
muitos documentos
eram afetados
Foco da questão
- Contratante - Contratante - Próprio ao trabalho de
Arquitetura de
Informação
Uso
Importância de
superar a
dificuldade
- Para adquirir a
confiança do contratante
e aumentar sua
participação no projeto
- Para diminuir o tempo
de produção e revisão
dos documentos
- Para diminuir o tempo
de produção e revisão
dos documentos
Estratégia utilizada
para superar a
dificuldade
- Análise do perfil do
contratante
- Envolver o contratante
com o projeto
- Negociação
- Produziu os wireframes
de todas as telas
- Utilizou um software
com múltiplos templates
para a produção dos
wireframes
- Ter múltiplos perfis de
arquitetos na equipe:
juniores, plenos e
seniores
Grau de superação
da dificuldade
- Sim, totalmente - Não - Não
Satisfação do
Entrevistado
- Sim, totalmente - Não - Sim, parcialmente
Satisfação do
contratante
- Sim, totalmente - Sim, totalmente - Sim, totalmente
Expectativa do que
ajudaria superar a
dificuldade
- Contratantes mais
parceiros (não nesse
projeto, mas nos
próximos)
- Contratantes que
entendam os
documentos de alto nível
- Saber, antes de fazer o
orçamento, se o
contratante não entende
os documentos de alto
nível para prever mais
horas de produção dos
wireframes
- Software com
bibliotecas e templates
que automatize a
produção dos
documentos de
especificação
Respostas citadas mais de uma vez possuem a quantidade de citações entre parenteses.
- Fazer o contratante compreender os documentos
de especificação (2)
LacunaEstratégia Situação
Categorias de análise
Dificuldades
Entrevistados que
citaram a dificuldade
5.2.2.4 Análise das estratégias adotadas
As estratégias dos entrevistados foram classificadas nos focos das questões através
das dificuldades em que foram adotadas. Essa análise mostra quais estratégias foram
empregadas em cada foco de questão e a eficiência delas.
Centrando a Arquitetura de Informação no usuário
214
As estratégias mais utilizadas nas dificuldades com foco da questão no contratante
são o envolvimento dele com o projeto, negociação e outras semelhantes (análise do perfil
do contratante, atitude de tentar entender a posição da outra parte, exigiu do contratante a
definição de um representante único e explicou os problemas de usabilidade decorrentes
das sugestões do contratante). Essas estratégias tiveram sucesso na superação da
dificuldade, o que mostra a importância do arquiteto de informação ter boas habilidades de
negociação, confirmando a investigação teórica.
Com relação as dificuldades com foco da questão no próprio trabalho de
Arquitetura de Informação, nenhuma estratégia se destacou e de forma geral as estratégias
adotadas foram eficientes. Pode-se observar nessas estratégias que os arquitetos de
informação lançaram mão de diferentes habilidades para superar suas dificuldades:
paciência, determinação, habilidade para apresentar seu trabalho, criatividade e iniciativa
(as duas últimas utilizadas para encontrar colegas de trabalho, amigos e parentes com
acesso as fontes de informação). Um ambiente favorável para seguir a metodologia de
projetos e um prazo adequado também ajudaram a superar essas dificuldades.
Por fim o que se observa nas estratégias adotadas para superar as dificuldades com
foco da questão no contexto tecnológico é elas se baseiam principalmente na pesquisa de
soluções (pesquisa de boas práticas e pesquisas de referência) e na negociação com a área
de tecnologia de informação. Porém nenhuma estratégia adotada foi completamente
eficiente. A Tabela 29 mostra as estratégias adotada pelos entrevistados classificadas pelo
foco da questão.
Investigação empírica das metodologias de projetos de arquitetura de informação de websites
215
Tabela 29 - Classificação das estratégias pelo foco das questões dos entrevistados
Foco da questão Estratégia Qtd citações Grau de superação da
dificuldade
Envolveu o contratante com o projeto 4
- Sim, totalmente (4)
Negociação 3
- Sim, totalmente (2)
- Sim, parcialmente
Pesquisa de referências 2
- Sim, totalmente
- Sim, parcialmente
Análise do perfil do contratante 1
- Sim, totalmente
Atitude de tentar entender a posição da outra parte 1
- Sim, totalmente
Envolveu a equipe de desenvolvimento com o projeto
1
- Sim, totalmente
Exigiu do contratante a definição de um representante
único
1
- Sim, totalmente
Explicar os problemas de usabilidade decorrentes das
sugestões do contratante
1
- Sim, totalmente
Focus group 1
- Sim, totalmente
Pesquisa de boas práticas 1
- Sim, parcialmente
Produziu os wireframes de todas as telas 1
- Não
Reuniões com a equipe de projeto 1
- Sim, totalmente
Ambiente favorável para seguir a metodologia de projetos
de arquitetura de Informação
1
- Sim, totalmente
Determinação
1
- Sim, totalmente
Dividiu o trabalho com outros profissionais com
habilidade de escrita
1
- Sim, totalmente
Encontrou colegas de trabalho, amigos e parentes com
acesso as fontes de informação.
1
- Não
Estudo de cenário
1
- Sim, totalmente
Eufemismo e polidez na apresentação 1
- Sim, totalmente
Justificou os pontos negativos 1
- Sim, totalmente
Paciência
1
- Sim, totalmente
Prazo adequado 1
- Sim, totalmente
Solicitou ao contratante que explicasse os pontos
negativos
1
- Sim, totalmente
Ter múltiplos perfis de arquitetos na equipe: juniores,
plenos e seniores
1
- Não
Teste de usabilidade
1
- Sim, totalmente
Utilizou um software com múltiplos templates para a
produção dos wireframes
1
- Não
Pesquisa de boas práticas 2
- Sim, parcialmente (2)
Pesquisa de referências 2
- Sim, parcialmente (2)
Análise heurística
1
- Sim, parcialmente
Envolveu Tecnologia de Informação desde o início do
projeto
1
- Sim, parcialmente
Envolveu o contratante com o projeto
1
- Sim, parcialmente
Humildade 1
- Sim, parcialmente
Negociação 1
- Sim, parcialmente
Contratante
Próprio ao trabalho
de Arquitetura de
Informação
Contexto
tecnológico
5.2.3 Síntese dos resultados encontrados
Essa pesquisa mostrou que os arquitetos de informação experientes adotam uma
metodologia nos seus projetos de arquiteta de informação, algumas delas documentadas,
outras guardadas no conhecimento tácito dos funcionários das suas empresas. E apesar das
diferenças de nomenclaturas e atividades, existe muita similaridade entre elas.
Os arquitetos concordam com suas metodologias pelos seguintes motivos: a
comprovaram na prática, elas caminham de uma visão macro para uma visão detalhada ao
Centrando a Arquitetura de Informação no usuário
216
longo do projeto e elas os ajudam a terem argumentos palpáveis e racionais para negociar
suas soluções.
Na maioria dos projetos, as metodologias são seguidas em todas as suas atividades.
A exceção são projetos pequenos, projetos com solução conhecida, projetos com restrição
de prazo e casos de resistência do contratante. Assim, as metodologias de projetos de
arquitetura de informação precisam ser flexíveis e oferecer atalhos.
Analisando-se as metodologias segundo o quadro de referência formulado na
investigação teórica foi possível encontrar atividades que correspondem a cada uma das
suas fases: Pesquisa, Concepção, Especificação, Implementação e Avaliação.
A análise da fase de Pesquisa nas metodologias levantadas mostra que o design do
website é mais centrado na empresa contratante e nos seus problemas internos que nos
usuários. São raros os casos em que são feitas pesquisas diretas com usuários, o que
demonstra que essas metodologias não seguem a abordagem de Design Centrado no
Usuário da Ciência da Informação.
A fase de Concepção não apresenta uma separação muito clara da fase de Pesquisa,
com a qual compartilha técnicas e atividades. O arquiteto lidera essa fase, mas conta com
a ajuda de outros profissionais para gerar idéias e validar sua soluções.
As técnicas empregadas nessa fase são, na sua maioria, técnicas de geração de
idéias utilizadas para definir os conceitos e as regras dos sistemas de organização, de
navegação, de rotulação e de busca. Poucos testes de usabilidade são realizados porque
não se consegue convencer os contratantes da importância e também porque não existe
pleno domínio das técnicas mais adequadas à Arquitetura de Informação. Isso demonstra
que as metodologias dos entrevistados seguem pouco a abordagem de Design Centrado no
Usuário da Interação Humano-Computador.
Na fase de Especificação também não existe uma separação clara da fase anterior.
O arquiteto de informação também é o principal ator dessa fase, mas continua a contar
com o auxílio das áreas de projeto gráfico e tecnologia de informação. Os documentos
Investigação empírica das metodologias de projetos de arquitetura de informação de websites
217
produzidos nessa fase são os apontados na investigação teórica: o sitegrama, o fluxo de
navegação e os wireframes.
Com relação à fase de Implementação, existe pouca preocupação com essa fase,
confirmando a investigação teórica.
Também foi observada pouca preocupação com a fase de Avaliação, que quando
existe fica inteiramente a cargo da empresa contratante e raramente o arquiteto tem acesso
aos relatórios de avaliação.
Com relação as dificuldades, foi observado que a maioria delas tem em comum o
foco o contratante e ocorrem mais na fase de Concepção.
As principais dificuldades na fase de Pesquisa são: definir o objetivo do website,
obter acesso as fontes de informação e produzir um documento conciso expondo os pontos
negativos do website do contratante sem gerar antipatias. Para superá-las, o arquiteto
emprega sua criatividade, iniciativa e o domínio de técnicas de apresentação. Ele também
pode participar do planejamento estratégico do website, embora não seja sua atribuição e
não tenha todas as habilidades necessárias.
Na fase de Concepção as principais dificuldades são integrar o website com
sistemas legados, evitar usar no website a linguagem e a organização interna do
contratante, atender a públicos-alvos diferentes e atender vários decisores. Para superá-las
o arquiteto realiza pesquisa de boas práticas e referências, estudos de cenário, análises
heurística, testes de usabilidade, envolve a área de tecnologia de informação e o
contratante com o projeto, negocia e tem uma atitude de humildade perante os demais
membros do time de projeto.
E na fase de Especificação as principais dificuldades apontadas são: fazer o
contratante compreender os documentos de especificação e gerenciar um volume grande
desses documentos. Para superar a primeira dificuldade, o arquiteto precisa alfabetizar o
seu leitor ou criar uma linguagem para ele. Já segunda dificuldade ainda não é totalmente
superada. Falta para o arquiteto de informação ferramentas de software, especialmente
ferramentas CASE, que automatizem a produção e o gerenciamento dos seus documentos.
Centrando a Arquitetura de Informação no usuário
218
Com relação as estratégias temos que para as dificuldades com foco no contratante
a negociação e o envolvimento do contratante são as mais adotadas com bastante sucesso.
Nas dificuldades com foco no próprio trabalho de arquitetura de informação as
estratégias resultaram de diversas habilidades dos entrevistados, como paciência,
determinação, habilidade em apresentar o seu trabalho, criatividade e iniciativa. Essas
estratégias também apresentaram sucesso.
Já nas dificuldades com foco no contexto tecnológico, as estratégias se basearam
na pesquisa de soluções e na negociação com a área de tecnologia de informação, porém
não foram completamente eficientes.
Considerações finais
219
Capítulo 6
Considerações finais
O nosso mundo contemporâneo produz uma quantidade gigantesca de informação
nunca antes vivenciada na história da humanidade. São bilhões de gigabytes de
informação nova produzidos todos os anos, sendo a Internet o maior catalisador desse
fenômeno. Esse admirável mundo novo precisa de novas formas de organizar suas
informações, do contrário sucumbiremos em uma montanha de dados incompreensíveis.
A Arquitetura de Informação é uma resposta para essa necessidade, um novo
campo multi-disciplinar com o objetivo de organizar a informação para satisfazer as
necessidades dos usuários tornando o complexo claro.
É justamente na organização da Web que a Arquitetura de Informação tem
encontrado sua maior aplicação atualmente. Ela se tornou uma das disciplinas essenciais
para o projeto de websites, sendo a responsável por definir a estrutura organizacional da
informação sobre a qual todas as demais partes se apoiarão.
Um projeto da arquitetura de informação de um website cria seus quatro
componentes fundamentais: os sistemas de organização, de navegação, de rotulação e de
busca. E por ser um problema complexo, com muitas variáveis, esses projetos precisam
Centrando a Arquitetura de Informação no usuário
220
seguir uma metodologia para reduzir o caráter intuitivo dos seus métodos, organizar o
trabalho e garantir a qualidade do produto final, do contrário as chances de falha
aumentam.
O objetivo desse trabalho foi estudar as práticas de projetos de arquitetura de
informação de websites com profissionais brasileiros que atuam na área para verificar o
grau de aderência com as propostas teóricas de metodologias de projetos dessa natureza.
Dado que o objetivo da Arquitetura de Informação é construir espaços
informacionais que satisfaçam as necessidades dos usuários, esse trabalho teve como foco
para sua análise as abordagens de Design Centrado no Usuário da Interação Humano-
Computador e da Ciência da Informação.
A abordagem de Design Centrado no Usuário da Interação Humano-Computador
surgiu com a popularização dos computadores, quando pessoas sem conhecimento em
informática passaram a utilizar essas máquinas e por isso necessitavam de interfaces mais
fáceis de usar. Um conceito chave na Interação Humano-Computador é a Usabilidade,
definida como a medida na qual um produto pode ser usado por usuários específicos para
alcançar objetivos específicos com efetividade, eficiência e satisfação num contexto
específico de uso. A abordagem de Design Centrado no Usuário da Interação Humano-
Computador tem por características: focalizar no usuário e nas tarefas que realizada,
utilizar medidas empíricas da usabilidade do produto observando a interação do usuário
com ele e empregar um processo de design iterativo e interativo com refinamentos
sucessivos.
De forma complementar temos a abordagem de Design Centrado no Usuário na
visão da Ciência da Informação, a qual nasceu de uma mudança de paradigma que essa
disciplina vivenciou a partir da década de 70, quando pesquisadores começaram a se
preocupar em compreender os aspectos cognitivos e comportamentais dos usuários quando
estão buscando informações. Essa mudança de paradigma questionou as abordagens
tradicionais dos estudos de usuários e necessidades de informação existentes na época,
cujo foco era centrado no sistema. Surgiu a abordagem alternativa dos estudos de usuários
e necessidades de informação, que centra seu foco no usuário. Essa nova abordagem é
caracterizada por observar o usuário de um sistema de informação como um cliente,
Considerações finais
221
estudar suas necessidades e a maneira como ele interage com o mundo para satisfazê-las,
ter uma visão holística dele e empregar técnicas de pesquisa qualitativa.
Ambas as abordagens de Design Centrado no Usuário trazem contribuições
importantes para a Arquitetura de Informação. A abordagem da Interação Humano-
Computador tem uma visão mais operacional, focada em compreender como o usuário
executa suas tarefas ao interagir com interfaces computacionais. Já a abordagem da
Ciência da Informação tem uma visão holística do usuário e preocupa-se em compreender
suas necessidades, a situação em que se encontra e o seu comportamento ao buscar
informação.
A revisão da literatura feita nesse trabalho apontou que as principais dificuldades
para organizar informação na Web estão relacionadas ao design de três dos quatro
componentes fundamentais da Arquitetura de Informação, que apresentam maior
independência: os sistemas de organização, de navegação e de rotulação. As principais
dificuldades do design desses três são ambigüidade, heterogeneidade, diferenças de
perspectiva, políticas internas, estética, localizar o usuário no website, ausência de
padrões, falar na linguagem do usuário, superar a ausência de feedback e manter a
consistência.
A investigação teórica das metodologias de projetos de arquitetura de informação
de websites formulou um quadro de referência para analisá-las com os seguintes
princípios:
• As metodologias devem possuir cinco fases distintas:
o Pesquisa: na qual são pesquisadas e analisadas as informações
sobre os usuários, suas necessidades e o seu ambiente para definir o
escopo e os requisitos do projeto.
o Concepção: uma fase eminentemente criativa, na qual se concebe a
visão macro da solução.
o Especificação: na qual a visão macro da solução é detalhada em
documentos e diagramas que explicam como construir o website.
Centrando a Arquitetura de Informação no usuário
222
o Implementação: na qual website é construído conforme
especificado e disponibilizado para uso.
o Avaliação: na qual o resultado do projeto é avaliado em função dos
seus objetivos iniciais para se registrar os acertos e erros.
• Aplicar na fase de Pesquisa os fundamentos e técnicas das abordagens de
Design Centrado no Usuário da Ciência da Informação de forma a buscar
uma visão holística do usuário e uma compreensão global de suas situações
particulares de uso de informação, incluindo o antes e o depois de suas
interações com o website.
• Aplicar na fase de Concepção os fundamentos e técnicas do Design
Centrado no Usuário da Interação Humano-Computador de forma a
focalizar no usuário e nas suas tarefas desde o início do projeto a ter um
processo de design com um ciclo iterativo e interativo de definição,
validação e refinamento da solução utilizando avaliações de usabilidade.
Foram encontradas na literatura apenas três metodologias de projetos de
arquitetura de informação descritas com detalhamento suficiente que permitiu que fossem
analisadas segundo o quadro de referência
Em todas essas metodologias, a maior atenção dos autores é para com as três
primeiras fases do quadro de referência: Pesquisa, Concepção e Especificação. Para essas
fases são descritas várias técnicas e atividades.
Para a fase de Implementação os autores dedicam poucos comentários. A ausência
dessa fase pode fazer com que o website não seja implementado conforme foi especificado
pelo arquiteto de informação, inutilizando parte do seu trabalho.
A fase de Avaliação é outro ponto carente nas metodologias analisadas. Em
algumas propostas são sugeridas técnicas oriundas da Usabilidade para mensurar os
resultados dos projetos, mas os autores não detalham quais técnicas e como empregá-las.
Ainda não existe uma adaptação dessas técnicas para mensurar atributos próprios da
Arquitetura de Informação.
Considerações finais
223
Um ponto forte visto nessas metodologias é a influência da abordagem do Design
Centrado no Usuário da Interação Humano-Computador. O ciclo interativo e iterativo
sugerido nessa abordagem está presente em todas elas assim como o emprego de técnicas
de avaliação de usabilidade. Com certeza a influência dessa abordagem melhora a
qualidade dos projetos de arquitetura de informação produzindo websites mais fáceis de
usar.
Porém a abordagem de Design Centrado no Usuário da Ciência da Informação têm
pouca influência nessas metodologias. A ausência desse tipo de abordagem leva a um
conhecimento superficial das necessidades de informação dos usuários e,
consequentemente, a websites que não as atendam completamente.
Na investigação empírica foram feitas duas pesquisas de campo. A primeira
levantou o perfil do arquiteto de informação das listas de discussão brasileiras e retratou
um profissional jovem, que vive nos grandes centros metropolitanos do país e que ainda
está descobrindo seu campo de trabalho. É um profissional com alto grau de instrução,
formação predominante na área de humanas e que desenvolveu seus conhecimentos sobre
Arquitetura de Informação de maneira autodidata.
Entre as atividades que desempenha, esse profissional se concentra mais naquelas
relacionadas às fases de Pesquisa, Concepção e Especificação. Pouca atenção é dedicada a
fase de Implementação e Avaliação, confirmando a investigação teórica.
Quase metade deles não segue qualquer metodologia em seus projetos. Entre os
que seguem, a maioria utiliza metodologias próprias desenvolvidas com base em suas
experiências e estudos autodidatas.
O arquiteto de informação brasileiro carece de uma formação mais multi-
disciplinar que equilibre as áreas de Exatas e Humanas, de cursos de formação sobre
Arquitetura de Informação e de uma metodologia de projetos para orientar o seu trabalho.
Segundo LATHAM (2002) são necessários três componentes para se legitimar
uma profissão: estabelecer uma metodologia, desenvolver um corpo teórico que suporte
essa metodologia e desenvolver um sistema de educação para formar futuros profissionais.
Centrando a Arquitetura de Informação no usuário
224
Assim, a falta de cursos e o alto número de profissionais que não seguem uma
metodologia compromete a legitimação da profissão de arquiteto de informação no Brasil.
A segunda pesquisa levantou as dificuldades que os profissionais de arquitetura de
informação enfrentam nos seus projetos e quais técnicas e metodologias utilizam para
superá-las. Nela foi observado que os arquitetos de informação experientes adotam uma
metodologia nos seus projetos e, apesar das diferenças de nomenclaturas e atividades,
existe muita similaridade entre elas. Essa pesquisa também validou na prática o quadro de
referência formulado na investigação teórica.
Na análise dessas metodologias pelo quadro de referência foi possível encontrar
atividades que correspondem a cada uma das suas fases: Pesquisa, Concepção,
Especificação, Implementação e Avaliação.
A análise da fase de Pesquisa nas metodologias pesquisadas na prática mostrou que
raramente são feitas pesquisas diretas com os usuários tornando os projetos mais centrado
na empresa contratante, o que demonstra que essas metodologias não seguem a abordagem
de Design Centrado no Usuário da Ciência da Informação, confirmando a investigação
teórica.
Na fase de Concepção não foi observada uma separação clara da fase anterior. O
arquiteto lidera essa fase, mas conta com a ajuda de outros profissionais para gerar idéias e
validar sua soluções. A maioria das técnicas empregadas nessa fase são para geração de
idéias e utilizadas para definir os conceitos e as regras dos quatro sistemas que compõem a
arquitetura de informação do website. Poucos testes de usabilidade são realizados dado
que não se consegue convencer os contratantes da importância desses testes e também por
não haver pleno domínio das técnicas mais adequadas à Arquitetura de Informação. Isso
demonstra que as metodologias vistas na prática seguem pouco a abordagem de Design
Centrado no Usuário da Interação Humano-Computador.
Também não existe uma separação clara da fase de Especificação daquela que a
antecede. Nessa fase o arquiteto de informação continua a ser o principal ator, mas conta
com o auxílio das áreas de projeto gráfico e tecnologia de informação. Foi observado que
Considerações finais
225
na prática são produzidos os mesmos documentos vistos na investigação teórica: o
sitegrama, o fluxo de navegação e os wireframes.
Existe pouca preocupação com a fase de Implementação, como ocorre com as
metodologias analisadas na investigação teórica. Isso pode ocasionar websites que são
implementados sem seguirem corretamente as especificações do arquiteto de informação.
Também existe pouca preocupação com a fase de Avaliação, confirmando a
investigação teórica. Quando existe essa fase, ela fica inteiramente a cargo da empresa
contratante e raramente o arquiteto tem acesso aos relatórios de avaliação. Falta uma
posição pró-ativa dos arquitetos de informação em solicitar avaliações aos seus
contratantes.
Com relação as dificuldades levantadas na segunda pesquisa de campo, foi
observado que a maioria delas tem em comum o foco o contratante e ocorrem mais na fase
de Concepção.
Na fase de Pesquisa três dificuldades foram apontadas: definir o objetivo do
website, obter acesso as fontes de informação e produzir um documento conciso expondo
os pontos negativos do website do contratante sem gerar antipatias. Para superá-las, o
arquiteto emprega sua criatividade, iniciativa e o domínio de técnicas de apresentação. Ele
também pode participar do planejamento estratégico do website, embora não seja sua
atribuição e não tenha todas as habilidades necessárias.
Já na fase de Concepção foram apontadas quatro dificuldades distintas: integrar o
website com sistemas legados, evitar usar no website a linguagem e a organização interna
do contratante, atender a públicos-alvos diferentes e atender vários decisores. Para superá-
las o arquiteto realiza pesquisa de boas práticas e referências, estudos de cenário, análises
heurística, testes de usabilidade, envolve a área de tecnologia de informação e o
contratante com o projeto, negocia e tem uma atitude de humildade perante os demais
membros do time de projeto.
Por fim na fase de Especificação apenas duas dificuldades foram apontadas: fazer
o contratante compreender os documentos de especificação e gerenciar um volume grande
Centrando a Arquitetura de Informação no usuário
226
desses documentos. Para superar a primeira dificuldade, o arquiteto precisa alfabetizar o
seu leitor ou criar uma linguagem para ele. Já segunda dificuldade ainda não é totalmente
superada. Falta para o arquiteto de informação ferramentas de software, especialmente
ferramentas CASE, que automatizem a produção e o gerenciamento dos seus documentos.
Com relação as estratégias temos que para as dificuldades com foco no contratante
a negociação e o envolvimento do contratante são as mais adotadas com bastante sucesso.
Nas dificuldades com foco no próprio trabalho de arquitetura de informação as estratégias
evidenciaram diversas habilidades necessárias aos arquitetos de informação: paciência,
determinação, habilidade em apresentar o seu trabalho, criatividade e iniciativa. Por fim
nas dificuldades com foco no contexto tecnológico, as estratégias se basearam na pesquisa
de soluções e na negociação com a área de tecnologia de informação, porém não foram
completamente eficientes.
De forma geral, ainda não existe por parte dos contratante uma compreensão da
metodologia de projetos de arquitetura de informação e da importância de cada atividade.
Com isso atividades essenciais são suprimidas ou não é dado o prazo adequado para
executá-las. Os testes de usabilidade são as atividades mais sacrificadas. Resta aos
arquitetos de informação usar sua criatividade, iniciativa e habilidade de negociação para
conseguir produzir websites de qualidade.
As metodologias de projetos de Arquitetura de Informação precisam evoluir e
realmente adotar abordagens de Design Centrado no Usuário para alcançarem o objetivo a
que se propõem: satisfazer as necessidades de informação dos usuários. Na adoção da
abordagem da Interação Humano-Computador é preciso melhorar o domínio das técnicas
mais adequadas à Arquitetura de Informação e conscientizar os contratantes da
importância de utilizá-las. Já para adotar a abordagem da Ciência da Informação é preciso
pesquisar formas de aplicar seus fundamentos e métodos na fase de Pesquisa, porque nesse
ponto a literatura se mostrou carente.
Também é preciso pesquisar técnicas de avaliação dos resultados dos projetos
próprias da Arquitetura da Informação para que os arquitetos possam avaliar se seus
projetos realmente conseguiram satisfazer as necessidades dos usuários
Considerações finais
227
E para legitimar a Arquitetura de Informação enquanto profissão é preciso que
aumente o interesse das instituições de ensino sobre o tema, de modo a que criem cursos
para formar arquitetos de informação. A formação autodidata que esses profissionais têm
adotado, devido a falta de alternativas, não tem se mostrado eficiente.
Crê-se que a importância desse trabalho não está apenas em consolidar e unificar
as metodologias de projetos de arquitetura de informação de modo que essas possam
evoluir e auxiliar na legitimação de uma nova profissão. A sua importância está em
auxiliar na busca de uma forma de trabalho que permita aos arquitetos de informação
realmente criarem websites centrados no usuário.
Centrando a Arquitetura de Informação no usuário
228
Referências
229
Capítulo 7
Referências
As referências desse trabalho estão resumidas e disponíveis para consulta no
website www.guilhermo.com.
ABDALLA, E. A seleção da metodologia da pesquisa por mestrandos em
Biblioteconomia e Ciência da Informação. São Paulo, 2003. Dissertação (Mestrado) –
Escola de Comunicações e Arte, Universidade de São Paulo.
ALMEIDA, R. ; OLIVEIRA, M. Mirando Resultados. São Paulo: Novatec, 2002.
ALONSO, J. ; MARTÍNEZ, L. Medios Interactivos: Caracterización y contenidos, In:
NOCI, J. ; ALIAGA, R. Manual de Radacion Ciperperiodista. Barcelona: Ariel, 2003,
cap. 6, p. 261-305.
ANTUNES, L. O texto tridimensional. São Paulo, Dissertação (Mestrado), Escola de
Comunicações e Artes, Universidade de São Paulo, 1998.
BARDIN, L. Análise de Conteúdo. Lisboa: Edições 70, 2000. p. 27-46, 93-150.
Centrando a Arquitetura de Informação no usuário
230
BELTON, K. A Design Foundation for Information Architecture. In: MORROGH, E.
Information Architecture: An Emerging 21st Century Profession. New Jersey:
Prentice Hall, 2003, cap. 22, p. 143-153.
BRINCK, T.; GERGLE, D. ; WOOD, S. Usability for the Web: Designing web sites that
work. San Francisco: Morgan Kaufmann, 2002.
BUSTAMANTE, A. Arquitectura de Información y usabilidad: nociones básicas para
los professionales de la información, 2004. Disponível em:
http://www.bvs.sld.cu/revistas/aci/vol12_6_04/aci04604.htm. Acesso em: 14 out 2005.
CAMPO,M.; GOMES, H. ; MOTTA, D., Elaboração de Tesauro Documentário. Biti,
2004. Disponível em: http://www.conexaorio.com/biti/tesauro/. Acesso em: 4 jan 2005.
CASTELLS, M. Internet e sociedade em rede. In: MORAES, D. (Org.). Por uma outra
comunicação. Rio de Janeiro: Record, 2003, p. 255-288.
CHEUK, B. ; DERVIN, B. A Qualitative Sense-Making Study of the information seeking
situations faced by professionals in three workplace contexts. EJC/REC, v. 9, n. 2,3,4,
1999. Disponível em: http://communication.sbs.ohio-state.edu/sense-
making/art/artabscheukdervin99ejoc.html. Acesso em: 11 out 2005.
CHIOU, F. We are all connected: The path from Architecture to Information
Architecture. Boxes and arrows, 2003. Disponível em:
http://www.boxesandarrows.com/archives/we_are_all_connected_the_path_from_architec
ture_to_information_architecture.php. Acesso em: 25 out 2005.
CNPQ. Diretório dos Grupos de Pesquisa no Brasil , 2006. Disponível em:
http://dgp.cnpq.br/buscaoperacional/. Acesso em: 15 out 2006.
COPPER, A. About Face: The Essencials of User Interface Design. Foster City:IDG
Books, 1995.
Referências
231
COOPER, A. ; REIMANN, R. About Face 2.0: The Essencials of User Interface
Design. Indianapolis:WILEY, 2003.
DEL NERO, H. O Sítio da Mente. São Paulo:Collegium Cognitio, 1997.
DERVIN, B. An overview of Sense-Making research: concepts, methods and results
to date. In: International Communications Association Annual Meeting. Dallas, 1983.
DERVIN, B. From the Mind’s Eye of the User: The Sense-Making Qualitative-
Quantitative Methodology. In: GLAZIER, J. ; POWELL, R. Qualitative Research in
Information Management. Englewood: Libraries Unlimited, 1992. cap. 6, p. 61-84.
Disponível em: http://communication.sbs.ohio-state.edu/sense-
making/art/artabsdervin92powell.html. Acesso em: 11 out 2005.
DERVIN, B. Chaos, Order, and Sense-Making: A proposed theory for information design.
In JACOBSON, R. ed. Information Design. Cambridge: MIT Press, 1997. Disponível
em: http://alexia.lis.uiuc.edu/gslis/allerton/95/dervin.draft.html. Acesso em: 22 out 2005.
DERVIN, B. ; NILAN, M. Information needs and uses. Annual Review of Information
Science and Technology (ARIST). vol. 21, pp 3-33, New York: Knowledge Industry
Publications, 1986.
DIJCK, P. Information Architecture for Designers. Hove:RotoVision, 2003.
DUBOIS, J. et al. Dicionário de Lingüística. Cultrix, 1993.
EDWARDS, D. ; HARDMAN, L. Lost in Hyperspace: cognitive mapping and navigation
in a hypertext enviroment in Hypertext: theory into practice, Oxford:Intellect, 1993.
EWING, C.; MAGNUSON, E. ; SCHANG, S. Information Architecture Proposed
Curriculum. www.gslis.utexas.edu, 2002. Disponível em:
http://www.gslis.utexas.edu/~iag/resources/ia-curriculum-final.PDF.
Acesso em: 18 jul 2005.
Centrando a Arquitetura de Informação no usuário
232
FAST, K.; LEISE, F. ; STECKEL, M. Creating a Controlled Vocabulary. Boxes and
Arrows, 2003. Disponível em:
http://www.boxesandarrows.com/archives/creating_a_controlled_vocabulary.php.
Acesso em: 25 out 2005.
FELDMAN, S. ; SHERMAN, C. The high cost of not finding information. IDC, 2001.
Disponível em:
http://www.kmworld.com/publications/magazine/index.cfm?action=readarticle&Article_I
D=1725&Publication_ID=108. Acesso em: 22 out 2005.
FERREIRA, S. Redes eletrônicas e necessidades de informação: Abordagem do
Sense-Making para estudo de comportamento de usuários do Instituto de Física da
USP. São Paulo, Tese (Doutorado), Escola de Comunicações e Artes, Universidade de
São Paulo, 1995.
FERREIRA, S. Estudos de Necessidades de Informação: dos paradigmas tradicionais
à abordagem Sense-Making, ABEBD, 1997. Disponível em:
http://www.eca.usp.br/nucleos/sense/textos/sumar.htm. Acesso em: 11 out 2005.
FLEMING, J. Web Navigation: Designing the User Experience. Sebastopol:O'Reilly,
1998.
FRASER, J. Taking a content inventory. New Architect, 2001. Disponível em:
http://www.webtechniques.com/archives/2001/10/fraser/. Acesso em: 01 out 2004.
FRIEDMAN, K. Creating design knowledge: from research into practice. IDATER,
2000. Disponível em:
http://www.lboro.ac.uk/departments/cd/docs_dandt/idater/downloads00/Friedman2000.pdf.
Acesso em: 13 out 2005.
FRIEDMAN, K. Theory construction in design research: criteria, approaches, and
methods. Design Studies, v.24, p.507-522, 2003. Disponível em:
http://w3.msi.vxu.se/~per/DVM752/Friedman.pdf. Acesso em: 13 out 2005.
Referências
233
FUVEST (2006) Manual do Candidato FUVEST 2007 , 2006. Disponível em:
http://www.fuvest.br/vest2007/manual/manual.stm. Acesso em: 17 dez 2007
GARCÍA, L. Interação Ser Humano-Computador: Marco Teórico e Implicações no
Design de Interfaces-Usuários, 2003. Material didático.
GARCÍA, X. Retórica del Hipertexto Periodístico, In: Noci, J. ; Aliaga, R. Manual de
Radacion Ciperperiodista. Barcelona: Ariel, 2003, cap. 9, p. 385-422.
GARRETT, J. A visual vocabulary for describing information architecture and
interaction design. JJG.NET, 2002. Disponível em: http://www.jjg.net/ia/visvocab/
Acesso em: 25 out 2005
GARRETT, J. (b) The Psycology of Navigation. 2002. Disponível em:
http://www.digital-web.com/articles/the_psychology_of_navigation/.
Acesso em: 4 jan 2005.
GARRETT, J. Um vocabulário visual para AI e Design de Interação. Afifa, 2004.
Disponível em: http://aifia.org/pt/translations/000332.html. Acesso em: 24 fev 2005.
GIL, A. Métodos e técnicas de pesquisa social. 5 ed. São Paulo: Atlas, 1999.
HAVERTY, M. Information Architecture without internal theory: An inductive design
process. Journal of the American Society for Information Science and technology,
v. 53 n. 10, p. 839-845, 2002.
HOOLEY, G. ; SAUNDERS, J. Posicionamento Competitivo, São Paulo:Makron, 1996.
HORTON, W. O Livro do Ícone. São Paulo:Berkeley, 1994.
IMMACOLATA, M. Pesquisa em comunicação. Loyola, 2003.
INFORMATION ARCHITECTURE INSTITUTE About Us. 2005. Disponível em:
http://iainstitute.org/pg/about_us.php. Acesso em: 10 out 2005.
Centrando a Arquitetura de Informação no usuário
234
INSTONE, K. Navigation Stress Test, 2003. Disponível em: http://user-
experience.org/uefiles/navstress/. Acesso em: 4 jan 2005.
INSTONE, K. Location, Path & Attribute Breadcrumbs. User-experience.org, 2004.
Disponível em: http://user-experience.org/uefiles/breadcrumbs/. Acesso em: 26 abr 2005.
JACOB, E. ; SHAW, D. Sociocognitive Perspectives on Representation. Annual Review
of Information Science and Technology (ARIST). v. 33, p. 131-185, New York:
Knowledge Industry Publications, 1988.
KOTLER, P. Administração de Marketing. 5ed. São Paulo: Atlas, 1998.
LAKOFF, G. Women, Fire, and Dangerous Things. University Of Chicago Press, 1990.
LARA FILHO, D. O fio de Ariadne e a arquitetura da informação na WWW. DataGrama
Zero, 2003, v.4, n.6, dez/03. Disponível em: http://www.dgzero.org/dez03/Art_02.htm.
Acesso em: 4 jan 2005.
LARIÚ, N. Dicionário de Baianês. 2ed, São Paulo:Inovação, 1992.
LATHAM, D. Information Architecture: Notes toward a new curriculum. Journal of the
American Society for Information Science and Technology, v. 53, n. 10, p. 824-830,
2002.
LIMA, G. Interfaces entre a ciência da informação e a ciência cognitiva. Ciência da
Informação, v. 32, n. 1, p. 77-87, 2003.
LINE, M. Draft definitions: information and library needs, wants, demands and uses.
ASLIB Proceedings, v.26, n.2, 1974.
MARCOS, J. El periodismo ante la tecnología hipertextual, In: Noci, J. ; Aliaga, R.
Manual de Radacion Ciperperiodista. Barcelona: Ariel, 2003, cap. 5, p. 231-259.
Referências
235
MARCUS, A. Return on Investment for Usable User - Interface Design: Examples
and Statistics. AM+A, 2002. Disponível em:
http://www.amanda.com/resources/ROI/AMA_ROIWhitePaper_28Feb02.pdf. Acesso em:
13 jul 2005.
MARQUES, S. Interfaces Homem-Máquina: Interação ou Integração?. São Paulo,
Monografia (Mestrado), Faculdade de Filosofia, Letras e Ciências Humanas, Universidade
de São Paulo, 1995.
MARTINEZ, M. Um método de web design baseado em usabilidade. Tese
(Doutorado), Escola Politécnica da Universidade de São Paulo, 2002.
MAURER, D. ; WARFEL, T. Card sorting: a definitive guide. Boxes and Arrows, 2004.
Disponível em:
http://www.boxesandarrows.com/archives/card_sorting_a_definitive_guide.php.
Acesso em: 27 abr 2005.
McDOWELL, S. Visio Replacement? You Be the Judge. Boxesandarrows, 2006.
Disponível em: http://www. boxesandarrows. com/ view/ visio_ replaceme.
Acesso em: 16 jan 2007.
McKNIGHT, C; DILLON, A. ; RICHARDSON, J. Hypertext in Context. Cambridge
University Press, 1991.
MELLY, M Como Projetar, 2003. Material didático. Disponível em:
http://www.eca.usp.br/prof/mylene/grad/disciplinas/metodologia/metodologia.htm.
Acesso em: 25 jan 2007.
MELLY, M.; FERREIRA, S.; GARCIA, M. ; REIS, G. Ciencias de la información y de la
computación: uma visión integrada del diseño de sistemas virtuales de búsqueda directa de
información centrados em el usuario. In: IV Coloquio Internacional de Ciencias de la
Documentación y VI Congresso del Capítulo Español de ISKO, 2003.
MOLINARI, L. Testes de Software. São Paulo: Érica, 2003.
Centrando a Arquitetura de Informação no usuário
236
MORGAD, L. Estilos de navegação no hipertexto: aspectos da construção do número
na criança em Jean Piaget, 1994. Disponível em:
http://www.niee.ufrgs.br/ribie98/CONG_1994/VOLUME_II/C35/II_48_65.HTML.
Acesso em: 25 out 2005.
MORROGH, E. Information Architecture: An Emerging 21st Century Profession.
New Jersey: Prentice Hall, 2003.
MORVILLE, P. Bottoms Up, 2002. Disponível em:
http://www.newarchitectmag.com/documents/s=7733/na1202b/index.html. Acesso em: 12
nov 2004.
MORVILLE, P. Information Architecture Conference. Paris:Information Today, 2004.
(palestra) Disponível em: http://www.infotoday.com/iaparis/programme.shtml.
Acesso em: 18 mai 2005.
MORVILLE, P. O uso estratégico da Arquitetura de Informação, São Paulo:
TerraForum, 2005. (palestra). Disponível em:
http://www.semanticstudios.com/events/brazilia.ppt. Acesso em: 29 jan 2006.
NETCRAFT. Web Server Survey, 2005. Disponível em:
http://news.netcraft.com/archives/web_server_survey.html. Acesso em: 13 out 2005.
NIELSEN, J. Projetando Websites. Rio de Janeiro: Campus, 2000.
NIELSEN, J.; et al. E-Commerce User Experience. Fremont: Nielsen Norman Group,
2001.
NOCI, J. ; SALAVERRÍA, R. Hipertexto Periodístico: Teoría y Modelos, In: Noci, J. ;
Aliaga, R. Manual de Radacion Ciperperiodista. Barcelona: Ariel, 2003, cap 2, p. 81-
139.
NORMAN, D. Cognitive Engineering In: User-Centered System Design: new
perspectives on Human-Computer Interaction. Lawrence Erlbawn, 1986.
Referências
237
NORMAN, D. Emotional Design: Why We Love (Or Hate) Everyday Things . New
York: Basic Books, 2003.
OJAKAAR, E. ; SPOOL, J. Getting Them to What They Want. UIE, 2001. Disponível
em: http://www.uie.com/reports/what_they_want/. Acesso em: 25 out 2005.
PORTER, M. Estratégia Competitiva. 18ed. Rio de Janeiro:Campus, 1986.
PRESSMAN, R. Engenharia de Software. São Paulo:MAKRON Books, 1995.
PROJECT MANAGEMENT INSTITUTE, Um guia do conjunto de conhecimentos em
gerenciamento de projetos (Guia PMBOK). 2004.
REISS, E. Pratical Information Architecture. Addison-Wesley Professional, 2000.
ROSENFELD, L. More Diagrams from Jess and Me. LouisRosenfeld.com, 2001.
Disponível em: http://louisrosenfeld.com/home/bloug_archive/000045.html.
Acesso em: 17 jul 2005.
ROSENFELD, L. User Experience Education. LouisRosenfeld.com, 2005. Disponível
em: http://louisrosenfeld.com/home/bloug_archive/000341.html. Acesso em: 17 jul 2005.
ROSENFELD, L. ; MORVILLE, P. Information Architecture for the Word Wide
Web. 2ed. Sebastopol: O'Reilly, 2002.
ROSENFELD, L. ; MORVILLE, P. Information Architecture for the Word Wide
Web. 3ed. Sebastopol: O'Reilly, 2006.
ROSENFELD, L. ; MORVILLE, P. (b) Polar Bear Book, Third Edition, Survey 3:
Software for IA. Information Architecture Institute, 2006. Disponível em:
http://iainstitute.org/documents/research/results/polar_bear_survey_3.html.
Acesso em: 22 jan 2007.
Centrando a Arquitetura de Informação no usuário
238
SATO, F. ; HASHIMOTO, M. Excesso de Informação. Informação, Comunicação e a
Sociedade do Conhecimento, 2004. Disponível em:
http://conhecimento.incubadora.fapesp.br/portal/trabalhos/2004/ExcessoDeInformacao.
Acesso em: 08 jan 2007.
SAUSSURE, F. Curso de lingüística geral. Cultrix, cap. 1 e 2, 1995.
SEYBOLD, P. Clientes.com. Makron, 2000.
SHIPLE, J. Information Architecture Tutorial. Webmonkey, 2000. Disponível em:
http://webmonkey.wired.com/webmonkey/design/tutorials/tutorial1.html.
Acesso em: 29 jan 2005.
SILVA, J.; FERREIRA, M. ; BORGES, M. Análise metodológica dos estudos de
necessidades de informação sobre setores industriais brasileiros: proposições. Ci. Inf.
Brasília, v. 31, n. 2, p. 129-41, maio/agosto, 2002. Disponível em:
http://www.ibict.br/cienciadainformacao/include/getdoc.php?id=489&article=201&mode=
pdf. Acesso em: 11 out 2005.
SNYDER, C. Paper Prototyping: The fast and easy way to design and refine user
interfaces. Morgan Kaufmann, 2003.
SOUZA, R. Get ROI from Design. FORRESTER, 2001. Disponível em:
http://www.forrester.com/ER/Research/Report/Summary/0,1338,11180,00.html.
Acesso em: 13 out 2005.
TAYLOR, A. The Organization of information. Englewood: Libraries Unlimited, 1999.
TOUB, S. Evaluating Information Architecture: A practical guide to assessing web site
organization. ACIA, 2000. Disponível em: http://argus-
acia.com/white_papers/evaluating_ia.pdf. Acesso em: 4 jan 2005.
Referências
239
UNIVERSITY OF CALIFORNIA AT BERKELEY, How Much Information ? 2003.
2003. Disponível em: http://www.sims.berkeley.edu/research/projects/how-much-info-
2003/index.htm. Acesso em: 16 jan 2005.
USABILITY NET International standards for HCI and usability, 2003. Disponível
em: http://www.hostserver150.com/usabilit/tools/r_international.htm.
Acesso em: 11 out 2005.
VIVINDECE RESEARCH, A Tangled Web. E-Tailer's Digest, 2001. Disponível em:
http://www.etailersdigest.com/resources/Specials/Tangled_Web.htm.
Acesso em: 16 jan 2005.
WEST, A. The Art of Information Architecture. iBoost, 1999. Disponível em:
http://www.iboost.com/build/backend/arch/644.htm. Acesso em: 29 jan 2005.
WILSON, T. Recent trends in user studies: action research and qualitative methods,
Information Research, v. 5, n. 3, abril, 2000. Disponível em: http://informationr.net/ir/5-
3/paper76.html. Acesso em: 11 out 2005.
WITHROW, J. Cognitive Psycology & IA: From Theory to Practice. Boxes and
Arrows, 2003. Disponível em:
http://www.boxesandarrows.com/archives/cognitive_psychology_ia_from_theory_to_prac
tice.php Acesso em: 25 out 2005.
WURMAN, R. Ansiedade de Informação. São Paulo: Cultura, 1991.
WURMAN, R. Information Architects. New York: Graphis, 1997.
WODTKE, C. Information Architecture: Blueprints for the web. Indianapolis: New
Riders, 2003.
YOURDON, E. Análise Estruturada Moderna. Campus, 1990.
Centrando a Arquitetura de Informação no usuário
240
Anexo I - Questionário da pesquisa on-line
241
Anexo I
Questionário da pesquisa on-line
A seguir estão apresentados a carta convite, enviada por e-mail e o questionário
on-line utilizado na pesquisa de levantamento do perfil do arquiteto de informação das
listas de discussão brasileiras.
• Carta convite
Prezado(a) Sr.(a)
Venho convidá-lo(a) a participar da pesquisa acadêmica que estou desenvolvendo como parte do meu
mestrado em Ciência da Informação na ECA/USP, sob orientação da Profa. Dra. Sueli Mara S. P. Ferreira,
e que tem como objetivo conhecer o perfil e as experiências vividas pelos profissionais brasileiros que
trabalham com Arquitetura de Informação.
Para tanto elaborei um questionário eletrônico, com tempo estimado de preenchimento de 10 minutos. Para
participar, basta clicar acessar o endereço www.guilhermo.com/questionario
As respostas serão mantidas em anonimato e utilizadas apenas para a pesquisa em foco.
Os participantes serão comunicados quando os resultados forem divulgados e receberão acesso a uma
versão eletrônica do mesmo
Desde já agradeço a sua participação.
Abraços,
............................... Guilhermo
Centrando a Arquitetura de Informação no usuário
242
• Questionário
Esse questionário foi disponibilizado na URL www.guilhermo.com/questionario.
Ao acessar essa URL, era apresentada ao usuário uma página com as instruções de
preenchimento e duas páginas com as perguntas. Na primeira página estavam as perguntas
destinadas a todos os entrevistados e na segunda página estavam as perguntas exclusivas
aos profissionais. Essas páginas estão apresentadas a seguir juntamente com os
comentários das perguntas.
Figura 14 – Questionário on-line - Instruções para o preenchimento
Figura 15 - Questionário on-line - Perguntas comuns a todos os entrevistados
Questões destinadas a identificar o
entrevistado de modo a garantir que uma
mesma pessoa não responda ao questionário
duas vezes.
Questões para o levantamento do perfil
demográfico do entrevistado.
Identifica o interesse em Arquitetura de
Informação do entrevistado, que pode ser
Pesquisa, Profissional ou ambos. Caso o
entrevistado não tenha interesse profissional,
ele não responde as questões da página
seguinte.
Identificação do grau de instrução do
entrevistado, utilizada para definir sua
escolaridade.
Questões destinadas a identificar o
entrevistado de modo a garantir que uma
mesma pessoa não responda ao questionário
duas vezes.
Questões para o levantamento do perfil
demográfico do entrevistado.
Identifica o interesse em Arquitetura de
Informação do entrevistado, que pode ser
Pesquisa, Profissional ou ambos. Caso o
entrevistado não tenha interesse profissional,
ele não responde as questões da página
seguinte.
Identificação do grau de instrução do
entrevistado, utilizada para definir sua
escolaridade.
Anexo I - Questionário da pesquisa on-line
243
Figura 16 - Questionário on-line - Perguntas exclusivas aos profissionais
Identifica a escolaridade do entrevistado.
Foram apresentados apenas os campos de
curso e instituição correspondentes ao grau
de instrução do entrevistado, respondido na
página anterior.
Identifica a empresas, o cargos e a formas de
contratação do entrevistado.
Avalia o grau de experiência do entrevistado
com Internet e Arquitetura de Informação.
Identifica como ocorreu o
aprendizado da Arquitetura de
Informação para o entrevistado.
As opções são: Aprendi na
empresa, Autodidata, Fiz curso
sobre o tema (qual curso?) e
Outro (qual?).
Identifica quais são as atividades
relacionadas à Arquitetura de Informação
executada pelo entrevistado.
Identifica se o entrevistado segue alguma
metodologia de projetos de arquitetura de
informação.
Espaço livre para o entrevistado fazer
quaisquer comentários que julgar relevante.
Identifica a escolaridade do entrevistado.
Foram apresentados apenas os campos de
curso e instituição correspondentes ao grau
de instrução do entrevistado, respondido na
página anterior.
Identifica a empresas, o cargos e a formas de
contratação do entrevistado.
Avalia o grau de experiência do entrevistado
com Internet e Arquitetura de Informação.
Identifica como ocorreu o
aprendizado da Arquitetura de
Informação para o entrevistado.
As opções são: Aprendi na
empresa, Autodidata, Fiz curso
sobre o tema (qual curso?) e
Outro (qual?).
Identifica quais são as atividades
relacionadas à Arquitetura de Informação
executada pelo entrevistado.
Identifica se o entrevistado segue alguma
metodologia de projetos de arquitetura de
informação.
Espaço livre para o entrevistado fazer
quaisquer comentários que julgar relevante.
Centrando a Arquitetura de Informação no usuário
244
Anexo II - Roteiro da entrevista individual
245
Anexo II
Roteiro da entrevista individual
Para a pesquisa de levantamento das dificuldades, técnica e metodologias
encontradas em projetos de arquitetura de informação de websites foi elaborado o roteiro
de entrevista apresentado abaixo.
Instruções
Primeiro gostaria de agradecê-lo(a) por participar dessa pesquisa e dedicar o seu
tempo. Como eu lhe disse no convite, eu estou fazendo uma pesquisa sobre a forma de
trabalho dos arquitetos de informação no Brasil. Para isso vou entrevistar alguns
profissionais com o intuito de detalhar como vocês trabalham.
Tudo que você disser vai ser usado apenas para essa pesquisa. Nos relatórios finais
você não vai ser identificado, nem qualquer projeto ou pessoa que você citar. Por isso,
quero que você se sinta bem à vontade para comentar tudo que quiser.
Eu estou filmando apenas para facilitar as minhas anotações. Essa fita e a sua
imagem não serão divulgadas sem a sua autorização.
Vamos começar.
Centrando a Arquitetura de Informação no usuário
246
Identificação do entrevistado
1. Nome:
2. Empresa onde trabalha:
3. Cargo:
4. Grau de Instrução:
5. Há quantos anos você trabalha com Arquitetura de Informação. Como foi que você
começou a trabalhar nessa área? Conte resumidamente a sua história.
6. Como você aprendeu Arquitetura de Informação?
Fase I - Levantamento da metodologia
7. O que você faz exatamente na sua empresa? Quais são as suas responsabilidades?
8. Quais são as atividades que compõem um projeto de arquitetura de informação na sua
empresa?
9. Eu escrevi cada uma dessas atividades em um cartão. Por favor, coloque-as na
seqüência que vocês costumam executá-la em um projeto de arquitetura de informação
na sua empresa.
10. [Se a quantidade de atividades for grande (maior que 15)] Agora, por favor, agrupe
essas atividades em fases. Você consegue dividir todas essas atividades nas fases de
um projeto?
11. Qual é o nome de cada uma dessas fases?
12. Essa divisão em fases existe na sua empresa?
Anexo II - Roteiro da entrevista individual
247
( ) Sim ( ) Não
13. Você concorda com essa seqüência de atividades e fases? Por quê?
( ) Sim ( ) Não
14. Existe na sua empresa alguma documentação dessas atividades e fases? Algum manual
de processos e procedimentos?
( ) Sim ( ) Não
15. Existe alguma atividade relativa à Arquitetura de Informação que vocês não fazem na
sua empresa e você acha que deveriam fazer?
Fase II – Análise das dificuldades de um projeto
16. Quantos projetos na sua empresa seguem todas essas fases?
17. Por que alguns projetos não seguem todas essas fases?
18. Você tem um projeto em que você participou e que seguiu todas essas fases? Qual era
esse projeto? Comente um pouco o que foi esse projeto.
19. Quais foram as grandes dificuldades desse projeto em cada uma dessas fases?
20. De todas essas dificuldades, quais foram as 3 dificuldades mais impactantes para o
sucesso do projeto?
[Para cada dificuldade]
21. Descreva essa dificuldade na forma de uma pergunta. Qual era pergunta que você tinha
que responder por causa dessa dificuldade? Qual era a pergunta que essa dificuldade
gerava?
Centrando a Arquitetura de Informação no usuário
248
22. Por que você teve essa dificuldade?
23. Por que superar essa dificuldade era importante no projeto?
24. Você conseguiu superar essa dificuldade?
( ) Totalmente ( ) Parcialmente ( ) Não conseguiu
25. Por que essa resposta?
26. [Se superou a dificuldade totalmente] Como você superou essa dificuldade?
[Se não superou a dificuldade] Mas você conseguiu superar essa dificuldade de alguma
forma? Conseguiu contornar o problema?
27. [Se superou a dificuldade totalmente ou parcialmente] Como vocês conseguiram
chegar nessa solução?
28. [Se superou a dificuldade parcialmente] Por que você não conseguiu superar a
dificuldade totalmente?
29. Você ficou satisfeito com a solução?
( ) Totalmente satisfeito ( ) Parcialmente satisfeito ( ) Insatisfeito
30. Por que essa resposta?
31. E o cliente do projeto, ele ficou satisfeito com a solução?
( ) Totalmente satisfeito ( ) Parcialmente satisfeito ( ) Insatisfeito
32. Por que essa resposta?
33. O que te ajudou a superar essa dificuldade?
Anexo II - Roteiro da entrevista individual
249
34. Se você pudesse fazer um pedido a um gênio da lâmpada de Aladim, que pedido você
faria superar essa dificuldade?
Levantamento das facilidades
35. Quais foram as facilidades que você teve nesse projeto?
36. Como essas facilidades te ajudaram?
Fase III – Comparação da metodologia do entrevistado com o modelo teórico
proposto (perguntas estimuladas)
37. Na sua empresa vocês tem uma fase de Análise/Pesquisa nos projetos de arquitetura de
informação? Existe uma fase onde vocês pesquisam os usuários, suas necessidades, a
empresa e definem o escopo e requisitos do projeto.
( ) Sim ( ) Não
Qual é essa fase?
38. Na sua empresa vocês não tem uma fase de Concepção nos projetos de arquitetura de
informação? Existe uma fase onde vocês definem as linhas gerais da solução, onde
vocês definem as regras dos sistemas de organização, de navegação, de rotulação e de
busca. Qual é essa fase?
( ) Sim ( ) Não
Qual é essa fase?
39. Na sua empresa vocês tem uma fase de Especificação nos projetos de arquitetura de
informação? Existe uma fase onde vocês detalham e documentam como o site deve ser
implementado, onde vocês geram os documentos de Arquitetura de Informação?
( ) Sim ( ) Não
Centrando a Arquitetura de Informação no usuário
250
Qual é essa fase?
40. Na sua empresa vocês tem uma fase de Implementação nos projetos de arquitetura de
informação? Existe uma fase onde vocês acompanham o trabalho de implementação
do site feito por outras áreas?
( ) Sim ( ) Não
Qual é essa fase?
41. Na sua empresa vocês tem uma fase de Avaliação nos projetos de arquitetura de
informação? Existe uma fase onde vocês avaliam os resultados do projeto?
( ) Sim ( ) Não
Qual é essa fase?
42. Vocês fazem pesquisas com usuários?
Quais?
Por que a resposta?
Considerações finais
Você tem mais algum comentário que gostaria de fazer?
Livros Grátis
( http://www.livrosgratis.com.br )
Milhares de Livros para Download:
Baixar livros de Administração
Baixar livros de Agronomia
Baixar livros de Arquitetura
Baixar livros de Artes
Baixar livros de Astronomia
Baixar livros de Biologia Geral
Baixar livros de Ciência da Computação
Baixar livros de Ciência da Informação
Baixar livros de Ciência Política
Baixar livros de Ciências da Saúde
Baixar livros de Comunicação
Baixar livros do Conselho Nacional de Educação - CNE
Baixar livros de Defesa civil
Baixar livros de Direito
Baixar livros de Direitos humanos
Baixar livros de Economia
Baixar livros de Economia Doméstica
Baixar livros de Educação
Baixar livros de Educação - Trânsito
Baixar livros de Educação Física
Baixar livros de Engenharia Aeroespacial
Baixar livros de Farmácia
Baixar livros de Filosofia
Baixar livros de Física
Baixar livros de Geociências
Baixar livros de Geografia
Baixar livros de História
Baixar livros de Línguas
Baixar livros de Literatura
Baixar livros de Literatura de Cordel
Baixar livros de Literatura Infantil
Baixar livros de Matemática
Baixar livros de Medicina
Baixar livros de Medicina Veterinária
Baixar livros de Meio Ambiente
Baixar livros de Meteorologia
Baixar Monografias e TCC
Baixar livros Multidisciplinar
Baixar livros de Música
Baixar livros de Psicologia
Baixar livros de Química
Baixar livros de Saúde Coletiva
Baixar livros de Serviço Social
Baixar livros de Sociologia
Baixar livros de Teologia
Baixar livros de Trabalho
Baixar livros de Turismo
