Estou escrevendo estes posts conforme leio:estão em ordem cronológica. Os livros/artigos que estão aqui serão a base da bibliografia da minha tese, que será sobre ensino de projeto de interfaces de softwares educacionais. Se você quiser disutir esses assuntos comigo, entre em contato. Estou usando isso para a revisao bibliografica da minha tese. Se voce acha esse material interessante, procure ler os artigos.
NÃO USE ESTE MATERIAL COMO FONTE DE PESQUISA!!!! APENAS COMO FONTE DE ESTUDO.
Pesquisa em design
Eastman (2001) afirma que temos 30 anos de pesquisa (começou em meados de 1970)
Cross (2001) acredita que a pesquisa em design possa ser organizada, pois design seria uma atividade diferente das demais. Uma forma diferente de resolver problemas. Sugere um framework para a pesquisa, dividido nos seguintes itens (os subiten marcam topicos a serem explorados):
- Formulacao de problemas
- Goal analysis
- Solution focusing
- Co-evolution of problem solution
- Problem framing
- Geracao de solucoes
- Fixacao
- Apego a conceitos
- Geracao de alternativas
- Criatividade
- Estrategias de processo
- Processo estruturado
- Oportunismo
Outro ponto importante e a questao de definir o que e design. Se conseguirmos colocar fronteiras ou especificar uma forma de determinar o que e e o que nao e design, poderiamos definir e justificar um campo de pesquisa. E disso que se ocupam Zimrig e Craig (2001). Eles se posicionam contra o uso de rotulos de disciplinas (arquitetura, engenharia etc) como forma de identificar design. Para eles, esta e uma definicao pouco precisa. Eles sugerem usar aspectos que podem diferenciar a praticas entre disciplinas. Eles poderiam ser:
- Diferencas nas praticas responsaveis por dar significado e forma as atividades de design
-
- Influenciadas por culturas educacionais, profissionais.
- Aspectos da pratica incluem contexto, estrategia, atividades fisicas e sociais, standarts de rigor e tipos de representacoes externas favorecidas por cada disciplina.
- Diferencas entre os tipos de tarefas
-
- Diferencas nos graus de precisao
- Graus de restricao (tempo de set up e custos, por exemplo).
- Diferencas entre os tipos de artefatos produzidos.
- Diferencas nos tipos de conhecimentos e nos processos cognitivos.
-
- O conhecimento e mais concreto ou abstrato?
- Privilegia experiencias, analogias, esquemas ou regras?
Mas este tambem e apenas um framework, nao podemos saber se pode ser conclusivo. Ate onde a experiencia indica, estas sao categorias validas, mas como saber se sao exaustivas?
Por isso os autores buscam definir o que e design atraves de paradigmas de resolucao de problemas:
- Como raciocionio abdutivo
- Design seria complexo demais para ser classificado desta forma
- Como resolucao de problemas mal definidos
- Nao e frequente apenas no design. Mesmo exemplos de problemas bem estruturados (como jogar xadrez) podem ser vistos como mal estruturados se considerarmos o jogo todo.
- Aponta que Goel afirma que as restricoes entre componentes numa decomposicao sao negociaveis
- As regras sao contingentes e contextuais
- Aponta uma referencia (Simon) que afirma que “todos os problemas sao mal definidos”, pois todos estao abertos a alguma reestruturacao
- Como resolucao de wicked problems
- Sao problemas cujas solucoes acarretam responsabilidade para o designer
- Resolver um problemas pode gerar outros (todo wicked problem e um sintoma de outro problema).
- Como construcao.
- Ao inves de resolver problemas apenas a partir do conhecimento (LTM), designers craim conceitos “on the fly” para ajudar a decompor e definir problemas.
Nenhuma das alternativas define design de forma conclusiva. Porem, elas podem apontar para uma tipologia de atividades de design. Por exemplo: mesmo que o fato de ser mal definido nao seja exclusividade (dos problemas de design) a complexidade pode demandar estruturas unicas. O autor coloca como alternativa focar nos processos envolvidos: analogias, coherence seeking, simulacao mental, modelagem dinamica, argumentacao, tomada de decisao etc.
Em Goel (1995) se ve a questao do que e ou nao design colocada de outra forma: sao problemas que nao podem ser descritos utilizando CTM (computational theory of mind). Goel nos lembra que esta teoria e “the only game in town”, ou seja: nao temos realmente outra explicacao/modelo para a cognicao humana fora da computacao. O papel dela e postular propriedades para os sistemas simbolicos nos quais as computacoes de nossa mente sao realizadas. “Cognição pode ser mais que computação mas é, pelo menos, computação”.
O argumento de Goel (para uma explicacao mais detalhada ver o post Sketches of thought) e que as propriedades de um sistema simbolico regido pelas CTM sao necessarias, porem nao suficientes para explicar problemas mal definidos, como design. O grande “puzzle”, na visão de Goel, é como estas teorias podem explicar fixação de referências e conteúdos (o conteudo semantico dos sistemas simbolicos). Goel se alinha com aqueles (a começar por Searle) que pontuam que a computação não explica, por exemplo: dependência de contexto, metáforas, ficção, opacidade… Nada disso teria contrapartida em sistemas computacionais.
Distinguir o que e do que nao e um problema em estruturado, como vimos em Zimrig e Craig, e bastante dificil. Goel sugere uma forma de resolver este dilema, usando as propriedades (de sistemas simbolicos baseado na) da CTM (ver o post Sketches of thought):
- Dividir um dado sistema em seus estados computacionais (lembre que devem ser individuados com base na estrutura causal).
- Ver se esta individuação está dentro das propriedades da CTM.
Goel sugere algumas características que podem definir atividades de design prototípicas, mas insiste que não são um subconjunto de características suficientes ou necessárias para definir atividades de design, apenas um modelo de características salientes. Goel afirma que não é simples (e que ele acredita que não seja possível) definir características de uma atividade de design. Ele afirma que estas atividades são do tipo “radiais”: há um caso prototípico e casos radiais, que apresentam variações. Segundo ele, seriam 12 as acaracteristicas de uma atividade de design:
- Disponibilidade da informação na definição do problema: pouca, insuficiente.
- Natureza das restrições: dois tipos: “natural”, “lógica” – não negociáveis, impostas – e sociais/políticas/legais/econômicas.
- Tamanho e complexidade dos problemas: normalmente são grandes e complexos, necessitando de dias e meses para serem resolvidos.
- Partes componentes: os problemas podem ser decompostos, mas pouco ou nada na estrutura do problema dita como será a decomposição: que é mais fruto da experiência.
- Interconectividade das partes: as partes não são logicamente interconectadas.
- Respostas certas e erradas: não existem… Apenas melhores e piores.
- Input / output: o input é sobre as pesoas que vão usar o artefato, os objetivos delas. O output é a especificação do artefato.
- Feeback: não há feedback durante a resolução do problema: ele deve ser simulado. Só há feedback quando o trabalho está feito.
- Custos dos erros: normalmente altos.
- Funcionamento independente do artefato: deve ser independente do designer.
- Distinção entre especificação e construção
- Separação temporal entre especificação e entrega: especificação sempre precede a entrega.
E tambem enumera 12 invariantes da estrutura do espaco do problema para o design:
- Regras pessoais para parar e avaliar: como não há respostas certas e erradas e nenhum feedback do mundo, as regras de parar e avaliar serão derivadas da experiência.
- Predominância de recuperação da memória de inferências não demonstráveis na tomada de decisão.
- Função transformação: como a estrutura não é bem definida, o designer pode escolhermudar parâmetros do problema.
- Modularidade/decomposição: como as decomposições (e conexões) não são lógicas, o designer atende umas e ignora outras.
- Desenvolvimento incremental.
- Estratégia de controle: designers usam um modo de controle de compromentimento limitado, para poder gerar diversas soluções.
- Compromissos, assumindo e propagando: como planos e especificações devem ser interpretados por terceiros, o designer assume e propaga compromissos.
- Fases distintas de resolução de problemas.
- Hierarquias de abstração.
- Construção e manipulação de modelos: porque não há feedback do mundo, só quando o artefato está pronto.
- Uso de muitos sistemas externos de símbolos.
- Diferentes sistemas de símbolos se correlacionam com diferentes processos cognitivos.
ZIMRIG C., CRAIG, D. L. Defining design between domains: an argument for design research á la carte In: Design Cognition, Design Knowing e Learning. Editado por Charles Eastman, Mike McCracken e Wendy Newstetter. Elsevier, 2001.
CROSS, N. Design cognition: results from protocol and other empirica studies of design activity. In: Design Cognition, Design Knowing e Learning. Editado por Charles Eastman, Mike McCracken e Wendy Newstetter. Elsevier, 2001
EASTMAN, N. New directions in design cognition: studies of representation and recall. In: Design Cognition, Design Knowing e Learning. Editado por Charles Eastman, Mike McCracken e Wendy Newstetter. Elsevier, 2001
Recent Comments