We start off so ambitious, don’t we?

When we start design systems, we look at the user interface disarray of our organizations, and we see possibilities. All of the things we can fix if only we had a good enough system. Too many incorrect variants of the main brand color. Random heading sizes. A lot of wheel reinventing.

So we try.

Some teams pick simple components that exist in many places, like buttons or text inputs. Other teams start smaller and try to establish some shared tokens for common categories like color or typography. Still others try to pick a larger component, like a product card or a login form.

Regardless of the starting point, design system teams that are lucky enough to last more than a few years find themselves inundated with lots of different things to manage: components, teams, partners, requests, bugs, improvements, tickets, and more.

In his popular book Getting Things Done, David Allen describes these things as “open loops:”

You’ve probably made many more agreements with yourself than you realize, and every single one of them—big or little—is being tracked by a less-than-conscious part of you. These are the “incompletes,” or “open loops,” which I define as anything pulling at your attention that doesn’t belong where it is, the way it is.

This describes a lot of typical design system work! You make color tokens for some web products, but you know someday you’ll have to figure out how to implement them on iOS and Android. You know it’s possible—that’s the point of tokens—but you don’t need to figure it out right now. Maybe in a year or two. Welcome to an open loop.

Components that you suspect will need more variations later. The MVP for composability that needs a few more teams to buy-in. That login prototype that uses that new JavaScript library you want to integrate. All of these are open loops, and design system teams are notorious at racking them up.

So whaddya do about them?

If you’re a new design system team just starting out, pick self-contained work that you can finish in a short amount of time. That’s probably a simple component, one that takes others a long time to create that takes your team a short amount of time to create. It’s probably something very specific like “Autocomplete search box for offices around the world“ that 5 or 10 teams can use, not that 1000 teams can use. Don’t pick anything “foundational” like tokens or buttons; these things are difficult to finish in a shorter timeframe than 12–24 months, so they continue to persist as open loops. Find things you can start and close in 2 week to 2 month intervals to build some momentum.

If you’re an established design system team with lots of existing open loops, devote some dedicated time to closing some loops. I’ve instituted a ritual with many teams called Systems Week, where the last week of every month is one where we’re not working with pilot teams and only working on closing loops. Six months of this will work wonders on your mental load.