(1) القياس: تحديد المقياس الحالي بدقة (1.5% من أي مصدر حركة؟). (2) التحليل: تحليل Funnel لإيجاد أكبر نقطة تسرب، Heatmaps لزر الشراء. (3) الفرضية: ‘إضافة ضمان استرداد 30 يومًا سيزيد الثقة ويرفع التحويل’. (4) التجريب: A/B Test لصفحة المنتج مع وبدون الضمان. (5) القياس: هل ارتفع معدل التحويل في مجموعة B؟ (6) التطبيق إذا كانت النتيجة إيجابية وذات دلالة إحصائية.

Waterfall: تخطيط كامل ← تصميم ← تطوير ← اختبار ← إطلاق — كل مرحلة تُكتمل قبل التالية. Agile: دورات قصيرة (2 أسبوع) تُنتج نسخة قابلة للاستخدام وتُتيح التعديل المستمر بناءً على ردود الفعل. Waterfall يناسب: مشاريع واضحة المتطلبات غير المتغيرة (موقع حكومي إداري). Agile يناسب: منتجات رقمية حيث المتطلبات تتطور مع الاستخدام.

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

Average Session Duration: متوسط الوقت الذي يقضيه المستخدم في كل زيارة. لا، ليس دائمًا أفضل. وقت جلسة طويل قد يعني: (إيجابي) محتوى جذاب يحتفظ باهتمام المستخدم. أو (سلبي) المستخدم ضائع لا يجد ما يبحث عنه. التفسير الصحيح يعتمد على السياق — في موقع أخبار: وقت أطول = أكثر قراءة = إيجابي. في موقع checkout: وقت أطول = يكافح لإتمام الشراء = سلبي.

CRO: مجموعة أساليب لزيادة نسبة الزوار الذين يُتمون الهدف المنشود (شراء، تسجيل، اتصال). العلاقة مع UX: CRO و UX يشتركان في كثير من الأدوات (A/B Testing, User Testing) لكنهما يختلفان في التركيز. UX يُركّز على تجربة الاستخدام الشاملة ورضا المستخدم. CRO يُركّز على مقاييس تجارية محددة. الممارسة الجيدة: CRO مبني على UX — تحسين التجربة يؤدي للتحويل، لا العكس.

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

Performance Budget: قيود مُحددة مسبقًا لمقاييس أداء الصفحة لا يُسمح تجاوزها (مثال: وقت التحميل < 3 ثوانٍ، حجم الصفحة < 2MB، LCP < 2.5s). يُستخدم: قبل بدء التطوير بتحديد هذه الحدود، أدوات CI/CD ترفض تلقائيًا أي كود يتجاوزها. يُمنع تضخم أداء الموقع تدريجيًا ('Performance Debt').

MVP: أبسط نسخة من المنتج تُقدّم القيمة الجوهرية وتُتيح جمع ملاحظات حقيقية من مستخدمين فعليين. الارتباط بالتحسين التكراري: MVP يُطلق مبكرًا للتحقق من الافتراضات قبل بناء كل شيء. كل ملاحظة تُوجّه Iteration التالية. بدلًا من: 18 شهرًا بناء ← إطلاق ← اكتشاف أن الافتراض الأساسي خاطئ = كارثة. الحل: أطلق MVP في 3 أشهر ← تعلّم ← حسّن.

الأخطاء التي تمنع الاستخدام (Blockers): مشكلات تمنع المستخدم من إتمام المهمة كليًا — الشراء يفشل تقنيًا، التسجيل لا يعمل. الأولوية: إصلاح فوري. مشكلات قابلية الاستخدام: تُعيق التجربة لكن لا تمنعها — زر صعب الإيجاد، نص صغير الحجم. الأولوية: مهمة لكن تُجدول في التكرار التالي. مبدأ: لا تُوسّع بنية منزل بناؤه معيب — أصلح الأساس أولًا.

مخاطر Big Bang: (1) لو كان فيه خطأ — المستخدمون كلهم يتأثرون فورًا. (2) صعب تحديد أي تغيير أحدث مشكلة ما. (3) لا وقت للتعلم والتعديل. (4) المستخدمون يُصدمون بتغييرات كثيرة مرة واحدة. الإطلاق التدريجي (Feature Flags): يُطلق لـ 5% من المستخدمين أولًا ← مراقبة ← توسيع تدريجي. إذا ظهر خطأ: تراجع فوري بدون أثر واسع.

معدل التحويل = (عدد الذين أتمّوا الهدف ÷ عدد الزوار) × 100. التفسير بحسب السياق: 2% في متجر إلكتروني = مقبول (المتوسط العالمي 1-3%). 2% في صفحة تسجيل مجاني = ضعيف جدًا (المتوقع 20-40%). مؤشر لا يُقرأ بمعزل — يُقارن بالمنافسين وبالنسخ السابقة للموقع نفسه.

Backlog: قائمة كل الميزات والتحسينات والإصلاحات المنتظرة مرتبة حسب الأولوية. طرق تحديد الأولوية: (1) RICE Score: مدى الوصول × الأثر × الثقة ÷ الجهد. (2) MoSCoW: Must have / Should have / Could have / Won’t have. (3) تأثير على مقياس KPI محدد. (4) توافق مع الاستراتيجية. المبدأ: ليس ما تُريده بل ما يُنتج أعلى قيمة بأقل جهد.