Welcome to Magical Meetings Stories, a series where I chat with professional facilitators, meeting practitioners, leaders, and CEOs across industries about their meeting culture. We dive deep into a specific Magical Meeting they’ve run, including their approach to facilitation design, and their tips and tricks for running meetings people thrive in. 

Today’s story is with Eric Morrow, a well established facilitator, instructor, and author. He has worked with several Fortune 100 companies such as Capital One, Walmart, and Google, and taught with General Assembly, the University of Oklahoma and CU Boulder. At IBM he led design thinking projects that aligned executive teams and engaged essential customers. He also started Staircase Strategy to partner with fellow leaders eager to use Design Thinking to solve complex problems. 

I spoke with Eric about his User Story Mapping meetings, what prompted him to implement them, what they help accomplish, and his advice for those looking to leverage user story mapping in their organizations.

“For me, you know a good workshop or a good meeting is hitting the mark when resistance to having that meeting disappears…where all the sudden people are asking for it, versus saying “Why do I have to do another meeting?” -Eric Morrow

Removing Obstacles 

Eric first implemented User Story Mapping meetings while doing design thinking workshops at IBM. The idea of user story mapping, from Jeff Patton’s book of the same name, is to “talk about the user’s journey through your product by building a simple model that tells your user’s story as you do.” Eric explained there would be a point in the workshops that everyone felt comfortable about the outcome, but fast forward a few months, and the engineering team hadn’t built what was discussed. “There seemed to be trouble with the transition between what the design and product folks were thinking, and then what the engineering team was actually building,” he says. Eric identified a need to make the design thinking workshops useful for the entire team, not just the design and product managers. After doing research on how to bridge that gap more effectively, User Story Mapping was the solution he decided on as a way to bring engineers and agile teams more closely into a design thinking and research-based process. 

The main purpose of the meeting is to bring the design, product, and engineering teams closer together and to be more in sync with each other: “Rather than this ‘throw it over the wall’ type of experience, it allowed the design leads, engineering leads, product leads to come together and really agree on what needs to be developed and designed and built, in a way that will really meet the end user’s needs,” he explains. 

When I asked if he received any pushback when he first came up with these meetings, he said it was actually the opposite and the pushback came before the meeting was implemented. Engineering teams didn’t want to waste their time doing design thinking activities, they told him, because it didn’t actually help them, and didn’t give them anything tangible to work on (which is what they really need, as they’re often evaluated based on how much code they push): “So I think the pushback was on design thinking workshops before I started using User Story Mapping. And then after that, design teams were really excited to come because they knew that what they were going to be working on was going to be relevant for the engineers. The product managers were happy to come, because by understanding what the engineers would be working on, they could validate those ideas with their end users/customers, and give them a better sense of what would become available. And then engineers liked it – if engineers build something that’s not ultimately used, they have to go back and redo it. That’s a big waste of time. And so the engineers were really happy to say ‘well, this has already been validated, this is good to go, that means we only will have to write that code once. We’re not going to have to write it then throw it away then write it then throw it away.’ For me, you know a good workshop or a good meeting is hitting the mark when resistance to having that meeting disappears…where all the sudden people are asking for it, versus saying ‘Why do I have to do another meeting?’”

Let’s take a closer look at Eric’s process to learn what makes his User Story Mapping meetings magical.

The Meeting 

Pre-Meeting Prep 

Eric recommends going into the meeting with two things (which is usually the design team’s responsibility to prepare): the personas and “as is” scenarios. The persona is who it is you’re building a feature for – it could be the end user or key stakeholders. Especially in B2B solutions, the person buying software may be very different from the person using the software, for example, so having personas for different people is important. The “as is” scenarios are understandings of how those people get their work done or go about their life today, as is. 

Exercise

These User Story Mapping meetings, which Eric recommends holding quarterly depending on the pace of the team, should include design leads, product leads, and engineering or technical leads. This meeting can be done with various sizes, but doing it with 6-8 people will likely take 2-3 hours in a remote setting (slightly faster if not remote). The main question the teams are trying to answer should be some form of a big idea: “What are we building? What ideas do we want to implement? What could we do to improve someone’s experience or help solve some of their problems?” Since each team will likely want a different version of an answer from that question, the purpose of the meeting is to get everyone on the same page and understand needs from the other disciplines. 

Mission Statement:

Eric explains the next step is to merge those three key pieces (the persona, “as is” scenario, and big idea) together into a mission statement, or as IBM calls it, Hills. “It should be some version of: A user wants to accomplish this goal, for whatever the reason is. For example, if we’re talking about a taxi hailing app, it would be: An airport traveler wants to press a button on their phone to summon a taxi to see where the taxi is and how much it’s going to cost to get them home after a trip.” 

The “to be” experience and user stories:

From there, the goal is to map out the “to be” experience for your persona, or what their life will be like after the solution or feature is available,(compared to the “as is” experience, which is what their life is like currently. The “to be” experience is full of steps, and the teams should break down each step or feature into user stories. Working closely with the technical team here is key, Eric says, to outline each individual piece that will enable the experience at a very granular level. The individual pieces are everything it would take to implement the experience. Going back to the taxi hail app, examples would include needing to get a user’s GPS location, ability to show where all the different taxis are located, ability to quickly determine a price based on a database, etc.

Revisit the big picture:

After getting granular, the next step is to zoom back out to the bigger picture and determine if the overarching “to be” experience still makes sense once all the details have been outlined. And usually, what happens when everyone looks at the granular details of the user stories, he says, is the team will want to change features around or revise the mission statement, and go up and down this chain quite a bit. “So after you’ve refined your mission statement, maybe you go back and revise your ‘to be’ experience and you revise your user stories. But this is really the magic – rather than spending too much energy at any one stage, I recommend teams move quickly through the back and forth of all these steps.” 

The tools:

After the “to be” experience and all the user stories are mapped out, it’s time to put them into an agile backlog in order to plan and prioritize them. Common tools for this include JIRA, Asana, or Github to keep track of all the tickets.

The golden thread:

The final step, according to Eric, is to make sure incremental value is being driven for the end-users. Using a golden thread approach, identify the key or essential experience, and build that first. “Generally speaking, folks are going to start building from left to right, and you don’t want to do that, you want to say: What’s the experience that will provide value to the end-user? So you can put it in front of them, get feedback, and then keep building with feedback from your end-user. That’s about 2-3 hours for all that work, for one very specific feature.”

Roles and Responsibilities 

Typically in a User Story Mapping meeting, Eric recommends having at least engineering, product, and design leads. Other teams could also benefit, such as sales and marketing or legal, even just as observers to see what’s coming down the pike.

“The way I think about it, the most amount of work ahead of time is done by Design at the beginning. Preparing the personas, the ‘as is’ scenarios, and then during the meeting, everyone participates in the big idea creation, the ‘to be’ scenarios. And then the engineers are much more involved when you get to writing the user stories. And then once again, the product person is going to be tasked with setting up the backlog, to ensure the engineers are working on the things most important to the customer, at the top. One nuance is if you have a lot of folks, you may want to split up or work individually for some of these story mapping bits, so that the team can make a lot of progress in concert, rather than working on everything one thing at one time. Especially if you’re time sensitive, you want to hammer everything out as quickly as possible. But other than that, usually it’s a whole group activity.”

The Deliverables

The primary deliverable is developing the user stories and curating a backlog for the engineering team, so they can immediately start work on any software development processes, Eric explains. A secondary deliverable is helping with the entire validation cycle, or according to Eric, the best part of design thinking. 

Potential Pitfalls

I asked Eric about any potential pitfalls to this meeting. He says the biggest potential pitfall is if teams try to do too much, too fast at once: “I think a facilitator who wants to run this sort of meeting needs to understand how all the different organizations work, especially if they’re working mostly independently with a ‘throw over the fence’ type mentality. Often folks aren’t used to working together in this really productive way, so starting out small with one feature, not trying to bite off everything at once. So do a couple features at the beginning, to get folks used to working in this way. So that’s probably the biggest pitfall, biting off more than you can chew if the team is not prepared to work this way and then ramping them up as you go along.”

Advice

Eric and I also discussed advice and recommendations he has for those looking to implement User Story Mapping meetings and workshops but maybe haven’t done them before. His recommendation is to keep it simple at first – start with just three people: the design lead, product lead, and engineering lead. Then, choose one small thing that’s important, but fairly far in the future. If possible, keep it to a one hour rapid fire session. “To do that, you really have to narrow down the scope so choose one feature that needs to get released. That’s what I recommend,” he says.

Other Resources

There are a few resources Eric recommends reviewing for those that want to learn more about user story mapping:

• Build Experiences not Features
• Connecting Design Thinking to Agile
• User Story Mapping

Looking Ahead

I asked Eric what he wants to do next, and how he might take User Story Mapping to the next level. He said he’d like to connect the specific, granular details back to the strategic aim: “Usually, your senior leadership leaves those technical details alone. But if you can show them – here’s how you take an idea, a strategic initiative, and here’s how we map it out so it aligns with all the initiatives of your entire product team, from the product owners to the product designers to the engineers. And moves all in concert. Through having sufficient upfront design research where you’re vetting all the features with your customers or with your users before shipping and building, we’re going to really improve the velocity of your engineering team and your ability to go to market. So I think if you’re really bold, you can use user story mapping to help show senior leadership how to achieve strategic initiatives faster and more effectively.”

The post User Story Mapping appeared first on Voltage Control.

Arguably one of the most famous Albert Einstein quotes is: “The definition of insanity is doing the same thing over and over again and expecting a different result.” If you are having the same meetings over and over again, expecting to learn or create something new – that is insanity! It is time to break out of your method biases and start having better, more magical meetings.

Method bias – and any kind of bias for that matter – exists because the human brain is programmed to turn repeated information and stimuli into mental shortcuts because this kept us alive in our hunter-gatherer days. Unfortunately, the human brain does not always know what is best for us now that our world is so much more complicated. Team facilitation is a much more complex task than identifying which leaves on a newly discovered bush are going to be sharp. Therefore, it is critical that we push past our impulses to rely on old habits lest we smother our teams’ innovative potential. Here are some strategies to eradicate your method biases, create a meeting agenda, and revitalize your meetings.

Backwards Design for a meeting agenda

The first step that must be taken to prevent method bias is to identify the desired outcome of your meeting. The activities you choose should be implemented for the sole purpose of delivering you to your desired outcome, so you need to understand where you’re going before you can start planning your journey. A plane does not take flight before it knows where it is going, and neither should you.

Backwards design is crucial for designing the activities that will fill your agenda. Just as you must let your objective lead the way when planning a meeting, so too must your desired outcome guide your methods. Don’t get stuck in old habits or rituals that do not properly serve your goal. Throw out frameworks created by others and devise a method specifically engineered to deliver your desired outcome. Trying to shoe-horn a system built for other teams or other projects will only end in both you and your team feeling frustrated or stalled.

Clear your mind of the impulse to use the same methods as always and reverse engineer your meeting activities to reach the outcome you want.

Don’t settle for an answer that’s too vague or broad when determining your desired outcome for your meeting agenda; drill down to the core of what you’re looking for. What are the deliverables you seek? What are you building? What does done look like? The better you understand what it is you’re looking to create, the more targeted you can be when devising your plan of attack. If you find that you’re having trouble moving past old methods created by others that have become habit, it is likely that you have not given enough thought to your outcome; return to it whenever you feel stuck.

This isn’t to say that you must construct every activity from scratch. Some methods are indeed tried-and-true. However, if you find yourself using the same few methods in every meeting, take it as a sign that you need to reconsider whether your methods are in service of your outcome. It may be that you’ve developed a repertoire of methods and activities that are flexible and multi-purposeful. If this is the case, that’s wonderful! On the other hand, it may be that you have replaced a previously held method bias with a new one.

Take Your Eggs from Many Baskets

Once you’ve solidly identified your meeting’s desired outcome, it’s time to decide how your participants will spend their time in service of that outcome once they are in the room. Look at your current go-to methods and consider where you first learned them. If your answer is “we’ve just always done it this way,” that is method-bias’s brightest red flag. Another warning sign is if all of your methods and activities were picked up from the same source.

As meeting-makers, we have been gifted with many talented facilitators, teachers, philosophers, and leaders who have shared their own unique methods and frameworks with us. It is natural to gravitate towards a particular framework or style, but you are doing yourself, and your meeting participants, a disservice by narrowing in on only one corner of this wealth of knowledge. You are standing in an orchard of facilitation wisdom; do not pick all your fruit from the same tree.

Do not feel pressured to color your agenda with a rainbow of different facilitation frameworks or philosophies, as this is likely to create a jumbled mess of mixed expectations for your participants. After all, methods within a framework are created to complement each other, so it stands to reason that they would be used together effectively. If you happen to find yourself stuck in a rut, picking up a few new ideas or activities from a new facilitation framework might be just the breath of fresh air your team needs to rejuvenate their creativity and engagement.

Don’t Be Afraid to Experiment

Breaking out of your bias may feel like a lot of pressure. People become comfortable in their routines and there can be a fear of judgment should a new approach fail. Release yourself from this pressure by recognizing that you will not be alone in trying anything new with your meetings. If you feel stuck in a routine or chained down by habit in your approach, your team does too. They will be excited to remove the weights of outdated or overdone meetings and soar to new heights of productivity, creativity, and collaboration.

Think of your new methods and activities as experiments; your hypothesis is that they will serve your team well, and you will either prove or disprove that hypothesis when you put them into action.

There should be no expectation that an activity is going to work flawlessly the first time you try it, nor that everything you try will be the right fit. You are a facilitation scientist, conducting experiments to find the best methods to reach your desired outcome. The failures are learning experiences just as valuable as those of the successes.

Need help building a better meeting? Bring in a professional facilitator from Voltage Control.

Voltage Control designs and facilitates innovation training, Design Sprints, and design thinking workshops, both in-person and virtual. Please reach out to us at hello@voltagecontrol.com if you want to talk.

The post Outcomes, Not Methods: Create a Meeting Agenda to Prevent Method Bias appeared first on Voltage Control.

When you view your business through the eyes of a customer, what do you see? That is what a design thinking approach to business is all about–creating ideas to address customers’ unique needs and desires; everything is viewed through a human-centric lens.

A design thinking approach goes beyond thinking about the product or service itself and asks what the human need is behind what’s being offered. This deeper level of thinking is central to entrepreneurs and businesses that want to generate bold and innovative ideas. A successful business is successful because it adequately serves people by providing a solution to their wants and needs. The entire design thinking approach is interactive–you want to be in constant awareness of your target market and their changing needs. 

“Design thinking is a mindset, not a toolkit or a series of steps.” -Arne van Oosterom

The following prompts are a guideline for integrating the design thinking approach into your business. They will help you stay conscious of the target audience and how to best serve them throughout the innovation process. 

Start our Design Thinking Foundations course today!

Learn and practice Design Thinking to help your team solve problems and seize opportunities.

Get Started

Who is your target audience? 

In order to best serve your audience, you must first understand them. Clearly identify your client/customer base. This includes narrowing down the demographics of the group as well as observing them and their behaviors. Why do these people behave in the way that they do? What problems are they experiencing? Why are things the way that they are? What is working well, what is not working well, and why? Inquiring with an open perspective and learner’s mindset will help you better understand the world at large and how you and your business can contribute to it in a truly meaningful way. 

What do they want or need? 

To fully understand people, you must know their wants and needs–what drives them? What problems stand in the way? These two questions are the heart of the design thinking approach. Get to really know people; talk to your target audience. Conduct user interviews. Gather as much information as possible. When you know what people desire as well as cleary defined roadblocks that are in the way of achieving those desires, you can find and offer those solutions. 

What is the problem you want to solve?

Reflect on your observations to gain clarity about the specific problem you wish to solve. What common themes do you see? Group and cluster like-ideas. Then, synthesize the information–this process will help you identify the most prominent problem that needs to be addressed. While you may want to, you can’t solve all customers’ problems. Center your energy on one impactful issue; do one thing well versus tackling multiple solutions. The end goal of this phase of the design thinking approach is to convert the defined problem into a tangible, human-centered statement, rather than focusing on technology, monetary returns, or specifics of a product. Remember, it’s about the people you want to help!

What are the possible solutions?

You know your target audience, their wants, needs, and the obstacles that they face, now it’s time to ideate solutions. Brainstorm, think creatively. There are infinite solutions to solving any problem. Design thinking is creative problem-solving, and it’s at its best in this stage. Challenge yourself to think outside of the box. How can you solve the issue innovatively? How can you best serve the people in need? 

How can you give your idea legs?

Take your top idea(s) from ideation and design a prototype; bring it to life. A digital or physical prototype springboards you from ideation to the material realm of reality. Creating a scaled-down version of the solution in question allows you to get feedback from users in your target market–critical to maintaining a design thinking approach. You will identify the solution best suited to solve the problem through trial-and-error. 

How do customers feel about your product? 

Test the solution(s) by sharing your prototype with consumers and get their feedback. It is an essential opportunity to make sure that everything about your idea is centered around the people who will be using it. Both positive and negative feedback is valuable here–use the information to flush out the details of your design and refine it as needed. Listening to the feedback is how you build the best prototype possible and ensures that the final product you launch is aligned with your target market’s needs and desires. 

Note: the design thinking approach is an ongoing process. Even after you launch your product, it’s imperative that you continue to observe and listen to the users. Their wants and needs may change and you will then want to refine your product accordingly. 

Your intention for business changes when you view it through the lens of the customer.

The end-user is top-of-mind and informs every decision that you make when you are focused on serving them. The design thinking approach is a powerful mindset that will transform your business and, in turn, the world around you. We contribute to a better world when we authentically serve others. 

Looking for training in the Design Thinking methodology?

Voltage Control offers a range of options for innovation training, design sprints, and design thinking facilitation. Please reach out to us at hello@voltagecontrol.com if you want to talk.

The post The Design Thinking Approach to Business appeared first on Voltage Control.

As consumers, we have our tried-and-true, reliable, and essential products that we use and rely on to enrich our lives and help us face and solve our daily challenges. They bring us joy, security, ease, and greater productivity. We also all know what it’s like to be frustrated by a product malfunction or absence of a component we’d like it to include to truly meet our needs and desires; that extra thing that would save us time, money or effort or increase our pleasure. The user experience is everything. It’s why we continue or discontinue to purchase certain products. That’s why understanding it through user interviews and directly designing for it in the making of a product is essential to customers’ satisfaction and the product’s success. 

User interviews are an increasingly popular way to gather user feedback quickly and easily and include it in the design of your product. They specifically focus on learning user perception of the product or service, versus its usability. Unlike focus groups, which source opinions from multiple users at one time, user interviews are one-on-one sessions to get to know the user’s perspective deeply. 

If you don’t talk to your customers, how will you know how to talk to your customers? – Will Evans, Design Thinker in Residence at NYU Stern

So when and how do you utilize user interviews? We break it down below: 

When to implement user interviews

User feedback is incredibly valuable. It can help advise the development of a product’s design in various stages of the design process. User interviews can be utilized in the following:

1. Before a design is created to enlighten product and workflow ideas
2. During the ideation phase of development to help inform the product’s purpose and usability
3. Throughout early concept development to collect and prioritize functional needs and challenges

How to conduct a user interview

1. Identify your customers

It is critical to interview people in the target audience you are designing for so that you can adequately understand their concerns and feedback and apply it to your design to best serve them. Who are the people that will be using the idea you are designing? They should be the participants in your user interviews. For example, say you are designing a fitness app for friends to workout together virtually. You would want to seek feedback from people who have an interest in fitness, who are seeking community, and who have a smartphone and an accommodating setting to workout out in.

2. Identify the interview objective

What do you or the stakeholders hope to learn from the user interviews? Identify a specific goal. Be careful not to make it too broad like to “identify what the user likes.” This is limiting because the results will not clearly address the questions you are hoping to answer about your design. Instead, identify a concrete goal that is based on a specific attitude or aspect of the end-user you would like to distinguish and cater to. A finer focus will also help you to create compelling and informative interview questions and conduct the interviews most effectively. 

3. Prescreen interviewees

Once you have identified your target audience, it can be beneficial to conduct a pre-screening to reduce numbers to a manageable size before engaging in a full user interview. Establish your criteria–what qualities/interests do people need to have to qualify? Preliminary questions that are given through an online screener, for example, help you to identify which candidates you would like to move forward with. An example question could be, “Are you interested in virtual workout programs?” Those who respond with a “no” will automatically be eliminated, reducing the number of potential participants. Ask additional questions to weed out people who do not fit the target audience criteria and create a finer focused group that does. 

4. Carefully craft interview questions

The best practice is to prepare interview questions beforehand that are thought-provoking, open-ended, nonleading, and support the identified objective. Ask interviewees questions that cover as many topics as possible to paint a clear picture of the information you are seeking. Avoid framing questions that can bulldozer over the opportunity for participants to express how they truly feel. For example: “Companies are exploring ways to offer workouts you can do at home but have the support of a community. That must make you excited, right?” Asking in this way implies that the participant is already excited. Perhaps they’re not. Guiding questions like this leave little room for interviewees to fully communicate their thoughts, which will alter your data. Sticking to neutral questions like, “what do you think about this?” will eliminate any potential filters that could affect interviewees’ responses.

5. Create a comfortable environment for the users

When people are relaxed, they are more likely to build a greater connection and trust with the interviewer and therefore will be more willing to talk openly and honestly. This type of dynamic delivers the best results in user interviews. A comfortable environment can be created in various ways. Start with unrelated, easy to talk about questions about the interviewee’s daily life, for example, to ease into a natural conversation. Then transition to questions related to obtaining your goal. What are the interviewee’s desires and dislikes about the product design? Next, return to rapport with questions about their interests, hobbies, and demographics. This will lighten the conversation and also provide you with additional context and information to identify any possible patterns that could be useful to consider for your design. 

5. Adapt and be flexible

Not all interviewees are the same, and you shouldn’t treat them as one unit. They are individuals with unique interests and backgrounds, therefore they will likely respond to questions differently during the interview. With that in mind, it’s important to avoid strict scripts when asking questions and adapt to the individual. You may need to alter a question or deliver it in a different way that is compatible with their understanding. They may need additional prompts or explanations. Listen to the interviewee and respond appropriately. It’s also important to note that while it is okay to guide participants, don’t lead or influence them to deliver a certain response. After all, their ability to respond and authentically share their needs, desires, likes and dislikes with you is vital to understanding how to best serve them.

6. Incorporate the results in the product design

The results of the user interviews will inform you if users find your product valuable. By observing the data, you will be able to identify the top priorities and problems that users currently have with your design, and if your product is truly needed. The data will also reveal any competitors. Often users will use other products or companies as references. This is a great opportunity to learn more about the competitors in your field, what they are doing, and how to make your design different. Hearing what users value and find important will also show you if your design truly meets their needs. If not, the data can direct you to other potential uses of your design to better address the user’s wants and needs. 

User interviews are an effective and time-saving tool to adequately understand how users feel, think, and perceive the world. An intimate snapshot of the user’s experience in daily life and how your product design can help them or satisfy their needs is essential to creating a product that truly serves them. No matter where you are in your design process, user interviews are a lucrative asset to creating the best product possible. 

Want to know more about how to implement design thinking?

Voltage Control designs custom engagements for clients, including design thinking workshops, innovation sessions, and Design Sprints. Please reach out to us at info@voltagecontrol.com for a consultation.

The post 6 Steps to Conduct User Interviews appeared first on Voltage Control.

In Richard Banfield’s book Enterprise Design Sprints, he talks about how Design Sprints have become “a trusted format for problem-solving at many large companies.” As the sprint’s popularity has increased, I’ve noticed that some organizations and consultancies are eager to tweak the Design Sprint process. Sometimes, that means running abbreviated or compressed sprints — trying to do the same thing in three or four days instead of the classic five.

The way that Jake Knapp originally outlined the Design Sprint process in Sprint is prescriptive and in the best way possible. It takes place over five days — a full work week. Each day has a particular set of activities; the methods walk you through gathering insights, problem framing, prototyping, and user testing.

So, why are people turning to shortened Design Sprints? Are three or four-day sprints a wise choice? Let’s explore the perceived benefits and downfalls of a quicker Design Sprint. Plus, I even got Jake’s take on three, four, and five-day sprints.

Spoiler alert: I’m a proponent of giving your Design Sprint the full five days.

The Allure of the 3 & 4 Day Design Sprint

Because everyone is hyper-busy these days, it’s unsurprising that companies want to run a Design Sprint in three or four days instead of five. It’s almost impossible to align calendars for a one-day workshop. Now you want five full days?! I get it. As a Design Sprint facilitator, people often come to me asking for a shorter format. It’s tempting— a shorter sprint may seem like a more realistic investment of time (and money). But, when you’re talking about Design Sprints, I don’t think it’s as simple as working faster and jamming more into every day.

When you’re talking about Design Sprints, I don’t think it’s as simple as working faster and jamming more into every day.

In a three or four-day Design Sprint, something has to drop off the agenda. Typically, this means that people skip prototyping or user testing. In my opinion, if you aren’t prototyping and testing, it’s NOT a Design Sprint. One of the most powerful aspects of the sprint is testing your ideas and assumptions through a prototype and hearing directly from your users. When you skip either of those steps, you cut out the moments that provide authentic direction, give voice to your users, and ensure that you’re not just navel-gazing.

“I always try to run five-day sprints because the ideas are deeper. Four days or less feel rushed and have less opportunities to uncover the boldest and most innovative ideas.” —Steph Cruchon, Design Sprint LTD.

When clients approach me about running a shorter sprint, I typically suspect a couple of issues could be at play. First, it indicates that they might not have a big enough problem in mind for their Design Sprint. If a challenge is large enough, the budget for a five-day Sprint should be there. It’s that important. Secondly, it tells me that they might not have total buy-in that this is an effective process or way of working. They’re hesitant to go all-in because they think it might not “work.”

Finally, the desire for a short sprint sometimes indicates that the organization isn’t planning on including a diverse team in the process. I’ve seen three and four-day formats based on the idea that the design team will build the prototype while the internal team is working on the rest. To drive ownership and buy-in, you have to involve everyone and keep them engaged. Otherwise, you’ll end up with a team simply pushing someone else’s work.

Is It Really Only Three or Four Days?

Another thing to be aware of with consultants or companies that promise and sell three or four-day sprints: it actually ends up being up to eight days of work. That’s because they shift some of the activities to take place before the sprint (i.e. a problem framing workshop ahead of the sprint) or they take care of some of the heavy-lifting—like prototyping—behind-the-scenes. Additionally, they might ask you to run a second, shorter sprint the week after the first sprint.

There’s not anything inherently wrong with these modes of tweaking the sprint. But, at Voltage Control, I like to focus on skill-building and transformation through the sprint process. If we take on some of the activities or “burdens,” instead of insisting that our clients do them, I think something fundamental is lost. By fully participating in the sprint from soup to nuts, our clients understand the process deeply and get the most out of the week. Next time, they might not even need our help.

The Many Benefits of a 5-Day Design Sprint

I understand why the full 5-day Design Sprint is a harder sell. There are complex schedules to coordinate and clear. A team is missing their day job for an entire workweek. There’s significant upfront work to gather your data and research. You might rent an offsite space to hold the sprint. You might need a professional facilitator. It’s challenging. However, I believe it’s worth it to push through the logistics and fear of the time investment.

Start our Design Thinking Foundations course today!

Learn and practice Design Thinking to help your team solve problems and seize opportunities.

Get Started

The Design Sprint was first perfected at Google, over time and with different teams and scenarios. In short, it works. Every ingredient is there for a reason.

First, the five-day Design Sprint is a well-designed, tried-and-true process. It was initially perfected at Google, over time, and with different teams and scenarios. In short, it works. Every ingredient is there for a reason.

As you might expect, when I asked Jake Knapp about his feelings on the five-day sprint, he’s still a proponent: “Five days is the most robust. I believe I can deal with anything that comes up in a five-day design sprint. Even without pre-work, I know we’ll learn something valuable by Friday.”

Second, the five-day sprint provides adequate time for two of the most critical aspects of the week. There is a full day for prototyping and a full day for user testing. (And, trust me, this will still feel rushed.) These activities are likely the ones your team needs most. Rapid prototyping is an important skill, but one that not many companies utilize often. Similarly, many companies talk to users, but not enough as they should.

“I see the Sprint like an iceberg. A lot of the magic happens below sea-level, e.g. the organizing that goes into setting up a Sprint for success both prior and post. It isn’t a silver bullet that means you are ready to launch. It is an exercise designed for learning and mitigating risk from product/service development.” —Dan Levy, More Space for Light

Lastly, it’s about flexibility. The five-day schedule leaves enough room for the unexpected to emerge, or for things to shift and tweak. The first two days are somewhat loose, but they are vital for opening up conversations and spurring the thinking that needs to happen within the group. When you cut off one or two days from your sprint, there’s a lot less time to change course or dig into something surprising.

Shorter Sprints Can Work…IF

While I’m pushing hard for companies to take the leap and invest in a five-day Design Sprint, it doesn’t mean there aren’t exceptions. In my new book, Beyond the Prototype, I share a story about The Home Depot. They’ve developed a practice of three-day sprints. “We’ve adapted the traditional five-day Sprint to work more efficiently inside Home Depot’s culture,” Eugene du Plessis, Senior UX designer said. “Getting everybody in a room for five days is close to impossible.”

However, I believe that they can run shortened sprints successfully because they’ve customized slowly, and only after mastering the sprint practices as designed. Brooke Creef, UX Manager at The Home Depot, shared: “What has gotten us so much success is that we customize slowly. We were very firm in staying as tried and true…and not as flexible with agendas until we matured.”

“What has gotten us so much success is that we customize slowly. We were very firm in staying as tried and true…and not as flexible with agendas until we matured.”—Brooke Creef, UX Manager, The Home Depot

Similarly, Google runs Design Sprints of different lengths and flavors. And, like The Home Depot, I would argue that Google has “earned” the right to play with the model. They’re working from a strong foundation and are a highly-mature organization in terms of design and innovation.

Jake shared his thoughts on three-day Sprints, and Google’s in particular: “Three days is super intense, and I wouldn’t sign up for it myself. If you look at Google’s three-day Design Sprint, keep in mind they have lots of designers and researchers, many existing products to pull design patterns from, and they have material design. They’ve spent many years specializing in the Design Sprint for Google. But if you’re not at Google, be careful and consider all the resources and trade-offs required to make a three-day Design Sprint work.”

He also shares my feeling that four-day sprints might be doable, especially if the team has more experience: “I find four days works best if the facilitator is really experienced, or if the team has Design Sprint experience. Pre-work becomes really important.”

“I find four days works best if the facilitator is really experienced or if the team has Design Sprint experience.” —Jake Knapp

Conclusion: The 5-day Design Sprint is your best bet in most cases.

Design Sprints can be a path to transformative organizational change. But, there is no shortcut to outcomes. If you’re new to Design Sprints, I strongly recommend starting with a five-day sprint. It ensures that you hit all the critical activities. It also gives you the momentum and focus to continue what you’ve started after the sprint. (BTW, that’s what my book is all about — avoiding the post-sprint slump and how to transition from ideas to outcomes.)

Design Sprints can be a path to transformative organizational change. But, there is no shortcut to outcomes.

Don’t short change yourself or your team. Invest in a five-day Design Sprint. Ideally, at the end of your five days, a light bulb will go off, and you’ll realize that you can work in this style any day of the year.

The post 1-Day, 2-Day, and 3-Day Design Sprints. Do they work? appeared first on Voltage Control.