الاعتقاد الذي يسبق كل إطلاق
حين يقرر فريق إضافة ميزة ذكاء اصطناعي إلى منتج موجود، يكون الافتراض الضمني غالباً أن القدرة وحدها كافية. إذا كان النموذج يصنّف الطلبات بدقة، أو يقترح ردوداً أفضل، أو يلخّص المستندات في ثوانٍ، فإن المستخدم سيلجأ إليه ويعتمد عليه. هذا الافتراض يبدو منطقياً على الورق، لكنه كثيراً ما يخذل أصحابه بعد أسابيع من الإطلاق.
المشكلة ليست في الذكاء نفسه، بل في ما يراه المستخدم. فالمستخدم الذي لا يستطيع أن يقرأ ما فعلته الأداة، ولا أن يتحقق منه، ولا أن يصحّحه، سيتجاهلها ببساطة. لن يعلن ذلك في تقرير، لكنه سيعود إلى الطريقة القديمة التي يعرفها ويثق بها.
لماذا يتجاهل الناس ما لا يفهمونه؟
تخيّل موظفاً في قسم المشتريات يفتح نظام إدارة الطلبات، فيجد زراً جديداً يقول "اقترح الأفضل" ويعيد له مورداً واحداً. لا يعرف لماذا اختاره، ولا ما الذي وُزن في القرار، ولا كيف يغيّر الاختيار إن كان خاطئاً. في المرة الأولى قد يجرّب، وفي الثانية قد يتردد، وفي الثالثة سيفتح جدول البيانات القديم ويكمل عمله كما كان.
هذا السلوك منطقي تماماً. الثقة لا تُمنح لمخرجات لا يمكن فحصها، وعدم الثقة لا يتحول إلى رفض صريح، بل إلى إهمال هادئ. ولهذا فإن الميزة التي لا تُظهر خطواتها تفشل في الغالب دون أن يلاحظ أحد الفشل.
ما الذي يحتاجه المستخدم فعلاً؟
يحتاج المستخدم إلى ثلاثة أشياء على الشاشة نفسها:
- أن يرى ما فعلته الأداة: أي البيانات استخدمت، وأي قاعدة أو نمط قادها إلى النتيجة.
- أن يتحقق منه بسرعة: مصدر الاقتراح أو الجزء من الوثيقة الذي بُني عليه الملخص.
- أن يصحّحه دون عناء: زر تعديل واضح، وطريقة لإخبار النظام بأن الاقتراح خاطئ، لتتحسن النتائج لاحقاً.
حين تتوفر هذه الأشياء، يتغير موقع الأداة في عيني المستخدم. لم تعد صندوقاً أسود يُطلب منه الإيمان به، بل مساعداً يعمل أمامه ويقبل الملاحظة.
كيف يبدو ذلك في الممارسة
في DB Agency يعمل مصممو تجربة المستخدم والمهندسون معاً منذ البداية، لأن سؤال "كيف سيرى المستخدم هذا؟" لا يُطرح بعد اكتمال البناء بل قبله. عملياً، يرسم المصمم شاشة الميزة بقلم أو بأداة نماذج أولية، ثم يُعرض الشكل على مستخدمين حقيقيين قبل كتابة سطر واحد من الكود المعقد.
خلال هذه الجلسات تظهر أسئلة لم تكن في المواصفات: هل يفهم المستخدم معنى كلمة "مقترح"؟ هل يبحث عن زر التراجع فيجده؟ هل يثق بالنتيجة لأنه رآها تُبنى أمامه، أم لأنه ببساطة لم يجد طريقة لرفضها؟ الإجابات تغيّر البناء، وغالباً تغيّره بأقل مما كان سيكلفه اكتشاف المشكلة بعد الإطلاق.
قائمة قصيرة قبل الإطلاق
إن كنت تخطط لإضافة ميزة ذكاء اصطناعي إلى منتجك، فاسأل فريقك هذه الأسئلة:
- هل يستطيع المستخدم أن يعرف لماذا ظهرت هذه النتيجة؟
- هل يستطيع أن يغيّرها أو يرفضها في خطوة واحدة؟
- هل سجّلنا التصحيحات لنتعلم منها، أم تذهب كل ملاحظة إلى لا مكان؟
- هل جرّبنا الشاشة مع أشخاص من خارج الفريق قبل أن نبني؟
إذا كانت الإجابة عن أكثرها "لا"، فالمشكلة ليست في الذكاء، بل في الواجهة التي تقدّمه.
الخلاصة
ميزة الذكاء الاصطناعي لا تنفع المستخدم إلا إذا أظهرت ما فعلته وأتاحت له أن يصحّحه. الذكاء وحده لا يكسب الثقة، والثقة وحدها هي التي تجعل الميزة تُستخدم فعلاً. وفي DB Agency نبدأ من هذه الحقيقة، فنختبر الشاشة مع الناس قبل أن نعتمد البناء.