Construir em cima de uma idéia é como construir um prédio. Você tem que começar pela base identificando sua premissa principal. Quando você tem uma base sólida é mais fácil construir sobre ela. As ideias e premissas posteriores, que estarão nos andares de cima, surgirão com naturalidade e se desenvolverão rapidamente.

Mas não saber qual é a premissa principal é como mexer na base o tempo todo depois de alguns andares já terem sido construídos. Quando você faz isso, inevitavelmente, você abala as estruturas. Pode até ser que você consiga concluir o que está construindo, mas não demora muito a ruir.

Qualquer semelhança com a realidade não é mera coincidência. Isto quase nunca acontece, não é mesmo?

Este episódio foi editado. Aqui está o link para informações sobre o original no site da Fox.

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.

“Não ouça os compradores, eles não sabem o que querem” – Steve Jobs.

Algo parecido acontece com os usuários em minha opinião.

“Saber o que quer” é diferente de “saber o que precisa”. O usuário sabe o que quer, mas você NÃO DEVE fazer o que ele quer, você deve fazer o que ele precisa!

O que usuário quer num primeiro momento vai deixá-lo com a falsa impressão que o projeto está indo bem. Mas depois de um tempo ele verá que não é bem assim. Depois de um tempo ele vai querer mudar para o que ele precisava mas não sabia.

O problema de desenvolver com foco no que o usuário quer é que isso é baseado em desejo e como tal é rotineiramente distorcido pelas impressões. Desenvolver baseado no desejo dos usuários o leva a assumir premissas e criar restrições erradas para o desenvolvimento do Software. Isso complicará o seu projeto e provavelmente levará a resultados pouco satisfatórios. O problema é que o usuário vai culpar você por isso e nem vai lembrar das informações imprecisas que ele lhe passou sobre o que ele desejava.

Sim, o usuário não vai lhe dizer o que ele precisa porque ele não sabe! Pior, por sua natureza, entender o que o usuário realmente precisa é mais “arte” do que ciência. Você precisa saber lidar com pessoas. Você precisa saber que o usuário é um ser humano como outro qualquer e que está muito confuso sobre o seu problema. O usuário define seus softwares tal como um casal apaixonado olha para o céu e vê cachorrinhos nas nuvens. E ele faz isso porque o nosso cérebro funciona assim: por associações. É por isso que vira e mexe ele olha outro software que não tem nada a ver com o seu problema e diz: eu preciso disso! Então você começa a desenvolver e aprende a duras penas que não era nada daquilo… e você muda um pouco aqui, muda um pouco ali e quando vê já está com um Software Frankenstein nas mãos.

O usuário define seus softwares tal como um casal apaixonado olha para o céu e vê cachorrinhos nas nuvens.

É neste ponto que você deve deve ter a “astúcia” de abstrair os desejos do usuário, considerar as informações relevantes sobre o que ele está lhe falando e propor soluções que, pelo seu conhecimento, devem agregar mais valor do que aquilo que o usuário pensava antes. E você terá que saber argumentar com ele sobre esta “nova” solução. Porém, compre mesmo esta briga! Não desista tão facilmente de convencê-lo a “fazer do seu jeito”. Demonstre confiança no que você esta falando. Baseie-se em estudos, fatos, exemplos. Conquiste a confiança dele antes de qualquer coisa. Não existe receita de bolo para isso e eu acredito que é por isso que estes templates de Casos de Uso ou qualquer outra coisa do tipo falham. Não me refiro ao artefato em si, mas o modo como ele é concebido: geralmente um processo burocrático, formal, nada humano e extremamente chato!

Finalmente, quando você consegue fazer O QUE O USUÁRIO PRECISA pode até ser que exista algum atrito no inicio – porque ele ainda não tem certeza que precisa daquilo. Mas conforme o tempo passa ele entenderá melhor porque as coisas estão tomando o rumo que estão tomando – ele aprende junto com você o real problema. E eis que o usuário passa a querer o que ele precisa e é aí que está a chave do sucesso.

Nota: Este post é uma “extensão” do comentário que fiz neste outro post.

Um dos problemas de desenvolvimento do Software, especialmente no Brasil, é o TI-Centrismo.

O TI-Centrismo prega que TI é o centro do Universo. Desta forma, muitas das decisões tomadas no ciclo de vida de desenvolvimento do Software visam “proteger” TI.
- “Não pudemos mudar isso, é padrão de TI!” = TI-Centrismo
- “Não dá para fazer assim, o banco não permite” = TI-Centrismo
- “Não vou deixar meu código feio assim. Deixa essa animação pra lá” = TI-Centrismo
- “Vamos fazer o Café com Leite, senão vai dar muito trabalho.” = TI-Centrismo

Precisamos mudar isso! Precisamos deixar o TI-Centrismo e adotar o Usuário-Centrismo. Pode não parecer mais isso muda muita coisa.

Programadores odeiam código feio. Por outro lado a parte estética da aplicação e as animações são sempre deixados para o final. O problema? Bem, muitas vezes perde-se muito tempo tentando fazer aquela arquitetura super hiper robusta com o super hiper design pattern onde não precisa.

Mas por que a estética, incluindo animação é importante? Porque isso deixa o usuário num estado mental muito melhor. Isso faz com que o usuário:

1. Perdoe erros mais facilmente
2. Tenha maior pré-disposição para aprender a mexer na aplicação

Fizeram uma experiência com dois caixas eletrônicos idênticos em termos de usabilidade e implementação. Um bonito e outro feio. O Caixa mais bonito teve uma avaliação muito melhor do que o caixa mais feio. No Caixa mais feio as pessoas reclamaram muito mais dos erros (propositais) do que no caixa mais bonito. Uma coisa é o usuário bater o olho numa coisa bonita e falar: “Uau… que legal isso. Bem, agora deixa eu ver como eu uso!”. Outra coisa é ele falar “Nossa! Que coisa medonha, como eu uso isso?” O estado mental é tudo. A motivação é tudo. E coisas feias definitivamente desmotivam.

Quando abandonamos o TI-Centrismo e adotamos o Usuário-Centrismo nossa percepção muda. Eu prefiro perder tempo fazendo uma animação que vai agregar mais valor à experiência do usuário do que aplicando aquele super ultra design pattern que li no ultimo livro que ostento na minha estante e que só vai servir para eu exercitar o que aprendi. E isso tem a ver com outra coisa que eu chamo de Tradeoff com foco no valor agregado (assunto para um outro post).

Em muitos casos o TI-Centrismo é como uma religião. Só espero não ser condenado como Galilei Galilei por tentar mostrar que o centro do Universo não é o que os devotos pensam.

Ao adotar o Usuário-Centrismo comecei a me perguntar se os POGs que tanto incomodam os programadores que pregam boas práticas em 100% do Software (TI-Centrismo) são realmente um mal em todos os contextos. Eu ousaria dizer que, no Usuário-Centrismo existe o POG do Mal e o POG do Bem. Imagine que você precisa implementar uma animação em Flex e que, como um bom programador, você tentou fazer da melhor forma possível. Mas não teve jeito! Você vai ter que colocar um Timer para fazer funcionar perfeito (típico POG para resolver problemas de tempo em animações em Flex). Mas você é um programador “bonzão”. Você jamais vai fazer este POG. Então você se recusa. Afinal de contas, para quê animação, não é mesmo? Mas a pergunta é: Tal animação vai agregar valor à experiência do usuário? Sim! O POG vai ser fonte potencial de problemas? Não! O POG vai ser difícil dos programadores entender? Não (nada que um comentário simples não resolva). Então, por que que eu vou me recusar de fazer algo que mais agrega à experiência do usuário do que, de fato, prejudica TI? Porque eu sou adepto do TI-Centrismo. Eu não faço software para o usuário, eu faço para mim. Para o meu ego.

Eu quis manter o diagrama acima simples e por isso o fiz “incompleto”. No caso da complexidade, por exemplo, mesmo que POG pareça “comprometer a complexidade” é preciso colocar isto na balança pois também acredito que não há mal algum em algo complexo, encapsulado e que pouco vai ser mexido. Mais um vez, é o que eu chamo de Tradeoff com foco no valor agregado.

O TI-Centrimo começa nas Universidades ou quando o iniciante está aprendendo a programar. Nesta época, sem experiência e capacidade para julgar, os professores colocam na cabeça das pessoas que a performance do sistema é um problema independente do contexto. Em outras palavras, aprende-se que sempre se deve otimizar um simples “for” (tentar transformar 200 iterações em 100 por exemplo). Aprende-se que se deve preocupar com a performance desde o início. Mas o que não é dito é que código otimizado é mais complexo. O que não é dito é que o gargalo de performance corresponde a um percentual muito pequeno do código do seu software. O que não e dito é que você geralmente não sabe onde está este gargalo e que no final das contas você vai perder muito tempo tentando otimizar código onde não é preciso, adicionando complexidade ao seu código e deixando de fazer outras coisas que agregam mais valor. Isto é TI-Centrismo!

O TI-Centrismo cria tantas restrições para se fazer um bom trabalho que Software de qualidade do ponto de vista do usuário é praticamente impossível. O TI-Centrismo é respaldado (entre outras coisas) pela alienação do programador. Softwares existem porque alguém precisa usar. Este alguém é o usuário. Ele é a razão do software existir. Mas muitos programadores esquecem disto e o seu código passa a ter uma razão de existir em si. Este programador aplica Design Pattern porque ele gosta. Ele aplica boas práticas porque ele gosta. Ele faz código otimizado porque ele gosta. Mas ele não gosta de perder tempo com animação – que as vezes é o que vai agregar valor à experiência final.

Você pode adotar o Usuário-Centrismo e continuar apreciando código bonito e de qualidade. A diferença é que o Usuário-Centrismo vai lhe fazer pensar que o seu código tem que ser bom para lhe permitir fazer um Software cada vez melhor não para você, mas sim para o usuário.

O que jamais podemos esquecer é que fazemos softwares para os usuários. Então ele deveria ser o centro do universo, e não TI.

Minha filosofia: mais importante do que saber o que implementar é saber o que não implementar para não perder tempo. Se eu entendo que têm coisas que raramente acontecem eu deixo pra lá. Quando acontecer? O usuário que se foda!

Não que eu não me importe com o usuário. Muito pelo contrário. Eu só deixo de fazer estas coisas que acontecem raramente para focar em coisas que acontecem com freqüência. No fundo, estou pensando em atender o usuário na maioria dos casos – o que realmente vai fazer diferença para ele no seu dia-a-dia. Não existe o Software perfeito e o usuário vai me xingar de qualquer forma. Mas não vai xingar a maior parte do tempo (porque a app ficou ruim pois perdi tempo desenvolvendo para a exceção). Ela vai me xingar só na hora da exceção.

O problema? O pessoal de TI vive desenvolvendo software para a exceção sem ao menos questionar a importância da exceção. Mas a exceção adiciona complexidade ao Software em todos os sentidos. Você vai levar mais tempo para fazer e muitas vezes vai ter uma usabilidade ruim para os casos que não são exceção… ou seja, para a maioria dos casos, justamente onde a usabilidade deveria ser boa. Neste caso, se você tiver mesmo que tratar a exceção faça isto a parte. Não prejudique 99% da usabilidade do seu software por causa do 1%. Se a usabilidade tiver que ficar ruim que fique no caso do 1%. Enfim, trate exceção como exceção, ou melhor, não trate… acredide, muitas vezes você não precisava lê-lo feito.

Pense nos Softwares que vocês usam. Quantas vezes não conseguimos fazer determinadas coisas? Isto é a Apple e a Microsoft falando “foda-se!” para nós usuários. Eles também não tratam todas as exceções. Por que nós, pobres mortais, temos esta ficção nisto? A minha dica é: Mesmo que o usuário bata o pé, se você estiver confiante que não precisa tente postergar. Deixe para fazer por ultimo. No meio do caminho faça coisas bem melhores, coisas que vão desviar a atenção dele. Acredite, lá no final o usuário não vai nem lembrar daquelas besteiras que ele pensava que eram importantes.

Imaginem se todos tivessem esta didática excepcional para explicar as coisas.

Este vídeo do Bill Verplank está no CD do livro Designing Interactions.

“Existiria algo nesta inovação que só seu idealizador, Steve Jobs, foi capaz de enxergar? Algo não tão evidente que o torna tão superior aos demais Smartphones do mercado?”

Eu nunca me importei com o ultimo ultramoderno celular XYZ 500 que tira foto com excepcional qualidade e faz cafezinho. Também sempre achei o IPod muito caro embora eu admire a sua superioridade como produto. Apenas quando eu estive na MAX em 2005 eu comprei um IPod Shuffle (e só fiz isso porque era para dar de presente para minha namorada). O que isto quer dizer? Que embora eu trabalhe com tecnologia eu não sou nenhum aficionado por Gadgets.

Mas depois que eu vi um amigo mexendo no seu IPhone, pela primeira vez eu me senti predisposto a pagar tão caro por algo que talvez eu nem precise de verdade. Mesmo assim eu ainda passei mais de um mês aqui nos EUA resistindo à tentação. Mas desta vez eu não fui tão forte e resolvi pagar $ 399,00 num IPhone. E valeu cada centavo!

Como uma criança com seu brinquedinho novo eu passei a noite inteira mexendo no meu IPhone. E quanto mais eu mexia mais eu queria conhecer sobre ele. Não apenas sobre suas funcionalidades, mas principalmente como a Apple conseguiu criar algo tão inovador e fascinante. Existiria algo nesta inovação que só seu idealizador, Steve Jobs foi capaz de enxergar? Algo não tão evidente que o torna tão superior aos demais Smartphones do mercado?

A primeira coisa que se nota no IPhone – e que não é mais novidade pra ninguém – é o fato dele não ter teclado. E ao contrário do que Steve Ballmer da Microsoft disse, é justamente por não ter teclado que o IPhone é tão superior. Afinal de contas, para que você precisa de um teclado quando você está vendo fotos? Para que você precisa de um teclado quando você está vendo um vídeo? Para que você precisa de um teclado quando você está ouvindo música? Em todos estes casos o teclado ocupa um espaço desnecessário no dispositivo.

Mas o problema com o teclado vai além do espaço físico que ele ocupa o tempo todo. O problema é que ele não é propício para acessar a maioria das funções dos aplicativos. E é por isso que no caso dos computadores existe o Mouse. Aponte e clique simplesmente. Isto é muito mais intuitivo. Imagine por um instante que não existe mouse e tudo que você precisa fazer você tem que fazer pelo teclado. Como você saberá qual tecla, ou combinação de teclas, você tem que pressionar para, por exemplo, alinhar um texto à direita no Word? Talvez as teclas “SHIFT + ]” pudessem ser mapeadas para esta funcionalidade se não houvesse outra maneira mais fácil de fazer isso. Mas definitivamente isto não é nada intuitivo.

Podemos dizer que o Mouse nos permite estender o teclado. Pois o que são as teclas de um teclado além de botões? Assim, na interface do Word existe um botão com um ícone para alinhar o texto à direita. Uma vez que você pode apontar e clicar neste botão, os desenvolvedores não precisam atribuir comandos diferentes aos “botões do teclado” para prover esta funcionalidade. E o melhor disto tudo é que você pode ter botões específicos para cada tipo de aplicação. É por isso que a interface do Photoshop é tão diferente da interface do Word. Pois imagine ter que usar uma combinação de teclas que faz algo no Word e a mesma combinação que faz algo totalmente diferente no Photoshop?

A maioria dos celulares tem um botão direcional para dar acesso a funcionalidades de navegação na interface. Eles têm também um botão de cada lado que hora servem para escolher entre mais de uma opção, hora possuem outra funcionalidade específica dependendo da interface. Embora esta tenha sido uma solução plausível para um dispositivo como o celular, ela ainda é muito limitada porque todos os aplicativos têm que se adaptar a este esquema de Interação limitado. Em outras palavras, o Software deve se adaptar às teclas. E o motivo é simples: As teclas não podem mudar.

Mas eis que surge o IPhone com seu Touch Screen e sua capacidade de “eliminar” os botões fixos. No IPhone os botões não são Hardware, mas sim Software. Hardware não muda, mas software sim. Os botões podem mudar para atender a cada aplicativo específico. Cada aplicativo tem seu conjunto de botões. Cada aplicativo tem a sua interface pensada a desenvolvida para oferecer a melhor usabilidade possível. Para navegar entre as fotos você possui um conjunto de botões, para ouvir música outro, para fazer ligações outro e assim por diante. E o teclado do IPhone não fica aparecendo quando ele não é necessário pois até o teclado também é Software e não Hardware.

Enfim, o que só Steve Jobs foi capaz de enxergar? Ele viu que os outros Smartphones eram como computadores sem Mouse. Pequenos computadores com teclados que impediam que os softwares pudessem ter uma boa usabilidade pela falta de um dispositivo de apontar e clicar. Steve Jobs percebeu que não era o Software que tinha que se adaptar aos botões (teclas) e sim os botões que tinham que se adaptar ao Software (quando você cria uma interface você coloca os botões no lugar mais conveniente). O IPhone pode fazer para os celulares o que o Mouse fez para o Desktop: torná-lo finalmente simples de usar. E embora o IPhone tenha uma série de outras inovações dignas de Oscar, isto já é o bastante para aplaudirmos de pé este grande visionário: Steve Jobs.

Nesta apresentação Steve Jobs explica o problema dos Smartphones atuais: “Eles têm teclado. E as teclas não podem mudar”:

O IPhone é tão fácil que até uma criança que mal sabe falar consegue mexer:

Dá até pena do Steve Ballmer da Microsoft ao vê-lo falar que o IPhone não é bom porque não tem teclado:

As imitações serão inevitáveis daqui pra frente:

Por isso a Apple tem mais de 300 patentes do IPhone.

Excelente definição (explicação) sobre Design extraída do livro Designing Interactions:

Charles Eames (CE) in conversation with Madame Amic (MA):

MA. What is your definition of Design?
CE. A plan for arranging elements in such a way as to best accomplish a particular purpose.

MA. Is design an expression of Art?
CE. The design is an expression of purpose. It may (if it is good enough) later be judged as art.

MA. What are the boundaries of design?
CE. What are the boundaries of problems?

MA. Does the creation of design admit constraint?
CE. Design depends largely on constraints

MA. What constraints?
CE. The sum of all constraints. Here is one of the few effective keys to the design problem – the ability of the designer to recognize as many of constraints as possible – his willingness and enthusiasm for working within these constraints – the constraints of price, of size of strength, balance, of surface, of time, etc.; each problem has its own particular list.

MA. Does design obey laws?
CE. Aren’t constraints enough?

O diálogo acima é muito interessante por diversos motivos, inclusive porque vai contra o senso comum sobre “limitar a criatividade dos Designers”. Eu sempre achei que esse papo de limitar não faz sentido. Muito pelo contrário, a criatividade real surge quando você encontra boas soluções dentro de limites estabelecidos. E este é o ponto que separa o Design da arte: o artista é livre para se expressar, o Designer não! Além disso, existe mais uma coisa que eu odeio ouvir quando estou trabalhando numa interface. Algo do tipo: “pode viajar a vontade”. Em minha opinião este tipo de viagem não leva a um resultado de Design eficiente, pois quando você “viaja” você não obedece às Constraints e se você não as obedece você não atinge o seu objetivo.

A definição de Design da Wikipedia é bem completa, mas faltou mencionar os significados mais comuns para o termo Design em português e, principalmente, relacionado ao desenvolvimento de Software no Brasil. Design: frescura; viagem; perfumaria.

É verdade que muitas vezes as pessoas falam isto em tom de brincadeira, mas o grande problema é que este sentido pejorativo do Design é muito mais difundido do que o seu real significado e importância. Talvez este seja um dos motivos pelo qual temos tantos aplicativos com interfaces péssimas. Além disso, nós programadores pensamos primeiro em nós mesmos (que banco usar, qual Pattern aplicar, etc) para depois, somente lá na frente, pensarmos no usuário (com será a tela?). Na realidade nós programadores somos mesmo muito egoístas. Orgulhamos-nos das soluções de programação que criamos e quando é para tratar da tela, o ponto de contato do usuário com o nosso software, menosprezamos, deixamos em segundo plano, desdenhamos e fazemos piadinhas. Se menosprezar o Design fosse pecado, o Inferno estaria cheio de programadores.

Por outro lado, parte daqueles que levam o Design mais a sério o relaciona sempre com um produto visual. Mas eu tenho um exemplo bem didático para mostrar que o produto do Design não é necessariamente algo visual. Há algum tempo atrás eu liguei para a central de atendimento da Ticket Restaurante para modificar a senha do meu cartão. Então começou: “digite 1 para fazer isto, digite 2 para fazer aquilo” e nada de “digite alguma coisa para trocar a senha”. Até que, por algum motivo, eu resolvi ouvir o saldo do cartão. Pois bem, para minha surpresa, depois de ouvir o saldo, finalmente surgiu uma nova opção para trocar a senha. Agora, como é que o usuário saberia que para trocar a senha ele tem que escolher a opção “ouvir saldo”? Suponhamos também que ligar para modificar a senha é uma atividade comum, necessária para a maioria dos usuários. Isto significa que o “trocar senha” deveria estar no primeiro menu – deveria ter maior importância – e como deve ser composto este menu é um trabalho de Design cujo resultado final nada tem a ver com algo visual.

Outros dizem que o Design é uma forma de comunicação. Mas a definição que podemos extrair do diálogo acima mostra o Design como um processo, um plano para encontrar melhores soluções para os problemas dentro de limites bem estabelecidos. Isto, obviamente, também é muito mais do que comunicação.

Eu vou ainda mais longe. Um bom programador em busca da melhor solução para um problema pode estar atuando como um Designer. Um Designer de Código, digamos. Suas Constraints giram em torno do equilíbrio entre uma solução que funcione bem e a legibilidade de sua implementação. Desta forma, isto seria uma quebra de paradigma no sentido em que bons Designers podem sim ser bons programadores. Além disso, uma etapa do processo de desenvolvimento de Software que reinou absoluto durante muitos anos se chama Design – e não se refere ao Design de Interface.

No livro Designing Interactions o autor também menciona que o que define as diferentes disciplinas de Design é a natureza de suas Constraints. O Designer de Interiores, por exemplo, lida com um conjunto de Constraints diferentes do Designer de Interfaces. E acreditem, existe tanto problema nessa área quanto na nossa de desenvolvimento de Software. Mas isto já é assunto para outro post.