ما يجب على كل مصمم معرفته قبل المشاركة في أول هاكاثون له

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

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

بعد أن وضعت جانباً متلازمة المحتال، وشكلت فريقاً، واجتزت 24 ساعة مرهقة، فاز مشروع فريقي بجائزة أفضل استخدام للصالح الاجتماعي (Best Use for Social Good). إليك بعض الأشياء التي تعلمتها من هذه التجربة:

لماذا يحتاج كل فريق هاكاثون إلى مصمم؟

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

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

ماذا يفعل المصمم في فريق الهاكاثون؟

إذا كنت مصمماً يرغب في المشاركة في هاكاثون ولست متأكداً من المخرجات أو الخطوات العملية التي يجب عليك اتخاذها طوال العملية (كما كنت أنا)، فإليك لمحة عامة عما كانت عليه مشاركتي:

تحليل المشهد (Landscape Analysis)

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

بالنسبة لي، تضمن ذلك إجراء بحث مكثف في القضايا المحيطة بمجال المشكلة الذي اخترناه، بالإضافة إلى الأدوات الموجودة في السوق التي تهدف إلى حل قضايا مماثلة (أو مختلفة). كما قمت بإجراء بعض أبحاث المستخدمين عن طريق التواصل مع معارف ذوي صلة لإجراء مقابلات مستخدمين قصيرة وغير رسمية لاكتساب فكرة أفضل عن تجربتهم ونقاط الألم لديهم في هذا المجال. كانت هذه خطوة لا تقدر بثمن في عمليتنا. عندما حان وقت تقديم مشروعنا، لم يكن لدينا فقط منتج قابل للتطبيق بحد أدنى (minimum viable product - MVP) لعرضه، ولكن أيضاً البحث الذي يثبت الحاجة إلى منتجنا في المقام الأول.

لقد تعمقت في عالم عدم المساواة على الويب لأولئك الذين يعانون من ضعف البصر ومحدودية النطاق الترددي.

تدفقات المهام والرسومات الأولية (Task Flows and Sketches)

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

تدفقات المهام الأساسية التي يجب أن يتضمنها منتجنا.

الوايرفريم والنماذج الأولية (Wireframes and Mockups)

تأخذ الوايرفريم (Wireframes) رسوماتك الأولية خطوة أخرى إلى الأمام وتمنح المطورين قيوداً أكثر أهمية للعمل بها. يساعد استخدام أدوات مثل Figma أو Zepplin لمشاركة تصميماتك مع المطورين على الاستفادة القصوى من وقتك، حيث يمكنهم فحص الكود المقابل واستخدامه. يساعد إضافة نماذج أولية عالية الدقة (high-fidelity mockups) في عرضك التقديمي على إبراز عملك وجعله يبدو أكثر واقعية ووظيفية من منتجك الأولي (MVP)، والذي سيبدو على الأرجح مثل الوايرفريم منخفضة الدقة (low-fidelity wireframes) الخاصة بك.

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

لعرض التصميم في عرضنا التقديمي، وضعت نموذجاً أولياً بصيغة PNG mockup لصفحة الهبوط الخاصة بمنتجنا داخل جهاز (باستخدام قالب ملف من مجتمع Figma Community)، بالإضافة إلى فيديو ترويجي قصير إضافي صنعته باستخدام Rotato.

الوايرفريم منخفضة الدقة الخاصة بي، والتي لم ير معظمها النور خارج ملف Figma الخاص بي.

إدارة المشروع والعرض التقديمي (Project Management and Presentation)

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

• مقدمة عن مشروعك وأعضاء الفريق.
• المشكلة التي تحاولون حلها.
• قاعدة المستخدمين وحالات الاستخدام التجارية، وكيف يحل منتجك هذه المشكلات.
• المكدس التقني (Tech stack) وميزات المنتج.
• التأثير طويل المدى لمنتجك.
• الصعوبات والمضاعفات التي واجهتموها، وما تعلمتموه على طول الطريق.

لقد بنيت عرضنا التقديمي في Canva، والذي يتيح سهولة التعاون ودمج الوسائط. يتمتع المصممون بميزة فريدة تتمثل في عدم تقييدهم بسير عمل واحد فقط خلال الهاكاثونات، مما يسمح لك بتحريك فريقك إذا/عندما يضيعون في الكود. هذا يحدد حدوداً وقيوداً زمنية مهمة، ويساعد على التأكد من توزيع وقتك ومهامك بكفاءة. طوال حدث الـ 24 ساعة، كنت أذكر فريقي بمواعيدنا النهائية القادمة: متى يجب أن ننهي منتجنا الأولي (MVP)، ومتى سنبدأ التدرب على عرضنا التقديمي، وموعد التسليم النهائي. تركت مساحة كافية لكل مرحلة في حال حدوث أي خطأ أو تأخير (وهو أمر شبه مضمون في عالم الهاكاثونات).

حيث تلتقي التعاطف بالاستراتيجية

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

1. ابدأ مبكراً: لا أقصد أن تبدأ أي "اختراق" فعلي قبل وقت بدء الحدث بالطبع. لكنني أقترح التعرف على فريقك، وتوليف بعض أفكار المشاريع، والتوصل إلى خطة عمل قبل بدء الهاكاثون فعلياً. قام فريقنا بالدخول إلى مستند Google Doc قبل أسبوع واحد من الهاكاثون لسرد مهارات كل منا الأساسية واقتراح فكرتين للمشروع للتصويت عليهما لاحقاً. قبل أن يبدأ الهاكاثون، كان لدينا بالفعل فكرة جيدة عن أعضاء فريقنا، وما كنا نجيده، وما سنبنيه في إطار الـ 24 ساعة.
2. قم ببحثك: لا يمكنني المبالغة في أهمية البحث في عمليتك. فهو لا يساعدك فقط في الوصول إلى بيان مشكلتك والتحقق من حاجة العالم لمشروعك، ولكنه يعمل أيضاً كتذكير خلال الساعات الأكثر صعوبة من الحدث بالتأثير الذي تأمل في إحداثه. في لحظات عدم اليقين، كنت أعود إلى البحث الذي قمت به في مجال هذه المشكلة، وأذكر نفسي بالحاجة الكمية للحل، وأستخدم ذلك كوقود لمواصلة الدفع.
3. كن مرناً (Agile): تعلمت بسرعة كبيرة، وربما ليس من المستغرب، أن بناء منتج قابل للتطبيق بحد أدنى (minimum viable product) من الصفر في فترة زمنية قصيرة يصبح فوضوياً. لن يصل كل ما شرعت في بنائه في بداية الهاكاثون إلى التصميم النهائي، وهذا أمر طبيعي. هذه بيئة رائعة لتكون فيها مرناً، وتفشل بسرعة (fail fast)، وتكرر (iterate)، وتبسط سير عملك قدر الإمكان.
4. تواصل بوضوح وبشكل متكرر: تواصل فريقنا بشكل أساسي عبر Facebook Messenger، حيث يمكن للمطورين استكشاف الأخطاء وإصلاحها بسرعة وتبادل الأفكار. استخدمت قناة الاتصال هذه لإبقاء الفريق على اطلاع دائم بما كنت أعمل عليه، وتقديم بعض ملاحظات واجهة المستخدم (UI notes)، والسؤال عما إذا كان أي شخص يحتاجني لأي شيء. كما استخدمتها لتذكير الفريق بما أحتاجه منهم، سواء كان ذلك بعض النصوص التقنية (tech copy) لوضعها في عرضنا التقديمي أو تذكير بالموعد النهائي للساعة الذي اتفقنا على بدء مراجعة مشروعنا بحلوله.
5. كن شغوفاً: المقولة الكلاسيكية لم تغب عن بالي، لكنها حقيقة. حتى وظيفة أحلامك في التصميم قد تأتي مع بعض المشاريع التي لست متحمساً لها للغاية. الهاكاثونات، من ناحية أخرى، توفر فرصة فريدة لبناء شيء أنت متحمس له حصرياً، دون أي التزام سوى إرادتك الخاصة. سواء كانت قضية اجتماعية أو تقنية إبداعية، فإن العثور على مشروع أنت شغوف به بعمق سيساعد في توجيه عملك ودعمه والتحقق منه من البداية إلى النهاية.

الخلاصة التقنية

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

الخلاصة التحليلية

يبرز هذا المقال بوضوح الدور المحوري للمصمم في بيئة الهاكاثون، متجاوزاً المفهوم التقليدي الذي يركز فقط على الجانب البرمجي. فالمصمم، من خلال عملية التفكير التصميمي (Design Thinking) والتركيز على تجربة المستخدم (User Experience)، لا يساهم فقط في جماليات المنتج، بل يضمن قابليته للحياة (Viability) وتركيزه على حل مشكلة حقيقية للمستخدمين. إن قدرته على قيادة البحث، وتحديد تدفقات المهام، وتصميم الوايرفريم والنماذج الأولية، ثم صياغة قصة المشروع المقنعة في العرض التقديمي، تجعله عنصراً لا غنى عنه لتحويل الفكرة التقنية إلى حل مؤثر ومقبول. يتطلب هذا الدور مزيجاً فريداً من التعاطف، والتحليل الاستراتيجي، ومهارات التواصل الفعال، مما يؤكد أن الهاكاثون هو منصة مثالية للمصممين لتطوير مجموعة واسعة من المهارات التي تتجاوز مجرد التصميم المرئي.