Systems Thinking for Theming in Design Systems with Sam Gordashko

What do you do when someone says:

"We need light and dark mode across 5 brands for web and mobile. Plus users want to customize the UI."

Most teams freeze.
Others create another variable collection and hope for the best.

At the Into Design Systems Conference, Sam Gordashko shared a clearer and more scalable way to approach theming:
use Systems Thinking before you touch any tokens, variables or components.

This guide captures her full framework and explains how you can apply it to your own Design System.

🧠 Systems Thinking for Theming

One of Sam's strongest insights is simple:

Theming problems are not token problems. They are system problems.

Systems Thinking helps you understand relationships, influences, constraints and long term impact before you make structural decisions.

Here is how she breaks it down.

1. Zoom Out Before You Zoom In

Design Systems teams often jump directly into:

• variable tables
• JSON structures
• Tokens Studio
• plugin interfaces
• theme files

But none of these show relationships or influences.

Sam's mantra:
"Think outside the grid."

Before you structure tokens or build new themes, sketch a systems map that answers:

• What is influencing this theming challenge?
• Who is involved in making or consuming the theme?
• Where does data flow from and where does it go?
• What is the real business or product goal behind this request?

Example

Before adding a brand theme, map how:

• design
• engineering
• marketing
• product
• accessibility

all interact with the decision.

This prevents local decisions with global consequences.

2. The Past, Present, Future Canvas

Sam uses a simple but powerful canvas:

• Past: What is working? Keep it.
• Present: What is broken? Fix or prioritize it.
• Future: What is coming? Prepare for it.

Why this works:

• It exposes gaps in your current system
• It builds a shared mental model
• It aligns teams across silos
• It reduces random requests that do not fit the long term plan

This canvas leads to better theming strategies because everyone understands the same reality.

3. Distinctions: What It Is and What It Is Not

This step prevents messy scope creep.

Instead of reacting to vague statements like "add more personalization", ask:

• What is this work truly about?
• What is not in scope right now?
• What is unknown and needs clarification?

Sam's rule:
Focus on 5 to 9 chunks at a time.
If there are more, split the map or zoom in.

This protects your theming system from becoming a dumping ground for unrelated ideas.

4. Mapping → Structure → Naming → Delivery

Once you understand the system, you can translate your map into practical outputs:

➡ Token structure

Clear foundations that reflect relationships and not random categories.

➡ Naming conventions

Names that reflect meaning, not arbitrary words.

➡ Figma files and variable sets

Structure that scales across platforms, brands and themes.

➡ Documentation

Guides that help others understand, adopt and maintain the system.

This is a thinking first approach.

Do not start in Tokens Studio. Start in FigJam.

5. Theme Maps Help With Adoption, Not Just Architecture

System maps are not only for architects or senior designers.

They help:

• new team members understand the system
• engineers know where values come from
• designers remember naming decisions
• PMs understand limitations and tradeoffs
• leadership understand complexity

Maps do not ship. But they help you ship better.

Good maps reduce confusion, create alignment and drastically reduce Slack DMs asking "where does this value come from".

6. Systems Thinking Makes Scaling Sustainable

Sam highlighted an important distinction:

• Growth means more output with more resources
• Scaling means more output with the same resources

Theming is one of the strongest levers for Design Systems to support scaling.

Systems Thinking helps you scale your theming in a controlled and maintainable way.

It reduces chaos, prevents token duplication, and ensures that architectural decisions match real product needs.

👇 Bonus: Build Your First System Map

Sam suggests a simple process to get started:

1. Sketch the goal
   Example: support 3 brands on 2 platforms using one shared library.

2. List all influences
   Business, design, engineering, marketing, accessibility, product.

3. Draw relationships
   Show how each influence affects the others.

4. Define what is in and out of scope
   This creates clarity and avoids chaos.

5. Translate the map into structure and naming
   Use the map to guide your tokens, variables and file structure.

This process gives you a solid foundation before you make any technical decisions.

🗂️ Get Sam's Files, Maps and Full Replays

If you missed Sam's talk from the Into Design Systems Conference, the complete replay is available including:

• FigJam templates
• theme mapping examples
• naming frameworks
• real world workflows
• Q and A section

👉 Get access to the recordings and resources