Words shape the way we think and act. When it comes to design systems, the words we use can either drive clarity or sow confusion. Some words feel harmless at first but can introduce ambiguity, create misalignment, and stall progress.

Two of the biggest culprits? “Should” and “Could.”

The problem with “should”

How many times have you heard statements like these in a design system conversation? (Or even find yourself thinking these kinds of thoughts?)

Our design system should have these components in it.

We should document our design tokens better.

Product teams should be using our design system more.

On the surface, these statements sound reasonable. But dig a little deeper. “Should” often implies obligation without accountability. Even worse: “should” often reflects external influence, that because Google’s or Amazon’s or Shopify’s or Microsoft’s design system has specific features, that yours should too.

The trap of “could”

“Could” is another sneaky troublemaker. Consider these phrases:

Our design system could power our entire product set one day.

We could move to a single source of truth for design and code.

Our design tokens could be automated.

Where “should“ which implies obligation without action, “could” introduces possibility without priority. It makes ideas sound exciting but doesn’t drive commitment. Teams spend months dreaming about what “could” happen but become discouraged or paralyzed by the possibilities.

Better than “should” and “could” are “will” and “does”

What’s better than focusing on what your design system “should” and “could” be? Committing to what your design system will be and celebrate what it does.

Replacing “should” with “will” sounds like:

Our design system will have these 2 components in it by June.

We will add design token documentation around accessibility this month.

These 3 product teams will adopt design system by the end of the year.

The move from “should” to “will” typically tends toward a major benefit: a bias toward specificity, which often leads to better accountability.

Replacing “could” with “does” sounds like:

Our design system does power a quarter of our entire product set.

Our design system does act as a single source of truth for designers on our marketing teams.

Our design token library does contain automation within our CMS platform.

Design system teams are often overwhelmed by the sheer amount of work ahead of them. A useful antidote is to celebrate the good work that’s already been done.

Vision vs. action

I’m not suggesting that you eliminate any dreaming about possibilities for your design system. That’s an essential part of any product’s growth. A strong vision helps guide teams, inspire innovation, and align stakeholders.

But spending too much time in those realms exclusively without transitioning to concrete action can be dangerous.

Instead of primarily envisioning possibilities, create a clear roadmap:

• Define actionable steps that turn aspirational ideas into concrete progress.

• Assign ownership and timelines to ensure accountability.

• Regularly evaluate the balance between vision and execution to maintain forward momentum.

Vision is powerful, but it only creates value when paired with decisive action. Ask yourself: What’s the real commitment here? Swap vague words for decisive ones, and watch how your design system—and your team—becomes more effective.