डिज़ाइन प्रणाली के बिना, प्रत्येक डिज़ाइनर और डेवलपर स्वयं छोटे-छोटे निर्णय लेता है: थोड़ा अलग नीला, एक नई बटन शैली, एक और रिक्ति मान। एक वर्ष के बाद उत्पाद में लगभग दर्जनों डुप्लिकेट हो जाते हैं। एक डिज़ाइन प्रणाली उन दोहराए गए निर्णयों को साझा निर्णयों से बदल देती है।
अधिकांश डिज़ाइन सिस्टम में तीन परतें होती हैं। डिज़ाइन टोकन नाम वाले मान हैं, जैसे कि रंग.प्राथमिक, स्पेस.4 या मोशन.ड्यूरेशन.शॉर्ट, जो कच्चे निर्णयों को संग्रहीत करते हैं। बटन, इनपुट, कार्ड और संवाद जैसे घटक उन टोकन से बनाए जाते हैं और इसमें हर राज्य शामिल होता है। दिशानिर्देश दस्तावेज करते हैं कि प्रत्येक घटक का उपयोग कैसे करें, लेबल और संदेश कैसे लिखें, और कौन से पहुंच-योग्यता नियम लागू होते हैं।
एक डिज़ाइन सिस्टम दो स्थानों पर रहता है: डिज़ाइन टूल में, एक घटक लाइब्रेरी के रूप में, और कोड में, एक पैकेज डेवलपर्स इंस्टॉल के रूप में। उन दोनों को एक साथ रखना सबसे कठिन हिस्सा है। जब कोडित बटन डिज़ाइन किए गए बटन से मेल नहीं खाता, तो लोग सिस्टम पर भरोसा करना बंद कर देते हैं।
गति भी व्यवस्था में है। अवधि, सहजता वक्र और स्प्रिंग सेटिंग्स टोकन हो सकते हैं, और इंटरैक्टिव घटकों को होवर, प्रेस, लोडिंग और ट्रांज़िशन के लिए परिभाषित व्यवहार की आवश्यकता होती है। ExodeUI, जिसे हम बनाते हैं, उस व्यवहार को राज्यों और स्प्रिंग भौतिकी के साथ एक खुली फ़ाइल में संग्रहीत करता है, इसलिए वही घटक React, Vue, SwiftUI, Flutter और अन्य ढांचे में चलता है।
प्रसिद्ध सार्वजनिक उदाहरणों में Google का Material Design, Apple का ह्यूमन इंटरफ़ेस दिशानिर्देश, IBM का कार्बन और Shopify का पोलारिस शामिल हैं। उन्हें पढ़ना यह देखने का एक अच्छा तरीका है कि एक परिपक्व प्रणाली कैसे व्यवस्थित होती है।