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.

Popularity: 48% [?]

Este post foi criado Terça-feira, 25, Setembro , 2007 às 8:49 am e arquivado sob Desenvolvimento, Design, Miscelânea. Você pode acompanhar as respostas para este post no RSS 2.0 feed. Você pode deixar uma resposta, ou trackback do seu próprio site.