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

[Marcos Souza <marcoshsouza AT gmail.com>]

Concordo a Isabela,

Não temos que determinar um modelo "x" de entregáveis para trabalharmos, e sim entendermos o projeto e os stakeholders a quem vamos apresentar.
Eu mesmo já passei por uma situação como aqui o Eduardo deve ter tido, de apresentar um wireframe de média fidelidade e de não ter tido nenhum feedback do cliente por falta de entendimento. E nesse mesmo caso levando sketches acredito que eu não iria ter  
um outro resultado.
Foi preciso o desenvolvimento de um wireframe de alta fidelidade e principalmente a apresentação do sitemap para que o cliente compreendesse o fluxo de navegação do seu site e posicionamento dos elementos.
Acho otima essa discussão sobre as metodologias de trabalho postas por cada um, mas não podemos esquecer dar identidade de cada projeto, clientes e usuários. 
Acredito que os profissionais de AI não deveriam procurar tachar uma metodologia, seja ela de entrega, teste ou qualquer outra, e sim focar no cliente e no usuário final de cada projeto.Â

Em 29 de abril de 2010 20:05, <aifia-pt-request AT lists.ibiblio.org> escreveu:

Enviar submissões para a lista de discussão AIfIA-pt para
       aifia-pt AT lists.ibiblio.org

Para se cadastrar ou descadastrar via WWW, visite o endereço
       http://lists.ibiblio.org/mailman/listinfo/aifia-pt
ou, via email, envie uma mensagem com a palavra 'help' no assunto ou
corpo da mensagem para
       aifia-pt-request AT lists.ibiblio.org

Você poderá entrar em contato com a pessoa que gerencia a lista pelo
endereço
       aifia-pt-owner AT lists.ibiblio.org

Quando responder, por favor edite sua linha Assunto assim ela será
mais específica que "Re: Contents of AIfIA-pt digest..."


Ao responder, modifique o campo Assunto para refletir o conteúdo de sua mensagem.
_______________________________________________

Tópicos de Hoje:

  1. Re: wireframes x clientes (Cid Boechat)
  2. Re: wireframes x clientes (Isabela Abrantes)


----------------------------------------------------------------------

Message: 1
Date: Thu, 29 Apr 2010 20:03:25 -0300
From: Cid Boechat <cidboechat AT gmail.com>
Subject: Re: [AI] wireframes x clientes
To: Arquitetura da Informação (em Português)
       <aifia-pt AT lists.ibiblio.org>
Message-ID:
       <n2t337262031004291603v3f17646dj9381d644493a4494 AT mail.gmail.com">n2t337262031004291603v3f17646dj9381d644493a4494 AT mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"

Trabalhei nos últimos 2 anos com métodos ágeis e concordo bastante com a sua
visão.

2010/4/29 Eduardo Rangel Brandão <brandaoedu AT gmail.com>

> Peterson,
>
> Ao fazer dessa forma, você está trabalhando de uma maneira linear,
> sequencial, que está morrendo (na verdade, em algumas empresas já morreu há
> muito tempo). Não se deve fazer um projeto como se cada passo fosse depois
> do outro... Procure discutir todos os aspectos da interface com a equipe e
> só depois partir pro layout.
>
> Além disso, não é o seu cliente que vai ter que tomar essa decisão sobre a
> posição do menu. É você junto com o designer da interface. Vocês vão
> construir a tela juntos. Enquanto um vai estar mais focado em
> funcionalidades e importância dos elementos, o outro vai pensar na posição
> desses elementos na tela.
>
>
> Abç,
>
> Eduardo Rangel Brandão
> brandaoedu AT gmail.com
>
>
> Em 29 de abril de 2010 13:58, Peterson Ramos <petersondrs AT gmail.com>escreveu:
>
> Concordo com o Poggi,
>> se o AI coloca algo importante como o menu na vertical no WF é por que ele
>> definiu que aquela é a melhor maneira para o site.
>> Eu só aceitaria a mudança de bom agrado se algum grande acontecimento
>> comprava-se a necessidade da mudança.
>> Digo aceitar de bom agrado pois se de pois de todas as explicações o
>> cliente bater pé gritar e falar que vai ser assim, ai não adianta é engolir
>> a seco e fazer a modificação.
>>
>> Aproveitando a deixa levanto outra questão.
>> Quais foram as maiores gafes que vocês cometeram ao apresentar um WF para
>> o cliente. Que vale se comentada para que outros também não a cometam.
>>
>> Abs
>>
>> 2010/4/29 Rafael Poggi <rpoggi AT gmail.com>
>>
>> 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
>>>
>>
>>
>>
>> --
>> Peterson Ramos
>> Designer Gráfico
>> + 55 21 8143 4329
>> http://pensarnaodoi.wordpress.com/
>>
>> . . . . . . . . . . . . . . . . . . . . . .
>> 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
>



--
Cid Boechat - Webdesign e Design de interfaces
----
http://www.fubap.org/cidboechat
http://www.flickr.com/photos/cidboechat/
@cidboechat
-------------- Próxima Parte ----------
Um anexo em HTML foi limpo...
URL: http://lists.ibiblio.org/pipermail/aifia-pt/attachments/20100429/ffbec6b3/attachment-0001.htm

------------------------------

Message: 2
Date: Thu, 29 Apr 2010 20:05:05 -0300
From: Isabela Abrantes <bela.abrantes AT gmail.com>
Subject: Re: [AI] wireframes x clientes
To: Arquitetura da Informação (em Português)
       <aifia-pt AT lists.ibiblio.org>
Message-ID:
       <x2i245130ab1004291605h59693eb4i7709d5404d34e7fc AT mail.gmail.com">x2i245130ab1004291605h59693eb4i7709d5404d34e7fc AT mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"

Então Eduardo, em relação a sua abordagem, creio que ela possa ser
problemática em alguns aspectos para algumas situações, inclusive a do
ecommerce, que foi o exemplo que usei.

Utilizei o exemplo do botão "enviar" em cima, pra exemplificar um absurdo.
Mas quero dizer que existem coisas que o designer não irá pensar, que
acredito ser papel do AI se focar.
Não cabe ao designer, por exemplo, imaginar todos os casos de uso diferentes
que impactarão na interface.

Com certeza se você deixar isso só não mão do designer ou se achar que
resolve isso apenas com sketches, seu projeto vai chegar ao final com um
monte de páginas não pensadas pelo layout.
Porque aí entra um dos muitos aspectos do AI, ele não pensa só em interface,
ele pensa na experiência do usuário como um todo, por isso, todas as
interações possíveis precisam ser pensadas e resolvidas.

Acho improvável que apenas com sketches você conseguisse mapear todas essas
saídas.
Talvez com um sitemap muito detalhado, você conseguisse, mas em vários
projetos muitas vezes foi só no wireframe que consegui "fechar todas as
saídas".

O que defendo não é que sketchs sejam uma solução ruim. O que eu defendo é
que em alguns casos ela resolveria tudo, em outros seria de pouca ajuda.
Que é exatamente o acontece com o wireframe se ele for aplicado a todo e
qualquer projeto, sem se entender a real necessidade do entregável (que às
vezes pode ser um documento formal pro cliente, às vezes apenas um rabisco
para o designer).

Portanto, reforço mais uma vez que eu não acredito que a solução esteja em
substituir um entregável por outro, e sim em focar na experiência do usuário
e no documento (ou mesmo um diálogo apenas, se for o bastante) que deixe o
planejamento dessa experiência mais claro possível para quem for criar o
layout e/ou desenvolver.

Acho que nossa diferença de visão se baseia inclusive no que é um wireframe.
Existem vários tipos de wireframes, navegáveis, estáticos, de alta ou baixa
fidelidade. Eu poderia utilizar inclusive softwares que você citou como o
Power Point, o Google Sites ou um papel para desenhá-lo. E inclusive, a
escolha desses diferentes formatos de wireframes também iriam variar de
acordo com a demanda do projeto. Na minha opinião, quase sempre um wireframe
diz muito mais sobre um site do que um documento de texto (do contrário,
estariamos replicando os documentos dos analistas de sistemas, tendo apenas
um foco maior na usabilidade, que eles não costumam ter). Mas se temos ainda
o desafio de criar outros modelos entregáveis, isso prova que esses
documentos ainda não atenderam a questão.

Até porque, é isso que os wireframes evitam: excesso de detalhes documentais
que não vão ser lidos por ninguém. Não concebo um wireframe como uma espécie
de relatório trabalhoso, imutável, cheio de especificações, sempre
navegáveis com todas as interações totalmente completas.  Aliás, a idéia do
wireframe é exatamente evitar um esforço desnecessário ou nas palavras do
Morville e Rosenfeld no urso polar "it's better to make such changes on
paper rather than reengineering the entire site at some point in the
future".

É por isso que você estrutura um wireframe, e não um layout. Porque é  mais
fácil saber antes se aquilo vai estar ali do que se aquilo vai estar ali e
vai ser azul, e vai ter gradiente e a fonte x.

Enfim, talvez o wireframe tenha se tornado desnecessário no seu dia-a-dia,
porque as interfaces que você trabalha sejam interfaces diferentes. Também
já foi desnecessário para mim em um projeto que era  um advergame enorme,
onde valeu mais a pena uma planilha gigantesca listando todos os estados de
tela diferentes e ações possíveis em cada estado, para que o designer
pudesse criar a partir daí. Geralmente em interações muito ricas, diferentes
devices ou games ele é de pouca ajuda mesmo. Por outro lado, já tive que
fazer um wireframe 100% navegável para uma interface que precisava ser
validada com muitos testes de usabilidade antes de passar para uma próxima
etapa de desenvolvimento.

Como eu disse, alguns tipos de projeto de interface, ele não é a solução
mais adequada para refletir o que foi projetado pelo AI. Mas isso não faz do
wireframe algo "cada vez mais desnecessário" como você afirmou em seu
primeiro e-mail. Acho que esse é o perigo do discurso, e acho que esse é um
risco que nenhum arquiteto deve assumir.
Insisto que a cada projeto a escolha do entregável (ou mesmo a opção por não
apresentar um entregável específico de AI), deve ser pensada exclusivamente
para situação e que nenhum profissional de UX deva assumir qualquer modelo
de entrega como um padrão para todos os seus projetos.

Abraços, Isabela


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

> Oi Renato, tudo bem?
>
> Os testes vão depender do estágio de desenvolvimento da interface. Para uma
> interface que está em fase de concepção você vai aplicar um tipo de teste
> (protótipo em papel, card sorting, questionários, entrevistas, grupo de
> foco, etc) e para uma interface que já está em uma fase mais adiantada (ou
> pelo menos alguma parte dela já está pronta) você vai precisar de outra
> abordagem (avaliação cooperativa, grupo de foco, teste de usabilidade,
> experimento controlado, etc.).
>
> Além disso, você tem outras questões, como o público-alvo da inteface,
> quantidade de usuários (dependendo do tipo de avaliação que você vai fazer),
> custos, infraestrutura para aplicar testes (vai fazer em uma sala, um
> laboratório), etc. e isso tudo vai ter influência nas suas decisões.
>
> Às vezes, dependendo do seu cronograma (ou do orçamento disponível para o
> projeto), você não vai conseguir testar a interface antes de lançar. Mas,
> para tentar minimizar isso, há um tipo de abordagem em interfaces que já
> estão em produção, com experimentos, testes A/B, etc., onde é realizada uma
> análise de métricas para saber quais são as páginas mais acessadas (e focar
> as suas estratégias e ações nessas páginas mais vistas), de onde os usuários
> chegam, para onde eles vão, por exemplo, ou com pequenas mudanças em alguns
> elementos na interface, para saber se acontece uma melhora na performance
> (como a mudança de cor, ou até mesmo de layout, de um box e o quanto isso
> aumenta a taxa de cliques nesse box; ou com testes onde um elemento é
> exibido para uma quantidade de pessoas em uma determinada posição e para
> outras pessoas num local diferente da página e, no final, são comparadas as
> taxas de cliques para descobrir qual a posição mais favorável).
>
> Não sei como são os testes que você utiliza, quantos usuários, como
> consegue esses usuários (se recorre a uma empresa de recrutamento, se possui
> um banco de dados com candidatos, etc.). Se puder, depois me conta um pouco
> mais sobre isso.
>
> Só não sei se você entendeu meu ponto. Eu não estou preocupado com a
> quantidade de entregáveis para a aprovação do cliente, muito menos acho que
> o usuário deve ficar em segundo plano em função disso. Eu disse que sou a
> favor de trabalhar de uma maneira mais ágil, diminuindo a quantidade de
> documentação e desburocratizando algumas etapas do trabalho. Como a
> discussão começou com wireframes, eu mencionei que não acredito mais nesse
> documento porque, para mim, aumenta o tempo de projeto e o cliente não
> entende na hora de aprovar.
>
> E concordo totalmente com você, acho muito válido fazer o cliente
> compreender o modo como trabalhamos. Até escrevi isso mais cedo, acho que
> foi em resposta para a Melina, se não me engano... Só não acho que um monte
> de documentos são a melhor maneira de fazer isso. Esses documentos não são a
> finalidade do projeto, são apenas os meios para atingir o objetivo final,
> que é criar uma interface bem projetada e com foco no seu público-alvo,
> atendendo suas necessidades e requisitos. Então, se a intenção é fazer com
> que seu cliente entenda a importância e necessidade do trabalho, acho melhor
> fazer isso na hora que apresentar a sua proposta/orçamento para ele,
> mostrando quais serão as etapas de projeto, quais serão os entregáveis
> (dando alguns exemplos), qual o cronograma e custos de cada etapa, etc. Mas,
> tenho certeza que o que irá impressionar mais o seu cliente será o produto
> final muito bem executado, simples de usar, fácil, intuitivo e ele (cliente)
> tendo o retorno do seu investimento.
>
>
> Abç,
>
> Eduardo Rangel Brandão
> brandaoedu AT gmail.com
>
>
> Em 29 de abril de 2010 17:30, Renato Monteiro <
> renato.renatomonteiro AT gmail.com> escreveu:
>
> Boa tarde, Eduardo,
>>
>> eu gostaria que você me esclarecesse uma coisa que tive dificuldade de
>> identificar nos processos que você descreveu: como e quando ocorrem testes
>> de usabilidade para avaliar se determinadas soluções atendem ou não às
>> necessidades do usuário?
>>
>> Pelo meu modo de ver as coisas, o foco nos entregáveis vislumbrando única
>> e exclusivamente a aprovação por parte do cliente estão colocando em segundo
>> plano o usuário final. Para levar algo ao cliente eu costumo criar
>> protótipos (normalmente utilizando o axure) com um WF razoavelmente bem
>> detalhado mas longe de ser um layout finalizado. Submeto este protótipo a
>> testes junto a grupos de usuários para validar as soluções de interface
>> pretendidas. Todo o processo até aí é compartilhado entre designers e AI's.
>>
>> Acho válido citar a metodologia de trabalho que empregamos aqui na
>> empresa, o SCRUM (XP), pois a abordagem também influencia no tipo de
>> material entregável. Eu entendo o seu ponto de vista quando você diz que o
>> que importa para o cliente é o layout finalizado, sob penalidade dele não
>> compreender as etapas de concepção e implementação do projeto. No entanto,
>> acho que é válido fazê-lo compreender o modo como trabalhamos com o intuito
>> de disseminar a complexidade que envolve a nossa profissão. Só com esta
>> compreensão poderemos requerer o reconhecimento que tanto nos falta (vide a
>> última pesquisa apresentada aqui na lista).
>>
>> Eu ainda prefiro ser metódico (óbvio que respeitando a natureza do projeto
>> - WF para 3 páginas?) pois me sinto mais confortável trabalhando desse modo.
>>
>> Assim como o Gino, devo confessar que concordo com várias das mensagens
>> daqui.
>>
>> Abs,
>> Renato Monteiro
>>
>> Em 29 de abril de 2010 17:15, Eduardo Rangel Brandão <
>> brandaoedu AT gmail.com> escreveu:
>>
>> Isabela,
>>>
>>> Eu não faria um e-commerce só com sketches. Faria com discussões baseadas
>>> em sketches e depois partiria para os layouts. Se wireframes forem
>>> necessários, pode até rolar de fazer um ou outro, mas em um nível mais
>>> macro, apenas para estudar algumas questões e sem grandes detalhamentos.
>>>
>>> Sobre a documentação, os próprios sketches já podem conter esse
>>> detalhamento. Se for necessário, uma documentação auxiliar pode ser
>>> produzida sim em um wiki, google sites, google docs, power point, etc. Mas
>>> nada muito aprofundado, senão você vai perder muito tempo gerando relatórios
>>> e especificações detalhadas, quando poderia estar focada nos problemas da
>>> interface a serem resolvidos ao invés de formalizar tudo em uma
>>> especificação.
>>>
>>> Sobre o fato de esperar que um designer pense nas questões da interface,
>>> acho que ele tem que pensar nisso sim. Para mim, se a equipe tem um designer
>>> e um AI, os 2 têm que trabalhar juntos para desenvolver a interface. Não
>>> acho que o designer tem que ser apenas o cara que vai colorir pixels e não
>>> pensa nas questões da interface. E pelo amor de Deus! Se ele entender que um
>>> botão "Enviar" vem antes de um formulário, é melhor trocar de designer, né?
>>> Se ele tem a necessidade de que alguém o informe sobre a posição do botão em
>>> um formulário, ele não precisa de um AI como dupla de criação. Na verdade,
>>> ele precisa de uma babá!
>>>
>>> Não vejo problema de criar um doc com uma lista de elementos. Já
>>> trabalhei dessa forma, inclusive, e deu super certo. É claro, não basta
>>> entregar a lista. Tem que ter uma conversa, uma troca de idéias constante
>>> enquanto a interface é desenhada. E concordo contigo. Cada caso é um caso.
>>> Isso não significa entregar essa lista em todos os projetos. Eu mesmo ainda
>>> faço wireframe de vez em quando...
>>>
>>> E a minha questão não é a negação do wireframe. Já fiz muitos wireframes
>>> ao longo da minha vida profissional e, baseado nas situações que eu vivi, só
>>> digo que é mais rápido trabalhar de uma outra forma, com outro tipo de
>>> entregáveis. Pelo que tenho visto no meu dia-a-dia, o wireframe se tornou
>>> algo desnecessário. E para mim, o entregável do projeto é a própria
>>> interface, é isso que vai demonstrar para outras pessoas o que foi projetado
>>> e não a documentação. Essa documentação é só uma consequência do projeto,
>>> não é uma finalidade. E só servirá no caso de furuas manutenções, futuros
>>> releases, porque no dia-a-dia ninguém vai parar para ler uma especificação
>>> (que, provavelmente, só vai ficar pronta no final do projeto - a menos que a
>>> empresa ainda trabalhe no esquema de metodologia clássica, fazendo o projeto
>>> em water-fall e, por conta disso, tenha a fase específica de fazer toda a
>>> documentação para, só depois, partir para os layouts).
>>>
>>>
>>> Abç,
>>>
>>> Eduardo Rangel Brandão
>>> brandaoedu AT gmail.com
>>>
>>>
>>> Em 29 de abril de 2010 15:53, Isabela Abrantes <bela.abrantes AT gmail.com>escreveu:
>>>
>>> Eu creio que se confunde o "desapego" ao wireframe com a negação do
>>>> wireframe.
>>>> Acho que o bom AI precisa saber entender qual é a necessidade de
>>>> entregáveis de cada projeto.
>>>> Nem sempre o wireframe é a melhor resposta, mas isso não significa dizer
>>>> que o wireframe não é resposta nunca.
>>>>
>>>> Como você faria um e-commerce, por exemplo, só com sketches?
>>>> E como documentar as decisões pra um equipe grande em papéis e
>>>> rascunhos? Tirando xerox desses arquivos?
>>>>
>>>> Acho um pouco imprudente essa visão "*Wireframe (...) só indica os
>>>> elementos que devem existir na interface e a importância dos mesmos*."
>>>> Isso não é "só", isso é fundamental, não se pode esperar que o designer
>>>> pense nisso.
>>>> Qual seria a alternativa, entregar um .doc com uma lista de elementos
>>>> pra ele incluir na página? Sem nenhuma hierarquia, podendo ele entender que
>>>> um botão "Enviar" vem antes de um formulário?
>>>> Não creio que isso sirva no caso de sistemas / interfaces mais
>>>> complexas.
>>>>
>>>> Entendo que nem todo projeto demanda wireframes como entregáveis, e
>>>> entendo que o papel do arquiteto é muito mais amplo do colocar placeholders
>>>> em seu lugar.
>>>> Mas entre entender isso e achar que o wireframe é 'o vilão' da história,
>>>> é um pouco reducionista e perigoso.
>>>>
>>>> Nosso papel é projetar uma experiência de uso de uma interface. O
>>>> entregável é a parte final desse projeto, mas ele é fundamental,
>>>> independente do formato que seja, pois é a forma como vamos demonstrar para
>>>> outras pessoas o que foi projetado.
>>>> Tenho visto essa defesa árdua anti-wireframe como se ela fosse a única
>>>> maneira de nos colocar em uma posição mais estratégica dentro da empresa.
>>>> Enfim, minha visão é que um pouco demais toda essa campanha focando o
>>>> wireframe como um entregável ruim quando a questão deveria não ter o foco
>>>> nunca no entregável, e sim na necessidade do projeto.
>>>>
>>>> Por isso acredito que a resposta a questão inicialmente proposta nesse
>>>> tópico, também é a mesma: mostrar o wireframe pro cliente vai depender do
>>>> cliente e do projeto.
>>>> Há casos em que mostrar essa etapa irá poupar boas horas de
>>>> desenvolvimento de layout em cima de estruturas que não serão aproveitadas.
>>>> Em outros casos, essas aprovações só vão demandar horas do projeto pois
>>>> o cliente só irá fazer considerações dessa estrutura quando ver isso no
>>>> layout.
>>>> Mas mais uma vez, é uma questão de bom senso.
>>>>
>>>> Abs,
>>>> Isabela
>>>>
>>>> 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
>
-------------- Próxima Parte ----------
Um anexo em HTML foi limpo...
URL: http://lists.ibiblio.org/pipermail/aifia-pt/attachments/20100429/6aaa99de/attachment.htm

------------------------------

. . . . . . . . . . . . . . . . . . . . . .
Ao responder, elimine o texto nao essencial
de mensagens anteriores e evite formatacao.

AIfIA-pt mailing list
AIfIA-pt AT lists.ibiblio.org
http://lists.ibiblio.org/mailman/listinfo/aifia-pt


Fim da Digest AIfIA-pt, volume 326, assunto 16
**********************************************

-- 
Marcos Souza
Designer
Gtalk: marcoshsouza AT gmail.com
Skype: marcoshsouzaa
Twitter: twitter.com/marcossouza
www.cesar.org.br
+55 (81) 8810.6607
+55 (81) 9642.3080