15 de set de 2010

Especificação de Arquitetura de Informação orientada ao todos traz resultados eficientes

A web quando foi criada não trouxe em anexo os profissionais que iriam geri-la, promove-la e contextualiza-la no mundo real. Por conta disto e a falta de profissionais web presentes no big bang da rede mundial, ainda hoje vemos as mais variadas disciplinas brigando, se apaixonando, se casando e enfim, construindo um lar real para o incontável numero de informações que passam a cada piscar de olhos pelas telas dos computadores.

Por conta desta constante adaptação nós podemos ver desfilando  alegremente pelo Team das agências e empresas de TI, variadas formações profissionais que contribuem para os novos desafios promovidos pela web, dentro da arquitetura de informação, ajustando todo o compasso desta, até então mal utilizada,
forma comunicação.

Nesse emaranhado de novidades e "nascimentos" muita coisa mudou e se adaptou às novas exigências deste mercado digital cada vez mais presente e ativo. Ainda no contexto de evolução contínua podemos ver as disciplinas que cuidam da experiência  e resultado durante a navegação, se encontrando e somando expertise para trazer uma melhor e mais fiel experiência para o internauta.

E o resultado desta multidisciplinaridade em equipe é a geração de bons trabalhos digitais que repercutem
diretamente em retorno para a empresa, atingindo um quase equilíbrio entre cliente e usuários satisfeitos.

Mas embora o entendimento da necessidade de integração de disciplina seja uma realidade em constante aprimoramento, ainda existem alguns ângulos do processo que ficam perdidos. Um deles é o a interpretação dos protótipos dos Arquitetos de Informação.

Por conta dos autores se originarem de diversas áreas, e pelo fato da profissão ainda estar se consolidando em muitos ambientes de desenvolvimento web (quer seja agência ou consultoria), são criadas especificações
com estilos muito particulares e ao serem apresentadas para a equipe, geram um entendimento deficiente que poderá se converter em resultados menos claros, equipe stressada e descontentamento geral.

Empolgadamente eu descrevo abaixo algumas linhas sobre especificações geradas pelo trabalho da arquitetura da informação. Não entendam como regra básica pois muita coisa ainda esta se adaptando, mas com alguns princípios poderemos fazer produtos que sejam claros e de boa interpretação para todas os
envolvidos no processo.

Para que serve uma especificação de AI?
Sitemaps, fluxo de transações, wireframes, métricas de performance, plano de implementação, matriz de
escopo e o que mais sua imaginação puder lembrar servem para uma única e exclusiva função: Orientar.

Mas orientar quem?
Cliente - Orientar para entenda a dimensão, premissas, organização de informações e fluxos que o projeto dele comporta;
Gerente de Projeto - Orientar no escopo e prazos do projeto;
Designers - Orientar no que diz respeito a localização dos blocos de informações de cada tela;
Desenvolvedores - Orientar como será o fluxo da navegação em cada seção;

Check list  que vale a pena dar uma conferida
Para que sua especificação seja interpretada de forma correta por iodas as pontas do projeto (cliente - equipe) é importante verificar se ele está cobrindo a maioria das sugestões abaixo:

- Cada projeto pode receber um tipo de protótipo. projetos onde o design de interação fale mais alto como hotsites e portais promocionais devem ter um wire mais aberto (sem detalhamentos que engessem os criativos) e extremamente conversado com a equipe pois juntos vão criar a melhor experiência para o produto/serviço que será ofertado.

- Projetos mais complexos como e-commerces devem conter, pela quantidade de UX e controle de vocabulário, uma arquitetura mais detalhada e, idealmente gerar protótipos navegáveis.

- Extranets ou intranets, onde a encontrabilidade é um fator fundamental devem ter seus wireframes construídos juntamente com os desenvolvedores do projeto (analistas e programadores) para que não seja criado um ambiente implementável apenas com linguagens alienígenas ou pertencentes a um futuro distante.

- Nem sempre o protótipo conseguirá cobrir as espectativas e entendimentos da equipe e/ou do cliente portanto temos que usar todas as outras possibilidades de especificações como sitegramas, vocabulários controlados e a própria especificação funcional das telas.

- O wireframe tem a intenção de ajudar o designer a estruturar o site ou sistema e não ensinar o design como fazer o seu layout. Se você é um arquiteto que antes era designer cuidado com os super protótipos. Tenha modos e respeite a linha de ação da disciplina que você não mais professa :P

- Wireframe por default, e para melhor entendimento do conceito de "protótipo", não tem cor e nem imagens. Porém não sejamos xiitas demais! Se o cliente tem dificuldade de abstrair o protótipo para a realidade dele pense com carinho na possibilidade de inserir imagens que estejam contextualizadas com o negócio dele(em
tons de cinza).

- Se existem telas que são complicadas até para você, arquiteto de informações, imagina para o cliente ou equipe que certamente não ficou lendo e decorando as 10 heurísticas do Nielsen. Seja um bom AI e explique bem cada passo deste fluxo de forma clara para todos os envolvidos.

- A equipe contribui muito no processo de criação da AI. Fale com as demais disciplinas e você verá que além do entendimento global haverá algumas boas idéias que você  pode, antes de finalizar a especificação, integrar na sua arquitetura. Não seja muito na sua, converse!

Não esqueça que especificações de AI não são diários particulares de suas experiências no projeto e sim livros que se tornarão  best-seller para todas as pessoas envolvidas na construção do website ou sistema web. Oriente-se!

Compartilhar

Postagens Relacionadas

Especificação de Arquitetura de Informação orientada ao todos traz resultados eficientes
4/ 5
Oleh

Assine via e-mail

Adicionar o seu endereço de e-mail para subscrever .

Página inicial