सबसे खराब UX एंटी-पैटर्न और उन्हें कैसे ठीक करें

पिछले हफ्ते मैंने एक बड़ी एयरलाइन की वेबसाइट पर कुकी सेटिंग्स बदलने की कोशिश की। 'Accept All' बटन चमकदार नीला था, जिसे नज़रअंदाज़ करना नामुमकिन था। 'Manage Preferences' वाला लिंक? धूसर टेक्स्ट, 11px फ़ॉन्ट, और कानूनी भाषा के एक लंबे पैराग्राफ़ के नीचे दबा हुआ। आखिरकार जब वो मिला, तो मैं एक ऐसे पेज पर पहुँचा जहाँ 47 अलग-अलग टॉगल स्विच थे, सब डिफ़ॉल्ट रूप से ऑन, और 'Reject All' का कोई बटन नज़र नहीं आया। मैं एक पूरे मिनट तक टॉगल क्लिक करता रहा, फिर हार मानकर हाथ से अपनी कुकीज़ साफ़ कर दीं।

यह कोई अपवाद नहीं है, यह आम चलन है। खराब UX सिर्फ़ झुंझलाहट नहीं पैदा करता, यह दुश्मनी जैसा व्यवहार है। और सबसे बुरी बात? इनमें से ज़्यादातर एंटी-पैटर्न के फ़िक्स इतने सीधे हैं कि उन्हें लागू करने में लगने वाला समय उन डार्क पैटर्न की जुगत से कहीं कम है जिन्हें वे बदलते हैं। मैं एक दशक से ज़्यादा समय से वेब ऐप्स बना रहा हूँ, और मुझे सच में हैरानी होती है कि हम यह सब अब भी शिप करते जा रहे हैं। तो चलिए, सबसे बड़े अपराधियों की बात करते हैं और जानते हैं कि उन्हें खत्म कैसे करें।

यूज़र्स को शिकार समझने वाले डार्क पैटर्न

डार्क पैटर्न गलती से नहीं बनते। किसी ने मीटिंग में बैठकर कन्वर्ज़न मेट्रिक्स देखे और तय किया कि यूज़र्स को बरगलाना एक स्वीकार्य बिज़नेस स्ट्रेटेजी है। यही बात उन्हें इतना चिढ़ाने वाला बनाती है, क्योंकि वे जानबूझकर बनाए जाते हैं।

Confirmshaming: UI एलिमेंट के रूप में अपराधबोध

ये आपने ज़रूर देखे होंगे। एक मोडल पॉप अप होता है जो न्यूज़लेटर सब्सक्राइब करने को कहता है। स्वीकार करने वाले बटन पर लिखा होता है 'हाँ, मैं पैसे बचाना चाहता हूँ!' और मना करने वाले बटन पर 'नहीं धन्यवाद, मुझे पूरी कीमत पर खरीदना पसंद है।' इसे confirmshaming कहते हैं, और यह हर जगह है: ई-कॉमर्स साइट्स, SaaS ऑनबोर्डिंग फ़्लो, यहाँ तक कि कुछ डेवलपर टूल्स में भी। यह कुछ ही फ़ीसदी यूज़र्स पर काम करता है और बाकी सबको दूर कर देता है।

इसका फ़िक्स बेहद सरल है: दोनों विकल्पों के लिए तटस्थ भाषा इस्तेमाल करें।

<!-- BEFORE: Manipulative confirmshaming -->
<div class="modal">
<p>Join 50,000 smart developers!</p>
<button class="btn-primary">Yes, sign me up!</button>
<button class="btn-link text-sm">
No thanks, I don't care about my career
</button>
</div>
<!-- AFTER: Respectful, neutral options -->
<div class="modal">
<p>Get weekly frontend tips — no spam, unsubscribe anytime.</p>
<button class="btn-primary">Subscribe</button>
<button class="btn-secondary">No thanks</button>
</div>

ध्यान दें कि "बाद वाले" संस्करण में बढ़ा-चढ़ाकर दिया गया सोशल प्रूफ़ भी हटा दिया गया है और स्पैम न भेजने का साफ़ वादा जोड़ा गया है। सम्मान से भरोसा बनता है, हेरफेर से नहीं। आपका लंबे समय का कन्वर्ज़न इसके लिए आपका शुक्रिया अदा करेगा।

रोच मोटल: एक क्लिक में साइनअप, सात स्टेप में कैंसलेशन

साइनअप में 30 सेकंड लगते हैं। कैंसल करने के लिए आपको Settings > Account > Subscription > Manage Plan > Cancel Plan > Tell Us Why > Are You Sure > Talk to Retention > Actually Cancel तक का सफ़र तय करना पड़ता है। कुछ सेवाएँ तो अब भी फ़ोन कॉल की मांग करती हैं। 2026 में। जिस सब्सक्रिप्शन को आपने एक क्लिक में शुरू किया था, उसे बंद करने के लिए इतनी मशक्कत।

मुझे इससे फ़र्क नहीं पड़ता कि आपके रिटेंशन मेट्रिक्स क्या कहते हैं। जो यूज़र्स फँसे हुए हैं वे वफ़ादार ग्राहक नहीं हैं, वे बंधक हैं जो चार्जबैक और एक-स्टार रिव्यू पैदा करते हैं। कैंसलेशन को बिल्कुल उतना ही आसान बनाइए जितना साइनअप है।

• कैंसल का विकल्प Account Settings में रखें, जहाँ लोग उसे ढूँढने की उम्मीद करते हैं
• ज़्यादा से ज़्यादा दो स्टेप: 'क्या आप निश्चित हैं?' और फिर 'हो गया, आपका अकाउंट कैंसल हो गया है'
• कैंसल बटन को 'Contact Support' लिंक के पीछे न छिपाएँ
• रिटेंशन डिस्काउंट देना ठीक है, लेकिन उसे फ़्लो का अनिवार्य स्टेप न बनाएँ
• कैंसलेशन को अपरिवर्तनीय महसूस कराने के बजाय रिएक्टिवेशन लिंक के साथ कन्फ़र्मेशन ईमेल भेजें

टूटे टॉगल स्विच और उलझाने वाले UI कंट्रोल

एक मज़ेदार प्रयोग करिए: अपने फ़ोन की सेटिंग्स में जाएँ और गिनिए कि कितने टॉगल ऐसे हैं जिन्हें आप तुरंत नहीं बता सकते कि चालू हैं या बंद। मैं इंतज़ार कर लूँगा।

कोड रिव्यू में मुझे जो सबसे आम UI गड़बड़ियाँ दिखती हैं, उनमें अस्पष्ट टॉगल सबसे ऊपर है। टॉगल को बस एक बात साफ़ बतानी चाहिए: अभी की स्थिति क्या है। चालू है या बंद? बस इतना। लेकिन डेवलपर्स ऐसे टॉगल शिप करते रहते हैं जिनकी दोनों स्थितियाँ लगभग एक जैसी दिखती हैं, या जहाँ रंग का कोड अस्पष्ट है, या जो अभी की स्थिति के बजाय अगले होने वाले काम को दिखाते हैं।

/* BEFORE: Both states look nearly identical */
.toggle {
width: 48px;
height: 24px;
background: #d1d5db;
border-radius: 12px;
cursor: pointer;
}
.toggle.active {
background: #9ca3af; /* barely different from inactive */
}
/* AFTER: Unmistakable state difference + accessible */
.toggle {
width: 48px;
height: 24px;
background: #d1d5db;
border-radius: 12px;
cursor: pointer;
position: relative;
}
.toggle[aria-checked="true"] {
background: #2563eb; /* strong contrast from inactive */
}
.toggle .label {
font-size: 10px;
font-weight: 600;
color: white;
}
.toggle[aria-checked="true"] .label::after { content: "ON"; }
.toggle[aria-checked="false"] .label::after { content: "OFF"; }

ऐसे टॉगल के लिए तीन नियम जो लोगों को उलझाते नहीं: हर स्थिति के लिए अलग रंग (इतने कंट्रास्ट के साथ कि कलरब्लाइंड यूज़र्स के लिए भी काम करे), टॉगल के अंदर या उसके साथ लगा टेक्स्ट लेबल, और सही aria-checked एट्रिब्यूट ताकि स्क्रीन रीडर स्थिति बता सकें। अगर आप सिर्फ़ रंग पर निर्भर हैं, तो आप एक ही कदम में UX और एक्सेसिबिलिटी दोनों में असफल हो गए हैं।

नेटिव फ़ॉर्म कंट्रोल को दोबारा बनाना बंद कीजिए

मैं बहुत सारे फ़्रंटएंड PR रिव्यू करता हूँ, और एक पैटर्न मुझे पागल कर देता है: कस्टम-बने ड्रॉपडाउन जो कीबोर्ड नेविगेशन तोड़ देते हैं। डेवलपर दो दिन लगाकर divs और click हैंडलर्स से एक शानदार select मेन्यू बनाता है। डेमो में बढ़िया लगता है। फिर कोई यूज़र फ़ॉर्म में Tab दबाता है, कस्टम ड्रॉपडाउन पर पहुँचता है, और कुछ नहीं होता। एरो की सपोर्ट नहीं, टाइप-अहेड सर्च नहीं, पासवर्ड मैनेजर के साथ काम नहीं करता, मोबाइल पर टूट जाता है।

इसके उलट, नेटिव <select> एलिमेंट, या Radix UI या Headless UI जैसी अच्छी तरह टेस्ट की गई लाइब्रेरी, यह सब मुफ़्त में संभाल लेती हैं। HTML popover API और <selectlist> एलिमेंट के लिए अब ब्राउज़र सपोर्ट भी मज़बूत है। इन्हें इस्तेमाल कीजिए। आपके यूज़र्स को इससे फ़र्क नहीं पड़ता कि आपके ड्रॉपडाउन में कस्टम एनिमेशन है। उन्हें यह चाहिए कि वह काम करे।

एक्सेसिबिलिटी के एंटी-पैटर्न जो असली यूज़र्स को बाहर कर देते हैं

एक्सेसिबिलिटी कोई अच्छा-होता-तो-ठीक-था फ़ीचर नहीं है। यह ऐसी चीज़ नहीं जिसे आप किसी आने वाले स्प्रिंट में जोड़ेंगे। दुनिया भर में एक अरब से ज़्यादा लोग किसी न किसी प्रकार की विकलांगता के साथ जीते हैं, और WebAIM Million रिपोर्ट लगातार बताती है कि शीर्ष दस लाख वेबसाइटों में से 96% से ज़्यादा में पहचानी जा सकने वाली WCAG खामियाँ हैं। ये कोई दुर्लभ किनारे के मामले नहीं हैं, ये टूटे बटन, गायब लेबल और बिना alt टेक्स्ट वाली इमेज हैं।

मैं सबसे ज़्यादा यही देखता हूँ:

1. बिना alt टेक्स्ट वाली इमेज: स्क्रीन रीडर बस 'image' कहकर आगे बढ़ जाता है
2. 4.5:1 से कम कंट्रास्ट अनुपात: कम दृष्टि वाले यूज़र्स के लिए टेक्स्ट पढ़ने लायक नहीं रहता
3. कीबोर्ड नेविगेशन नहीं: अगर आप अपने ऐप में Tab से नहीं चल सकते, तो कीबोर्ड और स्विच यूज़र्स बाहर रह जाते हैं
4. मोडल में फ़ोकस ट्रैप: यूज़र डायलॉग खोलता है और माउस के बिना उससे बाहर नहीं निकल पाता
5. फ़ॉर्म लेबल गायब: स्क्रीन रीडर को पता ही नहीं चलता कि इनपुट फ़ील्ड किस काम का है
6. बिना पॉज़ बटन के ऑटो-प्ले वीडियो: वेस्टिबुलर विकार वाले यूज़र्स के लिए यह भ्रमित करने वाला होता है

सबसे तेज़ फ़ायदा अपनी CI पाइपलाइन में ऑटोमेटेड एक्सेसिबिलिटी चेक जोड़ने से मिलता है। यह सब कुछ नहीं पकड़ पाता, ऑटोमेटेड टूल शायद 30-40% समस्याएँ ही ढूँढ पाते हैं, लेकिन स्पष्ट गड़बड़ियाँ शिप होने से पहले पकड़ लेता है।

// BEFORE: No accessibility testing at all
test('homepage loads', async ({ page }) => {
await page.goto('/');
await expect(page.locator('h1')).toBeVisible();
});
// AFTER: Accessibility violations fail the build
import AxeBuilder from '@axe-core/playwright';
test('homepage loads and is accessible', async ({ page }) => {
await page.goto('/');
await expect(page.locator('h1')).toBeVisible();
const a11yResults = await new AxeBuilder({ page })
.withTags(['wcag2a', 'wcag2aa'])
.analyze();
expect(a11yResults.violations).toEqual([]);
});

पाँच मिनट का सेटअप। हर PR पर चलता है। गायब alt टेक्स्ट, टूटे ARIA roles, कम कंट्रास्ट और दर्जनों दूसरी खामियाँ अपने आप पकड़ता है। ऐसा न करने का कोई बहाना नहीं है।

कॉग्निटिव ओवरलोड: नरक जैसा सेटिंग्स पेज

इंसान की वर्किंग मेमोरी एक समय में लगभग चार से सात आइटम ही रख सकती है। यह सुझाव नहीं है, यह एक कठोर संज्ञानात्मक सीमा है। जब आपका इंटरफ़ेस बिना किसी क्रम के एक ही पेज पर 200 विकल्प उड़ेल देता है, तो आप यूज़र्स को नियंत्रण नहीं दे रहे, आप उन्हें फ़ैसले के लकवे में डाल रहे हैं।

एक बार मैंने हमारे ऑफ़िस में इस्तेमाल होने वाले एक प्रोजेक्ट मैनेजमेंट टूल की सेटिंग्स गिनी। 347 विकल्प। एक ही पेज। कोई सर्च नहीं। 'General' और 'Advanced' जैसी धुंधली श्रेणियों के अलावा कोई ग्रुपिंग नहीं। आधी टीम ने कभी कोई सेटिंग नहीं बदली, क्योंकि पेज इतना भारी था कि लोग उसे तुरंत बंद कर देते थे।

फ़िक्स है प्रोग्रेसिव डिस्क्लोज़र। वे पाँच सेटिंग्स दिखाइए जिन्हें लोग सच में बदलते हैं। बाकी सब को साफ़ लेबल वाले एक्सपैंडेबल सेक्शन के पीछे रखिए। एक सर्च बार जोड़िए। और भगवान के लिए, समझदार डिफ़ॉल्ट दीजिए ताकि ज़्यादातर यूज़र्स को सेटिंग्स पेज की ज़रूरत ही न पड़े।

अगर आपके सेटिंग्स पेज को अपने ही डॉक्यूमेंटेशन की ज़रूरत पड़ती है, तो समस्या आपका सेटिंग्स पेज है।

नोटिफ़िकेशन की भरमार यूज़र्स को सब कुछ नज़रअंदाज़ करना सिखा देती है

जब हर घटना नोटिफ़िकेशन भेजती है, जैसे कोई टीममेट चैनल में जुड़ा, किसी ने इमोजी से रिएक्ट किया, डिप्लॉय पूरा हुआ, या 30 मिनट में कैलेंडर इवेंट शुरू होने वाला है, तो यूज़र्स सबको नज़रअंदाज़ करना सीख जाते हैं। आपने अपने नोटिफ़िकेशन सिस्टम को सफ़ेद शोर बना दिया है। वह एक ज़रूरी अलर्ट जो सच में मायने रखता है? 47 बिना पढ़े नोटिफ़िकेशन के नीचे दबा रहता है।

इसका जवाब है समझदार डिफ़ॉल्ट। नए यूज़र्स को सिर्फ़ ज़रूरी नोटिफ़िकेशन मिलने चाहिए। गैर-ज़रूरी चीज़ों को रोज़ के डाइजेस्ट में इकट्ठा करें। और हमेशा, हमेशा, यूज़र्स को नोटिफ़िकेशन से ही सीधे म्यूट या कस्टमाइज़ करने दें, न कि तीन क्लिक दूर किसी दबे हुए प्रेफ़रेंस पेज से।

धीमा UI मतलब टूटा हुआ UI: परफ़ॉर्मेंस एक UX समस्या है

जो बटन जवाब देने में दो सेकंड लेता है वह धीमा नहीं, टूटा हुआ है। यूज़र यह नहीं सोचता कि 'ओह, सर्वर मेरी रिक्वेस्ट प्रोसेस कर रहा है।' वह सोचता है 'क्या मेरा क्लिक दर्ज हुआ?' और दोबारा क्लिक कर देता है। अब आपके पास डुप्लिकेट सबमिशन, भ्रमित स्टेट और ऐसा यूज़र है जो आपके ऐप पर भरोसा नहीं करता।

100ms से ज़्यादा लगने पर UI सुस्त लगता है। एक सेकंड से ज़्यादा लगने पर यूज़र की सोच की लय टूट जाती है। फिर भी हम कई MB के JavaScript बंडल, रेंडर को रोकने वाली थर्ड-पार्टी स्क्रिप्ट्स, और लेआउट शिफ़्ट शिप करते रहते हैं जिनसे लोग गलत एलिमेंट पर क्लिक कर देते हैं। इसका फ़िक्स जटिल नहीं है, बस इसकी परवाह करने की ज़रूरत है।

// BEFORE: User clicks, waits 2 seconds, nothing happens
async function handleLike(postId: string) {
const result = await fetch(`/api/posts/${postId}/like`, {
method: 'POST',
});
if (result.ok) {
setLikeCount(prev => prev + 1); // UI updates after network round-trip
}
}
// AFTER: Optimistic update — UI responds instantly
function handleLike(postId: string) {
// Update UI immediately
setLikeCount(prev => prev + 1);
// Sync with server in background
startTransition(async () => {
const result = await fetch(`/api/posts/${postId}/like`, {
method: 'POST',
});
if (!result.ok) {
// Rollback only on failure
setLikeCount(prev => prev - 1);
toast.error('Something went wrong. Try again.');
}
});
}

ऑप्टिमिस्टिक अपडेट्स, स्पिनर की जगह स्केलेटन स्क्रीन, गैर-ज़रूरी JavaScript को लेज़ी-लोड करना, और Core Web Vitals को असली मेट्रिक्स मानकर मॉनिटर करना, बाद में सोचने वाली बातें नहीं। ये एडवांस्ड तकनीकें नहीं हैं। ये बुनियादी अपेक्षाएँ हैं।

मोबाइल UX के एंटी-पैटर्न जो मरने का नाम नहीं लेते

मोबाइल के अपने खास UX पाप हैं, मुख्यतः इसलिए कि डेवलपर्स एक नए iPhone पर टेस्ट करके दिन खत्म कर देते हैं।

टच टार्गेट जिन्हें सर्जिकल सटीकता चाहिए

Apple के दिशानिर्देश टच टार्गेट के लिए न्यूनतम 44x44 CSS पिक्सल कहते हैं। WCAG 2.2 भी यही कहता है। फिर भी मैं अब भी मोडल पर 20-पिक्सल वाले क्लोज़ बटन, फ़ुटर में एक-दूसरे से सटे छोटे लिंक, और फ़ोन पर लगभग न दबने वाले आइकन बटन देखता हूँ। मोटर समस्याओं वाले यूज़र्स के लिए यह और भी बुरा है।

/* BEFORE: Tiny, frustrating touch targets */
.close-btn {
width: 20px;
height: 20px;
font-size: 12px;
}
.footer-links a {
padding: 2px 4px;
font-size: 11px;
}
/* AFTER: Actually tappable elements */
.close-btn {
min-width: 44px;
min-height: 44px;
display: flex;
align-items: center;
justify-content: center;
}
.footer-links a {
padding: 12px 8px;
font-size: 14px;
/* spacing between adjacent targets */
margin: 4px 0;
}

कंटेंट को रोकने वाले फ़ुल-स्क्रीन इंटरस्टीशियल

आप सर्च रिज़ल्ट पर टैप करते हैं। पेज लोड होता है। एक शब्द भी पढ़ पाने से पहले एक फ़ुल-स्क्रीन मोडल आपसे ईमेल पता माँगता है। आपने अभी कंटेंट देखा ही नहीं है। आप सब्सक्राइब क्यों करेंगे?

Google 2017 से खोज रैंकिंग में इंट्रूसिव इंटरस्टीशियल को दंडित कर रहा है। ये फिर भी बने हुए हैं, क्योंकि कोई न कोई डैशबोर्ड पर 2% ईमेल कैप्चर रेट देखकर इसे जीत मान लेता है, और उस 40% बाउंस रेट को नज़रअंदाज़ कर देता है जो यह पैदा करता है। इनलाइन बैनर या बॉटम शीट इस्तेमाल करें। कुछ भी माँगने से पहले इंतज़ार करें जब तक यूज़र ने आपके कंटेंट से सच में जुड़ाव न दिखाया हो। जो पाठक तीन लेख पढ़ चुका है वह खुशी-खुशी सब्सक्राइब करेगा। जिसे तीन बार बीच में रोका गया है, वह चला जाएगा और कभी वापस नहीं आएगा।

UX गुणवत्ता की संस्कृति कैसे बनाएँ (सिर्फ़ अलग-अलग बग ठीक करना नहीं)

एक-एक करके एंटी-पैटर्न ठीक करना ज़रूरी है, पर काफ़ी नहीं। अगर आपकी प्रक्रिया उन्हें लगातार पैदा करती रहती है, तो आपको बेहतर प्रक्रिया चाहिए। असल में यह तरीका काम करता है:

1. हर PR पर ऑटोमेटेड a11y चेक के लिए अपनी CI पाइपलाइन में axe-core जोड़ें
2. UX रिव्यू को अलग से सिर्फ़ डिज़ाइन की प्रक्रिया न बनाकर कोड रिव्यू का हिस्सा बनाएँ
3. बड़े फ़ीचर शिप करने से पहले 5 असली यूज़र्स के साथ टेस्ट करें, 5 यूज़र्स लगभग 85% usability समस्याएँ सामने ले आते हैं
4. सिर्फ़ पेज व्यू और समय-ऑन-साइट नहीं, टास्क पूरा होने की दर और एरर रेट भी ट्रैक करें
5. पहले से बने एक्सेसिबल कंपोनेंट वाला डिज़ाइन सिस्टम इस्तेमाल करें, ताकि हर डेवलपर एक ही इंटरैक्शन समस्या शून्य से हल न करे
6. अपने प्रोडक्ट को लगातार खुद इस्तेमाल करें: जब सेटिंग्स पेज बनाने वाले डेवलपर को उसे रोज़ इस्तेमाल करना पड़ता है, तो वह जल्दी ठीक होता है

मेरा अब तक का सबसे अच्छा UX सुधार इस बात से शुरू हुआ कि मैंने अपने फ़ोन पर हमारा ही चेकआउट फ़्लो इस्तेमाल करने की कोशिश की और रात 11 बजे प्रोडक्ट चैनल पर गुस्से में मैसेज कर दिया।

इस लेख में हर एंटी-पैटर्न का एक सीधा फ़िक्स है। इनमें से किसी के लिए भी सबसे नई तकनीक या बड़े रीडिज़ाइन की ज़रूरत नहीं। इनके लिए बस परवाह करनी होती है। आज एक फ़िक्स से शुरुआत करें। इस हफ़्ते एक एक्सेसिबिलिटी ऑडिट चलाएँ। इस महीने एक असली यूज़र के साथ टेस्ट करें। अच्छा UX भव्य इशारों के बारे में नहीं है, यह लगातार अल्पकालिक मेट्रिक्स के बजाय अपने यूज़र्स के सम्मान को चुनने के बारे में है। जिस सॉफ़्टवेयर को लोग झेलते हैं और जिसे लोग पसंद करते हैं, उनके बीच का फ़ासला जितना आप सोचते हैं उससे छोटा है। वह बस हज़ारों छोटे फ़ैसले हैं, जो सही तरीके से लिए गए हों।