 What if I told you I can get you from an idea to prototype with real user feedback? In just four days, giving you a step-by-step process is the fastest and cheapest way to validate a product. That's right, I'm not bullshitting. Let's talk about the design sprit. I've been facilitating design sprints for the last five years, and without a doubt, it's the game changer for inexperienced product team. Whether you want to set a direction for a new project, establishing initial processes, aligning your team around product or vision, gaining speed, efficiency and focus, validating assumptions, reducing risk or failures, this framework covers it. In this video, I want to walk you through what is a design sprint? What it looks like each day, tips of becoming a confident facilitator, how to build workshop slides for your team, and then later I will talk about the most important topic of them all, the dangers of not doing a design sprit. So stick around for that. Okay, so what is a design sprint? A consecutive row of workshops that support co-creation and empowerment of your team. So why design sprints? Well, design sprints help you understand essential focus areas to ideate on, turn your ideas into testable hypotheses, and make real prototypes to get feedback from real users. So how does a design sprint even work? Well, we start off the week with Monday. This is where we map and understand the problem of space. Then from there, we identify what we're going to focus on, and then we produce sketches. We use a bunch of different techniques, first from noting to then crazy aides and then solution sketches. So stage by stage, we take you through the ideation process. Then on Tuesday, we actually have a rigorous voting system to decide what is the best idea in the room. And then from there, we paint a picture using a storyboard to say, okay, if we were to make this prototype, what would it look like? What does the customer journey look like? And what are the essential parts of that storyboard we should follow? Then Wednesday, we actually build this prototype. We adopt a fake mentality just enough to create a facade for the user. And then finally Thursday is the big thing, the culmination of all our work. We actually go out and test your prototype. So you can actually learn from what works and what doesn't, real feedback from real users. So when Friday comes around, you can just chill. It's Friday. You ain't got no job. And you ain't got shit to do. This is the Design Sprint 2.0. And it's an improved version by AJ and Smart. The original concept was actually done in five days. But I found this version to be way more efficient, saving you one extra day. Five days is a lot to steal from your team. Okay, let's talk about how you be a confident facilitator. The amount of work that could be accomplished during Design Sprint is absolutely incredible. You'll be amazed how productive your team can be, where they have a good sprint structure to guide them. To run a successful Design Sprint, focus on the following and this will make you a confident facilitator. The first thing, the big three, ask questions, jot things down and mine the clock. If you do those three things well, the whole process will run a lot more smoothly. The second is trust the process. It's a step by step framework. If you just follow this process, you'll be able to take your idea to getting real feedback so much smoother. Don't skip any of the steps. Number three, get people to commit to the sprint in advance or don't do at all. It's important you get bind from the beginning and they know what the sprint is about. If you have people coming in and out, it just does not work. Trust me, I've tried it before. No, no, no, no, no, no. Four, consent is key. So ask people at the beginning of the workshop, hey, we're about to do this thing. I'm going to move you on. If you start to ramble, is that okay? Once they have consent, you have their bite. Number five is write names on board, because if you're like me, you forget people's names. Say my name. It's actually harder to refer to them and also what they do. If you write the name of the board, you can't forget and it's clear that they are there. Cheers, Jeff. Number six, know that it's natural to be nervous and try your best to project confidence. To be a confident facilitator, you have to pretend that you're confident or at least play like a confident facilitator. Please just pretend to be confident if you cannot be confident in yourself. Number seven, give positive feedback. Giving positive feedback will help and encourage others to go brave and go crazy with their ideas. Remember, we're not here to judge, we're here for the best idea to win. Number eight, being a good facilitator requires a balance of patience and impatience, confidence and humility. Number nine, take regular breaks. Talking about a complex problem or lots and lots of ideas really take a toll. So remember to take regular breaks. Number 10, you do not have to be perfect. Learn from the process and make the sprint better. I mentioned you shouldn't skip part of the process, but if some part of the process can be optimized, feel free to do so. So those are some best practices for facilitators and to be confident, you also need your workshop slides to be on point. So you want to avoid slides with a lot of text. Create title pages before diving into each exercise. Include concise bullet points as instructions. Be more explicit about timing on the exercise. Hurry up. Show examples of a desired output for each exercise. Use large fonts. Include plenty of white space. Use color to highlight key points. Keep design elements to a big animal. Use visual aids only when appropriate. Limit the transition and animations if needed. Just subtle animations. You don't want flying things left and right. That's not point of good slide design. And finally, you've been waiting for this. Dangers of not using the desired sprint. Well, a few not so pleasant scenarios can happen if you decide to ignore the importance of desired sprint. For example, investing too much time and money in ideas and products without validating user's needs. We've all been there. Another one is making decisions without understanding user preferences and behaviors. Just guessing. Shooting in the dark. What about wasting resources on features that don't get used? I mean, even if it's cool, who cares? Missing opportunities to gain a competitive advantage. The slow mover does not win the race. Developing products with a poor user experience. Having an ineffective team collaboration. Take longer to get to market. Silo teams and gaps in collaboration. Unsuccessful product launches due to lack of user testing. I've run 20 sprints at work and as a consultant. The number one thing I hear is, wow, we got a lot done. It's rare that stakeholders can really focus on a specific problem without distractions. Getting people in the same room for hours or days can really move the ball forward. Inexperienced teams love this because it gives them a step by step formula that brings them from problem to solution with real user feedback. They get a taste of design thinking methodologies with meeting principles that focused on getting started, not being right. I mean, you can squeeze months of work into weeks or less. Here's a stat to back up my claim. According to IBM, design thinking research can lead to 75% in reduction in design and delivery time. Often reducing a project from eight months to three to four months. Whether for research, marketing, growth design, branding, strategy, or any other discipline related to building products or exploring new markets, the design sprint method is acknowledged as a viable, efficient, cost-saving research option. Considering that design sprints help you reduce the risk, offer more efficient process to validate your ideas, remove traditional convictions and accelerate innovation. You can't afford to not try this method. If you're interested in learning more about design sprints with a detailed guide and templates, check out the link in the description. Hit the big red button for another play-by-play breakdown of UX frameworks. Bye!