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