In my regular questing, one of the phenomena I continue to explore is design. Investigating, for instance, reveals that, contrary to recommendations, designers approach practice more pragmatically. That’s something I’ve been experiencing both in my work with clients and recent endeavors. So, reflecting, are and should folks be diving or surfacing?

The original issue is how designers design. If you look at recommendations, they typically recommend starting at the top level conceptualization and work down, such as Jesse James Garrett’s Information Architecture approach (PDF of the Elements of User Experience; note that he puts the highest level of conceptualization at the bottom and argues to work up). Empirically, however, designers switch between top-down and bottom-up. What do I do?

Well, it of course depends on the project. Many times (and, ideally), I’m brought in early, to help conceptualize the strategy, leveraging learning science, design, organizational context, and more. I tend to lead the project’s top-level description, creating a ‘blueprint’ of where to go. From there, more pragmatic approaches make sense (e.g. bringing in developers). Then, I’m checking on progress, not doing the implementation. I suppose that’s like an architect. That is, my role is to stay at the top-level.

In other instances, I’m doing more. I frequently collaborate with the team to develop a solution. Or, sometimes, I get concrete to help communicate the vision that the blueprint documents. Which,  in working with an unfamiliar team, isn’t unusual. That ‘telepathy’ comes with getting to know folks ;).

In those other instances, I too will find out that pragmatic constraints influence the overarching conceptualization, and work back up to see how the guidelines need to be adapted to account for the particular instance. Or we need to deconnect from the details to remember what our original objective is. This isn’t a problem! In general, we should expect that ongoing development unearths realities that weren’t visible from above, and vice versa. We may have good general principles, (e.g. from learning science), but then we need to adapt them to our circumstances, which are unlikely to exactly match. In general, we need to abstract the best principles, and then de- and re-contextualize.

I find that while it’s harder work to wrestle with the details (more pay for IDs! ;), it’s very worthwhile. What’s developed is better as a result of testing and refining. In fact, this is a good argument about why we should iterate (and build it into our timelines and budgets). It’s hubris to assume that ‘if we build it, it is good’. So, let’s not assume we can either be diving or surfacing, but instead recognize we should cycle between them. Start at the top and work down, but then regularly check back up too!

Someone reached out to me for a case study on addressing a workplace problem. I was willing, but there’s a small problem; I’ve never had to address a workplace learning problem. At least, in the way most people expect. Instead, I provide an outside perspective. What’s that mean?

So, first of all, I don’t come from an instructional design (ID) background. I did get some exposure to educational approaches when I designed my own undergraduate degree in Computer-Based Education. Yet, there weren’t any ID courses where I was a student. As a graduate student, I took psychology courses on learning. I also read Reigeluth’s survey of ID design approaches. Further, I got a chance to interview the gracious and wise David Merrill. But, again, no formal ID courses were on tap.

On the flip side, I was in a vibrant program that was developing a cognitive science degree, and read everything on learning I could find: behavioral, cognitive, social, neural, even machine learning! I was in my post-doc as they were forming the learning science approach, too, and I was at a relevant institution. Still, no ID. So, I do have deep learning roots, just not ID.

Then, after the post-doc, I taught. That is, practiced learning design, and continued reading and talking ID, and attending relevant conferences. Just not a formal ID course. Then I joined a small startup to design an adaptive learning platform, and then started consulting, but never a workplace learning role inwardly faced.

What that means is that I bring an ‘outside’ perspective to L&D. Which, I think, isn’t a bad thing. I’ve helped firms meet realistic goals in innovative ways, courtesy of not having my thinking pre-constrained. I’ve been able to interpret learning science in practical terms, and infer what ID says (also, I’ve read it and reflected in context on it). So, I’ve talked L&D design, and ID improvements, but from the view of an outsider.

Many times outsiders can bring new perspectives. And, they can be ignorant of all the contextual details. Thus, it’s really important to ask and establish those constraints, and then to be sensitive to the ones that they didn’t mention. (One of the benefits of the court jester was to reframe things in ways that showed the humor in the hidden assumptions.) Still, I’m not apologizing. I think the background I’ve acquired is useful to people who need to meet real goals, and have a decent track record in doing so. I welcome your thoughts on whether an outside perspective is of benefit.

So, I’ve been on a bit of a crusade saying we’re not formal logical reasoning beings. And, I do think it’s important to emphasize this in the face of some legacy beliefs. On the other hand, I think there’s evidence that we can be logical. So, how do we reconcile this?

The reason I push against a belief that we’re logical is that too often we are designing as if that’s the case. We see it in way too many policies, practices, and the like. Yet, as has been documented, that’s not our default.

On the other hand, we can be effective reasoners. We have created complex mathematics, advanced science, and generally improved our situation. Something is going on. But what?

Well, Kahneman talks about how we, effectively, have two systems, fast and slow. The slow one takes cognitive effort, so we tend to avoid it. The fast one, then, is default. It’s based upon instinct. Which can be good in two situations: one, where our instincts are likely to be right (e.g. dealing with biologically primary information) or where we have expertise. It can also be bad, where we use it inappropriately.

On the other hand, we can use the slow route. It’s hard, but it works.  This is where we reason things out. (We have to be careful, because being hard, we can depend on it inappropriately.) We can use cognitive support, and complementary skills, but we can document the situation, explore alternatives, trial solutions, and reason our way to good decisions.

And we should! Frankly, I’d rather have in office a policy wonk building coalitions of expertise than a solitary ‘profile’ claiming solutions across the board. I want evidence-based approaches, not simplistic and wrong answers to complex problems!

So, we can be formal logical reasoning beings. Under the right circumstances, with the right support. We should automate what we can so we build the necessary expertise, and provide the conditions for good decisions. That can sometimes be fast, and sometimes be slow, but better to be right than to be expedient. Not perfect, of course, but I’m suggesting we err on the side of likelihood.

That’s my view, at any rate. We can be logical, and that’s a matter of design. We should evaluate and optimize situations so we get the best decisions. That recognizes when training is helpful, when performance support can be used, and when we should support good innovation (problem-solving, research, design, etc). So let’s take a healthy informed look at how we make decisions, and increase the likelihood of good ones. That’s my decision, at any rate. What’s yours?