كفّوا عن اختراع الكلمات! شلال زائف؟ ماذا؟

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

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

الأمر كما هو

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

لنصمّم بكل ما أوتينا من طاقة!

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

أولًا، توقفوا عن التحديق في تلك المراجع الجميلة

كلما تعمقتم في عالم المصطلح الرائج "نظام التصميم" (Design System)، قد تتكوّن لديكم فكرة أنه مجموعة ضخمة ومحكمة ومدروسة بعناية من القواعد، ومنظومة تصميم يجب أن تسعوا إليها أنتم وفريقكم مهما كلّف الأمر. فتنظرون إلى أنظمة جميلة مثل Carbon و Fluent و Material، وتأملون أن تبنوا مثلها في مشاريع وكالتكم الرقمية القادمة. أليس هذا ما يجب أن تطمحوا إليه؟

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

ما الذي يجب مراعاته عند بناء نظام تصميم مدمج؟

1. قيود المشروع

• هل هذا مشروع بعقد مدته 6 أشهر أم منتج مستمر طويل الأمد؟
• هل الجدول الزمني ضيق؟ هل يمكنهم تحمّل انتظاركم حتى تطوّروه أكثر؟
• هل سيستعينون بعدة فرق تطوير لتنفيذ التصميم الذي اعتمدتموه؟
• هل لديكم وقت كافٍ لتهيئة مصمم آخر (أو أكثر) عند الحاجة؟

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

2. استخدموه بفاعلية، لا بتعصّب

تذكّروا أنكم تبنون نظام تصميم ليتبعه الجميع، لا لإرضاء غروركم وبناء مجموعة أعمال أحلامكم. فكل ما تصنعونه يجب أن يفيد من يعملون معكم. ونظام التصميم ينمو بما يتناسب مع طموحات المنتج وحجمه، لا العكس.

3. نظرة الآخرين إلى نظام التصميم

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

بناء نظام التصميم بذكاء

من أكثر الأخطاء شيوعًا بين المصممين عند العمل على مشروع أنهم لا يعرفون كيف ومن أين يبدؤون في بناء نظام التصميم. دعوني أقدّم لكم دليلًا بسيطًا تتبعونه. 1. كلما بنيتموه أبكر، كان أفضل

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

2. ابدؤوا صغارًا

يمكنكم أن تبدعوا كما تشاؤون في اختيار ألوان الأزرار، وإنشاء حالات متعددة لحقول إدخال النماذج، وتحديد نبرة اللغة التصميمية التي تستخدمونها في منتجكم، ما دام ذلك ضروريًا ولا يبالغ في التعويض عن شيء قد لا تستخدمونه إلا نادرًا على المدى الطويل. فإنشاء 15 لوحة من الدرجات الداكنة والفاتحة لأجل 3 رسوم توضيحية في شاشات التهيئة (onboarding) ليس طريقة جيدة لقضاء وقتكم إطلاقًا.

3. كونوا بنّائين

لا أحد يحب العمل مع نظام راكد وممل وغير بديهي. فأنظمة التصميم وُجدت لتنمو وتتحسن. وعند المساهمة في النظام، اطرحوا هذه الأسئلة باستمرار:

• ما المشكلة التي يحلّها هذا؟
• هل لدينا بالفعل هذا الحل تحديدًا في النظام؟
• ما أثره على سير العمل بأكمله؟

إذا استطعتم الإجابة عن هذه الأسئلة وظل الأمر منطقيًا في نظر أصحاب المصلحة، فيمكن، بل ويجب، تطبيقه.

4. التواصل هو المفتاح

تحدّثوا وناقشوا، اتركوا ملاحظات واشرحوا كل شيء بوضوح. فلا يمكن العمل على أي نظام دون الحديث والتواصل مع فريقكم. كونوا مستعدين للمساهمة ومشاركة التعليقات والأفكار حول كيفية التحسين وما نبني عليه.

5.لا تخجلوا من استخدام ابتكارات الآخرين

هذه ليست مسابقة لمن يبتكر أكثر الأنظمة تفصيلًا في أقصر وقت. بل هي ماراثون لبناء هيكل مدروس بعناية مع تقدّم عملكم. اقضوا وقتكم في البحث عن قوالب وUI kits متكاملة ومفيدة لتبدؤوا بها. وهذه هي الفكرة الأساسية من وجود نظام في المقام الأول. ولإجراء التعديلات، ابقوا على اطلاع بالأدوات والإضافات (plugins) المفيدة لتعتادوا عليه بسرعة.

الممارسة في التطبيق

والآن إلى الموضوع الأكثر إثارة: ما الذي يحدث فعلًا في فريقنا؟

في OOZOU، نعطي الأولوية لتجربة انضمام الزملاء وفق الترتيب التالي:

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

ولتقليص الوقت اللازم لنقل الموارد على امتداد الجدول الزمني للمشروع، نعدّ ما يلي أهدافنا الرئيسية:

حاولوا أن تجعلوه نظامًا يشرح نفسه بنفسه

يجب أن يكون نظام التصميم سهل الفهم والاعتياد. فعندما يبدأ مصمم جديد العمل في OOZOU، يُمنح الوقت والفرصة لدراسة الأساسيات وطريقة سير الأمور عبر وثائق التهيئة لدينا قبل أن يُكلَّف بأي عمل "فعلي". ومع ذلك، لا ينبغي أن يكون المرء مصممًا ليفهم هذه الأنظمة.

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

إذا بدا شيء معقدًا بعض الشيء، فاشرحوه بالكلمات

لا مفر من أن بعض جوانب النظام ستظل بحاجة إلى شرح ونقاش. وهنا يأتي دور التواصل.

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

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

في التسليمات المتلاحقة السريعة، يصبح التوثيق ترفًا

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

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

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