الرجوع للروابط
مقال

لما المستخدم مبقاش هو اللي بيضغط: إيه هو الـAgentic Web Design؟

اللغة الأصلية: العربيةنُشر: 13 سبتمبر 2026

الـAgentic Web Design يبدأ من فرق واضح: المستخدم يصف النتيجة، والـAgent يتولى أجزاء من الطريق إليها. الشاشة والـClick يفضلوا مهمين، لكنهم مبقوش الطريق الوحيد بين الإنسان والمنتج.

تخيل إنك عايز تحجز رحلة لدبي. في الـFlow المعتاد هتحدد التاريخ، وتفتح الـFilters، وتقارن الرحلات، وتراجع الشنط ومواعيد الوصول، ثم تدخل بياناتك وتكمل الدفع.

ممكن بدل كل ده تقول للـAI: «احجزلي أرخص رحلة مباشرة لدبي يوم الخميس بعد الساعة 6، بحد أقصى 12 ألف جنيه، ويفضل يكون مسموح بشنطة 23 كيلو».

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

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

من الـInterface إلى النتيجة

الويب الذي صممناه لسنوات اعتمد غالبًا على هذا النموذج:

Human → Interface → System

المستخدم يعرف هدفه، لكنه يحتاج أن يفهم تنظيم المنتج، ويعثر على المكان الصحيح، ويستخدم الـControls، ثم يكمل الخطوات التي حددها الفريق.

الـAI Agents أضافت نموذجًا ثانيًا:

Human → Agent → System → Outcome

المستخدم يوضح الـGoal أو الـIntent. الـAgent يفسر المطلوب، ويحدد خطواته، ويستخدم Tools، ويراجع النتائج، ويطلب توضيحًا أو موافقة عند الحاجة.

ده يغيّر سؤال المصمم. بدل ما نبدأ من «كيف نقلل عدد الخطوات في الشاشة؟»، نبدأ من «ما النتيجة التي يريدها الشخص؟ وما أفضل توزيع للعمل بينه وبين الـAgent والـSystem؟».

رحلة من هدف المستخدم إلى الأدوات والمراجعة والنتيجة
رحلة من هدف المستخدم إلى الأدوات والمراجعة والنتيجة

يعني إيه Agent أصلًا؟

الـAI الذي يجيب عن سؤال أو يلخص ملفًا ينتج Response. الـAgent يحاول إكمال Goal من خلال سلسلة أفعال لها أثر على حالة المنتج.

في Recruitment Product، مثلًا، ممكن تطلب منه: «شوف المرشحين اللي عدوا الـScreening ولسه محدش كلمهم، اختار اللي الـScore بتاعهم أعلى من 80، وجهز Interviews الأسبوع الجاي».

تنفيذ الطلب يحتاج أن يبحث في الـCandidates، ويقرأ الـScores والـCommunication History، ويراجع Calendars الفريق، ويقترح مواعيد، ويجهز الـInvitations. كل خطوة تعتمد على نتيجة الخطوة السابقة، وبعضها قد يحتاج موافقة أو معلومة إضافية.

الـAgent هنا يجمع بين أربع قدرات:

  • يفهم الهدف والقيود.
  • يضع خطة قابلة للتعديل.
  • يستخدم أدوات تغيّر Product State.
  • يراجع النتيجة ويعرف متى يتوقف أو يسأل.

بالنسبة للمصمم، القيمة في الجملة الأخيرة. الـAgent الجيد لا ينفذ كل ما يستطيع تنفيذه؛ يعرف أي قرار يحتاج الإنسان أن يراه ويوافق عليه.

من الـNavigation إلى الـIntent

جزء كبير من تصميم المنتجات الرقمية يجاوب عن سؤال: «أروح فين عشان أعمل ده؟». بنستخدم Information Architecture، وNavigation، وSearch، وTabs، وForms عشان نساعد المستخدم يتحرك داخل المنتج.

الـAgentic Interaction يسمح له أن يبدأ من سؤال أقرب لهدفه: «أنا عايز إيه؟».

الـFlow التقليدي قد يكون:

Navigate → Find → Configure → Submit

والـFlow المعتمد على Agent قد يصبح:

Intent → Interpret → Act → Review → Outcome

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

لذلك نحتاج أن نفكر في المنتج كمجموعة Pages يراها الإنسان، ومجموعة Capabilities يستطيع الإنسان أو الـAgent استخدامها.

من الـPages إلى الـCapabilities

مصمم الـATS يرى Candidate List، وCandidate Profile، وInterview، وActivity. الـAgent يرى قدرات: ابحث عن مرشح، اقرأ بياناته، ارفع CV، انقله إلى مرحلة، حدد Interview، أرسل Email، أو Archive Candidate.

المنتج هنا له تمثيلان يعملان معًا:

  • تمثيل للإنسان: Navigation، وScreens، وControls، وVisual Hierarchy.
  • تمثيل للـAgent: Entities، وActions، وInputs، وOutputs، وState.

ده لا يقلل قيمة الـUI. بالعكس، يجبرنا أن نفهم معنى كل Action وحدوده قبل أن نرسمها. لو الفرق بين `archivecandidate` و`rejectcandidate` غير واضح للفريق، فالـAgent سيكشف الغموض بسرعة لأنه يحتاج تعريفًا صريحًا لكل Capability.

الانتقال من صفحات يزورها المستخدم إلى قدرات واضحة يستخدمها الإنسان أو الـAgent
الانتقال من صفحات يزورها المستخدم إلى قدرات واضحة يستخدمها الإنسان أو الـAgent

كيف يفهم الـAgent ما يستطيع الموقع فعله؟

Browser Agents الحالية تتعامل أحيانًا مع الصفحة مثل الإنسان: تقرأ الـDOM أو Screenshot، تكتشف Button، تستنتج معناه من الـLabel، تضغطه، ثم تلاحظ ما تغيّر.

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

WebMCP يقترح طريقًا أوضح. الموقع يستطيع تعريف Tool مثل `bookappointment` مع الـInputs المطلوبة: Doctor، وDate، وTime، وPatient. الـAgent يكتشف الـAction ويستخدمها بصورة Structured بدل استنتاج كل شيء من شكل الزرار.

WebMCP ما زال Proposed Web Standard وتحت تجربة Origin Trial في Chrome. الـAPI قابلة للتغيير، ولا يصح تقديمها كـW3C Standard نهائي. أهميتها للمصمم في الفكرة التي تختبرها: الموقع يستطيع أن يعلن عن قدراته بطريقة Machine-readable، مع الحفاظ على الواجهة التي يراها الإنسان.

الأسئلة الناتجة Product Design Questions قبل أن تكون API Questions:

  • ما الـActions الأساسية في المنتج؟
  • ما الفرق بين Actions المتشابهة؟
  • ما المعلومات اللازمة لاختيار Action صحيح؟
  • أي Action تحتاج Preview أو Confirmation؟
  • ماذا يحدث عند الغموض أو الفشل؟

لما الـUser Flow يتحول إلى Agent Workflow

في الـATS التقليدي، المستخدم يفتح قائمة المرشحين، ثم ملف المرشح، ثم يغير المرحلة، ويحدد مقابلة، ويرسل الدعوة. المسار معروف ومحدود.

طلب واحد للـAgent قد يجمع البحث، والتصفية، وقراءة السجل، ومراجعة التقويم، وإنشاء المواعيد. أثناء التنفيذ قد يجد بيانات ناقصة، أو شخصين بالاسم نفسه، أو Calendar غير متاح، أو Tool نجحت وأخرى فشلت.

المصمم هنا لا يرسم Path ثابتًا من Screen A إلى Screen B. هو يصمم System فيه Branches، وLoops، وClarifications، وTool Failures، وPartial Success.

الـPrototype الذي يعرض Prompt ثم Perfect Response يخفي أغلب التجربة. الـPrototype المفيد يختبر الحالات التي يفهم فيها الـAgent الطلب بشكل ناقص، أو يحتاج معلومة، أو يواجه تعارضًا، أو ينجح في جزء ويعجز عن الباقي.

الـStates بقت أهم من الشاشة

المنتج التقليدي يحتاج Empty، وLoading، وSuccess، وError، وDisabled States. الـAgentic Product يضيف حالات مرتبطة بسير العمل نفسه:

  • Understanding
  • Planning
  • Executing
  • Waiting for tool
  • Needs clarification
  • Waiting for approval
  • Partial success
  • Conflict detected
  • Cancelled

كل State تحتاج أن تجيب عن سؤال المستخدم في اللحظة نفسها. أثناء مهمة طويلة، Spinner لا يوضح شيئًا. الأفضل أن يعرف الشخص أن النظام حمّل 214 مرشحًا، واستبعد من تم توظيفهم، ويراجع الآن الملفات المكررة.

ده لا يعني كشف الـInternal Reasoning الخاص بالـModel. المطلوب هو Visibility of System Status: ما الذي اكتمل، وما الذي يحدث، وما الذي يحتاج تدخلًا، وما الذي سيحدث بعد الموافقة.

حالات تنفيذ مرئية توضّح التقدم وطلب التوضيح والنجاح الجزئي وقرار الإنسان
حالات تنفيذ مرئية توضّح التقدم وطلب التوضيح والنجاح الجزئي وقرار الإنسان

الـError ليست نهاية واحدة

قد ينشئ الـAgent Candidate ويرفع الـCV، ثم يفشل في تحديد Interview لأن الأسبوع لا يحتوي على Interviewers متاحين.

رسالة مثل «Something went wrong. Try again» تمحو أهم معلومات في الـWorkflow. المستخدم يحتاج أن يعرف:

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

Partial Success ليست نسخة أخف من Error State. هي حالة مستقلة تحتاج Summary واضحًا، وActions قابلة للتوقع، وطريقًا لاستكمال المهمة من النقطة الصحيحة.

الـUX Writing جزء من الـArchitecture

Label عامة مثل «Continue» أو «Process» قد تمر عندما يرى الإنسان كل السياق حولها. الـAgent يحتاج أسماء تميّز القدرات بوضوح.

`Send interview invitation` أدق من `Process`. و`Archive candidate` أدق من `Done`.

الهدف ليس تحويل كل Copy إلى اسم Function. الهدف أن تكون اللغة واضحة للإنسان، ومتسقة مع معنى الـAction الذي يعلنه المنتج للـAgent. هنا تصبح تسمية الـEntities والـStates والـActions جزءًا من Product Architecture، لا طبقة تلميع في نهاية التصميم.

الـDesign System قد يتحول إلى Grammar

Generative UI لا تلغي الحاجة إلى Design Systems. الـAgent الذي يركّب Interface وقت التشغيل يحتاج قواعد أكثر من المصمم أو المطور الذي يعرف سياق المنتج.

Component مثل Comparison Table يحتاج تعريفًا يتجاوز الـStyles والـVariants. النظام يجب أن يعرف أنه يقارن عنصرين أو أكثر، وما البيانات اللازمة، ومتى يصبح Card أو List اختيارًا أفضل، وأي Actions يسمح بها مثل Sort وFilter وSelect.

A2UI يقدم مثالًا لهذا الاتجاه. الـAgent يعبّر عن UI Intent بصيغة Declarative، والـApplication يرندر النتيجة من Component Catalog موثوق. الـModel لا يرسل Arbitrary HTML وJavaScript؛ التطبيق يحتفظ بالتحكم في الـBrand والـAccessibility والأمان.

ده يوسّع دور الـUI Designer. إلى جانب تصميم الشاشات والحالات، سيصمم القواعد التي تسمح للنظام بتركيب Interface متماسكة من غير أن يكسر الـHierarchy أو الـInteraction Patterns أو هوية المنتج.

الـAnalytics تتحرك من الـClick إلى الـGoal

Page Views، وClicks، وFunnel Completion، وDrop-off تصف رحلة المستخدم داخل الواجهة. عندما ينفذ الـAgent أجزاء من المهمة خارج الصفحات المعتادة، الـFunnel لا يروي القصة كاملة.

مقاييس Agentic Workflow قد تشمل:

  • هل تحقق الـGoal؟
  • كام خطوة احتاجها التنفيذ؟
  • كام مرة طلب الـAgent Clarification؟
  • أين فشل الـWorkflow؟
  • أي Tool سببت الفشل؟
  • كم مرة احتاج المستخدم أن يصحح النتيجة؟
  • هل كرر النظام Action لها أثر؟

القياس هنا ينتقل من «المستخدم ضغط فين؟» إلى «هل المهمة انتهت بصورة صحيحة وآمنة؟».

أين ينتهي الواقع ويبدأ الـHype؟

Agentic Web Design ليس Discipline لها تعريف موحد حتى الآن. ستجد مصطلحات متداخلة مثل Agentic UX، وAgent Experience، وAgent-ready Web، وAgent-native Interfaces.

بعض التقنيات ما زالت Experimental، ومنها WebMCP. وفي المقابل، توجد بنية حقيقية تُستخدم اليوم: MCP لربط التطبيقات بالأدوات والـContext، وA2A للتواصل بين Agents، وA2UI وMCP Apps للواجهات الديناميكية، وبروتوكولات Commerce تنظم البحث والشراء والدفع من خلال Agents.

ورقة Designing Agent-Ready Websites for AI Web Agents المنشورة على arXiv في يوليو 2026 اختبرت نسختين من Ecommerce Prototype: نسخة Human-oriented، ونسخة أضاف الباحثان لها Machine-readable Structure ووضوحًا أكبر في الـActions وإشارات تساعد القرار.

شملت التجربة خمس مهام، وثلاثة Browser-agent Models، و300 Run. ارتفع Strict Success من 49.3% في النسخة الأساسية إلى 89.3% في النسخة Agent-ready، وانخفض متوسط عدد الخطوات من 9.31 إلى 6.49.

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

من هنا يظهر مفهوم Agent Experience أو AX. هو يسأل: هل يستطيع الـAgent اكتشاف الـCapability؟ هل يفهم مدخلاتها وأثرها؟ هل يتعامل مع الـErrors؟ وهل يصل إلى النتيجة من غير أن يعرّض المستخدم لقرار غير واضح؟

AX لا تستبدل UX. هي طبقة جودة إضافية لمنتج يستخدمه الإنسان بنفسه أو من خلال Agent يعمل بالنيابة عنه.

ماذا يتغير في دور مصمم الـUI/UX؟

إنتاج Screens أصبح أسرع بفضل أدوات توليد الـLayout والـCopy والـPrototype والـCode. الجزء الذي يقتصر على رسم شاشة قابلة للتسليم يتعرض لمزيد من الـAutomation.

في المقابل، الـAgentic Products توسع مساحة المشكلة:

  • تحديد الـCapabilities الأساسية وحدود كل واحدة.
  • توزيع القرار بين الإنسان والـAgent والـSystem.
  • تصميم States للغموض والفشل والنجاح الجزئي.
  • بناء Approval وUndo وAudit paths مفهومة.
  • تعريف Design System يمكن أن يدعم Dynamic UI.
  • قياس نجاح المهمة بدل الاكتفاء بحركة المستخدم بين الصفحات.

هذه مهام Product Thinking وSystems Design وResearch وInformation Architecture وHuman Behavior. قيمة المصمم تتحرك إلى الحكم على النظام، لا سرعة إنتاج الشاشة فقط.

كمصمم، محتاج تتعلم إيه؟

مش مطلوب تتحول إلى AI Engineer. المطلوب Mental Model يسمح لك أن تصمم السلوك قبل شكله.

ابدأ بفهم Agent، وTool، وContext، وMemory، وTool Call. كوّن معرفة Conceptual بالـAPIs، وما الذي يحله MCP، وما الذي يجربه WebMCP داخل الويب، وكيف تتعامل Generative UI مع Component Catalogs.

بعدها صمّم للـUncertainty. اختبر نفس المهمة عندما:

  • يكون الطلب ناقصًا.
  • يفسر الـAgent كلمة بأكثر من معنى.
  • تفشل Tool بعد نجاح Tool أخرى.
  • يحتاج Action إلى موافقة.
  • تتغير البيانات أثناء التنفيذ.
  • يطلب المستخدم الإلغاء أو التراجع.

الـPrototype الجيد لا يبيع Perfect Response. هو يكشف كيف يتصرف المنتج عندما لا تسير الخطة كما توقع الفريق.

أهم Skill هنا هي Product Judgment: تعرف متى يختصر الـAgent مجهودًا حقيقيًا، ومتى يضيف غموضًا أو مخاطرة كان الـFlow المباشر يتجنبها.

في الآخر، إحنا بنصمم إيه؟

سنوات من UX ركزت على سؤال: كيف نساعد الإنسان على استخدام الـSystem بسهولة؟ السؤال الجديد يضيف وسيطًا يستطيع التخطيط والتنفيذ والتصرف في حالة المنتج.

لذلك قد يتحول الـUser Flow إلى Agent Workflow، والـLoading State إلى Execution Progress، والـDesign System إلى قواعد تركيب، والـAnalytics إلى قياس تحقق الهدف.

السؤال العملي للمصمم لم يعد مقتصرًا على «إيه الشاشة اللي محتاج أصممها؟».

إيه التجربة اللي محتاجين نبنيها عشان الهدف يتحقق بوضوح وكفاءة، ويظل الإنسان فاهمًا ومسيطرًا على القرار؟

هذا هو جوهر Agentic Web Design: تصميم منتج يخدم الإنسان عندما يستخدم الواجهة، ويخدمه أيضًا عندما يرسل Agent ليتعامل مع النظام بالنيابة عنه.

المصادر