 How's everybody doing? Good. Have you been having a good day so far? Yes, a bit tired after lunch. Maybe excited, feeling a bit lazy. But we've had so many great talks now. Excited? Awesome. I'm here to talk to you folks about, thank you, being a designer. But before we get there, I want you all to try out an activity with me. Is that OK? You all with me? So I want you all to find a piece of paper. Hopefully, you have pieces of paper on your table. All right, I'm going to have to scroll through this. So what I want you to do is take about 15 seconds and draw me a vase on a piece of paper. I'm going to time you, but we'll do a vase. My timer going off for 15 seconds. How does your vase look? Something similar to what I have up here? Maybe somewhat similar, some shape, something? Yes? All right, hold on to this thought. I have another bit of this activity. Now take 30 seconds to draw me a way to bring nature into your home. Again, we'll time this, and you will hear my timer go off. 30 seconds up, yeah? How do you guys feel? Something similar to this, maybe a little bit of a varied kind of ideas flowing around. I'm sure you folks have some interesting stuff up on your paper. I want to quick show off hands. How many of you thought there was some sort of a difference in what you drew or imagined the first time around and the second time? Okay? Why do you think there was a difference? Any thoughts, any ideas? Perspective is different. You had more context to it. Okay? Okay? Yep, yep. So you're all getting there. The first activity, you were thinking more about the solution. You were thinking about what kind of ways you want to draw. What shape, maybe? What material, if I give you more time, then you'll probably figure out what kind of a design, what color. So you're thinking more about the ways. The second time around, I tried to make you explore a particular need or a problem space. So then what you did was you really took a step back from thinking about the solution and you're trying to figure out, okay, for this given need or this given problem space, what is it that I can do? That's where a lot of divergent ideas come at. That's where a lot of innovation happens because you're not tied to one kind of solving a problem. You're actually exploring different things, right? That is what really design thinking is. And I think the slides are jumpy, but you folks, all right, okay. So design thinking really is not just about designing the interface. It has nothing to do with just design. It's actually a way to solve problems. It's a problem solving approach. It's a shift of a mindset in terms of how you approach making stuff. It's about bringing empathy to what you build, right? Understanding what your users need. Understanding the people who will end up using your stuff and bringing their needs, their problems, their personality, their characteristics to what you're making. That's what really design thinking is. So at a very broad level, maybe you could identify with some sort of phases or stages of design thinking. Well, you start out with trying to understand your users, right, and you want to understand what they want. And then you go off and you try to explore some different ideas in order to solve those problems. And then you go off and try and prototype it in some form or the other. And then you go off and evaluate some of your prototypes. You talk to people, you figure out, hey, I made this, is this really being useful to you, right? And then you come back and understand. So this is the cycle that goes on. So if I were to add some typical methods being used in some of these contexts, and of course I haven't listed out everything. This is some stuff that we've used. With understanding, you do a lot of user research, different kinds of user research, maybe field research, maybe surveys, whatever it is, however you get to know more of what people want. And then you synthesize that information. Maybe you create personas, maybe empathy maps, stakeholder maps, whatever. And then you go off and explore. You try to figure out what is the current experience? What is it that you need to improve? Maybe you create some scenarios, some stories. Do some collaborative design exploration, whatever it is, and then you prototype. Whichever way you prototype, be it pen and paper, be it wire frames, or be it rough sketches, or maybe a series of stories that you wanna show in a scenario map, or different kinds of fidelities of mock-ups, like low fidelity, high fidelity, whatever. It doesn't really matter. You have some way of conveying your thought to the person that you may end up talking to. And then you take that prototype and then you evaluate that prototype on how well it's serving the need, right? You could do different kinds of evaluation. There's sometimes early concept evaluation that you do. There's maybe heuristic validation. There is usability testing and so on and so forth. You folks are probably pretty familiar with all of this. I don't wanna preach to the choir about all the different methods. But basically I wanted to really touch base on what design thinking really means and what is the flow in the process of design thinking, right? A quick snapshot of some of the things that, some pictures of some process that we follow in my team, at my company. The first one is really an affinity diagram that we were creating based off of some user research we did and then we did some story mapping. Here are some pictures of early wire frames from a collaborative design session. And then the final one, you can't probably really see it but we're talking through a story in a scenario map. All right, so enough about design thinking. You folks probably already know, all right, this sounds good but how do you put it in practice, right? It's well and good talking about all of the stuff. But for design thinking to really flourish, you need to have some sort of a conducive environment. It doesn't really happen like that. You need to build some sort of an environment that will actually help this flourish. What I think is building a product is more like making music with an orchestra. Why do I think so? Imagine an orchestra with different kinds of people playing different kinds of instruments, right? Everybody's, maybe there are some people playing on the piano, maybe, I don't know, different kinds of instruments but they're all playing to a certain kind of a tune, in the end what comes out of that orchestra is the music that you enjoy, right? Imagine if one person of that orchestra would go off tune or would go off step. What would that do to the product? The product being the music that they're making together, right? It won't work. So that's pretty much what making a product is like. I call it a product. You could call it whatever, a service and offering, whatever it is that you're making, right? Basically it's about coming together to make something. Going back to Dan's keynote yesterday, remember how he was talking about tribes and working in silos? I think building a product is more about breaking down those silos and coming together as a product tribe instead of being a UX tribe or a design tribe or a development tribe come together to be a product tribe. So what are some factors that really work to make this a conducive environment? The first one I have is collaborate. Work with people. Work with people who are not designers. Work with people who are a part of the tribe that we call the product tribe, who are involved with you in making something that is useful to people, right? It's not really about what you design. It's about what you put out there for people to use. Now very often when you work in such a team, you have different kinds of stakeholders. They all come from different perspectives. They speak different languages. So there's the developer or the engineer who understands a lot of technical jargon. There's the designer who understands a lot of, you know, all the stuff, all the words that we've been throwing around. Empathy and design thinking and scenarios and blah and blah. These may not really make a lot of sense to the developer out there. Then there's the product manager who looks at everything from a product or a market perspective, right? But you need to make sure that you're working with all of these people to come to some sort of a shared understanding of what it is that you're building together. Because one person from this group or one set of people for, excuse me, from this group is not going to be able to make that product and put it out in the market. You need everybody to come together, pretty much like the orchestra, right? If it were just one kind of an instrument, we probably wouldn't really call it an orchestra. It wouldn't have that kind of an impact on the music that they create. Now for those of you who are not designers in the room, remember that designers bring a lot of empathy to the table. It's really important. Why is empathy important? We learned from all of our different speakers over the course of the last day and a half why empathy is important, why it is important to learn about people. But for all the designers in the room, I want to point out that engineers are equally important. They bring real expertise or real experience in terms of making something to the table. And so our product managers, they bring a market perspective. It doesn't really make sense for you to go off and design something without figuring out the viability or feasibility because if you were to go off and design something and nobody were to use it, or if you couldn't launch it out in the market, is that really a good use of your time? Probably not. So you do want to keep that factor in mind. You do want to think about the feasibility of actually building something out there. So that's why I say collaboration is a key factor in making design thinking work. The next factor is focus. So now we have a team of different kinds of people coming together, which by the way is what I call a balanced team. And it's not just me. If you folks are interested, Google it. There's a group of people who identify themselves by the word of balanced team and they believe in working together with different kinds of people. It's not just the designers, but everybody coming together. Anyway. So now that you have that kind of a team, all right, you're working on a product more often than not in the real world, there are too many things that are thrown at you. There may be a number of clients or customers asking, hey, I want this thing built. Hey, I want that other thing built. There may be executives saying, hey, I want you folks to build something that'll be really cool, really successful. We need to meet our targets, market revenue, whatever. Tons of different things. There may be people from research or people from engineering who say, hey, I have this cool technology. Let's put it out. Let's make something out of it. At any given point in time, there are too many things, too many choices to pick from. What you really need to have is a focus on the team. This group of people working together should pick a direction that they want to work in because if you don't know where you're going, you cannot get there. And once you pick a direction, then you have to make sure that you're not getting sidetracked by all the different things that don't align with that direction that you've picked. So it's an active choice that you make. Of course, it's a difficult choice, but you have to go through that as a team to say, okay, this is what we as a group identify with. This is what we want to put our effort in towards, and let's go do this. It's only then that you can actually make effective work happen. Now the third factor that I have is alignment. Like I said, different kinds of people working together. I really firmly believe that, like I was saying, it's about a product tribe. It's not about UX or it's not about just engineering or product management. But really make sure that you bring alignment to this group. Make sure that each and everybody understands the language that is being spoken instead of using jargon. Make sure that everybody's a group understands what's being said, where are you currently and where do you need to be? What's the vision that you're going at? Where's the reality and how do you get there? And do this, it's very important, do this from a user's point of view, from a scenario point of view, from a story-based point of view. That's where you get empathy into this. And that's where it's different from going off and building something that's feature-based as opposed to story-based. Now about being a product designer. It's not just about being a designer. It's about being a facilitator. It's about being the conductor of that orchestra that we were talking about. There has to be somebody who really has to guide this whole group in a particular direction and say, okay, hey folks, here's what the story is like. Here's what people are saying. Here's what we learn from the users. Here's the scenario that we're working towards. Come back, pull these people back together whenever there's distractions and other stuff. So what does it mean to be a facilitator? I think as a designer, you have to be a story-driven designer, like I was saying. It's very important to bring empathy. I can give you an example. So not too far ago, my team and I were working on some sort of a demo of some cool technology that we were bringing out into the market and it was important to actually have some sort of a working demo so people would know what we were working on. Now there were engineers who were trying to put this piece of technology together, trying to make different kinds of APIs work. They figured out the technical aspect of it. They said, okay, we can connect this API to this other API and blah, and blah, and blah. And that's all. They said, that's it. Now what do we do with it? There were product managers. They said, hey, we need to make sure that this kind of client or customer would be able to see this and feel like they get value out of it. That's it, they stopped there. And then we had these series of discussions for weeks and weeks where people would just talk. Everybody sort of had an idea of where we were going but nobody was really feeling any confidence. Then what we did, there were a couple of designers on the team, what we did was we said, okay, let's get out onto the whiteboard or on a piece of paper, let's start drawing out the wireframes. We'll make a very rough sketch of the wireframes. We can iterate on it. It doesn't matter if we go wrong. That was when we started turning the direction. It, instantly I could see the, I could sense the change in the environment because now people had something to actually see, something concrete to talk about as opposed to just talking in the air, right? That's what I mean by story-driven work. So you as a designer can really take that into hand and guide the course of the direction. Then I say cohesive, be a cohesive designer. Identify the gaps in the experience. You as a designer can actually take a step back and look at the bigger picture. Most of the times when engineers are working on stuff, they're probably looking at the piece or the module that they are responsible for. But you as a designer can take a step back and connect the dots of the whole experience. Be that designer. Identify those gaps in the experience. Be the inclusive designer. Work with engineers, product managers. Bring them early on into the research that you're doing. It's not about you going off and synthesizing a ton of research and then displaying that to the product managers and the designers. It doesn't work one way because that'll be just as good as me standing here and presenting to you folks. I'm not even sure in a one-way communication how much of this is getting through. How do I expect you to respond back to that? So it's important to bring them early on and take them on this journey of synthesis with you because the more they get involved, the more they feel a part of it. They actively participate in this. Number four, be a grounded designer. Think through limitations and constraints. And this I say because I know as designers we wanna like think vision, think blue sky. But it doesn't really help to actually just keep thinking blue sky if we don't consider the feasibility and the viability of it. Quite often in my design team, we like come up with designs and then we talk to our dev folks and then we realize, hey, you know, the system that we have, we probably can't really achieve this design. So then what happens? At that point, if you don't keep that early on, think through the limitations and constraints, then your design gets scaled back. And a scaled back design will really leave a bad taste in the user's mouth unless and otherwise you have thought through the limitations and constraints. You don't want a half-cut apple. You want a smaller apple probably, right? So think through it early on. The last one I wanna talk to you about is just in time design. In recent times, as the development has changed, more agile methodology, people wanna move fast, iterate faster, put stuff out there into the market pretty fast. It's important to try lean research and design. Don't wait until you have all of your research gathered up upfront. Try to put your best guess out there and validate it. I'm not saying go with the best guess. I'm saying get something out there, focus on validating that. Just a quick thought of how we do it at IBM. And some of you folks have already seen some of the stuff at the workshop this morning. But at IBM, we try to implement design thinking using the concepts of hill-sponsor users and playback. What hills really are is a way of focusing on big problem and outcomes instead of a list of features. If I break a hill, which is actually a statement of what a team will do, given a time, is if I break it down into smaller parts, it's about the who, the what, and the wow. The who is the target user that we wanna build for. The what is basically what the user will do. And the wow is the value addition that we wanna provide to the user through this piece of functionality. Again, the language of hill is basically coming from, I think, the military somewhere. Think of a commander and his commandos, a team of commandos out in the field. When you have a critical situation, the commander doesn't really give you instructions on what to do next. You don't really get that kind of time. What they rely on is that they say, okay, we need to be at a certain place in a given time. That's what they align on. And then each of the commandos probably figures of their own way to get there. But as long as you're aligned on where you want to be, that's the job, that's half done. That's where it's coming from the commander's intent. That's what the hill is supposed to be. Like focus on the bigger problem and figure out where you wanna be in a given time. Then sponsor users. Sponsor users are basically target users who really match with the characteristics of the user groups that you've identified. It's a way to actually bring some user research more formally into a big company or a big team. Because sometimes if you don't have direct access to users, then you should probably look for at least one kind of user to talk to. So you can validate your ideas. The final one is playbacks. They're more like checkpoints. I say checkpoints are not checklists because it doesn't really matter about figuring out what features have been completed. What matters is to see the current state and the progress that you've made against the hill, but more from a story point of view. Driven by the experience. Don't talk about the fact that we built this feature or we built this module. Talk about the user. Lay out the story early on, the experience, and then talk through how much of that experience has been covered. That's what you wanna talk through. So the IBM Design Thinking Framework once again. That's pretty much what I have for you folks today. Thank you.