من الممكن أن يَعمَل موقعك دون أخطاء برمجية وأيضًا قد تبدو صفحاته مُرتَّبة، ومع ذلك يَعجِز الزائر عن إكمال ما جاء من أجله. يَجِد موعدًا مناسبًا، ثم يتردَّد أمام زِرّ لا يعرف إن كان سيؤكِّد الحجز أم سينقله إلى خطوة أخرى. المشكلة هنا في فَهْم الواجهة واستخدامها.
عندما نراجع قابلية الاستخدام (Usability)، نسأل إن كان الشخص يستطيع إنجاز ما يريد داخل الموقع بسهولة. في مثال الحجز، لا يكفي أن نُضيف زِرًّا لحجز الموعد؛ يجب أن يجده الزائر ويَفهَم الخطوات ويستطيع إكمال الحجز. فما يبدو واضحًا لنا قد يُربِك شخصًا يَستخدِم الموقع للمرة الأولى.
ما هي قابلية الاستخدام؟
قابلية الاستخدام هي مدى قُدرة أشخاص مُحدَّدين على إنجاز أهداف مُحدَّدة بفاعلية وكفاءة ورضا، ضمن ظروف الاستخدام الفِعليّة. وتَنقُل W3C هذا التعريف عن معيار ISO 9241-11. أي أننا نُقيِّم ما يحدث أثناء استخدام المُنتَج، وليس شكله وحده.
في موقع لحجز المواعيد، تعني الفاعلية أن يحجز الشخص الخدمة والموعد الصحيحين. وتعني الكفاءة أن يصل إلى النتيجة بوقت وجُهد مناسبين، بينما يرتبط الرضا بتقييمه للتجربة وشعوره تجاه استخدامها. قد يُكمِل الحجز، لكنه يصل إلى النهاية مُرهَقًا وغير واثق مما حدث.
كذلك، لا نَحكُم على التصميم دون تحديد جمهوره. المُوظَّف الذي يُدخِل عشرات الحجوزات يوميًا يختلف عن عميل يزور الموقع للمرَّة الأولى. وقد تتغيَّر الصعوبات عند استخدام الهاتف، أو الاتصال البطيء، أو قارئ الشاشة. لذلك اسأل دائمًا: مَن يَستخدِم الواجهة، ولأي هدف، وفي أي ظروف؟
هل تختلف قابلية الاستخدام عن سهولة الاستخدام؟
نستخدم عبارة «سهل الاستخدام» عادةً لوصف مُنتَج لا يحتاج إلى جُهد كبير لفهمه والتعامل معه. وهي عبارة قريبة من معنى قابلية الاستخدام، وليست مُصطَلحًا مُضادًّا لها. لكن قول شخص إن الموقع سهل لا يُخبِرنا وحده إن كان قد أنجز المطلوب أو واجه أخطاء.
أما تجربة المُستخدِم فهي أوسع؛ فقد تكون خطوات الحجز واضحة، ثم يتأخَّر تأكيد الموعد أو لا تُقدَّم الخدمة كما وُصِفت. هنا تَظلّ التجربة بحاجة إلى تحسين، حتى لو كانت الواجهة نفسها مفهومة.
وترتبط قابلية الاستخدام أيضًا بإمكانية الوصول Accessibility، التي تهتمّ بإزالة العوائق أمام الأشخاص ذوي الإعاقة. زِرّ واضح بصريًا لكنه لا يُستخدَم بلوحة المفاتيح قد يمنع بعض الأشخاص من إكمال الحجز. وتُوضِّح W3C تداخل المجالين؛ اختبارات الاستخدام مع بعض المُشارِكين لا تُغني عن مراجعة مُتطلَّبات الوصول.
خمسة جوانب تساعدك على التقييم
تَعرِض Nielsen Norman Group خمسة مُكوِّنات لجودة قابلية الاستخدام. يمكنك تحويلها إلى أسئلة مرتبطة بالمَهَمّة التي تراجعها:
قابلية التعلُّم (Learnability): هل يعرف العميل الجديد كيف يبدأ حجز موعد، دون أن تشرح له مكان البداية؟
الكفاءة (Efficiency): بعد معرفة طريقة الاستخدام، هل يستطيع تكرار الحجز بجُهد مناسب؟
سهولة التذكُّر (Memorability): إذا عاد بعد انقطاع، هل يستعيد طريقة التعامل مع الموقع بسهولة؟
الأخطاء (Errors): ما الأخطاء التي تحدث، وما أثرها، وهل يستطيع الشخص تصحيحها؟
الرضا (Satisfaction): كيف يصف الشخص استخدام الموقع، وما الذي أزعجه أو ساعده؟
هذه الأسئلة تُوجِّه المراجعة، لكنها لا تعني إعطاء كل شاشة درجة عشوائية من عشرة. اربط كل ملاحظة بسلوك شاهدته: اختار المُشارِك خدمة مختلفة، أو عاد ثلاث مرات للتأكُّد من السِّعر، أو لم يعرف كيف يُعدِّل الموعد.
لماذا تستحق قابلية الاستخدام التحسين؟
إذا كان العثور على الموعد صعبًا، فقد يترك العميل الموقع أو يتَّصل بالدعم ليُكمِل الحجز. وفي نظام داخلي قد يُضطرّ المُوظَّف إلى الاستمرار، لكنه يستغرق وقتًا أطول أو يحتاج إلى زميل يساعده. وجود بديل لدى المُستخدِم يُغيِّر رَدّ فِعله، ولا يُلغي المشكلة.
لذلك لا نحتاج إلى القول إن كل واجهة صعبة ستفشل حتمًا. ما يمكن مراجعته هو الأثر الفِعليّ: حجوزات خاطئة، ومحاولات مُتكرِّرة، وأسئلة للدعم، ومهام لم تكتمل. هذه تفاصيل تُساعدك على اختيار ما يستحق الإصلاح قبل الانشغال بتحسينات شكلية لا تُعالِج العائق.
كيف تُحسِّن موقعك أو تطبيقك؟
لنَستخدِم مثالًا افتراضيًا لموقع حجز خدمات: يختار الشخص الخدمة، ثم الفرع والموعد، ويكتب بيانات التواصل ويُراجِع الحجز. الخطوات الآتية تُوضِّح كيف تراجع هذه الرحلة.
وضِّح البداية والخطوة التالية
استخدم أسماء يفهمها العميل. «احجز موعدًا» أوضح من اسم داخلي مثل «إدارة الطلبات» إذا كان المقصود بدء حجز جديد. واجعل الزِرّ يصف ما سيحدث: «متابعة إلى بيانات التواصل» يختلف عن «تأكيد الحجز».
استفد من الأنماط المألوفة، وحافظ على طريقة مُتَّسِقة لاختيار المواعيد والتنقُّل. لكن لا تفترض أن وضع القائمة في أعلى الصفحة مناسب لكل واجهة. ما تحتاج إلى التحقُّق منه هو أن يَجِد الشخص وِجهته ويعرف كيف يعود، على الجهاز الذي يَستخدِمه.
اجمع المعلومات المرتبطة بالقرار
عند اختيار الموعد، أَظهِر الفرع والخدمة والسِّعر بالقرب منه، حتى لا يُضطرّ الشخص إلى العودة للتأكُّد مما اختاره. استخدم عناوين واضحة، مثل «اختر موعد الزيارة» و«بيانات التواصل»، واجعل الفرق بين الأقسام ظاهرًا بالمسافات وترتيب المحتوى.
لا تُخفِ التفاصيل الضرورية لمجرد تقليل العناصر الظاهرة. قد تبدو شاشة ذات زِرّ واحد بسيطة، لكنها تُجبِر العميل على فتح صفحات أخرى لمعرفة تكلفة الحجز. وفي فصل متاح من كتاب ستيف كروغ «لا تجعلني أفكِّر»، يُركِّز الكاتب على وضوح الاختيار والجُهد الذي يتطلَّبه، لا عدد النقرات وحده.
اجعل التفاعل والتصحيح واضحَين
ميِّز الأزرار والروابط حتى يستطيع الشخص اكتشافها، ووفِّر مساحة مناسبة للضغط عليها. إذا كانت المواعيد متقاربة جدًا على الهاتف، فقد يختار الشخص الوقت الخطأ رغم فَهْمه للمحتوى. يشرح قانون فيتس علاقة حجم الهدف والمسافة بسهولة الوصول إليه.
عند إدخال بريد غير صالح، لا تكتفِ بتلوين الحَقْل بالأحمر. وضِّح المشكلة بنصّ قريب منه، مثل «اكتب البريد بصيغة name@example.com»، مع إبقاء البيانات الأخرى. تُوضِّح إرشادات W3C ضرورة وصف الخطأ نصيًا وعدم الاعتماد على اللون وحده.
وبعد تأكيد الحجز، اعْرِض الخدمة والفرع والموعد ورقم الحجز. إذا كان الطلب يحتاج إلى موافقة المُوظَّف، فَقُل ذلك بوضوح؛ رسالة «تمّ الحجز» قد تجعل الشخص يظنّ أن الموعد مؤكَّد. كذلك، اجعل الوصول إلى تعديل الموعد أو إلغائه مفهومًا بحسب شروط الخدمة.
كيف تختبر أن التحسين مفيد؟
يمكن أن تبدأ بنَمُوذج أوَّليّ قبل تطوير الموقع، أو بمَهَمّة داخل المُنتَج الموجود. يُوضِّح دليل اختبارات الاستخدام لدى NN/g أن الاختبار يقوم على إعطاء مهام لأشخاص يُمثِّلون الجمهور، ثم ملاحظة ما يفعلونه أثناء التنفيذ.
في مثال الحجز، اطلب: «تريد زيارة الفرع القريب من عملك الأسبوع المُقبِل بعد الرابعة مساءً؛ ابحث عن موعد يناسبك واحجزه». لا تَقُل: «اضغط زِرّ المواعيد ثم اختر الفرع»، لأنك بذلك تشرح الطريق الذي تريد اختبار وضوحه.
كما في إرشادات الاختبار بإشراف باحث لدى GOV.UK، راقِب أين يتردَّد الشخص، وما الذي يقرأه، ومتى يعود إلى خطوة سابقة. اسأله بعد المَهَمّة عمّا فَهِمه وما الذي توقَّع حدوثه. وإذا تدخَّلت لمساعدته، فسجِّل ذلك؛ إكمال المَهَمّة بتوجيه منك يختلف عن إكمالها دون مساعدة.
مراجعة الفريق الداخلية مفيدة لاكتشاف عيوب واضحة، لكنها لا تكفي لمعرفة تجربة العميل الجديد؛ الفريق يعرف أسماء الأقسام وتسلسل الخطوات مسبقًا. كذلك، لا يكفي سؤال الناس إن كانوا يُحبّون التصميم، لأن الإعجاب بالمظهر لا يثبت قدرتهم على استخدامه.
كيف تقيس النتيجة وتختار الأولوية؟
قبل الجَلسة، حدِّد معنى نجاح المَهَمّة. في مثالنا، لا يكفي الوصول إلى آخر شاشة؛ يجب اختيار الخدمة والفرع والوقت المطلوبين، وفَهْم حالة الحجز. ثم دوِّن النتائج بطريقة ثابتة:
اكتمال المَهَمّة: هل وصل الشخص إلى النتيجة الصحيحة، وبمساعدة أم دونها؟
الوقت والجُهد: كم استغرق، وأين تكرَّر البحث أو الرجوع؟
الأخطاء والتصحيح: ما الذي أخطأ فيه، وهل استطاع إصلاحه؟
تقييم الشخص: ما الذي وَصَفه بالصعب، وما سبب ذلك؟
إذا أردت المقارنة بعد التعديل، حافظ قدر الإمكان على نوع المَهَمّة وظروف الاختبار وخصائص المُشارِكين. انتبه أيضًا إلى أن إعادة المَهَمّة للشخص نفسه قد تجعله أسرع بسبب التعلُّم. ولا تحوِّل ملاحظات جَلسات قليلة إلى نسبة تحسُّن عامّة عن جميع العملاء.
رتِّب المشكلات بحسب أثرها وتكرارها وقُدرة الشخص على تجاوزها. عدم معرفة أن الموعد ما زال ينتظر الموافقة قد يستحق أولوية أعلى من تردُّد قصير أمام عنوان. وبعد الإصلاح، اختبر المَوضِع مُجدَّدًا وتحقَّق من أن التعديل لم يجعل خطوة أخرى أصعب.
يمكنك الاستفادة من بيانات الموقع لمعرفة أين ينسحب الناس، ومن أسئلة الدعم لاختيار ما ستختبره. لكن ارتفاع الانسحاب من صفحة لا يشرح السبب وحده؛ ربما لم يَجِد الزائر وقتًا مناسبًا أصلًا. اجمع هذه الإشارات مع الملاحظة قبل أن تُقرِّر تغيير التصميم.
ابدأ بمَهَمّة مُهِمّة في موقعك: حجز، أو شراء، أو العثور على معلومة. راقِب شخصًا يحاول إنجازها، ثم أصلح عائقًا واضحًا وتحقَّق من أثر التعديل. بهذه الطريقة تصبح قابلية الاستخدام جزءًا من قراراتك اليومية، وتعرف ما الذي تحسَّن فعلًا بدل الاكتفاء بانطباع أن الواجهة أصبحت أجمل.
المصادر
Nielsen Norman Group — Usability 101: مكوّنات جودة قابلية الاستخدام؛ مرجع من المقال الأصلي.
W3C — Accessibility, Usability, and Inclusion: تعريف قابلية الاستخدام المنقول عن ISO، وعلاقتها بإمكانية الوصول.
Nielsen Norman Group — Usability Testing 101: المهام والمشاركون والملاحظة في اختبار الاستخدام.
GOV.UK — Using Moderated Usability Testing: إعداد جلسات الاختبار وملاحظة أداء المشاركين.
Steve Krug — Don’t Make Me Think, Revisited: كتاب من مراجع المقال الأصلي؛ الفصل المتاح من موقع المؤلف يناقش وضوح الاختيار والجهد وراء النقرات.
W3C — Error Identification: تحديد الخطأ ووصفه نصيًا.
W3C — Use of Color: عدم استخدام اللون وحده لنقل المعنى.
Baymard Institute — Travel Accommodations UX: مصدر لقطة تقويم الحجز في Expedia.
Nielsen Norman Group — Design Guidelines for Reporting Errors in Forms: مصدر لقطة رسالة الخطأ في نموذج Adobe. صورة جلسة الاختبار من دليل NN/g المذكور أعلاه.
تاريخ النشر
14 سبتمبر 2026
آخر تعديل
6 أكتوبر 2026
