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

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

Bom Rafael,

Eu só posso citar o caso da Globosat e da Globo.com, empresas onde eu trabalho/trabalhei dessa forma, utilizando uma abordagem mais ágil. E acredite, dá certo! Os produtos continuam sendo desenvolvidos e a documentação menos formal não impede que a experiência deixe de ser pensada de forma detalhada. Existem "arestas" a serem aparadas? É claro! Mas os resultados têm sido positivos, independente disso.

Já vi muitos artigos, posts, sites, etc. que apontam uma forma parecida de se trabalhar em outras empresas de tecnologia, como Google, Microsoft, etc. Talvez outros colegas da lista possam falar se eles trabalham dessa maneira nas empresas deles também.

Abç,

Eduardo Rangel Brandão
brandaoedu AT gmail.com

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

Eu ainda estou querendo saber como sem um wireframe com uma boa especificação funcional (depenendo do tamanho do projeto, da nacessidade do cliente, e bla bla bla) vcê vai conseguir passar não só para o designer mas como para a equipe de desenvolvimento as soluções sugeridas enquanto AI.

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 30 de abril de 2010 00:21, Eduardo Rangel Brandão <brandaoedu AT gmail.com> escreveu:

Isabela,

Concordo que existem "N" questões que o designer não irá pensar e que essas questões são funções e responsabilidades do AI. Mas também não dá para tratar o designer como um mero operador de photoshop, que só faz o que o wireframe determina. Por isso os 2 (designer e AI) formam uma dupla de criação, cada um complementando o trabalho do outro. Ou a mesma pessoa desempenha as 2 funções dentro da equipe, o que eu acho melhor ainda (e também é mais um motivo para eliminar o wireframe, senão o coitado vai fazer a mesma coisa 2 vezes).

Também concordo que, dependendo do projeto, diferentes enfoques serão dados. E diferentes entregáveis serão produzidos. Só não acho que o AI dependa da produção do wireframe para conseguir conceituar e desenvolver o projeto. Quando você deu o exemplo dizendo que só conseguiria produzir o site de e-commerce ao fazer um wireframe, acho que você fica muito limitada, muito amarrada a este documento. E não vai ser isso (wireframe) que vai fazer o site sair do papel (ou do wireframe). Seu projeto será desenvolvido a partir de conceitos, independente de como eles serão apresentados. Já aconteceu com você de ter uma idéia sobre uma interface, começar a fazer um wireframe para refletir essa idéia e, pela demora na produção do wireframe, alguns detalhes dessa idéia se perderam? Já tentou, ao invés de começar a produzir o wireframe, fazer um esboço dessa idéia no papel? O desenho/esboço conseguiu representar a idéia que você estava querendo passar para a equipe? Por isso eu acho que o sketch resolve melhor a questão. Pelo menos para mim. No final, não é isso que será entregue para o cliente, nem o wireframe, nem o site-map ou a lista de funcionalidades. Os layouts é que serão utilizados para a aprovação do projeto, com simulações de fluxos e funcionalidades se for necessário.

Logo, para mim, projetar a melhor experiência de uso independe de um wireframe. Eu também já enfrentei situações que o site-map foi a melhor saída para entender todos os fluxos. Em outras situações os wireframes serviram sim para entender melhor o fluxo do projeto. Em tantas outras, uma lista de funcionalidades escrita em post-its (que serviram para decidir a ordem de prioridades durante o brainstorm) foi utilizada como ponto de partida. Além disso, trabalhar dessa forma (sketch), é mais rápido para discutir os conceitos e soluções de projeto, resultando em algo parecido com a frase do Morville e Rosenfeld que você citou abaixo (it's better to make such changes on paper rather than reengineering the entire site at some point in the future). Aliás, com o sketch é mais rápido ainda realizar tais mudanças. Se você vê o wireframe como uma forma de evitar um esforço desnecessário, eu vejo o sketch como uma forma de evitar o esforço de fazer um wireframe no Axure, no Power Point, no Visio e afins (já que existem maneiras mais fáceis e mais rápidas de comunicar suas idéias para a equipe). Como eu disse em uma mensagem anterior, enquanto você está produzindo um wireframe (seja o nível de detalhamento que for), é uma oprtunidade perdida para conceituar e desenvolver a experiência do usuário. Além disso, se a questão era apresentar ou não o wireframe para o cliente (ou qualquer outro documento), não vejo onde o uso dos sketch pode prejudicar o processo de projetar a experiência do usuário (porque o que interessa para o cliente, no final, é ver a interface funcionando). Por isso eu prefiro não ficar preso a um tipo específico de documento, prefiro ter uma flexibilidade maior na hora de realizar um projeto e escolher a forma mais adequada de produzir os entregáveis.

Aproveitando a citação do Morville e Rosenfeld, o livro do urso polar é um clássico, se tornou a bíblia dos arquitetos da informação, etc. Mas, lembre-se que a sua primeira edição é de 1998. Em 12 anos muita coisa pode mudar, inclusive as metodologias e processos de trabalho adotados pelas empresas. No final de 2007 e início de 2008 quase ninguém falava de scrum, por exemplo. Hoje ele virou o pretinho básico da maioria das empresas de internet (em apenas 2 anos). Tudo bem que o livro do urso polar já foi revisado e reeditado em 2002 e depois em 2006, mas não foi totalmente reescrito. Por isso, eu acho que o bom senso se deve ao fato de conhecer as recomendações, as boas práticas, a forma clássica de se trabalhar e, mesmo assim, saber onde estas recomendações e boas práticas podem ser "quebradas" para uma otimização de tempo, otimização de produção e de entrega do projeto, evitando a realização de coisas desnecessárias e focando a atenção em coisas que são importantes, como novas funcionalidades ou soluções para novos problemas que possam surgir ao longo do projeto.

Não sei se você trabalha de forma linear, produzindo entregáveis para serem entregues para a sua equipe e só depois disso eles dão prosseguimento à próxima etapa do projeto. No meu caso, o sketch é pensado em conjunto com a equipe e o papel do arquiteto da informação é propor soluções que irão proporcionar a melhor experiência do usuário, propor funcionalidades e também propor um produto, sem ficar restrito apenas à experiência do usuário (pensando também nas decisões estratégicas, no negócio que aquela interface representa, enfim, não pensar somente no projeto centrado no usuário, mas na concepção do produto como um todo, nos futuros releases, na análise de métricas, etc.). Já se falou tanto nessa lista em valorizar o trabalho do AI. Será que a forma de valorizar esse trabalho é fazer com que o AI continue assumindo apenas um papel técnico dentro da empresa, entregando todos os documentos que a metodologia clássica (do livro do urso polar) determina, falando "amém" para tudo o que Morville e Rosenfeld escreveram? Ou será que esse AI também pode assumir um papel mais estratégico dentro da empresa? Isso não vai impedir dele continuar a pensar na melhor experiência para o usuário. Na verdade, vai até ajudar.

Você fala da sua preocupação quando eu digo que o wireframe é desnecessário. É a minha opinião, ora bolas. Isso não é uma lista de discussão? Estou expondo a minha maneira de ver isso tudo e a forma como o assunto é encarado em algumas empresas. Concorda quem quiser e isso não precisa ser visto como algo perigoso. Não falo isso de forma leviana e irresponsável, falo com base nas experiências que eu já tive e nos lugares onde já trabalhei / onde trabalho atualmente. E já estou nesse mercado há bastante tempo, acredite!

Enfim, você não vai mudar a sua opinião, eu também não vou mudar a minha. O importante é que você está trabalhando da forma que acha mais adequada e confortável para você e eu da forma que acho mais adequada para mim. Se funciona para você, ótimo! Te garanto que está funcionando para mim! :-)

Abç,

Eduardo Rangel Brandão
brandaoedu AT gmail.com

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

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

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