Preventing the Executive Swoop and Poop with Design Sprints

Originally published on medium.com on January 4, 2016.

We’ve all seen it. That moment when a high-ranking, influential executive suddenly takes our design project off the rails. They burst in with their ideas blasting about who they think the design is for and what it should be.

It doesn’t matter how hard the team has worked on their design. It doesn’t matter what research they’ve done. The highest paid person in the room has a “better” approach and that’s all that matters.

The team just experienced another executive swoop and poop. Like a seagull on the attack, the executive has swooped into the project and pooped all over the team’s design. Flying away as fast as they came, they left carnage and rubble in their wake.

A Symptom of A Bigger Problem: No Shared Understanding

While there is the occasional rogue executive who flies around big organizations cutting their path of disruption, most of the time this is a symptom of a bigger issue. It comes from the team not laying the groundwork to get all the important influencers on the same page about the design.

There may be others without shared understanding. They come into the middle of the project with different expectations. Most of the time, the team can dismiss the concerns of these uninformed folks. However, when someone with substantial position power (like an executive) marches in with different perceptions about the project, it’s hard to ignore. Swoop and poop.

The good news is swoop and poop events are preventable. Design Sprints are a popular process that gets the team, including important influencers, on the same page early in the design life-cycle. Through a series of structured exercises, the team identifies critical assumptions, creates a prototype, and validates their ideas, all within a single week or so. The result is a shared understanding of what the team is building and why.

A typical design sprint takes about a week (though some folks stretch them out and others have figured out how to do smaller versions in less time). A team of participants assemble from various roles and perspectives in the organization. They define and unpack a problem that needs solving. They generate ideas and decide which ones to pursue for testing. They build a prototype of their ideas, then validate their assumptions by observing people using it.

In that week, they’ve taken a deep dive into a problem and validated key ideas around it. More importantly, this crew now has a shared understanding, based on real data collected from real users. They can spread that understanding, delivering the insights they’ve gathered to the rest of the organization, including the likely future swoop-and-poopers.

While there is variation to how you execute a design sprint, they all share five common phases:

Understanding Phase: Answer the import questions and surface our assumptions. What’s the problem we’re trying to solve? What assumptions are we making? Who are we solving the problem for?

Brainstorming Phase: Generate as many potential solution ideas as we can, exploring the different dimensions of the problem in the process.

Deciding Phase: Home in on the best ideas, increasing our understanding of who we’re building for and why.

Prototyping Phase: Render a working version (even if it’s all smoke and mirrors or just a paper mock-up) of the best ideas in a plausible design to test our assumptions.

Validating Phase: Put our prototype in front of real users, and watch them give it a spin. We validate our assumptions, learning even more about their needs.

The nature of the design sprint is these phases happen very quickly, with a series of activities guided by a trained facilitator. The activities themselves are fun and productive, but the real value comes from their inherent qualities that lead to a shared understanding. It’s these critical qualities that help prevent future executive swooping and pooping.

Shifting Self Design to Activity-Focused Design

Self design is a decision making style where an individual makes choices based on how they’d want the design for themselves. It’s a common style for people who haven’t had much experience doing design, or when seasoned designers don’t have a lot of other information to go by. They put themselves in the role of the user and ask, “How would I want this design to work?”

Executives, without any of information, will often approach a design this way. If what the team has presented doesn’t match their own perception, they’ll questions the decisions and suggest their own alternatives.

In many cases where the executive’s attention is disruptive to the team, it’s because the team themselves have also used a self design approach to arrive at the current design. (Or worse, they used another style, unintentional design, where they hadn’t put much thought into the design at all.)

This is where a design sprint helps. The design sprint’s structure forces the team away from self design or unintentional design approaches. Instead, the team engages in activity-focused design, basing their decisions on researched activities of the user. When the team invites real users to try a prototype, they’re collecting data of what the users needs, which gives a more solid footing on what the design should be.

When the executive shows up, the team can present this data along with the design that emerged from it. Having real data behind the design decisions reduces the influence the executive can assert, and smart executives will embrace the approach.

Exposing the Team to Real Users

Teams who have regular opportunities to meet with, talk to, and most importantly, observe their users turn out better designs. We’ve found if team members spend two hours every six weeks watching their users, they bring that knowledge to their design decisions.

In our experience, the first exposure is the hardest for the team. Design sprints help tremendously, because usability tests are built into the process. Once a team has that initial influx of data, subsequent sessions become easier to execute. When the executive shows up to review the design, the team will have the data from their repeated exposures to bring to the table.

It’s even better if, while the design is evolving, the executive is also exposed to real users, along with the team. The executive will have their own exposure experience to draw on, instead of just relying on their own gut feelings about what the design should be.

Converting Requirements into Assumptions

The conventional approach for designing products and services starts with a list of requirements gathered from stakeholders and subject matter experts. The team then takes these requirements as truths, and tries to address them in their design.

The problem comes when the requirements turn out to be false. Unfortunately, because there’s usually no validation process built into the conventional design process, it isn’t until late (sometimes as late as when the product ships) that the team learns they went down the wrong rabbit hole.

Often times, it’s when an executive comes in for review that the team is first learning about problems with the requirements. While this appears to be a swoop and poop maneuver, it’s actually a course correction. Unfortunately, it’s happening too late in the process to be effective.

Using a design sprint approach, the team converts requirements into assumptions, then validates them. The assumptions are documented up front, prioritized, then as the sprint continues, tested against the realities of the world.

This gives the team fodder when they meet up later with the executive. They can intercept the swoop and poop in mid-flight, sharing what they learned from the assumption validations.

Neutralizing the Politics

It’s a bonus when the executive partakes in the design sprint directly. Not only do they see the rigor of the process, they can contribute their knowledge and experience first hand.

The beauty of the design sprint process is its special attention to neutralizing the politics in the room. Through each phase, the facilitator leads the activities using techniques designed to empower each participant, regardless of role power. Ideas and contributions from the sprint team’s lowest ranking member are equal to that of any executive or other high-ranking members.

A skilled facilitator makes this feel seamless and invisible. Everyone feels they’re being heard. More importantly, all ideas are open for equal consideration, making progress happen quickly and innovation more likely.

Because the executive contributed as part of the team, they’ll understand the underlying rationale of the design decisions. It’s a great way to prevent future swoop and poop operations from occurring.

Creating A Culture of Continual Learning

Trying out what seems like a great idea and discovering that you’re wrong is a fantastic way to learn. Doing it quickly and early in the process mitigates the risks associated with heading down the wrong paths, delivering more educational value to your organization at a lower cost.

Design sprints start with an innocent questioning of everything. Quickly your team learns that many of the assumptions you’d been basing their decisions on are not as rock solid as you thought. However, with each smashed assumption comes a new perspective on what the users need from the design.

Over the course of the sprint, a team learns a raft of new information. Smart teams don’t let that attitude of learning end when the sprint ends. Instead they build it into their culture, continuing to identify each new assumption and validate it, learning more as they go.

Building a culture of continual learning is probably the most valuable benefit of well-run design sprints. It doesn’t hurt that it builds the teams knowledge and confidence for when an executive shows up, ready to swoop. Knowledge about the users and what they’re trying to do makes for a solid poop umbrella.

Using Design Sprints to Prevent the Swoop And Poop

Design sprints aren’t the only way to prevent a swoop and poop incident. Nor are they guaranteed to stop them 100%.

Yet, the rising popularity of design sprints is warranted. They bring a lot of advantages to a team, delivering a shared understanding and solid basis of knowledge on what design they should be building.

When an organization integrates design sprints into projects, they see a dramatic decrease in outside influencer disruptions and an increase in their design quality. That a well-facilitated design sprint can help deflect an executive swoop and poop is just a very welcome extra benefit.