الفرق بين UI وUX: أين تقع مشكلة منتجك؟

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

## تجربة المستخدم أوسع من الشاشة يشمل [تعريف Nielsen Norman Group](https://www.nngroup.com/articles/definition-user-experience/) مختلف جوانب تفاعل الشخص مع المؤسسة وخدماتها ومنتجاتها. في منتج رقمي، قد تبدأ التجربة بالعثور على الخدمة وتستمر حتى إتمام المهمة أو متابعة مشكلة. في مثال افتراضي للتسجيل، ترتبط طريقة الدخول بإرسال الرمز واستعادة الحساب ورسائل الفشل. يدرس تصميم التجربة هذا المسار، ثم تحوّل الواجهة قراراته إلى عناصر قابلة للاستخدام. المثال هنا للتوضيح، وليس نتيجة اختبار منتج بعينه. ## كيف تبدأ التشخيص؟ اختر مهمة مهمة، مثل الحجز أو الدفع أو إرسال طلب. جرّبها بمحتوى واقعي على الهاتف والحاسوب. اكتب موضع التعثر بدقة: «لا يعرف المستخدم المبلغ النهائي قبل الدفع» أوضح من «التصميم قديم». راجع الملاحظات وبيانات الاستخدام المتاحة. انخفاض الإكمال لا يثبت أن الشكل هو السبب؛ فقد تؤثر الأعطال التقنية ونوعية الزيارات والعرض نفسه. المطلوب فرضية قابلة للفحص، لا إعادة تصميم مبنية على الانطباع وحده.

## لماذا لا يكفي تغيير الشكل؟ يعرض [تقرير Baymard](https://baymard.com/lists/cart-abandonment-rate) أسباباً تجارية وأخرى مرتبطة بالواجهة. افحص التكلفة والتوصيل ومسار الدفع قبل افتراض أن الشكل هو السبب. الرسم يبيّن بعض الإجابات، لا علاقة سببية مؤكدة. A: التكاليف الإضافية؛ B: بطء التوصيل؛ C: الثقة بالدفع؛ D: اشتراط حساب؛ E: طول عملية الشراء. بيانات لمتسوقين عبر الإنترنت في الولايات المتحدة بعد استبعاد فئة التصفح فقط. ليست النسب من جميع السلال، ولا يُفترض أن يبلغ مجموعها ١٠٠٪. لا يوضح النص العام حجم العينة. لا تمثل هذه البيانات معدل موقعك.

## ما المخرجات التي ينبغي الاتفاق عليها؟ قد تشمل معالجة المسار تدفقات الاستخدام وترتيب المعلومات ومخططات أولية ونموذجاً قابلاً للاختبار. ويشمل نطاق الواجهة الشاشات وحالاتها والمكونات المشتركة وشرح سلوكها. عدّ الشاشات وحده لا يوضح حجم العمل إذا غابت حالات الخطأ والفراغ والتحميل. عند التسليم للتطوير، حدّد الاستجابة لأحجام الشاشة وترتيب التركيز وسلوك النماذج. يشرح [دليل النماذج من W3C](https://www.w3.org/WAI/tutorials/forms/) دور التسميات والتعليمات والتغذية الراجعة في الاستخدام المتاح. ## هل يحتاج المشروع إلى الاثنين؟ يتداخلان غالباً، لكن نطاقهما ليس متطابقاً. إذا كان المسار مناسباً والمشكلة في اتساق العناصر ووضوح الحالات، يمكن تركيز العمل هناك. أما إذا كان تسلسل المهمة نفسه غامضاً، فالقفز إلى الشاشات النهائية يؤجل المشكلة. ابدأ بوصف مهمة حقيقية للمستخدم بدلاً من طلب عام بعنوان UI/UX. في [تصميم المنتجات الرقمية](/services/ui-ux-design) يُحدَّد النطاق حول هذه المهمة، ثم تُراجَع النتيجة بعد التنفيذ والاستخدام.

• تجربة المستخدم
• واجهة المستخدم
• تصميم تطبيقات