In work and in life, we often have to make decisions without all the facts. When we identify a problem, we generate a shortlist of potential solutions, and we pick one. Whether or not our choice turns out to be the best one, we’ve committed some combination of time, money, and energy to it, so we can’t turn around. Set-based design, often written as simply SBD, is the practice of keeping design options flexible for as long as possible during the development process.

This is the opposite of “just picking one.” In SBD (Set-Based Design), teams identify and simultaneously vet possible options, committing to implementing a technical solution only after testing and validating assumptions. Set-based design is best suited for situations with a high degree of innovation or variability involved, or problems with immovable deadlines.

Set-based design helps teams stay innovative while reducing costs of development – a clear win-win for any forward-thinking organization. Learn the basic concepts of set-based design, and decide whether it’s right for your team’s development process.

LeanKit Free Trial : LeanKit Online Kanban Software

Sign up for a 30-day free trial and you and your team can start building online Kanban boards today. Experience for yourself how LeanKit supports continuous delivery initiatives, eliminates waste and improves your team’s delivery processes and speed.

Start your Free Trial: LeanKit Free Trial

Set-Based Design vs. Point-Based Design

Set-based design isn’t a new concept; it’s as old as Lean thinking itself. Toyota called it set-based concurrent engineering, a term which accurately explains how the set-based design process differs from traditional point-based design: In set-based design, teams engineer multiple options concurrently, eliminating options as they learn.

This graphic by Scaled Agile Framework illustrates the difference like this:

This diagram shows the conceptual difference between set-based design and point-based design approaches.
This diagram shows the conceptual difference between set-based design and point-based design approaches.

Teams tend to naturally practice point-based design; a person or group makes a decision and the team executes it, adjusting to circumstances along the way.

The problem with point-based design is that it forces you to commit to one design solution before thoroughly testing assumptions about other solutions. By the time you realize you have to make serious adjustments, it’s too late or costly to do so at the level that is necessary.

With set-based design, you can continue weighing all possibilities until you gather enough data to narrow down your options.

Set-based design has built-in learning points – places where a piece of data helps you eliminate another option. This enables a process where you actively select options with your desired specifications, rather than constantly adjusting to the situation at hand, creating a less-than-ideal result.

Set-Based Design vs. Point-Based Design: A Road Trip Example

This familiar example shows how set-based design can save a team time, money, energy, and stress:

Imagine you’re on a road trip with your family. You’ve been driving 2.5 hours and you’re ready to grab a bite for lunch. So as soon as the thought, “I’m hungry,” pops into your head, you take the first available exit. Shoot – there’s nothing here that your picky eater wants to eat. You get back on the highway, and repeat this process again until everyone is frustrated and hungry (and you’ve wasted a ton of time and gas).

So that process looks like this:

“I’m hungry.”

Decide to take first exit available and see what’s there.

Options aren’t great, decide to go to next exit.

Options are even worse! Decide to wait until the bigger town 45 miles away to stop for food.

Drive 45 more miles as everyone gets progressively hungrier.

Finally eat, but everyone is too frustrated to enjoy it.

Now imagine instead, when you think, “I’m hungry,” you ask your partner to look up your options in the upcoming few towns. You talk through the pros and cons of each as a family, take a vote, and decide on an option that’s just a few exits down. You enjoy your lunch without incident, get back on the highway, and continue your journey.

The second process feels smoother because it follows a logical process of elimination. It goes like this:

“I’m hungry.”

Decide to do research to determine: What are our options in the next 30 miles?

Eliminate several options immediately based on personal preferences.

Discuss remaining options and weigh pros and cons of each.

Select one option and plug it into maps app.

Eat lunch together as a family and get back on the road.

Look back at the graphic above – isn’t it amazing how often we commit to ideas before we have to?

Maximizing Design Efficiency

The road trip example demonstrates the idea of design efficiency. Design efficiency is a measure of flexibility, cost, and speed. Set-based design allows teams to maximize flexibility, cost, and speed:

  • Designs stay flexible throughout the development process. The team can adjust to new information as needed.
  • Costs stay low because teams work to test assumptions before investing in technical solutions.
  • Teams move with greater speed because they stay focused on a singular goal: Using data to select the best option.

In a point-based system, flexibility, cost, and speed are all variables throughout the development process. Teams are more likely to:

  • Invest quickly into a risky design
  • Have to rework parts of the design
  • Have longer cycle times due to lack of efficiency