Especificações orientadas a clientes e equipe traz resultados eficientes

Achei interessante compartilhar.

Quando a web foi criada não trouxe em anexo os profissionais que iriam gerir, promover e contextualizar seu conteúdo no mundo real.
Por conta disso e contando com 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 até mesmo construindo um lar real para o incontável número de informações que passam rapidamente pelas telas dos computadores.

Com essa constante adaptação, nós podemos ver desfilando livremente pelo Team das agências e empresas de TI as mais variadas formações profissionais.
Estas acabam contribuindo para os novos desafios promovidos pela web, dentro da arquitetura de informação, e ajustando todo o compasso, até então mal utilizado, da forma a comunicação.

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

O resultado dessa 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.

Embora o entendimento da necessidade de integração de disciplina seja uma realidade em constante desenvolvimento, ainda existem alguns ângulos do processo que ficam perdidos. Um deles é a interpretação dos protótipos dos arquitetos de informação.

Já que os autores se originam de diversas áreas e também pelo fato de a 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, que, ao serem apresentadas para a equipe, geram um entendimento deficiente que poderá se converter em resultados menos claros, equipe estressada e descontentamento geral.

Redigi algumas linhas sobre especificações geradas pelo trabalho da arquitetura da informação. Não entendam como regra básica, pois muita coisa ainda está se adaptando, mas com alguns princípios poderemos fazer produtos que sejam claros e de boa interpretação para 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?

1. Cliente: orientar para entenda a dimensão, as premissas, a organização de informações e os fluxos que o projeto dele comporta;
2. Gerente de Projeto: orientar no escopo e nos prazos do projeto;
3. Designers: orientar no que diz respeito à localização dos blocos de informações de cada tela; 
4. Desenvolvedores: orientar como será o fluxo da navegação em cada seção.

Check list em 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 em que 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 tudo deve ser extremamente conversado com a equipe, pois juntos vão criar uma 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 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 os 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 o 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.
• Se existem telas que são complicadas até para você, arquiteto de informações, imagina para o cliente ou para a equipe - que certamente não ficou lendo e decorando as 10 heurísticas do Nielsen. Seja um bom AI e explique bem cada passo desse fluxo de forma clara para todos que estão envolvidos com o projeto. A equipe contribui muito no processo de criação. Fale com as demais áreas 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 introspectivo, converse!

Não esqueça que especificações de Arquitetura da Informação 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 que trabalham na construção do website ou sistema web. Oriente-se!