- The Facilitator’s Handbook: 24 Design Sprint Tips
- Written by Jake Knapp
- The Nuggets translation Project
- Permanent link to this article: github.com/xitu/gold-m…
- Translator: PokerF
- Proofread by: Rydensun
Here are a few things I think about when guiding a Design Sprint. I can’t explain a lot of things that lead deep into it — like some things you just do, you get experience, and it gets better and better over time. But there are a few principles and tricks that I consciously, and remind myself to do over and over again, because they work and are perfectly normal to me. (Some of these principles and techniques are in my book but most are not.)
1. Focus on three priorities: ask questions, take notes, and be aware of time.
At its core, bootstrapping is simple. You have to ask questions to get the information out there, document the information and ask more questions to make sure you document it correctly, and you have to have a sense of time to go through the steps. When feeling overwhelmed, go back to basics.
2. Trust the rules
My best guiding technique is to follow the design Sprint process, especially if I have to attend other meetings, I like to follow a pre-prepared process and schedule. Even after countless design sprints, I refer to the memo at the back of the book to remind me of the next steps when I’m guiding. Rules can help you do your job better.
3. Get pre-committed or skip the sprint
People coming in and out of meetings ruin sprints (unless you carefully plan to sit in, there’s more on that in the book) and it’s hard to end once it starts, so either get people committed up front to staying in the room for a while or never do sprints at all.
4. Explain the Sprint before you start
Sprints are easier when people know how the activity fits into the team. So a week before the sprint, I sent the team this 90-second sprint video and a link to my “Stop Brainstorming, Start Sprints” post, both of which were quick and accessible. Of course, it would be great if everyone previewed the book (and on the few occasions I did sprints, it would be incredible), but it’s not realistic. On the first morning of the Sprint, I started with a short story about what the sprint would be like. (You might show a 90-second video, audio or silent, so they’ll be reminded how it works.) And at the beginning of each subsequent day, I remind the team of what they are going to do today. (You can also use them for daily video, if you prefer.)
5. Ask permission
Once you’ve explained the sprint, tell the team you’re going to start guiding, keeping things on schedule, and driving everyone step by step. Ask them, “Does it sound good?” Don’t expect an enthusiastic response ———— but this is something powerful and symbolic about getting permission from the team. I learned this from Charles Warren, a guy I met at Google at IDEO. Master facilitator and great teacher for many years.
6. Break the ice yourself
I don’t like icebreakers. If there are skeptics in the room, a stupid icebreaker can destroy your credibility right from the start. I think the team has confidence that I can make the best use of their time and energy. That doesn’t mean we can’t have fun, but I want to get things started quickly and pragmatically. And eventually break the ice on its own. Be patient and don’t assume you have to have an ice-breaking event just because it’s the workshop default. It will be awkward at first, but trust that those people will get comfortable with each other. They always do, and you’ll be glad to have the extra time later.
7. Write your name on the blackboard
It’s important for the facilitator to remember their names — conversations will be much better when you can use them by name. Whenever anyone is a stranger to me, I like to walk around the room and ask everyone to introduce themselves and write their name in a corner of the whiteboard to make a small map of the room. Then everyone, including me, can refer to it when they want to know someone’s name — no name tag required.
8. Fake confidence (being nervous is perfectly normal)
You’ll gain more confidence over time, but at the same time you should know that it’s only natural as a facilitator to feel nervous before or during a sprint. I’ve been in a lot of sprints, and you’d think I shouldn’t be nervous, but I know I’m nervous before anyone. But you need to be confident in the sprint and in the team, even if you don’t feel completely confident in it yourself.
9. Don’t outsmart anyone
You’re not going to be the smartest person in the group. If you think you are, you are creating unnecessary stress and potentially making a fool of yourself. The facilitator is there to make sure the sprint happens and provide a framework for everyone to succeed. You don’t have to solve problems or be amazingly insightful. You’re not an actor or even a director. You’re more like a producer. You’re not an omelet, you’re an omelet pan. It’s a very important position, but it’s not about being smart. I’m with all kinds of super-smart people at Sprint, and I want to impress them — sometimes even famous founders that I really admire. But I soon learned that the best thing to do is not to be smart, but to be helpful. And the best way to be helpful is to get Sprint up and running, so Hotshot’s CEO and her talented team can figure it out. You ask questions, you take notes, you keep track of time. That means a lot, and it’s important.
10. Be energized
You don’t have to be crazy about it, but you are sprint’s battery. If you are low energy, the team will be low energy, and if you are positive, the team will be high energy.
11. Keep your caffeine intake steady and drink lots of water
I’m very aware of my caffeine levels when I’m leading. I’m a coffee lover and I always risk drinking a lot of coffee so I get high at the beginning of the day (when I’m highly stressed and trying to get high energy), but if I do, I pay the price and crash in the afternoon. Instead, I take a sip of coffee (I’m right to do so if it gets cold) and a small dose of black or green tea to maintain my energy levels throughout the day. I also intentionally drink a lot of water because it helps me remember — warning, it’s true.
12. Ninety minutes is the pee limit
If you rehydrate, you won’t forget this, but remember that 90 minutes is the maximum you can do without getting up and walking outside of rest, because people need to pee. Seriously, don’t make people uncomfortable when you’re in charge.
13. Give positive feedback
Find ways to give positive feedback on their work during the sprint. When someone says something clarifying and says “This is a very good method, very useful.” This may sound hypocritical, but it’s good for team motivation and confidence.
14. Acknowledge embarrassment
If you just get people together in a room, the design Sprint process is not the natural way people want to work together. Sometimes like in the critique on Wednesday, or on Monday you’re writing “what can we do” notes — it’s not natural. Don’t try to act like normal behavior. After many iterations, I say “This might feel a little awkward,” or “this doesn’t look natural,” and I find that people are visibly relieved to hear that they’re not the only one — and that often cuts down on the difficulty for those who want to focus on the process. If you’ve laughed at them, they won’t have any momentum. Well, sometimes they just keep doing it.
15. Seriously, mandatory “no device”
Don’t let people use their phones or laptops. It’s uncomfortable, but you have to do it. Let them make phone calls outside, check E-mail or whatever. Say, “I have to let you use them outside the room because the screen makes it hard for everyone to concentrate. But it’s perfectly fine for you to avoid going outside and then coming back.” Everyone will silently thank you, and you will build respect. Respect aside, you have to seriously exclude devices from sprint or things will get ugly.
16. How to deal with different people (3 levels)
All right, now let’s dive in. What happens when you meet someone different, a talker, a never-ending debater, a time-waster, or a complete jerk? You’ll have to deal with that, but you’ll get a good start. I use three gradually ascending levels:
- ** Level 1: Write down and continue – ** write down their arguments on the whiteboard and continue the sprint. Blame time and schedules, not people. Say, “Let’s write that down so we can move forward,” or “That’s a really good point, but we don’t have time to discuss it right now, but we can come back to that point later.” If this doesn’t work.
- ** Level 2: Remind them that the process will take care of it — ** This is another reason I like designing sprints: it gives me an honest way to end a time-wasting session. “Let’s make sure your point is reflected in the (Sprint question/room map/as a ‘HMW’ point).” Or “You’ll have a chance to sketch out your solution,” or “You’ll have a chance to make a case for what you think is the best solution,” or “We’ll have some preliminary data on Friday.” Try agreeing instead of disagreeing and asking directly: “Yes, this is an important point. The good news is late in the sprint.” If none of this works.
- ** Level 3: Be blunt – ** At this point you need to drop the hint and you need to tell the person to cut it out. You might want to stand by and talk to this guy. “I really value your contribution and want you to be part of the Sprint. But for this project to succeed, I need you to (smooth your tone/give the process a chance).” I find it helpful to remind people to think of the process as an experiment — prototyping and testing is an experiment, and the team can evaluate whether the process itself is useful later on, but if they resist the process during the process, we’ll never know if it works.
17. “Pause” instead of “stop”
I like to use the word “pause” instead of “stop” when I need to interrupt a team. “Let’s stop this conversation.” It’s a small thing, and it’s a good word — it seems more polite (and more acceptable to the team) than stop. But the idea is the same.
18. Balance patience and impatience
Good guidance requires a balance between patience and impatience, confidence and humility. Be patient and let the team talk for a few minutes, but also be impatient to remind them of time and shorten the conversation — it’s either productive or it’s not — when it gets too long. Be confident, the team will have confidence in you, the organization will have confidence in you, and things will move forward, but be humble and allow others to offer content, insights, and solutions — even if they’re off-topic. Part of being humble is keeping the conversation lighthearted sometimes, as this may lead to surprising insights for some people — but you can’t let that get too far off the point. As time goes on, you will master the skill of balance. When you’re just starting out, trust the timetable in the book, which is pretty good. Over time, you’ll know how much time you have left to keep the conversation moving and when to say, “Decider, I need you to break a tie so we can move on.”
Always be on time, even if you’re not
Another lesson from Charles: Always act in time. Don’t worry if you’re slightly behind schedule – I often do, and it’s quite possible to catch up again. But don’t spread the word to the team that you’re behind schedule. In fact, while you should use the time guide in the book to help you keep up with the schedule, I recommend not writing time on a whiteboard or sharing it with your team. If you fall behind, they don’t need to know about it because you’ll catch up again. And it’s easier to catch up when the team has confidence in you.
Blame it on the book
If you have to rush people, or if something gets weird, you can always blame the process, or the book, or me. It wasn’t you who said the device wasn’t allowed, it was stupid Jack. It’s not you saying we have to go crazy for eight seconds, it’s in the book, but let’s try it.
It’s not your fault that the process becomes annoying, it’s the stupid book.
21. Push the team to do something important (balance idealism and cynicism)
On a daily basis, it’s easy to get caught up in reactive reactions and optimizations — but in the Design Sprint, you might have the opportunity to reset the course. You might be able to do something that’s really important to your client. I said maybe it’s because it’s hard. Designing great things requires you to act with genuine idealism, which is discouraged in most workplaces.
Give it a try. Remind yourself and your team why you accepted the position or started the company or signed up for the program in the first place. It doesn’t have to be optimal. You don’t have to react. It’s ok to aim to do well and do well. If that sounds ideal, yes, it is. It’s okay to be idealistic, and you can do it if you sometimes add a little frank cynicism. Here’s what you should do:
- ** supports bold missions. ** When setting a long-term goal, try saying something like, “I want you to remember why you started this project, or why you joined this team. Right now, be naive and optimistic. Who are you doing this for, and how are you going to improve their lives? Be more optimistic, what will we get in a year or two?” To push the team to show their emotions. Bring back the bold attitude when the team describes the solution and decides on the prototype.
- The government stands for frank cynicism. ** But don’t just be Captain Sunshine. Do the main sedative when listing sprint problems and motivate the team to be “unrealistically cynical,” like, “How did things fall apart like this?” “And” Are there flaws in the plan that we don’t want to admit?” “And” What would our worst detractors say? You could even question Sprint’s framework itself: “Will the long-term results of this product be positive for customers — regardless of this Friday’s test results?” “Or” Does this project make sense for our time? What about customers?”
You may not feel comfortable doing these things in your first sprint, but it’s ok. When I created a Design Sprint, I was frustrated because so many teams wasted time building mediocre or pointless products (that’s cynicism) when they had the opportunity to go faster, do something wonderful, and make the world a better place. (This is absurd Silicon Valley idealism.) I have always believed in the efficacy of Silicon Valley idealism. But don’t just be idealistic. And instead of being a quitter idealist, temper yourself with cynicism. Embrace both and do something great.
22. Get represented
You will be better and more confident every time you guide. So even if you finish the book and use all the skills you have in this position, you’re not going to be the best facilitator in the world when you first do it. Get as many delegates as you can, and know that the first few will give you the steepest, fastest learning curve. Including workshops and sprints, I’ve probably guided over 200 things, and I’m still learning new things, but even after 5 sessions, I’m about 85% as comfortable as I am now in guiding. Offer to lead a team meeting or a half-day workshop or a sprint for another team. Do 5 representative experiences as quickly as possible.
23. Don’t take yourself too seriously.
You can laugh at yourself if you can. Laughed at the absurdity of a group of grown-ups sitting around a list of activities. There is.
24. Enjoy it
Running a Design Sprint is hard work, there’s no doubt about it. But it should be fun. To me, this is the absolute best job: a challenging problem, a period of undivided attention, a group of people working together and bringing them to their best, constructive opposition, and progress. This is just going to be one of those moments in your life — enjoy it.
One more thing: Remember, ** you don’t have to be perfect in the sprint. ** Your map doesn’t have to be perfect (mine never was), you don’t have to explain everything perfectly, and you don’t even have to remember these tricks. This process is very robust, can handle a lot of imperfections and still solve problems. Just ask questions, take notes, keep track of time. ⚡ ️
If you have questions or a tip of your own, please share them in the comments section below. Thank you very much!
The Nuggets Translation Project is a community that translates quality Internet technical articles from English sharing articles on nuggets. The content covers Android, iOS, front-end, back-end, blockchain, products, design, artificial intelligence and other fields. If you want to see more high-quality translation, please continue to pay attention to the Translation plan of Digging Gold, the official Weibo, Zhihu column.