Way we work
Intro
It is important for us to adopt a flexible approach that allows us to avoid interfering with product development and experimentation. This way, developers can create and modify components themselves using design system (DS) primitives. Meanwhile, the DS team can maintain control over the core aspects of the visual language through backgrounds and primitives, without affecting the logic of the components.
Create request → Describe your needs
→ We will work out it → Final review
How it works?
We are dividing responsibilities into two sides: DS and Product.
1.
Basic Components (Foundation → DS Primitives → DS Organisms) are the responsibility of the DS Team.
2.
Product Component is the responsibility of the Product team.
DS Responsibility
DS Foundation covers essential components, including headless components, icons, fundamental rules, frameworks, and principles.
Product Core inherits all elements from the background while applying color and text tokens.
DS-Primitive combines inherited styles and headless components from backgrounds into typography, buttons, selections, and more.
Intersection of product and DS
DS-Organism is a comprehensive composite structure linked to Figma and DS Foundation, serving as a universal reusable entity made from multiple ds-components or constructors, or simply a collection of slots (modal, toast, tuning field, dropdown menu).
Product Responsibility
Product Component refers to any variation or modification of an organism or primitive, incorporating product logic and data, fully under the influence and responsibility of the product (such as sidebars, floating bars, ratings, and comments sections). Components must be used correctly, as this is also a product-side responsibility.
This approach provides flexibility in scaling, allowing the product to create the organisms it requires. The product will have complete control over the logic of components and data flows. Meanwhile, the entire base derived from the DS will be managed and regulated through the DS's background, ensuring that we do not interfere with each other during scaling or global updates.
Product team
A product developer will always be insulated from external factors, as their focus is on specific product tasks and resolving local issues within product releases. When developing the client side, the developer will not consider the broader context, as it is not their concern. Therefore, the responsibilities of a product developer include:
Example: A new product button consists of text, an icon, and, say, a counter. The text is ready, the icon is there, and the counter is ready. All the parts are developed in library, and the button component itself is ready. Then product put together the new variation.
Developing the client side of the component.
Refer to a common base of components to avoid creating new entities.
Strictly monitor the use of tokens. If a token is not in the DS but is in the layout, or if the layout is built on hexes, a request should be made to the DS team.
Notify the DS team if planning total customization; we will discuss and decide together on the best approach.
All new or updated components created by the product are included in the product and documented in a special product Storybook.
The developer is responsible for implementing the components in the product and gradually replacing old parts with new ones. We will assist with integrations during challenging moments, such as when initiating a change in approach.
DS-Team
If something is obviously missing from the basic parts or there are bugs somewhere and it is our fault, then we do it.Or if it's a completely new UI and we decide that it's a DS component, then we develop it within ECHO DS, and product take it for yourself.
The DS team is responsible for changing the semantics and color tokens in the product, as well as typography, common systems, mechanics, brand updates, and background components that connect the product to the overall ecosystem.
The DS team is responsible for global fonts, updating them, and distributing them across the product range.
The DS team remains responsible for the usability of components. We will monitor this throughout 2025 to ensure that fundamentally the same code is not created in different products.
The DS team is responsible for tracking all major releases in which the components appear, to understand what is happening at the design level and where everything is headed.
The DS team will continue to provide advice on products, but only on issues related to components and their usage; we will no longer act as forest sanitarians.
Adopt useful practices from the product and integrate them into the Foundation.
Basic generation of token files for products (Application by product) plus a consulting component. The connection of the DS background means that the DS is not responsible for everything that occurred before the connection, but is obligated to use the background for all new features.
In case of questions
These channels will help you find answers to any questions related to DS or its surrounding topics. Please share your ideas and problems here:
Channels:
#ug-design-system
#ug-design-system
#mu-design-system
#au-design-system