تحليل السياق: القيود والموارد وبيئة التعلم

التصميم الذي ينجح في المختبر قد يفشل في الواقع

تحليل السياق يسأل أين سيحدث التعلم، وأين سيُستخدم ما تم تعلمه، وما الموارد والقيود التي تشكل القرار. هناك سياق للتعلم نفسه: الوقت، الجهاز، الاتصال، الدعم، اللغة، إمكان الرجوع للمحتوى، وطريقة التقويم. وهناك سياق للأداء بعد التعلم: الأدوات الفعلية، ضغط الوقت، الإشراف، المعايير، الموارد المرجعية، والعواقب المترتبة على الخطأ. إذا تجاهلنا الفجوة بين السياقين قد يتقن المتعلم مثالًا مريحًا داخل الدورة ثم يعجز عن النقل عندما تتغير الظروف.

حوّل القيود إلى معطيات تصميم

القيد ليس عذرًا لتخفيض المخرج تلقائيًا، لكنه يغيّر طريقة الوصول إليه. إذا كان المتعلمون يملكون عشر دقائق متصلة فقط في كل مرة، فقد نجزئ الشرح والممارسة مع حفظ التقدم، لكننا لا نحذف مهارة تحتاج ممارسة ممتدة من دون إعادة فحص المخرج. إذا كان الاتصال متقطعًا، نبحث عن محتوى خفيف أو قابل للتنزيل أو عن نقطة اتصال مخططة. وإذا كان الأداء الحقيقي يعتمد على مرجع عمل، فمن الأفضل أن يتدرب المتعلم على استخدام المرجع بدل مطالبة الذاكرة بحفظ تفاصيل يمكن الرجوع إليها بأمان أثناء العمل.

الموارد مهمة مثل القيود

قد يملك المشروع مدربًا خبيرًا لساعتين فقط، ومصورًا غير متاح، لكن لديه أمثلة عمل حقيقية منزوعة البيانات الحساسة ومرجع رسمي واضح. هذه ليست قائمة نقص فقط؛ إنها خريطة موارد. ربما تكون أفضل قيمة من وقت الخبير هي تسجيل تفسير لثلاثة أخطاء عالية الأهمية أو مراجعة الحالات التي سيبنيها المصمم، لا تسجيل محاضرة طويلة. كما قد يسمح وجود نظام إدارة تعلم أو أداة تأليف ببعض التفاعل، لكن وجود الميزة لا يعني أن استخدامها ضروري. نختار ما يخدم الأداء ضمن الموارد الموجودة.

فرّق بين القيد والافتراض

القيد معلومة نعاملها حاليًا كشرط تصميم، مثل «لا يتوفر اتصال أثناء المهمة» بعد التحقق من ذلك. أما الافتراض فهو شيء نستخدمه مؤقتًا لأن الدليل لم يكتمل، مثل «نتوقع أن أغلب المتعلمين يملكون هاتفًا حديثًا». الافتراض يحتاج تحققًا أو خطة إذا اتضح خطؤه. وضع الافتراض في قائمة القيود يجعله يبدو حقيقة ويزيد احتمال بناء قرار هش. وفي المقابل، تجاهل القيد لأنه مزعج لا يجعله يختفي.