تصميم الواجهات — من الفكرة إلى نموذج تفاعلي

1. UI مقابل UX — الشكل والتجربة

الهدف: تميّز بين واجهة المستخدم وتجربة المستخدم، وتستخدم الهرمية البصرية لتوجيه العين إلى المهمة الأساسية في الشاشة.

واجهة المستخدم (User Interface) هي الطبقة التي تراها وتلمسها: الأزرار والألوان والخطوط والأيقونات والمسافات. أما تجربة المستخدم (User Experience) فأوسع منها بكثير: كل ما يمر به الشخص منذ أن يفتح التطبيق حتى ينجز ما جاء من أجله أو يغلقه منزعجاً، بما في ذلك سرعة التحميل، ووضوح الرسائل، وطريقة التعامل مع الأخطاء. يعرّف موقع Nielsen Norman Group التجربة بأنها تشمل جميع جوانب تفاعل المستخدم مع الجهة وخدماتها ومنتجاتها، وهذا يعني أن جزءاً منها يقع خارج الشاشة أصلاً، مثل رسالة التأكيد النصية أو مكالمة خدمة العملاء.

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

الهرمية البصرية (Visual hierarchy) هي الجسر بين الشكل والتجربة. معناها ترتيب العناصر بحيث تقرأ العين الأهم أولاً ثم ما يليه. يتحكم المصمم في هذا الترتيب بخمسة مفاتيح: الحجم، فالعنصر الأكبر يُرى أولاً؛ والوزن، فالعريض يسبق العادي؛ واللون والتباين، فالعنصر المشبع على خلفية هادئة يجذب النظر؛ والموضع، فأعلى الشاشة وبداية سطر القراءة، وهي اليمين في العربية، يحظيان بالانتباه أولاً؛ والتقارب، فالعناصر المتجاورة تُفهم مجموعة واحدة.

مثال محلول — ترتيب الشاشة الرئيسية للصيدلية:
1) اكتب جملة المهمة: «مريض أو أحد أقاربه يريد إرسال الروشتة ومعرفة موعد الوصول في أقل من دقيقة».
2) رتّب المحتوى حسب الأهمية: زر تصوير الروشتة، ثم وقت التوصيل، ثم الطلبات السابقة، ثم العروض.
3) امنح المستوى الأول أكبر وزن بصري: زر بعرض الشاشة بلون العلامة، ثم نص متوسط الحجم لوقت التوصيل بجانب أيقونة ساعة.
4) اجعل العروض بطاقات صغيرة بإطار رمادي في أسفل الشاشة حتى لا تنافس المهمة الأساسية.
5) النتيجة المتوقعة: عند عرض الشاشة ثلاث ثوانٍ على شخص لم يرها من قبل، يستطيع أن يقول ماذا يفعل التطبيق وأين يضغط.

لفحص الهرمية بسرعة استخدم اختبار التحديق (Squint test): ضيّق عينيك، أو طبّق تمويهاً قوياً (Blur) على لقطة الشاشة في Figma حتى تختفي الكلمات وتبقى الكتل. إذا كان أول ما يبرز هو الإجراء الأساسي، فالهرمية سليمة. وإذا برزت صورة العرض الترويجي أو الشعار أولاً، فهناك عنصر ثانوي يسرق الانتباه. يستغرق هذا الاختبار دقيقة واحدة ولا يحتاج إلى أي أداة مدفوعة.

كثرة العناصر البارزة تلغي الهرمية من أساسها؛ إذا كانت خمسة أزرار كلها ملونة وعريضة، فلا يوجد زر أساسي. تنصح إرشادات Apple للأزرار بأن يبقى عدد الأزرار البارزة في الشاشة واحداً أو اثنين، وبأن يُميَّز الخيار المفضل بالأسلوب، كأن يكون معبأً باللون بينما البقية بإطار فقط، مع الحفاظ على الحجم نفسه للخيارات المتكافئة. القاعدة العملية للمبتدئ: زر معبأ واحد لكل شاشة، والباقي أزرار بإطار أو روابط نصية.

يظهر الفرق بين الدورين في الأسئلة التي يطرحها كل منهما. مصمم الواجهة يسأل: هل هذا الزر واضح ومقروء ومتسق مع بقية الأزرار؟ ومصمم التجربة يسأل: هل يحتاج المستخدم هذا الزر في هذه الخطوة أصلاً؟ وماذا يحدث بعد الضغط؟ وماذا لو انقطع الإنترنت في منتصف الطلب؟ في الفرق الصغيرة يقوم شخص واحد بالدورين، والمهم أن يطرح النوعين من الأسئلة قبل أن يعتبر الشاشة منتهية.

• UI هي الطبقة المرئية، وUX هي الرحلة كاملة بما فيها ما يحدث خارج الشاشة.
• ابدأ كل شاشة بجملة مهمة واحدة، ثم رتّب العناصر لخدمتها.
• الحجم والوزن والتباين والموضع والتقارب هي مفاتيح الهرمية البصرية.
• اختبار التحديق يكشف في دقيقة العنصر الذي يسرق الانتباه.

للاستزادة: NN/g: تعريف تجربة المستخدم · NN/g: الهرمية البصرية في تجربة المستخدم · Apple HIG: الأزرار وأسلوب الإجراء الأساسي

2. أساسيات Figma — إطار وشاشة

الهدف: تنشئ ملف Figma بإطار هاتف، وتبني عناصر مرنة بـ Auto Layout، وتضبط النص العربي وترتيب العناصر من اليمين.

Figma أداة لتصميم الواجهات تعمل في المتصفح وفي تطبيق لسطح المكتب، ولها خطة مجانية تكفي للتعلم والمشاريع الشخصية. الملف محفوظ على الإنترنت، فيستطيع أكثر من شخص فتحه والتعليق عليه في الوقت نفسه، ويمكنك الرجوع إلى نسخة سابقة من سجل الإصدارات. تنقسم الشاشة إلى ثلاث مناطق: لوحة الطبقات (Layers) على اليسار، ومساحة العمل (Canvas) في الوسط، ولوحة الخصائص على اليمين وفيها تبويب Design للمظهر وتبويب Prototype للتفاعل. واجهة البرنامج نفسها إنجليزية ومن اليسار إلى اليمين حتى لو كان تصميمك عربياً، وهذا لا يؤثر في النتيجة.

أهم مفهوم في Figma هو الإطار (Frame): حاوية لها مقاس محدد وخلفية خاصة، تمثل شاشة كاملة أو جزءاً منها. يختلف الإطار عن المجموعة (Group) في أنه يملك أبعاداً مستقلة، ويمكنه قص المحتوى الزائد عن حدوده، ويحمل شبكة تخطيط وAuto Layout، أما المجموعة فتلتف حول عناصرها فقط وتتغير بتغيرها. القاعدة العملية: كل شاشة إطار، وكل مكوّن له بنية داخلية إطار، والمجموعة للتجميع المؤقت فقط.

أول شاشة خطوة بخطوة — شاشة ترحيب لتطبيق حجز ملاعب متخيَّل:
1) اضغط F واختر من اللوحة اليمنى مقاس هاتف مثل 393 × 852، وهو مقاس iPhone 15 بالنقاط.
2) اضغط T واكتب العنوان «احجز ملعبك في دقيقة»، واختر خطاً عربياً، واضبط المحاذاة لليمين.
3) اكتب كلمة «ابدأ» في مربع نص جديد، وحدده، واضغط Shift+A فيلتف حوله إطار Auto Layout.
4) اضبط الحشوة (Padding) 24 أفقياً و12 رأسياً، واملأ الخلفية بلون العلامة، واجعل استدارة الزوايا 12.
5) غيّر النص إلى «ابدأ الحجز الآن»: يتمدد الزر وحده لأن عرضه مضبوط على Hug contents.
6) سمِّ الطبقات بوظائفها، مثل «زر/أساسي» و«عنوان/ترحيب»، بدلاً من الأسماء التلقائية مثل Frame 12.

يقوم Auto Layout على أربعة إعدادات تبني بها معظم المكونات. الاتجاه: أفقي أو رأسي أو التفاف (Wrap) إلى أسطر متعددة. والفجوة (Gap): المسافة الثابتة بين العناصر. والحشوة: المسافة بين حافة الإطار ومحتواه. وسلوك التحجيم لكل عنصر: Fixed لمقاس ثابت، وHug ليلتف حول المحتوى، وFill ليملأ المساحة المتاحة في الإطار الأب. بهذه الأربعة تصنع صفاً من أيقونة ونص، وبطاقة منتج، وقائمة تتمدد عناصرها عند إضافة عنصر جديد.

سجل مشكلات شائعة مع العربية في Figma وحلولها:
• المشكلة: صف أفقي فيه نص وسهم، ظهر فيه النص يساراً والسهم يميناً بعكس المطلوب. السبب: الصف الأفقي يرتب العناصر من اليسار بحسب ترتيب الطبقات. الحل: بدّل ترتيب العنصرين داخل الإطار ثم تحقق بعينك من الشكل النهائي.
• المشكلة: نهايات الأسطر غير متساوية في الشاشة. الحل: اضبط محاذاة كل مربع نص لليمين، واجعل عرض المربع Fill container بدلاً من عرض يدوي يختلف من مربع لآخر.
• المشكلة: سهم الرجوع في الشريط العلوي يشير إلى اليسار. الحل: في الواجهة العربية يشير الرجوع إلى اليمين، لأن تسلسل الشاشات يتبع اتجاه القراءة كما توضح إرشادات Apple لاتجاه RTL.
• المشكلة: جملة تخلط عربياً وأرقاماً وكلمات لاتينية تظهر بترتيب مربك. الحل: اختبر جملاً حقيقية مثل «طلبك رقم 4512 في الطريق» داخل التصميم، وسجّل أي ترتيب غريب ليعالجه المبرمج لاحقاً.

نظّم الملف من اليوم الأول بثلاث صفحات على الأقل: «مسودات» للتجارب، و«شاشات» للتصميم المعتمد، و«مكونات» للعناصر القابلة لإعادة الاستخدام. ومن الاختصارات التي توفر وقتاً ملحوظاً: Ctrl+D للتكرار، وCtrl+G للتجميع، وCtrl+Alt+G لتحويل التحديد إلى إطار، والضغط على Alt مع تمرير المؤشر فوق عنصر آخر لقياس المسافة بينهما، وShift+2 للتكبير على العنصر المحدد.

• كل شاشة إطار مستقل، والمجموعة للتجميع المؤقت فقط.
• Auto Layout يعتمد على الاتجاه والفجوة والحشوة وسلوك التحجيم.
• الصف الأفقي يبدأ من اليسار، فرتّب العناصر وتحقق بصرياً في الشاشات العربية.
• أسماء الطبقات الواضحة توفر وقتك ووقت من يستلم الملف بعدك.

للاستزادة: Figma: الإطارات في Figma Design · Figma: دليل Auto Layout · Apple HIG: الواجهات من اليمين إلى اليسار

3. الألوان — تناسق وقراءة

الهدف: تبني لوحة ألوان بأدوار واضحة، وتحسب نسبة التباين، وتتحقق من متطلبات WCAG AA للنصوص وعناصر الواجهة.

اللون في الواجهة أداة وظيفية قبل أن يكون زينة: يوجّه العين إلى الإجراء الأهم، ويميز حالات النجاح والخطأ، ويحمل هوية العلامة. لذلك تُبنى اللوحة بالأدوار لا بالأذواق. اللون الأساسي (Primary) للإجراء الرئيسي والروابط، والألوان المحايدة (Neutrals) للخلفيات والنصوص والحدود وتشغل معظم الشاشة، وألوان الحالة للنجاح والخطأ والتحذير والمعلومة، ثم لون ثانوي اختياري لتمييز أقل أهمية. قاعدة 60-30-10 الشائعة، أي نحو 60٪ محايد و30٪ داعم و10٪ لون بارز، ليست قانوناً، لكنها تمنع ازدحام الألوان في الشاشة.

سمِّ الألوان بوظيفتها لا بمظهرها: color/text/primary وcolor/bg/surface وcolor/status/error أفضل من «أزرق غامق 2». عندما تتغير هوية العلامة أو تضيف وضعاً داكناً، تعدّل القيمة في مكان واحد ويبقى المعنى ثابتاً، وهذا ما ستفعله لاحقاً بالمتغيرات (Variables) في درس المكونات.

أما قابلية القراءة فلها معيار مكتوب. في إرشادات WCAG 2.2 يطلب المعيار 1.4.3 في مستوى AA نسبة تباين لا تقل عن 4.5:1 بين النص العادي وخلفيته، و3:1 للنص الكبير، أي 18 نقطة (نحو 24 بكسل) بوزن عادي أو 14 نقطة (نحو 18.7 بكسل) بوزن عريض. ويطلب المعيار 1.4.11 نسبة 3:1 لعناصر الواجهة غير النصية التي يحتاجها المستخدم ليفهم الواجهة: حد حقل الإدخال، وأيقونة زر بلا نص، ومؤشر التركيز. ويستثني المعيار النصوص داخل عنصر معطّل والشعارات، لكن النص المعطّل يجب أن يبقى مفهوماً على الأقل.

مثال محلول — حساب التباين يدوياً مرة واحدة لتفهم ما تفعله الأدوات:
1) النسبة = (L1 + 0.05) ÷ (L2 + 0.05)، حيث L هو السطوع النسبي (Relative luminance) للون، وL1 للأفتح وL2 للأغمق، وقيمته من 0 للأسود إلى 1 للأبيض.
2) الأبيض #FFFFFF سطوعه 1، والرمادي #767676 سطوعه قرابة 0.181 بعد تحويل كل قناة لونية من مقياس sRGB إلى قيمة خطية.
3) النسبة = 1.05 ÷ 0.231 ≈ 4.54، فيجتاز حد 4.5:1 بفارق ضئيل.
4) الرمادي #999999 سطوعه قرابة 0.318، فالنسبة = 1.05 ÷ 0.368 ≈ 2.85، فيفشل للنص العادي وللنص الكبير معاً.
5) في العمل اليومي لا تحسب يدوياً؛ أداة WebAIM Contrast Checker أو إضافة داخل Figma تعطيك النسبة فوراً.

قبل وبعد، في حالة متخيَّلة لمخبز في الإسكندرية لونه المميز برتقالي فاتح #F59E0B. قبل التعديل: زر «اطلب الآن» برتقالي ونصه أبيض، ونسبة التباين نحو 2.1:1 فقط، فيصعب قراءته في ضوء الشمس. بعد التعديل جُرّب حلّان: إبقاء البرتقالي الفاتح للخلفية مع نص رمادي داكن #1F2937 بنسبة نحو 6.8:1، أو استخدام درجة أغمق من العائلة نفسها #B45309 خلف النص الأبيض بنسبة نحو 5:1. كلا الحلين يحفظ هوية المخبز ويجتاز مستوى AA، وبقي البرتقالي الفاتح للرسوم والشارات الكبيرة.

لا تحمّل اللون وحده المعنى. المعيار 1.4.1 في WCAG يطلب ألا يكون اللون الوسيلة الوحيدة لنقل معلومة، لأن بعض المستخدمين لا يميزون بين الأحمر والأخضر، وبعضهم يستخدم الهاتف في وضع توفير الطاقة أو تحت إضاءة قوية. رسالة الخطأ تحتاج أيقونة ونصاً بجانب اللون الأحمر، والرسم البياني يحتاج تسميات أو أنماطاً مختلفة للخطوط، والرابط داخل الفقرة يحتاج خطاً تحته أو تمييزاً آخر غير اللون.

اجعل الفحص جزءاً من بناء اللوحة: أنشئ في صفحة المكونات جدولاً صغيراً لكل زوج نص وخلفية تستخدمه فعلاً، واكتب بجانبه النسبة ونتيجة AA. هذا الجدول يمنع المفاجأة المعتادة في نهاية المشروع، حين يتبين أن لون النص الثانوي المستخدم في عشرين شاشة لا يجتاز المعيار.

• ابنِ اللوحة بالأدوار: أساسي، ومحايد، وحالات، وسمِّ الألوان بوظيفتها.
• مستوى AA يطلب 4.5:1 للنص العادي و3:1 للنص الكبير وعناصر الواجهة.
• عندما يفشل لون العلامة مع النص، استخدم درجة أغمق من العائلة نفسها.
• اللون وحده لا يكفي لنقل المعنى؛ أضف أيقونة أو نصاً.

للاستزادة: W3C: فهم المعيار 1.4.3 — الحد الأدنى للتباين · W3C: فهم المعيار 1.4.11 — تباين العناصر غير النصية · W3C: فهم المعيار 1.4.1 — استخدام اللون · WebAIM: أداة فحص التباين

4. الخطوط — هرمية وقراءة

الهدف: تختار خطاً عربياً ومرافقاً لاتينياً متناسقاً، وتبني سلّم أحجام ومسافات أسطر يناسب طبيعة الحروف العربية.

معظم ما يفعله المستخدم في أي تطبيق قراءة: عناوين وأسعار وتعليمات ورسائل خطأ. والكتابة العربية لها خصائص تفرض قرارات طباعية مختلفة عن اللاتينية. الحروف متصلة، ويتغير شكل الحرف بحسب موضعه في الكلمة، والنقاط والتشكيل والامتدادات فوق السطر وتحته أعمق من نظيراتها اللاتينية، ولا توجد حروف كبيرة وصغيرة. وثيقة W3C الخاصة بمتطلبات تخطيط النص العربي والفارسي (ALReq) تجمع هذه الخصائص، وهي مرجع جيد حين تحتاج إلى سبب مكتوب لقرار طباعي.

تنقسم الخطوط العربية الرقمية إلى عائلتين يكثر استخدامهما في الواجهات. خطوط النسخ (Naskh) مستوحاة من الخط اليدوي المستخدم في الكتب، ومريحة للنصوص الطويلة، مثل Noto Naskh Arabic وAmiri. والخطوط الهندسية المستوحاة من الكوفي أو المصممة للشاشات، مثل Cairo وTajawal وNoto Kufi Arabic وIBM Plex Sans Arabic، وتناسب العناوين والأزرار والتسميات القصيرة. هذا ميل عام لا قاعدة صارمة، والحكم النهائي لاختبار القراءة على الشاشة الحقيقية.

في اقتران الخطوط (Font pairing) ابحث أولاً عن عائلة عربية صُممت مع رفيق لاتيني: IBM Plex Sans Arabic مع IBM Plex Sans، وNoto Sans Arabic مع Noto Sans، أما Cairo فيتضمن حروفاً لاتينية داخل الملف نفسه. فائدة ذلك أن الأوزان والسماكات متقاربة، فلا تبدو الكلمة الإنجليزية داخل الجملة العربية غريبة. وتلاحظ إرشادات Apple أن النص العربي قد يبدو أصغر من نص لاتيني بحروف كبيرة بالحجم نفسه، وتقترح زيادة حجم العربي بنحو نقطتين لموازنة الشكل.

مقارنة بين إعدادين لصفحة مقال في تطبيق أخبار متخيَّل:
الإعداد (أ): خط نسخ بحجم 14 بكسل، ومسافة سطر 1.2، وتباعد حروف 1 بكسل بحثاً عن الأناقة، وعناوين مائلة اصطناعياً.
الإعداد (ب): Noto Naskh Arabic بحجم 18 للفقرات ومسافة سطر 1.7، وNoto Kufi Arabic للعناوين بوزن عريض، وتباعد حروف صفر، والتمييز بالوزن واللون.
عند تجربة الإعدادين على هاتف: في (أ) تقترب نقاط سطر من امتدادات السطر الذي تحته، وتتقطع الحروف المتصلة، ويتشوه الحرف المائل. في (ب) تُقرأ الفقرة دون تقريب الشاشة.

لماذا تباعد الحروف صفر؟ لأن الحروف العربية متصلة، وأي تباعد بينها يقطع الاتصال ويجعل الكلمة تبدو مكسورة، وهذا ما تنبّه إليه صفحة الخاصية letter-spacing في MDN تحت قسم اعتبارات التدويل. وللسبب نفسه لا تمد الكلمات يدوياً بحرف التطويل (الكشيدة) مثل «مـــرحبا»، لأن الكلمة الممدودة لا تطابق البحث ولا النسخ. وعلى الشاشات الضيقة تُفضَّل المحاذاة لليمين بلا ضبط كامل، لأن الضبط الكامل يوسع المسافات بين الكلمات بشكل غير منتظم.

ابنِ سلّماً ثابتاً من أربعة أو خمسة مستويات واحفظ كلاً منها نمط نص (Text style) في Figma: عنوان رئيسي نحو 28 بكسل عريض، وعنوان قسم نحو 22، ونص أساسي 16 إلى 18، ونص صغير 13 أو 14 للتواريخ والتلميحات. ووحّد شكل الأرقام في الشاشة كلها؛ الأرقام الغربية (123) والمشرقية (١٢٣) كلتاهما مستخدمة في العالم العربي ويختلف انتشارهما بين البلدان، فاختر ما يناسب جمهورك والتزم به. ولا تعكس ترتيب الأرقام داخل العدد الواحد أبداً، فالعدد 541 يُكتب بالترتيب نفسه في كل اتجاه.

قائمة مراجعة قبل اعتماد نظام الخطوط:
• خط عربي واحد بعدة أوزان، ورفيق لاتيني من العائلة نفسها إن أمكن.
• مسافة سطر للفقرات بين 1.5 و1.8 تُجرَّب على الهاتف، وأقل قليلاً للعناوين.
• تباعد حروف صفر لكل نص عربي، ولا مائل اصطناعي ولا كشيدة يدوية.
• شكل أرقام واحد في الشاشة كلها.
• جملة اختبار تخلط عربياً ولاتينياً وأرقاماً، مثل «ادفع 250 جنيهاً عبر Visa»، تُراجع في كل نمط نص.

• النسخ للنصوص الطويلة غالباً، والخطوط الهندسية للعناوين والتسميات.
• اختر عائلة عربية لها رفيق لاتيني لتتقارب الأوزان والسماكات.
• العربية تحتاج مسافة أسطر أكبر وتباعد حروف صفراً.
• شكل أرقام واحد في الشاشة، ولا يُعكس ترتيب الأرقام داخل العدد.

للاستزادة: W3C: متطلبات تخطيط النص العربي والفارسي · MDN: الخاصية letter-spacing واعتبارات العربية · Apple HIG: موازنة النص العربي والأرقام · Figma: إنشاء أنماط النص وتطبيقها

5. Wireframes — هيكل بلا زينة

الهدف: ترسم مسار مستخدم وwireframes لثلاث شاشات، وتطبّق قواعد عكس الاتجاه RTL منذ مرحلة الهيكل.

قبل رسم أي شاشة يحتاج المصمم إلى معرفة الطريق الذي سيسلكه المستخدم. هذا الطريق يسمى مسار المستخدم (User flow): سلسلة خطوات من نقطة الدخول حتى تحقيق الهدف، مع نقاط القرار والمسارات البديلة. والرسم الهيكلي لكل محطة فيه يسمى Wireframe: رسم بالأبيض والرمادي يحدد أماكن العناصر وترتيبها وحجمها النسبي، بلا ألوان نهائية ولا صور حقيقية. الرمادي مقصود، لأنه يُبعد النقاش عن الذوق ويركزه على سؤالين: هل الترتيب منطقي؟ وهل الإجراء في مكانه؟

حالة متخيَّلة — حجز موعد في عيادة أسنان بطنطا:
المسار الأساسي: فتح التطبيق ← اختيار الخدمة ← اختيار الطبيب ← اختيار اليوم والساعة ← إدخال الاسم والهاتف ← تأكيد الحجز.
المسار البديل الأول: لا توجد مواعيد في اليوم المختار، فتظهر رسالة «لا مواعيد يوم الخميس» مع زر «أقرب موعد متاح: السبت 11 صباحاً».
المسار البديل الثاني: رقم الهاتف ناقص، فتظهر رسالة تحت الحقل نفسه دون مسح بقية البيانات.
المسار البديل الثالث: انقطع الإنترنت بعد الضغط على «تأكيد»، فتظهر رسالة توضح هل سُجّل الحجز أم لا، مع زر لإعادة المحاولة.

المسارات البديلة هي ما يُنسى عادة، وهي مصدر معظم الارتباك في التطبيقات الحقيقية. لذلك ارسم المسار صناديق وأسهماً قبل أي شاشة، وضع علامة على كل نقطة قرار. واكتب في الـ Wireframe نصاً عربياً حقيقياً بدلاً من Lorem ipsum، لأن النص اللاتيني الوهمي لا يكشف أطوال الجمل العربية، ولا التفاف الأسطر، ولا المحاذاة لليمين. كلمة «تأكيد الحجز» قد تتسع في زر صممته لكلمة Book، وقد لا تتسع.

عكس الاتجاه يُحسم في مرحلة الهيكل. الواجهة العربية لا تُصنع بعكس واجهة إنجليزية كما في المرآة؛ هناك عناصر تنعكس وعناصر تبقى كما هي، وقواعدها موثقة في إرشادات Apple لاتجاه RTL وفي صفحة ثنائية الاتجاه في Material Design 3. القاعدة التي تجمعها: ما يرتبط باتجاه القراءة أو بالترتيب ينعكس، وما يمثل شيئاً من العالم الحقيقي أو اتجاهاً فعلياً يبقى.

ما ينعكس في الواجهة العربية:
• ترتيب التخطيط: الشعار والعنوان يميناً، والإجراءات الثانوية يساراً، والقائمة الجانبية تنزلق من اليمين.
• أسهم التنقل: الرجوع يشير لليمين، و«التالي» يشير لليسار، وأسهم الدخول في عناصر القوائم تشير لليسار.
• ما يعبّر عن تقدم أو ترتيب: شريط التقدم يمتلئ من اليمين، والمنزلق (Slider) يبدأ من اليمين، ومؤشر الخطوات يبدأ بالخطوة الأولى يميناً.
• الأيقونات التي تمثل نصاً أو حركة إلى الأمام، مثل أيقونة محاذاة الفقرة، ومكبر الصوت الذي تخرج منه الموجات.

ما لا ينعكس:
• الشعارات والعلامات العالمية مثل علامة الصح.
• أزرار تشغيل الوسائط، فالتشغيل والتقديم السريع تشير لليمين في كل اللغات لأنها تصف اتجاه شريط التشغيل.
• أيقونات الأشياء الواقعية كالساعة والكاميرا، والصور الفوتوغرافية والرسوم التوضيحية.
• الأرقام داخل العدد الواحد، مثل رقم الطلب 4512 أو رقم الهاتف أو رقم البطاقة.
• ما يشير إلى اتجاه فعلي، مثل سهم «انعطف يميناً» في تطبيق خرائط.

خطأ شائع يتكرر في الفرق الصغيرة: تصميم الشاشات بالإنجليزية ثم قلب الإطار كله بأمر Flip horizontal. النتيجة نصوص معكوسة كالمرآة، وشعار مقلوب، وزر تشغيل يشير للخلف. الطريقة الصحيحة أن تبني الهيكل من اليمين منذ البداية، ثم تمر على القائمتين السابقتين عنصراً عنصراً. وانتبه أيضاً للجمل المختلطة الاتجاه، مثل «تم شحن طلبك AX-93 اليوم»؛ ضعها في الـ Wireframe كما ستظهر فعلاً، لأن المبرمج قد يحتاج إلى وسوم مثل bdi أو الخاصية dir لعرضها بترتيب سليم.

• ارسم المسار بصناديق وأسهم، ومعه المسارات البديلة، قبل أي شاشة.
• استخدم نصاً عربياً حقيقياً في الـ Wireframe بدل Lorem ipsum.
• ما يرتبط باتجاه القراءة أو الترتيب ينعكس، وما يمثل شيئاً واقعياً يبقى.
• لا تقلب إطاراً إنجليزياً كالمرآة؛ ابنِ الهيكل من اليمين منذ البداية.

للاستزادة: Material Design 3: ثنائية الاتجاه وRTL · Apple HIG: ما ينعكس وما لا ينعكس · W3C: النص ثنائي الاتجاه داخل الأسطر في HTML · NN/g: رحلة المستخدم ومسار المستخدم

6. المكونات — أزرار وبطاقات

الهدف: تبني مكتبة مكونات مصغرة في Figma بالـ Variants والخصائص والمتغيرات، مع حالات كاملة لكل مكوّن تفاعلي.

نظام التصميم (Design system) مجموعة معايير وعناصر قابلة لإعادة الاستخدام تجعل المنتج متسقاً مهما كبر الفريق أو كثرت الشاشات. تصف Nielsen Norman Group مكوناته الرئيسية: دليل أسلوب يحدد الألوان والخطوط والمسافات، ومكتبة مكونات جاهزة، وأنماط استخدام تشرح متى يُستخدم كل مكوّن. ملف Figma المليء بالأزرار لا يكفي وحده؛ القواعد المكتوبة جزء أساسي من النظام.

وحدة البناء في Figma هي المكوّن (Component). تحدد العناصر وتضغط Ctrl+Alt+K فيتحول التحديد إلى مكوّن رئيسي (Main component)، وكل نسخة تسحبها منه تسمى Instance. أي تعديل على المكوّن الرئيسي يصل إلى كل النسخ، إلا الخصائص التي عدّلتها يدوياً في نسخة معينة، وتسمى تجاوزات (Overrides). وتجمع الـ Variants أشكال المكوّن في مجموعة واحدة بخصائص مثل النوع (أساسي، ثانوي، نصي) والحالة. وتضيف خصائص المكوّن (Component properties) تحكماً أدق: خاصية نصية لتغيير التسمية، وخاصية منطقية لإظهار الأيقونة أو إخفائها، وخاصية تبديل نسخة (Instance swap) لاختيار الأيقونة.

أما المتغيرات (Variables) فتخزن القيم المتكررة: ألوان وأرقام ونصوص وقيم منطقية، ويمكن أن يكون لكل متغير أكثر من وضع (Mode)، مثل فاتح وداكن. سمِّها بأسماء دلالية مثل color/bg/surface وspace/16 وradius/12، ثم اربط بها المكونات، فيصبح تغيير لون العلامة أو إضافة وضع داكن تعديلاً في مكان واحد بدلاً من مطاردة اللون في عشرات الشاشات.

لكل مكوّن تفاعلي حالات يجب أن تُصمَّم قبل استخدامه: عادي، ومضغوط، وتركيز يظهر بإطار واضح لمن يتنقل بلوحة المفاتيح، ومعطّل، وتحميل يمنع الضغط المزدوج على زر «ادفع». تنبه إرشادات Apple إلى أن الزر المخصص بلا حالة ضغط يبدو كأنه لا يستجيب. وإذا لم تصمم هذه الحالات، سيخترعها المبرمج بنفسه، وتخرج كل شاشة بأسلوب مختلف.

سجل ثلاثة أيام لفريق طلابي متخيَّل يصمم تطبيق «مكتبة الكلية»:
اليوم الأول: رسم كل عضو أزراره بنفسه، فظهرت ثلاث قيم مختلفة لاستدارة الزوايا (8 و10 و16) وأربع درجات من الأزرق.
اليوم الثاني: جرد الفريق العناصر المتكررة فوجد أربعة: زر، وحقل إدخال، وبطاقة كتاب، وشريط تنقل سفلي. أنشأ متغيرات للألوان والمسافات والزوايا، ثم مكوّن زر بخاصيتي النوع والحالة.
اليوم الثالث: استبدل الفريق الأزرار القديمة بنسخ من المكوّن، وصار تغيير لون العلامة يتم في متغير واحد يظهر أثره في كل الشاشات.
الحصيلة: قيمة واحدة للزوايا وخمس درجات لونية بدل الفوضى، واختفى نقاش «أي أزرق نستخدم؟» من المراجعات.

حقل الإدخال مثال جيد على مكوّن مركّب. تشريحه: تسمية فوق الحقل، والحقل نفسه، ونص مساعد اختياري تحته، ومكان مخصص لرسالة الخطأ، وأيقونة اختيارية. في الواجهة العربية فكّر في المواضع بمنطق البداية والنهاية لا اليسار واليمين: أيقونة البحث في بداية الحقل، أي يميناً في العربية، وزر المسح في نهايته. هذا المنطق نفسه هو ما تستخدمه خصائص CSS المنطقية لاحقاً عند البرمجة، فيسهل نقل التصميم إلى الاتجاهين.

متى تحوّل عنصراً إلى مكوّن؟ قاعدة عملية: إذا تكرر في أكثر من شاشة، أو كانت له حالات تفاعلية، أو كان يجب أن يتطابق شكله في كل مكان. أما الرسم التوضيحي الذي يظهر مرة واحدة في شاشة الترحيب، فتحويله إلى مكوّن يضيف تعقيداً بلا فائدة. وأرفق بكل مكوّن ملاحظة قصيرة في صفحة المكونات: متى يُستخدم، ومتى لا يُستخدم، وما أقصى طول مقبول لنصه.

• نظام التصميم مكونات وقواعد استخدام مكتوبة، لا ملف أزرار فقط.
• تعديل المكوّن الرئيسي يصل إلى كل النسخ إلا التجاوزات اليدوية.
• المتغيرات بأسماء دلالية تجعل تغيير الهوية أو إضافة وضع داكن تعديلاً واحداً.
• صمّم حالات الضغط والتركيز والتعطيل والتحميل قبل استخدام المكوّن.

للاستزادة: Figma: دليل المكونات · Figma: إنشاء الـ Variants واستخدامها · Figma: دليل المتغيرات · NN/g: مدخل إلى أنظمة التصميم

7. Mobile-first — الهاتف أولاً

الهدف: تصمّم للهاتف أولاً بشبكة أعمدة وسلّم مسافات وأهداف لمس مريحة، ثم توسّع للتابلت وسطح المكتب.

نهج Mobile-first يعني أن تبدأ بالشاشة الصغيرة لأنها تجبرك على تحديد الأهم، ثم تتوسع إلى التابلت والحاسوب بإضافة مساحة وتفاصيل. تنبه Nielsen Norman Group في مقال بعنوان «Mobile First Is NOT Mobile Only» إلى أن البدء بالهاتف لا يعني حرمان مستخدم الحاسوب من المحتوى؛ الفكرة ترتيب الأولويات، والنسخة الكبيرة تستحق تصميماً مدروساً هي الأخرى.

شبكة التخطيط (Layout grid) أعمدة غير مرئية تنظم عرض العناصر. إعدادات شائعة للبداية: هاتف بعرض 360 إلى 393 بأربعة أعمدة وهوامش جانبية 16 وفاصل 16، وتابلت بعرض نحو 768 بثمانية أعمدة وهوامش 24 إلى 32، وحاسوب بعرض 1280 إلى 1440 باثني عشر عموداً مع عرض أقصى للمحتوى حتى لا تطول الأسطر. تُضاف الشبكة في Figma من إعدادات الإطار. وفي الواجهة العربية يبدأ المحتوى من العمود الأول على اليمين، فالعنصر الذي يمتد عمودين يبدأ من الحافة اليمنى.

سلّم المسافات (Spacing scale) يمنع القيم العشوائية مثل 13 و17 و22. اختر قيماً من مضاعفات 4 أو 8، مثل 4 و8 و12 و16 و24 و32 و48، وهو أسلوب تعتمده Material Design أيضاً. وطبّق مبدأ التقارب: المسافة داخل المجموعة أصغر من المسافة بينها وبين المجموعة التالية، فتفهم العين أن صورة المنتج واسمه وسعره وحدة واحدة.

أهداف اللمس (Touch targets) هي المساحة التي تستجيب للإصبع، وقد تكون أكبر من الشكل المرئي. توصي إرشادات Apple بمنطقة ضغط لا تقل عن 44 × 44 نقطة، وتوصي Material Design بـ 48 × 48 وحدة مستقلة الكثافة (dp). أما WCAG 2.2 فيطلب في المعيار 2.5.8 بمستوى AA ألا يقل الهدف عن 24 × 24 بكسل أو أن تحيط به مسافة كافية عن الأهداف المجاورة، ويرفع المعيار 2.5.5 بمستوى AAA الحد إلى 44 × 44. الخلاصة العملية: أيقونة مرئية بحجم 24 داخل منطقة ضغط 44 أو 48، مع فاصل لا يقل عن 8 بين الأهداف المتجاورة.

كثير من الناس يمسكون الهاتف بيد واحدة ويضغطون بالإبهام، فالمنطقة السفلية الوسطى أسهل وصولاً من الزوايا العلوية. ضع الإجراء الأساسي والتنقل الرئيسي في الأسفل، وأبعد الإجراءات الخطرة، مثل «حذف الحساب»، عن الأماكن التي يُضغط فيها كثيراً.

مراجعة شاشة منتجات لمتجر ملابس متخيَّل على هاتف بعرض 360:
1) الملاحظة: أيقونة «المفضلة» بحجم 18 بلا حشوة، وملاصقة لزر «أضف للسلة». الإصلاح: منطقة ضغط 48 × 48 حول الأيقونة، وفاصل 8 عن الزر.
2) الملاحظة: المسافات 13 و17 و22 بلا نمط. الإصلاح: 8 داخل البطاقة، و16 بين البطاقات، و24 بين الأقسام.
3) الملاحظة: زر الفلترة في الزاوية العلوية بعيد عن الإبهام. الإصلاح: شريط ثابت في الأسفل فيه «فلترة» و«ترتيب».
4) الملاحظة: صور المنتجات بلا نسبة أبعاد ثابتة، فتقفز الشبكة أثناء التحميل. الإصلاح: نسبة 3:4 ثابتة لكل صورة.
5) الملاحظة: الأسعار بحجم 12. الإصلاح: 16 بوزن متوسط وبلون النص الأساسي.

عند التوسع اسأل: ماذا نضيف بالمساحة الجديدة؟ في المثال نفسه تعرض شاشة الهاتف بطاقتين في الصف، كل بطاقة تمتد عمودين من أربعة، وتعرض شاشة التابلت ثلاث بطاقات، ويعرض الحاسوب أربع بطاقات مع عمود فلاتر جانبي ثابت على اليمين بسبب اتجاه القراءة. المحتوى نفسه في الحالات الثلاث، والتغيير في الترتيب والكثافة وموضع الأدوات.

• ابدأ بالهاتف لترتيب الأولويات، وصمّم نسخة الحاسوب بعناية أيضاً.
• استخدم شبكة أعمدة وسلّم مسافات من مضاعفات 4 أو 8.
• منطقة الضغط 44 نقطة في Apple و48 dp في Material، والحد الأدنى في WCAG AA هو 24 بكسل.
• ضع الإجراء الأساسي في متناول الإبهام وأبعد الإجراءات الخطرة.

 هاتف 360–393: 4 أعمدة، هامش 16
 تابلت ~768: 8 أعمدة
 حاسوب 1280–1440: 12 عموداً

 أيقونة 24 داخل منطقة ضغط 48
 مسافات: 4 · 8 · 16 · 24 · 32

للاستزادة: NN/g: الهاتف أولاً لا يعني الهاتف فقط · W3C: فهم المعيار 2.5.8 — الحد الأدنى لحجم الهدف · Material Design 3: الشبكات والمسافات · Apple HIG: منطقة الضغط 44 × 44 نقطة

8. إتاحة الوصول — للجميع

الهدف: تصمّم نماذج ورسائل خطأ واضحة، وتطبّق متطلبات WCAG الأساسية، وتجهّز الواجهة العربية لقارئ الشاشة.

إتاحة الوصول (Accessibility، وتُختصر a11y) تعني أن يستطيع أكبر عدد من الناس استخدام المنتج: ضعاف البصر، ومستخدمو قارئ الشاشة، ومن يعاني رعشة في اليد، وكبار السن، ومن يستخدم الهاتف بيد واحدة في مواصلات مزدحمة. المرجع المعتمد هو إرشادات WCAG 2.2 الصادرة عن W3C، وتقوم على أربعة مبادئ: أن يكون المحتوى قابلاً للإدراك، وقابلاً للتشغيل، ومفهوماً، ومتيناً يعمل مع التقنيات المساعدة. والمستوى AA هو الهدف الشائع للمواقع والتطبيقات. درسا الألوان والهاتف أولاً غطيا التباين وحجم الأهداف، وهذا الدرس يركز على النماذج والرسائل والقراءة الآلية.

النماذج (Forms) أكثر مكان يتعثر فيه المستخدمون. يطلب المعيار 3.3.2 تسميات أو تعليمات واضحة لكل حقل يحتاج إدخالاً، لذا ضع تسمية ظاهرة فوق الحقل دائماً. النص التوضيحي داخل الحقل (Placeholder) يختفي عند بدء الكتابة، فينسى المستخدم ما المطلوب، وتعدّه Nielsen Norman Group ضاراً حين يحل محل التسمية. اكتب «(مطلوب)» أو «(اختياري)» نصاً صريحاً بدلاً من الاعتماد على نجمة حمراء، واجمع الحقول المترابطة معاً، واختر لوحة المفاتيح المناسبة: حقل الهاتف يفتح لوحة أرقام.

وفي البيئة العربية مشكلة تتكرر كثيراً: مستخدم يكتب رقم هاتفه بالأرقام المشرقية «٠١٠...» فيرفضه النموذج لأنه يتوقع 0 إلى 9 فقط. الحل أن يقبل النظام الشكلين ويحوّلهما إلى صيغة واحدة قبل الحفظ، وأن تُصمَّم رسالة الخطأ على هذا الأساس، لا أن يُطلب من المستخدم تغيير لوحة مفاتيحه.

رسائل الخطأ يحكمها معياران: 3.3.1 يطلب تحديد الحقل الخاطئ ووصف الخطأ نصاً، و3.3.3 يطلب اقتراح طريقة التصحيح متى كانت معروفة. وتضيف إرشادات NN/g لرسائل الخطأ: ضع الرسالة قرب موضع المشكلة، واكتبها بلغة مهذبة لا تلوم المستخدم، واحتفظ بما كتبه. وأفضل توقيت للتحقق بعد خروج المستخدم من الحقل، لا مع كل حرف يكتبه، وفي النماذج الطويلة اعرض ملخصاً بالأخطاء في الأعلى مع روابط إلى كل حقل.

قبل وبعد — رسائل نموذج تسجيل في منصة دروس متخيَّلة:
قبل: «خطأ في الإدخال». بعد: «رقم الهاتف ناقص: اكتب 11 رقماً تبدأ بـ 01».
قبل: «البريد غير صالح». بعد: «ينقص البريد علامة @، مثل name@example.com».
قبل: حقل يتلون بالأحمر فقط. بعد: أيقونة تحذير ونص الخطأ تحت الحقل مع حد أحمر أسمك.
قبل: مسح كل الحقول بعد خطأ واحد. بعد: الاحتفاظ بالبيانات ونقل التركيز إلى أول حقل خاطئ.
قبل: «كلمة المرور ضعيفة» بعد الإرسال. بعد: الشروط ظاهرة مسبقاً تحت الحقل، مثل «8 أحرف على الأقل منها رقم»، وتُعلَّم كل واحدة عند تحققها.

قارئ الشاشة يحتاج إلى معلومات لا تُرى. يجب أن تُعلن لغة الصفحة واتجاهها بالخاصيتين lang="ar" وdir="rtl" على عنصر html، حتى ينطق القارئ النص بصوت عربي صحيح ويعرض المتصفح الاتجاه السليم، وتوضح مقالات W3C للتدويل لماذا يُضبط الاتجاه في البنية لا بالتنسيق وحده. والمقاطع الإنجليزية داخل الصفحة تُعلَّم بلغتها. ويحتاج كل زر أيقونة اسماً مسموعاً بالعربية مثل «إغلاق» أو «إضافة إلى المفضلة»، وكل صورة تحمل معلومة نصاً بديلاً. ويسير ترتيب التركيز من اليمين إلى اليسار ومن الأعلى إلى الأسفل، ويجب أن يبقى المحتوى مقروءاً عند تكبير النص إلى 200٪ بحسب المعيار 1.4.4.

اختم كل شاشة بمراجعة سريعة: تسمية ظاهرة لكل حقل، ورسالة خطأ تشرح الإصلاح، وألا يكون اللون وحده حامل المعنى، وأسماء مسموعة لأزرار الأيقونات، ولغة الصفحة واتجاهها مضبوطان. ثم شغّل TalkBack على أندرويد أو VoiceOver على iPhone خمس دقائق مع تطبيق حقيقي، وستفهم سريعاً لماذا تهم هذه البنود.

• تسمية ظاهرة فوق كل حقل، والنص التوضيحي داخل الحقل لا يكفي وحده.
• رسالة الخطأ تحدد الحقل وتشرح الإصلاح وتحتفظ بما كتبه المستخدم.
• اقبل الأرقام المشرقية والغربية وحوّلها إلى صيغة واحدة.
• اضبط lang وdir للصفحة، وأعطِ كل زر أيقونة اسماً مسموعاً.

 تسمية ظاهرة
 [ حقل الهاتف        ]
 ⚠ رقم ناقص: اكتب 11 رقماً تبدأ بـ 01

 lang=ar  +  dir=rtl
 ترتيب التركيز: يمين ← يسار

للاستزادة: W3C: فهم المعيار 3.3.3 — اقتراح تصحيح الخطأ · W3C: فهم المعيار 3.3.2 — التسميات والتعليمات · W3C WAI: دليل النماذج سهلة الوصول · NN/g: إرشادات رسائل الخطأ · W3C i18n: البنية والنص من اليمين إلى اليسار في HTML

9. النماذج التفاعلية — اربط الشاشات

الهدف: تربط الشاشات في نموذج تفاعلي، وتدير اختبار قابلية استخدام بميزانية صغيرة، وتحوّل الملاحظات إلى أولويات.

النموذج التفاعلي (Prototype) محاكاة للتطبيق: تضغط الزر فتنتقل إلى الشاشة التالية كأن التطبيق مبرمج. قيمته أنه يتيح اختبار الفكرة مع أشخاص حقيقيين قبل كتابة سطر برمجي واحد، حين يكون التعديل رخيصاً. في Figma تنتقل إلى تبويب Prototype، وتحدد الزر وتسحب الدائرة التي تظهر بجانبه إلى الشاشة الهدف، وتختار الحدث (On tap) والإجراء (Navigate to) ونوع الانتقال مثل Instant أو Smart animate، ثم تحدد شاشة البداية وتضغط Present، أو تفتح النموذج على هاتفك عبر تطبيق Figma.

قبل الاختبار، ابدأ ببحث صغير يكاد لا يكلف شيئاً: مقابلات قصيرة مع خمسة أشخاص من الفئة المستهدفة، كل منها ربع ساعة. السؤال المفيد يدور حول سلوك حدث فعلاً، مثل «احكِ عن آخر مرة حجزت فيها ملعباً، ماذا فعلت خطوة بخطوة؟». أما «هل ستستخدم تطبيقاً كهذا؟» فإجابته مجاملة في الغالب، لأن الناس لا يتنبؤون بسلوكهم المستقبلي بدقة. وتفصّل Nielsen Norman Group في دليل المقابلات طرق صياغة الأسئلة المفتوحة وتجنب الأسئلة الموجِّهة.

كم مشاركاً تحتاج؟ في مقال شهير يوضح Jakob Nielsen أن خمسة مستخدمين يكشفون نحو 85٪ من مشكلات قابلية الاستخدام في اختبار نوعي، وأن ثلاث جولات بخمسة مشاركين، مع تعديل التصميم بعد كل جولة، أنفع من جولة واحدة بخمسة عشر. تنطبق هذه القاعدة على مستخدمين متشابهين؛ فإذا كان للتطبيق فئتان مختلفتان، كالطلاب والمدرسين، فاختبر كل فئة بمجموعة صغيرة خاصة بها.

التجنيد بميزانية صغيرة ممكن: معارف المعارف ممن يشبهون المستخدم الحقيقي، أو طلاب في جامعتك، أو جلسات قصيرة من عشر دقائق في مقهى مع مشروب على حسابك، أو جلسات عن بعد عبر مكالمة فيديو مع مشاركة الشاشة. اشرح لكل مشارك ما الذي سيُسجَّل، وأن له حق التوقف في أي لحظة، واطلب موافقة ولي الأمر إذا كان المشارك قاصراً.

نص جلسة جاهز لمدة 15 دقيقة:
1) ترحيب: «نختبر التصميم لا نختبرك، وأي صعوبة تواجهها تساعدنا على تحسينه».
2) اطلب التفكير بصوت عالٍ: «قل ما تبحث عنه وما تتوقع أن يحدث قبل أن تضغط».
3) أعطِ مهمة واقعية بلا تلميح: «احجز ملعباً خماسياً يوم الجمعة بعد العصر بأقل سعر».
4) راقب ولا تساعد؛ إن سأل المشارك «أضغط هنا؟» فأعد السؤال إليه: «ماذا تتوقع أن يحدث؟».
5) سجّل: هل أنجز المهمة؟ كم استغرق؟ أين تردد أو تراجع؟
6) ختام: «ما أصعب جزء؟ وماذا توقعت أن تجد ولم تجده؟».

سجل جولة متخيَّلة لتطبيق حجز ملاعب (خمسة مشاركين):
• م1: بحث عن السعر قبل اختيار الساعة، ولم يجده حتى شاشة التأكيد.
• م2: أنجز المهمة، لكنه ضغط أيقونة الفلترة ظناً أنها للترتيب.
• م3: بحث عن السعر أيضاً، ثم تراجع خطوتين.
• م4: لم يفهم أن الأوقات الرمادية محجوزة، وحاول الضغط عليها مرتين.
• م5: بحث عن السعر، وأنجز المهمة في ضعف وقت الآخرين تقريباً.

حوّل السجل إلى أولويات بمقياس شدة المشكلات الذي اقترحه Nielsen، من 0 (ليست مشكلة) إلى 4 (كارثة يجب إصلاحها قبل الإطلاق)، مع مراعاة تكرار المشكلة وأثرها وهل تتكرر مع المستخدم نفسه. إخفاء السعر ظهر عند ثلاثة من خمسة وأبطأ المهمة، فيستحق 3، والإصلاح عرض سعر الساعة بجانب كل موعد. والأوقات الرمادية تستحق 2، والإصلاح كتابة «محجوز» عليها. وأيقونة الفلترة 1 مؤقتاً. أصلح الأعلى شدة أولاً، ثم أعد الاختبار مع خمسة أشخاص جدد، فقد تكشف الجولة الثانية مشكلات كانت مختبئة خلف الأولى.

• النموذج التفاعلي يكشف مشكلات التدفق قبل أي سطر برمجي.
• اسأل في المقابلات عن سلوك حدث فعلاً، لا عن توقعات مستقبلية.
• خمسة مشاركين لكل جولة، وثلاث جولات قصيرة أنفع من جولة كبيرة.
• رتّب الملاحظات بمقياس شدة من 0 إلى 4 وأصلح الأخطر أولاً.

للاستزادة: Figma: دليل النماذج التفاعلية · NN/g: لماذا يكفي اختبار خمسة مستخدمين · NN/g: التفكير بصوت عالٍ في الاختبار · NN/g: مقياس شدة مشكلات قابلية الاستخدام · NN/g: مدخل إلى مقابلات المستخدمين

10. المشروع النهائي — نموذج أولي كامل

الهدف: تسلّم حزمة تصميم كاملة: مسار وwireframes ونظام مصغّر وتصميم نهائي ونموذج تفاعلي ونتائج اختبار، جاهزة للتسليم إلى مبرمج.

المشروع النهائي يجمع مهارات المسار في حزمة واحدة تعرضها في محفظة أعمالك أو تسلمها لمبرمج. من يراجع الحزمة، سواء كان صاحب عمل يبحث عن مصمم أو مبرمجاً سينفذها، يبحث عن وضوح التفكير خلفها: لماذا صُمم كل جزء بهذا الشكل؟ وما الذي كشفه الاختبار؟ وما الذي تغير بسببه؟ لذلك تحتاج كل شاشة نهائية إلى أثر مكتوب يربطها بالمشكلة أو بملاحظة من مستخدم.

محتويات الحزمة:
1) صفحة المشكلة: المستخدم المستهدف ومهمته في جملتين.
2) مسار المستخدم: خمس إلى سبع خطوات مع مسارين بديلين على الأقل.
3) Wireframes لثلاث شاشات بنص عربي حقيقي.
4) نظام مصغّر: متغيرات الألوان مع نسب تباينها، وأنماط النصوص، والمكونات بحالاتها.
5) التصميم النهائي للهاتف ونسخة لمقاس ثانٍ.
6) نموذج تفاعلي يربط ثلاث شاشات أو أكثر.
7) نتائج الاختبار: جدول ملاحظات بمقياس الشدة، وإصلاح منفذ مع لقطتي قبل وبعد.
8) قائمة مراجعة RTL والإتاحة: ما طُبّق وما بقي.

قيّم الحزمة بنفسك قبل تسليمها بسلّم بسيط: امنح كل بند من البنود التالية درجة من 0 إلى 2. وضوح جملة المشكلة. تغطية المسار للحالات البديلة. اجتياز الشاشة الرئيسية اختبار التحديق. توثيق نسب التباين لكل أزواج النص والخلفية. ألا تقل مناطق الضغط عن 44 نقطة. مراجعة العناصر الاتجاهية عنصراً عنصراً. اكتمال حالات المكونات. وجود دليل من اختبار حقيقي. المجموع من 16؛ إذا حصلت على أقل من 12 فارجع إلى أضعف بندين قبل التسليم.

مرحلة التسليم للمبرمج (Handoff) تحدد هل يخرج التطبيق مطابقاً للتصميم. نظّم الملف في صفحات منفصلة: «تصميم نهائي» و«مكونات» و«أرشيف». واجعل أسماء المتغيرات قريبة من الأسماء التي سيستخدمها المبرمج في الكود، مثل color/text/primary. واكتب ملاحظات على الشاشات تشرح السلوك: ماذا يحدث عند الضغط؟ ما أقصى طول مسموح للاسم؟ وماذا يظهر عند انقطاع الاتصال؟ وجهّز الأيقونات بصيغة SVG. يستطيع المبرمج قراءة المقاسات والألوان من الملف مباشرة، ويوفر وضع Dev Mode في Figma أدوات فحص إضافية تعتمد إتاحتها على خطة الاشتراك.

ومن ملاحظات التسليم المهمة في المشاريع العربية أن تطلب من المبرمج استخدام خصائص CSS المنطقية، مثل margin-inline-start بدلاً من margin-left، وهي موثقة في MDN. هذه الخصائص تعتمد على بداية السطر ونهايته، فتنقلب المسافات تلقائياً مع اتجاه الصفحة، وتتطابق مع منطق البداية والنهاية الذي استخدمته في تصميم المكونات.

حالة متخيَّلة توضح شكل دراسة الحالة: مشروع «مكتبة المدرسة» لحجز الكتب من الهاتف. المشكلة: طلاب الصف الثاني الثانوي يريدون معرفة توفر الكتاب قبل الذهاب إلى المكتبة. المسار ست خطوات. في الجولة الأولى تجاهل ثلاثة من خمسة مشاركين حقل البحث لأنه كان في منتصف الشاشة بلون باهت، فنُقل إلى الأعلى بحد واضح وتسمية ظاهرة. في الجولة الثانية وصل الخمسة إلى الكتاب المطلوب دون مساعدة. هذه الجملة الأخيرة، مع لقطتي قبل وبعد، أقوى ما في المحفظة كلها.

خطأ شائع عند التسليم: ملف مزدحم بنسخ متعددة من الشاشة نفسها دون تحديد المعتمدة، فينفذ المبرمج النسخة الخطأ. ضع علامة «جاهز للتنفيذ» على الشاشات المعتمدة، وانقل ما سواها إلى صفحة الأرشيف. وعند العرض خصص خمس دقائق: دقيقة للمشكلة، ودقيقتين للمسار والنموذج، ودقيقة لما كشفه الاختبار، ودقيقة للخطوة التالية.

• الحزمة الكاملة بأسبابها أقوى من شاشة واحدة فاخرة.
• قيّم مشروعك بسلّم من ثمانية بنود قبل التسليم.
• وثّق السلوك والحالات الخاصة واستخدم أسماء متغيرات قريبة من الكود.
• الخصائص المنطقية في CSS تجعل الواجهة تعمل في الاتجاهين.

للاستزادة: Figma: دليل Dev Mode للتسليم · MDN: خصائص CSS المنطقية · NN/g: مبادئ قابلية الاستخدام العشرة للمراجعة النهائية