Design Thinking, Design Sprints & Design Process

We got a hard video today. We have a tough one today. Hey everyone, my name is Ritzy. Today I have a pretty special topic I'm pretty excited about. I've been thinking about it for a little while. It's design thinking and how it's actually implemented in companies and within UX. We'll be covering design thinking, how it works, what it is, some details around it, design sprints, what those are, how they are different from design thinking, and how the actual process works. So come along, we're gonna get into some advanced UX stuff. So let's first start off with what is design thinking. The Interaction Design Foundation defines design thinking as an iterative process in which you seek to understand your users, challenge assumptions, refine problems, and create innovative solutions which you can prototype and test. Now to me, I guess design thinking, the way I would describe it is kind of like a general methodology for things you should do, right? So the steps are empathize, define, ideate, prototype, and test. Sometimes depending on what you look at, there's another one at the end of those that says implement. And I think this is very important and I'll get into more detail why I think that's important later. But overall the steps are empathize, define, ideate, prototype, test, and then implement. You'll also see areas that say understand, explore, materialize, And these are, like I said, broad steps that are part of the product creation process. Let's jump into what a design sprint is. A design sprint is a process for answering critical business questions through design, prototyping, and testing ideas with customers. This came from Google initially. Jake Knapp has a book about it called Sprint. There are big agencies that actually focus primarily on this. I think AJ&Smart is the big one. And so what it is, is a 4 to 5 day process in which you solve a big problem. You get together, you review what you know, you create concepts, you prototype something, you test something, and then you review it. Now what people start missing is, is that how this actually works in the process. Jumping back into more of the design thinking area, I mentioned the implementation, that implement last step. So that means there's an empathize, define, ideate, prototype, test step, and then there's implement. So in actual product development, you have really two different areas. You have discovery and then you have the implementation. And discovery is understanding what are we building? Why should we build that? How is it gonna affect our business? So it's all the things that you kind of need to understand before investing in building something. So I'll use a real reference here because I actually have a real reference. I have an app called Wheat. And so initially I wanted to build a, you know, build an app that helps solve a problem for basically what should I eat? What should we eat? And so I had to do some understanding. How do people choose this today, right? And that's now getting into that empathize, define. So I went and did, you know, discovery research. I talked to users, talked to people, understood that process they currently do. From there, I defined that problem. I started breaking that down into features and what goes into the app. Started creating some concepts, started prototyping them, testing them, and eventually moved into that implementation phase. So in a sense, that area was discovery. So to me, the discovery part is really the understand and explore, which is empathize, define, ideate, prototype, test, which are very similar steps to a design sprint. Now, the thing that's different is how you scope those steps. Now, for me, I didn't have a scope. I didn't say it was gonna be, we have 2 weeks to do this, right? So we need to follow this process. It was actually, we have limited time, I wanna do this because it's the right things to do. I wanna know which direction we're going. But if we were on a more limited schedule or even a block schedule, we have, we wanna know, we wanna create this in 2 weeks, then we may wanna say, how do we, what process do we use to find this stuff out? Right? In which case we might run a design sprint. We might say, okay, let's do a design sprint, do this and evaluate. Right? And that's an area a lot of times people will try to look at the design sprint as a, as a part of the design process, but really it's part of the discovery process. It doesn't leave you with enough information to actually build anything after. It leaves you with enough information to give you direction whether we should go forward or not. And when you really work in a company, you have, things are time-bound. As a, from the business standpoint, you need to know how much money it's gonna cost, how much money it's gonna bring, and how long it's gonna take and how long until it brings in money. So that being said, you need to know some of those answers. Is it going to make money? Is it going to, you know, be successful? Is it gonna make sense? Should we build this? You run a design sprint, you answer that question. If the answer is no, you didn't waste a bunch of time building something, costing a bunch of money and things like that. Quite the opposite, you only spent a week. Even though it is still expensive, it's significantly less expensive than actually building a product that no one uses and no one likes. So there are some similarities in that, but I think what really separates the two between design thinking and design sprint is design Sprints have a definitive process. It's a 5-day thing, you do this, right? So you can scope that amount of work, that amount of cost, what's gonna happen, and you can use the information to figure out whether we should proceed or not. So both of these really are in the discovery process. Now, going back into design thinking and that implementation process, we have validated through design sprints or through the discovery research or whatever it is we took to understand and validate the direction, we're now going to build this. And now we move into the implementation process. So this is where we're gonna build the feature and that even has a process within itself. So this'll move into an actual designer that has a scoped amount of time. Say it's, we wanna work on this for 2 weeks. We wanna explore this. We've tested this bigger concept, but we're gonna actually build it and build, you know, what's in scope. We need to define what's in scope. So what problem are we solving? What are our predispositions, our assumptions? What are our assumptions about the solution? Maybe we already have kind of an idea that we want to go, that we believe in. And then we start looking into the research. So we'll look into any user research. We'll look into the outcome of that design sprint. We'll look into all the research that's been gathered. We'll also look at competitive analysis. We'll look at literature review, which is best practices and standards. We'll gather what we know, the insights, we'll validate. It'll also, any existing patterns, what exists today, if we're enhancing a feature, inspiration. So all the stuff that has, it's gonna actually enforce the design direction. 'Cause we've already validated we're gonna build it, now we're building it. You'll take that, you'll create a concept, you'll take that, you know, a drawing, low fidelity, you know, flow, IA, you'll review it with your team, everyone comes together depending on, this is now getting into your design process. At your company and actually doing things. And then you'll prototype something and then test it depending, and this is depending on the scope. So what we do is we have these things called enablers, which are two weeks, you know, because we use time tracking, Scaled Agile Methodology, we track how long something's gonna take. We have two different types of works between enablers, which are based on time. So in this scenario, we said we're gonna try to design and explore for two weeks, or there's stories, which are based on completing tasks, but You know, actually scoping work is for another video. But so in this scenario, we say we're gonna work on this feature that we have explored for 2 weeks. We're gonna define it. We're gonna really figure out all the nuances, all the paths. Say the flow goes through here. There's error states, the things that are starting to go into development and starting to really mold this into something more solid. After that 2 weeks, you may evaluate and realize we need another 2 weeks. This feature is pretty big. There are a lot of different use cases. There's a lot of different areas that it touches. You need to create this. You need to see a report for this. You need to be able to interact with it here on this app. You know, so it could become very large and this is where the details happen. In 5 days, you don't have time to go through all those details and all those nuances and areas. You don't have the time to deliver something that's buildable in that 1 day of prototyping. But 2 weeks of prototyping, you actually have time to do, or 2 weeks of work and it may expand into 4 weeks. It depends on how far along you get done. And then from there you may schedule, like depending on, on the how long it takes you to test and what tools you use and things like that, you may need another 2 weeks for testing. You may need another 2 weeks for continue iterative design. So that's where design gets— you start seeing these cycles of going back and touching things because you really have to make sure you're testing in order to understand which direction we're going forward. Sometimes the process gets a little skewed and so it helps to define how it's gonna happen, when it's gonna happen. Now that we've touched a little bit about how you scope UX work and how to become a little bit more definitive in it, let's start from brand new beginning. Idea. Someone has an idea or even better, business has defined a problem. We wanna help increase the retention, right? People are buying a product but they're not coming back and buying anything else. Why is that? Why is that dropping off? And this will take generative research to understand your users, how that journey's going, what's the process, what are they doing, how do they get here, how do they leave here? And that right there may help inspire some kind of concept. Oh, you know what? Maybe if we add a loyalty program, they'll come back, right? We'll reward them for coming back. We do see some people come back, let's help give them some kind of reward that'll help them bring that. Or we'll also reward them for sharing it to other users so that they get rewarded for referrals. We'll start creating a loyalty program. It's a good idea, right? That's a great idea. So then we need to go look and see how that's happening today. Do people use loyalty programs? Do they value that? How do they expect it to happen? What rewards do they expect to get from that? So you have, I call the first one business discovery. And then feature discovery. So you move from that feature discovery to maybe a design sprint within that. Let's, let's try something. Let's see if this works. Let's test it out and see if it makes sense so we can actually show some UI, show some things. And really that can be X amount of enablers, X amount of 2-week enablers to finish that or to properly understand and validate your direction. And there's a, there's a great article about the, the design sprint quarter around how you validate whether you should go this direction or not. I'll link it in the comments or whatever is attached to this video. But once you've validated that, then it needs to be prioritized in your backlog. When are we going to build this? If is this, are we going to build this in the next, the next phase, the next epic, the next time or group of time? Is this the next priority? But it moves into the backlog as something ready to go. So When you actually start going to, okay, we're gonna, we wanna build this, say we wanna get this built sometime between, you know, October 2024 or October 2023, or, you know, Q2, whenever you wanna do it, you need to prioritize that based on that desired release. So then you start moving into that design process and that's the lean UX process. That's starting to design, going through that process I discussed. Around understanding the problem, the predispositions, reviewing the research, checking out the insights, concept, prototype, and then strategy. And then you may, after the lean UX phase, you move into usability testing in which you test it and make sure it's usable. It matches the user's mental model and concept, the conceptual connection. And then you start moving into what's actually gonna get built, making sure you have the proper blueprint to be built, the design in different breakpoints, using the right patterns, connecting the branding to the actual design, and making sure the development team has all the states they need, all the breakpoints they need, all the specs they need so that they can properly build a usable, functional, good experience for that feature. So I know that's a lot. And I tried to— what I tried to do there was take the— these large themes between design thinking, design sprint, design process, and put it into something realistic. I hope you guys enjoyed this. I hope it was helpful. If there's any confusion around it, let me know. I'd love to have more discussion about it and talk more about it. Some of these bigger concepts, I, you know, they can get into extreme, extreme detail. Like we can start covering into the exact steps of how to conduct the design sprint, we can talk about what areas of design thinking actually are. Like, what does empathize mean? That could be user research where you're observing, shadowing, you know, creating documentation. What does define mean? Those can be empathy maps, affinity maps. Those can be problem statements. Those can be what does the definition phase look like. But I'll try— that's kind of the point of this channel is to start diving into some of the advanced UX concepts and things Showing how they can actually be implemented, covering what they really are, and just opening the discussion, 'cause sometimes these things are not, they're very high level, and you need to actually understand them. There's, some people are big picture thinkers, some people are good at breaking down what actually needs to happen to accomplish things. I'm trying to marry the two. So, let me know if it makes sense. And thanks for watching. If you like this and you wanna see more of it, Make sure you subscribe. Uh, if there is something you want to know, feel free to comment, and I will talk to you guys later. Thanks for listening.