05 أغسطس 2025·7 دقيقة
إرشادات قابلية الاستخدام لنيلسن: قالب مراجعة سريعة
استخدم إرشادات قابلية الاستخدام لنيلسن لإجراء مراجعة UX سريعة قبل كل إصدار، اكتشاف المشاكل الواضحة مبكرًا، والحفاظ على سهولة استخدام تطبيقات الويب والموبايل.
استخدم إرشادات قابلية الاستخدام لنيلسن لإجراء مراجعة UX سريعة قبل كل إصدار، اكتشاف المشاكل الواضحة مبكرًا، والحفاظ على سهولة استخدام تطبيقات الويب والموبايل.
معظم مشكلات واجهة المستخدم في يوم الإطلاق ليست تغييرات تصميم ضخمة. إنها تفاصيل صغيرة سهلة التغاضي تظهر فقط عندما يحاول شخص ما إتمام مهمة حقيقية تحت ضغط الوقت. والنتيجة متوقعة: المزيد من تذاكر الدعم، وزيادة الفِرار، والمزيد من "الإصلاحات السريعة" المتراكمة.
تفوت الفرق هذه المشكلات قبل الإصدار لأن المنتج منطقي بالفعل بالنسبة للأشخاص الذين يبنونه. الجميع يعرف ما يجب أن يفعله الزر، ماذا تعني التسمية، وما هي الخطوة التالية. المستخدمون الجدد لا يملكون ذلك السياق.
عند السرعة، تستمر نفس أنواع مشكلات الويب والموبايل في الظهور: شاشات بلا خطوة واضحة تالية، ملاحظات مفقودة (هل تم الحفظ، الإرسال، أم الفشل؟)، رسائل خطأ تلوم المستخدم دون إظهار مخرج، عناصر تبدو قابلة للنقر لكنها ليست كذلك، وصياغات تتغير عبر الشاشات (Sign in مقابل Log in) وتضعف الثقة بهدوء.
مراجعة قصيرة وقابلة للتكرار تتفوق على تدقيق طويل لمرة واحدة لأنها تدخل في إيقاع الشحن. إذا استطاع فريقك تشغيل نفس الفحوص في كل إصدار، تلتقط الأخطاء الشائعة بينما لا تزال رخيصة الإصلاح.
هنا تأتي فائدة إرشادات قابلية الاستخدام لنيلسن. إنها قواعد عملية لاكتشاف مشكلات UX الواضحة. ليست بديلاً عن اختبار المستخدم أو البحث أو التحليلات. فكّر بها كفحص سلامة سريع: لن تثبت أن التصميم ممتاز، لكنها غالبًا توضح سبب تعثر الناس.
ستجد قالب مراجعة قابلية استخدام بسيط يمكن إعادة استخدامه، مع أمثلة حديثة لتدفقات الويب والموبايل، حتى يتمكن فريقك من إصلاح أكثر أخطاء UX شيوعًا قبل أن يلاحظها المستخدمون.
يعقوب نيلسن هو باحث في قابلية الاستخدام روّج لفكرة عملية: معظم مشكلات UX ليست غامضة. تتكرر عبر المنتجات. عشر إرشاداته لقابلية الاستخدام هي قواعد عقلانية تصف ما يتوقعه الناس عند استخدام واجهة، مثل الحصول على رد واضح، البقاء في وضع التحكم، وعدم إجبارهم على تذكر الأشياء.
لا تزال مناسبة للتطبيقات الحديثة لأن أساسيات السلوك البشري لم تتغير. الناس يتصفحون بسرعة، يفوتون تفاصيل، يضغطون الخطأ، ويصابون بالذعر عند اعتقادهم أنهم فقدوا عملهم. سواء كانت لوحة تحكم ويب، عملية دفع على الموبايل، أو شاشة إعدادات، تظهر نفس المشكلات: حالة غير واضحة، تسميات مربكة، إجراءات مخفية، وسلوك غير متسق بين الشاشات.
يجب أن تفسّر الإرشادات لتناسب منتجات اليوم. على الموبايل، الشاشات الصغيرة تجعل التعرف بدل التذكر ومنع الأخطاء أكثر عن التخطيط، وصول الإبهام، ومدخلات متسامحة. في التدفقات متعددة الخطوات (التسجيل، الإعداد، المدفوعات)، تحكم المستخدم وحرّيته يعني إجراءات رجوع آمنة، حفظ التقدم، وعدم المفاجآت عندما يغير خطوة ما ما يحدث لاحقًا. في ميزات الذكاء الاصطناعي، رؤية حالة النظام ليست مجرد مؤشر تحميل. يحتاج المستخدمون لمعرفـة ما الذي يفعله النظام، وما الذي استخدمه، وماذا قد يكون خطأً عندما تبدو النتائج غريبة.
تمنح الإرشادات الفرق أيضًا لغة مشتركة. يمكن للمصممين الإشارة إلى "التناسق والمعايير" بدلًا من مناقشة الذوق. يمكن للمنتج ربط المشكلات بالنتائج مثل انخفاض التحويل وتذاكر الدعم. يمكن للهندسة تحويل استرداد الأخطاء إلى مهام ملموسة مثل تحقق أفضل، رسائل أوضح، وإعدادات افتراضية آمنة. عندما يستخدم الجميع نفس المصطلحات، يصبح الاتفاق على ما يُصلح أولًا أسهل.
هذه الأربعة الأولى تلتقط الكثير من الاحتكاك اليومي. يمكنك اختبارها خلال دقائق على الويب والموبايل، حتى قبل إجراء دراسة قابلية استخدام كاملة.
لا يجب أن يتساءل الناس أبدًا "هل نجح؟". أظهر ردود فعل واضحة للتحميل، الحفظ، والإنهاء.
اختبار بسيط: اضغط إجراءً أساسيًا (حفظ، دفع، إرسال) على اتصال بطيء. إذا بقيت الواجهة ثابتة لأكثر من ثانية، أضف إشارة. قد تكون مؤشر تحميل، نص تقدم، أو تعطيل مؤقت للحالة. ثم أكد النجاح برسالة تبقى مدة كافية للقراءة.
استخدم كلمات التي يستخدمها جمهورك، ورتب الأمور بحسب كيفية تفكير الناس.
مثال: تطبيق سفر يطلُب "Given name" و"Surname" سيُربك بعض المستخدمين. إذا كان جمهورك يتوقع "الاسم الأول" و"الاسم الأخير"، استعمل ذلك. في نماذج الموبايل، جَمّع الحقول حسب المهمة الحقيقية: تفاصيل المسافر أولًا، ثم الدفع، ثم التأكيد.
الناس يخطئون. أعطهم مخرجًا آمنًا.
على الموبايل، يظهر هذا عادة كغياب تراجع بعد إجراء مدمر (حذف، إزالة)، لا خيار إلغاء لمهام طويلة (تحميلات، تصدير)، فعل الرجوع الذي يفقد تقدم النموذج، أو حوارات/تدفقات بملء الشاشة بلا مخرج واضح.
إذا اضطر المستخدم لبدء العملية من جديد لإصلاح خطأ، ستتبع ذلك تذاكر دعم.
حافظ على أنماط متشابهة عبر الشاشات ووافق عادات المنصات. إذا استخدمت شاشة "تم" في مكان و"حفظ" في آخر، اختر واحدًا. إذا كانت السحب للحذف موجودة في القائمة، فلا تُخفي الحذف فقط خلف قائمة في مكان آخر.
على الويب، يجب أن تبدو الروابط كرابط. على الموبايل، الأفعال الأساسية في أماكن متوقعة. يقلل التناسق زمن التعلم ويمنع أخطاء يمكن تجنبها.
معظم "أخطاء المستخدم" في الواقع مشكلة تصميم. ابحث عن أماكن تسمح الواجهة فيها للأشخاص بارتكاب الخطأ بسهولة، خصوصًا على الموبايل حيث النقر غير دقيق.
الوقاية الجيدة عادة تعني الافتراضات المعقولة، قيود واضحة، وإجراءات آمنة. إذا احتاج نموذج رمز الدولة، اقترحه افتراضيًا استنادًا لإقليم الجهاز، وامنع القيم المستحيلة بدل قبولها والفشل لاحقًا. للأفعال الخطرة (حذف، إزالة وصول، نشر)، اجعل الخيار الأكثر أمانًا الأسهل.
تظهر هذه الثلاثة بسرعة كوجود تفكير إضافي وخطوات زائدة. تحث إرشادات نيلسن على إظهار الخيارات، دعم المسارات السريعة للاستخدام المتكرر، وإزالة الضوضاء.
مرور مراجعة سريع:
مثال ملموس: تخيل تدفق "إنشاء مشروع". إن اضطر المستخدم لتذكر اسم مساحة العمل من شاشة سابقة، فأنت تُجبره على الاسترجاع. إن عرضت مساحات العمل المستخدمة مؤخرًا وقمت بتحديد آخر واحد تلقائيًا، تحوّل المهمة إلى تعرف بدل تذكر. يشعر النموذج بسرعة أكبر دون إضافة ميزات جديدة.
المبدأ 9 (مساعدة المستخدمين على التعرف على الأخطاء وتشخيصها والتعافي منها) يتعلق بما يحدث بعد الخطأ. تفشل العديد من المنتجات هنا بعرض رسالة مخيفة أو رمز أو طريق مسدود.
رسالة الخطأ الجيدة تجيب عن ثلاثة أشياء بلغة بسيطة: ماذا حدث، لماذا حدث (إن عرفت)، وماذا يفعل المستخدم بعد ذلك. اجعل الإجراء التالي واضحًا. إذا فشل نموذج، ظلل الحقل المعني واحتفظ بما كتبه المستخدم. إذا فشل الدفع، اذكر إن كانت البطاقة مرفوضة أو الشبكة توقفت، واقترح إعادة محاولة آمنة. إن منعت إذنًا على الموبايل من ميزة، اشرح ما الذي يجب تفعيله وقدم طريقًا واضحًا للعودة للمهمة.
فحوصات سريعة للمبدأ 9:
المبدأ 10 (المساعدة والوثائق) ليس "ابنِ مركز مساعدة" بل "ضع المساعدة حيث يتعثر الناس". يعتبر التفعيل الأولي، حالات القوائم الفارغة، والحالات الحافة هي مكاسب كبيرة.
قائمة فارغة يجب أن تشرح ما الذي ينتمي إليها وكيف تضيف العنصر الأول. شاشة التشغيل الأولى تشرح مفهومًا أساسيًا واحدًا ثم تخرج من الطريق. يجب أن تعرض الحالات النادرة إرشادًا قصيرًا في اللحظة، لا مقالة طويلة.
طريقة عملية لمراجعة حالات الخطأ دون اختلاق فشل: امشِ المسار الرئيسي وسجل كل شرط يجب أن يفي به المستخدم (حقول مطلوبة، أذونات، حدود، اتصال). لكل نقطة، تأكد من وجود خطأ واضح، طريق تعافي، وتلميح صغير "تحتاج مساعدة؟" يطابق الشاشة.
عامل هذا كفحص ما قبل الرحلة، لا كمشروع بحثي. الهدف التقاط المشكلات الواضحة باستخدام إرشادات نيلسن بينما التغييرات لا تزال جديدة وسهلة الإصلاح.
ابدأ باختيار رحلة أو رحلتين حاسمتين تمثلان قيمة حقيقية. اختيارات جيدة: التسجيل، الإعداد لأول مرة، السداد، إنشاء شيء جديد، النشر، أو دعوة زميل. إن حاولت تغطية المنتج كله، ستفوت المشاكل الكبيرة.
بعدها، اتفق على مجموعة الأجهزة لهذا الإصدار. بالنسبة للعديد من الفرق، يعني ذلك سطح المكتب بالإضافة إلى الويب على الموبايل. إن كان لديك تطبيق أصلي، ضم جهاز iOS أو Android واحد على الأقل لتلاحظ سلوك لوحة المفاتيح، الأذونات، والتخطيط الحقيقي.
أجرِ المراجعة هكذا:
حافظ على الملاحظات سهلة التنفيذ. "مربك" يصعب إصلاحه؛ "تسمية الزر تقول حفظ لكنه ينشر" واضحة.
اختم بفرز لمدة 10 دقائق. فصل الإصلاحات السريعة (نسخ، تسميات، تباعد، افتراضات) عن البنود التي يجب إصلاحها قبل الإصدار (المهام المحجوزة، مخاطر فقدان البيانات، أخطاء غير واضحة).
تفشل مراجعات الإرشادات عندما تتحول إلى نقد شاشة بشاشة. تظهر العديد من مشكلات UX فقط عندما يحاول شخص إتمام مهمة حقيقية في ظل قيود حقيقية (شاشات صغيرة، انقطاعات، شبكة بطيئة).
إن نظرت إلى صفحات فردية فقط، تفوت تسليمات مكسورة: فلتر يعود إلى قيمة افتراضية بعد الشراء، توست "تم الحفظ" يظهر لكن لا شيء يُحفَظ، أو زر رجوع يعيدك للخطوة الخطأ.
تجنب ذلك بمراجعة مجموعة صغيرة من المهام الأساسية من البداية للنهاية. اجعل شخصًا يقود التدفق بينما يسجل آخر انتهاكات الإرشادات.
"الإرشاد يقول إنه سيء" ليس نتيجة مفيدة. ملاحظة مفيدة تربط المبدأ بما حدث على الشاشة.
نتيجة قوية تتضمن ثلاثة أجزاء: ما الذي حاول المستخدم فعله، ماذا رأى، وماذا يجب تغييره. مثال: "على الموبايل، النقر على تم يغلق لوحة المفاتيح لكنه لا يحفظ النموذج. أعد التسمية إلى إغلاق لوحة المفاتيح أو فعّل الحفظ التلقائي عند الإغلاق."
كلمات مثل "مربك" أو "غير سلس" لا تساعد أحدًا.
استبدل الملاحظات الغامضة بتغييرات محددة قابلة للاختبار. سمّ العنصر بدقة (تسمية زر، أيقونة، نص الخطأ، عنوان الخطوة). وصف عدم التطابق (التوقع مقابل ما يحدث). اقترح تغييرًا محددًا واحدًا (نسخة، موضع، افتراض، تحقق). أضف مرجعًا لصورة أو رقم خطوة ليكون سهل العثور عليه. اذكر التأثير (يحجب المهمة، يسبب أخطاء، يبطئ المستخدمين).
مراجعات سطح المكتب تفوّت مشاكل مثل تغطية لوحة المفاتيح للحقول، تعارضات الإيماءات، أهداف النقر الصغيرة، ومناطق القطع الآمنة.
كرر نفس تدفق المهمة على هاتف حقيقي. قم بالدوران مرة. جرّب الاستخدام بيد واحدة.
قد يبدو التدفق مثاليًا على اتصال سريع ويفشل في الحياة الواقعية.
تحقق دائمًا من شاشات النتائج الفارغة، حالات البداية الأولى، تحميل يستغرق أكثر من 5 ثوانٍ، وضع عدم الاتصال (إن كان ذا صلة)، وإعادة المحاولة بعد طلب فشل. غالبًا ما تكون هذه الفروقات بين "يعمل" و"موثوق".
انسخ هذا في ملاحظات الإصدار أو مستند ضمان الجودة وضع علامة على كل شاشة. إنه فحص سريع يلتقط مشكلات شائعة مرتبطة بإرشادات نيلسن، دون الحاجة إلى سباق بحث كامل.
اختر مسارًا أساسيًا واحدًا (التسجيل، السداد، إنشاء مشروع، دعوة زميل) وشغّل هذه الفحوص على الويب والموبايل.
حالة النظام واضحة دائمًا: حالات التحميل والحفظ مرئية، الأزرار لا تبدو قابلة للنقر أثناء الانشغال، وردود الفعل بالنجاح تبقى مدة كافية للملاحظة.
الإجراءات الخطرة قابلة للعكس: خطوات مدمرة أو مكلفة لها مسار إلغاء واضح، التراجع متاح عندما يكون منطقيًا، والرجوع يتصرف كما يتوقع المستخدم (خاصة في الحوارات والنماذج متعددة الخطوات).
الكلمات تطابق عالم المستخدم: التسميات بلغة يومية، لا مصطلحات داخلية. إن اضطررت لمصطلح فني، أضف تلميحًا قصيرًا في موضع القرار.
الأخطاء تخبر الناس ماذا يفعلون بعد ذلك: الرسائل تشرح الخطأ بلغة بسيطة وتعطي خطوة تالية (تعديل الحقل، المحاولة مجددًا، الاتصال بالدعم). تظهر الرسالة بالقرب من المشكلة، وليس فقط في الأعلى.
التناسق عبر الشاشات: أسماء الأزرار، المواضع، ومعاني الأيقونات ثابتة عبر الشاشات الرئيسة. إن استخدمت شاشة "حفظ" وأخرى "تحديث"، اختر واحدًا.
قبل الإطلاق، قم بتمرير سريع باستخدام لوحة المفاتيح والإبهام.
فريق صغير يطلق تدفق تسعير وترقية جديد لأربع خطط (Free, Pro, Business, Enterprise). الهدف بسيط: تتيح للمستخدم الترقية في أقل من دقيقة على الويب والموبايل.
أثناء مرور قصير باستخدام إرشادات نيلسن، يمشي الفريق المسار نفسه مرتين: أولًا كمستخدم جديد على خطة Free، ثم كمستخدم مدفوع يحاول تغيير الخطة. تُسجّل الملاحظات بلغة بسيطة، ليست مصطلحات تصميم.
إليك ما يلتقطونه سريعًا، مرتبًا حسب الإرشادات:
يقررون ما يصلح فورًا وما يؤجل بناءً على المخاطرة. أي شيء يحجب الدفع أو يولد تذاكر دعم يُصلح فورًا. تعديلات النسخ وتسميات المصطلحات يمكن جدولتها لاحقًا، بشرط ألا تُربك المستخدمين أثناء الترقية.
يناسب نفس القالب الويب والموبايل لأن الأسئلة الأساسية ثابتة: هل يرى المستخدمون ما يحدث، هل يمكنهم التراجع عن الأخطاء، وهل يفهمون الكلمات على الشاشة؟ يتغير السطح فقط (حوارات على الويب، شاشات وإيماءات الرجوع على الموبايل).
حياة مراجعة إرشادية أو موتها يعتمد على كيفية كتابتك لها. اجعل كل ملاحظة صغيرة ومحددة: ما حاول المستخدم فعله، ما الخطأ، أين حدث، وأي مبدأ انتهك. لقطة شاشة تساعد، لكن المفتاح خطوة واضحة للفريق.
استخدم مقياس شدة خفيف ليتمكن الناس من الفرز بسرعة بدلًا من مناقشة المشاعر:
للأولوية، اجمع الشدة مع مدى الوصول. شدة 2 في مسار التسجيل الرئيسي قد تُقدم على شدة 3 في شاشة إعدادات نادرًا ما تُستخدم.
لتتبع التكرارات، علِّم الملاحظات بتسمية قصيرة (مثال: "نص خطأ غير واضح" أو "العمل الأساسي مخفي") واحتفظ بعدّاد حسب الإصدار. إن عادت نفس أخطاء UX مرات عديدة، حولها إلى قاعدة فريق أو عنصر في القائمة لفحص المستقبل.
توقف عندما ينتهي الوقت وتصبح الملاحظات الجديدة غالبًا "جميلة أن تتواجد". إن كنت تجد فقط بنود شدة 0-1 لمدة 10 دقائق، فقد تجاوزت نقطة العائد.
الإرشادات ليست القصة كلها. اصعد مستوى عندما ترى خلافًا حول ما سيفعله المستخدمون، انخفاضًا في التحليلات لا تفسير له، تذاكر دعم متكررة لخطوة واحدة، تدفقات عالية المخاطر (دفعات، خصوصية، تسجيل)، أو نمط تفاعل جديد لم تجربه من قبل. عندها يعلو اختبار قابلية الاستخدام السريع والتحقق من التحليلات أو بيانات الدعم على المزيد من النقاش حول إرشادات نيلسن.
تعمل مراجعات الإرشادات أفضل عندما تكون مملة ومتوقعة. عامل إرشادات نيلسن كفحص سلامة قصير، لا حدثًا خاصًا. اختر مالكًا واحدًا لكل إصدار (دوّره)، ضع إيقاعًا يتناسب مع وتيرة الشحن، وابقِ النطاق ضيقًا لكي يحدث فعلًا.
طقس بسيط يصمد مع الزمن:
خلال عدد من الإصدارات، ستلاحظ عودة نفس المشاكل: تسميات أزرار غير واضحة، مصطلحات غير متسقة، نصوص خطأ غامضة، حالات فارغة مفقودة، وتأكيدات مفاجئة. حولها إلى مكتبة إصلاح صغيرة يعاد استخدامها من الفريق. اجعلها عملية: نصوص مقبولة لأخطاء شائعة، نمط معياري للأفعال المدمرة، وبعض أمثلة تحقق جيد.
ملاحظات التخطيط تساعد في منع المشكلات قبل الشحن. أضف مرورًا إرشاديًا سريعًا لملاحظات التخطيط أو التصميم، خصوصًا عندما يتغير تدفق ما. إن أضاف تغيير خطوات، أو مصطلحات جديدة، أو حالات خطأ جديدة، يمكنك اكتشاف الخطر مبكرًا.
إن كنتم تبنون وتتكرّرون بسرعة باستخدام منشئ تطبيقات مدفوع بالمحادثة، من المفيد إقران هذه البِنى السريعة بفحص UX متكرر. بالنسبة للفرق التي تستخدم Koder.ai (koder.ai)، يساعد Planning Mode بالإضافة إلى اللقطات واسترجاع الحالة على الاتفاق مبكرًا على التدفق والنص، اختبار التغييرات بأمان، والتحقق من الإصلاحات على نفس الأساس قبل الإصدار.
استخدمها كـ فحص سلامة سريع قبل الإطلاق. تساعدك في اكتشاف المشكلات الواضحة (ردود فعل مفقودة، تسميات مربكة، رسائل خطأ تؤدي إلى طريق مسدود) ولكنها لا تغني عن اختبار المستخدم أو التحليلات.
قم بمرور سريع لمدة 30–45 دقيقة على مسارين أو مسار واحد حاسم (التسجيل، السداد، الإنشاء، الدعوة). أجرِ جولة سريعة كاملة، ثم جولة أبطأ لتسجيل المشاكل، عيّن لكل مشكلة معيارًا منسوبًا إلى مبدأ (heuristic)، ودرج شدة بسيطة (منخفض/متوسط/عالٍ).
الفريق الصغير يعطي عيونًا طازجة ويقلل العميان. شخص يقود، وشخص يسجل الملاحظات، وثالث يلاحظ التناقضات أو الحالات المفقودة. إن كنت بمفردك، قم بمرورتين: "جولة سريعة" ثم "جولة تفصيلية".
إذا استغرقت عملية أساسية أكثر من ثانية تقريبًا، فأظهر شيئًا ما:
اختبر أيضًا على اتصال أبطأ—العديد من المسارات التي تبدو "على ما يرام" تفشل هناك.
ابدأ بلغة يعرفها المستخدمون:
اجعل الإجراءات الخطرة قابلة للتراجع:
اختر اسمًا ونمطًا واحدًا واستعملهما في كل مكان:
التناقض يزيد الأخطاء وتذاكر الدعم بهدوء.
منع الأخطاء قبل وقوعها:
لا تقبل مدخلات خاطئة وتفشل لاحقًا برسالة غامضة.
رسالة الخطأ الجيدة تجيب عن ثلاثة أمور:
أيضًا: احتفظ بما كتبه المستخدم، ظلل مكان المشكلة بدقة، وتجنّب كلامًا يلقي اللوم.
ارتقِ إلى اختبار المستخدم عندما ترى:
عندها قم باختبار صغير قابلية الاستخدام وتحقق من التحليلات وبيانات الدعم بدل النقاش الطويل.