Existem algumas metodologias (ou práticas) que podem ser inseridas na arquitetura da informação. Porém, nem tudo que está listado precisa entrar no projeto. O importante é analisar bem a extensão, prioridades, público, mercado, tempo e expectativa do cliente. A divisão de fases de trabalho a seguir é apenas uma sugestão, pois cada projeto tem sua necessidade específica. Não adianta fazer tudo, gastar o dinheiro do cliente e, só no fim, perceber o “pleonasmo” dos insumos que a arquitetura de informação 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, é o momento de organizar as horas, analisar todo o material do cliente e propor para a equipe um conjunto de ações que irá 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 mesmo criar um modelo próprio.

Road Map
É um plano de ação, um roteiro, um passo a passo para o desenvolvimento de um projeto que precise de entregas faseadas. Ajuda a coordenar e planejar os avanços, além de deixar claras as datas e a enxergar o conjunto de tecnologias que pode ser aplicado para o projeto e o esforço necessário para cada etapa.

Benchmark
É a observação e o 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 estilo das telas e seus comportamentos.

Benefícios de um benchmark:

• Novo olhar sobre conceitos e padrões, o que pode trazer novidades bem focadas e pertinentes à proposta
• Permite que o conhecimento sobre o mercado e sobre o cliente seja amplificado e, consequentemente, sobre o 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 ser 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 ou detalhadíssima, com o intuito de personificar um usuário fictício dentro do público-alvo.

Essa pessoa fictícia ajuda no alinhamento das expectativas, tanto do cliente quanto da equipe, sobre recursos e funcionalidades que devem estar contidos no projeto, na priorização e na avaliação do produto.

Ao se criar essa pessoa, é recomendável que tenha:

• Nome, para facilitar a associação com pessoas reais
• Características e razões para que o produto seja importante para ele. Para isso, um histórico da persona, em relação às suas expectativas com o produto, é útil
• Cenários para ambientar as condições em que a persona vai interagir com o produto
• 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.), o ecossistema é 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 e 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 “responda a 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
Essa é uma interessante técnica com que 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, quando 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 interface do produto em questão.

Inventário de Conteúdo
Um nome bastante autoritário, mas, no fundo, trata-se de uma técnica simpática. 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, portal, sistema, app, software, produto.
Consiste de 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 para, no futuro, facilitar sua encontrabilidade.

Análise de Tarefas
É uma análise descritiva de como os usuários realizam tarefas utilizando o 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 Produto/Solução
Organograma que mostra todas as páginas que a solução/produto 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 mapa mais refinado, no qual é 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 o esqueleto do site, portal, sistema, app, software, produto. É o resultado de pesquisas, no qual 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.

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) visualize 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 – 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, frequentemente, eles estão habituados a este formato, por ter 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. Procura reunir referências visuais do que se espera encontrar no seu site, portal, sistema, app, software, produto. Ajuda muito os designers a definir 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, é hora de testar o produto, antes de entregá-lo ao cliente. Abaixo, estão algumas sugestões 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 a solução/produto deve conter. Com elas, podemos observar e analisar alguns pontos que ajudam a definir se o website, programa, aplicativo está usável ou não. Alguns exemplos de itens que essa 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

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 da solução/produto e ajustá-lo, para que a entrega esteja bem alinhada e com usabilidade eficiente.

Olhar 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. O resultado desses 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 fim do projeto, como medida constante de qualidade e adequação ao usuário final.

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 de 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 pode ser acessado 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 e aprovado? Então, agora é a fase de relatórios de melhorias e análises de comportamento.
Seguem abaixo sugestões de práticas que podem ser incluídas no seu set de monitoramento.

Teste de Usabilidade
Já falamos dele anteriormente. 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 as 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ê a versão A da tela, metade vê a versão B, durante um certo período de tempo. No fim, 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
É uma das técnicas mais modernas. 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, 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.

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)
A análise de interface quantitativa descobre o comportamento do usuário durante a navegação – por exemplo, descobrir que todo usuário clica na 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 também depois de sua implantação.

Esses dados permitem redefinir as seções, privilegiando as informações de acordo com o público ou definir premissas para um determinado projeto. Se 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 e com gerentes, deixe que eles conheçam o arsenal de entregáveis que a arquitetura da informação pode produzir, insira-a em seus projetos e colha os louros de um resultado eficiente.

Fonte: Websinder - Os entregáveis da arquitetura da informação