مقال

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

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

اللغة الأصلية: العربيةنُشر: 13 سبتمبر 202616 د قراءة

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

دي رحلة إحنا كمصممين قضينا سنين بنحاول نخليها أسهل. نقلل عدد الـSteps، نحسن الـNavigation، نرتب المعلومات بشكل أوضح، نخلي الـForms أبسط، ونشيل أي Friction مش ضرورية ممكن تخلي المستخدم يقفل الـFlow في النص. وفي الأساس، أغلب شغلنا كان مبني على افتراض بسيط جدًا: المستخدم عنده هدف، وعشان يوصله لازم يعرف يستخدم الـInterface اللي إحنا صممناها.

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

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

الفرق هنا مش بس إنك وفرت كام Click. إنت ما فتحتش Filters، وما قعدتش تقارن عشر Product Cards، وما دخلتش Checkout Flow من خمس Screens، وممكن أصلًا ما تكونش زرت موقع شركة الطيران بنفسك. إنت عبّرت عن النتيجة اللي عايز توصل لها، والـAgent بدأ يتعامل مع باقي الرحلة بطريقة مختلفة عن الطريقة اللي إحنا متعودين نصمم بيها المنتجات.

ودي في رأيي أسهل نقطة نبدأ منها عشان نفهم واحدة من التغييرات المهمة اللي بتحصل حاليًا في تصميم المنتجات الرقمية: Agentic Web Design.

الفكرة مش إن المواقع هيتضاف فيها Chatbot جديد، ومش إننا هنحط زرار AI في كل شاشة ونعتبر المنتج بقى Agentic. التغيير الأعمق هو إن الـInterface نفسها بدأت تبطل تكون الوسيط الوحيد بين الإنسان والـSystem.

لسنين طويلة، النموذج الأساسي كان تقريبًا:

Human → Interface → System

إنت عايز تعمل حاجة، فلازم تدخل المنتج، تفهم هو منظم إزاي، تعرف المكان الصحيح، تستخدم الـControls، وتكمل الخطوات اللي صممها الفريق عشان في النهاية توصل للنتيجة.

لكن مع الـAI Agents بدأ يظهر نموذج إضافي:

Human → Agent → System → Outcome

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

وده تغيير مهم جدًا للمصممين، لأن الوحدة الأساسية في التجربة مش لازم تفضل دائمًا هي الـScreen أو الـClick.

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

في آخر كام سنة اتعودنا على شكل معين من الـAI Interaction: إنت تسأل سؤال، والـAI يرد عليك. تسأله يلخص Document، يكتب Email، يقترح أفكار، أو يشرح مفهوم، وفي النهاية الناتج الأساسي بيكون Response.

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

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

الـOutcome هنا مش Paragraph مكتوب فيه أسماء المرشحين. عشان الـAgent ينفذ المطلوب فعلًا، ممكن يحتاج يبحث في الـCandidates، يعرف مين موجود في المرحلة المطلوبة، يقرأ الـScores، يراجع الـCommunication History، يدخل على Calendars الفريق، يلاقي Slots مناسبة، يجهز المواعيد، ويكتب الـInvitations.

وده هو الفرق الأساسي: الـAgent مش بس بيولد Content، لكنه ممكن يستخدم Tools ويتفاعل مع Product State ويحاول يكمل Workflow مكوّن من أكتر من خطوة.

وهنا السؤال بتاع المصمم بيتغير. بدل ما نبدأ مباشرة من "إزاي أخلي المستخدم يعمل الـAction دي بأقل Friction؟"، محتاجين أحيانًا نرجع خطوة لورا ونسأل: إيه النتيجة اللي المستخدم أصلًا عايز يوصل لها؟ وهل الـFlow الحالي هو أحسن طريقة للوصول لها؟

ودي Product Design Question بامتياز، لأنها بتخلينا نراجع الافتراضات اللي بنبني عليها الـExperience من الأساس.

جزء كبير من تاريخ تصميم المنتجات الرقمية مبني حول الـNavigation. المستخدم عنده هدف، لكنه محتاج يعرف "أروح فين عشان أعمله؟"، وإحنا كمصممين بنحاول نجاوب عن السؤال ده باستخدام Information Architecture واضحة، Menu منطقية، Search كويس، Tabs، Breadcrumbs، Buttons، Forms، وكل الحاجات اللي بتساعده يتحرك جوه المنتج من نقطة للتانية.

لكن الـAgentic Interaction بيضيف نموذج مختلف شوية، لأن المستخدم بدل ما يبدأ من سؤال "أروح فين؟"، ممكن يبدأ مباشرة من "أنا عايز إيه؟".

يعني بدل Flow تقليدي بالشكل ده:

Navigate → Find → Configure → Submit

ممكن يظهر Flow تاني بالشكل ده:

Intent → Interpret → Act → Review → Outcome

وده لا يعني إن الـNavigation هتختفي، ولا إن الـWebsites هتموت، ولا إن كل شاشة هتتحول لـPrompt Box. الواجهات هتفضل أساسية جدًا في الاستكشاف، المقارنة البصرية، التعلم، الـAccessibility، مراجعة التفاصيل، الحالات الاستثنائية، وأي موقف محتاج الإنسان يشوف الصورة بنفسه.

اللي بيتغير إن الـInterface ما بقتش الطريقة الوحيدة اللي ممكن المستخدم يتعامل بيها مع المنتج، وده ينقلنا من التفكير في المنتج كمجموعة Pages فقط إلى التفكير فيه كمان كمجموعة Capabilities.

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

لو عندك Recruitment Product، إحنا كمصممين ممكن نبص عليه في صورة Screens: Candidate List، Candidate Profile، Edit Candidate، Interview، Activity، وهكذا.

لكن لو Agent هو اللي هيتعامل مع المنتج، هو مش بالضرورة مهتم بالـScreen hierarchy بتاعتك بنفس الطريقة. بالنسبة له، المنتج ممكن يكون مجموعة Actions واضحة: ابحث عن مرشح، اقرأ بياناته، أنشئ Candidate جديد، ارفع CV، انقل المرشح لمرحلة تانية، حدد Interview، ابعت Email، أو Archive Candidate.

وده لا يعني إن الـPages ملهاش قيمة، لكنه معناه إن المنتج نفسه ممكن يبقى له تمثيلين مختلفين في نفس الوقت.

التمثيل الأول موجه للإنسان وبيحتوي على Navigation وScreens وControls وVisual Hierarchy، أما التمثيل الثاني فممكن يبقى موجه للـAgent وبيعبر عن Entities وActions وInputs وOutputs وState.

وده واحد من أهم الأفكار في Agentic Web Design، لأنك بتبدأ تبص للمنتج مش بس على إنه "إيه الصفحات الموجودة؟"، لكن كمان "إيه الحاجات اللي المنتج يعرف يعملها؟".

طيب الموقع هيخلي الـAgent يفهم الـActions دي إزاي؟

هنا بنوصل لجزء تقني شوية، لكن الفكرة نفسها بسيطة ومهمة للمصمم حتى لو مش هتكتب سطر Code.

تخيل إن عندك زرار على موقع مكتوب عليه Book appointment. في الطريقة اللي Browser Agents بتشتغل بيها حاليًا في مواقف كتير، الـAgent محتاج يبص على الصفحة أو يحلل الـDOM، يكتشف إن فيه Button، يفهم من الـLabel هو بيعمل إيه، يضغط عليه، وبعدها يلاحظ التغيير اللي حصل عشان يقرر يعمل إيه بعد كده.

يعني إحنا عمليًا بنطلب من الكمبيوتر إنه يقلد إنسان بيستخدم Interface معمولة أصلًا للإنسان.

لكن الاتجاه اللي بدأ يظهر هو إن الموقع نفسه يقدر يعرف الـAgent بشكل أوضح إن عنده Capability اسمها مثلًا book_appointment، وإن الـAction دي محتاجة Doctor وDate وTime وPatient، بدل ما الـAgent يفضل يستنتج كل ده من الـUI.

واحد من الأمثلة المهمة هنا هو WebMCP، وهو proposal لسه في مرحلة Emerging/Experimental، بيتم تطويره في سياق W3C Web Machine Learning Community Group وتم تطبيقه تجريبيًا في Chrome، وبالتالي مهم جدًا ما نتعاملش معاه كأنه Standard نهائي أو نقول إن كل المواقع قريب هتستخدمه.

لكن بالنسبة للمصمم، أهمية WebMCP مش في الـAPI نفسها، وإنما في الفكرة اللي وراها: إن الـWebsite ممكن ما يبقاش مجرد صفحات بصرية الإنسان يعرف يتعامل معاها، لكنه كمان يقدر يعرّف Actions بشكل Structured بحيث الـAgents تكتشفها وتستخدمها بصورة أكثر Reliability.

ومن هنا تظهر مجموعة أسئلة شكلها تقني من بعيد، لكنها في الحقيقة مرتبطة جدًا بالـProduct Design: إيه الـActions الأساسية في المنتج؟ إيه الفرق بين Actions شبه بعض؟ إيه المعلومات اللي لازم تكون واضحة عشان الـAgent يختار صح؟ وإيه الحالات اللي ممكن تسبب Ambiguity أو Failure؟

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

خلينا نرجع لمثال الـRecruitment، لأنه بيوضح الفرق بشكل قوي.

لو بتصمم ATS بالطريقة التقليدية، ممكن الـFlow يبقى بسيط: المستخدم يدخل Candidate List، يفتح Candidate Profile، ينقله للمرحلة المناسبة، يحدد Interview، وبعدها يرسل Invitation.

لكن لو المستخدم قدر يقول: "شوف المرشحين اللي عدوا الـScreening ولسه محدش كلمهم، واختار اللي الـScore بتاعهم فوق 80، وجدول معاهم Interviews الأسبوع الجاي"، فجأة شكل المشكلة اتغير.

الـAgent محتاج يمر بأكتر من Source وأكتر من Step، وممكن يلاقي Candidate Data ناقصة، أو Calendars مش متاحة، أو شخصين بنفس الاسم، أو Tool تشتغل وTool تانية تفشل.

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

وده معناه إن التفكير في الـStates بقى أهم من مجرد التفكير في الـScreens، لأن الـPrototype اللي بيعرض Prompt وبعده Perfect Response مش كفاية عشان يمثل Agentic Experience حقيقية. لازم تصمم وتشوف إيه اللي يحصل لما الـAgent يفهم غلط، لما معلومة تكون ناقصة، لما Tool تفشل، أو لما جزء من المهمة ينجح وجزء يفشل.

الـStates بقت أهم بكتير

واحدة من الحاجات اللي شايف إنها هتتغير في شغلنا هي طريقة التفكير في الـState نفسها.

في Product تقليدي، إنت غالبًا بتصمم Empty State، Loading State، Success State، Error State، ويمكن Disabled State.

لكن في Agentic Product ممكن يكون عندك States إضافية زي Understanding، Planning، Executing، Waiting for Tool، Needs Clarification، Partial Success، Cancelled، أو Conflict Detected.

وده مش مجرد Naming جديد، لأن كل State منهم محتاجة Experience واضحة للمستخدم.

لو الـAgent شغال على Task طويلة، الـLoading Spinner لوحده غالبًا مش هيكون كفاية. المستخدم ممكن يحتاج يعرف إن النظام حمّل 214 Candidate، واستبعد الناس اللي Already Hired، ودلوقتي بيراجع Duplicate Profiles.

إنت مش محتاج تكشف الـInternal Reasoning بتاع الـModel، لكن محتاج توضح حالة الـSystem بشكل مفهوم: إيه اللي حصل، إيه اللي بيحصل دلوقتي، وإيه اللي لسه فاضل.

Visibility of System Status، واحدة من أقدم مبادئ الـUX، لسه موجودة، لكن التطبيق بتاعها بقى أعقد شوية.

حتى الـError State نفسها هتتغير

في Workflow Agentic، ممكن يحصل إن جزء من المطلوب ينجح والجزء التاني يفشل.

تخيل إن الـAgent أنشأ Candidate ورفع الـCV بنجاح، لكنه معرفش يحدد Interview لأن مفيش Interviewers متاحين الأسبوع ده.

لو ظهرت رسالة تقول "Something went wrong. Try again"، فهي تقريبًا ضيعت أهم Information المستخدم محتاجها.

الـError المفيدة هنا محتاجة توضح إيه اللي نجح، إيه اللي فشل، ليه فشل، الـSystem State بقت عاملة إزاي دلوقتي، وإيه الخيارات المتاحة بعد كده، سواء يجرب الأسبوع الجاي أو يختار Interviewer تاني أو يسيب العملية Unscheduled.

يعني Partial Success نفسها بقت State محتاجة تتصمم، وده واحد من الأمثلة اللي بتوضح إن Agentic UX مش مجرد Chat Interface شكلها جديد، لكنه طريقة مختلفة للتعامل مع Product Behavior نفسه.

والـUX Writing كمان هيتغير

في المنتجات التقليدية، ممكن Label عامة زي "Continue" أو "Submit" تعدي عادي لأن المستخدم شايف الـContext كامل قدامه.

لكن لما نفس الـLanguage تبدأ تساعد Agent يفهم الـAction، الغموض يبقى مشكلة أكبر.

فرق كبير بين Action اسمها "Process" وبين Action اسمها "Send interview invitation"، وفرق كبير بين "Done" وبين "Archive candidate".

وده يخلي الـUX Writing جزء من وضوح الـProduct Architecture نفسها، لأن اللغة مش بس بتساعد الإنسان يفهم الـInterface، لكنها ممكن كمان تساعد الـAgent يميز بين الـCapabilities المختلفة.

وده مش معناه إن كل Copy لازم تتحول لاسم Function، لكن معناه إن الـClarity هتبقى أهم من أي وقت فات.

طيب والـDesign Systems؟

ممكن أول رد فعل يكون إن Generative UI هتقلل أهمية الـDesign Systems، لأن الـAI يقدر يولد Interfaces ويغيرها حسب الـContext، لكن أنا شايف إن ده ممكن يعمل العكس تمامًا.

لما Designer أو Developer هو اللي بيستخدم الـDesign System، عنده Context وخبرة تساعده يعرف إمتى يستخدم Table، وإمتى Card، وإمتى Alert، وإمتى Confirmation Modal.

لكن لو Agent هو اللي هيبدأ يركّب Interface في Runtime، محتاج يعرف أكتر من مجرد أسماء الـComponents وأشكالها. محتاج يفهم معنى كل Component، وإمتى يستخدمها، وإيه البيانات اللي محتاجاها، وإيه الـActions المسموحة جواها.

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

وفي مشاريع زي A2UI، الفكرة نفسها مبنية على إن الـAgent يقدر يعبر عن UI Intent، لكن الـApplication هو اللي يرندر النتيجة باستخدام Component Catalog موثوق بدل ما نخلي الـModel يكتب Arbitrary HTML وCSS وJavaScript.

وده ممكن يحرك دور الـDesign System تدريجيًا من Visual Library إلى حاجة أقرب للغة بتصف معنى الواجهة وقواعد تركيبها.

وساعتها دور الـUI Designer مش هيبقى بس تصميم Screens نهائية واحدة واحدة، لكنه ممكن يشمل تصميم الـGrammar اللي النظام يقدر يستخدمها عشان يبني Interfaces بشكل ديناميكي من غير ما يكسر الـBrand أو الـAccessibility أو قواعد الـInteraction.

الـAnalytics نفسها ممكن تتغير

إحنا متعودين نقيس المنتجات عن طريق Page Views، Clicks، Funnel Completion، Conversion Rate، Drop-off، والحاجات المرتبطة بالرحلة اللي المستخدم بيمشي فيها داخل الـInterface.

لكن لو الـAgent يقدر يحقق جزء من الهدف من غير ما المستخدم يزور كل الصفحات دي، فالـFunnel التقليدي مش هيحكي القصة كاملة.

ممكن يبقى أهم عندك تعرف هل الـGoal اتحقق أصلًا، كام Step احتاجها الـAgent، كام مرة احتاج Clarification، فين الـWorkflow فشل، وإيه الـTools اللي كانت سبب المشكلة.

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

وده تغيير مهم جدًا لأن طريقة القياس نفسها بتأثر على الطريقة اللي بنصمم بيها المنتج.

هل ده كله موجود فعلًا ولا إحنا بنجري ورا Hype؟

وده سؤال مهم، لأن مساحة الـAI مليانة مصطلحات جديدة، وفيه ميل طبيعي إن أي اتجاه جديد يتقدم كأنه المستقبل المحسوم.

الحقيقة إن Agentic Web Design نفسه مش Discipline ليها تعريف Standard متفق عليه عالميًا لحد دلوقتي، وفيه مصطلحات متداخلة زي Agentic UX وAgent Experience وAgent-ready Web وAgent-native Interfaces.

وفيه تقنيات ومقترحات ما زالت Experimental، وأوضح مثال عليها WebMCP، اللي ما ينفعش نقدمه على إنه Final W3C Standard.

لكن في نفس الوقت، التغيير الأساسي اللي بنتكلم عنه مش مجرد Prediction. MCP موجود كـOpen Protocol لربط Agents بالـTools والـContext، وA2A عنده Specification للتواصل بين Agents، وفيه مشاريع فعلية حوالين Generative UI، وفي Commerce ظهر فعلًا أكتر من Protocol بيحاول ينظم تعامل الـAgents مع Discovery والشراء والدفع.

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

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

وده طبعًا مش دليل إن فيه Formula واحدة اسمها Agent-ready Design وكل ما نطبقها هنضاعف النجاح في أي Product. دي دراسة واحدة في Environment محددة، ولازم نتعامل معاها على إنها Preliminary Evidence، لكنها بتدينا إشارة مهمة جدًا: قرارات التصميم نفسها ممكن يكون لها تأثير واضح على قدرة الـAgent على فهم الموقع وتنفيذ المهمة بنجاح.

وده يفتح باب لفكرة اسمها Agent Experience أو AX، واللي بتحاول تسأل أسئلة شبه الأسئلة اللي بنسألها في UX ولكن من منظور الـAgent: هل يقدر يكتشف الـCapability؟ هل يفهم هي بتعمل إيه؟ هل يقدر يستخدمها بشكل صحيح؟ هل الـErrors مفهومة؟ وهل يقدر يتعامل مع الـEnvironment بكفاءة؟

وده مش بديل عن UX، لكنه Layer إضافية ممكن تبقى جزء من جودة المنتج في المستقبل.

هل معنى كده إن شغل الـUI/UX Designer هيقل؟

الإجابة تعتمد بشكل كبير على إنت شايف قيمة المصمم في إيه.

لو الجزء الأكبر من القيمة اللي بتقدمها هو إنتاج Screens بشكل سريع، فالجزء ده فعلًا بيتعرض لـAutomation متزايد. الـAI بقى يقدر يساعد في Wireframes وLayout Alternatives وUI Generation وCopy وحتى Code، ومن الطبيعي إن القدرات دي تتحسن أكتر.

لكن لما تبص على الأسئلة اللي Agentic Products بتخلقها، هتلاقي إن المشكلة نفسها بتكبر.

إيه الـCapabilities الأساسية في المنتج؟ إزاي الـAgent يعرف يختار بينهم؟ إيه الـStates اللي ممكن تحصل؟ إزاي نتعامل مع Ambiguity؟ إزاي نختبر Failure؟ إزاي نصمم Design System يشتغل مع Dynamic UI؟ وإزاي نقيس نجاح Product لما الـGoal نفسه بقى أهم من عدد الصفحات اللي المستخدم زارها؟

دي كلها مشاكل مرتبطة بالـProduct Thinking والـSystems والـResearch والـInformation Architecture والـHuman Behavior أكتر من ارتباطها برسم Screens.

وعشان كده أنا مش شايف إن الـAgentic Web بيقلل أهمية الـUX، لكنه ممكن يقلل قيمة الجزء اللي كان بيربط التصميم بإنتاج الـScreens فقط، وفي المقابل يزود قيمة المصمم اللي يعرف يفهم Systems ويشتغل على مستوى أوسع من الـInterface نفسها.

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

مش مطلوب منك تتحول AI Engineer، ومش محتاج تبدأ تقرأ Protocol Specifications من أول صفحة لآخر صفحة عشان تفضل Relevant، لكن على الأقل محتاج تبقى فاهم الـMental Model.

تعرف يعني إيه Agent، Tool، Context، Memory وTool Call، وتكون عندك فكرة Conceptual عن APIs، وتفهم MCP بيحل إيه، وWebMCP بيحاول يعمل إيه في سياق الويب، وتتعامل براحة مع مفاهيم زي Generative UI والـAgent States.

والأهم من كل ده إنك تتعلم تصمم للـUncertainty.

لأننا متعودين على Software Deterministic نسبيًا: المستخدم عمل X، فالنتيجة Y. لكن في AI Products، ممكن نفس الـContext ينتج Interpretation مختلفة، أو الـAgent يبقى عنده أكتر من خطة صحيحة، أو يحتاج Clarification، أو يعمل Assumption.

عشان كده الـPrototype الجيد مش اللي يورّي Perfect Response، لكنه اللي يختبر الحالات اللي الـAgent فيها بيفهم غلط، أو يحتاج معلومة، أو Tool تفشل، أو جزء من المهمة ينجح والتاني لا.

وأعتقد إن أهم Skill هنا مش Prompt Engineering، لكنها Product Judgment، لأنك محتاج تعرف تفرق بين حاجة شكلها مثير لأنها AI، وحاجة فعلًا بتحل مشكلة للمستخدم بشكل أفضل.

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

لسنين طويلة، واحد من أهم أسئلة الـUX كان: إزاي نخلي الإنسان يستخدم الـSystem بسهولة؟

السؤال ده مش هيختفي، لكن بيتضاف له سؤال جديد: إزاي نصمم Product يشتغل كويس لما التفاعل نفسه ما بقاش دايمًا عبارة عن إنسان بيتنقل بين Screens واحدة واحدة؟

وده بالنسبة لي هو جوهر الـAgentic Web Design.

التغيير الأهم مش إن الـAI بقى يعرف يولد Website، ومش إن كل Button هيتحول لـPrompt. التغيير إن الـSoftware بدأ يكتسب Interaction Layer جديدة؛ Layer فيها الـIntent أهم، والـCapabilities أوضح، والـWorkflows بقت أكثر Dynamic، والـInterface نفسها ممكن تتكوّن أو تتغير حسب الـContext.

وده ممكن يغيّر معنى حاجات إحنا متعودين عليها جدًا. الـUser Flow ممكن يتحول لـAgent Workflow، والـLoading State يبقى Execution Progress، والـDesign System يبقى له دور في تحديد القواعد اللي الـAI يقدر يبني بيها Interface سليمة، والـAnalytics تتحرك من قياس عدد الـClicks إلى قياس هل الـGoal اتحقق فعلًا ولا لأ.

فبدل ما يبقى السؤال الأساسي للمصمم هو "إيه الشاشة اللي محتاج أصممها؟"، ممكن السؤال في منتجات كتير يبقى:

"إيه الـExperience اللي محتاجين نبنيها عشان الـGoal ده يتحقق بأوضح وأكفأ طريقة؟"

وده فرق صغير في صياغة السؤال، لكنه ممكن يغير جزء كبير من الطريقة اللي بنفكر بيها في المنتجات خلال السنين الجاية.