Creating Themed Versions of a Master Design in Figma

This post is part of a series Building a Design System with Figma at littleBits.

Having a master design, and effectively managing themed variations can be tricky.

Our base littleBits branded themes.

It’s important to have a clear separation between the core design and the variables of the theme. This makes it easy to manage changes to the core design and populate them to the themes.

Time was tight, so we had to keep our setup as simple as possible, but on the other hand… our themed app was going to be leveraging assets from Marvel — we wanted it to be distinct and pack some punch!

In part because the Avengers artwork was so strong, we decided we could achieve our goals with a system where nothing besides swatches and hero assets would change.

We defined a base set of swatches for the master design, then created sets of overrides for the swatches that could be applied not just on an app level, but for different sections of content within each app.

The ‘Journey Menu’ with different themes applied per stage of kit.

File Setup

Our eventual Figma Design file structure was:

• A base Design Library which had all of our atoms, components, and templates.
• The templates in the Design Library included example assets, but to avoid bloat, no more than what was necessary to demonstrate the how the layouts worked.
• All the components and styles from the Design Library were published into the team library.
• The Hero Inventor Kit app had a Theme File where we defined the extra swatches, and set up the theme specific assets
• We also made a Theme File for the littleBits app. Although it was closer to the base designs, it still had themed swatches for some content stages, and lots of kit specific assets we didn’t want in the Design Library.
• In the Theme Files we imported styles, components & templates from the Design Library and mixed them with styles from the theme to create themed style guides.
• We applied the Theme File swatches and asset swaps to the templates imported from the Design Library to create a full set of screens for each themed app.

Theming a basic template.

Theming Templates

Because switching the swatches was easy, we didn’t need to create extra nested master components for the themed templates.

For ongoing maintenance, if there were layout changes to be made, we could change the master templates in the Design Library.

Once one template had been themed, we could duplicate it within the Theme File knowing it could still be maintained by editing the theme’s shared swatches & assets.

This setup worked well for a number of reasons:

• There was just one set of ‘core designs’ — our Design Library is a single source of truth that engineers can reference for all components & templates across all apps.
• We were able to avoid too much duplication of child components within the Design Library, which can cause editing of the master component to be sluggish.
• We could duplicate child components as much as needed in the Theme Files (say if we wanted to mock a long flow of content screens) because the master components were edited via a separate file & managed through the Team Library.
• It was really clear for engineers what the theme variables were in the Theme Files.

Layout Variables Within the Templates

Because we were building our own custom CMS to drive the app content, we were able to use custom layout variables in aspects of the templates.

For example, we had ‘success’ screens where a character would pop up and offer encouragement. We thought it would feel a bit flat if the character was always in the same place, so we set custom positioning offsets for the character & speech bubble.

We did something similar for positioning of invention art on the journey menu.

Managing this in Figma was a little bit tricky because we needed to create a new component for each layout variant, and swap it into the master template, but this is something we will cover in the ‘what could be better in future’ section of this post.

Workflow for Edits

Outside of the main files, we also create WIP files for fleshing out new ideas and working in a less structured way.

There we copy paste templates from the master files (or drag in from the library) and pull them apart to mock up new features, try variations of the layout etc.

Once someone has new work to share we run a sort of informal pull request flow over slack with the team —we talk about how a proposed change fits into the system as a whole, and update the master files when everyone is happy.

That’s it!

Heres a screenshot of an end to end from the Hero Inventor Kit app — as you can see, beyond the designs, there was also a whole lot of content to create (and the littleBits app had much, much, more!), but thats another story in itself.

Through these posts, we have tried to present how we ultimately tackled a variety of problems. Hopefully some of this is gonna be useful for other people attempting similar things.

But if you want to read about what went wrong, and areas where we struggled with Figma.. here’s the post for you!

This post is part of a series Building a Design System with Figma at littleBits. Read the next post Creating a Design System in Figma: What went wrong.