OOZOU
تواصلوا معنا
العودة إلى المدونة

كيف نتعامل مع عدم الاتساق بين مشاريع التصميم

نعالج عثرات أنظمة التصميم المعقدة بحماس، حلًّا عمليًا واحدًا على مستوى الفريق في كل مرة. (الجزء 1 من 3)

28 يونيو 2020
9 دقائق للقراءة
كيف نتعامل مع عدم الاتساق بين مشاريع التصميم

هذا هو الجزء الأول من سلسلة "3 حلول عملية في التصميم"، وفيها نشارككم مبادئ حلول طبّقناها حصرًا في مشاريعنا المبنية على Figma. معظمها يُفترض أن يعمل في Sketch أيضًا (بل وحتى في ملف Sketch مستورد). إن وجدتم بعض هذه الحلول صعبة، راسلوني في التعليقات ونتحدث أكثر!

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

لا تقلقوا، لدينا ما يساعدكم! (نأمل ذلك :P) هذه الحلول ستجعل التجربة أكثر سلاسة للمستخدمين.

أنا أستعرض عضلاتي بعد تمرين عمليات التصميم (بعضلات أقل من عضلات Mark بنسبة 98%)

عدم الاتساق في التصميم

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

آثار عدم الاتساق

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

عدم الاتساق في تصميم UX مشكلة كبيرة

المشكلة الأساسية في فريق عملنا أننا كثيرًا ما نفتقر إلى فهم مشترك لكيفية تطبيق القواعد المتفق عليها في المشروع، ومنها:

  1. المسافات
  2. أحجام النصوص
  3. الألوان

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

أ. لمشكلات المسافات، استخدموا الـ "spacer" السحري

يوفّر كل من Figma وSketch ميزة Auto-layout (Smart layout) التي تعيد ترتيب العناصر وتوسّع حدودها تلقائيًا. لكن هذه الطريقة تتطلب بنية طبقات أعقد كلما أردتم تخصيص المسافات بين العناصر أكثر. ولا تقولوا إنكم لم تفعلوا ذلك من قبل لينتهي بكم الأمر إلى padding بمقدار 16px لكل عنصر في الـ components. فهذا سيجعل تصميمكم مملًا ومكررًا مثل حصة الرياضة في الروضة! (إلا إن كنتم تملكون بنية رياضي وتمارسون الرياضة منذ ولادتكم). بفضل هذا الحل، نتخلص من عملية النقر على كل نقطة في التخطيط وحفظ الأرقام، وذلك بإنشاء مجموعة من master components تمثّل الـ "padding" بشكل مادي. فالمسافات المناسبة جزء أساسي من تصميم UX، وتحسّن سهولة الاستخدام ورضا المستخدم. اجمعوا هذه العناصر معًا لتبديل ظهور كل components القياس دفعة واحدة بهذه الطريقة يمكننا تركيب كل جزء من عناصر النظام مع الحفاظ على المسافات بين العناصر. ("نُبقي القيمة 0 لكل العناصر التي تستخدم Auto-Layout"). وميزة ذلك أن أي مصمم يعمل على الملف يستطيع تبديل "ظهور" كل spacer components ليدرس قواعد المسافات في كل عنصر. ملاحظة جانبية: هذا الحل يحتاج إلى بعض الوقت للتعوّد عليه، فلا تطبّقوه من دون تفكير. في البداية، حين لا تكون فكرة التصميم قد نضجت بعد، سيكون نسخ عناصر الـ spacer أصعب من مجرد كتابة رقم في خصائص Auto-layout. فكّروا في الاستغناء عن طرق الـ padding التقليدية بعد أن يضع فريقكم مجموعة قواعد واضحة لها.

ملاحظة جانبية: هذا الحل يحتاج إلى بعض الجهد للتعوّد عليه، فلا تفرضوه من دون تفكير. في البداية، حين لا تكون فكرة التصميم قد نضجت بعد، سيكون نسخ عناصر الـ spacer أصعب من مجرد كتابة رقم في خصائص Auto-layout. فكّروا في الاستغناء عن طرق الـ padding التقليدية بعد أن يضع فريقكم مجموعة قواعد واضحة لها.

ب. مشكلة أحجام النصوص: أوصاف مساعدة

إن كنتم تبنون نظامكم انطلاقًا من بعض UI kits (أو بوجود شخص مختص بعمليات التصميم)، فغالبًا سترون مجموعة خطوط من هذا النوع في بداية نظامكم. من النصائح المفيدة أن تحذفوا ما لم تستخدموه منها. وإن لم يكن لديكم وقت لذلك للأسف، فستُبقون على الأرجح 3 إلى 4 مستويات من أحجام النصوص غير المستخدمة في النظام "احتياطًا"، تحسّبًا لاحتياجكم يومًا إلى حجم "أصغر أو أكبر قليلًا". هل تحتاجون فعلًا إلى حفظ طريقة استخدامها لأنفسكم (ولكل الآخرين)؟ فأحجام النصوص المناسبة جزء أساسي من تصميم UX، وتحسّن قابلية القراءة وتفاعل المستخدم.

أنشئوا مجموعة للعناصر التي تستخدمونها كثيرًا

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

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

أو أضيفوا تلميحات وصفية للمستخدم

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

ج. مشكلة الألوان: ما سبق ينطبق على أنماط الألوان أيضًا

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

كيف تختارون أصلًا؟

الحل البسيط جدًا هو إنشاء "مجموعة" ألوان لكل جزء محدد من واجهة المستخدم، وأن يلتزم بها الجميع.

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

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

الحل البسيط جدًا أيضًا هو إنشاء "مجموعة" ألوان لكل جزء محدد من واجهة المستخدم، وأن يلتزم بها الجميع.

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

تجربة مستخدم متسقة

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

الخلاصة

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

هذا كل شيء الآن

في الجزء الثاني، سنتناول كيفية تقليل التكرار الناتج عن سير عمل أنظمة التصميم التي تتطلب صيانة عالية.

Related Articles

كيف أصمّم برمجيات؟ دليل المبتدئين لأصحاب الأعمال

كيف أصمّم برمجيات؟ دليل المبتدئين لأصحاب الأعمال

تصميم البرمجيات عملية ممتعة لكنها معقدة، تتطلب الإبداع والتفكير المنطقي ومهارات حل المشكلات.

اقرأوا المزيد
مستقبل الحوسبة الطرفية: ما تحتاج الشركات إلى معرفته

مستقبل الحوسبة الطرفية: ما تحتاج الشركات إلى معرفته

يتطور المشهد الرقمي بسرعة، وعلى الشركات أن تتكيّف لتواكب الطلب المتزايد على السرعة والكفاءة والمعالجة في الوقت الفعلي.

اقرأوا المزيد
مستقبل قطاع التجزئة: الذكاء الاصطناعي والواقع المعزّز واتجاهات التحوّل الرقمي

مستقبل قطاع التجزئة: الذكاء الاصطناعي والواقع المعزّز واتجاهات التحوّل الرقمي

يتطور قطاع التجزئة بوتيرة غير مسبوقة بفضل الذكاء الاصطناعي (AI) والواقع المعزّز (AR) وتقنيات التحوّل الرقمي. فلم تعد المتاجر التقليدية مجرد أماكن لبيع المنتجات، بل أصبحت متاجر ذكية وتفاعلية.

اقرأوا المزيد

Have a Project in Mind?

Let's discuss how we can help bring your ideas to life with our expertise in web and mobile development.

ابدأوا المحادثةhello@oozou.com
OOZOU Logo

بانكوك · سنغافورة · هونغ كونغ

X
Facebook
Instagram
LinkedIn
OOZOU Co., Ltd.
548 One City Centre
Ploenchit Road
Bangkok 10330
Thailand
+66 2544 0000
hello@oozou.com

الخدمات

  • تطوير الويب
  • وكلاء الذكاء الاصطناعي والذكاء الاصطناعي التوليدي
  • تطوير تطبيقات الجوال
  • تحليلات البيانات وهندستها
  • تصميم تجربة المستخدم وواجهته (UX/UI) وتصميم المنتجات
  • التحوّل الرقمي

الشركة

  • من نحن
  • الوظائف
  • المدونة
  • دراسات الحالة
  • عروض حية
  • تعلّمت اليوم
  • تواصل معنا

المزيد

  • القطاعات
  • شبكة الشركاء
© 2026 OOZOU. جميع الحقوق محفوظة.
سياسة الخصوصيةمدونة قواعد السلوكسياسة مكافحة الرشوة والفساد