The only thing I’ve ever heard Sam Altman say that was helpful was about notebooks. He uses A6 notebooks, which are small enough to carry anywhere, as ideas come at any time. He writes ideas and rips out the ones that suck. The notebooks have hard front and back covers and he goes through them every two to three weeks. His pen of choice is a Uni-Ball micro 0.5mm or Muji 0.36mm/0.37mm in dark blue or black ink.

That’s a pretty specific experience and a deliberate choice. Now that he’s made that choice, it’s documented. The internet does its thing, and that’s now shared knowledge between the millions of people who give a shit about this one thread of words. In 2026 however, the others who know are Claude, ChatGPT, Gemini, Llama, Grok, DeepSeek and all the other butthole logo AI models out there (I didn’t make this up it’s a thing)

This past week, I had the privilege of speaking at the Big Design Conference at the Palace Arts Center in Grapevine, TX alongside some remarkable design professionals.

Jeremy Johnson showed some brilliant concept designs for the future of chat experiences. Brandon Ward insisted that we all become generals on the product battlefield. J Schuh’s high fructose content talk hit the spot.

Still digesting all of the conversations about UX, design systems, big trucks, telepathy, weather patterns and brisket. A common theme was that great UX and engineering don’t vanish because an LLM can write a poem on the 17th prompt. Same job and the handoff is still the hard part.

The Old Handoff using Artifacts

A design system's job is to reduce communication time during the handoff process. Even if you design the most professional Figma files with red lines and specs, you probably still have to walk the team through and explain it over Zoom or Slack or both if you’re lucky. See: pretty much every tech company ever. So the communication might look something like this:

Hey Engineering, here are the specs for the new channel layout:
The main frame is 1462x1036, sub-nav is 980 high with accent/aubergine (#611F69), 20 radius top-left and bottom-left only. Threads & Drafts components depend on sub-nav components which depend on sub-nav components — you’ll figure it out.
For colors, we’re using theme-intent-purple-dinosaur-8 as the primary, secondary theme-smooth-jazz-1, accent is Miami-9 but we’ll think of a better name for it later — oh, and the VP of Wizardry might want to change it before we ship.
For type, headings use Railroad Monospace and body copy uses Juniper Fluoride.
Just check the Figma file — I added 78 spec annotations.

We dream of a system that is matured well enough to just be able to say:

Hey Engineering, here’s the BDS theme options for the new channel layout:

1. Density: comfy
2. Color: aubergine
3. Radius: default
4. Type: mono

A New Handoff with Agents

If we’re going to be generals on the product battlefield, we need to shorten communications between the design system and the agents too — not just between designer and engineer.

Markdown rules are one way. Pick the component your team argues about most and write the rules file for it- save some time for the designer who’s on like nine other projects. See: every tech company.

Rules

This is where we get hyperspecific. A6 notebook, hard cover, dark blue ink, 0.5mm. What we need are constraints an agent can follow. Here’s what that looks like for a complex interaction.

Rules files are a good start, but someone still has to maintain them — and they go stale.

MCP Exploration

Heads up: I haven’t actually implemented an MCP into a design system in practice yet.
So I built a small one. It reads from a fake design system called Banana DS — five components, some tokens, a couple of patterns and UX rules. Pointed Claude Code at it and asked it to build a payment-declined modal.

Claude Code uses the MCP for context, asking about Banana’s components and patterns. The MCP returns clear info about the system.

Next, I tried something more complex — I asked Claude to design a payment-declined modal for the subscription flow, then open a PR with the changes on GitHub.

That’s the kind of work that usually takes a Slack thread, a code review, and someone from the design system team explaining intent. The agent one shotted it because the design system’s MCP gave it the right context.

This isn't proof yet, it's a prototype. At the very least, faster answers should help save us from death by Slack thread.

(Where I started: Anthropic’s MCP docs and Figma’s MCP server)

The Design System has joined the chat. was originally published in Design Systems Collective on Medium, where people are continuing the conversation by highlighting and responding to this story.

“Design is not just what it looks like and feels like. Design is how it works.”

Steve Jobs

Reimagining Design and Development

Imagine a designer hunched over a monitor, locked in a battle with the same UI pattern they’ve used a hundred times. They’re aligning buttons, tweaking margins, ensuring pixel-perfect consistency. Meanwhile, a developer sits across the room, meticulously converting design files into code, wrestling with inconsistent specifications. Both share a familiar frustration — creative ideas left unexplored, buried under repetitive tasks and endless adjustments.

But what if design systems could break this cycle? What if they could not only eliminate the blank canvas but also streamline design-to-code translation, freeing up both designers and engineers to focus on creativity?

Design systems are typically seen as tools for efficiency, but their true power is in how they can expand creative thinking across the entire team. By providing conceptual UX and design patterns upfront, they enable rapid ideation and smoother handoffs. Developers gain from this too: they can rely on consistent components and tokens, reducing tedious implementation work.

At the core, consistency is foundational. Yet, consistency isn’t the end goal — it’s just the start of more meaningful work. When both designers and developers operate from a shared system, they move beyond maintaining uniformity to creating engaging experiences. The design system’s well-defined elements don’t just enforce alignment; they allow teams to dive deeper into storytelling, interaction design, and strategic thinking.

Designers get more time to explore user behavior, while developers can optimize UI performance and ensure seamless interactions. The shift is profound: it’s not just about delivering designs but building user-focused experiences together. The best design systems give you more time to think about the user, not the UI.

This collaborative process empowers teams to quickly iterate and test new concepts without getting bogged down by the basics. Imagine a carousel of UI concepts, each one rapidly prototyped and iterated using the same design tokens and variables. These consistent patterns can still support varied user experiences, pushing design boundaries.

Empowering Senior Professionals

Design systems shouldn’t be seen as a set of rules that limit creative vision. They’re tools that encourage senior designers and engineers to zoom out — to approach UX infrastructure strategically. By removing repetitive tasks and solving fundamental UX needs, design systems create space for more ambitious thinking.

For senior engineers, this means focusing on enhancing the system itself — like optimizing component performance, ensuring accessibility compliance, or integrating behavioral insights directly into reusable modules. This bigger-picture thinking aligns with the brand’s UX goals while supporting meaningful, user-centered design. The best innovations come when you stop thinking about pixels and start thinking about people.

Rethinking the Role of Design Systems

It’s time to challenge the perception of design systems as mere tools for faster delivery. They are vehicles for creativity, offering opportunities for deeper research, prototyping, and experimentation. The collaboration between designers and developers becomes more dynamic, fostering innovation. With clear structure and shared language, teams can move faster toward impactful solutions. Let’s stop delivering designs. Let’s start delivering experiences.

Imagine transforming a simple UI element into a cohesive user experience — one that’s driven by design tokens, optimized by developers, and informed by real user behavior. This is the essence of a well-executed design system.

Creative Empowerment

Design systems are not the destination; they are the path. They are not the limit; they are the starting point for creativity and innovation. They liberate teams from the mundane, making room for the bold. The system’s power lies in how it connects design to development, enabling cross-functional teams to think bigger and move faster. Design systems don’t make you less creative — they make you more free.

Design systems foster a more collaborative environment, breaking down silos between designers and developers, and ultimately leading to better, more holistic user experiences.

Design systems are evolving from tools of efficiency to enablers of expansive creativity and collaboration. They have the potential to transform not just how we build interfaces but how teams create, collaborate, and inspire each other. By focusing on the bigger picture, we can unlock design systems’ true potential — helping us build experiences that matter.

One of the biggest hurdles in advocating for design systems within organizations is demonstrating their business value. It’s not uncommon for sales teams to struggle with selling the concept of a design system, often feeling like they’re pitching thin air. Meanwhile, tech debt accumulates as fragmented designs and inconsistent components bog down development teams, leading to costly rework and maintenance headaches. This challenge isn’t just theoretical — it’s a tangible roadblock that often prevents organizations from investing in the very tools that could save them time, money, and resources in the long run. I faced this challenge head-on with a potential client, and here’s what I did about it.

Design System Value in Business Terms

While the benefits of a design system are clear to designers and developers — consistency, efficiency, and a unified brand presence — translating these advantages into business terms can be difficult. Organizations often struggle to see beyond the immediate costs of building a design system, viewing it as a long-term project with unclear ROI. Tech debt continues to mount as teams spend countless hours maintaining and fixing inconsistencies, yet the idea of investing in a solution feels like a hard sell without concrete data to back it up. The key to overcoming this challenge is to present a clear, data-driven justification that highlights the long-term savings and value that a design system can deliver, reducing tech debt and providing a solid return on investment.

Changing the Conversation to Cost Savings

To tackle this challenge, I shifted the narrative from always pitching efficiency to focusing on cost savings. Speaking in hours allowed me to appeal to the business side because that can easily be turned into cost. I developed a formula that quantifies the value of a design system over time by comparing the hours spent on standalone components versus those integrated into a design system. This formula became the foundation for a calculator that allowed us to project potential savings. First, let’s start by quantifying the cost of a single component to create a baseline cost.

The Real Cost of Building a Button

Consider the cost of creating a single component, like a button, for one project across a large organization:

• Initial Design and Development: $2,000 (20 hours at $100/hour)
• Testing and Revisions: $1,000 (10 hours at $100/hour)
• Ongoing Support and Maintenance: $500 (5 hours over the component’s lifecycle)

If the organization worked on 50 projects last year, each building their own button, the total cost would be $175,000:

(2,000+1,000+500) × 50 = $175,000

With a Design System

By integrating this button into a design system, the initial cost remains, but the integration cost per project is significantly lower, let’s say $200 per project:

2,000 + 1,000 + (200×50) = $13,000

This results in a cost savings of $162,000 in just one year — just on building a button component, illustrating the significant financial impact of having an entire library of standardized components will have.

The Simplified Formula

Total Cost = Initial Investment +

(Integration Costs × Number of Projects)

Using this approach, it’s easier to demonstrate the financial benefits of a design system by converting time savings into concrete dollar amounts, making a compelling business case for stakeholders.

Securing Stakeholder Buy-In

The Power of Data-Driven Decisions

Securing buy-in for a design system often requires demonstrating clear, tangible benefits. By using a formula to show the actual hours saved and translating those into financial terms, I presented a data-driven case that aligned perfectly with their business goals. This approach not only made the decision easier for stakeholders but also emphasized the critical role of strategic business thinking in the design process.

How I Calculated the Business Case for a Design System was originally published in Bootcamp on Medium, where people are continuing the conversation by highlighting and responding to this story.

Once again, Figma’s Config delivered some gold on optimizing design systems this year. I’d like to share some of what I learned and some fresh techniques on structuring components effectively and how to communicate m̶o̶r̶e̶ better to elevate the game. Let’s go…

Smarter Components and Styles

At the heart of an effective design system lies intelligently structured components and styles. This begins by thinking modular — splitting big components into manageable sub-component sets. It’s a must-have if you want to easily update and scale. If this approach feels familiar, you’re not wrong — it’s really starting to look awfully similar to front-end library code.

When working with components, it’s crucial to understand the distinction between variants and properties. Variants are visual representations, while props are editable attributes within the set. Clearly distinguishing these helps in managing the components more effectively. I like to think of it this way:

Variants are what you see, properties are what you tweak.

To keep your design system organized and easy to navigate, consistent naming conventions are key. The more cohesive this is, the more it aligns with types and other shared code. This consistency extends to how you order and group your components. Keeping related variants and props together minimizes complexity and enhances discoverability.

When presenting your design system to users, it’s important to surface only the essential elements. This focused approach ensures that only the most relevant patterns are highlighted, minimizing mental load for users. Show off the key patterns rather than getting bogged down in fine details.

In cases where you find repetition, don’t hesitate to override names. This helps in maintaining clarity and reducing redundancy.

Keep it clean and clear.

Leverage configuration options to customize and streamline component behavior, making them more adaptable to various use cases. Flexibility is key in a robust design system.

To further refine your process, consider using tools that allow for side-by-side comparisons of detached components with the original. This helps the design system team understand what was missing when the product designer changed the component. Behind the scenes, hiding variables that aren’t used in production (what we might call backstage variables) helps streamline the design process. Focus on what really matters.

Finally, don’t underestimate the power of scoped targeting. Utilize scoping in Figma to target specific properties for precise and efficient design adjustments to your DS.

Assembling a Crew

Building a strong design system isn’t a solo endeavor — it’s about assembling the right crew and fostering collaboration. Communication is important, and it should be a two-way street. Talk it out about those component props to ensure everyone’s on the same page.

Don’t wait for perfection before sharing your work. Share early and share often — this approach gets feedback rolling and allows you to iterate like a pro. As you build your team, identify design system enthusiasts. These champions are your secret weapon for adoption, so provide them with the resources they need to spread the good word. Think interactive onboarding experiences — after all, you can’t be everywhere at once.

Remember that recognition goes a long way. Make design system contributions count in reviews. This not only motivates your team but also reinforces the importance of the design system within your organization.

Design System Analytics and Health

To ensure your design system remains effective and relevant, it’s crucial to monitor its health and usage. Start by getting to know your users — dive deep into what they need. A cool idea from Figma’s design system team is to throw in some emojis in the component file’s comments — you can search for them later (😎😭👍👎⭐️🚫).

Monitor the usage of libraries, components, and detaches through library analytics. This helps you understand who’s using (or not using) different parts of your system. Keep an eye on the big picture too — make sure your design system aligns with company goals. This alignment helps garner more buy-in and potentially attracts more contributors.

Building and maintaining a design system is an iterative process. Plan, test, publish, and repeat. Don’t be afraid to retire those outdated components — sometimes, deleting is progress too. By staying vigilant about your system’s health and continuously refining it based on user needs and company goals, you’ll create a design system that truly serves its purpose and evolves with your organization.

That’s my inside scoop on leveling up your design system game. Crafting a resilient design system is about much more than just components and styles. It’s about building a robust ecosystem that includes smart architecture, effective collaboration, strategic scaling, and feedback-driven decisions.

Crafting a More Resilient Design System Process was originally published in Bootcamp on Medium, where people are continuing the conversation by highlighting and responding to this story.

A Developer’s Guide to Applying Themes from Figma Design Systems

Theming is not just about aesthetics — it’s about creating adaptable user experiences that align with brand identity and user preferences. As applications grow in complexity and scale, the need for a robust theming solution becomes paramount, especially when implementing design systems across various platforms and products.

This guide will walk you through the process of building a robust theme service that seamlessly connects Figma design systems to code. We’ll explore a practical architecture that allows for easy maintenance and runtime theme switching.

Some of the key parts to bring theming to life:

• Extract theme data from Figma using variables and variable collections
• Build a flexible theme service in TypeScript
• Implement theme and mode switching in your components
• Create a scalable theming architecture that works across different projects and platforms

A Sample Theme Architecture

Here’s a basic implementation of a design system theme model that we’ll use for this exercise. The theme consists of two distinct collections:

1. Primitive Scales: These are the raw values exported from design tools, typically representing colors, typography, spacing, etc.
2. Semantic Themes: These map semantic names (like ‘primary’ or ‘background’) to values from the primitive scales.

This separation allows us to maintain brand consistency through the primitive scales while providing flexibility in how these brand elements are applied across different product themes or modes. By using this approach, we can easily swap between semantic themes (e.g., switching from light to dark mode) without altering the underlying brand scales or modifying component code.
We’ll implement this architecture using CSS variables, enabling runtime theme switching without any unstyled content flashes. This method ensures a smooth, consistent user experience across different themes and modes within our application.Setting Up the Theme Service

Let’s start by defining our types and creating the basic structure of our Theme Service:

// types.ts
export interface ThemeScale {
  colors: Record<string, string>;
  fontSizes: Record<string, string>;
  // Add other primitive scales as needed
}

export interface Theme {
  primary: string;
  secondary: string;
  background: string;
  text: string;
  // Add other semantic properties
}

// themeService.ts
import { ThemeScale, Theme } from './types';

class ThemeService {
  private scale: ThemeScale;
  private currentTheme: Theme;

  constructor(defaultScale: ThemeScale, defaultTheme: Theme) {
    this.scale = defaultScale;
    this.currentTheme = defaultTheme;
    this.applyTheme(defaultTheme);
  }

  public setScale(newScale: ThemeScale): void {
    this.scale = newScale;
    this.applyTheme(this.currentTheme);
  }

  public setTheme(newTheme: Theme): void {
    this.currentTheme = newTheme;
    this.applyTheme(newTheme);
  }

  private applyTheme(theme: Theme): void {
    Object.entries(theme).forEach(([key, value]) => {
      document.documentElement.style.setProperty(
        `--${key}`,
        this.scale.colors[value] || value
      );
    });
  }
}

export const themeService = new ThemeService(defaultScale, defaultTheme);

This ThemeService class provides methods to set both the scale and the theme, and it automatically applies the theme to the document root using CSS variables.

Integrating with Figma

To bridge the gap between design and development, we’ll use Figma’s native variables functionality and the Variables to JSON plugin to export our design tokens. This approach ensures we’re working with the most up-to-date design system data.

Exporting Variables from Figma

1. Install the Variables to JSON plugin from the Figma Community.
2. Set up your variables in Figma using the native variables feature.
3. Run the plugin (Plugins > Variables to JSON).
4. Click “Copy JSON” to get the JSON representation of your variables.

The plugin output will look similar to this:

{
  "colors": {
    "primary": {
      "500": "#0066CC"
    },
    "secondary": {
      "500": "#5BBF3B"
    },
    "gray": {
      "100": "#F5F5F5",
      "900": "#1A1A1A"
    }
  },
  "typography": {
    "fontSize": {
      "small": "12px",
      "medium": "16px",
      "large": "24px"
    }
  },
  "theme": {
    "light": {
      "background": "{colors.gray.100}",
      "text": "{colors.gray.900}"
    },
    "dark": {
      "background": "{colors.gray.900}",
      "text": "{colors.gray.100}"
    }
  }
}

Transforming Figma Output

Now, let’s update our functions to transform this Figma output into our ThemeScale and Theme:

// figmaIntegration.ts
import figmaVariables from './figma-variables.json';

function flattenColors(colors: Record<string, any>, prefix = ''): Record<string, string> {
  return Object.entries(colors).reduce((acc, [key, value]) => {
    if (typeof value === 'string') {
      acc[prefix + key] = value;
    } else {
      Object.assign(acc, flattenColors(value, `${prefix}${key}.`));
    }
    return acc;
  }, {} as Record<string, string>);
}

export function createScaleFromFigma(figmaJson: any): ThemeScale {
  return {
    colors: flattenColors(figmaJson.colors),
    fontSizes: figmaJson.typography.fontSize,
    // Map other collections as needed
  };
}

export function createThemeFromFigma(figmaJson: any, mode: 'light' | 'dark'): Theme {
  const themeValues = figmaJson.theme[mode];
  return {
    primary: figmaJson.colors.primary['500'],
    secondary: figmaJson.colors.secondary['500'],
    background: themeValues.background.replace(/[{}]/g, ''),
    text: themeValues.text.replace(/[{}]/g, ''),
    // Map other theme variables
  };
}

const scale = createScaleFromFigma(figmaVariables);
const lightTheme = createThemeFromFigma(figmaVariables, 'light');
const darkTheme = createThemeFromFigma(figmaVariables, 'dark');

themeService.setScale(scale);
themeService.setThemeWithModes({ light: lightTheme, dark: darkTheme });

Using the Theme Service in Components

With our Theme Service set up, we can now use it in our components. Here’s an example of a themed button component:

// Button.tsx
import React from 'react';
import styled from 'styled-components';

const StyledButton = styled.button`
  background-color: var(--primary);
  color: var(--text);
  font-size: var(--fontSize-md);
  padding: 10px 20px;
  border: none;
  border-radius: 4px;
  cursor: pointer;

  &:hover {
    background-color: var(--secondary);
  }
`;

export const Button: React.FC<React.ButtonHTMLAttributes<HTMLButtonElement>> = (props) => {
  return <StyledButton {...props} />;
};

Notice how this component uses CSS variables that correspond to our semantic theme. This allows the button to automatically update when the theme changes, without any modifications to the component itself.

Implementing Theme Switching

To demonstrate the power of our Theme Service, let’s implement a theme switcher:

// ThemeSwitcher.tsx
import React from 'react';
import { themeService } from './themeService';
import { lightTheme, darkTheme } from './themes';

export const ThemeSwitcher: React.FC = () => {
  const [isDark, setIsDark] = React.useState(false);

  const toggleTheme = () => {
    const newTheme = isDark ? lightTheme : darkTheme;
    themeService.setTheme(newTheme);
    setIsDark(!isDark);
  };

  return (
    <button onClick={toggleTheme}>
      Switch to {isDark ? 'Light' : 'Dark'} Theme
    </button>
  );
};

This component allows users to switch between light and dark themes at runtime, showcasing the flexibility of our theming solution.

Implementing Mode Switching

While theme switching allows for changing the entire color palette, mode switching typically involves toggling between light and dark versions of the same theme. This is a common requirement in many applications for improving readability and reducing eye strain in different lighting conditions.

Let’s extend our Theme Service to handle mode switching:

// types.ts
export type Mode = 'light' | 'dark';

export interface ThemeWithModes {
  light: Theme;
  dark: Theme;
}

// themeService.ts
class ThemeService {
  // ... previous code ...

  private currentMode: Mode = 'light';

  public setMode(mode: Mode): void {
    this.currentMode = mode;
    this.applyTheme(this.currentTheme[mode]);
  }

  public getMode(): Mode {
    return this.currentMode;
  }

  public setThemeWithModes(themeWithModes: ThemeWithModes): void {
    this.currentTheme = themeWithModes;
    this.applyTheme(themeWithModes[this.currentMode]);
  }

  // ... other methods ...
}

Conclusion

By implementing this Theme Service, we’ve created a powerful, flexible system for managing themes in applications that use design systems. Some of the important parts:

1. Decoupling: Themes are separate from component logic, allowing for easy updates and maintenance. Themes have at least two distinct parts to them allowing you to separate brand from application of brand.
2. Runtime Switching: Themes can be changed dynamically without page reloads or component updates.
3. Design to Development: Direct integration with design tools like Figma ensures consistency between design and implementation.
4. Scalability: The system can easily accommodate multiple themes and scales for different products or brands.

Remember, great theming is an ongoing process. Continuously gather feedback from designers, developers, and end-users to refine your system. With this foundation, you’re well-equipped to create themeable, consistent applications that fully leverage your design system and provide excellent user experiences across all themes and modes.

A Developer’s Guide to Applying Design System Themes from Figma to React was originally published in Bootcamp on Medium, where people are continuing the conversation by highlighting and responding to this story.

Design systems have become our go-to for creating scalable, consistent experiences across products. But are we trading creativity for cohesion? At Figma Config this year, speaker Cam Worboys challenged us to take a critical look at design systems and their impact on our work.

The Speed Paradox

We’ve all heard the promise: design systems accelerate our workflow. But Worboys reminded us:

“Great design takes time.”

This simple truth often gets lost in the rush to implement and leverage design systems. While efficiency is crucial, it shouldn’t come at the cost of innovation. The challenge? Finding the sweet spot where speed and creativity coexist.

Cohesion vs. Commoditization

In 2024, managing design at scale without a system seems almost impossible. Design systems create trustworthy branding and maintain consistency. But there’s a catch:

“Design systems can’t prevent bad design decisions.”

The sameness accelerated by design systems risks making our products indistinguishable. So, how do we maintain cohesion without sacrificing uniqueness?

Embracing the Deliberately Different

To combat design homogenization, Worboys suggests expanding our design system expression:

1. Exploring diverse interaction and animation patterns
2. Putting typography at the forefront (custom fonts, anyone?)
3. Focus on what makes your product unique

Quality: The True North

Design systems alone don’t guarantee quality. As Worboys put it, “The building blocks alone aren’t enough.” Instead, focus on quality as an outcome of doing the right things.

Take Cash App’s approach:

• Foundations
• Components
• Patterns
• Product primitives
• Governance

Their plugin/widget architecture allows customization while maintaining a scalable system.

The Recipe for Greatness

Good products stem from a clear vision, great ingredients, and great decisions. Design systems should provide teams with a recipe for greatness, not just a set of ingredients.

As we navigate the evolving landscape of design systems in 2024 and beyond, remember that design systems are tools, not rules. They should amplify your creativity whithout constraining it.

The next time you open your design system, ask yourself: “Am I using this to make something great, or just something familiar?” Your answer might just be the difference between a good product and an unforgettable one.

Beyond the hype: rethinking Design Systems in 2024 was originally published in Bootcamp on Medium, where people are continuing the conversation by highlighting and responding to this story.

Breaking Down a Design System

A design system, composed of carefully crafted components, harmonizes to serve a singular purpose: providing a cohesive language for its primary users, the engineers, and designers. These are the masterminds who shape user experiences, where their expertise directly impacts the quality of the outcome. Therefore, nurturing an enhanced work environment is pivotal. After all, cultivating sophisticated design starts with empowering the creators themselves.

The Design System Core

At the heart of our system is its core, which provides a range of services, functions, type systems, scales, and theme models essential for building cohesive components. A robust core shapes a consistent, intuitive creation experience for designers and engineers.

When constructing this foundational bedrock, three distinct, yet equally vital mindsets must be adopted:

• Designer Mindset — Unpacking the ‘Why’: This mindset is centered on the components’ visual attributes, including the color system, typography, and density models. The goal is to ensure each component visually aligns with the design language, fostering uniformity throughout.
• Product Mindset — Generating the ‘What’: With attention on the product’s future, this approach understands its intended growth, usage trajectory, and the creation of new use cases based on future roadmap items. This perspective helps the system team make decisions to shape the future of dynamic design across the product.
• Engineer Mindset — Detailing the ‘How’: Focused on the technical intricacies of the components, this mindset is all about adherence to best practices and high performance. The objective is flawlessness in every component’s function, leaving no room for inconsistency.

Uniting these diverse perspectives cultivates a comprehensive approach to building an effective, streamlined design system.

Component Library

Components are the main deliverables in a design system, with atomic design principles serving as a guiding framework for their development. These principles offer a holistic view of the library’s fundamental elements, supporting teams in creating common layouts and reusable micro user interfaces.

Key to maintaining user focus, components aim to standardize actions, mitigating the need to create bespoke solutions and learn new UX patterns. An effective component library respects versioning, providing concise, timely updates. Clear changelogs with outlined changes and integration steps can foster ease and confidence in teams during application updates.

Figma, Tokens, and Theming

A synchronized Figma Library stands as a pivotal part of a robust design system. It operates as the definitive reference for applying the design language to its components, serving up reusable and droppable artifacts that align perfectly with each developed component.

Tokens are a key element to the design language. They establish a uniform theme standard across application UX, bolstering consistency and clarity. I personally find Tokens Studio, a plugin for Figma, to be a highly effective tool. Please note, as I’m writing this post, there are some new features announced in Figma Config Keynote 2023; in particular Figma now natively supports variables for dynamic design solutions. Whichever tokens or variables solution you may chose, the output from either can be translated to CSS variables, ensuring a seamless transition from design language to code. This approach facilitates an efficient workflow, allowing us to maintain theme consistency without sacrificing the flexibility and adaptability needed in a dynamic development environment.

Themes can be exported from Figma to GitHub in a user-friendly JSON format, empowering the development team to consume and version these elements directly into the Component Development Kit (CDK) as themes. Furthermore, the library enriches the design system with embedded UX documentation, seamlessly integrated into the Storybook component pages. In essence, it acts as a dynamic, interactive guidebook, equipping teams with all the necessary tools to navigate and utilize the design system effectively.

Boilerplate

A boilerplate serves as a model repository, offering an efficient and streamlined starting point for launching front-end projects. A useful tool for creating a library boilerplate is NX. NX helps provide a flexible and incremental development framework, enabling developers to incorporate the specific package configurations needed for their unique builds, without creating unnecessary bloat.

Documentation

The importance of documentation cannot be understated. Without it, the system may fail to thrive, impede adoption, and limit contributions. In crafting your documentation, the aim should be to articulate information in a clear, concise manner, while also being inclusive of the diverse stakeholders in the ecosystem. By focusing on these aspects, you ensure that your documentation is not only informative and user-friendly but also inclusive, promoting wider engagement and collaboration within your community.

When it comes to solutions, Storybook shines as an invaluable asset. It automatically generates comprehensive documentation from comments and offers a live testing environment for component props. This feature empowers teams to experiment with and evaluate different component variations directly on the site, promoting a hands-on, interactive approach to component testing and optimization.

Proper Strategy and Governance

An effective design system is built upon a deep understanding of the needs and experiences of designers and developers. These considerations should form the foundation of your strategic approach.

Stakeholder Engagement

Firstly, thorough stakeholder engagement is crucial. Conduct in-depth interviews with target development teams and UX/design leads to capture their unique perspectives, requirements, and use cases. This helps ensure the design system you’re building aligns with their needs and facilitates their work.

Launch and Feedback

After launching the design system, iterative feedback and improvement should become a cornerstone of your strategy. Here are a few ways to foster this:

• Surveys: Distribute quarterly developer and designer experience surveys. This regular check-in provides insights into how well the design system is meeting needs and where improvements can be made.
• Contributions: Encourage contributions from within the team, following InnerSource principles. Foster an environment that emphasizes openness, transparency, prioritized mentorship, and voluntary code contribution. This inclusivity can empower team members to improve the system actively.

Governance Team

Establishing a governance team is critical in maintaining the system’s integrity:

• Inclusion Decisions: The governance team should decide on library inclusion based on relevance and compliance with certain standards. For instance, enforcing WCAG 2.0 Level AA and internationalization support as requirements for inclusion ensures accessibility and global usability.
• Theme and Functionality: The team should also make opinionated decisions on the system’s theme, functionality, and methods/services offered for downstream alterations. This ensures a degree of consistency and coherence in the design system.

Remember, the success of a design system hinges on it being a living, evolving entity, continually shaped by the needs of those who use it. Proper strategy and governance enable the system to grow organically while maintaining alignment with its original goals and principles.

Final Thoughts

In adhering to this approach, the design system becomes more than a mere tool — it transforms into an empowering platform that enables developers and designers to create consistent, accessible, and visually appealing application ecosystems. A robust design system stands as a keystone, cementing the visual and functional unity across any product ecosystem. It cultivates an environment for seamless collaboration between designers and developers, ensuring uniformity while accelerating processes.

Balancing the intricacies of design, development, governance, and documentation is undoubtedly complex, but it’s an endeavor worth pursuing. It’s a journey that ignites creativity and, at the same time, fosters a sense of structure and order. As you traverse the challenging terrain of creating a design system, remember to explore each of these aspects.

Remember, the journey to a robust design system is not a sprint, but a marathon. Each step you take, and each decision you make, contributes to a foundation that can support and inspire your teams for years to come. Let your design system be the catalyst for innovation, productivity, and most importantly, a memorable user experience.