Skip to Content.
Sympa Menu

aifia-pt - Re: [AI] wireframes x clientes

aifia-pt AT lists.ibiblio.org

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

List archive

Chronological Thread  
  • From: Guilherme Lundgren <g.lundgren AT gmail.com>
  • To: Arquitetura da Informação (em Português) <aifia-pt AT lists.ibiblio.org>
  • Subject: Re: [AI] wireframes x clientes
  • Date: Fri, 30 Apr 2010 11:00:14 -0300

meu deus do céu, voces complicam demais.

wireframe se faz junto ao cliente, não se entrega pra ele, wireframe é um documento SEU, da sua equipe.

a melhor maneira é fazê-lo a mao, numa folha de papel. voce ja pega as coordenadas do q o cliente espera do projeto nesse momento, tela a tela.

depois passa pra quem foi desenhar, junto com um briefing, é o suficiente pro projeto dar um up de 1000% na qualidade e eficiencia (sem milhoes de vai e voltas até aprovação final)

depois disso a gente monta o HTML e CSS, bem basicao né? mas...

...aí é que entra outra coisa EXTREMAMENTE importante, o DIFERENCIAL, mas q eu vejo pouca gente falar aqui, que é o PLANEJAMENTO do front-end (se liguem, estamos exatamente sobre a linha no tempo q separa o click, do touch), definir como o botao se comporta, que elementos e como vão se movimentar, onde deve ter AJAX etc (por isso eu defendo um conhecimento GENERALISTA nessa área, pq vcs, com suas mal***** teorias recem-nascidas, nao conseguem absolutamente nada além de ATRAPALHAR, BUROCRATIZAR e ENCARECER projetos, se liguem nisso, enxergem mais que 1 palmo diante do nariz) 

vc nao precisa mais de nada alem disso pra criar um software/site de pequeno a médio, com um resultado fantástico.

e como 90% dos projetos, sao de pequenos a médios. boa parte dessas teorias que voces debatem aqui a exaustão, NAO SE APLICAM, oneram o projeto sem necessidade nenhuma. 

guardem essa teoria toda pra um projeto q realmente necessite disso, um software q o care passe o dia todo olhando pra uma tela com sei la, 1000 informações diferentes e críticas.

projetos pequenos e médios nao são rocket science... descubram isso pelo amor de deus e nao sejam tão imb****.

abs,

ps: hoje nao to afim de xingar ninguem, por isso as ***, abs.

2010/4/30 Isabela Abrantes <bela.abrantes AT gmail.com>
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



--
guilherme lundgren
vi / veneo interactive
+55 11 6155 2560
http://veneo-interactive.com.br



Archive powered by MHonArc 2.6.24.

Top of Page