Dissecting the Design Sprint Event

Step Four: The Outbrief

The finish line of a design sprint is the final outbrief. This last piece is when participants and decision makers see the results of the hard work everyone has put into finding a solution. The outbrief is an integration of everyone’s efforts during the event and includes all the design sprint elements: the refined problem statement, personas and scenarios, solution design, and all the pieces in between.

Vel Preston, AF CyberWorx Head of Innovation Design, describes the elements of an outbrief. Just as the event begins with the problem statement, the outbrief also starts with the problem. As Vel asks, “What’s the impact of the status quo?”

Stakeholders define the goal, but it’s the participants who explore the problem and determine how the status quo impacts the end users and, by extension, the mission. While the military mindset tends to put mission first, people enable the mission. As Vel explains, “We’re in the military. A lot of our problems revolve around lives at stake,” whether that means boots on the ground being supported by aircraft in the sky or personnel relying on finance for their paychecks. In exploring the human aspects of the problem, participants identify specific pain points to improve upon.

After briefers reiterate the problem, explain its impact, and outline the human element involved, they’re ready to lay out their solution. The ideal solution addresses the problem statement directly and pertains to the specific barriers and pain points identified during the design sprint journey. Vel explains that overall, “we want our listeners to follow the logic trail…Here’s what the status quo is, here’s the impact of keeping it that way, here are the things that’re getting in the way [of improving], and here’s how we can do it better.” The solution is the final piece that gives stakeholders a direction to a better future.

For the best response to an outbrief, participants should keep in mind more than just what the problem and potential solution is. Participants need to know to whom they are briefing. Ideally, they will be the person or people who can say yea or nay to the next steps. When that’s not possible, the person receiving the information should be someone who can become a champion for the solution to those who do have say. To help with this, briefers need to understand what information the decision-makers need. The team needs to consider and include that information. Some of that can include approximate costs, necessary resources, items to investigate further, and what parts of a solution are already in place to easily use.

Though the purpose of a design sprint is to come up with new ideas and solutions to solve or mitigate a problem, there are still limits to keep in mind. As Vel says, “It’s harder to get behind someone who wants to restructure everything.” Resources across the DoD are shared among a lot of projects, programs, and departments. If a team attempts to change the world, even if that is what is ultimately needed, their solution may not gain much traction.

Vel explains that the best received solutions are when the participants have drilled down to a single root cause that affects several pain points of the problem. “Because [a team] focused on the root cause…the integrated solution was more impactful and powerful.” If they focus on the right problem, the solution will have a large impact and be received well by stakeholders even if the root cause is relatively small and can be fixed with little effort and resources.

The outbrief is not the end, however. As Vel encourages participants, “The outbrief should be the beginning of change that everyone is asking for.” Viewing the outbrief as the beginning of change, instead of the end of an event, changes the perspective from one of presentation and after action to one of suggesting next steps and path to improvement. AF CyberWorx works to enable change and improvement. Facilitating events and guiding experts through the process to a solution is simply a vehicle to enable that change, not an end in itself.

*The postings on this blog reflect individual team member opinions and do not necessarily reflect official Air Force positions, strategies, or opinions.


Add new comment

Restricted HTML

  • Allowed HTML tags: <a href hreflang> <em> <strong> <cite> <blockquote cite> <code> <ul type> <ol start type> <li> <dl> <dt> <dd> <h2 id> <h3 id> <h4 id> <h5 id> <h6 id>
  • Lines and paragraphs break automatically.
  • Web page addresses and email addresses turn into links automatically.