
A Iris Ferrera escreveu um ótimo artigo no Webinsider listando os entregáveis mais comuns na rotina de um arquiteto de informação. Gostei do jeito objetivo e descontraído com que ela descreveu os documentos – e resolvemos postar aqui também.
Não, não é uma lista definitiva. Nem aprofundada.
Mas é um ótimo checklist para ver qual o melhor tipo de entregável para cada etapa do projeto – e até para verificar se você não está se esquecendo de algum ou aproveitando pouco as vantagens oferecidas por eles.
Texto de Iris Ferrera, edições, grifos e links meus – e imagens do Google Images mesmo.
–
Durante a rotina de trabalho converso com muitas áreas em busca de “inspirações” para o projeto. E nesse papo percebo que o entendimento sobre arquitetura de informação aumentou e com ele veio a importância de protótipos na sua rotina de entregas.
Existe um valor surgindo de forma significativa sobre esta área (antes tão feia e má aos olhos de muitos), que coloca o arquiteto como um parceiro alinhado a todos os envolvidos para garantir uma entrega de sucesso.
Com este espaço ganho, agora é a vez de mostrar que o resultado de uma AI vai além de wireframes. Existem algumas metodologias (ou práticas) que podem ser inseridas na arquitetura, mas ainda estão esquecidas por vários fatores, inclusive entendimento.
Pensando nisso e também por alguns pedidos de alguns amigos e leitores, eu cataloguei alguns entregáveis que podemos gerar no estudo mais detalhado da arquitetura de um projeto com o intuito de deixar os wireframes bem mais alinhados com as necessidades do nosso cliente.
Nem tudo que estará listado precisa entrar no seu projeto, o que torna importante analisar bem a extensão, prioridades, público, mercado, tempo e expectativa do cliente.
Depois destas informações em mãos, alinhar com os modelos de métodos que mais tenham sentido. Lembrando que alguns terão custo de horas fora do ambiente de trabalho (cliente, laboratórios etc.).
Antes de começar, duas definições que devem iniciar o estudo como pequenos mantras:
Arquitetura de Informação é tornar o complexo claro.
WURMAN (1997)
Usabilidade é um conjunto de atributos que incidem sobre o esforço necessário para o uso, bem como sobre a avaliação individual de tal uso, por um indicou implícita ou conjunto de usuários.
Norma ISO 9241-11
Agora sim a lista, e eu coloco dividida em fases. Isto é apenas uma sugestão e reafirmo que cada projeto vai ter um grupo específico de entregáveis. Não adianta fazer tudo, gastar o dinheiro do seu cliente e no final se dar conta do “pleonasmo” dos insumos da Arquitetura de Informação que criou.
1ª FASE: CONCEPÇÃO
Após o “bater do martelo” (e algumas vezes antes mesmo disso acontecer), chega oficialmente a demanda para o arquiteto! Agora é hora de organizar as horas, analisar todo o material do cliente e propor para a equipe um conjunto de ações que irão culminar em uma entrega final muito mais embasada e consistente.
Esta é a fase da concepção e nela podemos envolver alguns dos seguintes passos (ou não, sinta-se à vontade para criar os seus):
Road Map
É um plano de ação, um roteiro, um passo-a-passo para o desenvolvimento de um projeto que precise de entregas faseadas, ajudando a coordenar e planejar os avanços. Além de deixar claras as datas, ajuda também a enxergar o conjunto de tecnologias que podem ser aplicadas para o projeto e o esforço necessário para cada etapa.
Benchmark
É a observação e estudo de produtos que tenham semelhança, em comportamento ou conteúdo, com o projeto que vamos desenvolver. É a análise dos pontos positivos e negativos que devem ser considerados no momento em que iremos criar o “jeitão” das telas e seus comportamentos.
Benefícios bacanas de um benchmark:
- Novo olhar sobre conceitos e padrões o que pode trazer novidades bem focadas e pertinentes com a proposta;
- Permite que o conhecimento sobre o mercado e sobre o cliente seja amplificado e consequentemente, do projeto também;
- Facilita a identificação das áreas críticas;
- Permite um olhar realista ao traçar objetivos.
Definição das Métricas de Sucesso
É uma lista do que vai ser usado para medir se o seu projeto/design/redesign atingiu os objetivos do cliente. Número de visitas? Número de seguidores no Twitter? Porcentagem de pessoas que compartilham seu conteúdo? Nessa hora vale uma boa conversa com o pessoal de Data Intelligence para definir quais métricas são importantes e possíveis de serem mensuradas. Sem essa métricas fica difícil calcular o retorno sobre investimento (ROI) do projeto.
Personas
Se a premissa é cada projeto ter um público-alvo, as personas são formatos de entender e enxergar melhor esse usuário. Pode ser uma descrição mais simples (como na imagem acima) ou detalhadíssima, com o intuito de personificar um usuário fictício dentro do público-alvo.
Esta pessoa de “mentirinha” ajuda no alinhamento das expectativas tanto do cliente quanto da equipe, sobre recursos e funcionalidades que devem estar contidas no projeto, priorização e avaliação do produto.
Criando sua pessoa, é bacana conter:
- Nome para facilitar a associação com pessoas reais;
- Características e razões para que o site seja importante para ele. Um histórico da persona, em relação às suas expectativas com o produto;
- Cenários para ambientar as condições em que a persona vai interagir com o site;
- Características de comportamento, quer emocionais, sociais ou culturais, que sejam comuns ao público representado pela persona, hábitos, linguagem e motivações.
Modelo conceitual
Normalmente é usado para representar uma visão macro de como um produto funciona do ponto de vista conceitual – sem a necessidade de entrar em detalhes sobre cada funcionalidade. Pode ser um gráfico, um parágrafo de texto ou um fluxograma – o importante é mostrar de forma simples como o produto irá funcionar. Geralmente é apresentado nas fases iniciais do projeto, para garantir o alinhamento entre as áreas.
Blueprint
Um daqueles entregáveis provindos do Service Design. Normalmente é um mapa que mostra todos os pontos de contato do seu serviço com o consumidor; e o que acontece com o usuário, com a interface e com o sistema em cada um deles.
Ecossistema
Quando um projeto é formado por diversas peças (um site, um aplicativo mobile, uma página no Facebook, um banner, um hotsite etc.), é um mapa detalhado de como esses diversos ambientes conversam entre si. Para onde você quer levar cada usuário e por quê? Qual o caminho que você espera que ele percorra?
Focus Group
É uma discussão entre um grupo geralmente pequeno sobre o produto que está sendo desenvolvido, que informa suas opiniões a respeito. No grupo existe um moderador, que direciona a conversa e garante que todos os assuntos sejam abordados. Os outros participantes são selecionados dentro do perfil do usuário do produto. O custo geralmente é baixo e pode trazer resultados interessantes focados diretamente no consumidor final.
Pesquisa Quantitativa
O famoso “responde essa pesquisa por favor”, que normalmente vem acompanhado de um link para um desses serviços de tabulação de resultados como o Survey Monkey ou o Google Docs. Ótimo para tirar uma dúvida, entender um pouco mais sobre o público-alvo ou levantar dados para justificar suas escolhas de design. O ponto negativo é que se a pesquisa não for bem elaborada, pode trazer resultados distorcidos da realidade. E se não for bem distribuído, o link pode acabar nas mãos de pessoas que não são necessariamente o público desejado. Revise oito vezes antes de enviar o link ou entregar o formulário impresso e, se possível, teste com um grupo menor antes de tornar a pesquisa pública.
Card Sorting
Esta é uma interessante técnica onde podemos entender um pouco do modelo mental do público do projeto. É normalmente usado para decidir qual a forma mais democrática de se agrupar conteúdos e qual o melhor nome a ser dado para cada um (taxonomia). Os usuários recebem um conjunto de pequenos cartões que devem ser organizados de um jeito que ele considere prático e simples, de acordo com seu próprio entendimento sobre o assunto.
Neste momento, onde pode acontecer (e deve!) uma conversa entre o usuário e o arquiteto de informação, é possível entender os motivos deste modelo de classificação. Depois de todas as escolhas, é feita uma análise dos agrupamentos mais recorrentes, que serão aplicados na tela/site em questão.
Inventário de Conteúdo
Um nome bastante autoritário mas no fundo trata-se de um cara legal. Quando no projeto, novo ou já existente, o conteúdo informativo é grande, se faz necessário ter um controle global destes textos que serão gerados para o site.
Consiste em um mapeamento de todas as páginas (previstas ou existentes) e do conteúdo de cada uma. Assim, conseguimos ver holisticamente todo o conteúdo, o que trará uma facilidade em organizar as informações (taxonomia, vocabulário controlado etc.), identificar conteúdo duplicado (muito comum em sites com grande volume de informações) e no futuro facilitar sua encontrabilidade.
Análise de Tarefas
É uma análise descritiva de como os usuários realizam tarefas utilizando o seu produto. Pode ser um passo-a-passo, uma tabela ou mesmo um documento de texto que contenha a narrativa das principais tarefas executadas. É muito útil na hora de definir quais tarefas são mais importantes e para avaliar se alguma delas está muito complicada para o usuário.
Mapa do Site
Organograma mostrando todas as páginas que o site irá conter. Este documento especifica as várias telas e mostra a relação hierárquica entre elas. Geralmente é produzido no início do projeto e refinado durante todas as etapas conforme as demandas posteriores.
Fluxograma
É um sitemap com QI acima da média onde é organizado o fluxo de informações. Desta forma é mais fácil compreender a transição das informações em cada tela. Fluxogramas são fundamentais para o olhar realista do projeto, pois além de se compreender os caminhos ainda permite encontrar fluxos mais objetivos para a visualização de determinadas seções ou telas.
Wireframes
A planta baixa do site, seu esqueleto. O resultado de pesquisas onde podem ser encontrados todos os elementos em cada tela e suas disposições e orientações. O intuito é mostrar a hierarquia das informações, das telas e o fluxo de navegação que irá existir.
O wireframe funciona melhor quando apresentado em tons de cinza, já que não há neste momento níveis de escalas ou posicionamento de elementos gráficos. O designer tem liberdade de criar um layout diferente do wireframe – desde que sejam respeitadas as organizações textuais e hierárquicas das telas.
Leia também: Como fazer wireframes do jeito certo >
Protótipos Navegáveis
São uma variação dos wireframes, mas com links entre as telas. Você pode clicar e navegar entre elas, como se estivesse navegando no produto final. Pode ser usado com diversos objetivos: desde ser exibido em um teste de usabilidade até fazer com que o público interno do projeto (desenvolvedores, gerentes de projeto, designers, cliente) visualizem mais facilmente como determinada peça vai funcionar. Hoje existem várias ferramentas que facilitam as construções desses protótipos, como o Flash Catalyst, o Microsoft SketchFlow ou o Axure.
Storyboards
Muitas vezes o produto que está sendo desenhado possui características audiovisuais muito específicas – muitas vezes incluindo ou se assemelhando a um filme. Nessa hora, muitos arquitetos preferem deixar de lado os wireframes e os protótipos navegáveis e rascunhar um storyboard da narrativa que está sendo criada. Funciona melhor tanto para quem está contando a história quanto para que o restante do time entenda (já que muitas vezes eles estão habituados a este formato, por terem trabalhado em produtoras ou agências de publicidade).
Mood Boards
Geralmente é um documento elaborado com ajuda do time de Cultural Insights, Planejamento e/ou Design, e procura reunir referências visuais do que se espera encontrar no seu site. Ajuda muito os designers a definirem qual linha visual devem seguir no projeto, baseado no universo de referências dos usuários.
2ª FASE: IMPLEMENTAÇÃO
Depois de feito o wireframe e aprovados os layouts, é a hora de testar antes de entregar para seu cliente. Abaixo a sugestão (sinta-se à vontade para discordar e criar seu próprio set) de entregáveis para esta fase:
Casos de uso, Documento de Especificação e Mensagens de Sistema
São o detalhamento de todos os cenários de uso e regras de funcionamento do sistema. Utilizados em projetos que possuem muitas variações de uso, esses documentos normalmente são escritos por um tecnólogo, que conta com a ajuda e validação do arquiteto de informação para levantar todas as situações possíveis. É importante prever soluções e mensagens (de sucesso ou de erro) para cada uma delas, para garantir que a conversa com o usuário seja consistente e eficaz independente do cenário em que ele se encontra.
Análise Heurística
É um conjunto de “boas práticas” de usabilidade que um site deve conter. Com eles podemos observar e analisar alguns pontos que ajudam a definir se o site está usável ou não. Alguns exemplos de itens que esta análise percorre:
- Visibilidade do estado do sistema;
- Correspondência entre o sistema e o mundo real;
- Controle e liberdade do usuário;
- Consistência e padronização;
- Prevenção de erros;
- Reconhecimento em vez de lembrança;
- Flexibilidade e eficiência de uso;
- Projeto estético e minimalista;
- Recuperação de erros;
- Ajuda e Documentação;
- Controle e liberdade do usuário.
Mais sobre análise heurística >
Teste de Usabilidade
São roteiros criados a partir dos fluxos existentes no protótipo ou produto, e testados com usuários reais para que possamos enxergar os pontos fortes e fracos do site, e ajustar para que a entrega esteja bem alinhada e com usabilidade eficiente.
Olhando as pessoas interagirem com o produto permite um olhar bastante claro e realista sobre as telas e sua forma de interação com o usuário, e o resultado destes testes ajuda na defesa de alguns conceitos envolvidos no projeto (quer seja pelo cliente ou equipe), desalinhados com o entendimento e necessidade do usuário.
Com os resultados em mãos, é hora de acertar os detalhes finais do produto. Ajustes e refações são comuns nessa etapa. O teste de usabilidade também pode ser feito mais no início ou mais no final do projeto, como medida constante de qualidade e adequação ao usuário final.
Leia também: Testes de usabilidade custam basicamente nada >
Controle de Qualidade (QA)
É a hora de testar os mínimos detalhes. Verificar se todos os links funcionam, se o fluxo de dados está ocorrendo corretamente e se todos os diferentes cenários de uso foram implementados e estão funcionando. O controle de qualidade normalmente é feito por uma equipe especializada, com o auxílio e orientação do arquiteto de informação.
Análise de Acessibilidade
Consiste basicamente em uma análise para verificar o nível de acessos facilitados do produto. Se está disponível e acessível a qualquer hora, local, ambiente, dispositivo de acesso e por qualquer tipo de visitante/usuário.
Também pode apontar se os usuários podem acessá-lo de diferentes sistemas operacionais e principalmente se podem ser acessadas por todos, independente de capacidade motora, visual, auditiva, mental, econômica, social ou cultural.
Recomendações de SEO (Search Engine Optimization)
São as recomendações para que o produto web seja construído nos parâmetros necessários para ser mais facilmente encontrado pelos buscadores (Google, Bing etc.). A produção desse documento normalmente exige a ajuda de alguém com conhecimento específico no assunto, como um profissional de SEO ou um programador que entenda de otimização para buscas.
3ª FASE: MONITORAMENTO
Arestas aparadas depois da bateria de testes pré-entrega, projeto finalizado com louvores e agora é só festa e férias… #claroquenao! Agora é a fase de relatórios de melhorias, análises de comportamento e resumindo a ópera: o filho precisa de cuidados depois que nasceu!
Abaixo a sugestão de algumas práticas que podem ser legais de incluir no seu set de monitoramento:
Teste de Usabilidade
Já falamos dele lá em cima… scroll para você que passou por ele e não leu… Os testes de usabilidade podem e devem continuar sendo feitos mesmo depois que o produto já foi publicado. É a melhor forma de refinar a usabilidade e promover a implementação gradual de novas funcionalidades, sempre validando com usuários reais.
Testes A/B
São testes comparativos entre duas ou mais soluções para uma mesma tela ou tarefa. O modelo clássico funciona da seguinte forma: metade dos visitantes vêem a versão A da tela, metade vêem a versão B, durante um certo período de tempo. No final, mede-se e compara-se a performance de cada uma das versões – e a melhor delas é implementada para 100% dos visitantes. Testes A/B podem acontecer de forma sucessiva e constante, para que o produto evolua sempre.
Eye Tracking
Última moda e grito da modernidade, o mapeamento do olhar do usuário sobre a interface auxilia na definição de pontos de interesse sobre conceito, layout, navegação e modelo de interação, com dados realistas para ajustar as informações da tela para que sejam mais atraentes ou fáceis de encontrar.
O entregável é um relatório que mostra quais pontos da tela foram mais olhados pelos usuários, em um modelo parecido com a imagem acima: um heatmap que mostra em cores quentes as áreas mais visualizadas da interface.
O custo de realização dos testes de eyetracking é mais alto do que os testes de usabilidade, pois são necessários equipamentos especiais para monitorar o movimento do olho do usuário.
Leia também: O que você precisa saber sobre eyetracking >
Análise de Métricas
É o olhar do arquiteto de informação sobre as métricas do projeto. Analisar os números de acesso, navegação e interação e encontrar soluções para melhora ou manutenção das telas. Se a taxa de rejeição de determinada tela está alta, talvez ela seja seu próximo alvo de melhorias de design e usabilidade.
Análise Quantitativa e Qualitativa (análise de interface)
Análise de interface quantitativa descobre o comportamento do usuário durante a navegação. Por exemplo: descobrir que todo usuário clica no logo quando quer voltar para a home ou que os usuários de uma determinada seção do site são predominantemente mulheres.
Já as análises qualitativas permitem, como no focus group, mensurar opiniões de grupos sobre o produto.
Os resultados não são apenas “este produto agrada” ou “este produto não me agrada”, mas sim os motivos dessas opiniões. Pode ser informação valiosa no desenvolvimento do projeto e depois de sua implantação.
Estes dados permitem redefinir as seções privilegiando as informações de acordo com o público ou definir premissas para um determinado projeto; onde antes só considerávamos os browsers e resoluções de tela, hoje podemos ir muito além, considerando também o perfil do usuário.
E o que mais for preciso…
Seja versátil. Adapte os seus entregáveis às necessidades de cada projeto. Evite redundâncias. Crie suas próprias variações dos documentos acima. Compartilhe-os com o time, na hora certa, e peça/aceite feedback sobre todos eles. Converse com os colegas de equipe, com gerentes, deixe que eles conheçam o arsenal de entregáveis que a AI pode produzir, insira em seus projetos e colha os louros de um resultado eficiente!
Moral da história: agora, como já diria capitão planeta, “O poder é de vocês!”.
Mas não se esqueça que com o entendimento vem o poder, e com o poder a responsabilidade. Portanto, juízo ao criar seu conjunto de entregas…
–
Bônus:

Faltou algum item na lista? Deixe um comentário com o título do item e a descrição, e vamos fazer essa lista ficar mais completa :)
Tiny URL pra você ter acesso rápido a este post quando estiver no meio de uma conversa com o gerente de projetos: http://tinyurl.com/entregaveisdeux
















Muito bom esse post, Fabrício. Esse é um sonho a seguir ainda no mercado de Salvador. Catequizar empresário e clientes da importância de seguir métodos e ter uma planejamento robusto. Mas, vamos continuar tentando!!
Discordo parcialmente da lista de entregáveis.
Wireframe detalhado é atividade de designer de interface ou de interação. Vejo muitos AIs ainda presos a wireframes detalhados, mas a evolução natural, até por conta das metodologias ágeis, é que todos passem a trabalhar com sketches/sketchboard, onde as questões visuais são abstraídas e o foco projetual está totalmente nas questões de informação e navegação.
Já Benchmark, Roadmap e Métricas de sucesso são atividades que caberiam a um Analista de produto ou Gerente de projeto/produto. Destas três, talvez o Benchmark seja a atividade híbrida em que o AI se encaixe. Mas roadmap é planejamento de projeto e métricas de sucesso é definição de negócio, não vejo Arquitetura de Informação, nestes casos.
Agora, faltam na lista, como atividades de um bom Arquiteto de Informação, a Criação de Taxonomias, Modelagem de Dados / Contexto Informacional, Monitoramento de Métricas / Comportamento de Navegação, Estudos de Busca e Recuperação de informações (information-seeking behavior), entre outros entregáveis.
Fico também em dúvida quanto à testes de Usabilidade e Avaliações Heurísticas, não sei se é papel do AI fazer tais testes ou avaliações. É mais razoável que testes sejam realizados por Analistas de Usabilidade ou similar. Mas cabe ao AI o senso crítico de analisar os resultados e propor melhorias.
Então, Bruno
Quais as atividades do AI, pra você? Fiquei curioso =]
Abraço
PS: Excelente post, Fabrício!
Pingback: Teste de usabilidade, protótipos de papel e crianças | Arquitetura de Informação
Pingback: O que é Lean UX? | Arquitetura de Informação
Complementaria com algumas idéias de um texto que escrevi há cerca de um ano atrás – http://ixdassa.posterous.com/por-que-falamos-tanto-de-metodos-e-tecnicas-e
Pingback: Como o Google atualiza o algoritmo de seu buscador | Arquitetura de Informação
Pingback: O tal do Diário de Uso Continuado #ebai | Arquitetura de Informação
Pingback: Os 5 posts mais sensação de 2011 (retrospectiva) | Arquitetura de Informação
Boa tarde!
“Felipe”, consigo entender o levantamento do “Bruno”, pois como aspirante á bibliotecária, vejo extrema necessidade de focar em taxonomia, módulos acertivos para buscas/recuperação da informação e comportamento de navegação; ferramentas que otimizam o dia a dia do usuário, principalmente quanto ao ganho de mercado, pois a informação localizada o quanto antes, é de suma importância para que as grandes empresas estejam sempre a frente dos concorrentes.
Quanto ao texto, realmente soa muito mais voltado ao profissional de TI (acho que foi isso que o “Bruno” estranhou), mas concordo com as atividades sugeridas no texto sim, pois cabe ao AI analisar a usabilidade, acompanhar as melhorias e resultados obtidos, afinal, a ideia é desenvolver da melhor forma a acessibilidade às informações e não existirá parâmetro sem avaliação/acompanhamento contínua(o).
Abraços e LUZ*
Os ícones em figura, sem pretensão a objetividade são ótimos. É como um meta wireframe do artigo, rsrs.
Concordo em partes com o Bruno também , por outro lado seu post esta bem interessante, até por que considerar essa sequência de processos, que eu chamaria de metodologia é algo extremamente interessante , visto que muitos profissionáis ignoram a existência de tais metodologias.
A única observação é que percebo que o que acontece muitas vezes é um módismo no uso de termos como o “metodologias agéis” , “arquitetura de qualquer coisa”. que acaba redefinindo algumas coisas já existentes ou já escritas anteriormente com outro nome.
Por exemplo essa parte de “arquitetura da informação”, conforme o RUP, possui seu pico de atividade na fase que ele chama de Elaboração, ou seja, após a concepção e anterior a implementação, pois definir requisitos de arquitetura durante a implementação poderia comprometer a solução ( o que infelizmente é aplicado em muitos projetos e leva aos famosos projetos não entregues de T.I. ). Ou seja essa parte de análise voltada a marketing, estudos usabilidade e interface ficariam entre as duas fases: Concepção e Elaboração.
http://edn.embarcadero.com/article/images/33319/RUP.JPG
Partindo dessa visão macro um projeto deve envolver diversas disciplinas e não somente a parte de analise no que se refere a Arquitetura da Informação nesse caso.
Nesse ponto talvez o bruno esteja querendo dizer que parece ultrapassar um pouco a disciplina quando entra em estratégia de negócio entre outros pontos.
Mas concordo também quando o Fabrício cita, que de nada adianta fazer tudo e pecar pelo excesso ou cometer o exagero de processos (burocracia). E esse é ponto totalmente criticável do RUP, pois trata-se de um conjunto de processos extremamente burocrático. O que não impede que possa ser aplicado parcialmente.
Mas como disseram é complicado aplicar isso, pois muitos clientes não têm ciência de tais metodologias e dos ganhos em um projeto e isso tudo acaba ficando no mundo das discussões nos blogs, no mundo acadêmico e sendo aplicado parcialmente em alguns projetos.
Fabrício, minha intensão com esse comentário não é a de criticar negativamente, pelo contrário, achei interessante a sua proposta de demonstrar que essa parte de definição não consiste apenas em entregar layout e o cliente achar isso bonito.. rsrs e sim que existem metodologias e que existe um papel arquitetura para tentar controlar e evitar que os projetos não sejam terminados, ou que não atendam as expectativas chegando a um insucesso.
Muito Bom POST ! só citei o RUP, como uma referência que abrange a mesma questão porém com um ponto de vista mais amplo, no sentido que existem outras disciplinas envolvidas. Pois se analisarmos desse ponto de vista verão que arquitetura de informação não deve ser algo distante da parte de T.I ( Arquitetura de Software ) e que na verdade devem trabalhar juntas em cima de um mesmo produto ( um site, ou um sistema on-line qualquer que seja ele )
Mas espero fortemente que um dia as pessoas ( clientes principalmente ) acreditem na importância desses papéis de arquitetura e das metodologias, como se acredita hoje para o outros ramos como a arquitetura civil, aonde existem legislações específicas para isso, que inclusive tornam alguns documentos obrigatórios no caso da construção e regularização de uma edificação.
Mas isso é apenas um processo de amadurecimento natural, isso tudo é muito novo se compararmos a outra área citada à cima. Acredito que um dia o design e arquitetura voltados ao mundo virtual ( cyber espaço ) seja algo regulamentado e realmente observado por todos como algo importante e que não seja vista uma barreira tão grande entre as áreas de t.i e marketing que são as duas áreas em evolução constante depois do advento da “internet” e que deveriam na minha opinião como disse, trabalharem juntas.
Correção, em relação a parte de Teste A/B e QoS claro.. Devemos considerar sim a fase de implementação e transição.
Pingback: Os entregáveis da Arquitetura de Informação | Arquitetura de Informação » Web Design
Ola, gostei muito do post, Parabéns!
Eu creio q vc cometeu um equivoco muito comum em trocar os conceitos de Quantitativa e Qualitativa, quando diz que “descobrir que todo usuario clica na logo…” esta é uma analisa quantitativa, ou seja quantidades de usuarios(metricas). E em “mensurar opiniões de grupos sobre o site/portal” é uma analise qualitativa, por ser uma analise apurada, detalhada e qualificada.
Espero ter ajudado!
abraços…
Muito bem observado. Já corrigi. Obrigado!
Pingback: Testes A/B agora podem ser feitos via Google Analytics | Arquitetura de Informação
Nossa, excelente resumo das tecnicas e praticas para montar, reformular e avaliar um site/projeto digital. Mas a gente sabe que o desafio eh conseguir ajustar o que o usuario esta fazendo com o que o cliente quer.
Pingback: A Arquitetura de Informação e seus entregáveis - Princi Agência Web - Blog
Pingback: A frase da semana, do mês, do ano | Arquitetura de Informação
Pingback: Elementos da User Experience | Arquitetura de Informação
Muito bom o post! Referência certa!
Pingback: [Blog] Arquitetura da informação para jornalistas | Portfólio Carol Vidal - Comunicação digital, Arquitetura da informação, Jornalismo e Revisão - Salvador / BA