Bauhaus Design System

Maintenance ​

Version Control and Maintenance of UI Library ​

The workflow and pipelines for maintaining the cross-file/cross-team collaboration and version control for tokens and components of Bauhaus Design System is defined via workshop in the DesignOps FigJam file and documented in this section of documentation.

Summarized process steps:

  • A defined, meaningful set of updates on the design system styles and components defined by the Product Owner become candidates for the next release of the design system npm package.

  • Design decisions such as Colors, Typographies, Effects and Gutters are tokenized by Designer. Developers are informed and fetch the changes as soon as they are available.

  • Azure project - Bauhaus Design System is used to set up the weekly sprints where Product Owner together with Designers and Developers define the work items for the upcoming sprint.

  • Azure Boards are used to manage the sprints.

  • Work items' hierarchy correspond to that of Atomic Design hierarchy for each component followed in Bauhaus Design System, and the smallest chunk of deliverable/iterable work items are Requirements, for example:

    • Molecules (Epic)
    • App Button (Implementation)
    • App Button icons [UPDATE] (Requirement)
    • Padding [FIX] (Bug)
    • Adapt to new color tokens [UPDATE] (Requirement)
    • New App Button type [ADD] (Requirement) etc.

  • Component-related work items that are defined for the next release are distributed per upcoming several sprints based on complexity.

  • Component is designed in Figma; documented by Designers in Figma; styles are tokenized; component is handed over with all Developer questions answered.

  • When a component or a new design update on the component is ready for the development, Designer renames the Figma page corresponding to the component and Figma component in the following format - "Name Of Component // ✅ (v1.0.0)", where version number corresponds to how many times this component has gone through changes that were implemented and deployed. One check emoji (✅) for it is ready in design and in development but not deployed; two check emojis (✅✅) for when it is deployed and live.

  • After handing it over and answering all developer questions, designer can not update this component and its documentation without proper communication with the developer. If the component is already live and changes need to be introduced by designer, then the Figma page corresponding to the component including the component itself should be duplicated, renamed to "Name Of Component // ✅ (v2.0.0)" and handed over to developers for the next release of the npm package.

  • Component or component-related work item is implemented by Developers and handed over for the QA.

  • Designer and Developer do the QA and iterate the component/work item if necessary.

  • After successful QA of all the component related work items it is finally ready to be candidate for the next release.

  • After all the candidates of the upcoming release are ready, the new Bauhaus Design System npm package will be tested for each existing project (using the BDS npm package), deployed and monitored for bugs by Product Owner.

  • During components' life cycle and usage in various projects they will go through usability tests and therefore there will always arise new work items to improve, add new components, or deprecate some.

INFO

The process definition of testing the components with users is a work in progress.