Arquitetura da Informação (em Português)

["Ana Paula Margarites" <anamargarites AT gmail.com>]

Oi pessoal,
Meus dois centavos :)
Achei legal o ponto da Karine sobre o excesso de documentação que acaba por tornar o processo de AI mais demorado.
Infelizmente, em algumas empresas, a documentação detalhada é o único jeito de fazer com que as definições da AI não se percam durante a construção da interface / aplicação. Já aconteceu comigo dezenas de vezes: sempre que deixo de lado as especificações mais detalhadas (principalmente por causa dos prazos), as funcionalidades acabam não funcionando como eu tinha idealizado.
O problema, a meu ver, é a forma como os projetos são vistos pelas empresas. Quando estou fazendo wireframes de uma interface, o designer gráfico já está desenhando as telas de um projeto que fiz semana passada, e o desenvolvedor HTML já está em outro projeto. Esse esquema "em cascata" dificulta a comunicação entre os membros da equipe.
Infelizmente, os processos ágeis, que possivelmente resolveriam estes problemas, são difíceis de serem aplicados em todas as situações. Eu, por exemplo, faço parte de uma equipe que está distribuída em duas cidades. É praticamente impossível que a comunicação entre os membros da equipe seja tão fluída como em  organizações onde todos estão na mesma sala, pelo menos na minha opinião. O que vocês acham?

Grande abraço a todos :)

--
Ana Margarites
*sorry this is an email and not a face-to-face conversation*

2008/10/17 Karine Drumond <karinedrumond AT gmail.com>

Ei Hugo,

O maior problema que vejo da aplicação da A.I, UX, DCU e todas essas siglas na prática, é a metodologia "não ágil"  principalmente para o contexto em que vivemos (que você bem citou, de prazos curtos, pressão, softwares e sistemas cada vez mais complexo, etc)

Documentação exessiva que os profissionais adotam (não sei se por exigência do mercado, dos clientes - que querem receber um relatório bonitinho ao invés de uma interface bem feita, ou porque a propria agência exige a entrega e confecção de todos esses documentos, como prova de que o processo foi feito, ou porque talvez os próprios profissionais são "agarrados" aos seus documentos).

Confesso que eu mesmo já fui agarrada aos meus modelos de requisitos, fluxogramas, sitemaps, casos de uso, mindmaps.-todos feitos, bonitinhos, em softwares próprios, Visio, Axures, Mindmaps e Illustrator, Power point da vida... Será que essas ferramentas e documentos tem auxiliados aos profissionais a realmente criarem sistemas interativos mais organizados, mais fáceis e mais interessantes para os usuários? Ou estão ajudando a criar documentos e especificações mais entendíveis? Não to dizendo que a documentação não é importante, mas o exesso dela prejudica que as melhorias se tornem realidade, se convertam em melhorias na interface, melhoria no produto, que o resultado da pesquisa se converta em um produto melhor.

Temos bastante simpatia pelo processo ágil de desenvolvimento e sua filosofia, procuramos aplicar ele para desenvolvimento de produtos próprios. Como? Principalmente: eliminando exesso de documentação, muitas vezes um protótipo e rascunhos em papeis já servem como especificações, equipe enxuta, comunicação em todo o processo, iterações curtas (não esperar o protótipo estar ultra mega perfeito), iterações rápidas e botar o usuário para usar o mais rápido possível, testes simples, desenvolvimento em paralelo a pesquisa e principalmente: começar a desenvolver a menor unidade do sistema, focar na essência...etc..

Tudo isso é aprendizado da metodologia ágil. "Menos documentação e mais software, mais produto"

Parece simples, mas o que vejo é que acabamos complicando o processo desnecessariamente.

Tavez tenhamos de voltar um pouco e descobrir a essência. "Fazer produtos mais usáveis, mais organizados, mais prazerosos".

O Caio (Caio Cesar) disse em uma palestra e eu vou repetir: "parafraseando o candidato, Isso dá para fazer".

Demos outro dia uma palestra sobre métodos ágeis de design de sistemas centrado nos usuários e está disponível neste link.

O mercado de hoje, ainda não permite a todos arquitetos trabalharem de forma
ágil e com qualidade de selo. Vejo muitos profissionais tendo que realizarem
diversas tarefas e todas muito bem, mas confesso que eles não implementaram
em suas interfaces, todos os detalhes de navegação e recursos que pensaram
no decorrer do projeto. Os prazos não permitem, a verba não foi lá essas
coisas, falta profissional, são diversas fatores que fazem empresas
sobrecarregarem seus funcionários e grupos de profissionais se submeterem
aos clientes que não sabem do assunto mas que no final ficam satisfeitos com
o que compraram.
O problema está nos profissionais? No mercado ou nas empresas? É cultura?
São n fatores para n casos.
Só vi esse tipo de desenvolvimento acontecer em projetos no qual a verba
destinada foi de agrado a todos ou nos projetos em que a vontade da equipe é
finalizar a idéia com gosto, visando uma ótima experiência para o usuário ao
utilizar a interface do projeto desenvolvido.

Formar a equipe é um ponto crucial e as vezes até difícil, aqui os
profissionais praticamente não existem, pergunto por eles e ninguém os
viram. É preciso sempre pensar nos detalhes e pessoas na equipe ajudam
muito, mas se não tiver como, caça com o teu gato o que vale é saber que a
interface poderia ficar melhor e não melhorar por certos motivos.

Abraço a todos!

Hugo Omena

--
Karine Drumond
Latitude14 | pesquisa + design centrado no usuário
www.latitude14.com.br
(31) 3542-9991
(31) 9132-8406

. . . . . . . . . . . . . . . . . . . . . .
Ao responder, elimine o texto não essencial
de mensagens anteriores e evite formatação.

Lista de discussão AIfIA-pt
AIfIA-pt AT lists.ibiblio.org
Arquitetura de Informação em Português
http://lists.ibiblio.org/mailman/listinfo/aifia-pt