تُعرض عليك عشرون شاشة على Figma، وتبدو كلها جميلة، والسؤال الذي لا تعرف كيف تطرحه: هل هذه الشاشات صحيحة؟ مبادئ تصميم UX/UI هي المفردات التي تجيب عنه: قواعد منشورة منذ التسعينيات، بعضها له ورقة بحثية محكّمة، وكلها تتحول إلى اعتراض محدد قابل للتنفيذ. «هذا الزر لا يخبرني بما حدث بعد الضغط» جملة يعمل بها المصمم؛ «مش عاجبني» ليست كذلك.
يجمع هذا الدليل ثلاث طبقات: القواعد العشر للاستخدامية التي وضعها ياكوب نيلسن، وأربعة قوانين لها أساس تجريبي مع حدودها التي تُهمَل عادةً، ثم قرارات الواجهات العربية التي تُقرأ من اليمين إلى اليسار، وهي الطبقة التي تسقط من كل مرجع إنجليزي لأنها ببساطة ليست مشكلته.
UX وUI: أين يقع الفرق في مشروعك فعلًا
تجربة المستخدم (UX) تجيب عن سؤال: ما الخطوات التي يمر بها شخص ليصل إلى ما جاء من أجله، وكم تكلّفه من انتباه ووقت؟ وواجهة المستخدم (UI) تجيب عن السؤال التالي: كيف تبدو كل خطوة على الشاشة؟ الفرق يظهر في نوع العطل الذي تراه بعد الإطلاق. عطل UX: عملاء يصلون إلى صفحة الدفع ثم يتصلون ليسألوا عن الشحن، لأن كلفته لم تظهر إلا بعد إدخال العنوان. وعطل UI: زر في مكانه الصحيح لكن لونه على خلفيته لا يُقرأ تحت الشمس على شاشة هاتف.
القاعدة العملية: قرارات UX تُحسم في النماذج قبل أن يكتب أحد سطر كود، وتصحيحها بعد البرمجة يعني تعديل قاعدة البيانات وواجهات الربط لا تغيير لون. وكلفة تعديل قرارات UI أقل، ما دام هناك نظام تصميم موحّد يجعل التغيير في مكان واحد. وإن كنت في طور اختيار من ينفّذ هذه المرحلة، فأسئلة التعاقد في كيف تختار شركة تصميم UX/UI، وبنود السعر في دليل تكلفة تصميم UX/UI.
القواعد العشر للاستخدامية: مصدرها وكيف تُستخدم
نشر ياكوب نيلسن قائمته في 24 أبريل 1994، وآخر مراجعة للصفحة في 30 يناير 2024. أصلها أقدم: وضعها مع رولف مولِش سنة 1990، ثم نقّحها اعتمادًا على تحليل عاملي لـ249 مشكلة استخدامية ليصل إلى مجموعة بأكبر قدرة تفسيرية. وهو يسمّيها heuristics لأنها «قواعد عامة تقريبية لا إرشادات محدّدة»: أسئلة تُطرح على الشاشة لا مواصفات تُنفَّذ حرفيًا. وهي هنا في أربع مجموعات حسب السؤال الذي تجيب عنه، لأن حفظها كقائمة من عشرة بنود لا يفيد وقت المراجعة.
هل يعرف المستخدم ما الذي يحدث؟
1. وضوح حالة النظام. تُعرِّف الواجهة المستخدمَ بما يجري، بتغذية راجعة مناسبة وفي وقت معقول. تطبيق InstaPay مثال مباشر: صفحة أسئلته الشائعة تنص على ثلاث حالات للمعاملة: ناجحة، ومرفوضة ويُرد المبلغ إلى حساب المرسل، ومعلّقة أي أُرسلت إلى بنك المستفيد وستُحدَّث لاحقًا. الحالة الثالثة هي التي تُنسى في أغلب الأنظمة المحلية: يُصمَّم مسارا النجاح والفشل، وتُترك «قيد التنفيذ» بلا شاشة، فيتحول الفراغ إلى مكالمة على خدمة العملاء.
9. مساعدة المستخدم على فهم الخطأ والتعافي منه. رسالة الخطأ تُكتب بلغة بشرية وتصف المشكلة وتقترح حلًا. وإرشادات NN/g لرسائل الخطأ تضيف ثلاثًا يسهل تجاهلها: تُعرض الرسالة قرب مصدر الخطأ لا في أعلى الصفحة، ولا تُعرض قبل أوانها، فإظهار خطأ بمجرد خروج المؤشر من حقل فارغ يعامل الاستكشاف كأنه ذنب، ولا تلوم المستخدم بكلمات مثل «غير صالح» أو «خاطئ».
هل تتكلم الواجهة لغة المستخدم؟
2. المطابقة بين النظام والعالم الواقعي. استخدم كلمات المستخدم لا مصطلحاتك الداخلية. أوضح تطبيق محلي: حقول العنوان. نموذج «العنوان سطر 1 / سطر 2 / الرمز البريدي» مترجم عن نماذج أمريكية، بينما العنوان الوطني السعودي له مكوّنات معلنة: رقم مبنى من أربعة أرقام، وشارع، ورقم إضافي من أربعة أرقام، وحي، ورمز بريدي من خمسة أرقام، ومدينة، إضافة إلى العنوان المختصر من أربعة أحرف وأربعة أرقام. الحقول التي تطابق ما يقرأه العميل في تطبيق حكومي تُملأ صحيحة من أول مرة.
4. الاتساق واتّباع المعايير. نيلسن يفرّق هنا بين اتساق داخلي (الزر نفسه يعني الشيء نفسه في كل شاشة عندك) واتساق خارجي مع أعراف الصناعة. والاتساق الداخلي مسألة بنية لا انضباط: يُضبط مرة واحدة في طبقة المكوّنات، ويشرحه دليل الأنظمة التصميمية بتفصيل.
10. المساعدة والتوثيق. الأفضل ألا يحتاج النظام شرحًا، وحين يحتاجه فليكن في سياق المهمة بخطوات محددة، لا صفحة «أسئلة شائعة» يُحال إليها الجميع.
هل يستطيع أن يرجع؟
3. تحكّم المستخدم وحريته. الناس يضغطون بالخطأ، فيحتاجون «مخرج طوارئ» واضحًا: تراجع، وإلغاء مرئي، وخروج معنون.
5. منع الخطأ. أفضل رسالة خطأ هي التي لا تظهر. وهنا تفرقة مفيدة من نص القواعد: الزلّات (slips) أخطاء غير واعية سببها السهو، وتُعالَج بقيود وقيم افتراضية جيدة؛ والأخطاء (mistakes) واعية وسببها اختلاف النموذج الذهني للمستخدم عن التصميم، وتُعالَج بتقليل عبء التذكّر وبالتأكيد قبل التنفيذ. مثال رقمي: حدود التحويل المعلنة في InstaPay حتى سبتمبر 2026 هي 70,000 جنيه للمعاملة الواحدة و120,000 جنيه يوميًا لكل بنك. عرض هذا الحد قبل أن يكتب المستخدم المبلغ منعٌ للخطأ؛ وعرضه بعد الضغط على «تحويل» رسالة خطأ.
ما مقدار ما تحمّله لذاكرته؟
6. التعرّف بدل التذكّر. اجعل الخيارات مرئية بدل أن يستدعيها المستخدم من ذاكرته. تطبيق نفاذ السعودي مثال واضح: دليل المستخدم الصادر عن سدايا يعرض في صفحته الثامنة شاشة «رقم الطلب» بثلاثة أرقام من خانتين، والتعليمة: اختر الرقم الظاهر لدى مزود الخدمة. لا نقل رمز من رسالة إلى حقل، بل تعرّف على رقم تراه أمامك. تفاصيل هذا المسار وبدائله في التحقق من هوية المستخدم في التطبيقات السعودية.
7. المرونة وكفاءة الاستخدام. اختصارات مخفية عن المبتدئ تسرّع الخبير: بحث بالكود لموظف المخزن، وإعادة طلب سابق بضغطة للعميل المتكرر.
8. تصميم جمالي مقتصد. كل معلومة زائدة على الشاشة تنافس المعلومة المهمة وتقلّل ظهورها النسبي. المطلوب ترتيب أولويات بصرية تخدم هدف المستخدم، لا واجهة فارغة.
أربعة قوانين لها ورقة بحثية، ولها حدود
تتداول المقالات هذه القوانين كشعارات. الأنفع أن تعرف ما قاسته التجربة الأصلية، لأن حدودها هي ما يمنعك من تطبيقها في غير موضعها.
قانون فيتس (1954): الحجم والمسافة
نشر بول فيتس ورقته في Journal of Experimental Psychology سنة 1954، وخلاصتها أن زمن الوصول بمؤشر إلى هدف يعتمد على حجمه والمسافة إليه، وأن العلاقة لوغاريتمية لا خطية. شرح NN/g للقانون يضيف تفصيلتين عمليتين: معدل الخطأ ينخفض كلما كبر الهدف، والأيقونة المصحوبة بنص هدف أكبر من الأيقونة وحدها، بشرط أن تكون المساحة كلها قابلة للنقر. والقرار المترتب: ضع زر الإرسال بجوار آخر حقل في النموذج، لا في أعلى الشاشة.
أما الحد: القاعدة الشائعة بأن حواف الشاشة «أهداف لا نهائية» صحيحة مع الفأرة، لأن المؤشر يتوقف عند الحافة فلا حاجة إلى التباطؤ. وعلى شاشات اللمس وجدت دراسة Avrahami في مؤتمر CHI سنة 2015 العكس: الأهداف عند الحواف تستغرق وقتًا أطول، فشريط أدوات ملتصق بحافة شاشة هاتف بحجة قانون فيتس تطبيق له في غير سياقه.
قانون هِك (1952): عدد الخيارات
فريق سنابل يوفر لك دراسة فنية مخصصة لتحديد التقنيات المناسبة وتكلفة التنفيذ الدقيقة.
نشر و. إ. هِك ورقته «On the rate of gain of information» في Quarterly Journal of Experimental Psychology سنة 1952، وتابعه راي هايمَن سنة 1953. الصيغة المتداولة، كما تنقلها مراجعة بروكتور وشنايدر في المجلة نفسها سنة 2018، هي RT = a + b log2 n لعدد بدائل متساوية الاحتمال.
انظر إلى التجربة قبل أن تعمّم: عشرة مصابيح في دائرة غير منتظمة، وعشرة أصابع على مفاتيح استجابة. هذا ليس مستخدمًا يمسح قائمة بعينه. والمراجعة نفسها تنقل أن لونجستريث خلص سنة 1988 إلى أن القانون لا ينطبق بعد نحو ثمانية بدائل، وأن سايبل حصر العلاقة الخطية سنة 1963 بين بديلين وثمانية.
الاستخدام الصحيح: في شاشة قرار واحدة (نوع الحساب، طريقة الدفع، الباقة) كل خيار إضافي يؤخر القرار، فاحذف ما لا يختاره أحد. والخاطئ: تقصير قائمة تصنيفات متجر لأن «هِك قال»، والقائمة تُمسح بالعين ولا تُقارَن خياراتها واحدًا واحدًا.
قانون ياكوب (2000): توقعات مبنية في مكان آخر
صاغه نيلسن في مقال «End of Web Design» في 22 يوليو 2000، ونصّه: «المستخدمون يقضون معظم وقتهم على مواقع أخرى. هذا يعني أنهم يفضّلون أن يعمل موقعك بالطريقة نفسها التي تعمل بها كل المواقع التي يعرفونها».
عمليًا في مصر والخليج: توقعات عميلك بُنيت في تطبيق بنكه وتطبيق التوصيل وتطبيق الحكومة. سلة الشراء أيقونة سلة، والرجوع سهم، وحساب المستخدم في الركن. الابتكار في هذه العناصر يكلّفك تعلّمًا لن يدفع أحد ثمنه؛ ابتكر في ما يميّز منتجك، والتزم العرف في البقية.
قانون ميلر (1956): الكتل لا السبعة
ورقة جورج ميلر «العدد السحري سبعة، زائد أو ناقص اثنين» نُشرت في Psychological Review سنة 1956. ما تقوله فعلًا: سعة الذاكرة الفورية عدد ثابت من «الكتل» (chunks)، وإعادة الترميز، أي تجميع المدخلات في وحدات أكبر، تزيد ما تحمله الكتلة الواحدة. وميلر ختم ورقته بأن تكرار الرقم سبعة في مجالات مختلفة قد يكون «مصادفة فيثاغورية خبيثة». ونيلسن حسم سوء الاستخدام الأشهر في مقال عن الذاكرة قصيرة المدى: الاعتقاد بأن حدود الذاكرة تفرض قوائم من سبعة عناصر «خطأ شائع»، لأن القائمة تقوم على التعرّف لا على التذكّر.
فالقرار المستخلص من ميلر يخص تقطيع الأرقام الطويلة لا طول القوائم: رقم الحساب والبطاقة والهاتف تُعرض وتُدخَل في مجموعات. ومثله عنوان الدفع الفوري في InstaPay بصيغة name@InstaPay بدل مشاركة رقم حساب كامل؛ استبدال كتلة يصعب حملها بأخرى تُحفظ.
التصميم من اليمين إلى اليسار: القرارات التي تغيب عن المراجع الإنجليزية
عكس الواجهة (mirroring) ليس زر «RTL» في أداة التصميم. توثيق Material Design للاتجاهين وإرشادات Apple للاتجاه من اليمين إلى اليسار يتفقان على أن الأصل هو العكس، والاستثناءات هي ما يفرّق بين واجهة عربية سليمة وأخرى مقلوبة حرفيًا.
ما يُعكس وما لا يُعكس
| العنصر | في الواجهة العربية | السبب المعلن في التوثيق |
|---|---|---|
| زر الرجوع | يشير إلى اليمين | تسلسل الشاشات يتبع اتجاه القراءة |
| الزر الأساسي والثانوي | يتبادلان موضعيهما | ترتيب الأزرار يتبع اتجاه القراءة |
| مربع الاختيار | يمين النص | مكان الأيقونة داخل الحقل ينعكس كذلك |
| شريط التقدّم | يمتلئ من اليمين | التقدّم يُرى في اتجاه القراءة |
| الخط الزمني وتسلسل الصور المرتّب | من اليمين إلى اليسار | مرور الزمن يتبع اتجاه القراءة |
| أزرار تشغيل الوسائط وشريطها | لا تُعكس | تشير إلى اتجاه الشريط نفسه لا إلى اتجاه الزمن |
| الساعة وأيقونتا التحديث والسجل | لا تُعكس | الاتجاه الدائري للزمن لا ينعكس |
| أيقونة البحث | لا تُعكس | مقبضها يعكس استخدام اليد اليمنى، وأغلب المستخدمين يمينيّون |
| الرسوم البيانية | لا تُعكس | نصّ Material يستثنيها صراحة |
| الشعارات وعلامة الصح والصور الفوتوغرافية | لا تُقلب | علامات كونية، والقلب يغيّر المعنى وله تبعات قانونية |
اتجاه التقدّم في النماذج والخطوات
الخطأ الأكثر تكلفة هنا أن يُعكس التخطيط وتبقى مؤشرات التقدّم بمنطق اليسار: مؤشر خطوات يبدأ من اليسار في شاشة تُقرأ من اليمين، فيظن المستخدم أنه في الخطوة الأخيرة وهو في الأولى. القاعدة: كل ما يمثّل مرور الوقت أو تقدّمًا نحو الإنجاز يبدأ من اليمين. وينسحب هذا على التبويبات، إذ يسحب المستخدم في الشاشة العربية يمينًا ليصل إلى التالي منها.
وتفصيلة من إرشادات Apple تنفع في النماذج: الأرقام التي تدل على تقدّم أو عدّ يُعكس ترتيبها لتطابق العنصر المعكوس، أما خانات الرقم الواحد فلا تُعكس أبدًا، فرقم الهاتف ورقم البطاقة يُقرآن بالترتيب نفسه في كل اللغات.
الأرقام والتواريخ داخل نص عربي
الرقم في النص العربي يُكتب من اليسار إلى اليمين حتى داخل سطر يُقرأ من اليمين، وهذا سلوك طبيعي لا عطل. الذي يُنتج عطلًا هو خلط أشكال الأرقام داخل الصفحة الواحدة، وما يتبعه من ترتيب غير متوقع حول العملات والنسب والتواريخ، وتفاصيله بأمثلتها في دليل إمكانية الوصول للمواقع العربية.
القرار المطلوب منك: اختر شكلًا واحدًا للأرقام والتزم به في الواجهة كلها، وثبّت صيغة التاريخ والعملة في نظام التصميم لا في كل شاشة. والنص غير المترجم (الروابط وأكواد المنتجات وأسماء الملفات) يبقى بترتيبه اللاتيني داخل الفقرة العربية، كما ينص توثيق Material.
الخط العربي بجوار نص لاتيني
تلاحظ أن الكلمة العربية تبدو أصغر إلى جوار كلمة إنجليزية بحروف كبيرة في زر أو عنوان، لأن العربية لا تحتوي حروفًا كبيرة أصلًا. وتوصي إرشادات Apple بزيادة حجم الخط العربي بنحو نقطتين لتحقيق التوازن البصري، وهي حالة يفشل فيها استخدام الحجم نفسه للّغتين.
إمكانية الوصول مبدأ لا إضافة
إمكانية الوصول ليست بندًا يُضاف في نهاية المشروع، لأن ثلاثة من قراراتها تُتخذ في أول أسبوع من التصميم:
- التباين. معيار WCAG 2.2 يطلب نسبة لا تقل عن 4.5:1 لنص المتن و3:1 للنص الكبير. والرقم ليس اعتباطيًا: وثيقة W3C تشرح أن حدة إبصار 20/40 ترافقها خسارة في حساسية التباين بنحو 1.5، فيصير 3 × 1.5 = 4.5:1. يُحسم هذا في لوحة الألوان قبل رسم أي شاشة.
- حجم أهداف اللمس. WCAG 2.2 يضع حدًا أدنى 24×24 بكسل CSS، بينما توثيق Material يوصي بـ48×48dp (نحو 9 مم فعليًا)، وعلى iOS التوصية 44×44 نقطة. لا تعارض بينهما: الأول حدّ مطابقة، والثاني توصية تصميم مريح. صمّم على توصية المنصة.
- التنقل بلوحة المفاتيح. كل وظيفة يجب أن تعمل بلوحة المفاتيح. لوحة تحكم إدارية تُستخدم ثماني ساعات يوميًا تكسب من هذا أكثر من أي تحسين بصري.
أخطاء تكلّف مالًا، والرقم الذي يكشف كل منها
الإحصاءات الجاهزة عن «نسبة التخلي عن السلة» لا تخبرك شيئًا عن منتجك. الأنفع أن تعرف أين يظهر كل خطأ في بياناتك أنت.
| الخطأ | أين يظهر في بياناتك | التعديل |
|---|---|---|
| الشحن أو الرسوم تظهر متأخرة | السقوط بين شاشة العنوان وشاشة الدفع | اعرض التكلفة أو نطاقها في صفحة المنتج |
| حقول لا تحتاجها الآن | معدل الخطأ لكل حقل وزمن إكمال النموذج | أجّل كل حقل لا يمنع إتمام الطلب |
| رسائل خطأ لا تقول ما العمل | تذاكر الدعم لكل 1000 طلب، ومكالمات «مش عارف أكمل» | أعِد كتابة أكثر خمس رسائل تكرارًا، واحفظ الإدخال |
| غياب شاشة لحالة «قيد التنفيذ» | تكرار محاولات الدفع للطلب الواحد | أضف حالة انتظار برسالة وزمن متوقع |
| هدف لمس صغير أو مزدحم | نقرات مرتدة على الأزرار المتجاورة | كبّر الهدف وأضف تباعدًا لا يقل عن 8dp |
| اتجاه تقدّم مقلوب في شاشة عربية | سقوط في أول خطوة من مسار متعدد | اعكس مؤشر الخطوات والتبويبات مع التخطيط |
كل سطر هنا مقياس تستخرجه من لوحة تحكمك خلال يوم بلا بحث سوقي. وإذا كانت الأرقام على صفحة هبوط بعينها فطريقة قياسها في تصميم صفحة الهبوط، أما التقنيات الموجّهة لرفع التحويل ففي تحسين معدل التحويل في المتجر الإلكتروني.
كيف تراجع شاشة قبل أن توافق عليها
راجعها بالقواعد لا بالذوق. أمام كل شاشة رئيسية اسأل ستة أسئلة:
- لو ضغطت هنا، هل ستخبرني الشاشة بما حدث؟ وأين حالة الانتظار؟
- هل الكلمات هي كلمات عميلي أم كلماتنا الداخلية؟
- أين زر التراجع أو الإلغاء في هذه الشاشة؟
- ما الذي أُطالَب بحفظه في رأسي من شاشة سابقة؟
- لو كنت في الشمس بيد واحدة، هل أصل إلى الزر الأساسي؟
- ما الذي ينكسر إذا قُرئت هذه الشاشة من اليمين: الأسهم، مؤشر الخطوات، ترتيب الأزرار، مكان الأيقونة في الحقل؟
ثلاثة يراجعون الشاشات نفسها منفردين ثم يقارنون ملاحظاتهم يجدون أضعاف ما يجده واحد، وهذا أصل التقييم الاسترشادي الذي وُضعت القواعد من أجله سنة 1990. وحين تحتاج أن تعرف لغة عملائك بدل أن تفترضها، فالطرق المنهجية في أبحاث المستخدم.
القواعد أعلاه لا تصنع منتجًا ناجحًا وحدها، لكنها تمنع أغلب ما يُصلَح لاحقًا بتكلفة أعلى. إذا كنت تخطط لتصميم تطبيق أو موقع أو لوحة تحكم بالعربية، اعرض فكرتك على فريق سنابل: يصلك خلال 24 ساعة تصوّر مبدئي للنطاق وتقدير للوقت والتكلفة، بلا رسوم ولا التزام.
المصادر
- Nielsen Norman Group: القواعد العشر للاستخدامية (1994، روجعت 2024)، وقانون فيتس (2022)، وEnd of Web Design (2000)، والذاكرة قصيرة المدى (2009)، وإرشادات رسائل الخطأ.
- مراجعة قانون هِك لزمن رد الفعل الاختياري، Proctor & Schneider، Quarterly Journal of Experimental Psychology، 2018.
- The Magical Number Seven, Plus or Minus Two، George A. Miller، Psychological Review، 1956.
- Material Design: Bidirectionality وAccessibility.
- Right to left، Apple Human Interface Guidelines.
- Understanding SC 1.4.3 Contrast (Minimum)، W3C WAI.
- الأسئلة الشائعة، InstaPay؛ دليل مستخدم نفاذ، سدايا؛ العنوان الوطني، البريد السعودي.
