مبادئ تصميم تجربة المستخدم عملياً

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

1. التسلسل البصري يقود العين

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

2. المساحة البيضاء ليست فراغاً مهدوراً

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

3. أعطِ تغذية راجعة فورية

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

4. الاتساق يبني الثقة

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

5. صمّم لإمكانية الوصول (Accessibility)

التصميم المتاح للجميع أفضل للجميع، وليس فقط لذوي الاحتياجات:

• التباين: اجعل النص واضحاً على خلفيته (نسبة 4.5:1 على الأقل للنص العادي).
• أحجام لمس مريحة: الأزرار على الجوال لا تقلّ عن 44×44 بكسل.
• نصوص بديلة: أضِف alt وصفياً للصور.
• التنقّل بلوحة المفاتيح: تأكّد أنّ كل تفاعل ممكن دون فأرة، مع مؤشّر تركيز مرئي.

هذه المبادئ تصبح قابلة للمحاسبة عندما تتحوّل إلى أرقام في ملف الأنماط. في التطبيق الذي نتحدّث عنه لم نستخدم إلا ثلاث درجات للون النصّ، لكل واحدة وظيفة محدّدة: --text:#362028 للنصّ الأساسي، و--text-m:#6e434f للتسميات والعناوين الفرعية، و--text-s:#a87a85 للبيانات الثانوية. على خلفية الموقع الكريمية #fdf9f5 تعطي الأولى تبايناً يقارب 14:1 والثانية نحو 8:1 — وكلتاهما فوق الحدّ بمريح. أما الثالثة فتباينها نحو 3.5:1، أي أقلّ من 4.5:1، ولذلك قيّدناها بقاعدة صريحة: لا تُكتب بها أي معلومة يضرّ تفويتها — التواريخ والقيم والتحذيرات لا تنزل عن الدرجتين الأولى والثانية أبداً. الاعتراف بأنّ لوناً في هويتك لا يصلح لكل شيء أنفع من رفع نسبة التباين ورقياً ثم استعماله في كل مكان.

وفي مساحات اللمس: أزرار الأدوات الرئيسية (الإشعارات والمحفوظات وطرق الدخول البديلة) بُنيت 46×46 بكسل، وزرّ الإرسال 42×42، وهي فوق 44 أو عندها. أما ما اضطررنا لتصغيره — أزرار الإغلاق 34×34 وأزرار أيام منتقي التاريخ بارتفاع 34 — فالتزمنا فيه قاعدتين: أن يُحاط بمسافة فارغة كافية، وألّا يجاوره هدفٌ آخر قابل للمس يُصيبه الإصبع بالخطأ. القاعدة الحقيقية ليست «44 بكسل» وحدها، بل «هل يمكن للإصبع أن يُخطئ ويُصيب شيئاً ضارّاً؟».

وأهمّها عملياً: لا تنقل معلومة باللون وحده. عدّاد الموعد يحمل كلمة مع لونه (اليوم / قريباً / فائت)، وقائمة الأطعمة تجمع نقطة ملوّنة مع اسم مكتوب ووصف مكتوب، وقراءات الضغط والسكر تُرفق كلمة الحالة لا خلفية حمراء فقط، وصفّ الرفع المكتمل يُضيف علامة ✓ نصّية بجانب اخضراره، وخليّة الأسبوع الحالي تحمل شارة «أنتِ هنا» فوق إطارها الملوّن. أضف إلى ذلك أحد عشر موضعاً تحمل aria-label وصفياً للأزرار الأيقونية ومناطق التنقّل — فالزرّ الذي عليه رمز فقط لا وجود له عند قارئ الشاشة إلا بهذه التسمية.

6. قلّل الحِمل الإدراكي

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

7. الكلمات جزء من التصميم (UX Writing)

النصّ في الواجهة ليس حشواً، بل توجيه. زرّ مكتوب عليه «ابدأ الآن مجاناً» أوضح وأكثر إقناعاً من «إرسال». رسالة خطأ تقول «البريد الإلكتروني غير صحيح — تأكّد من وجود @» أنفع من «خطأ في الإدخال». اكتب بلغة المستخدم لا بلغة النظام، وكن محدّداً، وأخبره دائماً بما يفعله تالياً.

8. صمّم حالات الفراغ والخطأ

معظم المصمّمين يصمّمون «الحالة المثالية» فقط، وينسون اللحظات الأقل بريقاً — وهي الأكثر تأثيراً في الانطباع:

• الحالة الفارغة: أوّل مرة، حين لا توجد بيانات بعد — اجعلها ترحيبية وموجِّهة، لا شاشة بيضاء محبطة.
• حالة الخطأ: اشرح ما حدث وكيف يُصلَح، بنبرة هادئة لا لوم فيها.
• حالة التحميل: أرِ تقدّماً أو هيكلاً مؤقّتاً (skeleton) بدل فراغ يوحي بالتعطّل.

9. اختبر مع مستخدمين حقيقيين

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

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

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

وأضِف إلى الوصفة اختبار الأطراف: أطول نصّ وأقصره. عند تشغيل الواجهة بالإنجليزية خرجت تسميات أزرار الإجراءات السريعة من حدودها لأن النصّ الإنجليزي أطول من العربي، فلم يكن الحلّ تقصير الكلمات بل قاعدة نمطية للاتجاه الأيسر تُصغّر الخطّ إلى 11px وتسمح بالالتفاف بعد أن كان النصّ ممنوعاً من الالتفاف. القاعدة العامة: أي تصميم يفترض طولاً معيّناً للنصّ سينكسر عند أوّل ترجمة أو أوّل اسم مستخدم طويل.

ما فعلناه في تطبيق حقيقي: أربع بوّابات قبل أي نافذة بينية

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

• بوّابة زمنية (تبريد): مدّة إلزامية بين ظهورين، افتراضها خمس دقائق ويضبطها المدير بالدقائق من لوحة التحكّم، والكود يفرض حدّاً أدنى دقيقة واحدة حتى لو أُدخل رقم أصغر. ولحظة آخر ظهور تُحفظ في التخزين المحلي لا في الذاكرة، فلا يُلتفّ على التبريد بإعادة تحميل الصفحة.
• بوّابة العدّ: لا سماح إلا كل ثلاث تنقّلات، والعدّاد يزيد على التنقّل الحقيقي بين التبويبات الرئيسية فقط — إذ نقارن باسم الصفحة السابقة، فالضغط على التبويب نفسه مرّتين لا يُحتسب تنقّلاً.
• سقف الجلسة: خمس مرّات كحدّ أعلى للجلسة كلّها، مهما طالت وبلغ عدد التنقّلات.
• بوّابة المحتوى (الحاكمة): لا تُفتح النافذة أبداً قبل التأكّد من وصول إعلان فعلي. نُحمّل الكود في إطار معزول، ثم نستطلع كل نصف ثانية بحثاً عن عنصر حقيقي (iframe أو img أو ins) داخله، بحدّ أقصى ستّ عشرة محاولة أي نحو ثماني ثوانٍ. فإن لم يصل شيء نُفرِّغ الحاوية بصمت — ولا نحتسب المحاولة من السقف، لأن ما لم يظهر لم يُزعج أحداً.

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

const INT_NAV_EVERY = 3;
const INT_SESSION_MAX = 5;
const INT_DEFAULT_COOLDOWN_MIN = 5;

الفائدة تصميمية لا تقنية فقط: عندما يكون الحدّ ثابتاً باسم مقروء، يستطيع صاحب المشروع مراجعة سياسة الإزعاج كلّها في ثلاث أسطر بدل تتبّع شروط متفرّقة. ولحظات الظهور نفسها اختيرت بعد إنجاز لا في وسطه: عند تنقّل حقيقي، وبعد إضافة موعد بتأخير 700 مللي ثانية، وبعد نشر موضوع بتأخير 800 — أي بعد أن ترى المستخدمة رسالة النجاح وتطمئنّ أنّ عملها حُفظ. والفتحة تحمل دائماً وسم «إعلان» صغيراً في زاويتها، مُعطَّل الاختيار والنقر (user-select:none وpointer-events:none) حتى لا يُحسب جزءاً من الإعلان ولا يُنقر بالخطأ. لمزيد عن هذا الجانب: إعلانات المواقع العربية.

الفراغ الذي يبدو خللاً: أخفِ المكوّن الذي لا محتوى له

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

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

.partner-block:empty, .partner-block .partner-block-body:empty { display: none }

ونظيره في مواضع أخرى: حاوية التحقّق البشري تُصفَّر هوامشها وهي فارغة حتى لا تُحدث فجوة وهمية بين الحقول، ومعاينة صور الردّ تُخفى تماماً وهي فارغة. لكن التطبيق أخبث من القاعدة، وأحد أسوأ الفراغات جاء من سلوك افتراضي في المتصفّح: الإطار (iframe) الذي لا ارتفاع صريح له يأخذ نحو 150 بكسل، فبنر إعلاني بمقاس 320×50 كان يجلس داخل صندوق رمادي ارتفاعه ثلاثة أضعافه — لا هو ممتلئ ولا هو مخفيّ، وهذا أسوأ الاحتمالات. الإصلاح كان بمقاومة الغريزة: لا تفرض height:auto على الإطارات؛ اترك ارتفاعها الأصلي من سمتها واكتفِ بتحديد max-width:100%. وللعرض أضفنا قاعدة تجعل الصندوق يحتضن البنر بدل أن يتمدّد حوله:

.partner-block:has(iframe){ width: fit-content; min-width: min(320px, 100%) }

ولأن الاتساق جزء من الأمر (المبدأ الرابع)، وُحّد أقصى عرض للفتحة في متغيّر واحد --banner-max-w:720px يُستعمل في الرئيسية وقائمة الأسابيع وتفاصيل الموضوع، فلا يختلف مقاس العنصر نفسه بين شاشة وأخرى ولا «يقفز» التخطيط عند التنقّل. وإن كنت تتعامل مع أطراف ثالثة تُحمَّل داخل هذه الإطارات فالجانب الأمني لا يقلّ أهمية عن البصري: سياسة أمان المحتوى مع أطراف ثالثة.

التخصيص كأداة انتماء: ستّة ألوان ومتغيّرات لا قيَم ثابتة

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

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

root.style.setProperty('--rose', c1);
root.style.setProperty('--rose-d', c2);
--rose-ll → rgba(r,g,b,.13)
--rose-l → rgba(r,g,b,.55)

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

والاستثناء المقصود مهمّ بنفس القدر: الألوان الدلالية لا تُخصَّص. الأحمر التحذيري، والأخضر الآمن، والذهبي للتنبيه المعتدل — هذه تنقل معنى لا هويّة، وتركها ثابتة يمنع كارثة أن يختار أحد الأحمر لوناً رئيسياً فتصبح كل الواجهة بلون التحذير ويفقد التحذير نفسه معناه. القاعدة: خصّص ما يعبّر عن الذوق، وثبّت ما يعبّر عن المعنى.

التسلسل البصري بأرقام حقيقية: إعادة تصميم بطاقة الملخّص

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

• شريط علوي بارتفاع 3 بكسل بتدرّج ثلاثي (فاتح ← أساسي ← غامق) — وهو نفس تدرّج شريط التقدّم أسفل البطاقة، فيربط العينُ العنصرين معاً بلا كلام.
• ترويسة بحشوة 15px 20px 13px وخلفية متدرّجة خافتة، معها شارة لونية عرضها 3 بكسل على حرف البطاقة بدل خطّ زخرفي.
• المؤشّر الرئيسي بحجم خطّ مرن: font-size: clamp(22px, 6.4vw, 28px) — يتغيّر مع عرض الشاشة بحدّ أدنى 22 وأعلى 28. على جوال بعرض 360 بكسل يستقرّ قرب 23، وعلى الشاشات العريضة يتوقّف عند 28 فلا يصير لوحة إعلانية. وأُزيل عنه كل إطار وخلفية (border:0 وbackground:none): بروزه يأتي من حجمه وموضعه في وسط البطاقة، لا من صندوق يحيطه. هذا جوهر التسلسل البصري — تُبرز عنصراً بإضعاف ما حوله لا بتقوية إطاره.
• صفوف المعلومات يفصلها خطّ شعري واحد 1px solid var(--rose-ll)، عوّض خمس درجات ذهبية متفاوتة كانت تُستعمل قبله. فاصل واحد مكرّر يُقرأ كنظام؛ خمسة فواصل مختلفة تُقرأ كإهمال.
• ثلاث بطاقات مؤشّرات في شبكة repeat(3,1fr) بأوزان متساوية، فلا يتغيّر مقاس البطاقة بطول نصّها.
• شريط تذييل بتاريخ اليوم يُقفل البطاقة بصرياً فتُقرأ ككتلة واحدة لا كتجميع عناصر.

وعلى الجوال (تحت 600 بكسل) لا يتغيّر التخطيط، تضيق الحشوات فقط: الترويسة إلى 14px 16px 12px، وصفوف المعلومات من 20 إلى 16 بكسل جانبياً. الفكرة أن الاستجابة تُعدِّل التنفّس لا الهيكل — الهيكل الذي يتغيّر بين الشاشتين يُجبر المستخدمة على تعلّم واجهتين. ووُحّدت الزوايا في متغيّرين فقط: --r:18px للبطاقات و--r-s:10px للعناصر الصغيرة، والظلال في مستويين: --sh للسكون و--sh-m للمرتفع أو المنبثق. مستويان من العمق كافيان لبناء تسلسل؛ عشرة ظلال متقاربة تُنتج ضباباً لا هرماً.

الخطأ الذي كلّفنا الثقة: رقم واحد يخالف التوقّع

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

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

ثم جاء صنف ثالث من الخطأ، بصري لا حسابي: في صفحة عربية بالاتجاه من اليمين إلى اليسار، حقول التاريخ والوقت والأرقام تُعيد ترتيب خاناتها بصرياً فتُقرأ تاريخاً آخر. عولج بفرض الاتجاه على مستوى الحقل: direction:ltr مع text-align:left وunicode-bidi:embed، وبعائلة خطّ نظامية أحادية العرض للأرقام حتى تثبت الخانات، وبإضافة font-variant-numeric:tabular-nums إلى المؤقّتات فلا يرتجف العدّاد وهو يتغيّر. الرقم الذي «يرتجف» أو «يقفز» يبدو غير موثوق حتى وهو صحيح.

أسئلة شائعة

ما الفرق بين UI وUX؟ الـUI هو المظهر (الألوان، الأزرار، الترتيب)، والـUX هو التجربة كاملةً (هل أنجز المستخدم هدفه بسهولة ورضا؟). الـUI جزء من الـUX، لكنّ التجربة أوسع من الشكل.

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

كيف أوازن بين الجمال وسهولة الاستخدام؟ حين يتعارضان، تنتصر سهولة الاستخدام. الجمال الذي يعيق الإنجاز يخسر المستخدم بعد الإعجاب الأوّل.

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

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

من أين أبدأ إن كان وقتي ساعة واحدة؟ ابحث عن الفراغات غير المقصودة وأخفِها، ووحّد الزوايا والظلال في متغيّرين لكلٍّ منهما، ثم افتح تطبيقك بحساب جديد في نافذة متخفّية. هذه الثلاثة تُخرِج أكثر العيوب التي يراها الغرباء ولا تراها أنت.

خلاصة

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

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