كيف غيّر الذكاء الاصطناعي تجربة المستخدم وطريقة عمل المصممين؟

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

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

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

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

تصميم واجهة المستخدم أصبح أقرب إلى تجربة قابلة للتشغيل

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

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

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

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

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

البحث يحتاج إلى أدلة يمكن الرجوع إليها

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

• هل تستطيع الرجوع إلى المقطع الأصلي؟

• هل جمع النظام عبارتين متشابهتين تحت معنى واحد رغم اختلاف السياق؟

• هل اختفى رأي مخالف لأنه ورد مرة واحدة؟

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

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

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

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

أين تذهب تكلفة المراجعة؟

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

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

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

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

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

كيف نستفيد من هذا في المراجعة؟ لا تنتظر من زميلك أن يتذكر كل مرة أين يمكن أن يخطئ الناتج. جهّز أسئلة قبول واضحة:

• ما المصدر؟

• ما الحالة التي لم نختبرها؟

• ما الذي قد يجعلنا نرفض الحل؟

وجود هذه الأسئلة في المهمة نفسها يعطي المراجعة مكانًا محددًا، بدل أن تكون مجهودًا إضافيًا يختفي مع ضغط التسليم.

دور الفريق يتغير عند حدود القرار

في توزيع العمل المقترح:

• مدير المنتج يحدد المشكلة التي تستحق الحل والنتيجة المطلوبة.

• الباحث يوضح حدود ما نعرفه عن المستخدم.

• المصمم يحوّل ذلك إلى تجربة يمكن تقييمها.

• المهندس يتحقق من السلوك والقيود الفعلية.

تستطيع الأدوات مساعدة أكثر من طرف، لكن قبول المخرجات يحتاج شخصًا معروفًا يستطيع تفسير القرار وتحمل مسؤوليته.

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

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

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

المعرفة التي يجب أن تبقى داخل الفريق

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

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

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

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

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