Bauhaus Design System

Hands-off ​

Checklist for component hand-off from design to development ​

  • Figma components are working as they should.
  • Ideally most design decisions are tokenized through
  • Figma’s native styles and with another layer of semantic tokens. These raw styles are coming from Design Tokens file and in case of Gutters, follow the Gutters table. For more information about tokens go to Design Tokens page. Styles that are used in this particular release should not be changed in Design Tokens file in Figma after the hand-off.
  • Preliminary developer and design questions are answered.
  • Designer asks Developer to fetch changes in tokens from Figma into code repository through Figma Plugin.
  • Component is documented in Figma using a defined template. This documentation is then transferred to Vitepress.
  • Every component page that is part of this release are renamed as follows: Name of Component // ✅ (v1.0.0) Rename every Master component’s name as Name of Component (v1.0.0).

INFO

The versioning in Figma is only concerning the Figma components, because they aid designers to have a control over what is the state of the implemented component compared to that of Figma. After component has been designed handed over to developer and developer implemented in code, component can only be altered in Figma by incrementing version number and saving the previous state. Ideally designers and developers should always follow design-first approach for any changes in components and the designed and coded components should be identical and up to date.

Developers use a different versioning system and only when the whole BDS npm package is released.

Checklist before a new version of BDS npm package is to be released ​

  • Make sure documentation for each component is in Vitepress and tokens are up to date.
  • Define which components/changes go into current release. Ideally only a component that is QA’d and tested (i.e. used in a Figma project at least and tested with users) is a candidate for next release.
  • After release rename Figma’s native version autosave respectively DS Release v1.0.0 to be able to go back when needed and duplicate/check out at that version if required to go back into that version. Write in description for version autosave what is in this release and what are all the changes to components (if it is hard to describe every change, write at least which components have been affected).
  • Add another “ ✅ “ to the name of the component page in Figma meaning it is Live. For example: App Button // ✅ ✅ (v1.0.0)

INFO

Go to Maintenance section of this documentation for more information on components’ life-cycle.

Documenting a component ​

Documentation of the component as well as the component itself are dynamic and can constantly evolve as we will be improving the design system in iterations. Nevertheless, components should be documented following the same template consistently to make finding any information easier for developers:

COMPONENT NAME

Usage

Describe here all the possible use cases of component in Bauhaus Design System, that is already in use or can be predicted.

Types

Here include all the types and variants of a component excluding generic sizes (Small, Medium, Big), states/statuses and brand they correspond to. For example in case of AppButton the types are: Primary, Secondary, CTA-Primary, CTA-Secondary.

Anatomy and Behavior

Include here an iframe from Figma with the diagram of component and what are its parts named. Further, names of tokens will be using the same names of component parts.

States

Here include all component states (pseudo-classes)and possible statuses. Status here refers to the states that are not necessarily pseudo-classes, such as validated, on error, selected, active, etc.

Gaps and Sizes

Include here every data regarding the dimensions and layouts inside the component. For now, these data are not semantically tokenized (no in-between semantic tokens) therefore they are referencing the style tokens directly. Tokens Here we should document all component-level tokens for the component that are referencing in most cases semantic tokens.

Properties, events and slots

These are all the properties available in the component derived from its implementation Vue. This defines but also limits what the component can do.

Playground

Playground should dynamically show all the configurations and states of the component as it is implemented. The quality assurance of the component will be carried out by designer and developer comparing the Figma design (plus documentation) and the results seen in Playground.

Configurations

Here we present a table with all the variations produced from the component., usually with developer adjusted classifications of variants that may differ from those in Figma.