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

[Carlos Rosemberg <carlbberg AT gmail.com>]

Olá pessoal,

Gostaria de deixar meus 2 centavos. A utilidade dos wireframes, assim como várias outras técnicas, métodos, ferramentas, etc., vão variar de projeto para projeto. São muitas variáveis em jogo, por exemplo:

Objetivo do WF (aprovação interna? externa? testes? etc...)

Estágio do projeto

Tamanho do projeto

Natureza e complexidade do produto

Tamanho da equipe

Perfil da equipe

Perfil do cliente (executivo? técnico?)

Expertise do profissional de AI/UX

Ferramentas disponíveis

Necessidade de documentação

Prazo

Recursos financeiros

...

<coloque sua variável aqui>

...

etc.

Ou seja, não dá para dizer que se usar wireframe é recomendado ou não sem se conhecer boa parte dos itens da lista acima. Tudo é relativo.

Então, o que posso falar depois de alguns anos na batalha, é que não devemos focar na técnica ou ferramenta, mas sim nas necessidades do projeto e claro, do seu cliente. Foi assim, inclusive, que essas técnicas e ferramentas foram criadas.

[]'s

CARLOS ROSEMBERG
@carlbberg
www.carlosrosemberg.com

2010/4/29 Isabela Abrantes <bela.abrantes AT gmail.com>

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