Friday, July 6, 2018

Design thinking is not an output only process

An Education Dive piece suggests that design thinking can help students with creativity and empathy. There has been a lot of conversation around design thinking because it's one of the current buzzwords in education. Some see it as an opportunity, some see it as an answer to a question they've not yet formulated, and others are waiting to see if this becomes an actual thing in education.

As the article notes, the concept of design thinking is generally associated with Stanford's d.School. The specific elements of that design thinking process are empathize, define, ideate, prototype, and test. Eons ago, when I was a systems analyst and programmer, we used the ADDIE model. There are some similarities though "analysis" sounds colder and more disconnected than "empathize."

So let's look closely at the elements of "empathize" in the Stanford model: interviews, shadowing, seek to understand, non-judgmental. As a systems analyst, I would have read a customer's project request so I had a very high level view of what the customer thought they wanted. Then we would do a version of 20 questions as I sought to have a clearer understanding of what the customer really wanted. They would be surprised by how much information they hadn't provided simply because it didn't occur to them. While I might not have been able to shadow in person, we would talk through processes, where things worked and where things needed to be improved or changed. My job was to understand what they were trying to accomplish and then provide a path to a solution that worked for the near-term and the foreseeable future. By often frustrating and painstaking review, we might uncover systems or processes they hadn't thought about or even situations they hadn't considered.

Then I could craft a design. We would review the design and make adjustments because by then the customer was thinking more clearly and more specifically. I'd have people tell me that every time they went back to their shop or their office, they would notice something they'd stopped seeing over time. Sometimes that mattered to my project and sometimes it didn't. When we were comfortable with the design, I would develop a prototype. We put together test situations to see how the system responded and would put it through its paces for the customer.

It was never right the first time, but we were often very close. We could then make adjustments, make sure we were really going in the direction the customer wanted, then fine tune the design and the product to a more final version.

Let me make a note here: there were times that the prototype showed the customer that their thinking was not quite accurate. By helping them notice more particularly, they often became aware of other issues that needed to be resolved. Sometimes that could be within the purview of whatever we were building but most of the time it did not. I've never had a customer scrap a project at the prototype, but I have had them make some serious adjustments to the final product or realize that the current project was an interim project.

Now, what does that have to do with the classroom? A.J. Juliani refers to the IDEO variation of design thinking which can provide students with a framework for thinking about how to find a solution to a problem and references other models for the design process.

So let me make another note here: what teachers are asking students to do is use a particular process to find a solution to a problem or situation. As a result of using this process, especially if they use the process regularly, they begin to adopt it and use this design process as a natural part of their thinking.

I've never stopped being a systems analyst in terms of the way I approach a challenge or problem, whether the project is for me or someone else (though I probably think through potential problems less when I'm working on a project for myself). So by using a design process--Stanford's d.School design process or IDEO's process or even ADDIE--students adopt and adapt the way they think about finding solutions.

John Spencer and A.J. Juliani developed what they called the LAUNCH Cycle for design thinking. It's pretty cool and definitely student friendly.
  • L: Look, listen, and learn. The point is for students to develop awareness. . .of the situation, of the audience who might need or want to use the end result, of the problem to be solved and why it needs to be solved, etc.
  • A: Ask tons of questions.
  • U: Understand the process or problem. In my opinion, this comes from asking tons of questions and doing research, maybe even seeing and trying to use the existing system or process or product to see why and how it might be improved or refined.
  • N: Navigate ideas. This is the ideate phase in Stanford's model and the design phase in ADDIE. Brainstorm, create a DFD or flowchart (seriously, a flowchart can really help!), test ideas, combine parts of ideas, and be prepared to do more research and ask more questions. This is most definitely an iterative process.
  • C: Create a prototype. This could be digital or it could be something made with craft sticks and duct tape or a glue gun. The prototype has to be testable.
  • H: Highlight and fix. This makes sense, of course, because once students start testing the prototype they'll see what works and what doesn't. This too is an iterative process. And, as Spencer notes, it's "where every mistake takes them closer to success."
Design thinking isn't new, but the names and some of the elements are new. Back in the late 70s, programmers used the Ganes and Sarson Data Flow Diagram (DFD) model, a model that was used through the 80s. In fact, the concept of DFDs can still be seen in agile modeling. Anyway, it was the same premise. Design something based on all of the information you have and can gather. Poke holes in it. Figure out where things could go wrong. Ask lots of questions. Redesign. Poke more holes in it. Figure out where things could go wrong. Ask more questions. Redesign. Once they determined they had covered as many known bases as possible, systems were built and tested. First came stub tests, then more complex tests depending on the nature and complexity of the system. I'll stop there because I can sense your eyes glazing over. ;)

But that testing piece is important and it is often overlooked in student-focused processes. So kids asked all of those questions at the beginning of the process to figure out how to build a prototype to get to a final product. But they use little of that data to figure out if the prototype really works because they don't design good tests. They design the basic "does it work?" test. And maybe that's enough.

What engineers and systems designers know about that the "does it work?" test is that it's not nearly enough. Does it work if the conditions are perfect? Excellent. But what if the conditions are not quite perfect? What if you try a heavier weight? What is someone tries x instead of y? Is that x variable a likely option? One of the challenges of testing is thinking about what users are likely to do and within reason. Asking students to design tests a bit more complex than "does it work?" will help them see flaws but also help them see potential.

My point is this: design thinking becomes a part of the way a student engages in learning and the world. Design thinking is a natural part of PBL. Design thinking can also be a logical and natural way to approach Genius Hour. After a while, design thinking will become a logical and natural extension of the way students approach any learning situation.

It is not limited to PBL or STEM/STEAM or Genius Hour. Design thinking can become the way students think. Period. The framework they use--whether Spencer and Juliani's LAUNCH cycle or the ADDIE model (more recognizable outside of schools) or the Stanford d.School model--doesn't matter.

The end result is thinking differently about a challenge or problem to be solved.

The end result is learning to think about how to find a solution that works and makes sense for the situation rather than simply how to solve a problem.

No comments:

Post a Comment