Screenwriter Markus McFeely dropped this gem in the director’s commentary of Avengers: Infinity War:

Scenes need to do more than one thing.

He acknowledged that the events of a scene need to happen, which is its primary reason for appearing in the story. But a scene can also do other things like set up a character conflict, inform you about some backstory or exposition, or somehow advance the plot point in another way—all things that McFeely suggests that screenwriters employ.

Even though I’m not making movies, I’ve found this technique to be invaluable to design system work. If you’re managing or leading a team or an initiative and intentionally and strategically structuring roadmaps and projects for your team to work on, you’re crafting a narrative about what work is and isn’t important at any given time.

Many design system teams choose a specific component to work on for a simple reason: because feature teams needed. This typically sounds something like this: “We’re working on a card component because more than three feature teams at our organization need a card component in their upcoming work.” It’s simple and effective logic.

Yet some teams still struggle with component adoption after they’ve made the component. These teams—who trend towards being component factories—often operate on the binary logic that, if a component doesn’t get adopted, their work is not successful. While there may be some truth to that, you can eliminate that worry if you apply McFeely’s maxim: all component work must do more than one thing. How can the work, the process, or any other element advance the plot (your design system strategy)?

Here are some examples of component work doing more than one thing:

• Make an accordion component because teams need an accordion component, and also use the process as a excuse for two of your team members who don’t get a chance to work together to collaborate.

• Make a table component because teams need a table component, and also use it as a trojan horse to work with a new division at your company that hasn’t used the design system much.

• Make a typeahead component because teams need a typeahead component, and also use it as a way to find favor with a VP whose teams have been struggling with high-quality form interfaces.

• Make a native iOS alert component because teams need a native iOS alert component, and also use it as an excuse to practice working across multiple platforms.

• Make a card component because teams need a card component, and also pilot it with a subrand to explore theming.

Let your component work do more than one thing. Find worthy projects within your design system projects. Even if the component doesn’t get adopted right away (or ever), you’ll still get major benefits for having worked on it.