Bauhaus Design System

Design ​

INFO

There is a distinction between the words "component" and "Figma component". Usually, but not always, Figma components become a component of Bauhaus Design System.

Tools ​

Figma is the primary design and collaboration tool for Bauhaus Design System. Designers can use Figma Professional Plan or a higher tier to create, store, maintain and handoff design tokens, components and elements in a unified team library. Figma's Professional Plan plan does not include branching and version control, therefore it is important to maintain it manually and have a consistent communication across design and development teams.

'Design Tokens' file in Figma is where all the design tokens are created, maintained and stored. Colors, Typography and Effects are stored as native Figma styles in this Figma file as well. For other design decisions that can be tokenized but are not native to Figma as of the time of the creation of this Design System (such as Gutters), use the same Figma file to create corresponding token tables as references for developers. 'Design Tokens' Figma file has a published team library that must always be up to date and is a single source of truth for design tokens. Be aware that changes made in the native Figma styles in this Figma file will affect all the shared team files when they are updated. If a non-Figma-native token needs to be changed, designers should manually apply all these changes in each team file that is using these styles after introducing the changes in 'Design Tokens' file, document and inform developers of these changes. For detailed specifications of design tokens visit Design Tokens page in the current documentation.

'Bauhaus Design System' file in Figma is where all UI components (Figma components) are designed, maintained and stored. Designed components are published to a shared team library from this file, therefore it is the single source of truth for all design components. Changes made to any designed component in this file will affect the team library in Figma and any shared team files using these components, when they are updated. Therefore it is crucial to follow the workflow defined in this documentation under the Maintenance section and communicate with other Designers. For detailed documentation of each component and their usage refer to corresponding components' page in this documentation categorized under the Atoms, Molecules, Organisms, Templates, Functions and Utilities.

'Archived Components' file in Figma is where all the deprecated/archived design components are stored and it should neither be published to the team library, nor should it receive any updates coming from other libraries. When a component is deprecated in 'Bauhaus Design System' file and is not affecting any team projects anymore then the component must be Cut & Pasted into 'Archived Components' file under the respective component page. When a component from the 'Archived Components' file needs to be back into the game, it must be Cut & Pasted into the 'Bauhaus Design System' file.

Vitepress is the documentation tool and a single source of truth for Bauhaus Design System where all the design and development workflows, creation, maintenance and usage of Design System components are delineated, implemented components are showcased in playground with all their properties and documentation. It is edited and formatted using any convenient code editor; VS Code in the current case. Current documentation you are reading is built using Vitepress.

Azure DevOps is an agile project management and code repository tool for Bauhaus Design System.

Organization - Atomic Design ​

Component organization in Bauhaus Design System is inspired by Atomic Design methodology.

  • Atoms: according to this categorization, they are the smallest functional building blocks of user interfaces that have a meaningful functionality in isolation. These atoms include basic HTML elements like form labels, inputs, buttons, and others that can’t be broken down any further without ceasing to be functional and losing their intended purpose. In Bauhaus Design System, Atoms can be divisible further into parts for modularity purposes, but these parts only exist in design pages where the components are created in Figma and are not published as separate components to the team library (e.g. icons that are used in Button component adapted to have the colors and the sizes only for this component are stored as the parts in the Button page in Figma and are not published to the team library).

  • Molecules: are relatively simple groups of UI elements (in most cases of Atoms) functioning together as a unit. For example, a form label, search input, and button can join together to create a search form molecule.

  • Organisms: are relatively complex UI components composed of groups of molecules and/or atoms and/or other organisms. These organisms form distinct sections of an interface. Building up on top of search form molecule; it can often be found in the header of many web experiences, so a search form molecule with navigation and a brand anagram can form together a Header organism. Organisms demonstrate those smaller, simpler components in action and serve as distinct patterns that can be re-used in different digital solutions.

  • Templates: are page-level objects that place molecules and organisms into a layout and articulate the design’s underlying content structure. It is critical to demonstrate how components look and function together in the context of a layout to prove the parts add up to a well-functioning whole. This part of Design system as well as most of the organism level components will be fulfilled with time as various applications to be developed using Bauhaus Design System will be creating the need for these templates and establishing the guidelines through iterative design thinking processes.

  • Functions: are components without UI that store some sort of functionality to be consistent in the whole design system. Not all Vue components need to render a UI element. This is particularly helpful when you a need logic to exist that updates the store, but has no associated UI. In this case, we have a container component that doesn't return any presentational component. An example of this is a Toast Manager - a component that controls the maximum number of toasts allowed in a viewport.

  • Utilities: are UI components that affect the overall state of the UI when triggered by user, such as language selector, background color changer, high-contrast toggle, etc.

Page organization in Figma ​

Pages in Figma correspond to each component name and are categorized in the same Atomic structure as in Vitepress. The names of the pages may contain some emojis to help designers and developers to have a better grasp on the status of the component. Below is the up to date list of emojis that can be used for the names of the pages. Also, if a component is already ready for development or deployed it will contain the version number in the Figma page name and Figma component name.

Component Structure and Naming Conventions in Figma ​

In Figma component names will be written in Title Case and their properties will have mixed cases (depending on some Figma-related factors). In Vue component names will be in PascalCase and their properties in camelsCase. See moore on naming conventions for developers

One of the most important principles to follow while building a new Figma component is flexibility. Components and patterns must have a modular structure allowing any changes in the future to be made with the minimum possible efforts from designers and developers. There are two reasons for that: first, it is due to the small-sized team of designers and engineers maintaining this design system; and second, it is the lack of context in the initial phases of the conception of Bauhaus Design System, which means that the components may adapt to the needs of future digital solutions in iterative manner.

TIP

Components must follow the same pattern and structure to ensure the long term adaptability and easy handover across designers and developers. In case a different structure is followed, it should be documented with justifications.

TIP

Use base components for every component set (i.e. variants group) that share some properties and will pass on some of their properties to the children.

A useful rule of thumb is that every design component in Figma should be created in layers. First layer is a base component that controls overall morphology (dimensions and compositions) of the component. These base components and their variant properties are all named using lowercase letters with dot instead of a space between words. If any of the properties in base components will not be overridden and the property will be exposed in the outermost layer, then this property can be in Sentence case. These base components also contain the word "base" in their name and start with dot (.) to avoid publishing them in the library. Base components are then used to create second layer of the structure which in case of most components control the states and types of the component. And the next layer is the final published component with addition of brand variations across our multi-brand design system. So, when a designer needs to update a component, they should be aware of which layer controls the change they are about to make and introduce the change in that specific layer. See example in Figma on how a button component is structured in these layers with annotations explaining what properties are controlled by which layer.