संक्षेप में जवाब
क्लाइंट के बिना मज़बूत पोर्टफोलियो असली सीमाओं के इर्द-गिर्द बनाना बेहतर है और हर प्रोजेक्ट की स्थिति — प्रशिक्षण, स्वयंसेवी या अनौपचारिक रीडिज़ाइन कॉन्सेप्ट — ईमानदारी से बतानी चाहिए।
केवल छात्र प्रोजेक्ट कमज़ोर सबूत क्यों हो सकते हैं
नीलसन नॉर्मन ग्रुप (NN/g) चेतावनी देता है कि विश्वसनीय पोर्टफोलियो बनाना कठिन हो जाता है अगर उम्मीदवार के पास दिखाने के लिए सिर्फ छात्र-काल के प्रोजेक्ट हों, क्योंकि ऐसे प्रोजेक्ट में अक्सर काल्पनिक सीमाएं, काल्पनिक यूज़र और पर्सोना होते हैं, जिससे वे असली परिस्थितियों में काम करने का सबूत कमज़ोर तरीके से देते हैं। NN/g सलाह देता है कि जहां संभव हो कम-से-कम एक असली प्रोजेक्ट इंटर्नशिप के ज़रिए हासिल किया जाए, और पहले से पूरे हो चुके छात्र-प्रोजेक्ट के लिए केस के विवरण में उनके अवास्तविक हिस्सों को ईमानदारी से बता दिया जाए, ताकि पाठक समझ सके कि यह प्रोजेक्ट असल में क्या साबित करता है और क्या नहीं।
इंटरैक्शन डिज़ाइन फाउंडेशन (IxDF) एक मिलती-जुलती प्रथा को अलग तरीके से देखता है: «काल्पनिक प्रोजेक्ट» किसी मौजूदा प्रोडक्ट के विश्लेषण पर आधारित हो सकता है, या पूरी तरह गढ़ा हुआ भी हो सकता है — IxDF दोनों को शुरुआत करने वालों के लिए अच्छी रणनीति मानता है। यह NN/g की चेतावनी से पूरी तरह मेल नहीं खाता: IxDF अलग से कहता है कि असली प्रोजेक्ट — स्वयंसेवी, छात्र, सामुदायिक या हैकाथॉन काम — अक्सर काल्पनिक प्रोजेक्ट से ज़्यादा मूल्यवान होते हैं, लेकिन प्रोडक्ट को खुद गढ़ने पर रोक नहीं लगाता। यह अंतर तथ्यों का नहीं, बल्कि ज़ोर देने के तरीके का है: NN/g सबसे पहले असली प्रोजेक्ट खोजने की सलाह देता है और उसके न मिलने पर ही ईमानदार स्पष्टीकरण के साथ यथार्थवादी सीमाओं की; IxDF पूरी तरह गढ़े प्रोडक्ट को भी मंज़ूरी देता है, हालांकि असली प्रोजेक्ट को अक्सर ज़्यादा मूल्यवान मानता है। इससे नीचे दिए तीन अभ्यासों के लिए संपादकीय सिद्धांत निकलता है: «शून्य से ब्रांड गढ़ें» नहीं, बल्कि «असली प्रोडक्ट और असली, जांची जा सकने वाली सीमा लें» — यह संपादकीय निर्णय NN/g की चेतावनी और खुद IxDF द्वारा असली प्रोजेक्ट को काल्पनिक से ऊपर रखने पर टिका है, न कि दोनों स्रोतों की साझा घोषित स्थिति पर।
एक गढ़े हुए ब्रांड की जगह तीन अभ्यास
तीनों अभ्यासों में से हर एक असली, जांची जा सकने वाली सीमा के इर्द-गिर्द बना है — कोई मौजूदा सेवा, कोई असली स्वयंसेवी अनुरोध या किसी दूसरी कंपनी का प्रोडक्ट — न कि गढ़े हुए मेट्रिक्स वाले काल्पनिक ब्रांड के इर्द-गिर्द। हर अभ्यास में सीमा अपनी तरह की है: पहले में मौजूदा तकनीकी प्लेटफ़ॉर्म और नेविगेशन, दूसरे में समय का बजट और भुगतान न होना, तीसरे में किसी दूसरी कंपनी की पहले से बनी विज़ुअल प्रणाली। मूल्यांकन का पैमाना भी हर अभ्यास के साथ बदलता है और यह सिर्फ इस पर निर्भर नहीं करता कि तस्वीर देखने में अच्छी लगी या नहीं।
तीनों के लिए सामान्य नियम: नतीजा किसी क्लाइंट की समीक्षा या न मौजूद बिक्री के आंकड़े नहीं, बल्कि एक जांचा जा सकने वाला आर्टिफ़ैक्ट (मॉकअप, प्रोटोटाइप, रीडिज़ाइन कॉन्सेप्ट) और खुलकर बताई गई प्रोजेक्ट स्थिति है। तीन अभ्यासों के लिए तीन फ़ॉर्मूले: «प्रशिक्षण प्रोजेक्ट, क्लाइंट का ऑर्डर नहीं», «(संगठन के प्रकार) के लिए स्वयंसेवी प्रोजेक्ट, बिना भुगतान के» और «रीडिज़ाइन कॉन्सेप्ट: किसी दूसरी कंपनी के प्रोडक्ट पर अनौपचारिक काम, न ऑर्डर न मालिक की मंज़ूरी»। स्रोत इंटरव्यू में ऐसे फ़ॉर्मूलों का वज़न पूरे किए गए ऑर्डर के वज़न से नहीं तौलते: NN/g प्रशिक्षण प्रोजेक्ट को असली परिस्थितियों में काम करने की क्षमता का कमज़ोर सबूत बताता है, और IxDF असली, स्वयंसेवी सहित, प्रोजेक्ट को काल्पनिक प्रोजेक्ट से ऊपर रखता है (ऊपर देखें) — यानी अकेले प्रशिक्षण-स्थिति का वज़न पूरे किए गए ऑर्डर से कम है। यहां से आगे का व्यावहारिक सिद्धांत संपादकीय है: क्लाइंट के लिए काम करने का झूठा प्रभाव न बने, इसलिए स्थिति को नतीजे के विवरण से पहले केस में बता देना बेहतर है, न कि इंटरव्यू तक अस्पष्ट छोड़ देना।
पहला अभ्यास: मौजूदा सेवा का ऑडिट और एक तर्कसंगत बदलाव
कोई ऐसी सेवा या इंटरफ़ेस चुनें जिसे आप खुद इस्तेमाल करते हैं — कोई अमूर्त «स्टार्टअप» नहीं, बल्कि असली स्क्रीन वाला ठोस ऐप, वेबसाइट या फ़ॉर्म जिसे आप खोलकर स्क्रीनशॉट ले सकें। एक संकीर्ण सवाल तय करें: इस इंटरफ़ेस में कौन-सा कदम सबसे ज़्यादा घर्षण पैदा करता है और क्यों। यहां सीमा तकनीकी और असली है: आप खाली जगह में नहीं, बल्कि पहले से मौजूद नेविगेशन, टाइपोग्राफ़ी और स्क्रीन के आकार के भीतर काम कर रहे हैं — और बदलाव सुझाने से पहले इसे समझाना ज़रूरी है। नीलसन नॉर्मन ग्रुप सलाह देता है कि किसी भी रीडिज़ाइन से पहले शुरुआती स्थिति को स्क्रीनशॉट या अन्य डेटा से दर्ज कर लिया जाए, ताकि बाद में अंतिम फ़ैसले की तुलना करने के लिए कुछ ठोस हो।
इंटरैक्शन डिज़ाइन फाउंडेशन इस फ़ॉर्मैट — किसी मौजूदा प्रोडक्ट का विश्लेषण और उसके लिए सुझाया गया सुधार — को शुरुआत करने वालों के लिए अनुशंसित रणनीति बताता है। केस की संरचना «संदर्भ और लेखक की भूमिका → प्रक्रिया → नतीजा और चिंतन» के अनुसार बनाएं, जैसा इसी संसाधन का एक और पद्धति-लेख बताता है: पहले, आपने कौन-सा सवाल क्यों उठाया; फिर, किन विकल्पों पर विचार किया और क्यों उन्हें छोड़ा; अंत में, आज उसी काम को फिर से करते तो क्या अलग करते।
नतीजा: एक कदम का प्रोटोटाइप और कम-से-कम एक छोड़ा गया विकल्प
इस अभ्यास का जांचा जा सकने वाला नतीजा पूरी सेवा का रीडिज़ाइन नहीं, बल्कि किसी एक ठोस कदम का मॉकअप या प्रोटोटाइप, उस कदम की «पहले» वाली स्थिति का स्क्रीनशॉट या रिकॉर्ड, और कम-से-कम एक ऐसे विकल्प का संक्षिप्त विवरण है जिस पर आपने विचार किया और इनकार की वजह के साथ छोड़ दिया। एक-दो हफ़्ते की समय-सीमा स्रोतों का कोई नियम नहीं, बल्कि संपादकीय अनुमान है — «सवाल → विकल्प → फ़ैसला» का रास्ता तय करने के लिए इतना काफ़ी है, बिना प्रशिक्षण कार्य को महीनों तक खींचे।
जांच: क्या समस्या मॉकअप देखे बिना समझाई जा सकती है
आत्म-जांच का पैमाना आसान है: क्या केस का पाठक मॉकअप देखे बिना बता सकता है कि आप असल में किस समस्या को हल कर रहे थे। इस अभ्यास में स्थिति है «प्रशिक्षण प्रोजेक्ट, क्लाइंट का ऑर्डर नहीं»; इसे केस के विवरण में सीधे बताना चाहिए, पन्ने के आख़िर में छोटे अक्षरों में नहीं — उसी भावना में जिसमें NN/g प्रशिक्षण प्रोजेक्ट के अवास्तविक हिस्सों को खुलकर बताने की सलाह देता है।
दूसरा अभ्यास: असली लेकिन अवैतनिक अनुरोध वाला स्वयंसेवी प्रोजेक्ट
दूसरी तरह की असली सीमा कोई परिकल्पना नहीं, बल्कि किसी ऐसे संगठन का जीवंत अनुरोध है जिसे डिज़ाइन-काम चाहिए पर उसके लिए बजट नहीं है। इंटरैक्शन डिज़ाइन फाउंडेशन ऐसी न-गढ़ी सीमाओं के स्रोत के रूप में सीधे धर्मार्थ और गैर-लाभकारी संगठनों, छात्र और सामुदायिक प्रोजेक्ट, हैकाथॉन का नाम लेता है — और अलग से चेतावनी देता है कि «अनुभव» के बदले श्रम अक्सर युवा डिज़ाइनरों के शोषण में बदल जाता है, इसलिए इसी सूची के नैतिक विकल्प चुनने चाहिए, न कि किसी से भी मिला कोई भी मुफ़्त काम।
इस अभ्यास और पहले अभ्यास में फ़र्क़ फ़ीडबैक की मात्रा में है: स्वयंसेवी अनुरोध में संगठन का एक प्रतिनिधि होता है जो भुगतान न होने पर भी फ़ैसले को मंज़ूर या नामंज़ूर कर सकता है। सीमा को पहले से लिखित रूप में, ब्रीफ़ के तौर पर तय करें: क्या करना है, कब तक, और किस फ़ॉर्मैट में नतीजा चाहिए। यह भुगतान वाले ऑर्डर के ब्रीफ़ पर काम करने जैसा ही हुनर है — फ़र्क़ बस इतना है कि यहां ब्रीफ़ आप खुद संगठन के प्रतिनिधि के साथ मिलकर लिखते हैं, न कि स्टूडियो के किसी क्लाइंट से बना-बनाया मिलता है।
नतीजा: ब्रीफ़, समाधान और संगठन के प्रतिनिधि की प्रतिक्रिया
जांचा जा सकने वाला नतीजा है काम और समय-सीमा वाला लिखित ब्रीफ़, खुद मॉकअप या प्रोटोटाइप, और सुझाए गए समाधान पर संगठन के प्रतिनिधि की एक छोटी दर्ज प्रतिक्रिया — भले ही यह कुछ विचारों को नामंज़ूर करना ही क्यों न हो: असली इंसान से मिले फ़ीडबैक का तथ्य ही अहम है, सिर्फ़ लेखक का अपना आकलन नहीं। कई हफ़्तों की समय-सीमा संपादकीय अनुमान है, स्रोत का नियम नहीं।
जांच: क्या इसी संगठन की सीमाओं का ध्यान रखा गया
केस के मूल्यांकन का पैमाना: क्या इसमें दिखता है कि फ़ैसला इसी संगठन की सीमाओं — उसके दर्शकों, सौंपने के बाद मॉकअप बनाए रखने के संसाधनों — को ध्यान में रखकर लिया गया, न कि किसी अमूर्त टेम्पलेट से उठाया गया। प्रोजेक्ट की स्थिति है «(संगठन के प्रकार) के लिए स्वयंसेवी प्रोजेक्ट, बिना भुगतान के», यह बताते हुए कि यह किसके लिए बनाया गया, बिना कोई ऐसा नतीजा गढ़े जिसकी संगठन ने पुष्टि न की हो।
तीसरा अभ्यास: खुली स्थिति वाला रीडिज़ाइन कॉन्सेप्ट, किसी दूसरे के प्रोडक्ट का
तीसरा फ़ॉर्मैट नैतिक रूप से सबसे जोख़िम भरा है: इसमें किसी दूसरी कंपनी का असली प्रोडक्ट लेकर उसे विज़ुअल तौर पर फिर से बनाना शामिल है, और यहीं नतीजे को उस कंपनी के पूरे किए गए ऑर्डर जैसा दिखाना सबसे आसान होता है। जांचे गए किसी भी स्रोत में इस बारे में सीधी मनाही नहीं मिलती — यह एक संपादकीय पद्धतिगत रुख़ है, जो NN/g की उस सलाह पर टिका है कि विवरण में प्रशिक्षण प्रोजेक्ट के अवास्तविक हिस्सों को खुलकर बताया जाए: यही सिद्धांत यहां किसी दूसरे के प्रोडक्ट पर काम तक बढ़ाया गया है — स्थिति तुरंत दिखनी चाहिए, न कि नियुक्ति करने वाले पक्ष को अंदाज़ा लगाना पड़े।
संपादकीय पारदर्शिता के नज़रिए से ऐसे केस को कंपनी के ऑर्डर के तौर पर पेश नहीं किया जा सकता: प्रोडक्ट या इंटरफ़ेस को स्वतंत्र विश्लेषण की वस्तु के रूप में लिया जाता है, और पहले ही वाक्य में साफ़ बताना ज़रूरी है कि काम अनौपचारिक है और इसे मालिक ने न तो ऑर्डर किया न मंज़ूर किया। लेकिन ईमानदार लेबल अकेले क़ानूनी सवाल हल नहीं करता। रूसी सिविल कोड के अनुच्छेद 1270 के अनुसार, संरक्षित रचना का अनुवाद या अन्य रूपांतरण, साथ ही रचना को जनता तक पहुंचाना, उन इस्तेमालों में गिना जाता है जो विशेष अधिकार के दायरे में आते हैं। ये रूसी क़ानून के नियम हैं: रूस के बाहर कॉपीराइट और ट्रेडमार्क सुरक्षा की व्यवस्था अलग हो सकती है, और इसे अलग से जांचना चाहिए। यह किसी ख़ास इंटरफ़ेस, लोगो या तत्व पर लागू होता है या नहीं, और कोई क़ानूनी अपवाद है या नहीं, यह वस्तु और परिस्थितियों पर निर्भर करता है। ट्रेडमार्क अधिकार अलग से नियंत्रित होते हैं और इस लेख में पूरी तरह नहीं समझाए गए हैं। इसलिए यह सामग्री किसी दूसरे का लोगो या उसका रीडिज़ाइन प्रकाशित करने की सार्वभौमिक अनुमति नहीं देती; व्यावहारिक न्यूनतम यह है कि ऑर्डर या मंज़ूरी का झूठा प्रभाव न बनाया जाए और प्रकाशन से पहले इस्तेमाल किए गए तत्वों के अधिकार अलग से जांचे जाएं।
नतीजा: खुली स्थिति वाला रीडिज़ाइन कॉन्सेप्ट
जांचा जा सकने वाला नतीजा है खुद रीडिज़ाइन कॉन्सेप्ट (मॉकअप, प्रोटोटाइप या सिस्टम) और विवरण के पहले पैराग्राफ़ में स्पष्टीकरण: क्या ठीक-ठीक फिर से बनाया गया, यह कि काम अनौपचारिक है, और कंपनी ने इसे न ऑर्डर किया न मंज़ूर किया। विवरण में कंपनी का ज़िक्र और उसके लोगो या किसी और चिह्न का इस्तेमाल — इन दोनों को अलग रखना चाहिए: ऐसे इस्तेमाल की वैधता ठोस संदर्भ और उस तत्व के अधिकारों पर निर्भर करती है, और यह लेख क़ानूनी जांच की जगह नहीं लेता।
जांच: क्या टेक्स्ट कंपनी की सहमति का संकेत देता है
प्रकाशन से पहले आत्म-जांच: केस के विवरण को दोबारा पढ़ें और हर उस जगह को चिह्नित करें जहां कोई सामान्य पाठक सोच सकता है कि कंपनी इस काम से वाकिफ़ है या इसे मंज़ूर किया, और उन जगहों को साफ़ शब्दों में फिर से लिखें। यही सिद्धांत लोगो पर भी लागू होता है, इंटरफ़ेस से अलग: असली ऑर्डर पर बनाए गए लोगो को पोर्टफोलियो में दिखाने का अधिकार, और किसी दूसरे के पहले से मौजूद लोगो के रीडिज़ाइन को दिखाने का अधिकार — दोनों अलग चीज़ें हैं जिनके अलग क़ानूनी नतीजे हैं, और यह फ़र्क़ प्रकाशन से पहले समझ लेना बेहतर है, इंटरव्यू में सवाल आने के बाद नहीं।
केस ऐसे बनाएं कि सिर्फ तस्वीर नहीं, सोचने का तरीका भी दिखे
तीनों केस के लिए एक जैसे सवाल रखना फ़ायदेमंद है — संदर्भ, लेखक की भूमिका, प्रक्रिया, विकल्प, नतीजा और चिंतन — बिना अलग-अलग प्रोजेक्ट को एक जैसे विज़ुअल टेम्पलेट में जबरन फ़िट किए। इंटरैक्शन डिज़ाइन फाउंडेशन इसी संसाधन के एक और पद्धति-लेख में «शुरुआत — प्रक्रिया — निष्कर्ष» का बुनियादी क्रम बताता है: पहले काम का संदर्भ और लेखक की भूमिका, फिर समाधान तक का रास्ता और विकल्प, अंत में नतीजा और यह चिंतन कि क्या अलग किया जाता। इस तर्क में अंतिम मॉकअप प्रक्रिया का नतीजा दिखाता है, लेकिन केस का खुद का फ़ॉर्मैट सामग्री के हिसाब से बदला जा सकता है।
इंटरैक्शन डिज़ाइन फाउंडेशन के एक वीडियो संकलन में भी ऐसा ही ज़ोर मिलता है, जिसमें कई डिज़ाइन लीडर और नियुक्ति करने वाले प्रबंधक शामिल हैं; पेज पर नाम और पद के साथ Smashing Magazine के क्रिएटिव लीड Vitaly Friedman और Netflix के प्रोडक्ट डिज़ाइन लीड Nival Sheikh का ज़िक्र है। वीडियो की ट्रांसक्रिप्ट पेज पर पढ़ी नहीं जा सकती, इसलिए इस लेख में उन्हें कोई ख़ास वाक्य नहीं दिए गए हैं। इस संकलन से IxDF का सारांश निष्कर्ष है कि पोर्टफोलियो में सोचने का तरीका दिखाया जाए और अस्पष्ट नहीं, बल्कि ठोस रहा जाए। पॉलिश की गई अंतिम तस्वीर से तुलना खुद इसी संसाधन के दूसरे पद्धति-लेखों में सीधे कही गई है — वह जो केस की संरचना बताता है, और वह जो पोर्टफोलियो की आम ग़लतियां गिनाता है। केस के लिए व्यावहारिक निष्कर्ष: सिर्फ़ «क्या नतीजा निकला» मत लिखें, बल्कि यह भी लिखें कि आपने कौन-से विकल्प क्यों छोड़े — केस की संरचना का यह हिस्सा हर फ़ॉर्मैट में ध्यान मांगता है, सिर्फ़ प्रशिक्षण वाले में नहीं।
प्रोजेक्ट की स्थिति ऐसे बताएं कि वह ऑर्डर न लगे
ऊपर इस्तेमाल की गई तीनों स्थितियां मुख्य रूप से पारदर्शिता के लिए हैं: केस पढ़ने वाला तुरंत समझ जाता है कि कहां प्रशिक्षण प्रोजेक्ट था, कहां स्वयंसेवी काम था, और कहां स्वतंत्र रीडिज़ाइन कॉन्सेप्ट था। नीलसन नॉर्मन ग्रुप पहले से पूरे हो चुके प्रशिक्षण प्रोजेक्ट के साथ ठीक यही करने की सलाह देता है — विवरण में उनके अवास्तविक हिस्सों को साफ़ बताना, ताकि नियुक्ति करने वाले पक्ष को यह न लगे कि लेखक को असली प्रोजेक्ट से फ़र्क़ ही नहीं पता। संपादकीय सलाह है कि स्थिति को केस के विवरण के पहले ही वाक्य में बता दें, ताकि विज़ुअल प्रस्तुति स्पष्टीकरण आने से पहले असली ऑर्डर का प्रभाव न बनाए।
शब्दों का चुनाव केस जितना ही ठोस होना चाहिए: «अभ्यास के लिए प्रोजेक्ट» नहीं, बल्कि «प्रशिक्षण प्रोजेक्ट, क्लाइंट का ऑर्डर नहीं, किसी ख़ास इंटरफ़ेस समाधान का अभ्यास करने के लिए बनाया गया»; «किसी संगठन की मदद की» नहीं, बल्कि «स्थानीय गैर-लाभकारी पहल के लिए स्वयंसेवी प्रोजेक्ट, बिना भुगतान के, कई हफ़्तों की अवधि में»; «ब्रांड का रीडिज़ाइन» नहीं, बल्कि «(कंपनी) के लिए रीडिज़ाइन कॉन्सेप्ट: लेखक की अपनी पहल, न ऑर्डर न मालिक की मंज़ूरी»। ये फ़ॉर्मूले संपादकीय सुझाव हैं, किसी स्रोत की सीधी बात नहीं: जांचे गए किसी भी दस्तावेज़ में इस तरह के लेबल के लिए तैयार भाषा नहीं मिलती, हालांकि प्रशिक्षण प्रोजेक्ट के काल्पनिक हिस्सों को बताने की ज़रूरत ख़ुद NN/g बताता है।
पहले से बने पोर्टफोलियो से क्या हटाएं
अगर पोर्टफोलियो में पहले से कई प्रशिक्षण प्रोजेक्ट हैं, तो उनके लिए जांच का एक अलग सेट है। इंटरैक्शन डिज़ाइन फाउंडेशन आम ग़लतियां गिनाता है जो मज़बूत काम को भी कमज़ोर कर देती हैं: केस के बजाय निजी लोगो जैसे गौण विवरणों पर समय बिताना; बिना छंटाई के, यानी सबसे अच्छे काम की क्यूरेट की गई चुनी हुई सूची के बजाय सब कुछ पोर्टफोलियो में डाल देना; सामग्री के हिसाब से ढाले बिना तैयार टेम्पलेट का इस्तेमाल; फ़ैसले लेने की प्रक्रिया का कमज़ोर दस्तावेज़ीकरण; और जवाबदेह रिस्पॉन्सिव लेआउट न होना, एक्सेसिबिलिटी की दिक्क़तें या केस के टेक्स्ट में टाइपो जैसी आम तकनीकी ख़ामियां।
नीलसन नॉर्मन ग्रुप और इंटरैक्शन डिज़ाइन फाउंडेशन एक और पड़ोसी सलाह पर सहमत हैं, जो सिर्फ़ तैयार पोर्टफोलियो को साफ़ करने के वक़्त नहीं, बल्कि प्रोजेक्ट पर काम करते वक़्त भी काम की है: विवरण भूलने से पहले, काम करते-करते ही प्रक्रिया को दस्तावेज़ करें। IxDF इसे अलग सिद्धांत की तरह बताता है — जितना संभव हो दस्तावेज़ करें और केस में ड्राफ़्ट, स्केच, तस्वीरें और वॉइस नोट शामिल करें; NN/g अलग से भविष्य के केस के लिए किसी भी काम की सामग्री सहेजने की सलाह देता है। फिर भी केस लंबे गद्य से बेहतर नहीं बनते: नियुक्ति करने वाले प्रबंधक पोर्टफोलियो को जल्दी-जल्दी देखते हैं, पूरा पढ़ते नहीं। असली सीमा वाले अभ्यासों में काम करते-करते दस्तावेज़ीकरण एक सबूत की तरह भी काम करता है: कोई ड्राफ़्ट दिखाता है कि समाधान शुरू से ही इकलौता स्पष्ट विकल्प नहीं था।
रिज़्यूमे में प्रशिक्षण प्रोजेक्ट कैसे बताएं, पोर्टफोलियो से अलग
रिज़्यूमे और पोर्टफोलियो अलग-अलग काम करते हैं। नीलसन नॉर्मन ग्रुप सलाह देता है कि रिज़्यूमे में अलग-अलग प्रोजेक्ट के लिए अलग सेक्शन बिल्कुल न बनाए जाएं: पूरा किया गया प्रशिक्षण कार्यक्रम और कोर्स वहां दो-तीन वाक्यों में, हुनर की भाषा में बताना काफ़ी है — कौन-से विषय पढ़े, कौन-से टूल सीखे — जबकि सारी जानकारी, विकल्प और स्थिति के साथ प्रोजेक्ट खुद ग़ैर-अकादमिक पाठक के लिए ढाले गए पोर्टफोलियो में बताए जाने चाहिए, न कि कार्यक्रम की आंतरिक रिपोर्ट में।
यह नियम इस लेख के तीनों अभ्यासों पर भी लागू होता है: रिज़्यूमे में पूरे किए गए कार्यक्रम या स्वतंत्र अभ्यास और मुख्य हुनर के बारे में एक सामान्य पंक्ति होनी चाहिए, न कि किसी सेवा, लोगो या संगठन से जुड़े ठोस केस के लिए अलग बिंदु। शोध, विकल्पों, प्रोजेक्ट की स्थिति और चिंतन वाला पूरा संस्करण पोर्टफोलियो में ही रहता है; जिस नियुक्ति करने वाले पक्ष को विवरण चाहिए होंगे, वह इसे खुद खोल लेगा।
व्यावहारिक चेकलिस्ट
- हर केस के विवरण में प्रोजेक्ट की स्थिति पहले वाक्य में बताई गई है, टेक्स्ट के आख़िर में छिपाई नहीं गई।
- सीमा ठोस रूप से बताई गई है: सेवा का पहले से मौजूद नेविगेशन और लेआउट, स्वयंसेवी प्रोजेक्ट का समय-बजट या किसी दूसरी कंपनी की विज़ुअल प्रणाली — अमूर्त आज़ादी नहीं।
- केस के टेक्स्ट में कम-से-कम एक छोड़े गए विकल्प और उसकी वजह पर एक पैराग्राफ़ है।
- केस में अंतिम समाधान आने से पहले सेवा या प्रोडक्ट की शुरुआती स्थिति स्क्रीनशॉट या अन्य डेटा से दर्ज की गई है।
- किसी भी केस में क्लाइंट की समीक्षा, बिक्री का आंकड़ा या ऐसे बिज़नेस रिश्ते का ज़िक्र नहीं है जो कभी हुआ ही नहीं।
- अगर केस किसी दूसरे के प्रोडक्ट या लोगो का रीडिज़ाइन कॉन्सेप्ट है, तो स्थिति पहले वाक्य में ईमानदारी से बताई गई है, और कहीं भी ऐसा संकेत नहीं दिया गया कि कंपनी ने इसे ऑर्डर या मंज़ूर किया; किसी दूसरे के चिह्न के रीडिज़ाइन को प्रकाशित करने का क़ानूनी जोख़िम अकेले एक टिप्पणी से ख़त्म नहीं होता।
- रिज़्यूमे में प्रशिक्षण कार्यक्रम और कोर्स दो-तीन वाक्यों में, हुनर की भाषा में बताए गए हैं; किसी ठोस प्रोजेक्ट के लिए रिज़्यूमे में अलग सेक्शन नहीं है — विवरण पोर्टफोलियो में ही रहता है।
सवाल और जवाब
क्या किसी असली कंपनी के लोगो का रीडिज़ाइन कॉन्सेप्ट उसकी जानकारी के बिना पोर्टफोलियो में दिखाया जा सकता है?
यहां साफ़ «हां» नहीं है। रूसी सिविल कोड का अनुच्छेद 1270 संरक्षित रचना के रूपांतरण और रचना को जनता तक पहुंचाने को उन इस्तेमालों में गिनता है जो विशेष अधिकार के दायरे में आते हैं। इसलिए किसी ख़ास रीडिज़ाइन को प्रकाशित करने के लिए अधिकार धारक की अनुमति चाहिए हो सकती है, या किसी लागू क़ानूनी अपवाद का सहारा लेना पड़ सकता है — यह इस पर निर्भर करता है कि ठीक-ठीक क्या रूपांतरित किया गया और क्या वह तत्व संरक्षित है। ट्रेडमार्क के अलग अधिकारों का विश्लेषण यहां नहीं किया गया है। ये रूसी क़ानून के नियम हैं: दूसरे देशों में कॉपीराइट और ट्रेडमार्क सुरक्षा के नियम अलग हो सकते हैं, और इन्हें अलग से जांचना चाहिए। किसी भी हालत में काम को ऐसे पेश नहीं किया जा सकता जैसे कंपनी ने इसे ऑर्डर या मंज़ूर किया हो, जबकि ऐसा हुआ ही नहीं।
पहली नौकरी के लिए पोर्टफोलियो भेजने में कितने केस चाहिए?
स्रोत अलग-अलग पर पास-पास की रेंज बताते हैं: नीलसन नॉर्मन ग्रुप विस्तृत केस के लिए 3–5 प्रोजेक्ट चुनने की सलाह देता है और कहता है कि संख्या से ज़्यादा दिखाए गए हुनर की विविधता मायने रखती है; इंटरैक्शन डिज़ाइन फाउंडेशन लगभग तीन से छह केस की रेंज बताता है। किसी ऐसी संख्या का डेटा नहीं है जो इंटरव्यू की गारंटी दे — न संपादकीय टीम के पास, न जांचे गए स्रोतों में।
क्या रिज़्यूमे में लिखना चाहिए कि कोई प्रोजेक्ट अवैतनिक या अकादमिक था?
नीलसन नॉर्मन ग्रुप की सलाह के अनुसार, रिज़्यूमे में ठोस प्रोजेक्ट के लिए अलग सेक्शन बिल्कुल नहीं बनाने चाहिए: कोर्स और प्रशिक्षण कार्यक्रम वहां दो-तीन वाक्यों में, हुनर की भाषा में बताना काफ़ी है, जबकि स्थिति, विवरण और चिंतन के साथ प्रोजेक्ट खुद पोर्टफोलियो में बताए जाने चाहिए। स्थिति — «प्रशिक्षण», «स्वयंसेवी», «रीडिज़ाइन कॉन्सेप्ट» — वहीं बताई जाती है, रिज़्यूमे में नहीं।
अगर उपलब्ध इकलौता स्वयंसेवी प्रोजेक्ट उस विशेषज्ञता में नहीं है जिसमें आगे काम करना चाहते हैं, तो क्या करें?
इंटरैक्शन डिज़ाइन फाउंडेशन सलाह देता है कि तरीक़े और केस के प्रकार लक्ष्य भूमिका के हिसाब से चुने जाएं और एक ही पोर्टफोलियो में अलग-अलग फ़ॉर्मैट मिलाए जाएं, न कि सिर्फ़ एक प्रोजेक्ट पर निर्भर रहा जाए। अगर स्वयंसेवी प्रोजेक्ट प्रोफ़ाइल से मेल नहीं खाता, तो संपादकीय सुझाव है कि इसे तभी इस्तेमाल करें जब इसमें लक्ष्य भूमिका के लिए उपयोगी तरीक़े दिखते हों, और पोर्टफोलियो की प्रोफ़ाइल को पहले या तीसरे अभ्यास से मज़बूत करें, जिन्हें चाही गई विशेषज्ञता के क़रीब चुनना आसान है।
एक विस्तृत केस बेहतर है या तीन छोटे?
स्रोत मात्रा के बजाय छंटाई के पक्ष में हैं: NN/g बताता है कि केस लंबे गद्य से बेहतर नहीं बनते, क्योंकि उन्हें वैसे भी जल्दी-जल्दी देखा जाता है, और समय कम होने पर बिखरने के बजाय एक-दो प्रोजेक्ट पर ध्यान देने की सलाह देता है। इस लेख के तीनों अभ्यास तीन अलग-अलग तरह की सीमाओं को कवर करते हैं और बिखरने के लिए नहीं, अलग-अलग हुनर के लिए बनाए गए हैं; अगर वाक़ई समय कम है, तो सभी तीन को सतही तरीक़े से शुरू करने के बजाय एक-दो अभ्यास पूरा करना ज़्यादा समझदारी है।