जानबूझकर फ्रिक्शन डिज़ाइन करना
फ्रिक्शनलेस का दौर खत्म। 2026 के सबसे अच्छे प्रोडक्ट्स ने फ्रिक्शन वापस जोड़ा, सोच-समझकर, खास जगहों पर, खास वजहों से। फ्रिक्शन कहाँ अपनी जगह कमाता है, वह कौन-से रूप ले सकता है, और किसी भी फ्लो को परखने का ऑडिट फ्रेमवर्क।
फ्रिक्शनलेस मर चुका है। हर टैप, हर कन्फर्मेशन, हर ठहराव हटाने की दशक भर की दौड़ ने प्रोडक्ट्स को टैप-करो-और-दुआ-करो वाली स्लॉट मशीनें बना दिया, और 2026 की सबसे अच्छी टीमें चुपचाप फ्रिक्शन वापस ला रही हैं। गलती से नहीं। जानबूझकर। खास जगहों पर, खास वजहों से।
फ्रिक्शन UX का दुश्मन नहीं है। फ्रिक्शन वही तरीका है जिससे UX सम्मान जताता है। जो प्रोडक्ट यूज़र को एक टैप में अकाउंट डिलीट करने देता है, वह उनका सम्मान नहीं करता। जो पहले अकाउंट का नाम टाइप करवाता है, वह करता है। ठहराव ही संदेश है।
आकस्मिक फ्रिक्शन एक अलग चीज़ है
"फ्रिक्शन बुरा है" वाली ज़्यादातर बहसें आकस्मिक फ्रिक्शन के बारे में होती हैं। लैग। उलझा हुआ UI। डार्क पैटर्न। 2026 में फैक्स नंबर माँगने वाले फ़ॉर्म। ऑनबोर्डिंग फ्लो जो प्रोडक्ट कुछ काम का करे उससे पहले ईमेल कन्फर्मेशन, SMS कोड और सेटअप विज़ार्ड माँगते हैं। ऐसा फ्रिक्शन बुरा है। इसका बचाव कोई नहीं कर रहा।
डिज़ाइन्ड फ्रिक्शन कुछ और है। यह ऊँचे दाँव वाले पल पर जानबूझकर लिया गया ठहराव है ताकि यूज़र आकस्मिक नहीं, असली फैसला ले सके। Apple Pay पर दूसरा टैप। GitHub पर डिलीट करने के लिए रेपो का नाम टाइप करना। Cursor आपके कोड को छूने से पहले जो diff दिखाता है।
आकस्मिक फ्रिक्शन एक बग है। डिज़ाइन्ड फ्रिक्शन एक फ़ीचर है। इन दोनों को मिला देने की वजह से ही इंडस्ट्री में वन-टैप अकाउंट डिलीट बटन के बगल में कॉन्टैक्ट फ़ॉर्म पर "क्या आप वाकई यह पेज छोड़ना चाहते हैं" वाले मोडल बैठे हैं।
वे छह जगहें जहाँ फ्रिक्शन अपनी कीमत वसूलता है
फ्रिक्शन खास संदर्भों में अपनी जगह कमाता है। ऐसे छह संदर्भ, इस क्रम में कि उसकी गैरमौजूदगी यूज़र को कितनी बुरी सज़ा देती है।
अपरिवर्तनीय एक्शन
जिस भी चीज़ को यूज़र वापस नहीं कर सकता, वह फ्रिक्शन की हकदार है। अकाउंट डिलीट करना। डेटाबेस ड्रॉप करना। Force-push। ट्रैश खाली करना। डिवाइस वाइप करना। गलत टैप की कीमत वापस नहीं मिलती, इसलिए प्रोडक्ट पर यूज़र का यह कर्ज़ है कि वह इरादा पक्का करने का एक पल दे।
GitHub का रेपो डिलीशन इसका पाठ्यपुस्तकीय उदाहरण है। डिलीट बटन चालू होने से पहले यूज़र को पूरा रेपो नाम, हूबहू, टाइप करना पड़ता है। यह फ्रिक्शन दिखावा नहीं है, यह एक फोर्सिंग फंक्शन है जो मसल मेमोरी को सोचे-समझे चुनाव में बदल देता है। Stripe इसे API key रिवोकेशन पर इस्तेमाल करता है। AWS रिसोर्स डिलीशन पर। "type DELETE" पैटर्न इसलिए है क्योंकि मसल मेमोरी इरादे को हरा देती है, और अपरिवर्तनीय एक्शन मसल मेमोरी से हारने का जोखिम नहीं उठा सकते।
पैसे का लेनदेन
जो भी प्रोडक्ट पैसा हिलाता है, उस पर यूज़र के लिए कन्फर्मेशन स्टेप का कर्ज़ है। Stripe Checkout जानबूझकर दो स्टेप का फ्लो है। एक स्क्रीन पर कार्ड डिटेल, अगली पर सारांश और कन्फर्म। यह "अतिरिक्त" स्टेप ही पूरी पिच है। चार्ज लगने से पहले यूज़र देखता है कि वह कितना दे रहा है, किसे दे रहा है और बदले में क्या पा रहा है।
Apple Pay का डबल-प्रेस यही विचार हार्डवेयर में सिमटा हुआ है। पैसा हिलने से पहले यूज़र दो बार कमिट करता है, बीच में एक सेकंड के अंतराल के साथ। वह दूसरा प्रेस पेमेंट और दुर्घटना के बीच का फ़र्क है।
फ्रिक्शनलेस पेमेंट मौजूद हैं। उन्हें सब्सक्रिप्शन कहते हैं, और ऐप स्टोर में सबसे ज़्यादा शिकायतों वाली कैटेगरी भी वही है, बेवजह नहीं। कन्फर्मेशन स्टेप हटाने से यूज़र खुश नहीं होता, उसे लगता है कि प्रोडक्ट उसका फायदा उठा रहा है।
AI टूल कॉल
जब भी कोई AI कोई असली एक्शन लेने वाला हो, फ़ाइल सिस्टम में लिखना, कमांड चलाना, ईमेल भेजना, API हिट करना, यूज़र एक अप्रूवल बीट का हकदार है।
Cursor का accept-or-reject diff गोल्ड स्टैंडर्ड है। मॉडल बदलाव सुझाता है, diff दिखता है, और बदलाव लागू होने से पहले यूज़र accept, reject या एडिट करता है। Claude का आर्टिफ़ैक्ट अप्रूवल भी इसी ढाँचे पर चलता है। कोड एजेंट फ़ाइल एडिट सुझाता है, यूज़र रिव्यू करता है, फिर कमिट होता है। फ्रिक्शन ही भरोसे की परत है। इसके बिना एजेंट कोडबेस बिगाड़ने का बस एक तेज़ तरीका है।
2024 और 2025 में जिन AI प्रोडक्ट्स ने यह स्टेप छोड़ा, उन्होंने बहुत भरोसा जलाया। जिन्होंने अप्रूवल बीट बनाई, यूज़र उन्हीं को सचमुच चलता छोड़ते हैं।
अकाउंट डिलीशन और विनाशकारी सेटिंग्स
Linear के विनाशकारी-एक्शन कन्फर्मेशन कम आँका गया उदाहरण हैं। प्रोजेक्ट आर्काइव करो, सिस्टम एक बार पूछता है। प्रोजेक्ट डिलीट करो, सिस्टम दो बार पूछता है और दिखाता है कि क्या गायब होने वाला है। वर्कस्पेस डिलीट करो, सिस्टम वर्कस्पेस का नाम सादे टेक्स्ट में टाइप करवाता है। फ्रिक्शन नुकसान के आकार के साथ बढ़ता है।
Notion यही ग्रेडिएंट चलाता है। आर्काइव एक टैप में क्योंकि आर्काइव वापस हो सकता है। डिलीट टाइप किए गए कन्फर्मेशन के पीछे क्योंकि डिलीट वापस नहीं होता। यूज़र को कभी पूछना नहीं पड़ता कि कौन-सा क्या है, क्योंकि फ्रिक्शन खुद दाँव का संकेत देता है।
जो प्रोडक्ट आर्काइव और डिलीट को एक ही वन-टैप जेस्चर मानता है, वह इस फ़र्क की इज़्ज़त नहीं करता। यूज़र को मुश्किल तरीके से पता चलता है, आमतौर पर मंगलवार रात 11 बजे, कि जो बटन उसने दबाया वह वह बटन नहीं था जो उसने सोचा था।
शेयर और पब्लिश करने के पल
पब्लिश बटन एक ठहराव का हकदार है। ट्वीट पोस्ट करना, चैनल में Slack भेजना, ब्लॉग ड्राफ्ट पब्लिश करना, क्लाइंट के साथ Figma फ़ाइल शेयर करना। यह एक्शन सिद्धांत में वापस हो सकता है और व्यवहार में शर्मनाक होता है। भेजने से पहले का ठहराव रात 2 बजे के उस DM को रोकता है जो एक व्यक्ति के लिए था और पूरे विभाग को चला गया।
Twitter का भड़काऊ रिप्लाई पर "क्या आप वाकई यह भेजना चाहते हैं" प्रॉम्प्ट एक चालू उदाहरण है। Slack की "आप 4,200 लोगों को मैसेज करने वाले हैं" वाली चेतावनी दूसरा है। फ्रिक्शन दरअसल प्रोडक्ट का यह याद रखना है कि यूज़र बाद में चाहेगा कि उससे पूछा गया होता।
यही तर्क पब्लिशिंग पर भी लागू होता है। WordPress, Ghost, Webflow और हर काम का CMS पोस्ट लाइव होने से पहले कन्फर्मेशन सारांश दिखाता है। यह फ्रिक्शन "पब्लिश" और "पब्लिश करो और तुरंत अनपब्लिश करना पड़े" के बीच का फ़र्क है।
संवेदनशील डेटा और अकाउंट एक्सेस
लॉग इन करना वह जगह नहीं है जहाँ फ्रिक्शन चाहिए। नए डिवाइस का कन्फर्मेशन वह जगह है। पहली बार संवेदनशील एक्शन लेने पर 2FA प्रॉम्प्ट वह जगह है। "हमने नई लोकेशन से लॉगिन देखा" वाला ठहराव वह जगह है।
फ्रिक्शन खतरे की सतह पर रखिए, मुख्य दरवाज़े पर नहीं। नए साइन-इन पर Apple के Are You Sure प्रॉम्प्ट सही आकार के हैं। रिकवरी ईमेल बदलने से पहले Google का सेशन री-ऑथ सही आकार का है। एक सीमा से ऊपर वायर ट्रांसफ़र पर बैंकों का दूसरा फ़ैक्टर माँगना सही आकार है। हर बार बैलेंस देखने पर दूसरा फ़ैक्टर माँगना गलत आकार है, और यह यूज़र को उन प्रॉम्प्ट्स को अनदेखा करना सिखा देता है जो मायने रखते हैं।
जहाँ फ्रिक्शन प्रोडक्ट को मार देता है
गलत जगह का फ्रिक्शन बस खराब प्रोडक्ट है। बचने के तीन पैटर्न, हर एक शिप हुए प्रोडक्ट्स की असली विफलता।
मुख्य दरवाज़े पर फ्रिक्शन। लॉग इन करने के लिए अतिरिक्त स्टेप। हर सेशन में Captcha। ईमेल कन्फर्मेशन फ्लो जो तीन दिन लेते हैं। यूज़र ने अभी कमिट नहीं किया है, इसलिए फ्रिक्शन का हर स्टेप छोड़कर जाने का मौका है। फ्रिक्शन उस वक्त के लिए बचाकर रखिए जब यूज़र रुकने का फैसला कर चुका हो।
डार्क-पैटर्न अनसब्सक्राइब। यूज़र को जाने से रोकने के लिए बनाया गया फ्रिक्शन। चार स्क्रीन गहरे दबे Cancel बटन। "क्या आप वाकई अपने सारे फायदे खोना चाहते हैं" वाले गिल्ट मोडल। जिन अकाउंट्स को साइन अप के लिए पासवर्ड नहीं चाहिए था, उन पर कैंसिल करने के लिए पासवर्ड टाइप करवाने वाले पैटर्न। शत्रुतापूर्ण फ्रिक्शन छोटी अवधि की रिटेंशन को लंबी अवधि के रेप्युटेशन नुकसान में बदल देता है। जो ब्रांड यह करते हैं, वे इसकी कीमत चुकाते हैं।
ऑनबोर्डिंग गेट। सेटअप विज़ार्ड जो प्रोडक्ट कुछ करे उससे पहले हर पसंद माँगते हैं। जिस प्रोडक्ट को यूज़र ने अभी आज़माने के लिए साइन अप किया है, उस पर "जारी रखने के लिए अपनी प्रोफ़ाइल पूरी करें" की दीवारें। भरोसा बनाने के चरण में फ्रिक्शन वह फ्रिक्शन है जिसे यूज़र ने अभी स्वीकारा नहीं है। सही पैटर्न प्रोग्रेसिव डिस्क्लोज़र है, जहाँ प्रोडक्ट जितना कमाता है, यूज़र उतना ज़्यादा देता है।
अंगूठे का नियम: फ्रिक्शन एक्शन पर, प्रवेश द्वार पर नहीं। फ्रिक्शन गलती की कीमत के अनुपात में। ऐसा फ्रिक्शन जिसे यूज़र परवाह की तरह पढ़े, रुकावट की तरह नहीं।
फ्रिक्शन एक डिज़ाइन मटीरियल है
ज़्यादातर टीमें यह गलती करती हैं कि फ्रिक्शन को बाइनरी मानती हैं। कन्फर्म या नो कन्फर्म। 2026 के सबसे अच्छे प्रोडक्ट शिप करने वाली टीमें फ्रिक्शन को ऐसा मटीरियल मानती हैं जिसका आकार ट्यून किया जा सकता है। छह आम आकार, हर एक का अलग वज़न।
पॉज़। टैप और एक्ज़ीक्यूशन के बीच 200ms की बीट। सबसे हल्का संभव फ्रिक्शन। hover-to-confirm पैटर्न और धीमे बटनों पर इस्तेमाल होता है।
कन्फर्मेशन। एक बार पूछने वाला मोडल। प्रोजेक्ट आर्काइव करने या इनवॉइस भेजने जैसे मध्यम दाँव वाले एक्शन के लिए डिफ़ॉल्ट फ्रिक्शन।
डबल कन्फर्म। लगातार दो प्रॉम्प्ट, दूसरा पहले से अलग। तब इस्तेमाल होता है जब पहला प्रॉम्प्ट ऐसी चीज़ हो जिसे यूज़र आदतन खारिज कर देते हैं।
टाइप करके कन्फर्म करें। यूज़र रिसोर्स का नाम, शब्द DELETE या अकाउंट ईमेल टाइप करता है। सोचा-समझा ध्यान लगवाता है। सबसे अपरिवर्तनीय एक्शन के लिए इस्तेमाल होता है।
कूलडाउन। एक देरी की खिड़की जिसके बाद ही एक्शन दोहराया या पलटा जा सकता है। बल्क ऑपरेशन और मॉडरेशन एक्शन पर इस्तेमाल होता है जहाँ घबराहट की संभावना होती है।
अनडू विंडो। एक्शन हो जाता है, पर यूज़र के पास उसे पलटने के लिए एक तय अवधि होती है। Gmail का send-undo। Slack की एडिट विंडो। सही आकार तब जब एक्शन मेहनत से पलटा जा सकता हो पर विनाशकारी न हो।
सही आकार दाँव, रिवर्सिबिलिटी और एक्शन कितनी बार चलता है, इस पर निर्भर करता है। हर फ्लो के लिए एक ही आकार चुनने वाले डिज़ाइनर वैसे ही डिज़ाइन कर रहे हैं जैसे कोई हर लेआउट के लिए एक ही फ़ॉन्ट वेट चुन ले। बग यही सीमा है, फ़ीचर नहीं।
स्पीड और फ्रिक्शन कैसे आपस में असर डालते हैं, इसके लिए देखिए स्पीड ही ब्रांड है और लैंडिंग पेज डिज़ाइन के सिद्धांत।
फ्रिक्शन ऑडिट फ्रेमवर्क
हर फ्लो को शिप करने से पहले इन चार सवालों से गुज़ारिए। अगर जवाब गलत हैं, तो फ्रिक्शन गलत है।
- क्या एक्शन पलटा जा सकता है? अगर हाँ, तो फ्रिक्शन हल्का या गैरमौजूद हो सकता है। अगर नहीं, तो फ्रिक्शन अनिवार्य है और गलती की कीमत के साथ बढ़ना चाहिए।
- अगर यूज़र गलती से टैप कर दे तो उसका क्या जाएगा? समय, पैसा, डेटा, रेप्युटेशन, चारों। फ्रिक्शन का आकार नुकसान के आकार से मेल खाना चाहिए।
- फ्रिक्शन फ्लो में कहाँ गिर रहा है? मुख्य दरवाज़े का फ्रिक्शन बुरा है। एक्शन के पल का फ्रिक्शन अच्छा है। यूज़र और वैल्यू के बीच का फ्रिक्शन गलत जगह पर है।
- क्या फ्रिक्शन परवाह की तरह पढ़ा जाता है या रुकावट की तरह? फ्रिक्शन से टकराने वाले यूज़र को सम्मानित महसूस होना चाहिए, रोका हुआ नहीं। अगर यह प्रोडक्ट के उसे धीमा करने जैसा लगे, तो फ्रिक्शन शत्रुतापूर्ण है।
चार सवाल, क्रम से, हर उस फ्लो पर जिसमें दाँव हो। ज़्यादातर टीमें इसे छोड़ देती हैं क्योंकि कन्फर्मेशन मोडल जोड़ने की इंजीनियरिंग लागत मामूली है और यह डिज़ाइन बहस कि वह वहाँ होना चाहिए या नहीं, मामूली नहीं है।
फ्लो-स्तर के फैसलों को गहराई से पढ़ने के लिए देखिए वेब डिज़ाइन के सिद्धांत, मॉकअप की मौत और AI प्रोडक्ट ऑनबोर्डिंग डिज़ाइन।
FAQ
UX फ्लो में फ्रिक्शन कब जोड़ना चाहिए?
ऊँचे दाँव वाले पलों पर फ्रिक्शन जोड़िए। अपरिवर्तनीय एक्शन, पैसे का लेनदेन, AI टूल कॉल, अकाउंट डिलीशन, पब्लिशिंग और संवेदनशील डेटा बदलाव। फ्रिक्शन गलत टैप की कीमत के साथ बढ़ना चाहिए, और उसे एक्शन पर गिरना चाहिए, प्रवेश द्वार पर नहीं।
क्या फ्रिक्शनलेस डिज़ाइन मर चुका है?
सार्वभौमिक लक्ष्य के रूप में फ्रिक्शनलेस मर चुका है। सही पलों पर फ्रिक्शनलेस अब भी सही है। बिना मेहनत का अनुभव और फ्रिक्शनलेस एक चीज़ नहीं हैं, और ऊँचे दाँव वाले पलों पर डिज़ाइन्ड फ्रिक्शन ऐसे प्रोडक्ट का संकेत देता है जो यूज़र का सम्मान करता है।
अच्छे फ्रिक्शन और डार्क पैटर्न में क्या फ़र्क है?
अच्छा फ्रिक्शन यूज़र को ऐसी गलती से बचाता है जिस पर वह पछताता। डार्क-पैटर्न फ्रिक्शन कंपनी को उस फैसले से बचाता है जो यूज़र पहले ही ले चुका है। अच्छा फ्रिक्शन एक्शन पर रहता है। डार्क-पैटर्न फ्रिक्शन यूज़र और निकास के बीच रहता है। आकार एक जैसा दिख सकता है। इरादा उलटा है।
वह परत बनाइए जो भरोसा कमाती है
फ्रिक्शन अच्छे UX का उलटा नहीं है। यह UX का वह हिस्सा है जो संकेत देता है कि प्रोडक्ट जानता है कि वह किस लिए है। 2026 में जिन टीमों के प्रोडक्ट्स पर लोग भरोसा करते हैं, उन्होंने अपने फ्लो मैप किए, ऊँचे दाँव वाले पलों को नाम दिया, हर एक के लिए फ्रिक्शन का सही आकार चुना, और जब लीडरशिप ने पूछा कि फ्लो में कन्फर्मेशन मोडल क्यों है तो उस चुनाव का बचाव किया।
अगर आपका प्रोडक्ट भरोसा खो रहा है क्योंकि हर एक्शन एक जैसा महसूस होता है, तो Brainy को हायर कीजिए। हम UX ऑडिट, फ्लो रीडिज़ाइन और वह फ्रिक्शन लेयर शिप करते हैं जो टैप-करो-और-दुआ-करो प्रोडक्ट को ऐसा प्रोडक्ट बना देती है जिसके साथ लोग टिके रहें। फ्रिक्शन एक मटीरियल है। इसे जानबूझकर इस्तेमाल कीजिए, सही जगहों पर, सही आकार में, और यूज़र जब भी प्रोडक्ट को छुएगा, वह परवाह की तरह पढ़ा जाएगा।
If your product is leaking trust because every action feels the same, Brainy ships UX audits, flow redesigns, and the friction layer that turns a slot machine into a product people respect.
Get Started
