लोडिंग स्टेट ही प्रोडक्ट है
लोडिंग स्टेट वह स्क्रीन है जिसे आपके यूज़र सबसे ज़्यादा देखते हैं। पाँच आर्कटाइप, Linear, Vercel, Stripe, Cursor, Claude और Figma के असली उदाहरण, और छह सवालों का ऑडिट जो आप आज ही चला सकते हैं।
आपका प्रोडक्ट साल भर में जितने भी लोडिंग स्टेट दिखाता है, उन सबको जोड़ लीजिए। हर यूज़र, हर सेशन, हर रिफ्रेश। यूज़र-घंटों में वह संख्या आपकी शिप की हुई सबसे ज़्यादा देखी जाने वाली स्क्रीन है। ज़्यादातर टीमें इसे ऐसे ट्रीट करती हैं जैसे कोई देख ही नहीं रहा।
डैशबोर्ड का डिज़ाइन रिव्यू होता है। एम्प्टी स्टेट का भी होता है, अगर आपने एम्प्टी स्टेट ही प्रोडक्ट हैं पढ़ा है। लोडिंग स्टेट को मिलता है 2012 की स्टाइलशीट का 16 पिक्सल का स्पिनर और एक दुआ। यह वह स्क्रीन है जो यूज़र को हमेशा दिखती है, और जिसे कोई डिज़ाइन नहीं करता।
लोडिंग स्टेट एक ब्रांड इम्प्रेशन है
हर लोडिंग स्टेट एक भरोसे का कॉन्ट्रैक्ट है। प्रोडक्ट यूज़र से कह रहा है: "मैं काम कर रहा हूँ, क्रैश नहीं हुआ, यह इंतज़ार जानबूझकर है।" इसके बाद स्क्रीन जो भी कहे, वही बन जाता है कि ब्रांड दबाव में कैसे पेश आता है।
Linear के लोडिंग स्टेट Linear जैसे ही लगते हैं। इश्यू लिस्ट के आकार की स्केलेटन रो, सर्वर के कन्फर्म करने से पहले कमिट होने वाला इनलाइन क्रिएट, सोची-समझी लय वाले ब्रांडेड ट्रांज़िशन। Stripe के Stripe जैसे लगते हैं। पे-बटन की शिमर, डैशबोर्ड में कार्ड के आकार की स्केलेटन, फाइनल स्टेट में बदलती रसीद। दोनों इंतज़ार को ही प्रोडक्ट मानते हैं।
खराब वर्ज़न है सफ़ेद बैकग्राउंड पर घूमता पुराना gif। न कंटेंट का आकार, न प्रोग्रेस का संकेत, न ब्रांड। यूज़र को कहा जा रहा है "हम व्यस्त हो गए और भूल गए कि आप यहाँ हैं।" यह भी एक ब्रांड इम्प्रेशन है। बस वह नहीं जो टीम शिप करना चाहती थी।
लोडिंग स्टेट के पाँच आर्कटाइप
ज़्यादातर टीमें "लोडिंग स्टेट" को एक ही डिज़ाइन समस्या मानती हैं। असल में यह पाँच हैं। हर एक अलग तरह के इंतज़ार में फिट होता है और अलग वजह से फेल होता है।
1. स्केलेटन स्क्रीन
एक प्लेसहोल्डर लेआउट जो अंतिम कंटेंट के आकार की नकल करता है। जहाँ रो आएँगी वहाँ रो, जहाँ कार्ड आएँगे वहाँ कार्ड। कंटेंट आने से पहले ही आँख ढाँचे पर टिक जाती है, और इंतज़ार शुरू होने जैसा नहीं, सुलझने जैसा लगता है।
Linear की इश्यू लिस्ट में रो के आकार की स्केलेटन होती हैं जो अंतिम लिस्ट से पिक्सल-दर-पिक्सल मेल खाती हैं। Stripe Dashboard के मेट्रिक्स सेक्शन में कार्ड के आकार की स्केलेटन होती हैं जो भरे हुए कार्ड में बदल जाती हैं। Notion में ब्लॉक के आकार के प्लेसहोल्डर होते हैं जो डॉक लोड होते ही असली ब्लॉक बन जाते हैं। वादा एक ही है: लोडिंग का आकार अंतिम आकार का अनुमान देता है।
कब इस्तेमाल करें: जब ढाँचा पहले से पता हो। कब छोड़ें: जब लेआउट इतना डायनामिक हो कि स्केलेटन आगे क्या आएगा इस बारे में झूठ बोलेगी।
2. ऑप्टिमिस्टिक UI
यूज़र का एक्शन सर्वर के कन्फर्म करने से पहले ही तुरंत रेंडर कर दें। बैकग्राउंड में मिलान करें। सर्वर सहमत हो तो UI में झिलमिलाहट नहीं होती। असहमत हो तो UI एक दिखने वाले undo रास्ते के साथ रोलबैक करता है।
Linear का इनलाइन इश्यू क्रिएशन गोल्ड स्टैंडर्ड है। C दबाइए, टाइटल लिखिए, एंटर मारिए, राउंड-ट्रिप पूरा होने से पहले इश्यू लिस्ट में मौजूद है। Figma के कर्सर और सिलेक्शन मूव पूरे मल्टीप्लेयर सेशन में ऑप्टिमिस्टिक हैं। यूज़र को नेटवर्क कभी महसूस ही नहीं होता।
कब इस्तेमाल करें: जब फेल होना दुर्लभ और पलटने लायक हो। कब छोड़ें: जब एक्शन विनाशकारी हो या यूज़र को आगे बढ़ने से पहले सर्वर का जवाब चाहिए।
3. स्ट्रीमिंग पार्शियल
पहला हिस्सा तभी रेंडर कर दें जब बाकी अभी तार पर हो। इंतज़ार आउटपुट में घुल जाता है क्योंकि यूज़र पहले से नतीजा पढ़ रहा होता है।
Claude की टोकन स्ट्रीम अब तक शिप हुआ सबसे साफ़ उदाहरण है, जिसकी स्मूद लय इंसानी रफ़्तार से पढ़ी जाती है। Cursor डिफ़ को टोकन-दर-टोकन स्ट्रीम करता है, तो मॉडल के लिखना खत्म करने से पहले ही यूज़र कोड पढ़ रहा होता है। Vercel डिप्लॉय लॉग लाइव स्ट्रीम करता है, तो यूज़र बिल्ड का इंतज़ार नहीं करता, उसे होते देखता है। बड़ी लेटेंसी रणनीति के लिए AI लेटेंसी के लिए डिज़ाइन वाला लेख पढ़ें।
कब इस्तेमाल करें: जब नतीजे की एक स्वाभाविक लय हो। कब छोड़ें: जब टुकड़े अकेले किसी काम के न हों।
4. कंटेंट के रूप में प्रोग्रेस
इंतज़ार खुद ही वैल्यू है। डिप्लॉय लॉग, बिल्ड पाइपलाइन, एजेंट का रीज़निंग ट्रेस। यूज़र नतीजे का इंतज़ार नहीं कर रहा। वह नतीजा पढ़ रहा है।
Vercel का डिप्लॉय व्यू इसका मानक उदाहरण है। डिप्लॉय लॉग ही लोडिंग स्टेट है, और प्लेटफ़ॉर्म की सबसे ज़्यादा शिप होने वाली स्क्रीन भी। GitHub Actions स्टेप-बाय-स्टेप रन आउटपुट के साथ यही करता है। Cursor का एजेंट पैनल काम करते हुए रीज़निंग ट्रेस दिखाता है, इसलिए कई मिनट का टास्क अटका हुआ नहीं, सार्थक लगता है। v0 और Lovable इसे प्रॉम्प्ट-से-ऐप सतहों पर शिप करते हैं, जहाँ बिल्ड-स्ट्रीमिंग ही लोडिंग स्टेट है और प्रीव्यू इनाम।
कब इस्तेमाल करें: जब इंतज़ार ही वैल्यू हो। कब छोड़ें: जब स्टेप्स उस यूज़र के काम के न हों जिसे सिर्फ़ अंतिम स्टेट से मतलब है।
5. ब्रांडेड स्पिनर
माइक्रो-पल्स, ग्रेडिएंट, शिमर। वह पल जब प्रोडक्ट अपना पर्सनैलिटी टोकन कमाता है। Stripe के पे-बटन की शिमर, Vercel का ग्रेडिएंट प्रोग्रेस बार, Linear का ट्रांज़िशनल इंतज़ार पर माइक्रो-पल्स। इनमें से कोई भी अकेला काम नहीं कर रहा। ये पहले चार पैटर्न में से किसी एक के ऊपर सवार होते हैं और पहले से ढाँचे वाले इंतज़ार में ब्रांड की पॉलिश जोड़ते हैं।
कब इस्तेमाल करें: जब इंतज़ार छोटा हो और सतह हाई-स्टेक्स हो। कब छोड़ें: जब पीछे कोई स्केलेटन या स्ट्रीम न हो। पहले चार में से किसी के बिना ब्रांडेड स्पिनर बस 1996 का स्पिनर है जिस पर 2026 का हेक्स कोड चिपका है।
स्केलेटन लगभग हर बार स्पिनर को हरा देती है
स्केलेटन आने वाली चीज़ का आकार बताती है। स्पिनर बस इतना बताता है कि कहीं कुछ हो रहा है। इंतज़ार वही, अनुभव दो अलग।
Stripe के डैशबोर्ड की स्केलेटन घड़ी पर स्पिनर वाले वर्ज़न से मुश्किल से तेज़ है, लेकिन महसूस होने वाली स्पीड का फ़र्क कहीं बड़ा है। यूज़र कार्ड के आकार का लेआउट देखता है और डेटा आने से पहले ही खुद को ओरिएंट करने लगता है। जब तक मेट्रिक्स आते हैं, आँख पहले से सही जगह पर होती है। स्पिनर के साथ यूज़र स्क्रीन के बीच में घूरता रहता है, कहीं और देखने की इजाज़त का इंतज़ार करते हुए। लेआउट का अनुमान लगा सकते हैं तो स्केलेटन शिप करें। नहीं लगा सकते तो स्टेटस लाइन शिप करें।
ऑप्टिमिस्टिक UI चीट कोड है
इंतज़ार अदृश्य हो जाता है क्योंकि इंतज़ार शुरू होने से पहले ही एक्शन कमिट हो चुका होता है।
Linear ने ऑप्टिमिस्टिक को हर जगह शिप किया। इश्यू बनाना, स्टेटस बदलना, असाइनी की अदला-बदली, लेबल जोड़ना, साइकिल मूव। हर एक इंटेंट पर लोकल स्टोर में लिखता है और सर्वर के जवाब के बाद मिलान करता है। Figma मल्टीप्लेयर कर्सर मूव, सिलेक्शन और ज़्यादातर एडिट पर ऑप्टिमिस्टिक है। Notion डॉक एडिट पर ऑप्टिमिस्टिक है। हर प्रोडक्ट लोकल सॉफ़्टवेयर जैसा लगता है क्योंकि नेटवर्क को ऑप्टिमिस्टिक परत के नीचे छिपा दिया गया है।
इसके काम करने के लिए दो चीज़ें ज़रूरी हैं। फेल होना दुर्लभ और पलटने लायक हो, वरना UI झिलमिलाता है और यूज़र का भरोसा उठ जाता है। और एरर दिखने चाहिए। जो ऑप्टिमिस्टिक एक्शन सर्वर एरर को चुपचाप निगल जाए, वह बिना ऑप्टिमिज़्म से भी बदतर है, क्योंकि वह यूज़र को सिखाता है कि एक्शन सफल रहा जबकि वह नहीं रहा। हर ऑप्टिमिस्टिक राइट के साथ undo, टोस्ट या ऐसा रोलबैक चाहिए जो यूज़र देख सके।
बेहतरीन लोडिंग स्टेट के पाँच नियम
पाँच में से चार पूरे करें तो इंतज़ार डिज़ाइन किया हुआ लगता है। तीन पर रुकें तो लोडिंग स्टेट बाद की सोच जैसा लगने लगता है।
- लोडिंग का आकार अंतिम आकार का अनुमान दे। रो के लिए स्केलेटन रो, कार्ड के लिए स्केलेटन कार्ड। कंटेंट आने पर लेआउट में कोई उछाल नहीं।
- जहाँ संभव हो, इंतज़ार को कंटेंट दें। टोकन स्ट्रीम करें, लॉग शिप करें, आंशिक नतीजा रेंडर करें। पढ़ता हुआ यूज़र इंतज़ार नहीं कर रहा।
- 800ms से लंबे हर इंतज़ार पर फ़ीडबैक मिले। 800ms से कम में साफ़ ट्रांज़िशन काफ़ी है। उससे ऊपर यूज़र को संकेत चाहिए कि सिस्टम ज़िंदा है, भले ही वह पहले ढाँचे, फिर कंटेंट का प्रोग्रेसिव डिस्क्लोज़र ही क्यों न हो।
- ऑप्टिमिस्टिक एक्शन को दिखने वाला undo रास्ता चाहिए। टोस्ट, रोलबैक, साफ़ एरर स्टेट। रिकवरी के बिना ऑप्टिमिज़्म गैसलाइटिंग है।
- ब्रांड की वजह के बिना कोई स्पिनर नहीं। ब्रांडेड स्पिनर पहले चार पैटर्न में से किसी एक के ऊपर सवार होते हैं, उनकी जगह कभी नहीं लेते। स्क्रीन पर अकेला स्पिनर है तो डिज़ाइन पूरा नहीं हुआ।
गहरा संदर्भ बड़े वेब डिज़ाइन सिद्धांतों के विश्लेषण में है, और इसमें भी कि core web vitals लेआउट शिफ्ट को महसूस होने वाली परफ़ॉर्मेंस की विफलता मानते हैं।
वे एंटी-पैटर्न जो लोडिंग स्टेट को मार देते हैं
छह फेल मोड ज़रूरत से ज़्यादा बार शिप होते हैं। हर एक सुधारा जा सकता है, और हर एक अभी कहीं न कहीं प्रोडक्शन में चल रहा है।
बिना प्रोग्रेस वाला अंतहीन स्पिनर। एक स्पिनर जो पंद्रह सेकंड से बिना किसी संकेत के घूम रहा है। यूज़र को नहीं पता कि रिक्वेस्ट ज़िंदा है, मर चुकी है या अटकी है। इसे स्टेटस लाइन, प्रोग्रेस बार या स्ट्रीमिंग सतह से बदलें।
पेज ब्लॉक करने वाला मोडल जिसे बंद नहीं किया जा सकता। एक लोडिंग मोडल जो पूरी स्क्रीन हाइजैक कर ले और यूज़र को स्क्रॉल, कॉपी या प्रोडक्ट का बाकी हिस्सा पढ़ने न दे। इंतज़ार बंधक संकट बन जाता है।
स्केलेटन के हल होने पर उछलने वाला लेआउट। एक स्केलेटन जो असली लेआउट से मेल नहीं खाती। रो खिसकती हैं, कार्ड दोबारा बहते हैं, हेडर हिल जाता है। स्केलेटन कोई अलग डिज़ाइन नहीं, वही डिज़ाइन है बस कंटेंट के बिना।
हमेशा चलता "Loading..." टेक्स्ट लूप। तीन घूमते डॉट, न प्रोग्रेस, न स्टेटस। यूज़र दो सेशन में इसे अनदेखा करना सीख जाता है, जो उस चैनल को मार देता है जिस पर सतह आगे कोई असली स्टेटस भेजेगी।
वह ऑप्टिमिस्टिक UI जो एरर चुपचाप निगल जाए। UI में एक्शन कमिट हो जाता है, सर्वर फेल होता है, प्रोडक्ट यूज़र को कभी बताता नहीं। इलाज है दिखने वाला टोस्ट, undo बटन या रोलबैक।
100ms के इंतज़ार पर ब्रांडेड स्पिनर। ऐसे इंतज़ार के लिए शिमर जो यूज़र के नोटिस करने से पहले खत्म हो जाए। शुद्ध ओवरहेड। तेज़ सतहें फ़ेड की हक़दार हैं। धीमी सतहें ढाँचे की।
जानबूझकर फ्रिक्शन डिज़ाइन करना उन दुर्लभ मामलों को कवर करता है जहाँ इंतज़ार जानबूझकर दिखना चाहिए। लोडिंग स्टेट वे नहीं हैं। ये वे इंतज़ार हैं जिन्हें अदृश्य होना चाहिए, डिज़ाइन होना चाहिए, या कंटेंट बन जाना चाहिए।
लोडिंग स्टेट ऑडिट
छह सवाल। अगली रिलीज़ से पहले हर लोडिंग सतह को इनसे गुज़ारें।
- क्या लोडिंग का आकार अंतिम आकार का अनुमान देता है? अनुमान लगाने लायक लेआउट के लिए स्केलेटन, अनिश्चित के लिए स्टेटस लाइन। हल होने पर लेआउट में उछाल नहीं।
- क्या इंतज़ार जानकारी ले जा रहा है? स्केलेटन, स्ट्रीम, प्रोग्रेस लॉग, स्टेटस लाइन। 800ms से लंबा कोई भी इंतज़ार जिस पर कुछ नहीं है, एक रिसाव है।
- क्या हर इंतज़ार के लिए एक ही मुख्य संदेश है? "डैशबोर्ड लोड हो रहा है" चार आपस में टकराते संकेतों से बेहतर है। एक संकेत, और विज़ुअल हायरार्की काम करती हुई।
- क्या लोडिंग स्टेट ब्रांड वॉइस से मेल खाता है? लोडिंग कॉपी को भरी हुई स्क्रीन के बगल में पढ़ें। टोन बदलता है तो लोडिंग स्टेट किसी और ब्रांड का चोला पहने है।
- क्या ऑप्टिमिस्टिक एक्शन पलटने लायक हैं और फेल होने पर दिखते हैं? हर ऑप्टिमिस्टिक राइट के साथ undo, टोस्ट या रोलबैक है। कोई साइलेंट फेल्योर नहीं।
- क्या लोडिंग स्क्रीन किसी अजनबी को प्रोडक्ट बेच पाएगी? अगर उन्होंने सिर्फ़ लोडिंग स्टेट ही देखी होती, तो क्या वह उस प्रोडक्ट जैसी लगती जिसके लिए उन्होंने साइन अप किया? नहीं, तो आपके ऐप की सबसे ज़्यादा देखी जाने वाली स्क्रीन सबसे खराब डिज़ाइन की हुई भी है।
जिस प्रोडक्ट का हर लोडिंग स्टेट इन छहों को पास करे, वह धीमे नेटवर्क पर भी तेज़ लगता है।
पैटर्न चुनिए, फिर इंतज़ार शिप कीजिए
लोडिंग स्टेट पॉलिश की परत नहीं हैं। ये ब्रांड की परत, भरोसे की परत और महसूस होने वाली परफ़ॉर्मेंस की परत हैं, जो उस स्क्रीन में सिमट गई हैं जिसे यूज़र किसी भी और स्क्रीन से ज़्यादा देखता है। हर इंतज़ार एक डिज़ाइन चुनाव है, चाहे टीम ने जानबूझकर चुना हो या नहीं।
जहाँ ढाँचा पता है वहाँ स्केलेटन। जहाँ फेल होना पलटने लायक है वहाँ ऑप्टिमिस्टिक। जहाँ नतीजे की लय है वहाँ स्ट्रीमिंग। जहाँ इंतज़ार ही वैल्यू है वहाँ कंटेंट के रूप में प्रोग्रेस। ब्रांडेड स्पिनर सिर्फ़ तब जब पहले चार अपना काम कर रहे हों। लैंडिंग पेज डिज़ाइन सिद्धांत का विश्लेषण इसी अनुशासन का मार्केटिंग-पेज वर्ज़न है।
लोडिंग स्टेट को धीमे होने की माफ़ी की तरह ट्रीट करना बंद कीजिए। कुल मिलाकर, यही प्रोडक्ट है। इंतज़ार को उनके समय के लायक बनाइए।
FAQ
स्केलेटन स्क्रीन और लोडिंग स्पिनर में क्या फ़र्क है?
स्केलेटन प्लेसहोल्डर लेआउट के साथ अंतिम कंटेंट के आकार का अनुमान देती है, इसलिए डेटा आने से पहले ही यूज़र खुद को ओरिएंट करने लगता है। स्पिनर बस संकेत देता है कि कुछ हो रहा है, बिना आकार, बिना ढाँचे, बिना प्रीव्यू के। स्केलेटन महसूस होने वाला इंतज़ार घटाती हैं। स्पिनर नहीं घटाते।
ऑप्टिमिस्टिक UI और स्ट्रीमिंग रिस्पॉन्स में से कब क्या इस्तेमाल करूँ?
ऑप्टिमिस्टिक UI तब जब यूज़र का एक्शन ही काम हो, जैसे इश्यू जोड़ना, स्टेटस टॉगल करना या कार्ड मूव करना। स्ट्रीमिंग तब जब काम सर्वर कर रहा हो और नतीजे की स्वाभाविक लय हो, जैसे टेक्स्ट जनरेशन, लॉग आउटपुट या डिप्लॉय पाइपलाइन। दोनों साथ चल सकते हैं।
क्या कभी सादा स्पिनर शिप करना ठीक है?
सिर्फ़ एक सेकंड से कम के फ़ॉलबैक के रूप में, सिर्फ़ तब जब लेआउट सचमुच अनिश्चित हो, और सिर्फ़ ब्रांड की किसी वजह के साथ। स्केलेटन, स्टेटस लाइन या स्ट्रीमिंग सतह हर परसीव्ड-परफ़ॉर्मेंस मेट्रिक पर स्पिनर को हराती है। डिफ़ॉल्ट रखें: स्पिनर सबसे आख़िर में।
इंतज़ार डिज़ाइन कीजिए, प्रोडक्ट शिप कीजिए
इंतज़ार वह स्क्रीन है जो यूज़र सबसे ज़्यादा देखता है। सबसे अधिक बार मिलने वाला ब्रांड इम्प्रेशन, सबसे अधिक बार पढ़ा जाने वाला भरोसे का संकेत, और हर पेज लोड पर चलने वाला परसीव्ड-परफ़ॉर्मेंस टेस्ट। जो टीम डैशबोर्ड पर छह हफ़्ते और लोडिंग स्टेट पर एक दोपहर लगाती है, वह काम का गलत अनुपात उस जगह शिप कर रही है जहाँ यूज़र असल में रहता है।
अगर आप ऐसी टीम चाहते हैं जो लोडिंग स्टेट को लॉन्च से पहले की आख़िरी स्प्रिंट के बजाय प्रोडक्ट का हिस्सा मानकर डिज़ाइन करे, तो Brainy को हायर करें। हम ऐसे प्रोडक्ट शिप करते हैं जहाँ इंतज़ार ब्रांड का हिस्सा होता है और महसूस होने वाली परफ़ॉर्मेंस असली परफ़ॉर्मेंस को मात देती है।
Want a product where the loading states sell instead of apologize? Brainy designs perceived-performance systems and loading surfaces as part of the product, not as the last sprint before launch.
Get Started
