Design Thinking é um termo usado inicialmente na academia para definir o modo particular como designers projetam, resolvem problemas e criam soluções. Recentemente, o termo foi ressignificado por escritórios de Design de renome com o objetivo de comercializar este modo de pensar como um serviço, não um produto.
Os escritórios sofriam com a alta competividade, enquanto os clientes precisavam economizar contratação de terceiros devido à crise. Design Thinking acabou virando sinônimo de levar o modo de pensar do Design para quem não é designer, com o objetivo de maximizar a inovação dentro das organizações — ao contrário de terceirizar com os escritórios de Design. Os escritórios viraram consultorias e o marketing esvaziou o termo Design Thinking de significado. Um dos grandes defensores do Design Thinking, numa pura jogada de marketing, chegou a afirmar que o Design Thinking é uma falha.
Se o Design Livre compartilha essa intenção de potencializar o design feito por designers sem formação específica, será que não corre o risco de terminar da mesma maneira?
Sim, é possível, mas vejo 3 limitações que fizeram o Design Thinking morrer na praia. Enfatizo-as porque acredito que, sem elas, o Desing Livre tenha mais fôlego.
1) O Design Thinking é elitista
Ele surgiu na academia, a elite intelectual da sociedade. Ele celebra o designer como ser criativo e define o usuário como um fornecedor de informações e receptor de produtos. O Design Thinking não reconhece que exista pensamento criativo na outra ponta do projeto. Se existisse, seria chamado “Use Thinking” e consistiria de escolhas de opções de uso.
A figura abaixo, um clássico para explicar o que é Design Thinking, deixa clara a diferença entre classes: o Design Thinking explora várias possibilidades de produção, enquanto que o usuário se contenta com as opções de uso. A estrutura em árvore representa uma evolução, enquanto a estrutura em grama representa apenas uma escolha dentre opções pré-definidas pelo objeto.
Defensores do Design Thinking contemporâneos defendem a co-criação com usuários, design participativo, etnografia e outras formas de incorporar a criatividade do usuário no projeto, porém, o Design Thinking continua sendo um fenômeno que acontece dentro da organização, não fora. A disseminação do Design Thinking se dá por consultorias que mesmo pequenas empresas não conseguem pagar, que dirá do usuário.
Como todo produto voltado para a elite, o Design Thinking vai sair de moda mais cedo ou mais tarde.
2) O Design Thinking é fechado
Mesmo que se reconheça que o usuário também pode fazer Design Thinking (ou talvez nesse caso seja melhor chamar de Design Doing), e transformar o produto com gambiarras e customizações, as ideias deixadas para traz ficam inacessíveis. Os dois processos de design se conectam apenas pela existência de um objeto que nada diz sobre de onde veio, como veio e porque veio. Em suma, o código-fonte não está disponível.
Embora o projeto possa continuar e o martelo virar uma máquina, os processos subsequentes não poderão se beneficiar de todo o Design Thinking que veio antes. Ideias rejeitadas poderiam ter adquirido valor em contextos não considerados. Isso pode acontecer até mesmo dentro de uma única empresa, como no caso do desenvolvimento de produtos em segredo por uma equipe de inovação treinada em Design Thinking que acaba sendo, no final, cancelado e a empresa não ganha nem com o aprendizado.
3) O Design Thinking é centralizado
Se é elitista e fechado, é claro que é também, centralizado. O problema dos sistemas centralizados é sua fragilidade. Se a empresa não consegue colocar o produto no mercado, todo o Design Thinking pra trás é inútil. Se o desenvolvimento continua centralizado na empresa original, atualizações e novas versões vão demorar pra acontecer, isso se houverem. Dificilmente o produto será transformado em outra coisa, pois isso desafia a autoridade do centro. Para que o centro continue centro, ele deve concentrar algo que a periferia deseje, no caso do Design Thinking, o conhecimento, este que se vende nas consultorias.
E o que pode ser o Design Livre?
Se começarmos a partir do Design Popular (ou Vernacular) e potencializarmos ele com o Design Thinking, mantendo o processo aberto e descentralizado, então podemos dar uma sobrevida, tanto ao Design Livre quanto ao Design Thinking. Para manter o processo aberto, é importante que ele seja realizado em público e que o código-fonte e outras formas de documentação estejam disponível. O processo se ramifica a cada ideia e, virtualmente, não termina nunca.
Estas ideias estão sendo testadas na Plataforma Corais. Lá você tem uma Árvore do Conhecimento com todos os principais Métodos de Design cultivados no Design Thinking, porém, não é necessário passar pela árvore para começar a desenvolver projetos. Os projetos são públicos e qualquer um pode aprender com os códigos-fontes e discussões. A gambiarra é celebrada como inovação e novas funcionalidades são desenvolvidas para oficializá-las. E o mais importante: não é preciso pagar um centavo para uma consultoria.
Ao invés de negar o Design Thinking, o Design Livre incorpora-o e utiliza para outros fins. Que outros fins você imagina?
Muito bom o texto. Direto ao ponto e claro.
Pessoalmente não consigo entender como o Design Thinking ajudaria qualquer iniciativa de Design a não ser transformá-la em mais um subproduto do próprio Design Thinking. Existe DT popular, aberto e distribuído aos montes pela Internet. Mesmo assim são concepções equivocadas do que realmente precisa acontecer para um design vir ao mundo. A única coisa que consigo imaginar é que vocês deveriam manter o DT longe do DL.
Em tempo: tenho sérias ressalvas sobre a ideia da disponibilidade de um “código-fonte” como estratégia de abertura para o design. Um código-fonte depende da combinação de elementos primitivos tendo em vista regras de produção oferecidas pela arquitetura do sistema. Só é possível ler um código-fonte conhecendo a sintaxe e a semântica da linguagem, o que é exatamente o que o Design Thinking propõe quando sugere que o design é uma forma de pensar baseada em métodos. Um código-fonte ainda implica a inferência da verdade das sentenças elaboradas no escopo da linguagem sem ambiguidades e um tempo finito definido pela própria arquitetura. Nem preciso entrar no mérito da teoria da informação que dá sustentação a ideia de código.
Seu desenho da árvore (última imagem) exibe exatamente a lógica de um analisador sintático: uma estrutura que é inegavelmente generativa mas depende da (re)combinação de elementos simples por meio de regras de produção. Pra mim, um produto de design não é um elemento terminal de uma rede de transformações.
Se assim for, o principal teórico do Design Livre é o jovem Noam Chomsky e não o guru da IDEO Tim Brown.
A gente tem exercitado a Antropofagia como base do Design Livre: ao invés de rejeitar, a gente honrosamente devora, digere e incorpora o diferente. As características que admiramos no diferente permanecem, as que não gostamos, deixamos pra trás.
A identidade negativa que a comunidade do Software Livre construiu em torno da ogeriza ao software proprietário é algo que não parece estar vindo junto com a sua canibalização. A gente tem feito Design Livre sempre que possível com Softwares Livres, mas sem preconceito quando isso não é possível.
Na verdade, apreciamos mais quando o processo de design é aberto do que quando o código-fonte é aberto. Existem vários softwares livres que oferecem códigos abertos, mas que as comunidades são extremamente fechadas à participação. Um designer que deseja ajudar, mas que não consegue trabalhar sem um Macintosh, acaba ficando de fora.
Por isso, a gente tem tentado estender a noção de código-fonte no Design Livre como se fosse o próprio processo de design. Para reproduzir ou continuar um projeto, não basta ter os arquivos com os códigons-fontes computacionais, mas saber como eles foram escritos, qual foi o raciocínio por trás, o contexto, os métodos, etc.
Conforme a gente menciona no livro do Design Livre, o código do design não precisa ser estruturado a ponto de ser legível por uma máquina (p.68), pois as pessoas podem ler as entrelinhas. O importante é que haja uma meta-comunicação sobre o processo que gerou o produto, que gerou o código-fonte.
Talvez a noção de código não seja a mais apropriada para trabalhar processo de design, mas a analogia com o código-fonte do software livre tem funcionado para explicar a sua importância. Digamos que estamos utilizando algumas categorias formalistas para fins ativistas, tal como o Caio Vassão sugere na sua tese com o conceito de formalização ingênua:
“Partiremos do princípio de que é possível estabelecer uma “gradiente de formalização”: desde a formalização absoluta do código binário, passando pela formalização aproximada da escrita, ainda pela formalização relativa do desenho a mão-livre e da abordagem artística da forma, até a formalização mínima da percepção imediata. Esse gradiente de formalização nos permitirá perceber que podemos nos posicionar em algum ponto ao longo dessa escala, reconhecendo quando uma entidade é ou não formal, em relação a outra que talvez seja mais ou menos formal. Os estudos sobre Ecologia de Mídias trabalham sem que se procure por um código subjacente às expressões da cultura,
mas por relações que se constroem na coleção de mídias, produtos da indústria cultural, na apropriação coletiva, descrições que não chegam a estabelecer um “código” que possa, ele próprio, descrever ou reproduzir a situação descrita.”
http://www.teses.usp.br/teses/disponiveis/16/16134/tde-17032010-140902/pt-br.php
Então a gente não quer abrir o código-fonte para reproduzir o produto em massa sem pagar royalties. Isso é muito pouco. O que a gente quer é continuar o processo de design. A representação em árvore é de fato uma representação ingênua e simplificada de como o processo pode ser continuado, mas na falta de uma representação melhor, usei essa. Outra idea?
A ideia de código pressupõe uma estrutura ou uma organização, mas é uma estrutura sem gênese. É preciso encontrar uma forma de explicar como se dá a gênese de uma organização e como essa organização por sua vez desencadeia uma nova gênese. Se o processo é dinâmico, pressupõe um equilíbrio estável do sistema sem status de verdade, exatamente o oposto do que o código é.
o preconceito existe dos dois lados, e tua fala demonstra isso fred, quando você usa a palavra ogeriza. além disso, o movimento do software livre difere do movimento open source. pra galera do software livre, a abertura do código é uma questão de ética. queremos saber o que colocamos em nossas máquinas, queremos poder modificar o que colocamos em nossas máquinas e queremos poder compartilhar tudo isso.
talvez fazendo uma analogia com a galera vegana (que também difere de vegetarianos), possa se entender melhor. não me refiro a estas pessoas como “o pessoal que tem ogeriza de carne”. tampouco faço trabalhos com eles que envolvam o consumo de carne. e se eu optar por trabalhar com um grupo que tem foco em não comer carne, é óbvio que serei questionada sobre o fato de eu ser uma consumidora de carne. complicado eu chegar com uma cesta cheia de salame e queijo numa confraternização de vegans, né?
além disso, já está mais que provado que é o uso em produção, num ambiente profissional, com deadlines e toda sorte de intempéries que um projeto pode sofrer, o que fornece subsídios sólidos para uma ferramenta melhorar tanto em termos de funcionalidade quanto de interface. se o designer usar uma ferramenta proprietária, ele não tem como interferir no processo dela. agora, se for SL mas a comunidade for fechada, rola até de fazer um fork. e aí entra a necessidade do saber articular, a parte de interação social destes processos.
WTF fred?
“ogeriza ao software proprietário” se você enxerga desta forma você não entendeu o ponto, como a maioria de visão simplória não entendeu. Isso aparece na superfície sim, como resultado que um entendimento profundo sobre ética e direitos. Completando a analogia de fabs: O vegan (não qq vegetariano) não tem ojeriza a carne, tem uma posição ética na defesa de seres sensíveis, o que o leva a não comer carne. Esse grupo até cita os malefícios da dieta onívora, mas esses argumentos são secundários. (Ótima analogia fabs!)
“A gente tem feito Design Livre sempre que possível com Softwares Livres, mas sem preconceito quando isso não é possível” … “preconceito”? É isso? O que baseia a decisão da galera do SL é um certo “preconceito” contra software proprietário? … Como fabs já citou SL é usado profissionalmente por artistas gráficos matriciais, vetoriais, 3d, áudio, vídeo… mas parece que para alguns é sempre mais fácil parar quando encontra um ponto onde o SL é menos eficiente, como se esta fosse uma característica global e imutável. Esse tipo de pensamento e esse tipo de atitude faz com que a evolução não ande no rítimo que gostaríamos, mas anda.
“Existem vários softwares livres que oferecem códigos abertos, mas que as comunidades são extremamente fechadas à participação.” Ow! puts… Sabe, vc está até certo, mas duvido que você vá apontar uma. Principalmente uma relacionada a artes gráficas.
“Um designer que deseja ajudar, mas que não consegue trabalhar sem um Macintosh, acaba ficando de fora.” O QUE!?!?!?!? Em que planeta isso acontecê? Nos principais projetos de SLs gráficos tem desenvolvedores que usam Mac por mais que isso seja incoerente do ponto de vista da liberdade, mas provavelmente a motivação desse cara seja outra.
“a gente tem tentado estender a noção de código-fonte no Design Livre como se fosse o próprio processo de design. Para reproduzir ou continuar um projeto, não basta ter os arquivos(…)” Certíssimo. Realmente o processo também deve estar aberto como se vê em quase todo projeto de SL. O código por sí só diz muito pouco e não dá certeza de onde veio e para onde vai o projeto. Maaassss… O processo aberto não adianta sem formato aberto e um SL que o suporte, para garantir que qualquer um realmente poderá participar do projeto.
fred, você parece um cara super bem intencionado, mas, com essas idéias que você aceitou e tem repassado sem provavelmente perceber, que tipo de design livre você espera conseguir? Você está a frente, junto com poucos, de um movimento contra-corrente, que será contraposto por muitos e desdenha quem está do seu lado. Alguém com quem, junto, poderia vencer melhor a correnteza.
Re-Think isso aí. 😉
Fabs e Aurium, a gente está há anos tentando engajar o pessoal do Software Livre na discussão sobre o Design Livre, mas o interesse tem sido pequeno até então. Se por acaso existem preconceitos e barreiras é simplesmente porque não houve conversa suficiente ainda.
Concordo plenamente que é melhor trabalhar com Software Livre, mas infelizmente já presenciei vários casos de designers que queriam contribuir com SL, mas foram barrados porque não usavam ferramentas livres, porque não sabiam codificar, porque tinham critérios diferentes de qualidade.
Eu uso SL sempre que possível e contribuo com os projetos. Desenvolvemos duas visões de futuro para a Mozilla, fizemos design participativo do portal BrOffice e fiz bug reporting e ajuda a outros usuários na comunidade Drupal. Gostaria de ter feito muito mais, porém, na maioria dos projetos não vejo como posso contribuir com minhas habilidades, já que codificar não é meu forte.
Por isso que a noção de código que estamos tentando desenvolver no Design Livre (e que pode até ter um outro nome no futuro) não é a de um compilador. A gente precisa de linguagens flexíveis, que permitam um diálogo produtivo entre diferentes comunidades. Eu acho que o Design Thinking tem alguns elementos interessantes para conversar, mas pode ser que eu esteja errado. Em última análise, a linguagem é uma construção social e não é meu interesse de regulá-la. Portanto, se uma pessoa fala “ogeriza” ou “simplória” tá de boa. O importante é manter o diálogo.
eu não sei se evitar diálogos onde aparecem substantivos como “ogeriza” e adjetivos como “simplória” seria uma regulação de linguagem, mas eu sinceramente evito permanecer em discussões onde esse tipo de vocabulário esteja presente. Isso indica uma polarização no debate que não leva à construção alguma de conhecimento, mas apenas a um embate entre pontos de vista diferentes, vide as polêmicas recentes sobre o cinema nacional.
algum gato comeu o meu link no comentário acima. Segue ele por extenso então: http://oglobo.globo.com/cultura/o-que-cinema-7717728
Fred,
Às vezes eu penso que você fala em colaboração e ao mesmo tempo menospreza o potencial da própria comunidade que pode colaborar. Essa flexibilidade que você busca pode resultar da dinâmica do grupo na interação com os meios e recursos disponíveis, não necessariamente da estrutura da linguagem em si.
Você acha que Java é flexível? Ou que C é flexível? Essa duas linguagens não foram originalmente planejadas para o perfil de usuários do Processing e Arduino e o esforço da comunidade (IDEs que ocultam complexidade absurda, libs forkadas e sketches compartilhados infinitamente, tutoriais, introduções, how tos etc) transformam qualquer noob em designer do dia pra noite.
Se você realmente acredita que a linguagem é uma construção social, precisa crer que a comunidade dará um jeito de dobrar as barreiras quando houver um objetivo em comum. Eu entendo que você busca estabelecer uma base conceitual mínima para falar em DL, só que na minha cabeça é a comunidade de um possível DL que construirá tal coisa.
Por outro lado, isso dará certo SE e SOMENTE SE o design for algo que pode ser explicado com base na documentação do processo e nos “códigos-fontes”. Eu nem preciso repetir que não só não acredito nisso como tenho evidências suficientes de que não é o caso. Esse caminho pode funcionar bem em algumas situações onde a própria arquitetura do sistema seria definida nos termos de processos e utilizaria sintaxes pré-definidas como forma da expressão, mas jamais em contextos onde o sistema em si é um processo que produz sua própria organização.
Nesses casos a documentação é um mero diário e o “código fonte” não explica o objeto, apenas o descreve momento a momento. A única coisa possível de aprender com isso é a história do sistema.
O que eu tou tentando fazer é colocar alguns pontos para discussão, seja para serem extendidos ou para serem rejeitados. Minha intenção é que de fato a comunidade tome conta do Design Livre.
A Plataforma Corais já tem diversos projetos desenvolvidos em comunidade que estão de fato tornando concreta a possibilidade de um design popular, aberto e descentralizado. O site DesignLivre.org foi criado com a intenção de refletir sobre esta experiência e trazer outras mais.
Eu não estou querendo estabelecer bases mínimas. O que eu quero no momento é trazer mais pessoas para a discussão.
E sobre a documentação como código-fonte, eu acredito que o objeto nada mais é que sua trajetória histórica e é precisamente isso que acho que deve estar disponível. O Corais tem sido projetado no sentido de oferecer essa possibilidade de reconstruir o objeto e continuá-lo de formas diferentes. O Design Thinking nos ajudou a definir as ferramentas que capturam os traços do objeto conforme ele vai sendo projetado pelas interações dos participantes.
Estou consciente de que posso estar equivocado. Por isso que desejo trazer outras abordagens práticas para a discussão.
Sobre a questão dos termos utilizados e do tema debatido, lembrei de um pequeno ensaio que fiz ano retrasado para uma disciplina de mestrado: “Regulação da participação em comunidades de software livre: abordagem do caso Debian-RS”.
A ideia de regulação da participação é bem interessante, e tomei ela a partir da proposta do circuito cultural e Stuart Hall. Escrevi o ensaio a partir do estudo de caso de Guilherme Carvalho da Rosa sobre identidade cultural da comunidade de usuários e desenvolvedores de software livre da comunidade Debian-RS. É curto, mas uma das questões que achei mais legal é a percepção presente nesta comunidade da necessidade de discutir o modelo de colaboração, cuja forma tradicional de participação na comunidade se dá mediante a códigos e traduções.
Fred e Gonzatto,
Não estou nem de longe sugerindo que não se deve propor coisas. É justamente o contrário: sem propostas não há debate nem discussão nem crescimento. Vocês já colocaram o DL no mundo e acho que se tem gente interessada é sinal que há uma lacuna conceitual a ser preenchida. As pessoas precisam de outros caminhos para entender como projetar e como pilotar suas próprias cabeças. O outro design, esse confinado a uns poucos especialistas, que é um equívoco.
Eu apenas acredito que o DT é um hype sem futuro (e por isso tenho sugerido que o descolem do DL), mas também posso estar enganado.