📝 Articles
Components as Data
Nathan discusses the importance of defining components as structured data to enhance scalability and interoperability in design systems. His team initiated a refactor, starting with the Pill component, to ensure consistent, platform-independent definitions. By using formats like YAML or JSON, they improve collaboration, automate documentation, and enable data-driven insights, emphasizing that treating components as data is crucial for evolving design systems in the AI era.
How we built a multi-brand icon system at Telefónica 🇪🇸
Rama discusses creating a multi-brand icon system at Telefónica, focusing on the challenges of maintaining consistency across brands. The Mística Icons project aimed to unify over 3,300 icons, addressing issues like inconsistent naming and concepts. By centralising the system and automating processes such as icon export and synchronisation, they improved efficiency and clarity while balancing automation with manual oversight.
Using composability over inheritance to scale design systems
Adam discusses the advantages of using composability over inheritance in design systems to enhance scalability and flexibility. He describes challenges faced when making simple changes to components, leading to inefficiencies and duplicates. By adopting a composable approach, teams can create flexible components that allow for customization without forking code, promoting reusability and simplifying the design process. This empowers teams to innovate and respond quickly to changing requirements.
👀 Interesting Reads
Behind the scenes of maintaining a design system component
Rama discusses maintaining and scaling design system components after launch, emphasizing processes for handling issues and enhancements. Once shipped, components enter maintenance mode, responding to consumer requests. Issues are categorized into bugs and enhancements, prioritized by impact, and resolved through direct fixes, workarounds, or custom solutions. Structured practices, like dedicated channels and weekly triage calls, ensure effective tracking and resolution, highlighting the importance of collaboration and transparency.
Mapping what is in my head: turning invisible solutions into shared clarity
Alex highlights the importance of mapping ideas to create shared clarity in design processes. They recount experiences at a global bank where mapping the design flow revealed discrepancies among stakeholders, leading to improved alignment and automation. Through token and component mapping during a redesign, Alex showcased progress and simplified the transition to a tokenized system, emphasizing that effective mapping transforms invisible solutions into collective understanding.
Refactoring the button component
Joyce refactored Edifire UI’s button component from 432 variants to 32 using parametric logic and Figma properties. Overwhelmed by variant overload, she shifted her focus from visual options to behavior, creating a scalable, token-driven system. This improved performance and usability, making the button easier to use. Joyce plans to apply this method to other components and aims to make Edifire open source.
How to Create a Strong Design System and Survive: Case Study
Olena shares a case study on implementing a scalable Design System in a major Ukrainian logistics company, tackling product inconsistency and legacy issues. After six months of stakeholder buy-in, the team built the system alongside ongoing feature delivery, focusing on user research and documentation. Key lessons include early stakeholder engagement, continuous communication with developers, and gathering measurable impact data.
🖤 Design Systems
SubZero 2.0
SubZero 2.0 from Axis Bank offers over 100 components and 50 products, co-created by 12 collaborators and trusted by over 900,000 consumers. Their design system aims to simplify complexity for "impactful online experiences", with extensive design and development libraries available for valuable resources.