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

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

ما الذي تثبته المصادر الرسمية؟

يصف مستودع OpenIntelligentUI الرسمي واجهة مفتوحة المصدر يختار فيها الوكيل بين النص والمكونات الجاهزة والأدوات التفاعلية المتولدة. يعتمد المشروع على CopilotKit وAG-UI، ويحدد ملف الترخيص رخصة MIT.

توضح وثيقة البنية وجود واجهة Next.js ووكيل Python يستخدم FastAPI وLangGraph، مع عرض الواجهات المخصصة داخل إطار معزول. بيانات الأمثلة المرفقة لا تثبت اتصالًا بمصدر حي.

يسرد دليل الإعداد متطلبات Node.js 22 فأحدث وpnpm 9 فأحدث وPython 3.12 فأحدث وuv، مع وصول إلى مزودي الإجابة وتوجيه التصور عبر Jev. لم نشغل نسخة منشورة ضمن هذه المراجعة، ولا ننسب إلى المشروع تاريخ إطلاق جديدًا.

ابدأ بسؤال يمكن التحقق من إجابته

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

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

ابنِ مثالًا يستطيع المراجع حسابه يدويًا

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

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

اكتب قواعد الحساب قبل اختيار الشكل

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

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

قيّم طريقة العرض بحسب المهمة

تذكر وثيقة توجيه التصورات أن Jev يختار العرض لكل رسالة جديدة، وأن الجداول الأساسية تستخدم A2UI بينما تستخدم الحاسبات والرسوم Open Generative UI. وتصف الوثيقة الاختيار بأنه حكم يصدره النموذج.

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

اجعل العربية جزءًا كاملًا من الاختبار

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

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

ضع حدود البيانات قبل دعوة المشاركين

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

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

راجع مسار المعالجة كاملًا

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

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

قارن بأداة تقليدية جيدة

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

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

نفذ جلسات ملاحظة محدودة

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

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

احسب الإنجاز الصحيح والجهد الخفي

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

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

اختبر الإخفاق قبل توسيع الوصول

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

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

قيّم التكلفة وحدد قرار المرحلة التالية

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

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

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