Preparing superb for scale with a Design System
My Role
⤥ Responsibilities
Designing tokens, base components and components.
Research on components performance
Documentation
Alignment with development
Designing tokens, base components and components.
Research on components performance
Documentation
Alignment with development
⤥ Output
Design System and Best Practices
Design System and Best Practices
⤥ Team
2 Product Designers, 1 Staff Front End Developer
2 Product Designers, 1 Staff Front End Developer
After series A, Superb was growing more than ever - The platform, the number of employees, and customers. As a product designer, who went from being the only designer to finally sharing the load with two others, I saw the challenge of scale — scaling with all my future designer colleagues, scaling for consistency with development, and managing all the changes and new features the platform would face.
The design system we had, was more a component library than a design system and could not do the job anymore. Therefore, I pitched the importance of putting efforts into building a complete design system. With the backup from the other product designers and the staff front-ender, leadership accepted us to allocate time to it.
The design system we had, was more a component library than a design system and could not do the job anymore. Therefore, I pitched the importance of putting efforts into building a complete design system. With the backup from the other product designers and the staff front-ender, leadership accepted us to allocate time to it.
We are treating our design system as a product. As the project owner -from the design perspective - I've been having the opportunity to learn more about design operations and collaboration with development.
Framework
Atomic design, but with less fancy words.
Using atomic method with different nomenclature
Naming that allows scale.
That a design system helps with scale, we know by now. But how to prepare the design system for the scale within itself, ready for, for example, a rebranding?
For us, that was by not making the name (of the token or components) married to the variable. So, if the yellow ever changes to, for example, purple, we just need to change the variable in the system (hex color) and not the token name.
Our naming structure was split into 3: what it is (name), the semantics (structure or context), and the variable.
