A especificação de arquitetura de informação

Share on facebook
Share on twitter
Share on linkedin
Share on whatsapp
Share on telegram
Share on pocket

A web quando foi criada não trouxe em anexo os profissionais que iriam geri-la, promovê-la e contextualizá-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 pelas equipes 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 que 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 todas 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…

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 ideias 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-sellers para todas as pessoas envolvidas na construção do website ou sistema web. Oriente-se! [Webinsider]

…………………………

Conheça os serviços de conteúdo da Rock Content..

Acompanhe o Webinsider no Twitter.

Íris Ferrera (iris.ferrera@gmail.com) escritora, estudante, arquiteta de informação e consultora de user experience nas horas vagas. Twitter @irisferrera.

Share on facebook
Share on twitter
Share on linkedin
Share on whatsapp
Share on telegram
Share on pocket

Mais lidas

6 respostas

  1. Parabéns, Iris!
    Como sempre um pensamento muito bem alinhado e super esclarecedor. Posso falar que foi um prazer trabalhar contigo. Continue escrevendo, o povo de UX agradece!

    Abraço!

  2. Oi Evandro, obrigada por me ler mas por favor não chore 😛

    Realmente são pontos beeeem delicados essa coisa toda de documentação e o limite de até onde podemos ir no detalhamento do wireframe…Mas sabe de uma coisa? Por experiência própria eu percebo que quanto mais envolvida estou no projeto desde o princípio dele, mais fácil fica definir até que ponto devemos ir em detalhamento de wireframe.

    Eu também já tive discusões com designers por fazer detalhamentos empolgados pelo projeto ser muito legal (vezes eu estava ultrapassando a linha tênue entre Design e AI e outras o projeto exigia mesmo detalhamento para ser melhor absorvido pelos envolvidos…enfim)e acho que a medida que nossa importância for sendo percebida e respeitada os mais resistentes vão conseguir entender que estamos ali para somar e não para roubar qualquer espaço. E este cenário acho que também é valido até para nosso posicionamento diante do dilema “detalhar o wire ou não?”

    Enquanto isso temos que seguir na militancia para colocar a AI dentro de todos os tamanhos e formatos de empresas digitais.

    Eu li esse artigo do Usabilidoido a um tempão atrás e achei simplesmente ótimo! Me inspirou a refletir sobre nossas especificações e nossa forma de entrega-las.

    Sucesso para nós todos envolvidos no projeto e muuuuita sabedoria para conduzir estes insumos de forma mais clara e pacifica possivel!

  3. Iris, isso só poderia ser escrito por alguém com UX na essência. Quase escorreu uma lágrima aqui agora hehehe

    Algo muito importante que vc passou no seu texto é o fato de que a AI é um documento, que precisa ser claro para todos os envolvidos no projeto. E se for preciso, que ele seja mais detalhado (não tão macro), como um protótipo navegável, e com isso, ser mais didático, esse é o caminho que ele deve seguir.

    Não sei exatamente sua formação, mas eu iniciei em sistemas e migrei pro Design, e agora pra UX, Projetos e QA. Isso tudo me ajudou muito a compreender as camadas de desenvolvimento e tentar focar a linguagem dos Wires para produtos e pessoas específicos.

    Outra coisa muito legal que você citou é sobre o limite que o AI tem de ter para não contaminar o Designer. Isso é uma discussão realmente muito saudável para ambas as partes.

    Eu já me peguei algumas vezes desenvolvendo protótipos que vão além do seu propósito, apresentando praticamente o layout. E com isso acabei engessando a capacidade de criar do Designer que fazia parceria no mesmo projeto.

    Rolou até uma discussão sobre isso no site do Fred. Na época, postei minha dúvida quanto a esse limite:

    http://usabilidoido.com.br/quanto_mais_simples_o_wireframe_melhor.html

    Aqui na empresa já rolaram altas discussões sobre isso. E posso ser sincero? Até hoje tenho essa dúvida. Talvez pela empolgação, a vontade de ser o mais didático e específico possível… e acho que vou morrer com essa dúvida.

    Iris, parabéns. Não conheço seu trabalho, mas pela visão que deixou claro aqui, deve ser excepcional.

    Como sempre digo: Sucesso a todos nós. E se for fazer, faça direito ehehehe

  4. É Evernton… ainda temos que evangelizar muitos setores das empresas que trabalhamos e cuidar muito com as manutenções das especificações. Mas o lado positivo disto é que a gente está ganhando espaço em cada “evangelização” ou mesmo em cada “briguinha” por espaço dentro do projeto. O fato é: somos importantes, documentar todo insumo que geram nossas pesquisas é algo fundamental e a medida que a empresa começa a sentir essa importancia, eu quero acreditar, que a gente vai ter mais “tempo” para fazer o que deve ser feito. Obrigada pela leitura e sigamos na luta” 😉

  5. Infelizmente devido a correria e volume de projetos para serem feitos em prazos utópicos, essa fase do projeto acaba ficando de lado muitas vezes.

    Na empresa que trabalho, uma multinacional, estou tentando evangelizar as pessoas da importância da AI e UX nos projetos.rs..tenho conseguido, porém outro fator de extrema dificuldade é manter essa documentação atualizada, visto que ocorrem muitas manutenções e alterações nos projetos pós implantados.

Deixe um comentário

O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *