تعرّف على معنى واجهة المستخدم وتجربة المستخدم من مثال واحد في تطبيق، وكيف تراجع قرار الواجهة وتختبر ما فهمه المستخدم بعد الضغط.
UI/UX اختصار يجمع تخصصين يعملان على المنتج الرقمي نفسه. الأول واجهة المستخدم، وهي ما يراه الشخص على الشاشة ويتعامل معه: الأزرار والنصوص وترتيب المعلومات، وما تفعله هذه العناصر حين يستخدمها. والثاني تجربة المستخدم، وهي ما يمر به الشخص وهو يحاول إنجاز هدفه بالمنتج أو الخدمة، قبل الشاشة وأثناءها وبعدها. الواجهة تجيب عن سؤال: ماذا يظهر أمامه، وماذا يستطيع أن يفعل؟ والتجربة تجيب عن سؤال آخر: هل أنجز ما جاء من أجله، وهل يعرف ما الذي حدث؟ وهذا التقسيم قريب مما تعرضه مجموعة نيلسن نورمان في دليلها لتخصصات تجربة المستخدم.
لنفترض أن متقدمًا ضغط «إرسال الطلب» في تطبيق مصرفي لفتح حساب. تختفي الخانات التي ملأها، وتظهر علامة صح خضراء. هل يستطيع استخدام الحساب الآن، أم أن طلبه وصل إلى فريق المراجعة؟ نجحت الشاشة في إبلاغه بأن شيئًا حدث، وتركته يخمّن ما هو. المثال افتراضي، لكنه يكشف الفرق بين التخصصين: زر الإرسال ورسالة النتيجة قرارات واجهة، وقدرة المتقدم على معرفة وضع طلبه ومتابعته غدًا سؤال عن التجربة.
ما الفرق بين واجهة المستخدم وتجربة المستخدم؟
يعمل التخصصان على المنتج نفسه، لكن كل واحد منهما يبدأ من سؤال مختلف. ويظهر الفرق بوضوح حين نتتبع زرًا واحدًا من لحظة ظهوره إلى ما بعد الضغط عليه.
واجهة المستخدم تبدأ بما يحتاج الشخص إلى قراءته وفعله
لنأخذ شاشة مراجعة الطلب قبل إرساله. أمام المتقدم اسمه ورقم جواله، وزر لتعديل البيانات، وزر رئيسي لإرسالها. على مصمم الواجهة أن يقرر أي معلومة تُعرض أولًا، ومدى وضوح الفرق بين التعديل والإرسال، وما الذي يظهر أثناء انتظار رد النظام. لون الزر جزء من هذه المهمة، وكذلك العبارة المكتوبة عليه، وما يحدث بعد لمسه.
لنفرض أن الزر يحمل كلمة «متابعة». تناسب هذه الكلمة خطوة يستطيع الشخص الرجوع منها، لكنها قد تفاجئه إذا كان الضغط يرسل الطلب فورًا. فإن كانت الخطوة التالية مراجعة البيانات، فعبارة «مراجعة الطلب» أدق. وإن كانت آخر خطوة، فعبارة «إرسال الطلب» تعطيه توقعًا صحيحًا. ويحتاج اختيار العبارة إلى اتفاق بين كاتب المحتوى والمطور على ما يفعله الزر فعلًا، كما شرحنا في مقالنا عن أثر الرسائل في تجربة العميل.
ويمكن اختبار القرار والشاشة ما زالت رسمًا أوليًا: غطِّ ما يأتي بعد الزر، واطلب من زميل لم يشارك في التصميم أن يصف ما سيحدث إذا ضغطه. إجابة واحدة لا تكفي للحكم على المستخدمين كلهم، لكنها قد توفر جولة كاملة من تحسين شكل زر لا يوصل المعنى المقصود.
أين تبدأ تجربة المستخدم وأين تنتهي؟
من جهة النظام، قد تنتهي العملية حين يُحفظ الطلب ويأخذ رقمًا مرجعيًا. ومن جهة المتقدم، تبدأ عندها مهمة جديدة: هل بقي شيء مطلوب منه؟ أين سيرى الرد؟ وكيف يعود إلى طلبه بعد إغلاق التطبيق؟ فإن لم يجد طريقة لمعرفة حالة طلبه إلا بتقديم طلب جديد، فالمشكلة أكبر من صياغة الرسالة، وتمس طريقة تنظيم الخدمة نفسها.
لهذا يفيد تحديد نهاية المهمة قبل رسم الشاشات. هل الهدف أن يرسل الشخص بياناته فقط، أم أن يعرف أيضًا حالة طلبه في زيارة لاحقة؟ في الحالة الأولى قد يكفي تأكيد الاستلام. وفي الثانية يحتاج المنتج إلى مكان معروف لحالة الطلب، وإلى اسم للحالة يبقى مفهومًا في صفحة الطلب وفي الإشعار على الجوال معًا.
وقد تمتد المهمة خارج التطبيق كله. حين تقول الرسالة «سنتواصل معك»، قد ينتظر المتقدم داخل الشاشة لأنه يظن أن الرد سيظهر فيها. يستطيع المصمم أن يسمي قناة المتابعة إن كانت معروفة. أما إن لم تتفق الفرق بعد على من يرسل الرد ومتى تتحدث الحالة، فهذا قرار خدمة يحمله فريق المنتج إلى فريق التشغيل، وكتابة وعد أدق لن تجعل الوفاء به ممكنًا. وعند هذا الامتداد تلتقي تجربة المستخدم مع تجربة العملاء في الرحلة كلها.
تنتهي الواجهة عند حدود الشاشة، وتستمر التجربة حتى ينجز الشخص ما جاء من أجله.
حدّد أين تنتهي مهمة المستخدم قبل أن ترسم الشاشات.
كيف نقرأ شاشة التطبيق قبل اعتمادها؟
مراجعة الواجهة تكشف ما يظهر على الشاشة، لكنها لا تثبت وحدها ما فهمه المستخدم. وفي كل قرار من القرارات التالية سؤالان: ماذا نرى؟ وما الذي يحتاج إلى ملاحظة استخدام حقيقي حتى نعرفه؟
ماذا يعني الرقم الذي أراه؟
في منصة سعودية للبيانات الائتمانية أعادت عزم إكس تصميمها، تتصدر الدرجة الائتمانية الشاشة الرئيسية، ومعها وصف بالكلمات يشرح معناها، وتاريخ آخر تحديث للبيانات. كان يمكن عرض الرقم وحده بحجم كبير، واعتبار أن المعلومة الأهم أخذت حقها. لكن الوصف والتاريخ يجيبان عن سؤالين لا يجيب عنهما الرقم: ماذا تعني هذه الدرجة؟ ومتى كانت صحيحة؟
من زاوية الواجهة، يرى المراجع كيف جُمعت العناصر وما الذي يظهر أولًا. ويرى كذلك أين يجد الشخص شرحًا إضافيًا. ومن زاوية التجربة، يحتاج الفريق إلى معرفة إن كان المستخدم يقرأ الدرجة، ويفهم حداثة بياناتها، ويعرف خطوته التالية. فقد ينظر شخصان إلى الرقم نفسه ويخرجان بفهمين مختلفين، لأن أحدهما انتبه لتاريخ التحديث والآخر لم ينتبه.
ولمراجعة شاشة مشابهة، يمكن عرض تاريخين على نموذج أولي: تاريخ زيارة التطبيق وتاريخ تحديث البيانات، ثم سؤال المشارك أيهما يصف الرقم الذي أمامه. فإن اختار التاريخ الخطأ، فالمراجعة تبدأ من التسمية، ثم من موضع التاريخ وقربه من الرقم. وهذا اختبار نقترحه للتعلم، لا نتيجة منسوبة إلى ذلك المشروع.
اقرأ حالتين متتاليتين، لا شاشة واحدة
نعود إلى طلب فتح الحساب. في الحالة الأولى يرى المتقدم بياناته وزر «إرسال الطلب»، وفي الثانية يرى «استلمنا طلبك» ورقمًا مرجعيًا. يستطيع المراجع أن يثبت أن رقمًا ظهر وأن النص يذكر الاستلام. أما أن المتقدم فهم أن حسابه لم يُفعَّل بعد، فهذه فرضية تحتاج إلى اختبار.
ولنجعل السؤال أصعب: إذا أغلق المتقدم التطبيق وعاد إليه مساءً، فهل يجد زرًا لبدء التسجيل من جديد، أم رابطًا باسم «متابعة طلبي»؟ قد تكون رسالة التأكيد ممتازة ثم يضيع أثرها بمجرد مغادرة الشاشة. وهنا يظهر الفرق بين مراجعة شاشة ومراجعة مسار: الأولى تكشف وضوح الكلام، والثانية تكشف إن كان الكلام يبقى صحيحًا ومفيدًا بعد الانتقال إلى مكان آخر.
وفي لحظة الانتظار قرار آخر. إن لم يصل رد النظام بعد، فماذا يرى الشخص؟ إعادة عرض زر الإرسال قد تدفعه إلى تكرار المحاولة، وإخفاؤه دون تفسير يتركه بلا إشارة. والأفضل أن يتفق المصمم مع المطور على الحالات الممكنة فعلًا، كالإرسال الجاري والاستلام المؤكد وتعذّر التحقق من النتيجة، ثم تُكتب لكل حالة عبارة تناسب ما يعرفه النظام وقتها. فلا تظهر عبارة «تم الاستلام» إلا حين يكون الاستلام مؤكدًا.
ثم تأتي العودة من الخطأ. إذا تعذّر إرسال الطلب، فهل احتفظ النموذج بالبيانات؟ وهل المطلوب تعديل حقل بعينه، أم الانتظار والمحاولة مجددًا؟ هذه الإجابات تحدد النص والإجراء معًا. وتؤكد إرشادات اتحاد شبكة الويب العالمية لإشعارات النماذج أهمية إبلاغ المستخدم بالنجاح أو الخطأ، وإرشاده إلى التصحيح عند الحاجة، مع اختلاف التنفيذ بين مواقع الويب والتطبيقات.
ما الذي يتغير في واجهة عربية؟
على شاشة جوال بالعربية، قد يجتمع في سطر واحد اسم عربي ورقم مرجعي بحروف لاتينية وتاريخ. والمحاذاة إلى اليمين جزء صغير من القرار. هل يبدو الرقم مرتبطًا بتسميته الصحيحة؟ هل يقرأ قارئ الشاشة المعلومات بالترتيب المقصود؟ وإذا نُسخ الرقم، فهل تبقى حروفه بترتيبها؟ يشرح اتحاد شبكة الويب العالمية أثر تحديد اتجاه النص الأساسي، وطريقة التعامل مع المقاطع التي تسير في اتجاه مختلف داخل السطر، ويبقى التحقق من السلوك الفعلي على كل منصة ضروريًا. وقد فصّلنا هذه القرارات في دليل تصميم واجهات المستخدم العربية.
جرّب سطر رقم الطلب داخل النموذج الحقيقي، ومعه علامة ترقيم، ثم ضيّق المساحة. قد يكون الترتيب سليمًا على شاشة المصمم الكبيرة، ثم ينفصل الرقم عن تسميته حين ينكسر السطر على الجوال. واطلب من المشارك أن يقرأ الرقم أو يستخدمه للعثور على طلبه، فقراءة عنصر منفرد في ملف التصميم لا تكشف ما يحدث حين يضيق المكان.
وانظر إلى كلمة الحالة نفسها. عبارة «بانتظار المراجعة» توضح ما يجري حتى لمن لا يميز لون الشارة. وإذا كان المطلوب استكمال حقل، فسمِّ الحقل واشرح المطلوب بجواره، لأن نقطة حمراء وحدها في أعلى النموذج تُحمّل الشخص مهمة البحث عن الخطأ وفهمه معًا. وتنص إرشادات الوصول إلى محتوى الويب على ألا يكون اللون الوسيلة الوحيدة لإيصال المعلومة.
كيف تعرف أن تجربة المستخدم تحسّنت؟
القياس يبدأ بمهمة واضحة، وبفريق يتفق قبل الاختبار على ما يعدّه نجاحًا.
كيف يعمل فريق الواجهة وفريق التجربة على القرار نفسه؟
في اجتماع مراجعة نموذج فتح الحساب، قد يقول مسؤول المنتج إن الهدف تقليل المكالمات التي تسأل عن حالة الطلب. يبدأ الباحث من سبب المكالمة كما يصفه صاحبها، ويجرب مصمم الواجهة مكانًا أوضح لرابط الطلبات السابقة، ويسأل كاتب المحتوى إن كانت كلمة «مكتمل» تعني اكتمال البيانات أم اكتمال فتح الحساب. أما المطور وفريق التشغيل فيحددان الحالات التي يرسلها النظام فعلًا. وتختلف المسميات الوظيفية بين الشركات، لذلك يفيد توزيع العمل بحسب القرار المطلوب، لا بحسب من يملك الشاشة.
ويظهر الفرق بين التخصصات أكثر حين لا تنجح المعالجة الأولى. يضيف الفريق الرابط، ثم يكتشف في الاختبار أن المتقدم رآه ولم يفتحه، لأنه ظن أن «الطلبات السابقة» تعني الطلبات المنتهية. أمام الفريق الآن حلول معقولة: إعادة تسمية الرابط، أو إبراز الطلب الجاري في الصفحة الرئيسية، أو شرح مسار المتابعة بعد الإرسال. والاختيار يتوقف على ما فعله المشاركون، وعلى ما تستطيع الخدمة تنفيذه.
اختبر مهمة واحدة، وعرّف النجاح قبلها
اختر مهمة قصيرة يمكن ملاحظتها. أعطِ المشارك نموذجًا تجريبيًا وبيانات مصطنعة، واطلب منه تقديم الطلب ثم معرفة ما حدث له، واتركه يستخدم الواجهة كما يفهمها. فإن قلت له «اضغط على متابعة طلبي»، فقد أعطيته جزءًا من الإجابة التي تريد اختبارها. وتشرح مجموعة نيلسن نورمان في مدخلها إلى اختبار قابلية الاستخدام كيف تكشف ملاحظة المشاركين، وهم ينفذون مهامّ واقعية، مواضع تعثرهم.
وفي مثالنا ثلاثة أحداث يُسجَّل كل منها على حدة: إرسال الطلب مرة واحدة، والعثور عليه بعد العودة، ووصف حالته وصفًا صحيحًا. قد ينجح المشارك في الأولين ثم يظن أن الحساب جاهز للاستخدام. والفريق الذي يكتفي بعدّ الطلبات المرسلة تفوته أهم ملاحظة في التجربة، والذي يكتفي برأي المشاركين في جمال الواجهة لا يعرف أي خطوة تحتاج إلى مراجعة.
سجّل أول تصرف قبل تقديم أي مساعدة، ثم اسأل المشارك بعد المهمة عما توقعه حين اختار. وفرّق بين من يعرف النسخة القديمة ومن يراها أول مرة: الأول قد يبحث عن رابط حفظ مكانه، والثاني يعتمد على الكلمات والترتيب الحاليين. واحتفظ بما رأيته منفصلًا عن تفسيرك له.
وعند تجربة نسخة معدّلة، غيّر ما يجيب عن سؤالك وحده. لمعرفة إن كانت التسمية مفهومة، ثبّت موضع الإجراء وقارن النصين. ولمعرفة إن كان الإجراء سهل الوصول، ثبّت النص وغيّر الموضع. أما إعادة التصميم الكاملة فتناسب سؤالًا أوسع، لكنها تُصعّب معرفة أي تغيير أحدث الفرق.
وقد تتعارض الأرقام مع ملاحظات الجلسة. قد تقلّل النسخة الجديدة وقت الإرسال، ويخرج بعض المشاركين مع ذلك وهم يظنون أن الحساب فُعِّل. اختصار الوقت هنا لا يحسم قرار الإطلاق، والسؤال يعود إلى لحظة الالتباس: أي معلومة غابت عند الإرسال؟ ربما يحتاج النص إلى تعديل بسيط، وربما يحتاج النظام إلى إظهار حالة لم تكن متاحة أصلًا.
ما الذي يخرج به اجتماع المراجعة؟
خذ الشاشة التي أثارت أكبر خلاف في فريقك، واكتب تحتها ثلاثة أسطر. في الأول ما يظهر: «يعرض التطبيق رقم الطلب بعد الإرسال». وفي الثاني التوقع: «سيفهم المتقدم أن الطلب وصل، وأن التفعيل ما زال معلقًا». وفي الثالث الدليل: «يعود إلى الطلب ويشرح حالته دون مساعدة». صار لديك الآن قرار واجهة وسؤال تجربة، ومعهما طريقة للتحقق من السؤال.
بعد ذلك، حدّد المعلومة الناقصة التي تمنع القرار. إن كان الخلاف على ما يفعله النظام، فاطلب وصفًا دقيقًا للحالات من فريق التطوير. وإن كان على ما يفهمه الناس، فراقب أشخاصًا وهم يستخدمون النموذج. ولمن يحتاج إلى توسيع هذا العمل من شاشة واحدة إلى خدمة كاملة، تعرض عزم إكس خدماتها في تصميم واجهات المستخدم وتجربته، وما يمكن فحصه مع المستخدمين في مختبر تجربة المستخدم.
وحين يعرض عليك فريقك علامة الصح الخضراء مرة أخرى، اسأل سؤالًا واحدًا: ماذا أصبح بإمكان الشخص أن يفعل الآن؟ فإن اختلفت الإجابات، فقد وجدت قرار تصميم يستحق الوقت قبل اختيار شكل العلامة أو لونها.
