In her book Thinking in Systems, environmental scientist, educator, and author Donella Meadows outlines what is and is not a system.

A conglomeration without any particular interconnections or functions is not a system ... stop dissecting elements and start looking for the interconnections, the relationships that hold the elements together.

How the components of your design system relate to one another is everything.

It doesn’t matter how detailed your button instructions are, or how you’ve organized engineering code snippets.

If the system doesn’t work together, you don’t have a system. You have a collection of things that may or may not be moderately helpful.

Connecting your “collection of things”

When you start looking for what’s shared, what’s common, and the connections between the components, you’re on the verge of implementing the early stages of an effective design system.

This is the point at which you start moving beyond learning the language of your supervisors or other key stakeholders in your organization.

Step 1: Tie the entire digital ecosystem together by designing dependencies in every website and application.

This isn’t about wresting control away from that “rogue” team that “does their own thing.”

Step 2: Connect design system goals and activities to larger and broader organizational priorities.

Failing to connect technology to the highest objectives of your organization will result in your work — your team’s work — being seen as isolated or secondary priorities or, perhaps even as “nice-to-haves” versus necessary.

Connecting design system goals and activities to larger and broader organizational priorities ensures that design systems efforts aren’t isolated or treated as secondary.

The more you infuse the design system with the regular and vital goings-on of the rest of the organization, the more wins you’ll experience there, too.

Step 3: Connect designers and engineers.

Designers can't help engineers if they've never seen a line of React code.

Engineers can't help product managers if they think release cycles are garbage.

When designers and engineers start to proactively schedule product walk-throughs with product managers, the magic begins.

A product walk-through begins fairly simply by tracking down emails of promising teams, product owners, and leads.

A process for conversations that foster connectedness

Start scheduling times — either on Zoom or in-person — for various stakeholders to walk you through their products. It’s as simple as, “Show me what you’re working on.”

Everything is relevant at this stage, whether it’s a product feature, a wireframe, or even sketches.

As part of this process, you’ll start cataloging some components and features. FigJam makes it easy to capture what you glean from these sessions.

For example, you have a meeting with the payments team and they’re walking you through their product. All you need to do is make a note of all the components you see.

At this stage, don’t get hung up on names, titles, or even format. It’s way too easy to spend hours figuring out which tool you should start building.

None of this matters. Keep it simple. Even Post-it notes work fine at this stage.

Now you repeat this process with the next team, and the next, and the next.

Bringing the heat (map)

When you’ve finished this process, you will have an inventory of all the components teams are working on across your company.

As your catalog grows, you’ll end up with a pretty accurate heat map, which helps you start tying things together into a definitive system.

Now it’s time to start building out a design system that will be useful — because you’ve begun the process of cultural transformation in your organization.

“But where do we begin?” is a question that gets most teams hung up. We’ll talk through that next time.