सेटिंग्स पेज की समस्या
सेटिंग्स पेज वह जगह है जहाँ प्रोडक्ट की ईमानदारी दम तोड़ देती है। पाँच आर्किटाइप, छह नियम, Linear, Notion और Vercel के असली उदाहरण, और एक ऑडिट जिससे आप सीधे शिप कर सकते हैं।
सेटिंग्स पेज आपके प्रोडक्ट की सबसे ईमानदार स्क्रीन है। एक ही स्क्रोल में यह दिखा देता है कि टीम ने कौन-से फ़ैसले लेने से इनकार किया। हर टॉगल एक जमा हुआ झगड़ा है। हर नेस्टेड टैब एक "बाद में देख लेंगे" है जिसे किसी ने कभी नहीं देखा।
ज़्यादातर सेटिंग्स पेज कचरे के ढेर हैं। तीन साल के टॉगल, जो उन इंजीनियरों ने डाले जो ना नहीं कह पाए, उन मार्केटर्स ने डाले जिन्हें ऑप्ट-आउट चाहिए था, और उन PM ने डाले जो "फ़ैसला करो" की जगह "इसे configurable बना दो" कहते रहे। नतीजा: एक स्क्रीन जिसे डेमो करने में टीम शर्मिंदा होती है और जिसे छूने से यूज़र डरता है।
यह सेटिंग्स को एक फ़र्स्ट-क्लास प्रोडक्ट सतह मानने की पैरवी है। पाँच आर्किटाइप, छह नियम, उन प्रोडक्ट्स के असली उदाहरण जिन्हें आप रोज़ इस्तेमाल करते हैं, और शिप करने से पहले चलाने के लिए एक ऑडिट।
सेटिंग्स वह स्क्रीन है जो टीम को बेनकाब करती है
Settings sprawl संगठनात्मक गड़बड़ी का एक leading संकेतक है। जब टीम किसी डिफ़ॉल्ट पर सहमत नहीं हो पाती, टॉगल शिप हो जाता है। जब कस्टमर शिकायत करे और कोई पलटकर मना न करना चाहे, टॉगल शिप हो जाता है। जब PM दो फ़्लो में से एक नहीं चुन पाता, दोनों एक सेटिंग के पीछे शिप हो जाते हैं।
छह महीने बाद किसी को याद नहीं रहता कि आधे टॉगल क्यों हैं। किसी सेटिंग को हटाने के लिए वही फ़ैसला चाहिए जिससे टीम पहली बार बची थी, इसलिए वे जमा होते जाते हैं। तीन साल से ज़्यादा पुराना कोई भी प्रोडक्ट देखिए, सेटिंग्स ट्री में आप न लिए गए फ़ैसले गिन सकते हैं।
बुरे सेटिंग्स पेज के पाँच आर्किटाइप
बुरे सेटिंग्स पेज बेतरतीब नहीं होते। वे पाँच पैटर्न में आते हैं, और हर एक किसी खास तरह के संगठनात्मक आलस्य का अंतिम पड़ाव है।
1. डंप
कालक्रम से जमा होता ढेर। सेटिंग्स उसी क्रम में दिखती हैं जिसमें जोड़ी गईं, कभी ग्रुप नहीं होतीं। सबसे नया feature flag 2019 की एक नोटिफ़िकेशन पसंद के बगल में बैठा है, जिसके बगल में एक बीटा टॉगल है जिसे दो साल पहले ग्रैजुएट हो जाना था। Cursor इसी तरफ़ फिसल रहा है। हर रिलीज़ General टैब में तीन टॉगल जोड़ती है, और General टैब अब असंबंधित फ़ैसलों का 40 पंक्तियों का स्क्रोल बन चुका है। डंप हर उस सेटिंग्स पेज की डिफ़ॉल्ट हालत है जिसे कोई सक्रिय रूप से डिज़ाइन नहीं कर रहा।
2. स्प्रेडशीट
वर्णमाला क्रम की पसंदें। टीम ने हायरार्की छोड़ दी और छँटाई OS पर डाल दी। हर टॉगल का वज़न बराबर, हर पंक्ति एक जैसी। Slack की नोटिफ़िकेशन पसंदें यहीं रहती हैं। साउंड, बैज, मोबाइल, चैनल, कीवर्ड, डू-नॉट-डिस्टर्ब, शेड्यूल, कस्टम, सब एक दीवार में चपटे कर दिए गए, इस कहानी के बिना कि कौन-सी ज़रूरी हैं।
3. डेड-एंड
ऐसी सेटिंग्स जो कुछ भी दिखने लायक नहीं बदलतीं। यूज़र "Compact mode" पलटता है और स्क्रीन वैसी ही दिखती है। "Enable advanced features" पलटता है और कुछ नहीं उभरता। macOS पर Apple के System Settings रीडिज़ाइन ने इनकी एक पूरी पीढ़ी शिप की: ऐसी सेटिंग्स जो चुपचाप दूसरी सेटिंग्स से ओवरराइड हो जाती हैं, ऐसी सेटिंग्स जिन्हें रीस्टार्ट चाहिए और स्क्रीन इसका ज़िक्र तक नहीं करती। डेड-एंड यूज़र को सिखाता है कि सेटिंग्स काम नहीं करतीं, और फिर वे बाकी प्रोडक्ट पर भी भरोसा करना छोड़ देते हैं।
4. भूलभुलैया
नेस्टेड टैब्स के दस स्तर। सेटिंग्स किसी कैटेगरी, सब-कैटेगरी, "Advanced" डिस्क्लोज़र और एक मॉडल के नीचे दबी हुई। यूज़र जानता है कि टॉगल मौजूद है, पहले पलट चुका है, फिर भी उसे ढूँढ नहीं पाता। पुराने Jira ने इसी पर पूरा करियर बनाया: प्रोजेक्ट, बोर्ड, वर्कफ़्लो, स्कीम, परमिशन स्कीम, नोटिफ़िकेशन स्कीम, सब अलग-अलग ट्री।
5. संग्रहालय
ऐसी सेटिंग्स जिन्हें तीन साल से किसी ने छुआ नहीं। वे इसलिए बची हैं कि हटाना जोखिम भरा लगता है। वे उन फ़ीचर्स का हवाला देती हैं जो 2023 में बंद हो गए। हर पुराने SaaS प्रोडक्ट में एक संग्रहालय विंग होता है, और कीमत यह है कि टीम उन कोड पाथ्स को सँभालने का वादा निभाती रहती है जिन्हें दो रीफ़ैक्टर पहले मार देना चाहिए था।
सेटिंग्स प्रोडक्ट की सतह है, कोई अलमारी नहीं
ज़्यादातर टीमें सेटिंग्स को वह जगह मानती हैं जहाँ बाकी प्रोडक्ट की सफ़ाई का बचा-खुचा काम निपटाया जाता है। यही सोच बग है। सेटिंग्स प्रोडक्ट की सबसे ज़्यादा असर वाली सतहों में से एक है, और सबसे मज़बूत टीमें इसे वैसे ही डिज़ाइन करती हैं।
सेटिंग्स यूज़र के बारे में प्रोडक्ट का नज़रिया बताती हैं। वे एक साथ चार बातें कहती हैं। टीम यूज़र पर कितना भरोसा करती है। टीम कितना कंट्रोल साझा करने को तैयार है। टीम के हिसाब से सही डिफ़ॉल्ट क्या हैं। और क्या टीम यूज़र के समय की इतनी इज़्ज़त करती है कि उन 5% के लिए डिज़ाइन करे जो डिफ़ॉल्ट बदलते हैं, बिना उन 95% को सज़ा दिए जो नहीं बदलते।
Linear ने सेटिंग्स को एक सिंगल सर्च सतह की तरह डिज़ाइन किया, command-K से चलने वाली, लगभग बिना नेस्टेड टैब के। छिपा संदेश: यूज़र सक्षम है, सर्च तेज़ है, हायरार्की का काम टीम ने कर दिया ताकि यूज़र को न करना पड़े। Notion उलटी दिशा में गया और उसी तरह जीता। सेटिंग्स उस चीज़ के बगल में रहती हैं जिसे वे प्रभावित करती हैं। पेज की सेटिंग्स पेज पर। डेटाबेस की सेटिंग्स डेटाबेस पर। Contextual settings काम में घुल जाती हैं।
Vercel स्कोप्ड हायरार्की इस्तेमाल करता है: प्रोजेक्ट, टीम और अकाउंट, हर एक साफ़ लेबल वाला, हर एक उस रिसोर्स तक सीमित जिसे वह चलाता है। Stripe Dashboard एक्शन-केंद्रित है, जहाँ हर स्क्रीन "यह काम करो" है, "यह पसंद कॉन्फ़िगर करो" नहीं। GitHub की repo सेटिंग्स स्कोपिंग बढ़िया निभाती हैं, repo, org और अकाउंट मालिकाने के बीच साफ़ अलगाव के साथ।
छह नियम जो हर सेटिंग्स पेज का फ़ैसला करते हैं
ये नियम मिलकर असर बढ़ाते हैं। छह में से पाँच पर खरे उतरें तो पेज प्रोडक्ट की सतह जैसा पढ़ा जाता है। तीन पर उतरें तो एक साल के भीतर वह किसी आर्किटाइप में फिसल जाता है।
नियम 1: पहले सर्च
हायरार्की एक फ़ॉलबैक है, प्राथमिक नहीं। यूज़र को सेटिंग का नाम पहले पता होता है, यह बाद में कि वह किस टैब में रहती है। Linear का command-K सेटिंग्स को पहले दर्जे के रिज़ल्ट टाइप की तरह कवर करता है। Figma ने सेटिंग्स सर्च जोड़ी और टॉगल तक पहुँचने का समय तुरंत घट गया। अगर आपके सेटिंग्स पेज में सर्च बार नहीं है, तो आप दाँव लगा रहे हैं कि यूज़र आपका information architecture रट लेंगे। वे नहीं रटेंगे।
नियम 2: केंद्रीय रजिस्ट्री की जगह संदर्भ के पास जगह
सेटिंग्स उस चीज़ के बगल में रहती हैं जिसे वे प्रभावित करती हैं। नोटिफ़िकेशन सेटिंग्स नोटिफ़िकेशन पैनल में। पेज सेटिंग्स पेज पर। केंद्रीय सेटिंग्स पेज अकाउंट-स्तर की चिंताओं जैसे प्रोफ़ाइल, बिलिंग और सेशन के लिए ठीक है, और लगभग किसी चीज़ के लिए नहीं। Notion गोल्ड स्टैंडर्ड है। Figma का राइट-रेल लेयर, फ़्रेम और कंपोनेंट प्रॉपर्टीज़ के लिए यही काम करता है।
नियम 3: समझदार डिफ़ॉल्ट जो भरोसा कमाएँ
हर डिफ़ॉल्ट एक प्रोडक्ट फ़ैसला है। वह बताता है कि टीम के हिसाब से 80% यूज़र्स के लिए सही जवाब क्या है। अगर डिफ़ॉल्ट ग़लत है, तो टॉगल एक पट्टी है। Slack के नोटिफ़िकेशन डिफ़ॉल्ट मानकर चलते हैं कि आप पहुँच में रहना चाहते हैं, चुप नहीं। औसत यूज़र के लिए यह दाँव सही है। ज़्यादातर टीमें पहले टॉगल डिज़ाइन करती हैं और डिफ़ॉल्ट को अपने-आप निकलने देती हैं। यह क्रम ग़लत है।
नियम 4: सपाट फैलाव की जगह Progressive disclosure
यूज़र को वे पाँच सेटिंग्स दिखनी चाहिए जिनकी 90% यूज़र्स परवाह करते हैं। बाकी 50 एक क्लिक गहरे, साफ़ "Advanced" संकेत के पीछे रहें। Vercel की प्रोजेक्ट सेटिंग्स यह बखूबी निभाती हैं। पहली स्क्रीन पर डोमेन, environment variables और डिप्लॉयमेंट प्रोटेक्शन दिखते हैं। बिल्ड ओवरराइड, फ़ंक्शन कॉन्फ़िग और रीराइट्स Advanced में रहते हैं।
नियम 5: कोई अनाथ नहीं
हर सेटिंग किसी ग्रुप की है। हर ग्रुप का एक नाम है। अनाथ टेस्ट: कोई भी लेबल बिना किसी और संदर्भ के ज़ोर से पढ़ें। अगर आपकी टीम का कोई डिज़ाइनर बता नहीं सकता कि टॉगल क्या करता है, तो वह अनाथ है। अनाथ संग्रहालय के अंकुर हैं।
नियम 6: हर सेटिंग अपनी जगह कमाए
सेटिंग एक अनुबंध है। टीम उसे हमेशा के लिए सँभालने, दस्तावेज़ करने, टेस्ट करने और बाकी हर सेटिंग के साथ उसके इंटरैक्शन पर सोचने का वादा करती है। ज़्यादातर सेटिंग्स यह किराया नहीं चुका सकतीं। किसी भी नई सेटिंग पर डिफ़ॉल्ट जवाब "नहीं" होना चाहिए। अच्छी टीमें शिप करने से ज़्यादा सेटिंग्स मारती हैं।
वे एंटी-पैटर्न जो बताते हैं कि गड़बड़ कहीं गहरी है
तीन पैटर्न बाकी सब मिलाकर जितने सेटिंग्स पेज मारते हैं, उससे ज़्यादा मारते हैं। हर एक इस बात का लक्षण है कि समस्या स्क्रीन नहीं, उसके पीछे की टीम है।
फ़ैसलों की जगह सेटिंग्स। टीम ऑप्ट-इन या ऑप्ट-आउट पर सहमत नहीं हो सकी, तो उसने टॉगल बनाकर शिप कर दिया। यूज़र को अनसुलझा झगड़ा विरासत में मिलता है। अगर आप स्टैंडअप में "चलो इसे configurable बना देते हैं" सुनें, तो आप यह एंटी-पैटर्न बनते देख रहे हैं। इसकी गहरी पड़ताल जानबूझकर फ़्रिक्शन डिज़ाइन करने में है।
बुरे डिज़ाइन की भरपाई करती सेटिंग्स। "Compact mode" टॉगल, क्योंकि डिफ़ॉल्ट डेंसिटी बहुत ढीली है। "High contrast" टॉगल, क्योंकि ब्रांड रंग एक्सेसिबिलिटी में फ़ेल हैं। "Classic view" टॉगल, क्योंकि रीडिज़ाइन ठुकरा दिया गया। हर एक असली सुधार है जिसे विकल्प का जामा पहनाया गया। इलाज यह है कि डेंसिटी, कॉन्ट्रास्ट और व्यू पहली बार में ही सही डिज़ाइन करें।
ऐसी सेटिंग्स जिन्हें कोई एक वाक्य में समझा न सके। अगर कोई डिज़ाइनर यह न बता सके कि सेटिंग क्या करती है, पलटने पर क्या बदलता है और यह किसके लिए है, तो वह सेटिंग शिप नहीं होनी चाहिए। कोई भी नया टॉगल कोडबेस में पहुँचने से पहले यह टेस्ट चलाएँ।
सेटिंग्स पेज ऑडिट
हर सेटिंग्स पेज को इन सात सवालों से गुज़ारें। छह पर पक्का हाँ न मिले तो पेज पूरा नहीं है।
- क्या यूज़र किसी भी सेटिंग को पाँच सेकंड से कम में ढूँढ सकता है? अगर नहीं, तो पेज में सर्च नहीं है या हायरार्की टूटी है।
- क्या हर सेटिंग का एक वाक्य का विवरण है जिसे ग़ैर-इंजीनियर समझ ले? अगर लेबल समझाने के लिए इंजीनियर चाहिए, तो वह प्रोडक्ट सतह पर नहीं होना चाहिए।
- क्या टॉगल पलटने से दिखने वाला, तुरंत असर होता है? छिपे हुए स्टेट बदलाव भरोसा मारते हैं।
- क्या सेटिंग्स यूज़र के काम के हिसाब से ग्रुप हैं, फ़ीचर टीम के हिसाब से नहीं? जो पेज इस आधार पर बना हो कि फ़ीचर किस टीम का है, वह प्रोडक्ट में रिसता हुआ आंतरिक ढाँचा है। यूज़र के लक्ष्य के हिसाब से ग्रुप करें।
- क्या डिफ़ॉल्ट कहीं लिखित रूप में सही ठहराए गए हैं? टीम किसी दस्तावेज़, किसी visual hierarchy फ़ैसले या ब्रांड सिद्धांत की ओर इशारा कर सके। अगर डिफ़ॉल्ट "जो इंजीनियर ने स्प्रिंट में सेट कर दिया" है, तो पेज पूरा नहीं है।
- क्या आप आधी सेटिंग्स हटा सकते हैं और यूज़र को पता भी न चले? अगर हाँ, तो हटाइए। संग्रहालय टीम के सोचने से ज़्यादा भारी है।
- क्या पेज बाकी प्रोडक्ट जैसा दिखता और महसूस होता है? इसे अपने landing page design principles के बगल में रखकर पढ़ें। अगर ब्रांड बिखर जाए, तो सेटिंग्स पेज ब्रांड से बाहर है।
जो टीम साल में दो बार यह ऑडिट चलाती है, वह ऐसी सेटिंग्स सतह शिप करती है जिससे यूज़र सहमते नहीं। जो टीम इसे कभी नहीं चलाती, वह ऐसा सेटिंग्स पेज शिप करती है जो प्रतिस्पर्धी के लिए भर्ती का औज़ार बन जाता है।
सिद्धांत चुनिए, फिर पेज की छँटाई कीजिए
सेटिंग्स टीम का नज़रिया हैं, टॉगल में जमा हुई। अच्छी टीमें पेज को पहले दर्जे का फ़्लो मानती हैं, उसी कारीगरी के साथ जो वे ऑनबोर्डिंग, डैशबोर्ड और मार्केटिंग साइट में लगाती हैं।
सेटिंग्स पेज सुधारने का सबसे तेज़ तरीका उसे रीडिज़ाइन करना नहीं है। उसका आधा हिस्सा हटा देना है। हर वह सेटिंग हटाइए जो अनाथ टेस्ट, एक-वाक्य टेस्ट और अपनी-जगह-कमाओ टेस्ट में फ़ेल हो। जो बचता है, वही असली सेटिंग्स सतह की रीढ़ है।
Empty states से रिश्ता संयोग नहीं है। दोनों स्क्रीन दिखाती हैं कि जब ध्यान भटकाने को और कुछ स्क्रीन पर नहीं होता, तब टीम क्या मानती है। यही अनुशासन web design principles में भी दिखता है।
अक्सर पूछे जाने वाले सवाल
एक प्रोडक्ट में कितनी सेटिंग्स होनी चाहिए?
जितनी कम से कम हो सकें। हर सेटिंग एक अनुबंध है जिसे टीम हमेशा सँभालती है। किसी भी नई सेटिंग पर डिफ़ॉल्ट जवाब "नहीं" होना चाहिए। अगर टीम सेटिंग को एक वाक्य में सही नहीं ठहरा सकती, उस यूज़र का नाम नहीं बता सकती जिसकी वह सेवा करती है, और यह नहीं बता सकती कि पलटने पर क्या दिखने लायक बदलता है, तो सेटिंग शिप नहीं होनी चाहिए।
सेटिंग्स प्रोडक्ट में कहाँ होनी चाहिए?
उस चीज़ के बगल में जिसे वे प्रभावित करती हैं, किसी केंद्रीय सेटिंग्स विंग में नहीं। पेज सेटिंग्स पेज पर। वर्कस्पेस सेटिंग्स वर्कस्पेस पर। नोटिफ़िकेशन सेटिंग्स नोटिफ़िकेशन पैनल में। केंद्रीय सेटिंग्स पेज बिलिंग, प्रोफ़ाइल और सेशन जैसी अकाउंट-स्तर की चिंताओं के लिए ठीक है, और लगभग किसी चीज़ के लिए नहीं।
सालों के जमा टॉगल वाले सेटिंग्स पेज को कैसे साफ़ करूँ?
ऑडिट चलाइए, फिर हटाइए। हर सेटिंग को यूज़र के काम के हिसाब से ग्रुप कीजिए। अनाथ, डेड-एंड और संग्रहालय के टुकड़े पहचानिए। पहले दौर में नीचे के 30% हटाइए और सपोर्ट टिकट देखिए। अगर कोई शिकायत न करे, तो 20% और हटाइए।
सेटिंग्स पेज को होमपेज की तरह डिज़ाइन कीजिए
सेटिंग्स पेज कोई तहखाना नहीं है। यह वह कमरा है जिसमें आपके पावर यूज़र रहते हैं, और जिससे नए यूज़र आपको परखते हैं। इसे होमपेज, ऑनबोर्डिंग और डैशबोर्ड की तरह बरतिए। वही कारीगरी लगाइए। उसी दृढ़ता से शिप कीजिए।
अगर आप ऐसी टीम चाहते हैं जो सेटिंग्स पेज को बाकी प्रोडक्ट की तरह डिज़ाइन करे, बैकलॉग से विरासत में लेने की जगह, तो Brainy को हायर करें। हम सेटिंग्स को फ़र्स्ट-क्लास फ़्लो की तरह डिज़ाइन करते हैं, उस अनुशासन के साथ जो पेज को छोटा और टॉगल को अपना किराया चुकाता रखता है।
Want a settings surface that reads like the product instead of the bug tracker? Brainy designs settings as a first-class flow, not a graveyard.
Get Started
