تخيل أنك تفتح تطبيقًا لحجز موعد في عيادة، ستظهر أمامك أسماء الأطباء وصورهم وتخصصاتهم وأسعار الكشف وغيرها من المعلومات. لكنك تبحث عن شيء محدد: موعد متاح هذا المساء. تمرّ على البطاقات واحدة تلو الأخرى، وتفتح تفاصيل كل طبيب حتى تجد ما تحتاجه.
في تطبيق آخر، تختار التخصص وتحدد الوقت المناسب، فتظهر المواعيد المتاحة مع معلومات الطبيب والسعر. ببساطة أنت تجد أن الحجز أسهل في هذا التطبيق لأن ترتيب المعلومات يوافق ما تحاول إنجازه.
هذا النوع من القرارات هو ما يشغل مصمم واجهات المستخدم: ماذا يظهر على الشاشة؟ بأي ترتيب؟ وكيف يعرف المستخدم ما يستطيع فعله وما حدث بعد تفاعله؟
لبناء واجهة واضحة، تبدأ بفهم المهمة والمحتوى، ثم تحدد الأولويات البصرية، وتصمم المكونات وحالاتها، وتختبرها بأحجام ومحتويات مختلفة. وبعد التنفيذ، تراجع المنتج لتتأكد من أن هذه القرارات تعمل كما توقعت، هذه باختصار كل النقاط التي يجب أن تفكر بها، ولكن ماذا يعني كل هذا لنبدأ بالفهم.
ما هو تصميم واجهات المستخدم؟
تصميم واجهات المستخدم، أو UI Design، هو تصميم العناصر البصرية والتفاعلية التي يستخدمها الشخص للتعامل مع المنتج، مثل الصفحات والأزرار والحقول والقوائم ورسائل النظام. هدفه أن يكون المحتوى مفهومًا، والإجراء واضحًا، ونتيجة التفاعل قابلة للملاحظة.
يشمل العمل تخطيط الشاشة، والخطوط والألوان والمسافات، وطريقة عرض المحتوى، وسلوك المكونات في حالات مثل التحميل والخطأ والتحديد. ويتطلب أيضًا مراعاة اختلاف أحجام الشاشات واللغات واحتياجات الوصول.
أيضاً للجمال دور أساسي هنا. فاختيار خط مناسب وتكوين متوازن وهوية متسقة يجعل تجربة الاستخدام أكثر جاذبية وهذا شيء أساس ومهم. لكنك تحتاج إلى فحص الوضوح والجاذبية كلًّا على حدة؛ فقد تبدو الشاشة جميلة بينما يصعب العثور على الإجراء الأساسي فيها.
ما الفرق بين UI وUX وتصميم المنتجات؟
يركز تصميم واجهة المستخدم UI على التفاصيل البصرية والتفاعلية للواجهة. أما تجربة المستخدم UX فتتناول تجربة الشخص الأوسع مع المنتج، بما فيها فهم احتياجاته وتنظيم الرحلة واختبار سهولة الاستخدام. بينما يجمع تصميم المنتجات Product Design هذه الاعتبارات مع أهداف العمل والقيود التقنية لتطوير الحل وتحسينه.
يمكن رؤية الفرق في مثال حجز الموعد:
المجال | سؤال نموذجي | تطبيقه في رحلة الحجز |
|---|---|---|
تجربة المستخدم UX | ما الذي يجعل المستخدم يتردد أو يتوقف؟ | معرفة ما إذا كان يحتاج إلى التأكد من قبول التأمين قبل اختيار الطبيب |
واجهة المستخدم UI | كيف نعرض المعلومات ونجعل التفاعل مفهومًا؟ | إظهار التأمين المقبول بوضوح وتصميم حالات اختيار الموعد |
تصميم المنتجات | ما الحل المناسب للمستخدم والعمل، وكيف نختبره؟ | تحديد دور التأمين في رحلة الحجز بالتعاون مع الفريق ومتابعة أثر التغيير |
مع يجب أن تدرك أن حدود الأدوار تختلف بين الشركات، وقد يقوم شخص واحد بجزء كبير من هذه المهام. لذلك يفيد هذا التقسيم في فهم المسؤوليات، مع بقاء التعاون بينها ضروريًا طوال المشروع ومراعاة دورك في المشروع بحسب الشركة التي تعمل لصالحها.
كيف تبدأ تصميم الواجهة؟
ابدأ بوصف المهمة بجملة محددة. «حجز أقرب موعد مسائي مع طبيب جلدية» هذه الجملة تعطيك اتجاهًا أوضح من «تصميم صفحة للأطباء».
في الحالة الأولى، ستحتاج إلى إبراز التخصص والمواعيد المتاحة. أما إذا كان المستخدم يبحث عن طبيب بعينه للمتابعة، فقد يصبح البحث بالاسم هو المدخل الأنسب. اختلاف الحاجة يغيّر نقطة البداية.
قبل رسم الشاشة، دوّن إجابات عن هذه الأسئلة:
ما الذي يريد المستخدم إنجازه؟
ما المعلومات التي يحتاجها لاتخاذ القرار؟
ما الخطوة التالية، وماذا سيحدث بعدها؟
ما الذي قد يمنع إكمال المهمة؟
ما القيود التي يفرضها المحتوى واللغة والجهاز وطريقة عمل الخدمة؟
بعد ذلك، اكتب محتوى الشاشة كنص بسيط: عنوانها، والمعلومات الضرورية، والخيارات، وأسماء الإجراءات. ستكتشف أحيانًا أن المشكلة تبدأ من المحتوى نفسه؛ فقد تكون معلومة أساسية مفقودة، أو قد يطلب التدفق من المستخدم اتخاذ قرار قبل تزويده بما يحتاجه.
ففي مثالنا، قد تطلب العيادة بعض المعلومات حول المستخدم قبل قبول الحجز مثل العمر والجنس والمشاكل الصحية السابقة، لذلك من المهم أن تقوم بوضع هذه المعلومات أمامك قبل أن تبدأ في تصميم الشاشات.
كيف ترتّب المعلومات داخل الشاشة؟
التسلسل الهرمي البصري Visual Hierarchy هو ترتيب العناصر بحيث يلاحظ المستخدم المعلومات والإجراءات بحسب أهميتها. تساعدك الأحجام والأوزان والألوان والمسافات والمحاذاة على بناء هذا الترتيب.
تتناول إرشادات التخطيط لدى Apple ترتيب العناصر بحسب أهميتها واتجاه القراءة، وتشرح إرشادات الخطوط دور الحجم والوزن واللون في إظهار هرمية المعلومات.
لنستخدم مثالًا تعليميًا لشاشة حجز تحتوي على المعلومات الآتية:
د. ليلى أحمد، اختصاصية جلدية.
فرع الروضة.
موعد متاح في 15 أكتوبر، الساعة 6:30 مساءً.
رسوم الكشف: 200 ريال.
إمكانية الاطلاع على ملف الطبيبة واختيار الموعد.
إذا ظهرت هذه المعلومات بأحجام متقاربة، وبجوارها زران بارزان بالقدر نفسه، فقد يتوقف المستخدم ليفهم العلاقة بينهما. يمكنك تحسين الشاشة بترتيبها حول القرار المطلوب:
يظهر اسم الطبيبة وتخصصها معًا، ويأتي الموعد تحت تسمية واضحة مثل «أقرب موعد مسائي». تبقى رسوم الكشف والفرع ظاهرين قبل الاختيار، ثم يبرز زر «اختيار الموعد»، بينما يأخذ رابط «عرض ملف الطبيبة» وزنًا بصريًا أقل.
أيضاً هناك نقاط اخرى مثل اسم الزر نفسه. فإذا كان الضغط ينقل المستخدم إلى مراجعة بيانات الموعد، فإن «اختيار الموعد» يصف ما يحدث بدقة أكبر من «تأكيد الحجز». هنا يجب الاحتفاظ بالتأكيد للخطوة التي يثبت فيها الحجز فعلًا.
هذا ترتيب مناسب للسيناريو الذي افترضناه. وقد تحتاج إلى تغييره إذا أظهرت دراسة المستخدمين أن الموقع أو التأمين أهم في قرارهم.
لاختبار وضوح التسلسل الهرمي، اعرض الشاشة لفترة قصيرة على شخص، ثم اسأله: ما الموعد المتاح؟ كم تبلغ الرسوم؟ وماذا تتوقع بعد الضغط على الزر؟ إجاباته تعطيك مؤشرًا أوليًا إلى وضوح الشاشة، ويمكنك بعدها اختباره أثناء تنفيذ المهمة كاملة.
المكونات والحالات: ماذا يحدث بعد التفاعل؟
عند تصميم واجهة اختيار الموعد، تحتاج إلى تحديد شكلها وسلوكها في أكثر من لحظة. هل الموعد متاح؟ هل اختاره المستخدم؟ وهل ما زال متاحًا عند محاولة تأكيده؟
قد يختار المستخدم الساعة 6:30، ثم يحجزها شخص آخر قبل اكتمال العملية. في هذه الحالة تحتاج الواجهة إلى شرح ما حدث، والاحتفاظ بما يمكن الاحتفاظ به من بياناته، ومساعدته على اختيار بديل، هذه حالة يجب أن تفكر بها، لذلك عندما تعمل كمصمم واجهة استخدام ليس مطلوب منك تصميم الواجهة فقط وإنما أيضاً تصميم كل الحالات المتوقعة.
تختلف المعالجة بحسب حالة النظام أي الحالة التي سوف تحدث في التصميم:
الحالة | ما يحتاج المستخدم إلى فهمه | مثال على المعالجة |
|---|---|---|
التحميل | يجري جلب المواعيد | مؤشر تحميل قريب من قائمة المواعيد |
التحديد | هذا هو الموعد الذي اختاره | علامة تحديد مع التاريخ والوقت |
عدم وجود مواعيد | لا توجد نتائج تطابق اختياره | رسالة تتيح تغيير اليوم أو الفرع |
فقدان الموعد المختار | أصبح الموعد غير متاح | توضيح ما حدث وإظهار البدائل |
تعذر التحقق من الحجز | نتيجة العملية لم تتأكد بعد | رسالة دقيقة وخيار للتحقق من حالة الحجز |
النجاح | اكتمل الحجز | تفاصيل الموعد ورقم الحجز وطريقة الوصول إليه لاحقًا |
انتبه إلى الفرق بين حالة فشل الحجز وحالة تعذر معرفة نتيجة. فمثلا إذا انقطع الاتصال بعد الإرسال، فقد يكون الحجز قد اكتمل بالفعل. يجب أن تعكس الرسالة ما يعرفه النظام، حتى لا تدفع المستخدم إلى تكرار العملية دون حاجة.
وأيضًا للمكونات نفسها حالات تفاعل أخرى، مثل التركيز عند التنقل بلوحة المفاتيح. التركيز يوضح العنصر الذي سيتلقى التفاعل التالي، بينما يوضح التحديد الخيار الذي اختاره المستخدم. وقد تجتمع الحالتان على العنصر نفسه.
تساعد مكتبة المكونات على توحيد هذه القرارات. وعندما تستخدم نمطًا قائمًا، راجع أنه يدعم المحتوى والسلوك المطلوبين، وأضف الحالات الناقصة بالتعاون مع الفريق.
كيف تجعل الواجهة متجاوبة؟
التصميم المتجاوب هو تكييف ترتيب عناصر الواجهة وأبعادها مع المساحة المتاحة، مع الحفاظ على المحتوى والوظائف التي يحتاجها المستخدم، أي بإختصار كيف سوف تظهر الواجهة على شاشات بمقاسات مختلفة.
على شاشة واسعة، يمكنك وضع معلومات الطبيبة بجوار المواعيد. وعلى الهاتف، يمكن ترتيبها رأسيًا: معلومات الطبيبة، ثم اختيار الموعد، ثم ملخص السعر والإجراء التالي.
راجع وجود المعلومات نفسها في الحالتين. إذا اختفى السعر من نسخة الهاتف، فقد تكون حسّنت ترتيب العناصر على حساب معلومة يحتاجها المستخدم قبل المتابعة.
ابدأ بمساحة صغيرة، ثم وسّعها تدريجيًا. عندما يصبح السطر طويلًا أو تتباعد العناصر المرتبطة أو يتوقف التكوين عن خدمة المحتوى، اختبر ترتيبًا آخر. هذا يتفق مع توجيه web.dev إلى اختيار نقاط التحول بحسب حاجة المحتوى، بدل الاعتماد فقط على مقاسات أجهزة محددة.
ولا تكتفِ بعرض التصميم على مقاسين جاهزين مثل اجهزة سطح المكتب والهاتف المحمول. جرّب المساحات الواقعة بينهما أي هنا مقاس الأجهزة اللوحية، هذه الحالات تكشف مشاكل قد لا تظهر في النسخة المثالية.
ما الذي تحتاج إلى مراجعته في الواجهة العربية؟
تؤثر اللغة العربية في اتجاه القراءة والمحاذاة وتسلسل العناصر، ويزداد الأمر دقة عندما يجتمع النص العربي مع الأرقام والأسماء اللاتينية.
في بطاقة الحجز مثلًا، اختبر اسمًا عربيًا طويلًا، واسم خدمة بالإنجليزية، وتاريخًا ووقتًا ورقم حجز. راقب ترتيب الرموز وعلامات الترقيم داخل السطر، لا محاذاة البطاقة وحدها.
ومن المفيد مراجعة الآتي:
هل يبدأ ترتيب المعلومات من الموضع المتوقع للقارئ العربي؟
هل تبقى الأوقات والأرقام والمقاطع اللاتينية مقروءة بترتيبها الصحيح؟
هل تشير أسهم التنقل إلى الاتجاه المناسب؟
هل الخط العربي واضح في النصوص الصغيرة والأزرار؟
هل يتسع المكوّن للترجمة دون اقتطاع معلومات ضرورية؟
هل هناك اتساق بين الخط العربي والخط اللاتيني الذي قمت بإختياره؟
توفّر متطلبات تخطيط العربية والفارسية لدى W3C مرجعًا لاتجاه النص ومزج العربية بالمقاطع الأخرى، وتوضح إرشادات Apple للواجهات من اليمين إلى اليسار كيفية التعامل مع العناصر التي يتغير اتجاهها والعناصر التي تحتفظ باتجاهها.
استخدم محتوى عربيًا فعليًا خلال التصميم. المستطيلات التي تمثل النص مفيدة في التخطيط الأولي، لكنها لا تكشف التفاف الكلمات أو تداخل الاتجاهات أو اختلاف ارتفاع السطور,
ملاحظة: حالياً توليد محتوى واقعي عبر AI أصبح أمراً سهلاً ، لذلك استفد من هذه الميزة من أجل توليد محتوى للتصاميم التي تعمل عليها.
إمكانية الوصول Accessibility: هل يستطيع المستخدم قراءة الواجهة والتفاعل معها؟
تظهر مشكلات إمكانية الوصول في تفاصيل يومية: سعر مكتوب بلون باهت، أو موعد يصعب الضغط عليه، أو مؤشر تركيز لا يمكن ملاحظته. وهي مشاكل قد تؤثر على على جميع المستخدمين أو على شريحة محددة منهم، وسوف نتطرق لشرح إمكانية الوصول بمقال منفصل بشكل أكبر.
ولكن حتى تبدأ الآن قم بالإطلاع على مجموعة من الفحوصات، مثل إرشادات WCAG 2.2:
تباين النص: يحدد معيار WCAG للمستوى AA نسبة تباين لا تقل عن 4.5:1 للنص العادي، و3:1 للنص الكبير وفق تعريف المعيار، مع استثناءات محددة. افحص الألوان المستخدمة فعليًا بدل تقدير التباين بالنظر. مرجع تباين النص
تكبير النص: اختبر تكبير النص حتى 200% دون فقدان المحتوى أو الوظيفة، وفق نطاق المعيار واستثناءاته. راقب خصوصًا الأزرار والحقول والبطاقات ذات الارتفاع الثابت. مرجع تكبير النص
مساحة التفاعل: ينص معيار الحد الأدنى لحجم الهدف في WCAG 2.2 على 24×24 بكسل CSS، مع استثناءات تشمل التباعد الكافي بشروط محددة. تعامل معه كحد أدنى، واختر مساحة مريحة لطبيعة التفاعل. مرجع حجم الهدف
كذلك أضف علامة أو نصًا إلى الحالات التي تميزها بالألوان، واجعل رسائل الخطأ تشرح المشكلة والخطوة التالية. وراجع ترتيب التنقل بلوحة المفاتيح ووضوح أسماء الحقول والإجراءات لقارئ الشاشة بالتعاون مع المطور.
هذه الفحوص بداية للمراجعة، ويحتاج تقييم إمكانية الوصول الكامل إلى اختبار بقية المتطلبات المناسبة للمنتج.
كيف تسلّم التصميم إلى المطور؟
يحتاج المطور إلى فهم القواعد التي تحكم الشاشة، خصوصًا القرارات التي لا تكشفها الصور ثابتة.
في مثال الحجز، ينبغي أن يعرف متى يتم تفعيل زر المتابعة، وما الذي يحدث عند تغيير الفرع، وكيف تُحدَّث المواعيد، وما الرسالة التي تظهر إذا أصبح الاختيار غير متاح.
جهّز الملفات للتسليم:
المكونات المستخدمة وحالاتها.
قواعد ترتيب المحتوى عند تغير العرض.
النصوص الفعلية، بما فيها رسائل الخطأ والمساعدة.
القيم المرتبطة بنظام التصميم، مثل المسافات وأحجام الخطوط.
الحالات التي تحتاج إلى قرار مشترك مع فريق التطوير أو الفريق المنتج.
توثيق نصي للمكونات لتسهيل فهم عملها وحالاتها.
كيف تتعلم تصميم واجهات المستخدم عمليًا؟
اختر مهمة صغيرة يمكنك إكمالها من البداية إلى النهاية، مثل حجز موعد. المشروع المحدود يمنحك فرصة لفهم التفاصيل ومراجعتها.
ابدأ بالمحتوى والتدفق، ثم ارسم تصورًا أوليًا للشاشات. بعد ذلك، طوّر الخطوط والمسافات والألوان، وقم ببناء المكونات والحالات، وجهّز نموذجًا تفاعليًا يمكن لشخص آخر تجربته.
أثناء الاختبار، اطلب من الشخص تنفيذ مهمة واضحة: «اختر موعدًا مسائيًا واعرف تكلفته قبل التأكيد». راقب أين يتوقف وما الذي يتوقعه، واترك له فرصة المحاولة قبل شرح الواجهة.
دوّن ما تغيّر بعد التجربة وسبب تغييره. هذه الملاحظات ستفيدك في المشروع التالي، وستجعل عرض المشروع في ملفك أقوى؛ إذ يستطيع من يراه يفهم المشكلة والبدائل والقرارات التي أوصلتك إلى هذه النتيجة.
قائمة مراجعة قبل اعتماد الواجهة
هل يعرف المستخدم ما يستطيع إنجازه في الشاشة؟
هل تظهر المعلومات الضرورية قبل اتخاذ القرار؟
هل تصف أسماء الأزرار ما سيحدث بعدها؟
هل توجد معالجة واضحة للتحميل والفراغ والخطأ والنجاح؟
هل يحتفظ المستخدم ببياناته عندما يواجه مشكلة؟
هل تعمل الواجهة بمحتوى عربي طويل وأحجام شاشة مختلفة؟
هل يمكن قراءة النص والوصول إلى عناصر التفاعل بسهولة؟
هل يفهم المطور القواعد والحالات المطلوبة؟
هل تم اختبار المهمة بعد التنفيذ؟
ابدأ في واجهتك التالية بشاشة واحدة، واكتب المهمة التي يفترض أن تساعد المستخدم على إنجازها. ضع فيها محتوى واقعيًا، ثم راقب شخصًا يحاول استخدامها. التفاصيل التي يتردد عندها ستعطيك نقطة بداية واضحة للمراجعة: معلومة تحتاج إلى إبرازها، أو إجراء يحتاج إلى تسمية أدق، أو حالة تحتاج إلى تفسير.
المصادر الأساسية
تاريخ النشر
26 سبتمبر 2026
آخر تعديل
26 سبتمبر 2026
