Skip to content

Global Design System vs. Local Library

What’s the difference? As we scale our digital experiences across markets and teams, it’s helpful to understand how a global design system and a local library play different but complementary roles.

Global Cookbook, Local Flavors

A global design system is the world’s cookbook of core recipes and rules, while a local library is the regional kitchen shelf with adapted versions for local tastes.

Global Design System

Our global design system, Builders, is the single source of truth for how we design and build scalable digital products across countries and platforms the entire organization at Gjensidige.

Think of it as the shared language that ensures coherence, quality, and speed no matter where or what we build.

Local Libraries

Local libraries are created to support specific product needs and target groups. They allow for local flexibility and can also serve as testing grounds for new ideas that may later be adopted globally. Put on convention for naming here....  

How They Work Together

  • The global system ensures consistency and alignment.
  • Local libraries ensure relevance and agility.
  • Together, they help us deliver better experiences faster while still respecting local needs.

If you’re unsure where to contribute or find what you need, start with the global system and build locally only where the gap is real.

Why local?

There are three main reasons why we encourage all teams to keep local libraries.

1. Keeping the core at core level

Our core library can't be cluttered with too many components that only a selected few use. It should be easy to find what you need in the core library, either you are a designer working in Abstract and Sketch or a developer working with manageable libraries.

2. Evolving from your contributions

Working with local libraries is a great way to evolve our design system as a whole, while designers and developers contribute more freely. It's easier to see how new components are adopted and to what extent they are useful when gatewaying components through local libraries.

A local library is a great way to filter contributions into the core library.

How to local

All our design tokens are documented in our foundation's section on gjensidige.builders

We have listed a few key points to help you create a functional team specific component library.

  • Based on tokens ​​​​​​​Always use design tokens from Builders Core to create new components (atoms and molecules) or a specific combination of components (organisms).
  • Use Builders components When possible, re-use items from Core in your new components. This allows our design to be more consistent.  
  • Save to library files Always save your components to library files in Abstract. This makes it easier to manage and update your components through different projects.  
  • Do research before you create Always check if you can solve UI/UX problem with existing components from Core. You can also ask other teams if they're working on a similar issue.

Sharing with others

Your creation might be useful to others, or maybe another team already created a similar component. So be sure to share both your challenges and solutions with others. Your contributions to the libraries allow them to evolve, to the benefit of us all.

Be open

By keeping everything out in the open, we may inspire others and request their feedback. This way, we can improve both ourselves and our customers’ Gjensidige experience.

Open library files

Teams should keep their component library open and available for everyone as a library file in Abstract. We also advise all teams to create their own Storybook, to keep all developed components well documented.

 

Atomic library structure

Gjensidige’s design system is based on the principles of atomic design, starting on a subatomic level with what is often called design tokens. These are not components, but rather styles and rules used in components (such as colours, spacing, typography, and font sizes, which are used in atoms).

Such subatomic particles can be combined into atoms (such as buttons, input fields and icons). Adding several atoms together forms molecules (such as a search bar consisting of an input field and a button). Several molecules in one element make up organisms (such as a «navigation bar», consisting of a logo, multiple links and a search field). These can later be used to create templates and eventually whole pages for the web.

Using atomic structures in libraries allow us to build UI elements that scale well and stay visually consistent, even with many contributors.

Atomic design

If you're not already familiar with atomic design, there are many good articles to get you started, such as

Related content

Contribute to Core

See our step-by-step guide on how to add new or improved components to our library.

4 principles for great design

Not just for designers, these principles help us all deliver The Gjensidige Experience. Use the principles as a checklist during the design process or a tool for team discussions.

Embedded applications

To improve user journeys across editorial webpages and applications, the Builders Platform allows you to embed small applications to any page in Content Studio.