Conventions for product teams

These conventions are also published in our Tech Base

Our conventions guarantee that all teams, both internal and external, operate within a framework that prioritizes consistency and efficiency, while still allowing for necessary customization and innovation. We emphasize a collaborative and communicative process with the Design System team to ensure the overall design language's integrity and coherence.

Unified technology stack and component management guidelines

Technology stack

• Figma is the designated tool for all design-related tasks, including the creation of components and complete layouts.
• Storybook is used for documenting functional components, providing a platform for interactive examples and properties documentation.

Component management

• Product-specific libraries in Figma and branches in Storybook should only contain components that are not (yet) part of the Design System. This ensures a focus on leveraging standardized components for consistency across products.
• Teams must prioritize using components from the Design System, resorting to product-specific components only when necessary.
• Once a product-specific component is integrated into the Design System, it must be replaced in both the product's Figma library and its Storybook instance with the standardized version, and the original component should be removed to prevent duplication and maintain consistency.

Collaboration and communication

• Continuous collaboration between product teams and the Design System team is essential for proposing new components, integrating them into the Design System, and updating both Figma and Storybook accordingly.
• Regular review sessions and open lines of communication will facilitate this process, ensuring all teams are aligned and utilizing the most current and approved components.

The infrastructure

Product component creation process

1. Identification & alignment: The product team identifies a UI component not yet in the Design System and aligns with the DS team.
2. Existence check: They assess whether the component already exists within the Design System.
3. Requirement analysis:
   • If the component exists and meets all requirements, it must be used.
   • If not, the product team and DS team discuss to better understand the requirements.
4. Development decision:
   • If changes or a new creation are needed, it’s determined if the work is part of the DS or just a one-off product item.
5. Concept creation:
   • Depending on its relevance to the DS, the initial concept is created either by the DS team or the product team.
6. Review & iteration:
   • Both teams regroup to review the concept, iterating until it meets all requirements.
7. Component development:
   • The creator of the component, often the product team, develops it by their standards.
8. Quality assurance:
   • The DS team may develop the component in rare situations, followed by QA and documentation to DS standards.
9. Finalization:
   • If the component meets all standards, it’s either released for product use or added as a new component in the Design System, ready for use by every team.
   • If there have been component developments by the product team, they must exchange them by the DS component.

Throughout this process, the emphasis is on maintaining a smooth and unimpeded product development flow while ensuring that the components either align with or contribute to the Design System. The process is designed to be flexible, allowing product teams to move forward with urgency when necessary but also ensuring that potential additions to the Design System are considered and integrated in a structured manner.