डिज़ाइन सिस्टम की छवि की एक समस्या है: मशहूर उदाहरण उन कंपनियों से आते हैं जिनकी समर्पित टीमें हमारे पूरे डिज़ाइन विभाग से बड़ी हैं। इसलिए जब छोटी टीमें पूछती हैं कि क्या डिज़ाइन सिस्टम बनाना चाहिए, तो असल सवाल यह होता है कि क्या इस विचार का कोई संस्करण उनके आकार में समाता है। समाता है — पर वह कॉन्फ्रेंस की प्रस्तुतियों जैसा नहीं दिखता।
शुरुआत टोकन से करें, कंपोनेंट से नहीं। रंग, टाइप स्केल, स्पेसिंग इकाइयाँ, बॉर्डर रेडियस और शैडो — एक फ़ाइल में वेरिएबल की तरह दर्ज, जिसे डिज़ाइनर और डेवलपर दोनों कानून मानें। टोकन बनाना सस्ता है, निभाना लगभग मुफ़्त, और एक भी कंपोनेंट बनने से पहले ही वे सबसे दिखने वाली असंगतियाँ चुपचाप ठीक कर देते हैं।
कंपोनेंट माँग पर बनाएँ, पहले से कभी नहीं। छोटी टीमों के डिज़ाइन सिस्टम का कब्रिस्तान उन बटन-लाइब्रेरियों से भरा है जो किसी उत्साही स्प्रिंट में बनीं और सर्दियों तक लावारिस हो गईं। हमारा नियम: कोई पैटर्न साझा कंपोनेंट तब बनता है जब वह दूसरी बार चाहिए हो — पहली बार नहीं, और काल्पनिक पाँचवीं बार भी नहीं। सिस्टम ठीक उतनी तेज़ी से बढ़ता है जितना प्रोडक्ट साबित करता है।
डॉक्यूमेंटेशन कोड के पास रहे, वरना मर जाता है। हमने अलग डिज़ाइन-सिस्टम साइट आज़माई; महीने भर में पुरानी पड़ गई। जो काम करता है वह है हर कंपोनेंट के ऊपर टिप्पणी-खंड और टोकन की एक पठनीय सूची वाला अकेला पेज। उबाऊ, काम के नज़दीक — और इसीलिए वाकई निभाया जाता है।
छोटी टीम के लिए गवर्नेंस एक वाक्य है: साझा कंपोनेंट में किसी भी बदलाव पर एक और व्यक्ति नज़र डाले। कमेटी नहीं, रिव्यू बोर्ड नहीं — एक सहकर्मी। इतना घर्षण लापरवाह बदलाव रोकने को काफ़ी है, और इतना कम है कि लोग नियम के इर्द-गिर्द रास्ता निकालने की बजाय उसका पालन करते हैं।
नतीजे ने हमें चौंकाया। लक्ष्य एकरूपता था, पर इनाम रफ़्तार निकली — नए पेज घंटों में उन हिस्सों से जुड़ जाते हैं जो उबाऊ सवालों के जवाब पहले से जानते हैं। छोटे पैमाने पर डिज़ाइन सिस्टम पूर्णता का इंफ्रास्ट्रक्चर नहीं — एक ही निर्णय दोबारा कभी न लेने की मशीन है।
इस पोस्ट से जुड़ी किसी चीज़ में मदद चाहिए?
हमारे इंजीनियर सीधे जवाब देते हैं — होस्टिंग, डेटाबेस, कोड, या इस पोस्ट से जुड़ा कुछ भी।