दृष्टिकोण
आपके इंस्ट्रक्शनल डिज़ाइन पोर्टफोलियो को साक्ष्य की एक श्रृंखला की आवश्यकता है
एक पूरा नमूना दिखाता है कि आपने क्या बनाया। साक्ष्य की एक श्रृंखला दिखाती है कि आपने समस्या की जांच कैसे की, प्रतिक्रिया कैसे चुनी, इसका परीक्षण किया, और इसकी सीमाओं को समझा।
आपका पोर्टफोलियो कहता है कि आप प्रदर्शन समस्याओं को हल करते हैं। मैं इसे कहां देख सकता हूं?
एक पॉलिश किया हुआ नमूना आपके उत्पादन कौशल को दिखा सकता है। यह पृष्ठ पर सबसे बड़े दावे को भी बिना समर्थन के छोड़ सकता है। मैं कोर्स खोल सकता हूं, लेआउट की प्रशंसा कर सकता हूं, और फिर भी यह नहीं जान सकता कि कोर्स का अस्तित्व क्यों आवश्यक था।
यदि आप एक पोर्टफोलियो चाहते हैं जो लर्निंग डिज़ाइन निर्णय को दिखाए, तो पाठक को निर्णय का पालन करने का एक तरीका दें। आपने क्या देखा? कौन सा साक्ष्य आपकी व्याख्या को बदलता है? आपने इस प्रतिक्रिया को क्यों चुना? जब किसी ने इसे आजमाया तो क्या हुआ?
मैं इसे साक्ष्य की एक श्रृंखला के रूप में सोचता हूं। प्रत्येक लिंक किसी अन्य व्यक्ति को तर्क की जांच करने देता है न कि शीर्षक को स्वीकार करने देता है।
एक दावे से शुरू करें जिसे कोई जांच सकता है।
नमूना मामले का एक टुकड़ा है। यह पूरा मामला नहीं है।
इसका मतलब यह नहीं है कि हर प्रोजेक्ट के बगल में एक लंबा निबंध लिखा जाए। इसका मतलब है कि उन कुछ विवरणों को चुनना जो आपके सबसे महत्वपूर्ण निर्णयों को समझने योग्य बनाते हैं।
चार लिंक जोड़ें।
एक उपयोगी पहले पास के लिए, मैं चार चीजें जोड़ूंगा: समस्या, साक्ष्य, निर्णय, और परीक्षण।
समस्या: काम में अंतर का वर्णन करें। "कर्मचारियों को ऑनबोर्डिंग की आवश्यकता है" एक कार्यक्रम का नाम देता है। "नए समन्वयक स्वतंत्र रूप से एक सटीक हैंडऑफ़ पूरा नहीं कर सकते" कुछ ऐसा वर्णन करता है जिसे आप जांच सकते हैं।
साक्ष्य: दिखाएं कि आपकी व्याख्या को क्या सूचित किया। यह एक अवलोकन, एक साक्षात्कार का निष्कर्ष, एक स्वीकृत प्रक्रिया, या काम का एक नमूना हो सकता है। समझाएं कि सामग्री क्या समर्थन करती है और क्या स्थापित नहीं कर सकती।
निर्णय: एक विकल्प की पहचान करें जिसने अनुभव को प्रभावित किया। शायद आपने एक प्रक्रिया अवलोकन को हैंडऑफ़ प्रैक्टिस से बदल दिया। उस विकल्प को समझाएं जिसे आपने विचार किया और आपने अलग तरीके से क्यों चुना।
परीक्षण: दिखाएं कि आपने विकल्प की जांच कैसे की। एक प्रोटोटाइप समीक्षा भ्रमित करने वाले निर्देशों को प्रकट कर सकती है। एक प्रैक्टिस कार्य गायब जानकारी को प्रकट कर सकता है। इनमें से कोई भी स्वचालित रूप से एक व्यावसायिक परिणाम को साबित नहीं करता।
जब इनमें से कोई एक लिंक गायब होता है, तो अंतर को लेबल करें। एक ईमानदार अगला कदम एक आविष्कारित परिणाम से अधिक उपयोगी है।
एक छोटे प्रोजेक्ट में श्रृंखला दिखाएं।
यहाँ एक काल्पनिक पोर्टफोलियो प्रोजेक्ट है: परियोजना समन्वयकों को काम को एक अन्य टीम को सौंपने में मदद करना।
प्रारंभिक अनुरोध एक ऑनबोर्डिंग मॉड्यूल है। इस उदाहरण में, नमूना हैंडऑफ़ सुझाव देते हैं कि बार-बार समस्या यह है कि समन्वयक पूर्ण गतिविधियों को सूचीबद्ध करते हैं लेकिन अनसुलझे निर्णयों को छोड़ देते हैं। एक प्रक्रिया मालिक पुष्टि करता है कि प्राप्त करने वाली टीम को कौन सी जानकारी की आवश्यकता है।
डिज़ाइनर एक हैंडऑफ़ टेम्पलेट और एक छोटा प्रैक्टिस गतिविधि प्रस्तावित करता है। टेम्पलेट वास्तविक कार्य का समर्थन करता है। प्रैक्टिस समन्वयक से पूछती है कि प्राप्त करने वाली टीम को काम स्वीकार करने से पहले क्या जानना चाहिए।
एक संक्षिप्त केस-स्टडी अंश।
"मैंने प्रोटोटाइप को अनसुलझे निर्णयों पर केंद्रित किया क्योंकि नमूना हैंडऑफ़ ने दिखाया कि वे अक्सर गायब होते थे। मैंने एक पुन: प्रयोज्य टेम्पलेट को प्रैक्टिस के साथ जोड़ा न कि एक व्यापक ऑनबोर्डिंग मॉड्यूल बनाने के लिए। पहला परीक्षण यह देखेगा कि क्या उपयोगकर्ता गायब निर्णय की पहचान कर सकते हैं, इसके मालिक को रिकॉर्ड कर सकते हैं, और समझा सकते हैं कि क्या अवरुद्ध है।"
ध्यान दें कि इस अंश में क्या दावा नहीं किया गया है। यह नहीं कहता कि प्रोटोटाइप ने पुनः कार्य को कम किया, उत्पादकता में सुधार किया, या पैसे बचाए। ये संभावित परिणाम हैं जिनकी जांच की जानी चाहिए, न कि प्रदर्शन से जोड़ा जाने वाला परिणाम।
पोर्टफोलियो में अनाम अवलोकन सारांश, एक एनोटेटेड डिज़ाइन निर्णय, कार्यशील प्रोटोटाइप, और परीक्षण योजना दिखा सकता है। यह बिना हर बैठक के नोट्स अपलोड किए तर्क को स्पष्ट करने के लिए पर्याप्त है।
एक वास्तविक परिणाम को एक नियोजित परिणाम से अलग करें।
एक स्व-प्रेरित प्रोजेक्ट निर्णय को प्रदर्शित कर सकता है। यह साक्ष्य प्रदान नहीं कर सकता जिसे आपने कभी एकत्र नहीं किया।
यदि आपका दर्शक काल्पनिक है, तो ऐसा कहें। यदि आपने दो लोगों का साक्षात्कार लिया है, तो उस संकीर्ण आधार को समझाएं। यदि आपने प्रोटोटाइप का परीक्षण नहीं किया है, तो "योजना बनाई गई परीक्षण" लिखें न कि "मान्य समाधान।"
मैं एक केस स्टडी में साक्ष्य के तीन स्तरों को अलग करूंगा:
- डिज़ाइन साक्ष्य: क्या आपके द्वारा चुने गए उत्तर का समर्थन करता है?
- उपयोग साक्ष्य: जब लोगों ने अनुभव को आजमाया तो क्या हुआ?
- प्रदर्शन साक्ष्य: काम में बाद में क्या हुआ, और क्या कुछ और प्रभाव डाल सकता था?
आपके पास केवल पहले स्तर का साक्ष्य हो सकता है। यह एक वैध प्रारंभिक बिंदु है। एक मजबूत दावा करने से पहले आपको अगला अवलोकन समझाना चाहिए।
हस्तांतरण उदाहरण के लिए, एक सफल प्रोटोटाइप परीक्षण यह दिखा सकता है कि प्रतिभागी निर्णय के मालिकों की कमी को पहचानते हैं। यह अभी भी यह खुला छोड़ देगा कि क्या टेम्पलेट वास्तविक हस्तांतरण के दौरान उपयोग किया जाता है और क्या प्राप्त करने वाली टीम इसे सहायक पाती है।
उन सीमाओं को स्पष्ट रखना मामले को अधिक विश्वसनीय बनाता है। यह एक साक्षात्कारकर्ता को आपके साथ चर्चा करने के लिए कुछ ठोस भी देता है।
निर्णयों के लिए संपादित करें, न कि प्रोजेक्ट की कालक्रम।
एक केस स्टडी को यह नहीं बताना चाहिए कि सब कुछ किस क्रम में हुआ।
"पहले मैंने विश्लेषण किया, फिर मैंने डिज़ाइन किया, फिर मैंने विकसित किया" पाठक को बताता है कि आपने एक प्रक्रिया का पालन किया। यह उन्हें यह नहीं बताता कि प्रक्रिया ने आपको क्या खोजने में मदद की।
उस निर्णय से शुरू करें जिसने परियोजना को बदल दिया। शायद आपने दर्शकों को संकीर्ण किया, सामग्री को हटा दिया, वितरण प्रारूप को बदल दिया, या पाया कि अनुरोधित गतिविधि गलत व्यवहार का अभ्यास कर रही थी।
फिर उस निर्णय के पीछे के सबूत दिखाएं। एक ऐसा आर्टिफैक्ट शामिल करें जो निरीक्षण करना आसान बनाता है: एक एनोटेटेड पहले और बाद का, एक कार्य विश्लेषण से एक छोटा अंश, या एक परीक्षण अवलोकन जो एक संशोधन से जुड़ा हो।
अपने योगदान की भी एक स्पष्ट सीमा दें। यदि किसी और ने शोध किया, तो उसे लिखें। यदि आपने अभ्यास को डिज़ाइन किया लेकिन रोलआउट का स्वामित्व नहीं लिया, तो उसे लिखें। सहयोग एक विश्वसनीय केस स्टडी में होना चाहिए।
एआई का उपयोग भी समान स्पष्टता की आवश्यकता है। समझाएं कि इसने क्या उत्पादन करने में मदद की, आपने आउटपुट की समीक्षा कैसे की, और एक महत्वपूर्ण निर्णय जो आपने इसका उपयोग करने या अस्वीकार करने के बारे में लिया। उपकरणों की एक सूची स्टैक को समझाती है; यह आपके योगदान को नहीं समझाती।
एक नमूने का ऑडिट करें इससे पहले कि दूसरा जोड़ा जाए।
अपने सबसे मजबूत पोर्टफोलियो नमूने को खोलें और पूछें कि क्या कोई परियोजना से अपरिचित व्यक्ति इन प्रश्नों का उत्तर दे सकता है:
- आप किस विशेष समस्या का समाधान कर रहे थे?
- आपके व्याख्या का समर्थन करने वाला क्या सबूत था?
- कौन सा डिज़ाइन विकल्प निर्णय की आवश्यकता थी?
- आपने क्या परीक्षण किया, अवलोकन किया, या परीक्षण करने की योजना बनाई?
- क्या अभी भी अनिश्चितता है?
यदि उत्तर गायब हैं, तो एक और नमूना बनाने से पहले मामले में सुधार करें। एक दूसरा पॉलिश किया हुआ आर्टिफैक्ट पहले पर unsupported claim को ठीक नहीं करेगा।
लाइव अनुभव को आसानी से पहुंचने योग्य और व्याख्या को स्कैन करने में आसान रखें। पाठक को काम को समझने के लिए पर्याप्त तर्क दिखाएं, फिर उन्हें नमूने का अन्वेषण करने दें।
मेरे लिए, यह मानक है जिसे हासिल करने का लक्ष्य रखना चाहिए: एक पोर्टफोलियो जो किसी को यह जांचने देता है कि आप कैसे सोचते हैं और आप अपने विचारों की जांच कैसे करते हैं।
पाठक को ऐसा सबूत दें जिसे वे अनुसरण कर सकें, न कि केवल एक परिणाम जिसे उन्हें प्रशंसा करनी है।
संबंधित पढ़ाई
एक परिदृश्य केवल उसी निर्णय के रूप में अच्छा है जिसे यह अभ्यास करता हैएक ठोस अभ्यास निर्णय का उपयोग करें ताकि पोर्टफोलियो नमूने के पीछे का तर्क स्पष्ट हो सके।
Learning Rewired Lab™
केस स्टडी लिखने से पहले एक ठोस मामला बनाएं।
The Lab एक संपूर्ण पेशेवर कार्यक्षेत्र है जो एक शिक्षण अनुरोध को एक ठोस प्रदर्शन समाधान में बदलता है। अनुरोध को चुनौती दें, प्रणाली की जांच करें, प्रतिक्रिया डिज़ाइन करें, और एक जुड़े हुए प्रोजेक्ट में सबूत की योजना बनाएं।
अनुरोध को चुनौती दें, प्रणाली की जांच करें, और उत्पादन शुरू होने से पहले प्रदर्शन के लिए डिज़ाइन करें।
- एक जुड़े हुए प्रोजेक्ट रिकॉर्ड
- अनुरोध और प्रदर्शन निदान
- उत्पाद-उन्मुख शिक्षण उपकरण
- AI-सहायता प्राप्त डिज़ाइन कार्यप्रवाह
- व्यावहारिक कार्यस्थल अनुप्रयोग