Ninguém compra um carro apenas por causa do motor. As pessoas não buscam apenas resolver seu problema de transporte. Hoje em dia, ninguém mais compra um celular só porque ele faz ligações. Então, por que o Software tem apenas que resolver um problema, mesmo que de forma feia?
Desenvolvimento de Software, ao contrário de outras áreas como construção civil e arquitetura ainda é uma área relativamente nova. Nestas e em inúmeras outras áreas num primeiro instante não havia preocupação com a estética por uma questão de prioridade: prioriza-se a solução do problema essencial. Mas passada esta fase (que acredito que estamos chegando próximo no que diz respeito ao desenvolvimento de software) começa a pesar os fatores humanos, os fatores psicológicos, etc. Como diz Donald Norman “As coisas mais bonitas funcionam melhor”. Por que? Porque somos seres humanos e as coisas mais bonitas colocam nosso cérebro num estado muito mais propicio para uma determinada atividade: seja dirigir um carro, manusear um celular ou usar uma aplicação. Aqui entra uma outra tese minha junto com o TI-Centrismo Vs. Usuário-Centrismo que é o Trade-off com Foco no Valor Agregado.
Desenvolver softwares é também saber tomar as decisões certas com foco no todo e não em partes isoladas. E este conceito é sutil mas poderoso (e acredito que possui certa relação com a Gestalt). Daí a importância do Trade-off – que para quem não sabe é, basicamente, você fazer uma escolha entre um número de opções mas sempre sair perdendo umas coisas e ganhando outras. O grande problema do Trade-off em desenvolvimento do Software é que ele é influenciado pelo TI-Centrismo e não pelo valor agregado à experiência final do usuário como deveria ser.
Vejam exemplos:
A tabela acima deixa duas coisas bem claras:
1. Desenvolvimento sempre ganha
2. Estética sempre perde
Porém, dada a premissa de que a estética é importante porque somos seres humanos, será que, visando o produto final, visando a experiência como um todo, não seria interessante considerar eventualmente fazer um POG do Bem para oferecer uma melhor estética pois o usuário vai se sentir melhor com a sua aplicação? Será que você não deveria considerar que a Usabilidade não precisa ser a melhor do mundo, num dado contexto, para deixar o Designer Gráfico mais livre para trabalhar a estética? (sim, a Usabilidade cria restrições para o Designer Gráfico. Perguntem aos Designers se eles não se sentem um tanto limitados pelos Wireframes).
Quando eu falei da idéia do Trade-off com foco no valor agregado com o Luciano Lobato da DClick ele disse: mas todo Trade-off não deveria ser com foco no valor agregado? Sim, deveria, mas não é! Por quê? Porque na maioria das empresas cada tipo de profissional olha para o seu próprio umbigo e não para o software como produto final.
Que designers e programadores não se bicam não é novidade. Mas isto não é uma questão pessoal (pelo menos não no começo) . O problema, paradoxalmente, é que cada um de nós quer fazer o melhor trabalho possível. O Arquiteto da Informação quer oferecer a melhor usabilidade. O Programador quer fazer o melhor código. E o Designer quer fazer a aplicação mais bonita. Mas como cada um trabalha de forma independente, o que geralmente acontece é que um complica a vida do outro e ninguém sabe de fato o que é mais importante para a experiência final do usuário como um todo – chamo isto de Egocentrismo Funcional: o ego criado pela função que você exerce o impede de enxergar o que é melhor para o produto final. Desta forma, o programador se recusa a implementar algo muito complexo definido pelo arquiteto de informação – mas perde um baita tempo aplicando patterns desnecessários. O arquiteto de informação se recusa a mudar um wireframe sugerido pelo designer para deixar as coisas mais bonitas – e não pensa que talvez tal mudança agregue muito mais em estética do que perde em Usabilidade. Enfim, quando nenhum destes profissionais olham para o software como um todo, o que eles mais fazem é criar restrições que impactam negativamente o trabalho dos demais. E, além disso, quando se trata de tomar uma decisão isto não é deliberado e sim imposto por uma questão hierárquica (quem manda) ou pelo TI-Centrismo (Estética perde sempre. Usabilidade perde sempre.)
O POG do Bem nada mais é do que um exemplo de Trade-off com foco no valor agregado envolvendo programação e estética/usabilidade. Vamos agora a um exemplo de Usabilidade Vs. Estética.
Antigamente na DClick os arquitetos de informação definiam a usabilidade e depois restava ao Designer colorir os Wireframes. Certa vez uma alteração proposta pelo designer estava para ser recusada (como freqüentemente acontece) com argumentos dos arquitetos do tipo:
- Isso é ruim. O usuário terá que dar dois cliques no lugar de um.
Como eu estava de fora, observando o produto como um todo, eu perguntei:
- Mas espere um pouco! Com que freqüência ele terá que dar dois cliques?
- Não muita. – Responderam os arquitetos.
- Então isso é realmente um problema?
- Não, não é um problema grande!
- Então devemos priorizar a estética que no final das contas vai agregar mais à solução, visto que a perda de usabilidade neste caso é insignificante.
Suponha que na sua empresa o Arquiteto de Informação tenha mais “moral” que o designer, o que aconteceria? Suponha que o TI-Centrismo impere na sua empresa e que a mudança proposta pelo designer vai gerar certa complexidade, o que aconteceria?
Isto é Trade-off com foco no valor agregado! Você precisa abstrair e pensar num contexto maior: o produto final. Assim, não se deve tomar como regra a tabela de tabela de trade-off tradicional onde o desenvolvimento sempre ganha e a estética sempre perde. Não deixe esta tabela, que talvez esteja implicitamente arraigada na cultura da sua empresa, influenciar você!
O que temos que ter em mente é que nosso cérebro (novamente ele) não avalia nada isoladamente. Assim, o usuário falar se uma aplicação é boa depende do conjunto da obra. Por isso precisamos encontrar um equilíbrio entre a estética e a parte funcional. As vezes o programador deve deixar de fazer algo assim tão otimizado, pois talvez não seja necessário, para dedicar mais tempo na implementação de uma animação que agrega valor ou fazer bem um skin numa parte do software que o usuário passa a maior parte do tempo. As vezes você deve deixar de querer a melhor usabilidade do mundo se o problema de usabilidade não for assim tão grave e, por outro lado, isto deixa o designer livre para fazer algo realmente mais bonito. Por que? Porque é disso que o usuário vai lembrar quando ele pensar sobre o software. Não digo que ele vai lembrar APENAS da estética. Não digo que ele vai lembrar APENAS do funcional. Ele vai lembrar do conjunto da obra (Gestalt novamente). Ele vai lembrar das animações e isso o fará pensar que, junto com outras coisas, o software é bom. Ele vai lembrar do que ele pode fazer (funcionalidades) e isso o fará pensar que o software, em conjunto com a estética, é bom. É isto que é a experiência do usuário: o todo, não as partes isoladas. Então, refazendo a tabela de trade-off ela ficaria assim:
Isto é Trade-off com foco no valor agregado e não em paradgmas arraigados na cultura das organizações influenciados pelo TI-Centrismo ou por algum tipo de hierarquia burra.
