I’ve been testing the Foundation: Color Generator plugin for Figma, mainly as a quick way to generate colour scales and check how different colour systems present shades, contrast, and usage.

What I like immediately is the way the generated swatches are presented. The plugin gives a clear visual overview of the palette, and it also shows contrast values and accessibility ratings such as AA and AAA. That makes it very practical when thinking about WCAG, especially at the early stage of defining colours for UI work.

It is useful not only as a colour generator, but also as a quick reference point for how colours might behave across light and dark interfaces, surfaces, text, borders, and interaction states.

Orbit System

The Orbit system seems like a very quick solution, especially when someone needs a more complete colour setup without spending too much time building a design system manually.

However, for the way I usually work, it is not the most useful option.

I prefer to generate a base colour palette first, and then map colours to specific design tokens and usage later. Orbit appears to generate colours that are already mapped to usage. As a result, the same colour can appear in multiple places and contexts.

For example, one shade may be used across several mapped states, such as:

  • Light:hover
  • White:active
  • Light:hover / Dark

This can become confusing, because this is the kind of mapping I would rather define myself at the design system level, not at the palette generation stage.

So, for me, Orbit is probably not ideal when I want more control over the structure of the system. But for a quick, complete setup — especially when skipping a more detailed token-building process — it could be very useful.

Ant Design

The Ant Design option is probably the preferred method for me.

I like the gradation of the generated shades. It feels balanced and practical, especially when using a regular brand colour as the starting point and then selecting one of the lighter shades for neutrals, surfaces, subtle backgrounds, and UI layers.

This approach gives me a clean colour scale that I can then map myself into semantic tokens, such as:

  • background
  • surface
  • border
  • text
  • muted text
  • primary
  • primary hover
  • accent
  • warning
  • success
  • error

That separation matters to me. I want the generator to help me create the raw colour palette, but I still want to decide how each colour is used in the actual system.

Material Design

The Material Design option also works well.

It gives a clear and predictable colour scale, and the naming convention is probably the easiest to understand at a glance: color-100, color-200, color-300, and so on.

That kind of naming is simple, readable, and easy to translate into design tokens or documentation later.

As with Ant Design, the lighter shades can be useful for surfaces and backgrounds, while the darker shades can work for text, emphasis, or stronger UI elements.

Summary

Overall, the plugin is useful because it gives a quick, visual way to explore colour systems, generate shade scales, and check accessibility contrast early in the design process.

The contrast preview is especially valuable. Being able to see numerical contrast values and AA / AAA ratings directly next to colour combinations makes the palette much easier to judge from a practical UI and WCAG perspective.

For my own workflow, I would use this plugin mainly to generate and compare base colour palettes, not to fully define semantic usage. I prefer to keep the mapping layer separate and handle that inside the design system or token structure.

So my preferred direction would be:

Generate palette first → review contrast → select useful shades → map colours manually into design tokens.

For fast projects, or when a complete system needs to be created quickly, the Orbit approach could work well. But for a more controlled design system workflow, Ant Design or Material Design style scales feel more flexible and easier to build on.