“To the designer, great design is beautiful design. A significant amount of effort must be placed into making the product attractive. To the client, great design is effective. It must bring in customers and meet the goals put forth to the designer in the original brief. To the user, great design is functional. It’s easy to read, easy to use and easy to get out of it what was promised… Truly great design, then, is when these three perspectives are considered and implemented equally to create a final product that is beautiful, effective and functional.” – Joshua Johnson
Acho que esta leitura pode complementar bem a discussão que sempre é gerada em torno do assunto das diferenças entre as perspectivas do designer, do cliente e do usuário. Cai bem para aqueles que ficaram com a curiosidade aguçada pela leitura do post sobre a discórdia que existe entre os caras da 37 Signals e o Don Norman.
Ontem, um tweet do Pedro Belleza me chamou a atenção mais uma vez para um assunto que é muito importante e que, na semana passada havia (novamente) caido no meu colo*. É algo antigo; data de 2008. Trata-se da discussão gerada entre Don Norman e o pessoal da 37 Signals gerada – simplificadamente falando – em função do posicionamento da empresa na concepção de seus produtos (basicamente eles argumentam que desenvolvem para si mesmos e que isso é o suficiente pois eles são o público de seus produtos) que vai em direção diametralmente oposta ao que Norman argumenta ser o mais eficiente (devemos desenvolver pensando no usuário e não em nós mesmos, mesmo que sejamos parecidos com nossos usuários).
A coisa, que começou com uma matéria publicada na Wired, que foi prontamente respondida por Norman e treplicada pelo pessoal da 37 Signals, é, desde então, assunto de algumas de minhas aulas sobre Design Centrado no Usuário quando aobordo justamente a importância de trabalharmos com dados reais de usuários, não subestimento estas informações e abandonando a arrogância tão fácil de surgir na personalidade de um designer quando este acha que sabe exatamente como o usuário pensa. Embora antiga e já conhecida por parte de meus alunos e ex-alunos (pelo menos os que cursaram Usabilidade comigo desde então) acho que nunca formalizei nada a respeito em texto e enxerguei no post do Pedro, uma boa oportunidade.
Então vamos lá.
Por qual motivo isso é importante?
Em primeiro lugar, porque é complicado fazer afirmações controversas como as que o pessoal da 37 Signals fez e sair ileso. Especialmente quando se trata de ir contra algo que é comprovadamente necessário (compreender os consumidores e desenvolver para eles). Isso é tão claro que em sua tréplica, eles atenuam a coisa, meio que tentando sair pela tangente dizendo que se importam com seus consumidores…
A complicação maior, no entanto, não está nas afirmações em si, mas sim nas consequências delas. A principal é ver muita gente achando que o jeito certo de desenvolver é esse – especialmente porque os produtos da 37 Signals fazem sucesso. E, para quem busca resultados imediatos e não gosta de fazer muita interpretação do que lê ou vê, este é um sinal de que eles estão certos e que o Norman está errado.
E a coisa não é bem assim.
Para ajudar em minha argumentação, devo citar Jared Spool, que costuma deixar bem claro que desenvolver pensando no usuário não implica em fazer apenas (ou prioritariamente) testes de usabilidade. Para Spool, implica em observar os usuários usando seus produtos e aprender com as dificuldades que eles encontram para melhorar o produto em uma próxima iteração. Como exemplo, Spool costuma usar a Apple, que – notoriamente – não faz testes com usuários (e para os mais rasos, poderia ser um exemplo que corroborasse com os postulados da 37 Signals), mas isso não quer dizer que ela não pratica o UCD. A Apple faz o que Spool costuma recomendar: observa. Algo mais ou menos parecido com o que a IDEO faz em seus trabalhos e é muito bem mostrado no famoso vídeo sobre o processo de desenvolvimento deles (assista abaixo ou aqui).
O que Spool, a Apple e a IDEO fazem é Design Centrado no Usuário em procedimentos que eles, às vezes, não chamam de DCU ou mesmo de procedimentos com usuários. E, novamente de maneira simplificada, apenas nisso se diferem do que Norman argumenta.
Portanto, o que dá para perceber é que a posição de Jason Fried e David Heinemeier (da 37 Signals) é tão rasa quanto quem argumenta em seu favor, e ainda cita a Apple como empresa que não faz testes com usuários, por exemplo. Tenho certeza que muita gente vai concordar (ao menos em parte) comigo quando argumento que esta seleuma toda se deve apenas a uma questão de interpretação. Mas o que é grave é que isso acontece apenas em parte. Há uma outra parte que fecha os olhos para justamente o fato de ser uma questão de interpretação. Observar usuários é eficiente e ajuda muito o desenvolvedor a compreender seu público e melhorar seu produto. Não fazer isso e falar que não fazer isso é algo bacana é, no mínimo, muita ingenuidade.
Por fim, a importância dessa coisa repousa no fato de que muita gente acaba achando que não é necessário fazer qualquer procedimento com usuários e, ainda assim, ter produtos excelentes. A verdade, no entanto, passa longe disso.
*Por qual motivo isso chamou novamente a minha atenção?
Na semana passada, estava colocando em dia a audição do The Big Web Show quando, no episódio 10 lá estava o Jason Fried falando de como ele, na 37 signals, desenvolve as coisas que faz para si mesmo e, se você não se adapta ao produto, provavelmente não tem que usá-lo.
Muito bacana este texto onde o Nathan Curtis explica uma maneira de se conduzir o processo de construção de uma biblioteca de User Experience. Mas… O que vem a ser uma biblioteca de UX?
Em primeiro lugar, uma biblioteca de recursos nesse sentido representa uma coletânea de informações que podem ser aproveitadas em diferentes projetos de diferentes produtos eu até mesmo de diferentes clientes. O uso de uma biblioteca proporciona um ganho extraordinário de tempo e economia considerável de recursos pois permite a reunião (no sentido de consolidação) de uma série de informações (a biblioteca) que serão compartilhadas por muitos membros de uma equipe (ou até de várias equipes).
Uma biblioteca de UX, então, representa a consolidação de documentação, instruções e até elementos que devem ser usados em projetos de médio ou grande porte que vão permitir que seja criada uma experiência de interação eficiente, uniforme e adequada para seus usuários. O texto foi referenciado em um post do Jared Spool onde ele contextualiza as conflitantes posições que ele (Jared) e Curtis tinham acerca do conceito de uma biblioteca de UX. Enquanto para Spool argumentava que uma biblioteca deveria representar as ações futuras, Curtis discordava explicando que, na verdade, seriam um retrato do passado. Confesso que tendia a concordar com Jared Spool, mas a argumentação de Curtis é bem bacana e vale a leitura. Imagino que – da mesma forma que a minha concepção balançou – a sua também pode balançar.
Enfim; voltando ao texto em questão… Nele, Curtis argumenta que o processo, que é bem complexo, envolve quatro grandes áreas ou fases:
Análise – Entender o que é uma biblioteca de UX, para que vai servir e como se encaixará em seu projeto;
Consolidação – Reunir a documentação e consolidar todas as instruções e direcionamentos para aplicação;
Adoção – Comunicar, informar a equipe e incentivar a participação;
Adaptação – Administrar e melhorar ao longo do tempo promovendo iterações e incrementando a documentação.
Então, vale a pena ler o texto inteiro pois nele você vai ter uma série de dicas acerca do processo de construção – e aplicação, o que é importante – de uma boa Biblioteca de User Experience.
