Local component libraries
All teams have their individual needs when crafting the best user experience – what fits one team might not fit others. This is why we encourage all product teams to create their own component libraries, tailored to each of their requirements.
Core vs local
Gjensidige’s global component library “Builders Core” consists of our shared design tokens and most used components such as buttons, global icons and so forth.
Yet, team specific problems need team specific solutions, which are best kept in team specific libraries.
When your team uses a set of components frequently (e.g. a specific set of forms for a customer’s personal information), you should consider standardising it into a predefined component in your team's local library.
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
Using atomic design in your local library
Team specific libraries should always be created with subatomic particles and atoms from our Core library.
We suggest building your local libraries of molecules that solve UI/UX problems that only your team faces. If your team needs a specific component that falls under the atom category (such as a specific icon or button), always build your local atoms using the subatomic tokens from core.
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.
3. Familiarity and ownership
Teams can create better solutions more effectively with a close relationship to the UI elements they use. We achieve this through loving contributions to the design and functionality of our components. In turn, this enhances the sense of ownership to the solutions we make.
Each team should make new creations based on their own needs, but also suggest changes to the core library. In our increasingly dynamic world, design requirements and expectations to “look and feel” are in constant and rapid change.
How to local
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 Core 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.
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.
Reviews in Abstract
When you create new components or change existing ones, invite other designers from other teams to review your work in Abstract. Help your colleagues understand what you need by adding context, and specify whether the change relates to UI or UX.
Slack channels
We also encourage all teams to share their work in Slack channels such as #team-builders or #look-what-ive-made to keep everyone up to speed with any additions you and your team make.
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.