For deeper learning to be systematically integrated into the experiences we create, we need an enlightened design process. To complement our white paper on deeper learning, we’re also creating a series of posts about a deeper learning design process. This first post outlines the underlying approach.
The main reason to have a design process is to have a manageable and predictable process that we can use to estimate timelines and costs. When we design, we typically need to have a specified budget and schedule, at least once the analysis is done (and a separate budget and schedule for the analysis too, then). A second, and equally important reason, is to overcome our flaws as designers. Our cognitive architecture, as amazing as it is, inherently contains some systemic limitations. (No one architecture can do it all!) Thus, our design process needs to minimize those problems and provide remedies.
The flaws in our architecture include phenomena such as set effects, functional fixedness, premature evaluation, and more. ‘Set effects’ means we tend to solve new problems in ways that we solved previous problems, even if a different way would be better. ‘Set effects’ is where we tend to limit our use of tools to one approach, even if the tools can be used in other ways. We also tend to prematurely converge on some solutions without fully exploring all of them, despite the benefits of diverging in our search before converging on an approach.
There are other limitations to how our minds work, too: our working memory is small, we have some randomness in our actions, we typically have trouble remembering large amounts of arbitrary information, and so on. We have developed tools and practices to get around these limitations. For instance, we can use templates for parts of our information gathering and design, to avoid overloading our cognitive capacity. We also use checklists to help us not skip steps. Further, we use external representations such as spreadsheets to overcome our inability to remember large quantities of information.
We also have built into our practices things like prototyping and early evaluation, (proper) brainstorming, and more. Here, we recognize that those we design for are also human, and we can’t completely anticipate the ways in which they can interpret our ideas. Thus, we need to test and tune them. Yet we also want systematicity. We do analysis before design, before development.
We’ve got nuances within all of this. As designers, we should follow the best principles, using the right tools. My hope, here, is to lay out some of those practices with the cognitive rationale that underpins them. Learning science, like design, is based on how our brain works. Understanding that leads to not only better designs but better design processes. Which, after all, is what we all should want.
