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

[Eduardo Rangel Brandão <brandaoedu AT gmail.com>]

Renato, perfeito tudo isso que você disse.

Só não concordo com a parte do wireframe, rs :-)

Não quero parecer chato. E acredite, há alguns anos atrás eu era um defensor (com unhas e dentes) do wireframe (ou documentações super formalizadas). Só que, hoje, mudei a minha maneira de pensar.

Se o sprint tem um tempo determinado para acabar (aqui na Globosat são 10 dias, por exemplo), vai ser mais rápido tomar decisões em cima de um sketch do que produzir um wireframe (ou qualquer outro documento formal). A menos que você determine sprints específicos para criar algum tipo de documentação. Mesmo assim, essa documentação não será compartilhada com o cliente, servirá para a equipe desenvolver o projeto. No final, o que é entregue para o cliente é um pedaço da interface funcionando, ou um layout para ele validar (se o propósito desse sprint foi criar esse layout).

Por aqui costumamos fazer os sprints iniciais para conceituar o projeto e "amarrar as pontas". As histórias e tarefas se baseiam em definições de AI. Sempre que surgir a necessidade de criar algo novo, mesmo em sprints avançados do projeto, a abordagem se repete. Fica mais rápido para todo mundo discutir e tomar as decisões.

E falando em metodologia ágil a gente entra ainda em outra discussão, que é o momento que o profissional de UX deve participar do sprint. Os desenvolvedores acham que eles têm que caminhar junto com o resto da equipe, trabalhando sempre no mesmo sprint. Já o pessoal de criação acha que o profissional de UX tem que andar sempre na frente, desenvolvendo coisas antes do sprint começar para os conceitos já estarem definidos no momento desse sprint ser colocado em pratica...

Mas, enfim, isso é outra discussão totalmente fora do foco inicial dessa troca de mensagens. Vamos deixar para outro fórum.

Abç :-)



Eduardo Rangel Brandão
brandaoedu AT gmail.com

Em 30 de abril de 2010 12:07, Renato Monteiro <renato.renatomonteiro AT gmail.com> escreveu:

Eduardo,

só para contextualizar algo em cima da sua última mensagem, para a Isabela: como eu comentei anteriormente, quando se utiliza métodos ágeis de desenvolvimento, os processos de interação junto ao cliente são mais constantes, até por pregarmos a transparência total do projeto. Desse modo, fica mais claro entender o porquê da necessidade de se "apresentar" um WF (e os outros "entregáveis") a ele. Os sprints (timeboxes de desenvolvimento) são períodos relativamente curtos, em geral de 1 a 3 semanas, onde se vislumbra a entrega de uma parte do projeto finalizada. Sei que alguns aqui devem ter dificuldades com este tipo de abordagem como eu mesmo tive no começo, mas hoje já me adaptei a ele e sei que grandes empresas (como a globo.com, por exemplo) o utilizam. Diariamente preenchemos uma planilha onde pontuamos o que estamos fazendo, se há algum tipo de impedimento e quais os próximos passos dentro deste sprint. Com essas janelas de interação com o cliente reduzidas, torna-se natural que ele acompanhe (e entenda!) os processos admitidos dentro do desenvolvimento.

Como falei antes, o tipo de abordagem metodológica também pode influenciar na necessidade ou não de se entregar relatórios, WF, inventários e fluxogramas.

Abs,

Em 30 de abril de 2010 11:40, Eduardo Rangel Brandão <brandaoedu AT gmail.com> escreveu:

Isabela,

Infelizmente você não entendeu nada do que eu falei.

A questão não é dispensar ou não os entregáveis para se firmar de uma maneira estratégica. A questão é não achar que sem os entregáveis formais você não é capaz de projetar, ou valorizar o seu trabalho, ou que sem esses entregáveis formais a AI micro e mais detalhada vai deixar de ser pensada. Um projeto pode ser altamente documentado, detalhado, etc., mas isso não livra essa interface de ser uma boa merda! Os documentos servem apenas para a equipe desenvolver o projeto, uma formalização maior dessas entregas pode acabar impactando nos prazos, no aumento dos custos, etc. Por isso defendo uma forma de trabalho mais ágil e menos burocratizada.

Para mim não existe a necessidade de ficar preso no documento A, B ou C. Esses documentos não irão valorizar o seu trabalho perante o cliente (que na maioria das vezes não vai nem entender do que se trata). Por isso, o que deve ser apresentado para o cliente é um layout/protótipo mais próximo da realidade que pretende-se entregar no final. E para se chegar mais rápido nesse protótipo, é melhor trabalhar de uma maneira menos formal (e essa maneira mais informal não prejudica a comunicação entre a equipe, o entendimento do projeto por todos os membros dessa equipe e a entrega do produto final).

Logo, não há necessidade de ficar preso a um modelo antiquado de trabalho, onde tudo que tem que ser formalizado e leva o dobro, ou o triplo, do tempo para entregar o projeto.

Você também não entendeu minha crítica ao livro. Acho a leitura dele indispensável para qualquer AI. Só não acho que tudo que foi escrito no livro ainda se aplica hoje, não tem que seguir 100% do que está escrito ali. Vou tentar dar outro exemplo: o Jakob Nielsen, por exemplo, durante muitos anos escreveu que os links têm que ter a cor azul e os links visitados têm que ter a cor violeta. Só por causa disso você vai sempre colocar links dessas cores nas suas interfaces? Só porque o cara escreveu um livro, ou um artigo, não deve existir espaço para o questionamento dessas recomendações? E se o seu briefing pede uma interface que quebre paradigmas? Você não vai fazer, porque leu em algum lugar que aquela não é a maneira correta de se fazer uma abordagem? Foi só isso que eu quis dizer ao criticar o livro. É importante conhecer a fundo tudo o que está escrito no urso polar, até para saber o que pode ser "quebrado" em função das suas necessidades de projeto. Mas nunca falei em invalidar o conhecimento.

Abç,

Eduardo Rangel Brandão
brandaoedu AT gmail.com

Em 30 de abril de 2010 10:20, Isabela Abrantes <bela.abrantes AT gmail.com> escreveu:

Eduardo, no fim, estamos dizendo a mesma coisa.

Quando eu "defendo" o wireframe, não defendo ele como entregável indispensável. Só defendo que falar "wireframe é cada vez mais desnecessário" é precipitado, porque do mesmo jeito que optar por ele em todos os projetos seria um erro, dispensar ele totalmente em todos projetos seria um erro igual.

E mesmo em projetos onde eu utilizo wireframes, meu entregável não se resume a ele, obviamente. Inclusive, em quase 99% dos projetos que fiz que demandaram wireframes, o sitemap e o inventário de conteúdo foram igualmente fundamentais.

Embora eu acredite que cada um tenha mesmo sua metodologia própria, continuo insistindo que é exatamente por isso que não se pode optar por um modelo de entregável e nem mesmo optar por jamais usar determinado modelo.

Como eu disse anteriormente, o papel estratégico não está ligado a você entregar ou não um documento específico. Sei que existe um desejo geral de se fazer apenas a macro AI, em ser somente o 'estratégico', e é por isso que uma boa parte dos AIs que eu conheço acaba acreditando que a evolução natural de um AI é virar um planner.

Eu discordo disso e acho que a Micro AI é tão importante quanto a Macro AI, e se um profissional dentro de seu ambiente de trabalho só vai conseguir firmar o seu papel estratégico dispensando entregáveis formais, a culpa não é do entregável, e sim do profissional. 

Quanto sua crítica ao urso polar, ela é válida, até certo ponto. O fato do projeto de UX ter hoje desafios muito mais amplos do que os que existiam há 12 anos atrás, não invalida ou nega o conhecimento adquirido até então e nem as necessidades de se projetar uma interface que foram mapeadas na época. Esses desafios apenas se ampliaram, porque as possibilidades e formatos dessas interfaces também se ampliaram.

Abs, Isabela

Em 30 de abril de 2010 09:33, Rafael Poggi <rpoggi AT gmail.com> escreveu:

"No final das contas, cada um pensa de um jeito e cada um se sente mais confortável trabalhando de uma forma ou de outra."

Mas, Eduardo, se for assim, a sua colocação lá sobre os AIs que você teria dispensado porque se diziam feras em wireframes vai por água abaixo. Afinal, para você, o certo não seria isso. Para eles, não. E quem ficou sem o emrpego foram eles.

Esquisito...

Acho que cada projeto demanda uma solução. Cada empresa sabe dos seus processos. Se um layout pode alterar algo que com o avaldo AI tenha se decidido ser a  melhor soluçao, não vejo porquê não atualizar o wireframe. Seria certamente algo pontual.

Mas como eu disse, cada caso é um caso.

abs

Rafael Poggi
::: design+letras
::: 21 8213-3449

Web
::: http://www.designeletras.com

Networking
::: http://twitter.com/rpoggi
::: http://www.linkedin.com/in/rafaelpoggi

Humor
::: http://www.insolente.com.br

Em 29 de abril de 2010 15:36, Eduardo Rangel Brandão <brandaoedu AT gmail.com> escreveu:

Rafael,

Sim, o sketche não deixa de ser um wireframe. Só que é muito mais rápido de ser produzido e cumpre o mesmo propósito.

Também concordo que, na maioria das vezes, o layout vai seguir a estrutura do wireframe, até porque você desenha o wireframe pensando no layout final (é muito difícil separar uma coisa da outra).

Mas isso não pode ser uma regra. Quando você desenhar o layout, pode perceber outros aspectos que não visualizou na etapa anterior, quando o wireframe foi feito. E aí? O que acontece? Faz outro wireframe? Não, né? ;-) Por isso não deve existir essa obrigatoriedade de um seguir o outro.

Se fosse sempre assim, ou seja, o layout deve seguir o desenho do wireframe, você está engessando o trabalho do designer de interface. Ou você acha que ele só serve para colorir pixels e não participa da elaboração da interface?

O wireframe serve como uma etapa inicial do processo de projeto da interface. Sua função é de rascunhar a interface, tentar estruturar seu funcionamento e posição dos elementos. Se a interface tem que ser exatamente igual ao wireframe, para quê fazer isso 2 vezes? Por quê se privar de novas propostas que podem surgir no momento do layout ao invés de apenas dobrar o seu trabalho e desenhar a tela 2 vezes? Às vezes o briefing do projeto também pede uma interface mais diferentona, que não siga certos padrões. O wireframe não vai permitir pensar nesses aspectos, ele sempre vai representar uma interface mais quadradona, mais "durona".

Mas, enfim, como diz o grande filósofo Helio de La Peña, opinião é que nem bunda, cada um tem a sua! :-) No final das contas, cada um pensa de um jeito e cada um se sente mais confortável trabalhando de uma forma ou de outra.

Abç pra todos!

Eduardo Rangel Brandão
brandaoedu AT gmail.com

Em 29 de abril de 2010 15:07, Rafael Poggi <rpoggi AT gmail.com> escreveu:

Concordo que o sketche já bastaria. Mas ele não deixa de ser um wireframe. Pode não se rum protótipo navegável, como os que eu costumo fazer no Axure, mas é. Mas se o wireframe não comportar a arquitetura do site para que o layout se acomode ali, ele pode ser simplesmente um pedaço de papel riscado mesmo, onde eu escreva: topo, menu, formulário de contato, imagens, thumbs, texto. Pronto. Sei lá, o layout a meu ver deve seguir a AI apresentada na forma do WF.

Rafael Poggi
::: design+letras
::: 21 8213-3449

Web
::: http://www.designeletras.com

Networking
::: http://twitter.com/rpoggi
::: http://www.linkedin.com/in/rafaelpoggi

Humor
::: http://www.insolente.com.br

Em 29 de abril de 2010 14:14, Eduardo Rangel Brandão <brandaoedu AT gmail.com> escreveu:

Rafael,

Wireframe não é layout, ele é um documento para você indicar os elementos que devem existir na tela. O layout é o trabalho do designer de interface. Ele irá posicionar os elementos na tela. É claro que isso é, na maioria das vezes uma decisão em conjunto com o AI.

Antes de pensar no wireframe, sugiro o AI sentar junto com o designer e conceituar a tela, suas funcionalidades, quais os elementos são importantes. Para isso, um sketche já basta. Fazer o wireframe será uma perda de tempo maior, para um documento que ficará engavetado no final do projeto.

Não concordo com essa visão de que o layout tem que seguir o wireframe. Pense que o trabalho do AI tem mais a ver com o planejamento da interface, com o projeto, é mais macro, o AI tem uma visão do todo e o designer de interface vai dar a solução sobre o layout. Se o AI e o designer de interface forem a mesma pessoa, melhor ainda.

Abç,

Eduardo Rangel Brandão
brandaoedu AT gmail.com

Em 29 de abril de 2010 13:34, Rafael Poggi <rpoggi AT gmail.com> escreveu:

Olá!

Você disse: "Um menu, por exemplo, se estiver na horizontal no wireframe, não é obrigado a ficar na mesma posição no layout final. "

Eu não concordo muito com isso. O trabalho do AI não é também proporcionar uma experiência de navegação adequada? Se eu coloco um menu na vertical é porque ele seria  a melhor solução para o problmea apresentado. Então ele deve ser layoutado na vertical, exatamente ali onde eu coloquei. Penso assim pelo menos...

abs

Rafael Poggi
::: design+letras
::: 21 8213-3449

Web
::: http://www.designeletras.com

Networking
::: http://twitter.com/rpoggi
::: http://www.linkedin.com/in/rafaelpoggi

Humor
::: http://www.insolente.com.br

Em 29 de abril de 2010 11:24, Eduardo Rangel Brandão <brandaoedu AT gmail.com> escreveu:

Rafael,

Acho o wireframe um documento cada vez mais desnecessário.

1) O AI perde tempo para produzir, num trabalho burocrático quando ele poderia estar pensando em novas soluções e funcionalidades. Além disso, se a interface final tiver mudanças depois do wireframe pronto (o que quase sempre acontece), esse wireframe se torna defasado (afinal, depois da interface pronta você não vai perder tempo para consertar o wireframe, certo?).

2) Wireframe não é layout, ele só indica os elementos que devem existir na interface e a importância dos mesmos. O layout final, inclusive, não precisa seguir a mesma posição que os elementos ocupam no wireframe. Um menu, por exemplo, se estiver na horizontal no wireframe, não é obrigado a ficar na mesma posição no layout final. O wireframe tem que indicar a existência desse menu, quais são seus itens, etc., mas não dizer se fica na horizontal ou vertical.

3) O cliente não tem capacidade para entender o wireframe, digo isso por experiência própria. Muitas vezes, nem as outras pessoas da equipe conseguem entender completamente esse tipo de documento e acabam interpretando uma coisa ou outra de maneira errada.

O conselho que te dou é: trabalhe com sketches para conceituar a interface, discutir com o designer (e o restante da equipe também). Na hora de apresentar o projeto para o cliente, use um layout ou um protótipo, se o seu objetivo for mostrar para ele que efeito algumas funcionalidades produzem na interface.

Abç,

Eduardo Rangel Brandão
brandaoedu AT gmail.com

Em 29 de abril de 2010 11:07, Rafael Poggi <rpoggi AT gmail.com> escreveu:

Bom dia!

Gostaria de saber como é a reação dos seus clientes perante um wireframe (e obviamente sua especificação funcional). Vocês costumam mostrar a ele e discutir a arquitetura detalhadamente? Ou o wireframe é discutido apenas com o designer e o cliente fica apenas com o layout para avaliar? Falo isso porque um cliente freela meu - pequeno - disse que não entendeu o porquê do wireframe e não entendia aquilo, mesmo eu tenho explicado a ele toda a importância da parada. 

abs

Rafael Poggi
::: design+letras
::: 21 8213-3449

Web
::: http://www.designeletras.com

Networking
::: http://twitter.com/rpoggi
::: http://www.linkedin.com/in/rafaelpoggi

Humor
::: http://www.insolente.com.br

. . . . . . . . . . . . . . . . . . . . . .
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

. . . . . . . . . . . . . . . . . . . . . .
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

. . . . . . . . . . . . . . . . . . . . . .
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

. . . . . . . . . . . . . . . . . . . . . .
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

. . . . . . . . . . . . . . . . . . . . . .
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

. . . . . . . . . . . . . . . . . . . . . .
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

. . . . . . . . . . . . . . . . . . . . . .
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

. . . . . . . . . . . . . . . . . . . . . .
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

. . . . . . . . . . . . . . . . . . . . . .
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

. . . . . . . . . . . . . . . . . . . . . .
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