A four-part series on design, barriers, and some heuristics to improve outcomes:
I found my passion in learning technology. I took most of a computer science degree (after flirting with biology, and…) before designing my own major combining CS with education. I went back to grad school to learn a lot about cognition and learning. I took a rather eclectic approach, going beyond cognitive approaches to include behavioral approaches, instructional design, social learning theories, constructivist learning theories, even machine learning. (I continue that today.)
As I took very much an ‘applied’ approach (not doing pure research, but interpreting research to meet real problems, now known as “design-based research” in the edtech field, but close to the more general ‘action research‘), and was teaching interaction design, I started looking at design processes in that same eclectic way. (NB: I’ve also tracked ‘engagement’, as those who’ve read the book or heard me speak on games know). I looked at interface design processes, and instructional design processes, heck, I looked at architectural, industrial, engineering, and graphic design processes. And I realized some things that I’ve talked about in various places but haven’t written about for over 10 years, and yet I think are still relevant. I’m going to talk here about design, our cognitive (and other) barriers to design, and my plan is to subsequently post about a suite of heuristics I’ve come up with to minimize the consequences of those barriers.
Design can be characterized as a search of a ‘solution’ space. Think of all the possible solutions as this n-dimensional space or cloud, and outside the cloud are designs that wouldn’t solve the problem, like the old approach we were using; inside the cloud are possible solutions). Sometimes we can evolve an existing design incrementally to solve the problem, and sometimes we combine previous solutions to create a new one (or so some theories say). Another way to think about it is we have this infinite solution space, and then we start putting in constraints that limit the space (must cost less than $50K, must be doable in six weeks, must work in our technical environment, etc). Constraints are actually good, as they limit the space we have to search. However, too often when we consider all the constraints, we’ve just made the space the null set; we’ve excluded any solution. Then we have to relax constraints: reduce scope, increase budget, etc.
One of the problems is prematurely limiting our search. It turns out that our cognitive architecture has biases that may limit our search long before we consciously look at our options. We may only search a limited space nearby our prior experience, and only achieve what’s know in search as a ‘local maximum’, as a good solution for part of the space but not the best solution overall (a ‘global maximum’). We need to know the barriers, and then propose solutions around those barriers. Coming up: Functional Fixedness, Set-Effects, Premature Evaluation, and the ever-dreaded Social issues. Stay tuned!