يا جماعة الخير، السلام عليكم ورحمة الله. معكم أخوكم أبو عمر.
خلوني أحكي لكم قصة صارت معي ومع فريقي قبل كم سنة. كنا شغالين على تطبيق جديد، تطبيق “ذكاء اصطناعي” فكرته كانت عبقرية على الورق. سهرنا الليالي، كتبنا آلاف الأسطر من الكود، وبنينا خوارزميات معقدة… يعني شغل متعوب عليه، شغل “مرتب” زي ما بنحكي. وفي يوم الإطلاق، كنا كلنا فخورين بأنفسنا، متوقعين إنه الناس راح تنبهر باللي عملناه.
لكن اللي صار كان العكس تماماً. بعد كم يوم، بلشت توصلنا رسائل الدعم الفني زي المطر. “مش عارف ألاقي زر الإعدادات”، “كيف أسجل خروج؟”، “البرنامج معلّق ومش راضي يعمل إشي!”. والمصيبة الأكبر كانت في تقييمات المتجر: نجمة واحدة، نجمتين… والتعليق المتكرر: “فكرة حلوة بس التطبيق صعب ومستحيل استخدامه”.
في البداية، كنا بنكابر. “المستخدم مش فاهم”، “الناس بدها كل إشي جاهز”، “هذول ما بعرفوا في التكنولوجيا”. لكن لما قعدت مع حالي بآخر الليل، وأنا بقرأ التعليقات المحبطة، عرفت إنه المشكلة مش فيهم. المشكلة فينا. إحنا صممنا واجهة لأنفسنا، للمبرمجين اللي عارفين كل زاوية في التطبيق، بس نسينا أهم إشي: المستخدم العادي اللي أول مرة بشوف شغلنا. كان المستخدم حرفياً “يُقاتل” الواجهة عشان يعمل أبسط المهام. وقتها أدركت إننا في “جحيم التصميم غير البديهي”، وكان لازم نلاقي مخرج.
وهون بدأت رحلتنا مع ما يسمى بـ “قوانين تجربة المستخدم”.
ما هي قوانين تجربة المستخدم (UX Laws)؟ وليش هي مهمة؟
ببساطة يا جماعة، قوانين تجربة المستخدم مش قوانين بالمعنى الحرفي اللي بتتنفذ في المحاكم. هي عبارة عن مبادئ وملاحظات مستخلصة من علم النفس والإدراك البشري، بتساعدنا نصمم واجهات أفضل وأسهل للاستخدام. هي زي “قوانين الفيزياء” لعالم التصميم؛ بتقدر تتجاهلها، بس النتائج راح تكون كارثية.
الفكرة كلها مبنية على إنه البشر عندهم طرق معينة في التفكير ومعالجة المعلومات. لما نفهم هاي الطرق، بنقدر نصمم منتجات “بتحكي لغتهم”، منتجات بديهية وسهلة، مش العكس. الشطارة مش إنك تعمل تصميم “فني” أو “مبدع” على حساب سهولة الاستخدام. الشطارة إنك تخلي المستخدم ينجز مهمته بأقل مجهود ذهني ممكن.
أهم قوانين تجربة المستخدم اللي أنقذت مشروعنا (مع أمثلة عملية)
بعد ما “أكلنا الكف” الأول، قررنا نرجع خطوة لورا ونعيد تقييم كل شبر في تطبيقنا على ضوء هاي المبادئ. خلوني أشارككم أهم القوانين اللي كان إلها أثر السحر على مشروعنا.
1. قانون جايكوب (Jakob’s Law): “المستخدمون يتوقعون أن يعمل موقعك مثل كل المواقع الأخرى”
هذا القانون بقول إن المستخدمين بقضوا معظم وقتهم على مواقع وتطبيقات ثانية غير تطبيقك. وبالتالي، هم بنوا “نموذج عقلي” لكيفية عمل الأشياء. بيتوقعوا إنه قائمة التنقل تكون فوق، وسلة المشتريات تكون في الزاوية اليمنى العلوية، وشعار الموقع يرجعك للصفحة الرئيسية. لما إنت تيجي وتتفلسف وتحط القائمة تحت على الشمال، بتجبر المستخدم يتعلم إشي جديد، وهذا إشي هو بكرهه.
في مشروعنا: كنا حاطين أيقونة الإعدادات على شكل “ترس” (Gear) لكن بتصميم فني غريب ومختلف، ومخبيينها جوا قائمة فرعية. المستخدمين ما كانوا يلاقوها أبداً.
الحل: بكل بساطة، استخدمنا أيقونة الترس المتعارف عليها عالمياً، وحطيناها في مكان واضح ومتوقع في صفحة البروفايل. خلال يوم واحد، اختفت 90% من تذاكر الدعم اللي بتسأل عن الإعدادات.
نصيحة من أبو عمر: ما تخترع العجلة يا خوي! الابتكار مطلوب، لكن في الوظائف الأساسية، خليك مع المألوف. التقليد في هاي الحالة مش عيب، بل هو احترام لعادات المستخدم.
2. قانون فيتس (Fitts’s Law): “الأهداف الكبيرة والقريبة أسهل في الوصول إليها”
هذا القانون بسيط ومنطقي جداً: كل ما كان الزر أكبر وأقرب لإصبع المستخدم، كل ما كان الضغط عليه أسهل وأسرع. تخيل حالك بتحاول تضغط على زر صغير جداً في زاوية الشاشة بإصبعك الإبهام، الموضوع صعب ومستفز، صح؟
في مشروعنا: كان زر “إضافة إلى السلة” صغير وباهت اللون، وجنبه زر “إلغاء” كبير ولونه جذاب. النتيجة؟ الناس كانت بتضغط “إلغاء” بالغلط أكثر مما بتضغط “إضافة”.
الحل: عملنا تعديل بسيط في الـ CSS. كبّرنا زر الإضافة، أعطيناه لون أساسي قوي (Primary Color)، وصغّرنا زر الإلغاء وخلينا خلفيته شفافة (Ghost Button).
/* CSS قبل التعديل */ .btn-add { padding: 8px 12px; background-color: #ccc; } .btn-cancel { padding: 8px 12px; background-color: #ff4d4d; /* لون أحمر جذاب! كارثة */ } /* CSS بعد التعديل بناءً على قانون فيتس */ .btn-primary { /* زر الإضافة */ padding: 15px 30px; /* أكبر */ font-size: 1.1rem; background-color: #007bff; /* لون أساسي واضح */ color: white; border: none; cursor: pointer; } .btn-secondary { /* زر الإلغاء */ padding: 14px 28px; background-color: transparent; color: #6c757d; border: 1px solid #6c757d; }نصيحة من أبو عمر: فكر دايماً بـ “منطقة الإبهام” (Thumb Zone) على شاشة الموبايل. أهم الأزرار لازم تكون في المنطقة اللي بوصلها الإبهام بسهولة بدون ما المستخدم يمد إصبعه أو يغير مسكة الجوال.
3. قانون هيك (Hick’s Law): “كلما زادت الخيارات، زاد وقت اتخاذ القرار”
لما تعطي المستخدم خيارات كثيرة مرة واحدة، بصير عنده إشي اسمه “شلل التحليل” (Analysis Paralysis). بتلاقيه صفن في الشاشة، مش عارف شو يختار، وفي النهاية ممكن يترك التطبيق كله ويهرب. كثرة الخيارات مش دايماً إشي منيح.
في مشروعنا: صفحة التسجيل كانت كابوس. كنا طالبين 15 معلومة من المستخدم في شاشة واحدة: الاسم الأول، اسم العائلة، الإيميل، تأكيد الإيميل، كلمة السر، تأكيد كلمة السر، تاريخ الميلاد، الدولة، المدينة… إلخ. نسبة اللي كانوا بكملوا التسجيل كانت متدنية جداً.
الحل: طبقنا مبدأ “التأهيل التدريجي” (Progressive Onboarding). قسمنا عملية التسجيل لـ 3 خطوات بسيطة. الخطوة الأولى: إيميل وكلمة سر فقط. الخطوة الثانية (بعد التسجيل): “أخبرنا عن اسمك”. الخطوة الثالثة (عند أول استخدام لميزة معينة): “نحتاج لموقعك لنعرض لك نتائج أفضل”. بهذه الطريقة، المستخدم ما بحس بالضغط، وبنعطيه قيمة قبل ما نطلب منه معلومات كثيرة.
نصيحة من أبو عمر: “شوي شوي يا حبيبي”. لا ترمي كل حملك على المستخدم من أول لحظة. ابدأ بالأهم، واطلب المعلومات الإضافية في سياقها المناسب. إذا كان عندك قائمة طويلة من الإعدادات، اجمعها في مجموعات منطقية واخفِ الخيارات المتقدمة تحت زر “إعدادات متقدمة”.
4. قانون ميلر (Miller’s Law): “العقل البشري يتذكر حوالي 7 عناصر”
هذا القانون بقول إن ذاكرتنا العاملة (القصيرة المدى) محدودة. بنقدر نتذكر حوالي 7 (زائد أو ناقص 2) عناصر في نفس الوقت. أي إشي أكثر من هيك بصير صعب تذكره ومعالجته.
في مشروعنا: قائمة التنقل الرئيسية في التطبيق كان فيها 11 عنصر! “الرئيسية”، “ملفي الشخصي”، “الرسائل”، “الإشعارات”، “الأصدقاء”، “البحث”، “المجموعات”… إلخ. كانت فوضى عارمة.
الحل: أعدنا تجميع العناصر. “الرسائل” و “الإشعارات” و “الأصدقاء” حطيناهم تحت أيقونة واحدة للبروفايل. العناصر الأقل استخداماً نقلناها لقائمة “المزيد”. النتيجة؟ قائمة رئيسية فيها 5 عناصر فقط، واضحة ومباشرة وسهلة التذكر.
مثال آخر على تطبيق هذا القانون هو “تقسيم المعلومات” (Chunking). بدل ما تعرض رقم هاتف هيك:
0599123456، اعرضه هيك:0599-123-456. صار أسهل للقراءة والمعالجة الذهنية، مع إنه نفس الرقم.نصيحة من أبو عمر: ساعد دماغ المستخدم، لا تتعبه. قسم المحتوى الطويل لفقرات صغيرة. قسم النماذج الطويلة لخطوات. قسم الأرقام الطويلة لمجموعات. التقطيع يريح العين والعقل.
كيف تبدأ بتطبيق هاي القوانين في مشروعك اليوم؟
يمكن بتحكي الآن: “كلامك حلو يا أبو عمر، بس من وين أبدأ؟”. الموضوع أبسط مما بتتخيل:
- راقب واستمع: أول خطوة هي تعرف وين المشكلة. استخدم أدوات مثل (Hotjar) عشان تشوف تسجيلات حقيقية للمستخدمين وهم بستعملوا تطبيقك. اقرأ رسائل الدعم بعناية. انظر إلى بيانات (Google Analytics) لترى أين يغادر المستخدمون موقعك. كن متواضعاً واستمع لشكوى المستخدم، فهي كنز من المعلومات.
- حدد الأولويات: لا تحاول تصلح كل شي مرة واحدة. ركز على المشاكل اللي بتسبب أكبر ألم للمستخدم. اسأل نفسك: “أي تغيير بسيط ممكن يعمل أكبر فرق؟”. غالباً ما يكون إصلاح تدفق تسجيل الدخول أو عملية الدفع هو الأهم.
- صمم حلاً بناءً على قانون: لما تلاقي مشكلة، حاول تربطها بأحد قوانين تجربة المستخدم. هل المستخدمون لا يجدون الزر؟ (قانون فيتس). هل يتخلون عن النموذج؟ (قانون هيك). هل يضيعون في القوائم؟ (قانون ميلر وجايكوب). استخدام هذه القوانين يمنحك أساساً علمياً لقرارك التصميمي.
- اختبر وكرر: بعد تطبيق التغيير، راقب النتائج. هل انخفض عدد تذاكر الدعم؟ هل زادت نسبة التحويل؟ التصميم ليس عملية من مرة واحدة، بل هو دورة مستمرة من البناء والقياس والتعلم.
الخلاصة: من مبرمج إلى صانع تجارب
يا جماعة، التحول اللي صار في مشروعنا ما كان مجرد تغيير في الأزرار والألوان. كان تحول في العقلية. انتقلنا من التفكير كـ “مبرمجين” همهم الوحيد هو كتابة كود يعمل، إلى التفكير كـ “صانعي تجارب” همهم الأول هو راحة المستخدم وسعادته.
تطبيق قوانين تجربة المستخدم لا يتطلب منك أن تكون مصممًا محترفًا حاصلًا على شهادات. يتطلب منك شيئًا واحدًا فقط: التعاطف. أن تضع نفسك مكان المستخدم، وتشعر بإحباطه، وتفكر في كيفية جعل حياته أسهل ولو بقليل.
شغلنا كمبرمجين ومطورين مش بس نكتب كود نظيف، شغلنا نحل مشاكل الناس. وتجربة المستخدم هي قلب هاي المعادلة. لما تبدأ تفكر بهذه الطريقة، صدقني، مش بس منتجك راح يصير أحسن، إنت نفسك راح تصير مطور أفضل. 😉
