خلّيني أكون صريح معك من البداية: معظم المبرمجين (وأنا كنت واحد منهم) كانوا يشوفوا تصميم واجهات المستخدم إنه “شغل المصمّم”، وإن دور المبرمج ينتهي عند الكود، الـ API، والـ Database.
تكون شغال أيام وأسابيع على Backend نظيف، Queries محسّنة، كود مرتب… وبعدين المستخدم يفتح المشروع، يضيع من أول شاشة، ويسكّر التطبيق أو الموقع.
مش لأن الكود سيئ.
لأن الواجهة سيئة.
في النهاية، المستخدم ما بيشوف Class ولا Function ولا Endpoint. كل اللي بيشوفه:
- صفحة تسجيل دخول
- نموذج تسجيل
- قائمة منتجات
- أزرار، ألوان، رسائل، وحالة واضحة أو مربكة
وهنا بالضبط بيجي دور تصميم واجهات المستخدم (UI). الهدف من المقال هذا مش يخليك مصمّم محترف، بل يخليك مبرمج أقوى بعقلية تفهم المستخدم والواجهة، مش بس الكود.
الكود يشتغل… بس هل المستخدم فهم الواجهة؟
خلينا نبدأ بسيناريو بسيط:
- عندك صفحة تسجيل حساب.
- حقول كثيرة: اسم، بريد، رقم هاتف، كلمة مرور، تأكيد كلمة مرور، دولة، مدينة، مهنة…
- أزرار محشورة، رسائل خطأ عامة، وما في أي توضيح شو المطلوب.
تقنياً:
- الـ Validation ممتاز.
- الـ API يرجع Responses صحيحة.
- الـ Database مصممة صح.
بس عملياً:
- المستخدم حاسّ حاله في امتحان رسمي.
- أي خطأ بسيط يطلع له برسالة: “حدث خطأ، حاول مرة أخرى”.
هل رح يكمل التسجيل؟
غالباً لا.
هذا هو الفرق بين مشروع شغال و منتج ناجح فعلاً.
المبرمج اللي يفهم واجهة المستخدم ما بيفكر بس: “هل الكود يشتغل؟”، بل يسأل كمان: “هل المستخدم فهم؟ هل حسّ أن الأمور منطقية؟”.
ونفس العقلية اللي تحتاجها عشان تفهم الأكواد المعقّدة وتبسطها، هي نفسها اللي تحتاجها عشان تبني واجهة واضحة وبسيطة. لو حاب تطوّر هذا الجانب أكثر، احفظ رابط المدوّنة عندك، لأنه فيه محتوى كثير قريب من هذا الأسلوب.
طيب… شو يعني أصلاً “يتعلم المبرمج تصميم واجهات”؟
مهم جداً نحدد نقطة أساسية:
تعلم UI للمبرمج لا يعني:
- إنك تصير “Graphic Designer” كامل.
- أو تقعد ترسم شعارات وشخصيات.
- أو تتقن كل شيء في Photoshop وIllustrator.
تعلم UI للمبرمج يعني:
- تفهم كيف عين المستخدم تتحرك على الشاشة.
- تعرف ليش زر معيّن لازم يكون أوضح من غيره.
- ترتّب العناصر بشكل يخلي التجربة منطقية وبسيطة.
- تكون واعي للألوان، الخطوط، المسافات، وحالات العناصر.
بمعنى آخر:
تفهم لغة الواجهة بنفس درجة فهمك للغة البرمجة.
وعلى فكرة، عقلك كمبرمج يساعدك كثير هنا. أنت أصلاً متعود على:
- التفكير المنطقي.
- تقسيم المشكلة إلى أجزاء.
- بناء Flow واضح (if/else, conditions, states).
كل هذا نفس اللي تحتاجه في UI، بس على مستوى التجربة البصرية.
لماذا تعلّم UI مهم جداً للمبرمج؟ (4 أسباب حقيقية)
1) لأن المستخدم لا يهمه الكود… يهمه الشعور
المستخدم مش راح يفتح Console ويشوف أخطاءك. مش راح يقيم الـ Architecture ولا الـ Design Patterns.
كل اللي بيشوفه:
- هل فهم من أول نظرة ماذا يفعل الموقع أو التطبيق؟
- هل يعرف أين يضغط؟
- هل يشعر أن كل شيء مرتب وواضح؟
- هل النتائج منطقية، وردود الفعل (Feedback) مفهومة؟
لو الواجهة فوضوية:
- المستخدم بيغلط كثير.
- يحس التطبيق “معقّد” أو “ثقيل”.
- يترك الخدمة حتى لو كانت أقوى من غيرها.
2) لأن التواصل مع المصممين جزء أساسي من شغلك
في فريق تطوير حقيقي، غالباً عندك:
- Product Manager
- UI/UX Designer
- Developers
لما تكون فاهم أساسيات UI:
- تتكلم مع المصمم بنفس اللغة.
- تفهم ليش يحكي عن Hierarchy، White Space، Contrast.
- تقدر تقول: “هاي الحركة تقيلة جداً على الموبايل، خلينا نعمل نسخة أبسط”.
بدل ما يكون الحوار:
المصمم: لازم نزيد المسافات ونغيّر لون الزر.
المبرمج: ليش؟ هيك أسهل إلي في الكود.
يصير الحوار:
المصمم: بدنا نخلي الزر الأساسي أوضح.
أنت: تمام، نخليه Primary بلون مختلف، ونخفّف باقي الأزرار.
3) لأن UI الجيد يفرض عليك قرارات برمجية أفضل
مثال بسيط:
لو قررت تعمل:
- حالة Loading واضحة لكل Button.
- رسائل خطأ مخصصة لكل حقل.
- Empty State أنيق لما ما يكون في بيانات.
رح تضطر في الكود أنك:
- تضيف States أكثر.
- تبني Error Handling مرتب.
- تفكر في كل سيناريو: قبل الطلب، أثناءه، بعده.
هذا لوحده يرفع مستوى جودة كودك.
4) لأن قيمتك في السوق ترتفع (خاصة كمبرمج مستقل)
لو أنت مبرمج مستقل، العميل عادةً بدو:
- موقع أو تطبيق يشتغل.
- شكله محترم.
- وتجربة بسيطة ما تربك الزوار.
لو أنت:
- تكتب كود نظيف.
- وتفهم الواجهة.
- وتعرف تحسّن التجربة بدون ما تحتاج دائماً لمصمّم.
عندك قوة تفاوض أعلى، وسعر أعلى، وفرص شغل أكثر.
ولو مهتم بموضوع العمل الحر للمبرمجين وكيف تبني قيمة حقيقية للعميل، ادخل على قسم المدوّنة وابحث عن مقالات العمل كمبرمج مستقل، لأنها تكمل نفس الفكرة من زاوية ثانية.
ماذا يحتاج المبرمج أن يتعلم بالضبط في UI؟
ما بدنا نفتح كل عالم التصميم. هدفنا حقيبة أدوات صغيرة، بس فعّالة.
1) التسلسل البصري (Visual Hierarchy)
الفكرة بسيطة:
- مش كل شيء على الشاشة له نفس درجة الأهمية.
- عين المستخدم لازم تعرف مين “العنوان”، مين “الزر الأساسي”، مين “معلومة ثانوية”.
أدواتك هنا:
- حجم الخط (العنوان أكبر من النص).
- الوزن (Bold للعناصر المهمة).
- اللون (لون الزر الرئيسي أوضح من الباقي).
- المسافة (العنصر المهم محاط بمساحة “يتنفس” فيها).
مصدر ممتاز يشرح هذه الأفكار للمبرمجين بأسلوب عملي:
- Refactoring UI:
https://www.refactoringui.com/
2) المسافات والتخطيط (Layout & Spacing)
كثير واجهات شكلها “رخيص”، مو لأن الألوان سيئة، بل لأن كل شيء ملزّق ببعض.
قواعد سريعة:
- استخدم Grid بسيط (عمودين أو ثلاثة).
- حافظ على نفس الـ Padding داخل الكروت والأقسام.
- خليك ثابت في نظام المسافات (مثلاً: 8، 16، 24).
هذا يترجم في الكود إلى قيم ثابتة في CSS أو في Flutter/React، بدل ما تكون عشوائية.
3) الألوان والتباين (Colors & Contrast)
الهدف مو تعمل لوحة فنية، بل واجهة مقروءة وواضحة.
- النص لازم يكون واضح على الخلفية.
- الزر الأساسي لازم يبرز عن بقية الواجهة.
- رسائل الخطأ والتحذيرات لازم تكون ملفتة بدون ما تكون مزعجة.
أداة عملية جداً لفحص التباين:
- WebAIM Contrast Checker:
https://webaim.org/resources/contrastchecker/
4) الخطوط (Typography)
الخط هو أكثر عنصر يشاهده المستخدم.
نصائح بسيطة:
- لا تستخدم أكثر من خطين.
- اجعل أحجام الخطوط لها منطق (H1 > H2 > Body).
- اهتم بالـ Line-height عشان القراءة تكون مريحة.
مستودع خطوط مجاني:
- Google Fonts:
https://fonts.google.com/
5) العناصر والحالات (Components & States)
كل Button، Input، Card… له حالات:
- Default
- Hover (على الويب)
- Active / Pressed
- Disabled
- Loading
- Success / Error
لما تفكر بهذه الحالات من البداية، كودك رح يصير أنظف، وتجربة المستخدم أوضح.
لو فتحت أي Design System مثل Material Design من جوجل، رح تلاحظ كيف يفكروا في المكونات ككيانات لها حالات، مو مجرد شكل ثابت:
- Material Design 3:
https://m3.material.io/
خطة عملية لتعلّم UI كمبرمج (خلال 7 أيام)
ما بدنا تنظير، خلينا نحط خطة واقعية تقدر تطبقها.
اليوم 1: مشاهدة وتحليل
- افتح 3 مواقع تحسها “مريحة” في الاستخدام.
- اسأل نفسك: ليش أنا مرتاح في استخدامهم؟
- ركّز على: حجم العناوين، مكان الأزرار، المسافات.
اليوم 2: تقليد واجهة جاهزة
- افتح Figma.
- ابحث في Community عن “Login Page”.
- خذ تصميم مجاني وحاول تعيد بناءه كـ كود (HTML/CSS أو إطارك المفضل).
تعليم رسمي ومجاني من Figma نفسه:
اليوم 3: دراسة بسيطة لـ Material Design
- افتح:
https://m3.material.io/ - اقرأ عن Buttons, Cards, Layout.
- لاحظ كيف يتم استخدام المسافات، الألوان، والظلال.
اليوم 4: اللعب بالألوان
- اختر تدرج ألوان بسيط: لون أساسي + لون ثانوي + لون للـ Background.
- استخدم WebAIM لفحص التباين.
- طبّق الألوان على نفس صفحة تسجيل الدخول اللي عملتها.
اليوم 5: إضافة الحالات (States)
- أضف حالة Loading لزر تسجيل الدخول.
- أضف رسائل خطأ واضحة لكل حقل.
- أضف Empty State لصفحة “بدون بيانات”.
اليوم 6: اختبار على شخص حقيقي
- اعرض الصفحة على صديق، أخ، أخت، أي شخص.
- لا تشرح له… بس قل له: “سجّل حساب”.
- راقب: هل عرف ماذا يفعل من أول مرة؟ أين وقف؟ أين تردد؟
اليوم 7: تدوين الدروس وربطها بمشاريعك
- اكتب لنفسك ملاحظات عن:
- أكثر شيء اكتشفت إنه مهم.
- أكثر خطأ كنت تعمله بدون ما تنتبه.
- كيف رح تغيّر شغلك القادم بعد هالتجربة.
بهذه الخطة، خلال أسبوع واحد، رح يصير عندك:
- أول مشروع بسيط تطبق فيه UI بوعي.
- فهم حقيقي لاحتياجات الواجهة.
- بداية قوية لتطوير نفسك في هذا الاتجاه.
أخطاء شائعة يقع فيها المبرمج لما يبدأ يتعلم UI
- يحاول يصير مصمم Dribbble من أول يوم
يضيع ساعات على ظلال معقدة وGradients غريبة… بينما المشكلة الأساسية هي أن الفورم نفسه مش واضح. - ينقل واجهات حرفياً بدون ما يفهم ليش
يشوف تصميم يعجبه، ينسخه 1:1، بس ما يتعلم المنطق وراه. - يهمل القيود التقنية
يعمل تصميم خرافي بس مستحيل يتنفّذ بكفاءة على الموبايل أو على شبكة ضعيفة. - يستحي يجرّب ويغلط
ينتظر يكون “متأكد” قبل ما يصمم شيء… وهذا ما بيصير.
نفس اللي صار معك بأول مشروع برمجي: ما تعلمت إلا لما كتبت كود، غلطت، صححت، وكررت.
كيف ينسجم هذا كله مع رحلتك كمبرمج؟
هدفك في النهاية مش بس “تكتب كود يشتغل”، بل تبني شيء الناس فعلاً تستخدمه وتحبّه.
تعلم تصميم واجهات المستخدم جزء طبيعي من هذه الرحلة:
- يخليك تفهم الإنسان اللي يستخدم شغلك.
- يجبرك تفكر في الوضوح والبساطة، مش بس في التعقيد التقني.
- يخلّي مشاريعك القادمة أسهل في البيع، أسهل في الاستخدام، وأسهل في التطوير.
ولو حاب تتابع مواضيع قريبة من هذا الأسلوب (واقعية، عملية، من تجربة حقيقية)، احفظ عندك رابط كود التطور – الرئيسية ورابط قسم المدوّنة وارجع لهم كل فترة.
الخلاصة: أنت مش محتاج تصير مصمم… لكن محتاج تفهم الواجهة
مش مطلوب منك ترسم شعارات أو تصمم Brand كامل.
المطلوب:
- ما تطلع من مشروع جديد بواجهة “تعبانة”.
- ما تعتمد 100% على المصمم عشان تكمل شغلك.
- ما تبني شيء صعب الاستخدام وتستغرب ليش المستخدمين ما حبوّه.
تعلم تصميم واجهات المستخدم للمبرمجين هو ترقية لعقلك البرمجي، مش تبديل تخصص.
ابدأ اليوم بخطوة بسيطة:
- افتح Figma.
- اختَر أي UI جاهزة.
- حاول تعيد بناءها كـ كود.
وبعد أسبوع واحد من اللعب والتجربة، رح تلاحظ قديش تفكيرك في المشاريع القادمة صار مختلف.
وقتها، رح تحس إنك فعلاً ما عدت بس “مجرّد مبرمج”، بل صاحب منتج يفهم الناس، والآلة، والواجهة اللي بينهم.
اكتشاف المزيد من كود التطور
اشترك للحصول على أحدث التدوينات المرسلة إلى بريدك الإلكتروني.
