O que um arquiteto de informação faz (e o que não faz)

Publicado por: Tássia Spinelli em: setembro 14, 2009

Em: Arquitetura de Informação | equipe | esboços | processos
Comente!

Sabe quando você se sente um apêndice? Uma parte do corpo humano que não serve pra nada, que a gente diz que tem para fazer uma média, porque sabe que algumas pessoas não têm? É um dos dilemas de vida dos arquitetos de informação. No começo é tudo muito bom, principalmente no início de um projeto. O cliente quer escutar que o projeto tem AI ou UX, então o seu olhar otimista cai bem. Marquei UX no seu coração feelings. É aí que somos levados para as reuniões como analistas de produto, consultores astrológicos, conhecedores técnicos, porque afinal, qual dessas coisas não está em contato com o usuário, então podemos ser tudo isso!

E no dia a dia, como fica? Às vezes por não saber o que pedir, o seu chefe, vai sim, te passar trabalhos nonsense. Quero deixar claro aqui que a culpa não é do chefe. Sim, a culpa é nossa. Nós deveríamos não somente ter explicado o que um arquiteto faz, mas também o que ele entrega.

Em nossa empresa, estabelecemos que não somos espelhos de analistas de produto, arquitetos de software e muito menos diretores de criação. Ok, o NUX ainda está caminhando para ser alguma coisa, mas com certeza bem alinhado nos limites de ser e não ser um Núcleo de Usabilidade.

Abaixo, alguns exemplos que procuramos buscar com sucesso nessa empreitada dentro da Abril digital:

Nota: Nossos parâmetros são alinhados ao dia a dia da nossa empresa, do nosso processo (agile/scrum), portanto, muito cuidado ao replicar e tomar essas sugestões como um ISO. Também descobrimos que seguir um processo acadêmico às vezes é um mundo ideal dentro de milhares de variáveis, então é melhor sermos diretos ao ponto e nos fazermos entender mais.

TUDO NASCE DE UMA IDÉIA…

Foto: Silvio Tanaka.

1. Idéia – acompanhamento próximo ao Product Owner e argumentação se o conteúdo apresentado gera valor para o usuário;

Documentos que podem ser entregáveis: Pesquisa de audiência (ex: on line surveys), análise crítica de benchmarks ou testes de usabilidade (aham, é possível oferecê-los antes de fazer as melhorias).
Documentos que não precisam ser entregues: Pesquisa de oportunidades de mercado.

2. Briefing – Validação sobre quais seriam as necessidades do ponto de vista da AI com as outras áreas (PO e Arquiteto de software) para garantir a adequação da interface do produto e que as regras de negócio atuais estejam consistentes;

Documentos que podem ser entregáveis: NENHUM
Documentos que não precisam ser entregues: Definição de regras de negócios, histórias escritas, definições detalhadas sobre banco de dados, direção de arte, etc.

3. Slicing das features – Garantir que as features essenciais permaneçam no Release 1 e mantenham uma boa experiência para o usuário;

Documentos que podem ser entregáveis: NENHUM.
Documentos que não precisam ser entregues: os mesmos do item 2.

4. Especificação / Requisitos – Validar com o P.O todas as orientações de produto e criar um documento que seja de fácil entendimento a todos os envolvidos no projeto. Esse documento representa os padrões que serão aplicados, a estrutura da informação, o comportamento dos elementos e a apresentação da interface. Acompanhamento junto com qualidade (seo/qa) para a construção de critérios de aceitação. Protótipo navegável e validação com usuários reais.

Documentos que podem ser entregáveis: planilha de descrição do conteúdo, resultados de card sorting, protótipo navegável, vocabulário controlado, estudo de canais, fluxogramas, entre outros.
Documentos que não precisam ser entregues: os mesmos do item 2.

5. Layout – Validação da disposição visual dos elementos e feedback visual.

Documentos que podem ser entregáveis: relatório com orientações/modificações de acordo com as heurísticas de usabilidade.
Documentos que não precisam ser entregues: definição de grid, tamanho de imagens, planejamento visual.

6. Implementação – Validação de requisitos não funcionais (tempo de carregamento, acessibilidade, etc.).

Documentos que podem ser entregáveis: NENHUM.
Documentos que não precisam ser entregues: wireframes que impactem na sprint atual, garantia de testes detalhados de Q.A.

7. Testes – Consultoria ao Q.A do projeto e validação constante no ambiente de homologação.

Documentos que podem ser entregáveis: NENHUM.
Documentos que não precisam ser entregues: testes de Q.A..

8. Implantação – Avaliação do feedback do usuário.

Documentos que podem ser entregáveis: relatório ou workshop de feedback dos usuários (ex: acessos ao google analytics, testes com usuários, pesquisas de opinião, etc).
Documentos que não precisam ser entregues: ROI do produto.

É isso! Seguindo em frente e aprendendo sempre, até à próxima!

Um abraço do NUX.