Skip to Content.
Sympa Menu

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

aifia-pt AT lists.ibiblio.org

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

List archive

Chronological Thread  
  • From: Eduardo Rangel Brandão <brandaoedu AT gmail.com>
  • To: Arquitetura da Informação (em Português) <aifia-pt AT lists.ibiblio.org>
  • Subject: Re: [AI] wireframes x clientes
  • Date: Thu, 29 Apr 2010 18:46:24 -0300

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




Archive powered by MHonArc 2.6.24.

Top of Page