जब मैं अपनी पहली वेबसाइट बनाने बैठा, तो उत्साह वास्तविक था। मुझे लगा कि कठिन हिस्सा कोडिंग सीखना होगा—टैग याद करना, फंक्शन्स को समझना, सिंटैक्स को सही करना। मैं गलत था। कोड लिखना तो आसान हिस्सा निकला। असली चुनौती उन लाइनों को कुछ ऐसा बनाने में थी जिसे लोग बिना किसी भ्रम या हताशा के इस्तेमाल कर सकें। उस पहले प्रोजेक्ट ने मुझे सिखाया कि डेवलपमेंट अकेले बैठकर टाइप करने के बारे में कम और उन इंसानों की समस्याओं को हल करने के बारे में अधिक है जिन्हें आपके स्टैक (stack) से कोई लेना-देना नहीं है। मैंने ऐसी गलतियाँ कीं जिनसे मेरा समय, नींद और शुरुआती यूज़र्स, सब कुछ दांव पर लग गया। उनमें से पाँच गलतियाँ सबसे अलग थीं।
शिप करने से पहले पूर्णता (Perfection) के पीछे भागना
मैं पूर्णता के जाल में बहुत पहले ही फंस गया था, इससे पहले कि मैं किसी चीज़ को 'परफेक्ट' कहने का हकदार बन पाता। मैंने पूरी दोपहर सिर्फ एक शेड के लिए हेक्स कोड (hex codes) बदलने, बॉर्डर-रेडियस (border-radius) वैल्यू को आठ पिक्सेल से दस करने और फिर वापस बदलने, और एक भी विज़िटर के पेज देखने से पहले हेडलाइन कॉपी को पाँच बार फिर से लिखने में बिता दी। मैंने खुद से कहा कि मैं इसे निखार रहा हूँ, लेकिन वास्तव में मैं गुणवत्ता के बहाने काम टाल रहा था। परिणाम? मैंने तीन हफ्ते की देरी से लॉन्च किया। जब साइट आखिरकार लाइव हुई, तो किसी भी यूज़र ने उस बटन के कर्व (curve) पर कोई टिप्पणी नहीं की जिसके लिए मैंने इतनी चिंता की थी। उन्हें इस बात से मतलब था कि फॉर्म बिना क्रैश हुए सबमिट होता है या नहीं।
सबक साफ था: पहले अपना काम शिप (ship) करें। आप उस फीडबैक पर काम नहीं कर सकते जो आपको मिला ही नहीं है। स्ट्रक्चर को मजबूत बनाएं, सुनिश्चित करें कि मुख्य रास्ता (core path) काम कर रहा है, और उसे लाइव कर दें। सुधार वर्ज़न दो (version two) के लिए है, वर्ज़न जीरो (version zero) के लिए नहीं। आपके यूज़र्स आपको बताएंगे कि वास्तव में क्या टूटा हुआ है और क्या केवल आपकी कल्पना में अपूर्ण है।
बहुत जल्दी बहुत कुछ बनाना
मेरा प्रोजेक्ट बुक रिकमेंडेशन (book recommendations) साझा करने के एक साधारण टूल के रूप में शुरू हुआ था। बस यही इसका मुख्य उद्देश्य था। दूसरे हफ्ते तक, मैंने एक यूज़र लॉगिन सिस्टम, एक डायनेमिक रेटिंग ग्राफ, एक नेस्टेड कमेंट सेक्शन, एक डार्क-मोड टॉगल और एक ईमेल डाइजेस्ट का खाका तैयार कर लिया था। उनमें से कोई भी ठीक से काम नहीं कर रहा था। लॉगिन फ्लो आधी बार टूट जाता था। ग्राफ में दिखाने के लिए कोई वास्तविक डेटा नहीं था। कमेंट सेक्शन डुप्लिकेट्स की अनुमति दे रहा था। इस बीच, बुनियादी बुक-लिस्टिंग फीचर—जिसके लिए यह साइट बनी थी—टूटे हुए और आधे-अधूरे अतिरिक्त फीचर्स के ढेर के नीचे दब गया था, जिससे होमपेज पर आने वाला कोई भी व्यक्ति भ्रमित हो जाता था।
एक साधारण साइट जो एक समस्या को सफाई से हल करती है, वह हमेशा एक जटिल साइट से बेहतर होगी जो दस काम खराब तरीके से करती है। कोड की एक और लाइन लिखने से पहले, उस एक काम को परिभाषित करें जो आपका प्रोडक्ट यूज़र के लिए करता है। उसे बनाएं। उसका परीक्षण करें। उसे तब तक निखारें जब तक वह विश्वसनीय न हो जाए। यदि यूज़र्स वास्तव में डैशबोर्ड या सोशल फीड मांगते हैं, तो आप उसे तब जोड़ सकते हैं। तब तक, जब किसी को केवल एक तेज़ किचन चाकू की ज़रूरत हो, तो 'स्विस आर्मी नाइफ' बनाने की इच्छा पर काबू रखें।
दिखावे के पीछे के अनुभव को नज़रअंदाज़ करना
मैंने शानदार फोंट और एक स्टाइलिश कलर पैलेट चुनने में घंटों बिताए। मैं हीरो सेक्शन (hero section) के बैकग्राउंड ग्रेडिएंट को लेकर जुनूनी हो गया था। फिर मैंने इस बात को नज़रअंदाज़ कर दिया कि साइट का उपयोग करना वास्तव में कैसा महसूस होता है। पेज बहुत धीरे लोड हो रहे थे क्योंकि मैं बिना कंप्रेशन के फुल-रेज़ोल्यूशन PNGs सर्व कर रहा था। नेविगेशन लेबल में चालाकी भरी शब्दावली का उपयोग किया गया था जो दिखने में तो अच्छी थी लेकिन लोगों को यह अंदाज़ा लगाने पर मजबूर कर देती थी कि लिंक उन्हें कहाँ ले जाएगा। बटन पतले और स्टाइलिश थे लेकिन फोन की स्क्रीन पर टैप करने के लिए बहुत छोटे थे।
मैंने कठिन अनुभव से सीखा कि विजुअल डिज़ाइन और यूज़र एक्सपीरियंस (user experience) एक-दूसरे के विकल्प नहीं हैं। एक सुंदर इंटरफ़ेस तब विफल हो जाता है जब विज़िटर्स को बैनर इमेज के लिए कई सेकंड इंतज़ार करना पड़ता है, या यदि वे दो क्लिक से कम में आप तक पहुँचने का तरीका नहीं समझ पाते। हर इंटरैक्शन को सरल बनाएं। नेविगेशन को सरल भाषा में लेबल करें। अपनी एसेट्स (assets) को कंप्रेस करें। जाँचें कि टैप टारगेट पर्याप्त बड़े हैं या नहीं। स्पीड और स्पष्टता कोई बोनस नहीं हैं जिन्हें आप अंत में जोड़ते हैं; वे वह नींव हैं जिस पर बाकी सब कुछ टिका होता है।
केवल अपने ही मशीन पर टेस्टिंग करना
मैंने पूरी साइट एक ही लैपटॉप, एक ही ब्राउज़र और एक ही स्क्रीन रेज़ोल्यूशन पर विकसित की थी। मेरी मशीन पर सब कुछ दोषरहित लग रहा था। फिर एक दोस्त ने इसे अपने iPhone पर खोला। बटन एक-दूसरे के ऊपर आ गए। टेक्स्ट अपने कंटेनर से बाहर निकल गया। एक अन्य दोस्त ने Mac पर Safari का उपयोग किया, और पूरा CSS ग्रिड लेआउट एक अपठनीय ढेर में बदल गया। मैंने चुपचाप यह मान लिया था कि अगर यह मेरे लिए काम कर रहा है, तो यह सबके लिए काम करेगा। उस धारणा की वजह से मुझे एक सप्ताहांत तक पागलों की तरह हॉटफिक्स (hotfixes) करने पड़े और शर्मिंदगी भरी माफी मांगनी पड़ी।
मेरी गलती न दोहराएं। पब्लिश करने से पहले, अपनी साइट को Chrome, Firefox, Safari और Edge में चलाकर देखें। अलग-अलग चौड़ाई वाले फोन, टैबलेट और लैपटॉप का अनुकरण (simulate) करने के लिए अपने ब्राउज़र के डेवलपर टूल्स का उपयोग करें। हर लिंक पर क्लिक करें। हर फॉर्म सबमिट करें। विंडो को ज़ोर-ज़ोर से रीसाइज करें। टेस्टिंग के दौरान पकड़े गए बग्स, प्रोडक्शन (production) में यूज़र्स द्वारा खोजे जाने वाले बग्स की तुलना में बहुत सस्ते पड़ते हैं।
फीडबैक को व्यक्तिगत हमले की तरह मानना
प्रोजेक्ट साझा करने से मैं घबरा गया था। क्या होगा अगर लोगों ने इसे नापसंद किया? जब एक सहकर्मी ने उस फीचर को हटाने का सुझाव दिया जिस पर मैंने खर्च किया था