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.

A Design Sprint is a tried-and-true method that can help you jumpstart a project at work. It is a five-day process where you dissect a business challenge through a set of powerful activities. Design Sprint activities are carefully planned and executed to lead the group to their end result: a rapid prototype that has been vetted with real customers. The implementation of each design sprint activity helps you accomplish a month’s worth of work in a week.

The Design Sprint was initially developed at Google Ventures as a process for “answering critical business questions through design, prototyping, and testing ideas with customers.” It’s an excellent way to push through confusion and inertia to come up with new ideas and find out quickly if your customers might respond positively to them.

Why do we need Design Sprints?

Most teams and organizations probably have a challenge that would benefit from a Design Sprint. But, if you’re wondering if it’s a good thing to consider, here are some scenarios that point to a strong need for a Sprint:

• You’re about to kick off a project or a new product, and you want momentum, excitement, alignment, and focus from the start.
• You’re in the middle of an initiative, and you don’t know where to go next.
• You haven’t talked to your customers enough, and your team feels stuck in an internal feedback loop.
• You think you need to pivot in your business or product model and want to explore the right way to go next.

Any of these scenarios are good reasons to hold a design sprint. Consider setting aside five days for a cross-disciplinary team to complete a Sprint. (Please don’t try to run your first Sprint in less than five days.)

Design Sprint Activities

One of the beautiful things about the Design Sprint is that it is a prescriptive (in the best meaning of the word!) week of events. You don’t need to wonder what to do. You don’t need to struggle to come up with an agenda.

This doesn’t mean a Design Sprint is “easy”; it does mean that the activities for each day are clearly defined so any team can jump in and run a Sprint if they take the time to read up on the process.

Do you need a professional Design Sprint facilitator?

Here at Voltage Control, we are professional Design Sprint facilitators, so it’s difficult to be unbiased when it comes to this question. We think teams can certainly run a design sprint on their own if they have one person on the team who wants to take the lead, do the prep and lead the group through all the activities. However, if you can make the investment, you might want to consider a professional facilitator. They can take care of logistics and making sure the team stays on track.

Preparation & Planning

Preparation and planning for your Design Sprint is the first step. Don’t underestimate the time that needs to be put into a Sprint before it even starts. It could take one to two weeks of someone’s time to get ready for a sprint. Here are some of the things you’ll do during this phase:

• Read the book Sprint.
• Secure a spot for your Sprint — on-site, or, even better, off-site.
• Buy Design Sprint supplies.
• Make your participant list. (Spoiler: more people isn’t better.)
• Plan for how you’re going to find research participants.
• Prepare the Sprint participants.
• (If needed) Engage a professional facilitator.
• Gather background research and data that might inform your Sprint.

Day 1 | Design Sprint Activities

The first day of your Design Sprint charts the course for the rest of the week and creates the focus.

Here are the activities:

• Create a long-term goal.
• Map the business challenge you’re tackling.
• Talk to internal experts on your team to get their perspectives on the challenge.
• Identify a target: agree on the specific part of your problem that you will focus on during the week

Day 2 | Design Sprint Activities

If day 1 of a Design Sprint is getting laser-focused on the problem or issue you face, the second day is when you begin to think bout how you might solve your problem.

Here’s an overview of activities for day 2:

• Gather inspiration: the team shares outside inspiration that might inform your solution (i.e., what are other companies doing that we love or might want to “copy”/remix?)
• Sketch: The group sketches ideas for answers using the Four-Step Sketch method. Drawing ability is NOT necessary! It’s more about the thought.
• Plan for customer testing: On Friday, you’ll be interviewing customers, so you also start work on that recruitment on this day (if you haven’t already.)

Day 3 | Design Sprint Activities

On the third day of your Sprint, you look at all of the solutions you’ve come up with and start to hone in on what you might prototype and test.

Start our Design Thinking Foundations course today!

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

Get Started

Here’s an overview of what happens on this day:

• Critique each solution: keeping an eye on which ones are best for achieving the goal you set on day one.
• Create a storyboard: mix and match your favorite ideas from all of the sketches and piece together a storyboard that will be turned into a prototype that you’ll show to customers.

Day 4 | Design Sprint Activities

The fourth day of a design sprint is when things get very exciting, and depending on your experience with prototyping — a bit scary or daunting. You’ll be making your storyboard into your prototype.

• Prototyping is the main activity for the day!
• Prepping for your user interviews. Make sure you have a user interview script as well as a method for taking notes.

Day 5 | Design Sprint Activities

The last day of your Design Sprint is the moment of truth. It’s when you show users your prototype and get their feedback. This is when you’ll learn if your idea has legs and you should run with it, or if you need to rethink things.

After the Sprint Activities

A Design Sprint might be a week-long, but the activities should spread into the week after — at the very least.

Some of the essential things to do after your Sprint are:

• Hold a debrief or retrospective with the group to define what you learned.
• Communicate to your larger org or team what you learned.
• Align on your next steps.
• Read Beyond the Prototype: We saw companies struggle in the post-Sprint world, so we wrote a whole book about it. Check it out for more details about what to do after a Sprint.

The post An Overview of Design Sprint Activities appeared first on Voltage Control.

Has your company told you that you are going to participate in something called a Design Sprint? Or, are you curious about how you might run one for your own team? In this article, we outline some of the basics of what happens in a Design Sprint workshop—what to expect each day, what you’ll learn, and how to have an effective, successful Design Sprint.

What’s a Design Sprint workshop?

A Design Sprint is a week-long process for tackling a business problem that was initially developed at Google Ventures. Over five days, the sprint takes a team through a design thinking-based process to uncover insights, prototype an idea, and test it with users.

The Design Sprint is covered in-depth in Sprint: How to Solve Big Problems and Test New Ideas in Just Five Days by Jake Knapp, Braden Kowitz, and John Zeratsky. This book is truly the bible on the method.

Why Should You Run a Design Sprint workshop?

• Align a team around a shared vision
• Answer critical business questions
• Discover the essence of a creative challenge or problem
• Cut through endless internal debate by building a prototype that your customers can give feedback on

When Should You Run a Sprint?

Design sprints are useful at many different stages of a project or product lifecycle. But, here are some great times to do a sprint:

• When kicking off a new initiative
• When looking for new breakthrough features for a product
• When you need to switch gears or iterate on a current product
• When you haven’t talked to your users enough

The Design Sprint Process

The Design Sprint is five days of focused workshops. It’s a tried-and-true formula, with clear plans and activities for each day:

• Day 1 | Map: Monday is about making a plan and getting focused. The first day’s activities help you define key questions, your goal, hear from internal experts and pick an area of focus.
• Day 2 | Sketch: The second day gets everyone’s creative juices going. But, instead of group brainstorming, the process prioritizes individual sketching of solutions.
• Day 3 | Decide: On Wednesday, the team looks at the potential solutions and works together to decide on what to storyboard and prototype.
• Day 4 | Prototype: On day four, the team creates a rapid prototype based on your storyboard, so you have something visual and tangible to test with users.
• Day 5 | Test: On the final day, you show your prototype to five different users in one-on-one interviews to gather feedback and get a gut-check on your possible direction.

“The big idea of the sprint is to take a small team, clear the schedule for a week, and rapidly progress from problem to tested solution.” — Jake Knapp, creator of the Google Ventures Design Sprint

What Do You Learn in a Design Sprint?

Some of the fundamental approaches to creative problem-solving that you digest through the sprint are:

• How to break down a complex problem into a focused target.
• The benefits of a diverse, cross-functional group when tackling a project.
• The power of learning through quick-and-dirty prototyping versus months of product development.
• The importance of showing your work to customers early to get actionable feedback.
• Plus, the need for collaboration, open-mindedness, divergent thinking, and empathy for the end-user.

Tips for a Successful Design Sprint Workshop

If you’ve decided to plan a Design Sprint, you can follow the agenda and activities as outlined in Sprint. But, through our experience running Design Sprints for people like Favor and Adobe, here are some of the things we’ve found critical for Sprint workshop success.

Start our Design Sprint course today!

Learn tips and tricks for facilitating a Design Sprint (whether it's your first or 101st) and for incorporating these techniques into normal meetings.

Get Started

Daily readout: One evolution we’ve made to the Design Sprint is the addition of a daily readout. Every day of the Sprint, we schedule a readout so the team can keep the larger stakeholder group informed. These are the folks that aren’t in the Sprint but need to know what’s going on. Be strategic about who’s on the readout. When the right people are in the loop, they’ll feel part of the process and you’ll avoid speed bumps down the road.

Stay on task: Your facilitator should be actively keeping people on task and engaged. They should also work to course-correct if someone is derailing the agenda or not participating. A skilled facilitator will make sure you are staying true to the Sprint questions, goals, and target that you set on Day 1.

Brain food: It might seem like snack micromanagement, but don’t overlook the importance of having healthy food on-hand for the team. Donut breakfasts and pizza lunches will inevitably lead to sugar crashes and post-lunch naps. Stock the Sprint room with things like nuts, fruit, protein bars and water to get people through the long days.

Facilitators are Your Friends

A final consideration: who is going to run or lead your Design Sprint? Is there someone on your team who can facilitate sprints, creative working sessions, or user testing? There is a ton of material out there on participatory design techniques, but being good at running them is another thing. It takes practice and time. Having someone with experience and expertise will bring better results if your plan has you continuing sprint techniques.

If you don’t have someone on your team or within your organization who can do this, you may need to bring in an outside coach or facilitator. Naturally, we’re wildly biased because we facilitate Design Sprints, but choosing the right facilitator for your Design Sprint is vital. An excellent facilitator is a mix between a party planner (they deal with logistics and scheduling), a sherpa (they guide the group through each activity), and a counselor (they have to know how to handle tough conversations). They may sound like a unicorn, but you can find one!

Looking for a Design Sprint Workshop Facilitator or Design Sprint Training? Get in touch.

Voltage Control facilitates design thinking workshops, innovation sessions, and Design Sprints. Please reach out at hello@voltagecontrol.com for a consultation.

FAQ Section

What is the Design Sprint process and why is it important?
The Design Sprint is a five-day process that helps teams tackle critical business questions by creating a realistic prototype to test with real users. This process involves cross-functional collaboration, enabling the sprint team to work through ideas with customers and answer crucial questions about a product’s development and potential solutions. It’s a powerful tool for speeding up the product development process and ensuring alignment with long-term goals.

How does a Design Sprint benefit cross-functional teams?
Cross-functional teams benefit from the Design Sprint by fostering remote collaboration and allowing input from a wide range of perspectives, including the design team, product manager, and sprint team. This collaboration creates a unified approach to answering key questions and results in innovative solutions for complex products, while keeping the entire team aligned on the project’s long-term goal.

What role do prototypes play in the Design Sprint process?
Prototypes in the Design Sprint serve as simple prototypes or more realistic prototypes to simulate user journeys and test potential user experiences. By involving real users in the testing phase, sprint teams can collect user feedback early on, ensuring that the final product is grounded in real-world usage. This allows teams to adjust quickly before investing heavily in development, making the process step more efficient.

Can Design Sprints be conducted remotely?
Yes. By using essential tools for remote collaboration, such as video conferencing and digital whiteboards, teams can engage in the same structured sprint process from different locations. The remote design sprint approach still delivers valuable insights, potential solutions, and user feedback while allowing for flexibility across time zones.

What are the common pitfalls in the Design Sprint process?
Some common pitfalls include not engaging with real customers early enough, skipping user feedback stages, or misaligning the sprint team’s goals. However, with expert interviews and a focus on realistic prototypes, teams can avoid these pitfalls by maintaining clear communication, addressing critical business questions, and ensuring the product development process remains on track.

How can a Design Sprint improve a customer journey?
A Design Sprint improves the customer journey by focusing on user experiences and answering key questions about how a product interacts with potential users. By mapping out the customer journey, sprint teams can ensure that the finished product aligns with the needs of real customers, offering an innovative, user-centered solution that drives long-term success.

The post What Happens in a Design Sprint Workshop? appeared first on Voltage Control.

Design thinking is a way of working that companies are adopting as a way to drive thoughtful decisions, greater collaboration, and better results. But what exactly is design thinking and why is it important to train your team in these methods?

What is design thinking?

To put it simply, design thinking is a way of approaching problems and tackling complex business challenges that places the end user at the center of all decision making.

Organizations of all kinds — from Google to Procter & Gamble — work with the tenants of design thinking. The power of design thinking and its ability to drive real impact has led to companies of all kinds to seek out design thinking training for their teams. Knowing the essentials of design thinking is more important than ever in many fields, even if you aren’t a designer.

According to IDEO U (one of the experts in the field), the three essential aspects of Design Thinking are: empathy, ideation, and experimentation.

What does it mean to be human-centered?

When you read the phrase design thinking, another one—human-centered design — will likely follow closely. Human-centeredness and design thinking go hand-in-hand.

User needs should be the “north star” or driving force behind your solution.

Being human-centered means that when you design your experience, product, or service, you create it from the perspective of your end user. (The term user-centered is another one you’ll hear a lot. It is basically interchangeable with human-centered.) In other words, with design thinking you don’t design things based on hunches, gut reactions, or rigid business needs. You start by finding out what your users, customers, or “humans” want and need. These user needs should be the “north star” or driving force behind your solution.

As mentioned above, many organizations today are engaging experts to train their teams in the methods of design thinking to help evolve and transform their work. Read on to find out why the human-centered approach works.

Why companies are engaging with design thinking training:

1. Design thinking training unleashes creativity

Through design thinking training, employees are encouraged to think differently and reject “business as usual” attitudes. Design thinking teaches people how to come up with new solutions based on user insights. This process is called ideation (think: lots of sticky notes and whiteboards).

In our day-to-day work, we can get caught up with the way things have been rather than how they could be. When we teach team members new ways of working and solving problems, we unleash the creativity and fresh thinking that may have been lying dormant.

2. The best innovation comes from inside

Companies can hire outside consultants to come in and tell them how to innovate or change their business. “Outsiders” can definitely bring a new perspective. At the same time, there is also tons (maybe more) of potential for innovation within your existing team.

Your employees know your business and politics better than anyone. They know how to make things happen and who to partner with. When you train your internal team in design thinking, you give your people the power to innovate around the things they better than anyone.

3. It encourages more collaboration

One of the fundamental aspects of a human-centered or design thinking approach is empathy and collaboration. People rarely innovate or have breakthroughs in a vacuum or completely by themselves.

A design thinking approach priorities cross-disciplinary teams coming together and bringing their skills together to create something better than they could have done by themselves.

4. Design thinking methods will change the way you think about anything

It’s tempting to think that design thinking training is only applicable to designers, design problems, or those who want to be designers. But, that couldn’t be further from the truth. Design thinking methods can be applied in almost many settings and companies and to any issue, both large and small.

When your team has design thinking skills, it impacts how they tackle key projects, but also how they do just about anything. You’ll find that the design thinking mindset encourages teams to think differently about big challenges, but even how you run meetings or design your workspace.

5. Design thinking is an essential 21st-century skill

The skills that are important for working in today’s workplaces are changing. Now, it’s not just about having “hard skills” — knowing certain computer programs or having a specific degree. 21st-century skills are softer.

As Forbes points out, it’s things like problem-solving, communication, collaboration, creativity and innovation that are important right now. And these skills are baked into design thinking. When you teach design thinking to your team, you’ll give them these tools that they’ll need to thrive in any job right now.

How do I get Design Thinking Training?

Thinking you want to give your team the gift of design thinking training? Voltage Control has a set of services to engage teams and teach them about innovation, facilitation, and design thinking methods. Get in touch with Douglas at info@voltagecontrol.com if you want to talk.

The post Design Thinking Training: Why Human-Centered Approaches Win appeared first on Voltage Control.