ما هو ملف UX.md، وكيف توجّه به أدوات الذكاء الاصطناعي؟

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

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

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

لماذا قد تنتج الأداة واجهة مرتبة وتجربة غير مناسبة؟

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

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

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

ما هو ملف UX.md؟

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

طرح Tony Alicea الفكرة في مقال لدى Nielsen Norman Group عن تصميم سياق تجربة المستخدم، واقترح أن يشمل هذا السياق معرفة المستخدم وظروف استخدامه ونتائج البحث ومعايير التفاعل والمصطلحات. المقال يقدم UX.md بوصفه فرضية قابلة للتجربة، ولذلك ينبغي التعامل مع الاسم والبنية بهذه الصفة.

وتناول Peter Van Dijck المقترح في Model Context Experience، مشجعًا تجربة صيغة خفيفة يمكن تطويرها. هذه بداية مناسبة لتطبيق الفكرة: أن تختار مهمة محددة وتكتب ما يساعد على تصميمها، ثم تراجع فائدة ما كتبته.

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

ما المعلومات التي نضعها في الملف؟

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

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

يمكنك تنظيم نسخة أولى حول خمسة أجزاء:

• المهمة ونطاقها: ما الذي نصممه، وما الذي لا تعالجه هذه النسخة؟

• المعرفة المتاحة: ما الذي نعرفه عن المستخدم وظروفه، ومن أين عرفناه؟

• التوجيهات وأسبابها: ما السلوك المطلوب، ومتى ينطبق؟

• المصطلحات والمراجع: الكلمات المعتمدة وروابط المتطلبات والمكونات ذات الصلة.

• المسائل المفتوحة: ما الذي يحتاج إلى قرار أو بحث أو تحقق تقني؟

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

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

كيف تحوّل المعرفة إلى توجيه يمكن التحقق منه؟

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

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

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

ويمكن كتابة النسخة الأولى من الملف بهذه الصورة:

# سياق مهمة إنشاء طلب صيانة

## نطاق المثال
إنشاء مسودة طلب والعودة إليها ثم إرسالها.

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

## مصطلح الواجهة
استخدم «طلب صيانة» في النصوص المرتبطة بهذه المهمة.

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

ما الفرق بين UX.md و DESIGN.md و AGENTS.md؟

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

توضح وثائق DESIGN.md من Google Labs أن الصيغة تجمع قيمًا منظمة لنظام التصميم مع شرح لاستخدامها. ويصف موقع AGENTS.md ملفًا مخصصًا لسياق وتعليمات وكلاء البرمجة، مثل الإعداد والاختبارات وقواعد العمل.

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

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

كيف تستخدم الملف ضمن مهمة فعلية؟

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

أتح الملف للأداة بالطريقة التي تدعمها، وحدد الأجزاء المطلوبة من المهمة. يمكن أن تكون صياغة الطلب:

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

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

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

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

كيف تعرف أن الملف أحدث فرقًا؟

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

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

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

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

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

كيف تحافظ على فائدة الملف مع تغيّر المنتج؟

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

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

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

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

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

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

المصادر

• UX-Context Design — Nielsen Norman Group

• UX.md — Model Context Experience

• مواصفة DESIGN.md — Google Labs

• الموقع الرسمي لـAGENTS.md