ما هي هندسة التصميم؟ وكيف يُوَسِّع الذكاء الاصطناعي دور المُصَمِّم؟

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

هنا تأتي هندسة التصميم (Design Engineering): ممارسة تجمع مهارات التصميم وتطوير الواجهات، بحيث يستطيع الشخص المشاركة في تشكيل التجربة وبنائها واختبار تفاصيلها. ومع أدوات الذكاء الاصطناعي، أصبح بإمكان مزيد من المُصَمِّمين تجربة أفكارهم بالكود. سنُوَضِّح ما يعنيه هذا الدور، وكيف يساعد AI في ممارسته، من خلال مثال افتراضي للتسجيل في ورشة تعليمية.

ما المقصود بهندسة التصميم؟

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

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

والمصطلح سابق لموجة الذكاء الاصطناعي التوليدي الحالية. ففي عام 2020 صَدَرَ دليل Design Engineering Handbook، وتُوَثِّق صفحة OddBird عن الدليل مشاركة ممارسين في مناقشة العلاقة بين التصميم والتطوير. لذلك يمكن ممارسة هندسة التصميم باستخدام أدوات برمجة معتادة؛ أما AI فيُوَسِّع الخيارات المتاحة لتَعَلُّم هذه الممارسة وتسريع بعض أعمالها.

لماذا يَتَجَدَّد الحديث عن هندسة التصميم مع الذكاء الاصطناعي؟

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

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

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

أين يختلف مهندس التصميم عن مُصَمِّم المُنْتَجات ومُطَوِّر الواجهات؟

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

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

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

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

من الفكرة إلى تجربة تعمل: مثال تسجيل في ورشة

لنفترض أننا نعمل على مِنَصَّة تعليمية عربية، ونريد تسهيل التسجيل في ورشة لها موعدان. هذا مثال تعليمي، وما سنقترحه فيه يحتاج إلى اختبار قبل اعتماده في مُنْتَج حقيقي.

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

يمكننا إعداد تصميم أَوَّلِيّ، ثم استخدام أداة AI لبناء نَمُوذَج يعمل في المُتَصَفِّح. نُوَضِّح للأداة أن الواجهة عربية، وأن المطلوب اختيار موعد وإدخال الاسم والبريد، مع حالات للانتظار والخطأ والنجاح. ونَسْتَخْدِم بيانات تجريبية، مع توضيح أن إرسال التسجيل في هذه المرحلة محاكاة.

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

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

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

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

ما الذي يجب أن نفهمه عندما يكتب AI الكود؟

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

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

لذلك لا يمكن فصل هذا الدور عن المعرفة التقنية. من المفيد فهم كيفية بناء عناصر الصفحة وتنسيقها وإضافة التفاعل إليها، ثم تَعَلُّم قراءة الكود وتَتَبُّع الأخطاء. في الويب، تُؤَدِّي HTML وCSS وJavaScript هذه الوظائف الأساسية. ويَتَحَدَّد عمق المعرفة المطلوبة بحسب ما ستبنيه وما سيتولى بَقِيَّة الفريق مراجعته وتنفيذه.

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

كيف تساعد أنظمة التصميم على ضَبْط النتيجة؟

نظام التصميم Design System يجمع المُكَوِّنات والقواعد التي يَسْتَخْدِمُها المُنْتَج بصورة مُتَكَرِّرة. وجود زِرّ وحقل إدخال ورسالة خطأ مُعْتَمَدة يمنح المُصَمِّم والأداة نقطة بداية واضحة، ويساعد على إبقاء صفحة التسجيل مُتَّسِقة مع بَقِيَّة المِنَصَّة.

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

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

يمكنك الاستفادة أيضًا من فكرة ملف UX.md لتوثيق سياق تجربة المُسْتَخْدِم في التصميم الذي تعمل عليه وفي مثالنا هنا صفحة التسجيل في الورشة، نُوَثِّق سبب إظهار المنطقة الزمنية، وما الذي يعنيه نجاح التسجيل، ثم نراجع أثر هذه التوجيهات في الواجهة.

كيف تبدأ بتطبيق هندسة التصميم في عملنا؟

اِخْتَرْ مهمة صغيرة تعرف هدفها، مثل تعديل نَمُوذَج التسجيل أو تحسين اختيار الموعد. حَدِّدْ ما تريد تَعَلُّمَه من النَّمُوذَج قبل بنائه، حتى تستطيع معرفة متى أصبحت التجربة مفيدة. وإذا كان سؤالك عن فهم المحتوى فقط، فقد تكفي مُسَوَّدة أبسط من واجهة مكتملة.

يمكن أن تبدأ بأربع خطوات:

1. اُكْتُبْ المهمة والقرار الذي تريد اختباره. مثل معرفة هل يفهم الشخص الفرق بين موعدَي الورشة والمنطقة الزمنية لكل منهما.

2. اِبْنِ نسخة محدودة من التفاعل. اِسْتَخْدِمْ أدواتك المعتادة أو AI، ودَوِّنْ الوظائف التي تعمل فعلًا وما جرت محاكاته.

3. جَرِّبْ الحالات المختلفة. راجِعْ البيانات الناقصة والطويلة، والشاشة الصغيرة، والانتظار، ومحاولة التصحيح.

4. اِخْتَبِرْ الفهم مع شخص مناسب للجمهور. اُطْلُبْ منه التسجيل في الموعد الذي يناسبه، وراقِبْ اختياره وما يعتقد أنه حدث في النهاية.

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

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

المصادر

• Design Engineering at Vercel: تعريف الدور ومسؤولياته وصور التعاون داخل الفريق.

• Design Engineering Handbook — OddBird: توثيق للدليل الصادر عام 2020.

• What Is Good Design in the Age of AI? — Figma: تقارب مهارات التصميم والتطوير.

• When Coding Becomes Conversation — Figma: مراجعة الكود المُوَلَّد وجودة التنفيذ.

• 5 Shifts Redefining Design Systems in the AI Era — Figma: توثيق السياق وتوجيه أدوات الذكاء الاصطناعي.