Today we played Little Big Planet.
No, seriously. We pulled the couches out from the walls, sat down, and engaged in epic 3-player platforming action.* The students, needless to say, were thrilled, even if none of them had played Little Big Planet previously.** They scuffled along through the first few levels, each group of three getting just enough play time to whet their appetites and to become comfortable with the basic controls. Meanwhile their classmates played games of their own: Apples to Apples, Chess, and "Trumps," a card game similar to Whist or Spades.
* It would have been four, but the fourth controlled wouldn't recognize the PlayStation, and I didn't have the USB cable to plug it in with.
** Isn't this generation supposed to be all game all the time? How have they not played LBP? I was even more shocked to discover this than I was when I heard they had not seen The Princess Bride.
Now hold on, you're thinking, how could you possibly get away with doing that in a high school creative writing class? Games are for wasting time, for eating away at kids' brains and turning them into useless zombie-people, right?
To which I can only respond: yes, and soon my zombie army will be complete.
Actually, my reasons for playing Little Big Planet stem from the core values of the class: collaboration, dialogue, and metacognition. The playing itself doesn't really hit those - there's a degree of collaboration, but the other two are limited - but it's not what you do that counts, it's how you do it. On the front end of our LBP adventure we used LBP's character creator to imagine a story snippet involving a zombie-pirate, and then worked on a (seemingly unrelated) mini Design project. On the back end, we designed games of our own using the materials available in the classroom (from Apples to Apples to dice, cards, chess pieces, and so on). Tomorrow, the students will be writing essays about the design of LBP, their learning while playing it, and their own experience designing a game. And then we'll be talking about how all of that connects to creative writing.
How does it connect to creative writing? Easy, it's creative, and it's writing. Playing a game is constructing a narrative. Designing a game is even more so, because you have to build into your design the learning and narrative-building of your potential player. Is that any different from writing, where you have to build a narrative, ensure that your audience can read (and sometimes learn to read) your work, and be engaged? Perhaps the outcome is different - indeed, there's no question that the outcomes of game design and creative writing differ - but the processes might have a lot in common, after all.
That's certainly my bias, and that's a big part of why I've made design a pivotal part of my curriculum. But it's no good doing design and restricting it to writing in the narrowest sense of poems, short stories, and essays. The real value of design, to a writer, is taking it to other areas: games, architecture, movies, and even other-class-interrupting-presentations (about which I will remain mysterious). Thinking outside the box - letting "writing" become bigger than just words on a page and letting "design" replace "creativity" - is a great way to become a better writer (and maybe even a better, or at least more interesting, person?). And, what's more, a great way to learn how to become a better writer, which is the real thing.
It's no accident then, that as we wrap up our mini design projects - including game design - tomorrow with finished products, an essay, and a discussion (see, playing PlayStation can lead to actual work) we'll start looking at Invisible Cities,* start trying to repaint the campus and the city and the world in which we live in terms of both design and literature. Having digested, or at least partially chewed, all of that, the students will be drafting a proposal for a final project. My hope? Collaboration, and a shortage of traditional short stories and poems. If the lot of them want to, say, write an interactive fiction computer game as a team and publish it on the Kongregate Arcade... Frankly, I'd be thrilled.
* For the longest time I couldn't decide whether I should do this work in the prose week or the poetry week. And then I realized that, duh, it belongs in the design week. It is, really, a quintessential "design literature" book. Heck, they even read it in architecture programs, or so I've heard.
So why Little Big Planet? Well, it fits into what I'm doing. But I used it not just because it fits, but because I want to model imagination, stepping beyond the bounds of what's expected, breaking "the rules." We played Little Big Planet today because it was fun, but also because it was a small, trivial, and totally essential step towards a set of entirely original, creative, and against "the rules" final projects.*
* Or at least I hope so...
Showing posts with label design thinking. Show all posts
Showing posts with label design thinking. Show all posts
Tuesday, June 28, 2011
Thursday, October 21, 2010
Comparing Discussion to Brainstorming
One of the most important parts of a design process is good brainstorming. It is impossible to end up with good prototypes - that is, prototypes that result in meaningful feedback - without being unafraid to engage in the kind of intensive, creative, and often bizarre brainstorming that is at the heart of companies like IDEO or programs like Stanford's dschool. But what makes for a good brainstorm?
I have both participated in and facilitated (and often both at the same time) brainstorms with my peers, with teachers and administrators, and with students. In that experience, I have found that good brainstorms essentially follow the rules I was taught at the dschool. But I have also found that those good brainstorms - those rules for brainstorming - are nothing all that revolutionary. It strikes me that a good brainstorm is a lot like a good conversation, only with a whiteboard and more post-it notes.
What do I mean? Consider the dschool's "rules for brainstorming:"
1) Defer judgment
2) Go for volume (that is, quantity, not noise)
3) One conversation at a time
4) Be visual
5) Headline
6) Build on the ideas of others
7) Stay on topic
8) Encourage wild ideas
Obviously a number of these rules complement each other. One conversation at a time, build on the ideas of others, and stay on topic are mutually reinforcing rules. Likewise, going for volume and encouraging wild ideas work together. The more wild the ideas, the more likely the brainstormers will produce more of them.
For my own part, I find facilitating a brainstorm fascinating, because the role the facilitator has to play is one of empowerment. That is, you have to empower people to follow the rules. Sometimes that comes in the form of yelling "One at a time!" or "Headline!" when appropriate. More often, however, a teacher of brainstorming has to offer the wildest and craziest ideas that everyone else is afraid to mention. For example, during our recent NALU 102 session, when the students were brainstorming experimental questions to investigate at Waimanalo Beach Park, I offered the classic "how many grains of sand are there on the beach?" Why? Not because I thought it was feasible or even all that interesting, but because I wanted to demonstrate that there's no reason to only ask questions that you can answer easily.
The same can be said of brainstorming for product development. It's a waste of time to suggest only ideas that are easy to do. I doubt that the people at Nintendo, for example, were having a sedate and measured conversation about feasibility when they first came up with the Wii. No, that was a wild idea that turned into an industry force principally because it was a wild idea. Similarly, I don't think the Google folks held back when offering the idea of getting street-view pictures of every road and intersection in the country to include with GoogleMaps. Wild ideas - even the ones that don't lead anywhere - are essential to coming up with something that is actually innovative.
Anyway, the point here is not to discuss brainstorming, but to talk about how brainstorming is similar to a good, dialogic conversation. As a graduate of St. John's College I have some strong opinions as to what makes a good conversation, but fortunately I don't have to articulate those myself. Stringfellow Barr, one of the founders of the Great Books program at the college, wrote a wonderful piece called Notes on Dialogue that does the job for me.
There's less "headlining" than in the dschool list, granted, but I want to call out what I understand to be Barr's "rules for a good conversation:"
1) Be brief
2) Suggest crazy ideas
3) Ask for clarification
4) Practice prevents bedlam
5) Listen to each other
6) Try to reach an agreement
7) Follow the argument wherever it goes
8) Don't use hand-raising as a crutch
9) Listen to each other (again) and be friends
10) Don't take things too seriously
Now these rules are not identical to the brainstorming rules, but I see some overlap. Consider Barr's demand for brevity in dialogue. That matches quite well with the brainstorming maxim of headlining, as well as the desire to promote quantity of ideas. Both the dschool and Barr agree, also, about the importance of wild ideas. Moreover, the brainstorming triumvirate of "one at a time," "stay on topic," and "build on each other" are intimately related to Barr's ideals of listening to each other and following the argument where it leads. I would also associate not taking things too seriously with deferring judgment.
What Barr does that the dschool does not do is address some of the "how," instead of just the what. Barr advocates what goes without saying in brainstorming: practice makes perfect. In dialogue, in particular, this is important, because as Barr points out, engaging in a non-hands-raising, authentic dialogue is extremely frustrating and often highly ineffective with beginners. Of course, the same is true in brainstorming, where too many beginners are liable to talk over each other, to judge each other's ideas, and to be afraid to sound too crazy.
I also think that - and have experienced that - asking for clarification is sometimes essential in a brainstorm. "Headline" can be translated as "be brief," but it can also mean, "ask someone to clarify or simplify." Often when someone is facilitating a brainstorm (or when experienced brainstormers are working without a facilitator), the shout of "headline!" means exactly that: simplify, clarify, explain.
Perhaps the only substantive difference between the two lists is in the brainstorming preference for visual representation. Because dialogue is a purely auditory and oral event, there is little opportunity to draw on the board (though of course, as Barr says, doodling is permissible and even encouraged). It is true, at St. John's anyway, that good conversations in math or science classes often find a student or tutor at the board drawing mental models or working with equations, but that is a far cry from the design ideal of representing every idea - or as many ideas as possible - with pictures instead of words.
This difference is a fascinating cultural disparity between a past that was much more bookish than we are today. For good reason we do better encouraging the visual in our modern conversations. Nevertheless, the heart of a good conversation remains the same: listen, be brief, and don't be afraid to offer a wild idea. It strikes me that two places so different as Stanford - at the cutting edge of design and technology and science - and St. John's - employing a Great Books and dialogic model that is over a century old - could be so close together not in what they do, but in how they do it. To me that is an affirmation that good thinking, good collaboration, and good conversations, whether for the sake of building something, for the sake of understanding something, or just for fun, have some fundamental building blocks that are the same in almost any environment.
I have both participated in and facilitated (and often both at the same time) brainstorms with my peers, with teachers and administrators, and with students. In that experience, I have found that good brainstorms essentially follow the rules I was taught at the dschool. But I have also found that those good brainstorms - those rules for brainstorming - are nothing all that revolutionary. It strikes me that a good brainstorm is a lot like a good conversation, only with a whiteboard and more post-it notes.
What do I mean? Consider the dschool's "rules for brainstorming:"
1) Defer judgment
2) Go for volume (that is, quantity, not noise)
3) One conversation at a time
4) Be visual
5) Headline
6) Build on the ideas of others
7) Stay on topic
8) Encourage wild ideas
Obviously a number of these rules complement each other. One conversation at a time, build on the ideas of others, and stay on topic are mutually reinforcing rules. Likewise, going for volume and encouraging wild ideas work together. The more wild the ideas, the more likely the brainstormers will produce more of them.
For my own part, I find facilitating a brainstorm fascinating, because the role the facilitator has to play is one of empowerment. That is, you have to empower people to follow the rules. Sometimes that comes in the form of yelling "One at a time!" or "Headline!" when appropriate. More often, however, a teacher of brainstorming has to offer the wildest and craziest ideas that everyone else is afraid to mention. For example, during our recent NALU 102 session, when the students were brainstorming experimental questions to investigate at Waimanalo Beach Park, I offered the classic "how many grains of sand are there on the beach?" Why? Not because I thought it was feasible or even all that interesting, but because I wanted to demonstrate that there's no reason to only ask questions that you can answer easily.
The same can be said of brainstorming for product development. It's a waste of time to suggest only ideas that are easy to do. I doubt that the people at Nintendo, for example, were having a sedate and measured conversation about feasibility when they first came up with the Wii. No, that was a wild idea that turned into an industry force principally because it was a wild idea. Similarly, I don't think the Google folks held back when offering the idea of getting street-view pictures of every road and intersection in the country to include with GoogleMaps. Wild ideas - even the ones that don't lead anywhere - are essential to coming up with something that is actually innovative.
Anyway, the point here is not to discuss brainstorming, but to talk about how brainstorming is similar to a good, dialogic conversation. As a graduate of St. John's College I have some strong opinions as to what makes a good conversation, but fortunately I don't have to articulate those myself. Stringfellow Barr, one of the founders of the Great Books program at the college, wrote a wonderful piece called Notes on Dialogue that does the job for me.
There's less "headlining" than in the dschool list, granted, but I want to call out what I understand to be Barr's "rules for a good conversation:"
1) Be brief
2) Suggest crazy ideas
3) Ask for clarification
4) Practice prevents bedlam
5) Listen to each other
6) Try to reach an agreement
7) Follow the argument wherever it goes
8) Don't use hand-raising as a crutch
9) Listen to each other (again) and be friends
10) Don't take things too seriously
Now these rules are not identical to the brainstorming rules, but I see some overlap. Consider Barr's demand for brevity in dialogue. That matches quite well with the brainstorming maxim of headlining, as well as the desire to promote quantity of ideas. Both the dschool and Barr agree, also, about the importance of wild ideas. Moreover, the brainstorming triumvirate of "one at a time," "stay on topic," and "build on each other" are intimately related to Barr's ideals of listening to each other and following the argument where it leads. I would also associate not taking things too seriously with deferring judgment.
What Barr does that the dschool does not do is address some of the "how," instead of just the what. Barr advocates what goes without saying in brainstorming: practice makes perfect. In dialogue, in particular, this is important, because as Barr points out, engaging in a non-hands-raising, authentic dialogue is extremely frustrating and often highly ineffective with beginners. Of course, the same is true in brainstorming, where too many beginners are liable to talk over each other, to judge each other's ideas, and to be afraid to sound too crazy.
I also think that - and have experienced that - asking for clarification is sometimes essential in a brainstorm. "Headline" can be translated as "be brief," but it can also mean, "ask someone to clarify or simplify." Often when someone is facilitating a brainstorm (or when experienced brainstormers are working without a facilitator), the shout of "headline!" means exactly that: simplify, clarify, explain.
Perhaps the only substantive difference between the two lists is in the brainstorming preference for visual representation. Because dialogue is a purely auditory and oral event, there is little opportunity to draw on the board (though of course, as Barr says, doodling is permissible and even encouraged). It is true, at St. John's anyway, that good conversations in math or science classes often find a student or tutor at the board drawing mental models or working with equations, but that is a far cry from the design ideal of representing every idea - or as many ideas as possible - with pictures instead of words.
This difference is a fascinating cultural disparity between a past that was much more bookish than we are today. For good reason we do better encouraging the visual in our modern conversations. Nevertheless, the heart of a good conversation remains the same: listen, be brief, and don't be afraid to offer a wild idea. It strikes me that two places so different as Stanford - at the cutting edge of design and technology and science - and St. John's - employing a Great Books and dialogic model that is over a century old - could be so close together not in what they do, but in how they do it. To me that is an affirmation that good thinking, good collaboration, and good conversations, whether for the sake of building something, for the sake of understanding something, or just for fun, have some fundamental building blocks that are the same in almost any environment.
Friday, May 14, 2010
An Ode to Stardock
As a Stanford graduate student, it is almost impossible to avoid design. Never mind that "design" is in the title of the program I'm a part of, design permeates the Stanford world. Why? Because almost everything we interact with day-to-day, as well as the way that we interact with those things, is the product of some design process. Good design process, however, is hard to find.
I won't go too far into what Stanford bills "Design Thinking" right now. Instead I want to talk a little about video game design, and the difference between what most companies do and what one company in particular - Stardock - does. Along the way perhaps we'll get some design thinking, too.
Most game companies, like Electronic Arts, develop game ideas that they think will be marketable and will appeal to a wide audience. The Madden series is a good example of this. Americans love football, especially long passes, bone-crushing sacks, stiff-arms, and spin-moves, so EA developed a game that is, essentially, a hyped up version of football that is realistic enough to not feel gimicky, but far enough removed from being realistic that it's not frustrating to play for the majority of EA's consumer-base. That's a model that works, and EA has gotten away with progressive minor graphical upgrades and occasional feature additions on the way to huge sales year after year of what is essentially the same game.
Of course, EA is not alone in this. Almost every major game - especially on the PC, but also on consoles - these days is a sequel. Mass Effect 2, Tropico 3, Majesty 2, Fallout 3, Final Fantasy 7,326, and so on. In sports gaming, perhaps it's inevitable that all games are remakes, but in strategy, or RPG, or action it's not so much good game-design as good business.
Stardock does things a little differently. Don't get me wrong, they are still doing what they need to do to make money. Because Stardock is a hybrid company, they use their massive enterprise software profits to support a game-development branch that can afford to and does risk doing things differently. The result has been some of the most innovative games of the last few years: Sins of a Solar Empire, Demigod, and Galactic Civilizations. All three were successful and, in their own ways, completely different from what anyone had done before.
At the moment, Stardock is developing Elemental: War of Magic. Old-time gamers will recognize Master of Magic, one of the most famous strategy games of all time, and the godfather of Elemental.

What is striking about Elemental, besides the far superior, post-1995 visuals, is the process Stardock has used in its development. Design Thinking 101, you might call it.
(Here's a link to some screenshots)
Stardock opened the Beta for Elemental to any and all pre-ordering customers over a year before their scheduled release date. In essence, they made available to the public an early alpha version of the game, sans graphic engine, sans most features, sans fun. Why? Because they wanted to know what their customers wanted to have in the game. They had a lot of good ideas themselves, of course, and as experienced game designers they knew what they reasonably could and could not hope to accomplish. But the most important first step to good design thinking is to build empathy, to know not what you can, should, and desire to make, but rather what you ought to make, and for whom. Stardock, more than any other game designer, does just that.
For example, Stardock's last game, Demigod, was a multi-player focused RTS/RPG hybrid. It released buggy, struggled in reviews, and never really took off despite a fairly solid game mechanic and an innovative structure. Stardock learned, from the subsequent year's customer survery - which, I should mention, they publish freely - that most of their buyers don't really care for multi-player games. In a time when the gaming world is going MMORPG, where World of Warcraft has a larger annual income than many countries, this is a stunning revelation. It's not that people don't want multi-player, it's that there are a whole bunch of gamers who simply don't play online, but for whom almost no one is developing games anymore.
As they continually build a sense of what their future players want, Stardock also continues to introduce the prototypes of ideas they develop in their own brainstorm. The public beta has allowed for more feedback than most games could ever hope to get, both in the form of bug-catching and in terms of refining the game engine. This is also design thinking: rapid prototype, show to users, and refine based on feedback. Whereas EA doesn't show this year's Madden to a large audience until release, at which point features are locked in and only bugs remain (because it's way easier to catch bugs with 1,000,000 players than with 100 testers). Stardock, by making the game available before it is finished, is allowing the game's future players to actually help determine what's in the game.
The most exciting thing about Stardock, however, is that they're not just a bunch of crazy idealists. They have a business model, a successful plan. They are already a strong, established company, and they are just as susceptible to the need for profits as any other corporation. What's exciting, then, is that they do things the right way anyway, because, as it turns out, that's a more sustainable model for customer satisfaction, long-term profits, and, when it comes down to it, good, satisfying design. Where Electronic Arts is lagging in innovation compared to companies like Paradox Interactive and Bioware (who they essentially bought-out), Stardock is leading the way in building games for people, rather than building games for games.
I won't go too far into what Stanford bills "Design Thinking" right now. Instead I want to talk a little about video game design, and the difference between what most companies do and what one company in particular - Stardock - does. Along the way perhaps we'll get some design thinking, too.
Most game companies, like Electronic Arts, develop game ideas that they think will be marketable and will appeal to a wide audience. The Madden series is a good example of this. Americans love football, especially long passes, bone-crushing sacks, stiff-arms, and spin-moves, so EA developed a game that is, essentially, a hyped up version of football that is realistic enough to not feel gimicky, but far enough removed from being realistic that it's not frustrating to play for the majority of EA's consumer-base. That's a model that works, and EA has gotten away with progressive minor graphical upgrades and occasional feature additions on the way to huge sales year after year of what is essentially the same game.
Of course, EA is not alone in this. Almost every major game - especially on the PC, but also on consoles - these days is a sequel. Mass Effect 2, Tropico 3, Majesty 2, Fallout 3, Final Fantasy 7,326, and so on. In sports gaming, perhaps it's inevitable that all games are remakes, but in strategy, or RPG, or action it's not so much good game-design as good business.
Stardock does things a little differently. Don't get me wrong, they are still doing what they need to do to make money. Because Stardock is a hybrid company, they use their massive enterprise software profits to support a game-development branch that can afford to and does risk doing things differently. The result has been some of the most innovative games of the last few years: Sins of a Solar Empire, Demigod, and Galactic Civilizations. All three were successful and, in their own ways, completely different from what anyone had done before.
At the moment, Stardock is developing Elemental: War of Magic. Old-time gamers will recognize Master of Magic, one of the most famous strategy games of all time, and the godfather of Elemental.
What is striking about Elemental, besides the far superior, post-1995 visuals, is the process Stardock has used in its development. Design Thinking 101, you might call it.
(Here's a link to some screenshots)
Stardock opened the Beta for Elemental to any and all pre-ordering customers over a year before their scheduled release date. In essence, they made available to the public an early alpha version of the game, sans graphic engine, sans most features, sans fun. Why? Because they wanted to know what their customers wanted to have in the game. They had a lot of good ideas themselves, of course, and as experienced game designers they knew what they reasonably could and could not hope to accomplish. But the most important first step to good design thinking is to build empathy, to know not what you can, should, and desire to make, but rather what you ought to make, and for whom. Stardock, more than any other game designer, does just that.
For example, Stardock's last game, Demigod, was a multi-player focused RTS/RPG hybrid. It released buggy, struggled in reviews, and never really took off despite a fairly solid game mechanic and an innovative structure. Stardock learned, from the subsequent year's customer survery - which, I should mention, they publish freely - that most of their buyers don't really care for multi-player games. In a time when the gaming world is going MMORPG, where World of Warcraft has a larger annual income than many countries, this is a stunning revelation. It's not that people don't want multi-player, it's that there are a whole bunch of gamers who simply don't play online, but for whom almost no one is developing games anymore.
As they continually build a sense of what their future players want, Stardock also continues to introduce the prototypes of ideas they develop in their own brainstorm. The public beta has allowed for more feedback than most games could ever hope to get, both in the form of bug-catching and in terms of refining the game engine. This is also design thinking: rapid prototype, show to users, and refine based on feedback. Whereas EA doesn't show this year's Madden to a large audience until release, at which point features are locked in and only bugs remain (because it's way easier to catch bugs with 1,000,000 players than with 100 testers). Stardock, by making the game available before it is finished, is allowing the game's future players to actually help determine what's in the game.
The most exciting thing about Stardock, however, is that they're not just a bunch of crazy idealists. They have a business model, a successful plan. They are already a strong, established company, and they are just as susceptible to the need for profits as any other corporation. What's exciting, then, is that they do things the right way anyway, because, as it turns out, that's a more sustainable model for customer satisfaction, long-term profits, and, when it comes down to it, good, satisfying design. Where Electronic Arts is lagging in innovation compared to companies like Paradox Interactive and Bioware (who they essentially bought-out), Stardock is leading the way in building games for people, rather than building games for games.
Labels:
business,
design thinking,
Electronic Arts,
Elemental,
Stanford,
Stardock
Saturday, February 6, 2010
What's the Problem?
Kumu Keahi, a friend and teacher in Honolulu, gives a lesson to his students about his "Problem-Solution Algorithm-Matrix." I'm not sure exactly if I have the hyphens in the correct places, but you get the idea. The goals of this lesson are many, but the most important bit is the end, where he implores students to be leaders because it is leaders who act, rather than simply sitting back and arguing or contemplating forever.
Keahi says there are five steps to problem solving, and ties each to a level of thinking and development. The steps are as follows:
1) Recognize that there is a problem - "This is something even a cockroach can do," Keahi says. "You turn on the light, and the cockroach says, 'whoa, that's a problem,' and scurries into the corner."
2) Identify the problem and its source - This is, as I recall, high school-level thinking. More on that in a second.
3) Enumerate possible solutions - This, Keahi says, is more college-level thinking.
4) Select a solution - You can see where this is going; this is graduate school-level thinking.
5) Act - Here, of course, is where Keahi springs the leader bit on his students. Those previous levels do not mean that you need to go to grad school, because leaders are the most important thing.
I don't think Keahi means to insinuate that we should act without doing a good job identifying problems or selecting solutions, because it is something of a truism that action without reflection or strategy often results in making things worse. It is no accident, too, that educated people often struggle to act, because one of the marks of education is a recognition that simple solutions - solutions that are easy to act upon - often have unintended consequences. A simple example would be the standards movement in education: standards were designed as a way to make sure every student was reaching a certain baseline of knowledge. The real outcome, however, has been a high-stakes, test-based system that reinforces socio-economic boundaries rather than blurs them. That was never the intent, but it has been the outcome.
While I think Keahi's lesson is quite valuable for teenagers, I'm not convinced the problem-solving process is actually so linear (nor am I convinced that Keahi would claim it is). The second step, in particular, is trickier than it seems. Identifying the problem is a matter of much nuance and skill, and in fact failure to so properly is the cause of many failed solutions.
The "d.school" at Stanford believes in user-centered design, and emphasizes identifying the problem, not by simply contemplating, but by asking users. One might cynically suggest that this kind of design thinking leads to "discovering" problems that don't really exist (consider the Snuggy, or any other infomercial product) by mis-emphasizing needs,* but on the whole it's a fairly good system. There's a certain attractive subtlety in asking users what they want, and then comparing their words with their actions and emotions to determine their needs.
* What I mean is, it's easy to watch someone with a blanket and decide that they really don't want to get out from under it when answering the phone. Indeed, the person might even be able - with prompting - to articulate this need. More interesting, however, are the unarticulated needs that are perhaps subtler and larger-scale. I believe the d.school would be interested, not in reinventing the blanket, but in reinventing the phone. But I don't really know. Either way, you can see that defining the problem here is tricky; which is why it is treacherous to let marketing decide the problem for you.
User-centered design, however, does not always work in education. Indeed, formal education would not exist if the "users" (students) could articulate their needs. Educators believe, by necessity, that they not only have material that students need to learn, but that the students will not be able to identify what that material is on their own. That might sound draconian, but think of it this way: what second grader would choose, of his own free will, to learn to read, to write, to do arithmetic, and to share? Perhaps those things would come naturally by contact with a literary, mathematical, and socially complex culture. But perhaps not.
As we get further along - as students are given more choice in the form of "elective" classes - there remains an external push for students to continue taking math, English, foreign language, and - in some blessed schools - art and athletics courses. While much could be said about how those courses fail, it seems fair enough to say that educators as a whole have a better sense of how important those subjects are to future happiness and success. From the other perspective, there are many students who wish they'd paid more attention in Spanish class. There's a certain irony here: students only realize how much teachers have their best interests in mind after they're out of school. Regardless, there seems to be general agreement that teachers can identify the problems of education better than the "users" can.
The contrarian in me, however, wants to point out that this has lead to an under-emphasis on student opinion. A great deal of education research and policy concerns teacher practices, administrator opinions, community biases, impersonal standards, and parent involvement. Where, in all of that, are the kids? User-centered doesn't have to mean students know what they need to learn. It could, alternatively, mean that students have a good sense of why they aren't learning. Indeed, they might have more to say about themselves than tests ever could.
The challenge, here, is that students have a hard time articulating what they dislike about school. What's the problem? School sucks. That's not a good dialogue. Rare is the researcher who, like Dr. Denise Pope at Stanford, decides to follow students around and comes up with a mutually agreeable conclusion.
Pope's Doing School highlights one of the great many problems in education - and this is the bigger issue; there is never only one problem. Where much research focuses on what's wrong, Pope's research question was the opposite: what's going right at good schools, and with good students? She followed around five students over the course of the year, shadowing, doing interviews, and avoiding teachers, parents, and administrators. She wanted the student perspective, and she got it.
What did she get? Well, she went in trying to find out what was right, but she saw instead something deeply wrong. All of these "excellent students" she followed were unhealthy and unhappy. They cheated. They competed mercilessly with their classmates. They never actually remembered the material they were meant to be learning. They were, in short, "doing school."
In a competitive education system, it's easy to look at the people who fail. Competition necessitates failure,* and it is easy to see the racial and economic biases that predict that failure. Many education researchers and reformers, therefore, target the failing schools. What they ignore is the successful schools and successful students where, as Pope discovered, students are miserable, and not learning a thing.
* And don't you forget it. A great deal of hand-wrangling is done over "failing schools." Standardized tests are designed to produce a curve. Schools, in short, are supposed to fail. Either policy-makers who make a big deal of this are very clever, ignorant, or both.
I know, I know. Poor kids! They aren't happy! But they still get to go to Harvard and Yale and make a good living when they're older. Ah, but that's the issue, really. They are not really being prepared to succeed later in life. While there is perhaps some corporate value to employees who know how to "do school," there is also value in students who love to learn. Indeed, beating the love of learning out of students - teaching stress, frustration, and cheating instead - produces future employees who don't know how to work together, who are wary of each other's success instead of doing good work themselves, and who are afraid to be creative and take risks for fear of losing their secure spot. Companies across the country are complaining that there aren't enough good employees graduating from America's schools, despite the fact that school admissions are getting more and more competitive. So how do we define the problem?
I've looked at one particular issue here, but hopefully you can see how this is much broader. In any social structure there are almost always problems, but defining those problems can be very difficult. Indeed, there are often contradictory problems at play, or problems that are contingent upon a certain ideology (for example, the price of health care might seem a problem to one person but not to another, depending on ideology).
At the moment, I am meant to be identifying a "learning problem" to design a solution around for my Master's project. This, I'm finding, is a terribly complicated process. There are so many problems, many of which interrelated, that it makes narrowing difficult. I'm not worried about finding something - indeed I can see a great many small-scale things I could work on - but I am worried that whatever I do settle on will be either too broad or too narrow. I feel I need, more than anything, a broader sense. While I might articulate a small, sub-problem, I still need to define the big problem that most motivates me, and I find myself vacillating on that issue continuously. I might as well ask why I am in education at all. My answer is to multitudinous to define in a sentence.
The burden of complexity is that it is, well, complicated. "What is the problem?" is too simple a question.
Keahi says there are five steps to problem solving, and ties each to a level of thinking and development. The steps are as follows:
1) Recognize that there is a problem - "This is something even a cockroach can do," Keahi says. "You turn on the light, and the cockroach says, 'whoa, that's a problem,' and scurries into the corner."
2) Identify the problem and its source - This is, as I recall, high school-level thinking. More on that in a second.
3) Enumerate possible solutions - This, Keahi says, is more college-level thinking.
4) Select a solution - You can see where this is going; this is graduate school-level thinking.
5) Act - Here, of course, is where Keahi springs the leader bit on his students. Those previous levels do not mean that you need to go to grad school, because leaders are the most important thing.
I don't think Keahi means to insinuate that we should act without doing a good job identifying problems or selecting solutions, because it is something of a truism that action without reflection or strategy often results in making things worse. It is no accident, too, that educated people often struggle to act, because one of the marks of education is a recognition that simple solutions - solutions that are easy to act upon - often have unintended consequences. A simple example would be the standards movement in education: standards were designed as a way to make sure every student was reaching a certain baseline of knowledge. The real outcome, however, has been a high-stakes, test-based system that reinforces socio-economic boundaries rather than blurs them. That was never the intent, but it has been the outcome.
While I think Keahi's lesson is quite valuable for teenagers, I'm not convinced the problem-solving process is actually so linear (nor am I convinced that Keahi would claim it is). The second step, in particular, is trickier than it seems. Identifying the problem is a matter of much nuance and skill, and in fact failure to so properly is the cause of many failed solutions.
The "d.school" at Stanford believes in user-centered design, and emphasizes identifying the problem, not by simply contemplating, but by asking users. One might cynically suggest that this kind of design thinking leads to "discovering" problems that don't really exist (consider the Snuggy, or any other infomercial product) by mis-emphasizing needs,* but on the whole it's a fairly good system. There's a certain attractive subtlety in asking users what they want, and then comparing their words with their actions and emotions to determine their needs.
* What I mean is, it's easy to watch someone with a blanket and decide that they really don't want to get out from under it when answering the phone. Indeed, the person might even be able - with prompting - to articulate this need. More interesting, however, are the unarticulated needs that are perhaps subtler and larger-scale. I believe the d.school would be interested, not in reinventing the blanket, but in reinventing the phone. But I don't really know. Either way, you can see that defining the problem here is tricky; which is why it is treacherous to let marketing decide the problem for you.
User-centered design, however, does not always work in education. Indeed, formal education would not exist if the "users" (students) could articulate their needs. Educators believe, by necessity, that they not only have material that students need to learn, but that the students will not be able to identify what that material is on their own. That might sound draconian, but think of it this way: what second grader would choose, of his own free will, to learn to read, to write, to do arithmetic, and to share? Perhaps those things would come naturally by contact with a literary, mathematical, and socially complex culture. But perhaps not.
As we get further along - as students are given more choice in the form of "elective" classes - there remains an external push for students to continue taking math, English, foreign language, and - in some blessed schools - art and athletics courses. While much could be said about how those courses fail, it seems fair enough to say that educators as a whole have a better sense of how important those subjects are to future happiness and success. From the other perspective, there are many students who wish they'd paid more attention in Spanish class. There's a certain irony here: students only realize how much teachers have their best interests in mind after they're out of school. Regardless, there seems to be general agreement that teachers can identify the problems of education better than the "users" can.
The contrarian in me, however, wants to point out that this has lead to an under-emphasis on student opinion. A great deal of education research and policy concerns teacher practices, administrator opinions, community biases, impersonal standards, and parent involvement. Where, in all of that, are the kids? User-centered doesn't have to mean students know what they need to learn. It could, alternatively, mean that students have a good sense of why they aren't learning. Indeed, they might have more to say about themselves than tests ever could.
The challenge, here, is that students have a hard time articulating what they dislike about school. What's the problem? School sucks. That's not a good dialogue. Rare is the researcher who, like Dr. Denise Pope at Stanford, decides to follow students around and comes up with a mutually agreeable conclusion.
Pope's Doing School highlights one of the great many problems in education - and this is the bigger issue; there is never only one problem. Where much research focuses on what's wrong, Pope's research question was the opposite: what's going right at good schools, and with good students? She followed around five students over the course of the year, shadowing, doing interviews, and avoiding teachers, parents, and administrators. She wanted the student perspective, and she got it.
What did she get? Well, she went in trying to find out what was right, but she saw instead something deeply wrong. All of these "excellent students" she followed were unhealthy and unhappy. They cheated. They competed mercilessly with their classmates. They never actually remembered the material they were meant to be learning. They were, in short, "doing school."
In a competitive education system, it's easy to look at the people who fail. Competition necessitates failure,* and it is easy to see the racial and economic biases that predict that failure. Many education researchers and reformers, therefore, target the failing schools. What they ignore is the successful schools and successful students where, as Pope discovered, students are miserable, and not learning a thing.
* And don't you forget it. A great deal of hand-wrangling is done over "failing schools." Standardized tests are designed to produce a curve. Schools, in short, are supposed to fail. Either policy-makers who make a big deal of this are very clever, ignorant, or both.
I know, I know. Poor kids! They aren't happy! But they still get to go to Harvard and Yale and make a good living when they're older. Ah, but that's the issue, really. They are not really being prepared to succeed later in life. While there is perhaps some corporate value to employees who know how to "do school," there is also value in students who love to learn. Indeed, beating the love of learning out of students - teaching stress, frustration, and cheating instead - produces future employees who don't know how to work together, who are wary of each other's success instead of doing good work themselves, and who are afraid to be creative and take risks for fear of losing their secure spot. Companies across the country are complaining that there aren't enough good employees graduating from America's schools, despite the fact that school admissions are getting more and more competitive. So how do we define the problem?
I've looked at one particular issue here, but hopefully you can see how this is much broader. In any social structure there are almost always problems, but defining those problems can be very difficult. Indeed, there are often contradictory problems at play, or problems that are contingent upon a certain ideology (for example, the price of health care might seem a problem to one person but not to another, depending on ideology).
At the moment, I am meant to be identifying a "learning problem" to design a solution around for my Master's project. This, I'm finding, is a terribly complicated process. There are so many problems, many of which interrelated, that it makes narrowing difficult. I'm not worried about finding something - indeed I can see a great many small-scale things I could work on - but I am worried that whatever I do settle on will be either too broad or too narrow. I feel I need, more than anything, a broader sense. While I might articulate a small, sub-problem, I still need to define the big problem that most motivates me, and I find myself vacillating on that issue continuously. I might as well ask why I am in education at all. My answer is to multitudinous to define in a sentence.
The burden of complexity is that it is, well, complicated. "What is the problem?" is too simple a question.
Labels:
denise pope,
design thinking,
Education,
keahi,
Learning,
Master's project,
problem-solving,
school,
Stanford
Subscribe to:
Posts (Atom)