Flash and JavaScript are required for this feature.
Download the video from iTunes U or the Internet Archive.
Teaching Design Thinking
PROFESSOR BLADE KOTELLY: I think the way that we open their thinking in the process of teaching it is to start connecting our process to everything else they do in life. So start to really make sure that they understand the connections between the design process being used for something as simple as planning a birthday party to something more complicated, like making a mechanical system, designing a phone, or something like that. We try to have them reflect on it in their normal existence. So, do a design critique of something, and come back in with that. So we can actually have them think about oh, the design of a simple object in my life, what do I like about it? What don't I like about it? And then they start thinking a little bit differently, because they realize that all the ideas they've had about certainty, these principles are true-- they realize, well, they aren't always true. In fact, they're only true in context.
PROFESSOR JOEL SCHINDALL: Part of what we do in the class is to ask provocative questions. Students will give an answer that they think is the normal answer to the question. And Blade will say, why do you think that? The students are a little irritated. I think that because that's the right thing to think. But it turns out that it's not the only way to look at it. And they simply haven't challenged that way of looking at. And sometimes we have to walk a little fine line to not be too irritating with this. But the fact is, the irritation provokes the expanded exploration, the sensitivity to things around them, which is what we want to draw out in this class.
PROFESSOR BLADE KOTELLY: Some of the other goals include just doing a really clean, simple design process they can apply to anything. Being able to operate as a designer does. So in the context of whatever they're doing, know how to evaluate systems. Thinking about people. Understanding stakeholders. Understanding a little bit about the architecture of a system and how to abstract it out. Understanding how to write good requirements. Being able to usability test something to see if someone actually can use it, they like using it. Understanding the psychology of human interaction with technology is really important. Being able to think that the brand of something actually affects the way someone uses it. It's not just the logo or something else, but the way the whole system feels and the identity it produces in the mind of someone that's unique compared to other systems. And hopefully they're able to see all this whenever they create anything.
PROFESSOR JOEL SCHINDALL: Blade had previous experience when we put the course together in speech-activated satisfaction systems, or answering systems. There's no easy name for it in the language, or at least I'm missing it, but when you call American Airlines to get information about a flight, or when you call to order a pizza, you'll often interact with an automated voice system which gives you certain prompts, listens to your responses, and based on those responses it gives you other prompts. Most people find them very exasperating, because somehow they don't seem to be foreseeing correctly the issue that you're dealing with. And so we have the students design systems.
Initially, we have them design a simple pizza ordering system or simple banking transaction system, but then as their project for the term, they will do a more complicated system. Something like, one of them did a system-- I forget the exact name-- but it was for a parent to let a child call this automated system and it would say, "Hi, this is Santa's elf. And what would you like for Christmas this year?" And the child will respond with what it would like to get for Christmas. And the system is prompted to listen for things and it will record the child's answer, say that's a wonderful thing, we'll see what we can do. And then the system actually will call or text the child's parent to tell the child's parent what the child asked for for Christmas. It was a very clever idea, and it was implemented in such a way that people who used it actually had fun and enjoyed the answers.
The challenge for the students is that you'd think that designing a speech-activated system is an easy thing to do. And you quickly get humbled by the fact that the first person who you have try it comes up with a perfectly logical response that is not what you had predicted. And it forces you to get into the user's head and look at what do I need to provide the user in the way of information and what responses do I need to be prepared to respond to, so that I can have an effective dialogue with this user? It's a wonderful way of training the students in how to be methodical, how to put together a plan, how to engineer something, but how to also test it with users and deal with the issues that come up with those users.