Master Class: Planning A Design Thinking Training
Master Class: Planning A Design Thinking Training
11. Master Class: Planning A Design Thinking Training
Class Introduction14:42 2
High-Five And Five Whys03:34 3
Goal Setting06:55 4
Framework: Connection, Explanation, Action and Reflection10:13 5
Lesson Planning And Time Management14:28 6
Learning To Listen03:28 7
Three Mini Design Challenges06:23 8
Design Thinking In Action10:03
Master Class: Planning A Design Thinking Training1:00:11 12
Debrief And Q&A - Taking It Home12:29
Master Class: Planning A Design Thinking Training
You have the materials that I've done. I've explained to you a little bit about why I've done them, and so now we're gonna remix everything and apply it to a real-world context. So in a little bit, I'm gonna invite up my two students, Cindy and Neil. They work at a tech company here in Seattle, and I'm going to do a master class with them. So this is sort of a microcosm of what I would do with any real-life client that comes to us and says, hey, we wanna design a workshop for our team around design thinking. And so it's a little bit meta, actually. We're gonna use design thinking to design a design thinking workshop. You'll get a little bit of a view into how we do that, and it's also a review of these bag of tricks that I've shown already. Without further delay, I'll bring up Cindy and Neil. Alright, hello. Awesome. Hey! Thanks for joining me. Thank you. So we've done the connection, and now we wanna start with the discovery, right? So, just as with any other design thinking proce...
ss, I wanna learn more about you guys and what your needs are, what's happening with your team, what's happening with your company. Let's just start there, then. Why don't you tell me a little bit more about yourselves and what you do, and from there, we'll start talking about your team and how we can design some awesome experience with them. Yeah. Okay. Hi, everyone, I'm Cindy. I work at a tech company. Neil is my coworker. We both work in kind of an enterprise product, and we work with developers, PMs, designers. Our group, we kinda work, we all each have our own dedicated part of the product, but we kinda have to check in with each other, so it's a lot of cross-collaboration among design, PM, and dev, as well. That's kind of what we do. So yeah, we're both designers, and a lot of stuff that we're doing right now currently, we're kind of in this fast pace mode. Getting together and reviewing what's going on and what we're doing and how things are moving along can get missed because we are so concentrated on our specific features and things like that. Just the idea of, how can we get people together so that we're reviewing, we're taking a look at stuff and actually brainstorming more, is something that... Is a good skill. Would be beneficial for us moving forward. Yeah. So as a consultation point, it's interesting to think about where your team is right now. It sounds like you don't have a lot of time because you're in heads down mode. Doing some paraphrasing parrot here to repeat back what I think I've heard. But you still have this need of reflection or to maybe zoom out a little bit to think about what are we actually doing here, what is the big picture. Is that capturing Yeah, yeah. what you're saying? Trying to see holistically how things are being stitched together from each individual group perspective so that we do understand what the others are perhaps working on and how it fits into the uber feature that we're working on moving forward. Is that good? Mm-hmm. Sometimes it's helpful with what we call the creative cross-training is that if your team is already super focused on shipping specific features out in this product, it could be helpful to actually design some sort of facilitation where you're designing something for yourselves or designing something that's not directly related to the stuff you're doing. Because it sounds like you're already in implementation mode. Unlike that pharmaceutical company, it's not like you guys are designing the wrong thing or over budget, where you're not lost there. You're just busy there and you want some more perspective. Does that jive with what's going on? Yeah, yeah, I think so. It's more we have an idea from a product perspective of what it is. It's now, how do we stay in sync better with not only the design perspective, but perhaps our partners in, not only PM and dev, but our partners in other groups within the context of our organization. And can you tell more about your process as a team? 'Cause it sounds like if you're already implementing things you already have some sort of process, right? Yeah. We kinda operate, like Neil said, like agile among the designers. We meet daily every day for a 10-minute sync to just check in and share work. Maybe once a week the designers will... If there's anything they want to raise a hand and share their work out, they can. Where we work on the floor, among the design organization, we might have once a month a share-out where we'll have a quick, hey, I'm Cindy and I'm working on this product so that people can be like, oh! We're trying to solve a problem in a similar space. I should reach out to you and connect. But I feel like oftentimes, because we're so heads down, there's a lot of missed opportunities to communicate. And is it just among the design team, or do you hope to bring in people from these other related disciplines that you're collaborating with? Yeah, that would be ideal. I think we have a good... Process going from the design perspective. It's now, how do we bring those ideas and thinking that we're doing to the broader audience of partners. 'Cause they're busy doing their PM stuff, their dev stuff. We try to build that baseline so that everyone's thinking from a more holistic user-centered point of view, is, I think, kinda hard because as an occupation we have that understanding. But it's hard, I think, if you're not a natural public speaker or whatnot or having those tools in your kit, to get everyone on the same baseline. It's a little bit harder. I find that even if you're creating something for your customers or your users that's user-centered or human-centered, sometimes we forget to turn that on ourselves and our own organizations, and how do we make our teams and our processes more human-centered or user-centered, right? You guys are the users of your own organization in a way. Yeah, and sometimes when we do have these conversations with our partners, PM and dev, being a designer, you are... I don't know if it is intrinsic into who we are as people, but you do have an empathy, you do have a feeling, but really, it's, how do you communicate? That is a need from a dev and PM perspective in looking at the user in that sense, too. Right, so maybe it is introducing this holistic method or shared vocabulary, at least, about the process. But it sounds like there's also a mindset thing, where you feel like, as designers, you got some stuff that's more instinctive or things that you've learned by doing design, whereas other people, because they come from different disciplines, may not instinctively think that way or feel that way. Absolutely. They might have it as a person, but it's in practice creating from a tech perspective, in practice how it manifests into a process moving forward. Got it. We'll keep learning more, we'll keep doing more discovery with Cindy and Neil, but I'm just gonna start taking some notes to help us figure out what's going on. Let's start with a who. So you guys represent design. You've also mentioned the PMs and then-- Dev. Dev. Marketing, product marketing. Researchers. And then even our leadership, from a leadership perspective. So there's a couple different ways to approach this. You can have the master list of, hey, do you just bring in a lot of people into one thing, or if this is a new thing and you're kind of putting yourselves out there, right? Maybe it also makes sense to start with a smaller group of maybe representatives from here, and then you can broaden it out to more people. And it really depends on the culture and the logistics of your organization. I don't know how many people all of this implies in your group. I don't know, can you tell me more about that in terms of just head count for this initial facilitation that we're gonna plan? Yeah, I think from my perspective, I think from a daily, weekly cadence perspective, it would be the first design PM and dev people groups. And then the marketing research is more of a high-level communication that might not be in your daily or weekly cadence. It might be a monthly thing or a biweekly thing where you're just communicating things. But from a daily perspective it can be those three. Maybe you could also sequence it, too, where this is maybe a, not a friendlier audience, but an audience that's more familiar, right? And then you could also maybe do a subsequent event that brings in some of these people, especially once you've gotten a little bit more practice facilitating it and you feel more comfortable doing that. Would that make sense? Yeah. Sort of as a concentric circle thing. You'll start with your ingroup first and then you can roll it out to a wider group. Mm-hmm. Okay. Let's focus on this small group exercise first as an experience to design a workshop to design. How many people are we thinking here in terms of head count for the first pilot? What do you think, two, two, two? Two, two 10, roughly. Yeah, 10? 10? Alright. So this will be about 10 people. Including the facilitator and-- Plus two facilitators, right? That's perfect, because there's two of you guys, and so that's a good student/teacher ratio or facilitator/participant ratio that we've noticed in our work, too, of having about one facilitator to every four or six participants, especially early on, just gives some hands-on attention that everyone can feel like there's enough of you there that you can transmit that mindset and that culture as well. When you're planning a workshop, are you usually working with the design side of that org to plan the workshop, and does that change how you would go about planning it, as opposed to if you're approached from the business side? It really depends. Some cases were brought in by HR as a professional development thing, we're just introducing skills to members of an organization. Sometimes it comes from the executive side. Sometimes it does come from the design side. It really varies. We like to map out the stakeholders first. In this case, it looks like there's potential to do multiple workshops over time. So to help them bring this back and just get started in an actionable way, I think we're focusing on this small group. But if we were brought in as experienced facilitators, we might go about it as, okay, let's just get a cross-section of the organization first if the goal is about this mindset shift and just getting everybody on the table. For example, at West Point, there was a small group of cadets and officers that worked with us over the whole week, but just to get buy-in, because this was a relatively new concept at the military academy, we invited pretty much anyone who worked there or was at school there for this half-day summer course. They could experience a small subsection of it and then a smaller group stayed for more in-depth stuff. So you can think about it that way, as well as in terms of who needs buy-in and how much culture work you're doing. In some organizations, new things might be seen... They might be more hostile to these new things, and so you have to fly under the radar first, prove that it works, and then spread it out, and other times, you wanna say, hey, this thing is happening. Everyone should experience it. And then some people can experience it more deeply. But that's the importance of this discovery phase and understanding the specific culture of a team or of an organization. If there is a design arm to the organization that you're working with, do you typically have them facilitate the workshop, or participate in the workshop? Yeah. That's a really helpful question. One thing that happens in the wider design or design thinking world is that there have been some conflicts and controversies where designers sometimes look down on design thinking. They see it as a diluted version of design that's actually something that strategists do, or they feel like their discipline is being invaded by outsiders. That's a very real debate and discussion. One way around that is to assure the designers that a lot of this design thinking stuff is stuff that they already do, sometimes instinctively just from their training in their experience. We're just creating a shared vocabulary of... Understanding what this process is. Like I said before, you don't have to use the labels that I use, but that designers are allies and we're not trying to tell them how to do their work. In another workshop that I did, we invited Claudia Kotchka as a guest speaker, and Claudia used to run innovation at P&G, and she said that she didn't even call it design thinking, she was just brought in to do innovation. Since P&G already had design teams, she worked with the design teams as these internal allies and co-facilitators to expand it to other teams. So I think figuring out these political dynamics, especially working with designers, since they already grok this stuff, even if they don't necessarily use the terms and use those methods, is a really helpful in to a lot of larger legacy organizations. That's a good point. We've got about 10 people. What kind of time commitment do you think we could get out of people as an introductory workshop? And we could always ramp it up later. (laughing) One hour. (Neil laughs) One hour? You think? A time commitment? Yeah, probably a couple hours. Couple hours, okay. One to two hours, like Cindy was saying. Alright. For an introductory experience, right? Yeah. So we can think about designing an experience in a similar way to telling a story. And usually in breaking down storytelling, there's some sort of triggering event or some sort of invitation. So if you think about any epic story, whether it's Lord of the Rings and Frodo gets the visit from Gandalf, or you're Luke Skywalker and you find these droids, whatever that is, and so could be a specific invitation or it could be tied to something, like you have annual staff training or you have some quarterly thing. What would be a triggering event to make this happen? Whether it's an invite that you guys send or you could always tie it to some specific timeline or event or something that's happening in your team. I'm trying to think of... An all-hands? Yeah, an all-hands or something like the big company thing that just happened, right? Oh. Something where it's depressing-- Yeah, like an annual conference. Right, things like that, where something might be needed and some brainstorming might need to happen for this particular event and stuff like that that happens on a monthly or quarterly basis. Got it. Yeah. So maybe it's some sort of annual or quarterly meeting, and then this could be a side event to that, right? Absolutely. Okay. And so we've talked about this progressive review. We're having a little bit of mystery. You wanna get people... Even if people are required to go because there are people that report to you or you've got the buy-in that they have to go to this, you wanna entice them some way, even if they're gonna go anyway. We can come back to this, but just one thing to think about is... What are ways to get people to want to come to this with some sort of mystery? One example is sending them a ransom note-type letter about being at a specific place at a certain time. Or it can just be something mysterious that's a clue to what will happen in the actual workshop that's different from just the typical memo or the calendar invite, where, like, okay, you're going to this thing. We can come back to ideation for this idea a little bit later, but thinking about the trigger, you also want to think about what is the surprise bit or what is the carrot? What is the enticement? So we'll come back to that. Why don't we just map out some of the major, what we call the booms. In storytelling or experience design, we talk about what we call beats and booms. There's these little story beats, like the triggers, but then the booms are these bigger things that are turning points or just big parts of the experience that we wanna map out, and then we can figure out some of the details as we map it all out. In terms of the mood setting, would you do this on campus at work, or could you get people outside? What sort of scene can you create in terms of the staging of something like this? I think we could be open to that. At least in our company we have facilities that are... Interesting, right? More interesting from a facility and indoor and how things feel perspective. But then you got your classic conference room and stuff like that. I think that if we-- We have options. We do have options to make something more different, so to speak. From an environment perspective. Okay. So we'll do some setting. Worst case scenario, it's a conference room. And it could always be a conference room that you redecorate in some way. What we've done before, too, in organizations where it's not practical to go offsite is we'll remove the furniture from a conference room so that anybody who doesn't have mobility issues will just stand most of the time, or we put cushions on the floor. We change it up in some way that's not the typical... Onsite conference room kind of thing. Moving on from this setting, let's think about the goals. We've got the meat of the facilitation and what we can hope to accomplish in two hours, and we can work backwards from there to fill the time. If we have some sort of fish bone, what is the goal of this two-hour thing? We've talked about it as a bit of an introduction. What are some things that we could hope to get out of this? Get everyone on the same page, make sure we're all aligned. Alright. Also, coming at it from the design perspective, it's also an education point of view from how we as designers solve problems as opposed to how they might solve problems and how those differences are and how they can be the same in some way. 'Cause they are different disciplines and how people solve problems are different. Sometimes what we do gets lost just because they don't understand how we solve problems or look at problems from a design perspective. Got it. Here it's the same page, educate. It's almost like a cultural or interdisciplinary exchange. Absolutely, yeah. So I think one thing that I'm thinking about now is since 10 people is relatively intimate and you have design and then non-design, so we can always think about some activities where we deliberately pair somebody who's a designer with somebody from another discipline, even if everyone's working together all the time. But when you do pair or smaller group exercises, you deliberately match people that way. Mm-hmm. Right, yeah. Good, yep. Okay. You've got these goals. It sounds like... The goal here is getting people on the same page, educate, cultural exchange, and that sounds totally doable for a two-hour intro workshop to something like that. It's kind of like team building. Yeah, it's team building. And it's not to say that... How I as a designer is the right way to think. It's also saying that we understand how you're thinking, and it is kinda like how we're thinking, to basically... Say that it's okay to think that you're doing the same thing that we're doing. You just don't know that that's happening. Things like that. That makes sense. One thing with the pairing off, too, is maybe you design small things for each other. You prototype small things for each other, and it could be these everyday things, too. Like redesign your experience of getting lunch while you're at work or the experience of your commute. Things that are common to everybody that are not limited to a single discipline or industry to also build that, you said the team building, right? It's that empathy, because you guys are designing for users or customers out in the world. But then how do you design something for each other, in a way, that's more immediate and has a more immediate feedback loop than the kind of consumer tech that you're working on? Okay, so we talked about making that connection, and so what's a good, if we think about the first activity we can put in the fish bone, we have several different kind of stokes or icebreakers that we've talked about before. When I talk to clients about this usually it's helpful to get some sense of how game people are for doing weird and wacky things. You can always step it up, right? I don't have the people making weird hats activity or things like that as the first thing for most organizations unless they're already kind of wacky. So what's something that... May not be an everyday thing, but isn't too out there that we could use as some sort of icebreaker or stoke? It also depends on how much people know each other. Is this a team where people are talking about their outside lives with each other, or is it more of a business-only kind of relationship. Yeah, yeah, it's very business-only. I think that for people that really gel, there is some level of knowing them on a personal level that you need to have. Perhaps maybe something where somebody's sharing a more personal thing. It could be-- A story? Of an artifact? Yeah, yeah. Yeah, the artifact story's a really good one for just strangers or colleagues that are not... They just don't know a lot about each other personally. Because, especially when you say, it's something in your wallet, or it could even be a picture on your smartphone, and it's sort of just a mutual show-and-tell, especially if people aren't in an office that's open plan or adjacent, where you see pictures of people's family or people's dogs on their desks. If you don't see that, this is an opportunity for some sort of show-and-tell thing. There's no dress-up or making something. Also, a lot of mix of personalities. I think most people are introverts. (chuckles) Yeah, yeah. Introverts. And so just pulling them out might be helpful, especially if we're gonna have to collaborate on activities moving forward. That would be good. Another priming thing, too, is thinking about we wanna get people on the same page, think about this cultural exchange thing. But two hours is also enough time to actually get them to make something. I gave the example of those six-minute mini challenges where you'd also prototype something that's you guys designing concepts for each other, and so it's also helpful with the stokes or the openers to have some sort of making activity before you get to playing with the pipe cleaners. Another thing that I could suggest is doing blind portraits. Oh... Blind portraits. And basically this is a way of getting people to draw, but taking away the risk of drawing badly. The way the blind portraits things works is that you give everybody a sheet of paper and a pen or a marker or something, and then you pair people up and you look at each other and you draw, but you can't look at the paper. You can look at each other, you're supposed to make eye contact the whole time, and that also builds intimacy, because we're not used to holding that while we're drawing. It works in 30 seconds to a minute, so it's not so long that it starts to get awkward and weird, but it is enough of a norm-pushing thing that you've started to create a little bit of this magic circle. Because you probably don't do this in your stand-up meetings. Yeah. No. Alright. And that also builds on this sort of artifact thing, of, like, you've broken the ice, you've stared into each other's eyes for 30 seconds to a minute, and then you can get to the artifact stories, which I think makes sense because you mentioned that it's kind of an introverted team. Even though you can share whatever mundane artifact you want or get pretty personal, this, I think, opens up that a little bit. This is just probably 15 minutes and you're good. Now we can think about more activities or how might we question, or another activity that people can start doing together, or maybe start pairing people off or getting people in small groups to do some sort of challenge. If team building is your goal, maybe it's helpful to have some design challenge that's an internal thing so it's not about designing something for your customers, but it's designing something for your team. Maybe we can think together a little bit about what that question could be or what that challenge could be. Or it could be a non-work related thing to start out, too, and figure out how much leveling up we need for people. Yeah. I'm trying to think of when we get together as a team, not from the design team's perspective, but from our core team, from the design, PM, and dev. Is there a familiar setting or something that is... That helps start the meeting in a more familiar way as opposed to... In our space it can be somewhat chaotic. Not only from the project perspective. Even from the setting and the environment and stuff like that. The projector not working and stuff like that. Things like that, is there a way to create this, I don't know, ritual or something where it's, okay, we're starting this team thing together. I like that. You know what I mean? Yeah, if I were to continue on that thread, it's almost like, could you get people to redesign a meeting? Exactly. Or redesigning the weekly stand-up or the daily stand-up. Right, so that it's more efficient or everybody has their say, rather than one or the other having their say because they scheduled the meeting, right? Yeah. And so in this initial group of 10 people, it's people with enough authority or power to actually change the meetings if they decided to redesign the meeting. Yeah, yeah. To best fit the project holistically. Rather than what I want to get out of it. Yeah, that makes a lot of sense. We'll put another bone in the fish here. So it's redesign, oops. Meetings. This could take the form of some design challenge where you go through the design thinking methodology. Maybe we'll also have to insert some sort of explanation here from you guys where you can show the wheel of discover, define, et cetera for me, or you can also think about more organizational or brand-specific labels and terms that works for you. But I try to keep the explanation in these in-person facilitations minimal. 'Cause you didn't invite people here for a two-hour lecture. You want them doing something. You just want to give them enough to do that. And you want to chunk it, too. You can give the broad overview of, okay, you want to discover and then define the problems and then ideate, etc. But you can also give the explanations one by one and then it makes sense at the end. There's always a little bit of suspense of not knowing what's gonna happen. It's kind of a balance. But if they know that it's gonna be a two-hour thing, there's a finite end time, and it's a short enough thing where you don't have to give them the whole breakdown. So in regards to the explanation, I know a lot of meetings, especially for design workshops, people always like to throw up a PowerPoint slide that's like an itinerary, like, oh, we're gonna do this exercise. You're saying no. You just want to give them a little bit peek ahead, but you're not gonna tell them what the whole day's or the whole time's outline. Yeah. Two hours is not that long, but it's also long enough. You want to engage people in a way that they're not looking at their watches and you also don't want to give these small timer, you don't want these time metrics that will cause anxiety. You should plan it for yourselves, and we do this too, where things are planned down to the five minute, and you can fudge it a little bit if you need more time or if you're going fast, you can just keep going. But I never share that with them. I'll tell them when coffee break is and when lunch is, but I'm not gonna tell them, the first five minutes we're gonna talk about this, and the next five minutes we're gonna do that, because it's too much information. And then if you need to go off script a little bit, they're like, well, we didn't talk about that for the full five minutes. Or, we're running late. It's just enough explanation to do the next thing. From there, I guess my question is... This is pretty personal. It's pretty close to home for your team in terms of redesigning the meetings, and so politically, do people know that, are the meetings problematic, or how do you couch it in a way that isn't threatening? I'm leading the witnesses a little bit, but the question where I'm thinking is, does it need some sort of scaffolding activity, where you practice design thinking on a totally safe topic first before you bring it to an internal topic? 'Cause I know you don't have a lot of time, but it is also about the trade-offs of, is problem solving an actual goal, or is it just getting people familiar with the methodology of goal for this, and then you can work on the internal challenge first. And that's also a cultural consideration to think about. Mm-hmm. Let me think. I think it's more the latter. It's just about building that sense of trust and sharing different perspectives. Then we eventually want to get to the point where we could have good conversations at our meetings that exchanges a bunch of ideas and stuff. But I think you kinda need to build up that relationship. Yeah, the relationship. Because there isn't really much of a relationship. To gel and all that. Yeah, it's the soft skills from a people perspective. Yeah. So maybe what you could do, rather than jumping straight into redesigning the meetings, is think about what's a parallel to a work meeting that's not a work meeting. Is it some social gathering or it's something where... It's like a meeting, but it's different enough that it seems safe to redesign. Yeah, I see what you're saying. I think something like... We have researchers who do these findings, like market findings. They talk to customers, stuff like that. That could be a good way to be like, rather than being like, well, you're criticizing our work and whatnot, it's a way to be like, oh, we're hearing from our actual customers... I see what you're saying. It's kind of a good way to bridge. Oh, let's talk about what we can learn from each other based on what we're working on. I'm not certain. Though people do tend to do happy hours, too. (laughs) That's true. Happy hours, going out after work and stuff like that. Or lunches. Lunches, things like that, where it's, let's get together and just have fun. Maybe you start there with the purely team building thing, and we can also riff on the party planning activity that we've talked about. So, if you think about it this way, you could do an explanation and demo of the no, buts and then the yes, and for planning the ultimate party. And then maybe you have a design challenge with them about, it doesn't have to be happy hour necessarily. You don't want to be so specific, where the solution is already defined, but it's about, can you design something that brings people from different disciplines together in a social way. Then you're sort of getting people in that pliant mindset of, it could be happy hour, or maybe it's something else. It's volleyball, it's a bike outing. That's really interesting, 'cause we talked about it particularly for our product team, but our team got kind of reorged so that there's a bunch of other different design groups on the same floor, and people feel disconnected because you see a bunch of strangers, you don't know who they are. It's kind of awkward from a social level, so I feel like this could also apply to that scenario as well. And I could see how that can segue into the meeting. How the meeting is conducted, because you do already have the social gel already outside of work. It could bring it into the work environment itself in the meeting. Yeah, and it's also thinking about it as, what's something universal but relatively non-threatening? Because with the meeting thing, you have to work up to that, where people don't feel like they're being blamed for being a boring facilitator. But the team building one is great. Another idea I had was around onboarding. Onboarding new people? Onboarding new people. How do you welcome a new team member, especially if you have a merger or reorg? Everyone has the experience of being brand new to a place for the first time, and so is there a way to redesign that process? It could be like, you're new at the company, or you're new on the team, or it could be like, hey, you just transferred here from another office from another city. You're new to Seattle. Everyone's been new at one point, and it allows, I think, people to open up about their experiences of having been new that then they can design something for each other about, say, wayfinding or getting to know people and things like that. Yeah. That's good. Cool. Looks like we have the major beats here for an experience. So why don't we just plan out a little bit of some of the logistics and the timing of what you need. We'll start with the blind portraits. We'll have some sort of welcome from you guys, right? And the blind portraits and then the artifact story. With this, you could do welcome plus blind portraits. Let's just call that five minutes, about. And then... I'll change colors here. You welcome people. You always want to leave a little bit of a buffer. Then the artifact stories. If you have 10 people or 12 people, even, you can insert yourselves into the groups. Maybe you preassign the partners here. There's a few ways to do this logistically that minimizes drama and commotion. You could just assign the seats or you just tell people when people pick up their name badges, if they don't all know each other, maybe there's just color codes so that people connect with each other. Or you just have a list. I mean, 10 people is a small enough group where you can just say, Bob, you're with Erin. That part is easy because it's not such a big group, but sometimes you want to plan that out before if it's a larger group. The artifact story takes about a minute to explain, and then it's good to give people maybe five minutes each. Person A interviews person B and then person B interviews person A. Let's just say 10 minutes there. We can play with the times there. Then you want to introduce some sort of... Explanation of what's gonna happen for the meat of this facilitation. Actually, what's helpful here, too, is you want to build these one-on-one connections, but you also want to build these one-to-many connections or these many-to-many connections. What I do with the artifact story: since 10 people is a small enough group, you'll have people pair off. They'll get to know each other's stories, but then you give people time for maybe a couple of the groups to share back. You can say, oh, I talked to Cindy and she told me the story of her scarf, and then I share it back with all 10 people, which is also just practice for the introverts to have to talk in front of those 10 people. Why don't we just bump up the time here. About 15 minutes. Yeah, I think that's good, especially in our team, where people are introverts. So the more time for them to think and get comfortable with the situation perhaps maybe might be better than less time. Alright, and then we'll have... This explanation will also be the intro to the challenge of team building or onboarding. I think they're related enough that maybe they can choose. You can also just with 10 people or 12 people, even if you're gonna enter the groups, with 12 people you could do four groups of three. And you could also just preassign that. You could have some sort of written creative brief. I like to have a little bit of theatricality to it. It can be in sealed envelopes so it's like an awards show where people open it and they get that sort of message, with, your mission is... Which you can also do here with the trigger with the invitation, too, especially to preview either an artifact story or blind portrait. You could send some clue in with the invitation. You could send it as an image in an e-mail. There's just an image of just some personal artifact, and be like, learn the story of this and come to this workshop on design thinking. It could also be a blind portrait. You do it of each other and then instead of your regular headshot at the bottom of the e-mail, Cindy is like her blind portrait version that's drawn by you. Something that's previewing but doesn't fully give it away, where it's like, this is a little bit out of the ordinary, but it draws people into the story world, into the magic circle. For the intro and the explanation, you said to keep it brief, succinct. Don't give away the whole outline of what you're doing for this meeting. Since we work in a group that's very efficiency-focused, do you want to tell them the explanation, give a little intro, but tell them the value of why they're there? Yeah, you can talk about... Maybe you wanna talk about the goals, of this is about cultural and interdisciplinary exchange. This is about team building. You're designing something that really affects everybody in the organization, but it's relatively non-political. We call it creative cross-training at Foossa, but it's basically about practicing your creative skills on different topics, different problems, to help us solve bigger problems or things for the wider world or for our customers. It's a form of creative cross-training, it's about team building and onboarding. They've practiced this with the artifact stories, so you'll probably have some sort of interview where you're going to be, people are in their groups and they're gonna be both the designers and the clients, which doesn't happen in real life, when you're designing for someone else, but it's easier to practice this process when you're just designing for each other because it's relatively safe. Maybe one person in each of these groups is the client, and maybe you can even have, since you're bringing in other designers and they're familiar with these techniques, maybe just make the designer the client. 'Cause the client can also, you're the client/the coach. You're gonna be nudging a little bit and lead questions, because it forces the people who have less experience doing design research or doing design thinking to act like designers, and then the designer can just, you've reversed the roles a little bit. Right. No, that's good. Yeah. And then from there you can come up with the how-might-we questions that we talked about before. These are your initial starting points of how do we improve team building, how do you improve onboarding, and the how-might-we question is a more focused refined question that responds to that. Say Alex is a designer on your team. His teammates interview him for about 15 minutes. You've demonstrated the interview techniques with the mascots from Learning to Listen. They take notes about his needs. They create a user profile of Alex, and then it's like, how might we help Alex feel welcome when joining a new team in a new city? Or something like that, where it's taken this and made it actionable, and then it's also for a person. It's not just like, how do we improve team building in the whole organization, it's, how do we improve onboarding for Alex in this very specific context. Then we also know what are the challenges that Alex faces in terms of being shy or not knowing if it's a right time to approach somebody he doesn't know or figuring out these more specific questions. Who to go to for problems. Troubleshooting. Yeah, it's almost like... There's all this knowledge that each individual person might have, whether in the context of a project, but it's not really centralized in one place that somebody new can get it. So it's, how do you get those people up to speed from those different disciplines on a project so that they can go now as opposed to later? Or learning because they did it the wrong way. It's in somebody's head, but it might not be somewhere else where somebody could read it and learn from it. Exactly, and so that could be a related how-might-we question here, or you might add some subcategory or some story there to help people understand that. You may also give a scenario with the team building thing, where it's like, hey, how can we redesign the team building experience, and then you could also give a story that's totally fictionalized, but just at least, since you don't have a lot of time, it's a prompt for this kind of ideation in concept development. That takes us almost up to the first hour. We've learned something briefly about our user, our clients, who's the designer. Spent some time with the how-might-we questions and really defining the brief and synthesizing the user needs and profile. That's something where you guys can come in as the facilitators to really help the groups. It's a small enough group where you can get hands-on with that. It sounds like for the second hour you wanna have time for ideation and then time for prototyping and then just time for share back and reflection. Maybe it's like 15 minutes, I'm running out of space here, of ideation. And then prototyping... Could be 20, or you could stretch it a little bit more, and then you have the report back. With the ideation, you could also use the demo that I've done before, with planning a party, 'cause that's very much related to some of this team building stuff, and then you demonstrate through your own behavior. The two of you could just do this. Do a role play, and it just helps open them up, too, if it's a more introverted team. Just ham it up, where they're like the bad, very critical role play of no, but, and then we do the really open-ended yes, and. And it's important to plan it out so that you have some kind of crazy ideas, like the person in a bear suit popping out of a cake, just to open up what's possible for people so they don't feel like they're constrained by the obvious. And then you have the prototyping, which will have the craft supplies. It's a small enough group where maybe, you could either make it a surprise and do the burrito thing, like I talked about where there's like... Open up your packages and you'll find your materials in there. Which I think works in terms of building up the surprise. Another technique for doing that is to just have things out there all along, and then people will naturally start playing with stuff. Either one works, but it sounds like this is a group that may need a little bit of warming up, so I may do the element of surprise there, or just have them open up the packets and be like, surprise! You're playing with pipe cleaners today. Then you'll demonstrate the prototypes where I think it's a short enough process and it's a small enough group that between the designers on your team and you guys, you'll just lead by example for that prototype. Then because the clients are embedded in the teams, just to compress a little bit, maybe they just give feedback and then report back at the end. Also, I think it's helpful when you're dealing with these interdisciplinary teams to really share a structure for giving feedback. 'Cause you wanna take things out of the personal opinion space of, I don't like that font, I don't that color, to some sort of design critique that's helpful as it relates back to the user and the user needs. Maybe that's actually the final point that you give, of, okay, now people are gonna report back and you can model a little bit of what a design crit looks like as shared vocabulary, which I think hits your goals here. And then you've got two hours and then you can debrief with people afterwards and say, hey, can we do this again with a different group. And it's sort of a safe entry point to introducing this stuff to people. Great. Cool. Thank you. Any other ideas for build for this? Obviously you can turn this into a neater timeline. Yeah, I could also even see this just applying to our studio in general. The new people that come into the design studio, is what I'm saying. It's using this model to get them onboarded from the design perspective, not only from the product perspective. It translates over, which is great. Yeah, because all of this is team building in itself, so you're having a design team building while building the team, which is pretty meta. (laughs) Yeah. Awesome. Great. Thank you. Cool. Well, thank you so much, guys. I hope you guys can make use of this or remix it in a way that will work. Thank you. Alright. Thank you. Thanks, Cindy. Thanks, Neil. Alright. Why don't we take some questions from the room or from the internet and see if anyone has any questions about what they just saw here or ways that they can even apply this itinerary to a workshop that they're planning for themselves or for their teams. My question was on how much time facilitators might be spending on thinking about user profiles maybe beforehand, just in terms of thinking about maybe some of the challenges coming with a particular group you're working with. How much planning time. Not to get too... Obviously there's a good bit of planning you guys just did, but how much time/space. I don't know if that's clear. Yeah, in this case they wanted to do a broad overview and to just learn the vocabulary. They also had people who could be allies in the design team. And so they're really designing for each other. It's not enough time to go really deep into interviewing techniques and user profile techniques. They have people who can do this helping them. But I think in other cases, if you're focused on other things, like the ideation or the prototyping stuff will precede some of the research, we'll just conduct a user interview and then give them the user profile as the synthesis of our research. So then they have that to work from, but it's helpful to have them generate some sort of user profile themselves, too, as one of the skillsets. It kinda varies in terms of what your goal is, but since their goal is very much an overview-type goal, I think 15 minutes is enough to do a preliminary taste into what a user interview could look like. HD? Can you provide some tactics that you use to... Like you were mentioning during the design critique to create an open-minded space and try to get people's egos out of that design critique phase? Sometimes I just keep it pretty strict. I'll introduce those four categories of how to give critique, with the things that work, things that don't work, the questions, and the concerns. If you're worried that people are gonna go all over the place, I'll chunk it. I'll say, okay, you have five minutes and you can only say positive things. And then you have five minutes and you can only say negative things. And then five minutes you can only ask questions. You also have to tell the people who are presenting the design to not sell or advocate. If somebody's giving feedback, you have to say, this is silent sponge time. You'll note down the feedback, but you're not responding to it. You're just kind of taking it in. And then if there's time you can give them a chance to respond to the feedback. But the point of keeping the feedback structured is you might just have to chunk it and sound like, here's the positives, here's the negatives, here are the questions, just to keep people on track and just be really strict with the timekeeping. Just to train people. And also if there's not enough time, which it's deliberately designed to not have enough time, is you can also have people write feedback on post-it notes or note cards and then they can pass it to the team as well. And that also helps with introverts, too, if people are afraid of sounding too critical. Sometimes having pre-written feedback or just give people introvert time to say, okay, here are the four categories: positives, negatives, questions, ideas, and then just give them different colored note cards for each of those and have them write it down and then they give their feedback. So there's less stream of consciousness happening and it's a little bit more controlled and keeps things more on topic. Jamie asked... Jamie's an educator, and she asked about whether or not you do design thinking for middle school, high school students, educators. Have you done trainings like that, and what's that like? How would this adapt to that environment? A lot of it really adapts the same way. I actually started my career teaching junior high school in Japan, and I think a lot of this stuff would work with junior high kids. It's just tweaking some of these personal interviews, 'cause obviously with younger students they have less life experience, so you can't really ask them about, I don't know, last time you took an airplane by yourself or something like that. But just thinking about these questions and their challenges in a way that makes sense with their life experience. I think the hardest part for younger students is those how-might-wes and framing these questions. But in some ways they're better at the prototyping and the ideation because they have less social baggage about sounding silly in front of other people. I think it's up to the teacher, but most of this stuff transfers pretty easily, and if they look at the bonus content, the Stanford d.school has materials aimed specifically to educators, as well, that they can download and worksheets that they can use in their classes. Cool. Jess asked, "As a freelance designer, "is it legit to act as a facilitator "if you're presenting your own work to clients?" I think so. That's very much how we approach our work, is that we're being hired to design for, but also with, our clients. And so we're experts in design and in facilitation, but our clients are experts in whatever industry or discipline they're in, and the more collaborative we can be, the better. But we really have to be that bridge and that facilitator. Part of it is just the mental model, too, of set up that expectation and that mental model in the head of your clients, that you're not just there as a service provider to do what they say or to do what they want, but to facilitate something that you're designing together.
Ratings and Reviews
The course fits my need in supplementing my DT facilitation activities. It was well designed, paced properly and full of useful tips. Thank you!
This follow-up to Lee-Sean's Design Thinking for Business Innovation helped me to strategize and envision how I would bring these principles into my agency context. I look forward to using his guidance during this workshop in a way that is appropriate to a community healthcare setting.
There is a lot of common facilitator knowledge and skills shared in this course. The course was useful for me and helped me connecting the dots.