12 نوفمبر 2025·6 دقيقة
مبادئ Don Norman في تجربة المستخدم لتجنب الواجهات المربكة
مبادئ Don Norman في تجربة المستخدم تساعدك على اكتشاف التدفقات المربكة، تقليل تكاليف الدعم، والتحقق من الشاشات المولّدة بالدردشة قبل أن يضل المستخدمون طريقهم.
مبادئ Don Norman في تجربة المستخدم تساعدك على اكتشاف التدفقات المربكة، تقليل تكاليف الدعم، والتحقق من الشاشات المولّدة بالدردشة قبل أن يضل المستخدمون طريقهم.
الواجهات المربكة لا تشعرك فقط بالسوء. إنها تولد تكاليف قابلة للقياس: الناس يتخلون عن التسجيل أو عملية الدفع، يطلبون استردادات، ويتواصلون مع الدعم لأمور كان يجب أن تكون واضحة.
غالبًا المشكلة ليست في التصميم البصري. إنها في الوضوح. لا يستطيع المستخدمون معرفة ما الذي يريده النظام، ماذا سيحدث بعد ذلك، أو ما إذا كان من الآمن المتابعة.
تتحول هذه الحيرة إلى وقت ونقود حقيقيين بعدة طرق متوقعة. معدلات التسرب ترتفع عندما يصل الناس لنقطة شك. الدعم يُغرق برسائل «أين X؟» و«لماذا حدث هذا؟». تزداد الاستردادات والمنازعات عندما تكون تدفقات الأسعار أو التأكيد أو الإلغاء غير واضحة. داخليًا، تقضي الفرق وقتًا في كتابة أدلة وحلول بديلة لأن المنتج لم يشرح نفسه.
الاحتكاك الصغير يصبح مكلفًا لأنه يتكرر في تدفقات شائعة. تسجيل مربك قد يكلفك مستخدمًا مرة واحدة. دفع مربك يمكن أن يكلفك في كل مرة.
سيناريو بسيط يوضح ذلك: شخص ينشئ حسابًا ويغيّر إعدادًا مثل تكرار الإشعارات. يرى مفتاح تبديل، يضغطه، ولا يؤكّد شيء. لاحقًا ما زال يتلقى رسائل بريدية. الآن لديك تذكرة دعم، يشعر المستخدم بالخداع، وتهبط الثقة. قد تبدو الواجهة نظيفة، لكن التجربة غير واضحة.
السرعة تجعل هذا الأمر أسهل في الفقدان. عندما تبني بسرعة، خاصة باستخدام أدوات دردشة تولّد شاشات وتدفقات بسرعة، قد ينتهي بك الأمر بخطوات منطقية للبنّاء لكنها غير منطقية لمستخدم لأول مرة.
الإصلاح يبدأ ببعض الأفكار المرتبطة عادة بـ Don Norman: اجعل الأفعال بديهية، واطابق نموذج المستخدم الذهني، امنح رد فعل سريع، ومنع الأخطاء قبل حدوثها. بقية هذا الدليل عملي: مجموعة صغيرة من المبادئ، وروتين بسيط للتحقق من أي تدفق بنيناه بسرعة قبل أن تضيع المستخدمين الحقيقين.
الناس لا يقرؤون الواجهات. هم يخمنون.
يحضر المستخدمون نموذجًا ذهنيًا، قصة في رأسهم عن كيفية العمل اعتمادًا على تطبيقات أخرى، أشياء العالم الواقعي، والعادات. عندما تطابق واجهتك ذلك النموذج، يتحرك الناس بسرعة. عندما تتعارض معه، يتباطأون، يترددون، ويرتكبون "أخطاء" هي في الواقع أخطاء تصميم.
مستخدم ينقر على زر الحفظ يتوقع أن عمله آمِن. من ينقر على حذف يتوقع تحذيرًا أو طريقة للعودة بسهولة. من يرى مربع بحث يتوقع أن يكتب ويضغط Enter. هذه التوقعات قائمة قبل أي نص مساعد.
تجربة مستخدم جيدة تستند إلى تلك التوقعات بدلًا من محاولة إعادة تدريب الناس.
الـ affordance هو ما يمكن للعنصر أن يفعله. الـ signifier هو ما يخبرك أنه يستطيع فعله.
حقل نص يسمح بالكتابة. علامة الإشارة هي الصندوق المرئي، المؤشر، وأحيانًا نص العنصر النائب. زر يتيح النقر. علامة الإشارة هي شكله، تباينه، وتسميةه. إذا صممت زرًا ليبدو كنص عادي، لم يتغير الـ affordance، لكن علامة الإشارة ضعفت، فيفوته الناس.
فجوة التنفيذ هي الفجوة بين ما يريده المستخدم والأفعال المتاحة في الواجهة. إذا أراد شخص تغيير عنوان الشحن لكنه يرى فقط "تعديل الملف الشخصي" فقد لا يعرف ماذا يفعل.
فجوة التقييم هي الفجوة بين ما فعله النظام وما يستطيع المستخدم فهمه من الشاشة. إذا نقر على "ادفع" ولم يتغير شيء (أو ظهر مؤشر تحميل صغير فقط)، لا يستطيع أن يقرر إن نجح، فشل، أم ما زال قيد المعالجة.
رد الفعل الجيد سريع، واضح، ومحدد. يجب أن يجيب عن ثلاثة أسئلة: هل نجح؟ ماذا تغير؟ وماذا عليّ أن أفعل بعد ذلك؟
هذا يصبح أكثر أهمية عندما تبني بسرعة باستخدام أدوات دردشة. الشاشات المولدة تحتاج إلى علامات إشارة واضحة وردود فعل لا لبس فيها حتى لا يضيع المستخدمون الجدد.
نادرًا ما تفشل الواجهات المربكة لأن الشيفرة خاطئة. تفشل لأن الشاشة لا تطابق ما يظن الناس أنه سيحدث لاحقًا.
مثال كلاسيكي هو فوضى «حفظ مقابل إرسال مقابل نشر». في كثير من الأدوات قد يعني "حفظ" مسودة، أو حفظ ومشاركة، أو إنهاء العملية. المستخدم الذي يريد فقط حفظ عمله سيَتردد، أو يضغط الزر الخطأ ويشعر بالذعر. تسميات مثل «حفظ كمسودة» و«نشر الآن» تقلل هذا الخوف لأنها تصف النتيجة.
شاشات الإعدادات تسبب ضررًا صامتًا أيضًا. مفاتيح تبديل غير واضحة أو مقلوبة منتشرة: مفتاح معنونه «الإشعارات» دون توضيح ماذا يعني تشغيل. الأسوأ مفتاح يبدو قيد التشغيل بينما الميزة فعليًا معطلة بسبب تبعية أخرى. يفتقد الناس الثقة في الصفحة ويبدأون بالتخمين.
النماذج مجرَّبة أيضًا. نموذج تسجيل يفشل دون شرح السبب يكاد يقول للمستخدم "حاول مجددًا حتى تنجح بالصدفة". قواعد كلمات المرور المخفية حتى بعد الخطأ، حقول مطلوبة تُظهر إطارًا أحمر صغيرًا فقط، أو رسائل مثل "إدخال غير صالح" كلها تضيف عملًا إضافيًا.
الحالات الفارغة قد تحاصر المستخدم. لوحة بيانات فارغة تقول فقط "لا توجد بيانات بعد" تترك المستخدم يتساءل. حالة فارغة مفيدة تجيب على سؤال واحد: ماذا أفعل بعد ذلك؟ عبارة بسيطة مثل «أنشئ مشروعك الأول» مع جملة عن ما سيحصل بعد ذلك تكفي غالبًا.
الأفعال المدمرة غالبًا ما تختبئ خلف كلمات بريئة. "إزالة" قد تعني "الإزالة من هذه القائمة" أو "الحذف نهائيًا". إذا كانت النتيجة غير قابلة للاسترداد، يجب أن تقول التسمية ذلك بوضوح.
إذا كنت تبني بسرعة، فهذه المناطق تستحق التحقق المزدوج أولًا: يجب أن تَصف تسميات الأزرار النتائج، توضح المفاتيح معنى تشغيل وإيقاف، تشِر رسائل الأخطاء للحقل والقواعد مباشرة، تعرض الحالات الفارغة خطوة تالية، وتسمي الأفعال المدمرة بوضوح وتؤكدها عند الحاجة.
معظم الالتباس يبدأ عندما يُبنى المنتج من الخارج للشاشة بدلًا من الداخل لهدف المستخدم. قد تبدو الشاشة مكتملة لكنها تفشل إن لم تساعد شخصًا على إنهاء ما جاء لينجزه.
اختر هدفًا واحدًا واكتبه كمهمة، لا كميزة: «إنشاء فاتورة وإرسالها»، «حجز حلاقة يوم الجمعة»، أو «نشر صفحة هبوط». هذا الهدف هو مرساك لأنه يحدد معنى "تم".
ثم اختصر الرحلة لأقل عدد من الخطوات التي لا تزال تبدو طبيعية. إحدى أسرع الطرق لخفض الالتباس هي إزالة الخطوات التي توجد فقط لأن البنّاء يعرف سياقًا إضافيًا. غالبًا ما يقدّم البنّاء إعدادات مبكرة لأنها بدت منطقية أثناء الإعداد. المستخدمون الجدد عادة يريدون البدء بالعمل ثم تعديل الإعدادات لاحقًا.
اختبار عملي: افحص كل خطوة بثلاثة أسئلة:
إذا فشلت أي خطوة في واحد من هذه، يتباطأ المستخدمون. يعلّقون الفأرة، يتصفحون، يفتحون قوائم عشوائية، أو يسألون زميلًا.
ابحث عن نقاط التوقف المتوقعة: خيار بفوارق غير واضحة («مساحة عمل» مقابل «مشروع»)، نموذج يطلب معلومات ليس لديهم، صفحة بها عدة أزرار أساسية، أو تدفق يغير المصطلحات في منتصف العملية.
عندما تكتشف نقطة توقف، ساوِ بين الإجراء التالي والهدف. استخدم كلمات المستخدم، اجعل الإعدادات المتقدمة لاحقًا، واجعل هناك خطوة واحدة واضحة تالية. يجب أن يشعر التدفق كمسار موجه، لا كاختبار.
يمكن للناس التعامل مع أي واجهة تقريبًا إذا عرفوا ماذا يفعل النظام وماذا حصل بعد تفاعلهم. يبدأ الالتباس عندما تلتزم الشاشة الصمت: لا علامة للحفظ، لا تلميح أن العمل جاري، ولا دليل أن الزر نفّذ شيئًا.
الرد الفوري ليس زخرفة. إنه الواجهة التي تقول "سمعتك". هذا يمنع النقر المزدوج، وإعادة التحميل الغاضبة، والنماذج المهجورة.
أي فعل يستغرق أكثر من طرفة يجب أن يملك حالة مرئية. هذا يشمل تحميل صفحة، معالجة دفعة، رفع ملف، توليد تقرير، أو إرسال رسالة.
قاعدة بسيطة: إن كان المستخدم قادرًا على التساؤل "هل نجح؟" واجهتك يجب أن تكون قد أجابت بالفعل.
اجعلها ملموسة:
التأكيد مفيد فقط عندما يقول ماذا تغير وأين تجده. «نجح» غامض. «الفاتورة أُرسلت إلى [email protected]. يمكنك رؤيتها في الفواتير المرسلة» يطمئن.
الأخطاء يجب أن ترشد لا تعاقب. رد فعل خطأ جيد يحتوي على ثلاثة أجزاء: ما الخطأ، كيف تصلحه، وطمأنة أن المستخدم لم يفقد عمله. احتفظ بما كتبه المستخدم. لا تعِد تعبئة النموذج لأن حقلًا واحدًا خطأ.
الفشل الصامت أسوأ أنواع الردود. إذا فشل شيء، قل ذلك بوضوح واقتراح الإجراء التالي (أعد المحاولة، عدِّل، اتصل بالدعم). إن كنت تحفظ تلقائيًا، أظهر ذلك. إذا لم تستطع الحفظ، اذكر السبب.
عادة لا يرتكب الناس الأخطاء لأنهم مهملون. هم يرتكبونها لأن الواجهة تسمح بالحركة الخاطئة بصمت، أو تفشل في إظهار ما سيحدث بعد ذلك.
فكرة Don Norman عن القيود بسيطة: صمّم بحيث يكون الفعل الأكثر أمانًا هو الأسهل.
قيد جيد ليس نهاية طريق. إذا كان شيء معطلاً، يجب أن يفهم المستخدم السبب وكيف يصلحه. «حفظ» بالرمادي بدون تفسير يبدو معطلاً. «حفظ (أضف عنوانًا للاستمرار)» يبدو مفيدًا.
بعض الأنماط تقلل الالتباس دون أن يشعر المستخدم بأنه مُراقب. استخدم منتقيات أو إعدادات مسبقة عندما يؤدي النص الحر إلى أخطاء قابلة للتجنّب (تواريخ، دول، أدوار). قدم قيم افتراضية معقولة للحالة الأكثر شيوعًا، ثم اترك للمستخدمين المتقدمين تعديلها. تحقق أثناء الكتابة برسائل محددة. إذا عطّلت إجراءً، ضع السبب بجانبه مباشرة.
مثال ملموس: تخيل تدفق "إنشاء مساحة عمل" بُني بسرعة. إذا كانت منطقة قاعدة البيانات مطلوبة، لا تطلب من المستخدم كتابتها. قدم منتقيًا مع افتراضي موصى به وملاحظة قصيرة عن سبب الأهمية. إذا كان الاسم مطلوبًا، أظهر القاعدة مبكرًا («3 إلى 30 حرفًا») بدلًا من انتظار الخطوة الأخيرة.
مربعات التأكيد لا يجب أن تكون مخيفة. يجب أن تكون محددة. بدّل "هل أنت متأكد؟" بما سيتم حذفه، ماذا سيُفقد، وهل يمكن التراجع.
مخرج آمن جزء من منع الأخطاء. «إلغاء» و«عودة» لا يجب أن يحرِفا التقدم بصمت. عندما أمكن، قدّم تراجعًا بعد أفعال مثل إزالة زميل أو حذف مسودة.
الاحتكاك الإضافي يستحقه عندما تكون تكلفة الخطأ عالية: المدفوعات والترقيات، حذف بيانات أو حسابات، منح أذونات، إرسال دعوات لعملاء حقيقيين، أو عمليات تصدير وإعادة ضبط لا رجعة فيها. الهدف ليس إبطاء المستخدمين. الهدف جعل العواقب مرئية قبل النقر.
عندما تبني ميزة بسرعة باستخدام منشئ مبني على الدردشة، الخطر ليس في الشيفرة السيئة. إنه في تدفق منطقي للبنّاء لكنه غير واضح لمستخدم لأول مرة. استخدم حلقة التحقق القصيرة هذه قبل أن يدفع أحد ضريبة الالتباس.
اكتب قصة المستخدم بجملة واحدة. سمِّ الشخص، الهدف، وماذا يعني "تم": مثال: «عميل لأول مرة يريد إعادة تعيين كلمة المرور والعودة لتسجيل الدخول». إن لم تستطع قوله في جملة واحدة فالتدفق غالبًا كبير جدًا.
ارسم الخطوات ثم احذف. خطط الشاشات أو الأفعال بالترتيب. إن لم تُقرب خطوة المستخدم من الهدف، احذفها أو حرّكها لاحقًا.
تحقق من التسميات مقابل القصة. في كل شاشة، تأكد أن الزر الأساسي يطابق الهدف بوضوح. استبدل تسميات غامضة مثل «متابعة» بتسميات نتيجة مثل «أرسل رابط إعادة التعيين» أو «احفظ العنوان». وتأكد أن عنوان الصفحة يتطابق مع ما يحدث.
نفّذ اختبار ممر لمدة 5 دقائق. سلّم التدفق لشخص لم يبنِه. أعطه فقط قصة المستخدم وقاعدة واحدة: لا تلميحات.
سجل الاحتكاكات، لا الآراء. دوِّن كل توقف، تراجع، نقرة خاطئة ولحظة "أين أنا؟". كل منها يصبح تعديلًا ملموسًا: غيّر الصياغة، حرّك حقلًا، أضف رد فعل، أو احذف اختيارًا.
اختبر مجددًا حتى يبدو بديهيًا. أصلح أهم 2–3 مشاكل ثم جرّب مع شخص جديد. توقف عندما يكمل الناس المهمة بسهولة ويستطيعون شرح ما حدث بكلمات بسيطة.
الحلقات القصيرة والمتكررة تهزم المراجعات الطويلة مرة واحدة.
السرعة رائعة حتى تغير ما تركز عليه. أدوات الدردشة قد تملأ الفراغات بتفاصيل معقولة. المستخدمون لن يفعلوا ذلك. هم يحملون كلماتهم، أهدافهم، وصبرهم.
فشل شائع هو انحراف المصطلحات. البنّاء ومحفزات الدردشة تميل إلى المصطلحات الداخلية مثل "workspace"، "entity"، "billing profile"، أو "sync". مستخدم جديد يريد فقط "إضافة زميل" أو "إرسال فاتورة". إن لم تطابق التسميات نموذجه الذهني، يتباطأ ويترك.
فخ آخر هو جعل الواجهة مرآة لقاعدة البيانات. من المغري إظهار الحقول كما توجد في التخزين لأن توليدها سهل: first_name, status_id, plan_tier. لكن الناس لا يفكرون في أعمدة الجداول. هم يفكرون في أسئلة وأفعال: "لمن هذا؟"، "ماذا سيحدث بعد؟"، "هل أستطيع التراجع؟"
البناء السريع يدعو أيضًا لتكديس الميزات. عندما يبدو خطوة ما محرجة، الغريزة إضافة خيار أو تبويب أو قسم متقدم. غالبًا هذا يخفي المشكلة الحقيقية: اللحظة الأولى المربكة ما تزال مربكة.
احذر من نص المساعد كعكاز. العناصر النائبة والتلميحات الصغيرة لا تنقذ تخطيطًا لا يفسر نفسه. إن كانت الشاشة تحتاج فقرات شرح، التصميم يطلب من المستخدم القراءة بدلًا من العمل.
وأخيرًا، "النظافة" قد تكون مكلفة. إخفاء الفعل الرئيسي داخل قائمة قد يبدو أنيقًا لكنه يجعل الناس يبحثون. إن كان هنالك فعل رئيسي على الشاشة، يجب أن يبدو كالفعل الرئيسي.
وأخيرا، السرعة تخفي الحالات الحدية. تدفق يعمل مع بيانات مثالية قد يفشل في الحياة الواقعية: حالات فارغة، شبكات بطيئة، مدخلات خاطئة، أو خروج المستخدم منتصف الخطوة.
تدفق مربك يضيف تذاكر دعم، استردادات، وتسجلات انسحاب بصمت. قبل أن تُطلق شاشة أو تدفق بنيته بسرعة، قم بمرور لعشر دقائق مستخدمًا نفس الأفكار الثلاث: علامات إشارة واضحة، رد فعل فوري، وقيود لطيفة.
ابدأ بالطريق الرئيسي (الشيء الذي جاء معظم المستخدمين لفعله) وتحقق:
فحص يتخطاه كثيرون: بعد النجاح والفشل، يجب أن تكون الخطوة التالية واضحة. حالة النجاح يجب أن تشير إلى الفعل المفيد التالي (عرض الإيصال، تتبع الطلب، دعوة زملاء). حالة الفشل يجب أن تترك المستخدم مسيطرًا (إصلاح الحقل، إعادة المحاولة، الاتصال بالدعم) دون مسح المدخلات.
إن كنت تبني على Koder.ai، اعتبر هذه القائمة مرورًا نهائيًا على نص الواجهة وحالاتها قبل النشر. وضع التخطيط يمكن أن يساعدك على كتابة هدف الجملة الواحدة والخطوات المتوقعة مسبقًا، حتى لا تبدو الواجهة المولدة مكتملة بينما هي في الواقع متاهة.
السرعة ليست الهدف. الوضوح هو الهدف. أسرع بناء يفشل إن لم يستطع الناس إكمال الشيء الذي أتوا من أجله.
عادة بسيطة تحافظ على أمانتك: راجع تدفقًا أساسيًا في كل إصدار. اختر التدفق الذي يدفع الفواتير أو يبني الثقة (التسجيل، الإنشاء، الدفع، الدعوة). عندما يكون ذلك التدفق واضحًا، يصبح الباقي أسهل.
اجعل التغييرات صغيرة ومرئية. إن غيّرت تسمية زر، رسالة الخطأ، وتخطيط الصفحة معًا، فلن تعرف ما الذي ساعد.
الاختبار مع المستخدم الحقيقي لا يحتاج مختبرًا. أعطِ شخصًا مهمة بسيطة واصمت. إن تردد، تلك هي قائمة أخطاءك.
للفِرق التي تبني وتتكرر بسرعة، أدوات مثل Koder.ai تساعد على النمذجة والنشر بسرعة، لكن أساسيات تجربة المستخدم هي التي تقرر ما إذا كان المستخدمون سيكملون المهمة. اعتبر عمل الوضوح جزءًا من البناء، لا خطوة تنظيف لاحقة.
واجهة مربكة تخلق تكاليف متكررة:
الوضوح يتعلق بما إذا كان مستخدم لأول مرة يستطيع الإجابة عن ثلاثة أسئلة في كل خطوة:
يمكن أن تكون الواجهة بصريًا "نظيفة" وتفشل إن لم تكن النتائج متوقعة وواضحة.
النموذج الذهني هو توقع المستخدم لكيفية عمل شيء ما بناءً على تطبيقات أخرى وعادات الحياة اليومية.
النهج الافتراضي: طابق التوقعات الشائعة (مثلاً: حفظ يعني حفظ العمل، حذف يعني تحذير أو إمكانية التراجع). إذا اضطررت لكسر توقع، فافعل ذلك بتسميات واضحة وردود فعل صريحة حتى لا يضطر المستخدم للتخمين.
الـ affordance هو ما يمكن لعنصر أن يفعله. الـ signifier هو ما يجعله واضحًا.
مثال: زر ما يزال "يعمل" حتى لو بدا كنص عادي، لكن الـ signifier ضعيف فسيغفل الناس وجوده. الحل العملي: حسّن علامات الإشارة عبر تسميات واضحة وتباين ومكان وحالات (مضغوط/تحميل/معطل).
استعملها كتشخيص سريع:
لغلقهما: اجعل الفعل التالي سهلًا للعثور، واجعل النتائج لا تُخطئ.
استعمل تسميات مبنية على النتيجة.
الهدف: يجب أن يعرف المستخدم النتيجة قبل الضغط.
اجعل المعنى الصريح لـ ON/OFF واضحًا وحافظ على صدق النظام:
تجنّب مفاتيح تبدو مُشغّلة بينما الميزة فعليًا مُعطلة.
قاعدة افتراضية: إذا كان المستخدم قد يسأل «هل نجح؟» فواجهة المستخدم يجب أن تكون قد أجابت بالفعل.
أنماط عملية:
امنع الأخطاء بجعل المسار الآمن هو الأسهل:
وبالنسبة للأفعال المدمرة، أكد مع تفاصيل (ما سيُحذف، ما سيُفقد، هل يمكن التراجع؟).
شغّل حلقة تحقق قصيرة قبل الإطلاق:
كرر حتى يكمل الأشخاص المهمة بسلاسة ويشرحون ما حدث بكلمات بسيطة.