يُخالف ‘مرئية حالة النظام’ (Visibility of System Status). المستخدم لا يعرف: هل نجح التحويل؟ هل ينتظر؟ هل فشل؟ التصحيح: عرض رسالة فورية (‘تم التحويل بنجاح — رقم العملية: XXXX’)، أو مؤشر تحميل أثناء المعالجة، أو رسالة خطأ واضحة مع الخطوة التالية في حالة الفشل.

UI جيد (المظهر جميل). UX سيئ (تجربة الاستخدام: يصعب إتمام المهمة الجوهرية — الدفع). موقع يمكن أن يكون جميلًا ولا يُستخدم، أو بسيطًا ومريحًا جدًا. المثالي: الاثنان معًا. لكن إذا اضطررت للاختيار في تطبيق تجاري: UX أولًا — موقع بشع يُكمل فيه المستخدم الشراء أفضل من موقع جميل يخرج منه دون شراء.

الاسم (خيالي): أحمد حسن، 22 سنة، طالب جامعي. الهدف: تعلم Python للحصول على وظيفة. الإحباطات: الشروحات بالإنجليزي فقط، مسائل بلا تطبيق عملي. مستوى التقنية: متوسط (يستخدم الإنترنت يوميًا، لا خبرة برمجية سابقة). الجهاز الأساسي: موبايل Android. كيف يُستخدم: 30 دقيقة في المواصلات. قيمة الـ Persona: تُوجّه القرارات — ‘هل أحمد يحتاج هذه الميزة؟’

تنظيم يراعي الفحص السريع: (1) الأهم أولًا (اسم المنتج، السعر، الصورة الرئيسية) في أعلى الصفحة. (2) عناوين فرعية واضحة لكل قسم (المواصفات، التقييمات). (3) نقاط نقرية بدلًا من فقرات طويلة. (4) تمييز بصري للعناصر الأساسية (زر الشراء بلون مختلف). (5) أهم ضامن يُرى بدون تمرير (‘شحن مجاني’, ‘الأكثر مبيعًا’).

منع الأخطاء: التصميم يمنع المستخدم من ارتكاب الخطأ قبل أن يحدث. أمثلة في حجز الطيران: (1) تعطيل التاريخ الماضي في منتقي التاريخ — المستخدم لا يستطيع اختيار يوم مضى. (2) تنسيق تلقائي لرقم جواز السفر. (3) تحذير ‘رحلة العودة قبل الذهاب’ قبل الدفع. (4) خانة تأكيد البريد الإلكتروني لتجنب أخطاء الكتابة.

Wireframe: مخطط هيكلي بالأبيض والأسود يُحدد مواضع العناصر ووظيفتها — بدون ألوان أو تفاصيل مظهرية. Mockup: تصميم مرئي كامل (ألوان، خطوط، صور) لكن غير تفاعلي — صورة ثابتة. Prototype: نموذج تفاعلي قابل للنقر يُحاكي تجربة الاستخدام الحقيقية دون كتابة كود كامل. الترتيب: Wireframe → Mockup → Prototype → تطوير.

أسباب UX محتملة: (1) إلزامية إنشاء حساب قبل الشراء (اجعلها اختيارية أو أضف ‘شراء كضيف’). (2) تكاليف شحن تظهر فجأة في آخر خطوة — عنصر مفاجأة سلبية. (3) عملية دفع طويلة (6 خطوات بدلًا من 2). (4) نقص في بيانات الثقة (لا شهادات أمان، لا سياسة إرجاع واضحة). (5) الموقع لا يتذكر بيانات المستخدم في المرة التالية.

Accessibility: تصميم يُتيح استخدام الموقع لأشخاص ذوي إعاقات (بصرية، سمعية، حركية). مبادئ WCAG: (1) قابل للإدراك (Perceivable) — النصوص البديلة للصور، تعليق الفيديو. (2) قابل للتشغيل (Operable) — التنقل بلوحة المفاتيح دون ماوس. (3) قابل للفهم (Understandable) — لغة واضحة، أخطاء مفهومة. (4) متين (Robust) — يعمل مع قارئات الشاشة.

نمط F: دراسات تتبع العيون وجدت أن المستخدمين عادةً يقرؤون السطر الأول أفقيًا، ثم السطر الثاني أفقيًا أقصر، ثم ينزلون رأسيًا على الجانب الأيسر (RTL معكوسة للعربية: الجانب الأيمن). التوجيه: المعلومات الأهم في السطرين الأولين والجانب المقروء أولًا. القوائم الجانبية الأيمن في المواقع العربية أكثر مشاهدةً من الأيسر.

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

نظرية حِمل الإدراك: الذاكرة العاملة لها سعة محدودة — كلما زادت القرارات والمعلومات المطلوبة في نفس الوقت، زاد الجهد المعرفي وزاد احتمال الخطأ أو التخلي. في النموذج: (1) اجعله قصيرًا (اسأل فقط ما تحتاجه). (2) قسّمه لخطوات. (3) تعليمات واضحة قبل كل حقل. (4) تحقق فوري من صحة الحقل (لا ترسل وتُخبر بالخطأ بعد الإرسال).

A/B Testing: عرض نسختين مختلفتين لمجموعتين من المستخدمين في نفس الوقت وقياس أيهما تُحقق الهدف المطلوب. مثال: متجر يريد تحسين معدل النقر على ‘اشتر الآن’. النسخة A: زر أزرق. النسخة B: زر برتقالي. النتيجة: البرتقالي يحصل على نقرات أكثر بـ 23%. القيمة: قرارات مبنية على بيانات حقيقية لا تفضيلات شخصية.