كيف تصبح مصمم AI ؟

في مقال نشره UX Collective، تعرض Maya Brennan تصوراً عملياً لما تسميه AI-native design، مستنداً إلى تجربتها ضمن فريق يبني منتجاً جديداً في Amplitude. بالنسبة إليها، لم يعد دور المصمم يقتصر على إعداد الشاشات وتسليمها، بل يمكن أن يمتد إلى تجربة التدفقات التفاعلية في كود سريع، والمشاركة في تحسين الواجهة داخل المنتج نفسه.

تبدأ التجربة من مشكلة مألوفة في الفرق التي تتحرك بسرعة: ملفات Figma وشاشات الـ prototype الدقيقة قد لا تلحق بالتغييرات اليومية في المنتج. لذلك تقترح Brennan تجربة الابتعاد المؤقت عن Figma، لا باعتباره أداة انتهى دورها، بل لكسر روتين التصميم التقليدي واختبار وسائل أسرع لاستكشاف الفكرة.

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

لاحقاً، انتقلت إلى مزيج من النماذج منخفضة وعالية الدقة باستخدام Claude Design، بحسب نوع الملاحظات المطلوبة. لكنها واجهت سؤالاً تنظيمياً مهماً: أين توجد النسخة المعتمدة من التصميم إذا كانت النماذج والكود يتغيران باستمرار؟ استخلصت من تجربتها أن المنتج المنشور نفسه قد يصبح الـ Source of Truth للتصميم، بدلاً من أن تكون ملفات التصميم وحدها المرجع النهائي.

هذا التحول قادها إلى طلب الوصول إلى codebase والمساهمة في الـ frontend. وهي لا تقصد أن يبني المصمم الواجهة كاملة أو يحل محل مهندس frontend، بل أن يتولى قرارات الواجهة ويستطيع تنفيذ بعض التعديلات ذات الصلة بالتصميم، مثل التفاصيل البصرية والتفاعلات والاستجابة، ثم يراجع Pull Requests الخاصة بالواجهة بالتعاون مع فريق الهندسة.

وتشدد Brennan على أن العائق الأصعب ليس كتابة الكود بحد ذاتها، بل الحصول على الدعم والصلاحيات والسياق التقني المناسب. من اقتراحاتها للفرق: البدء بتغييرات UI صغيرة، وتوضيح أن الهدف ليس إنتاج PRs عشوائية تزيد عبء المراجعة، بل تقليل بعض الأعمال البصرية المتكررة عن مهندسي frontend، والعثور على شريك هندسي يساعد في إعداد البيئة ومراجعة الممارسات.

كخيار أقل احتكاكاً، تقترح البدء بـ coding agent bot داخل مساحة الرسائل في الشركة، بحيث يطلب المصمم تعديلات صغيرة على الكود من دون إعداد GitHub أو Repository أو بيئة تطوير منذ اليوم الأول. أما من لا تتوفر له هذه البيئة في العمل، فترى أن بناء مشاريع شخصية بأدوات مثل V0 وLovable، ثم الانتقال تدريجياً إلى Cursor وClaude Code، يمكن أن يوفر مساحة للتعلم العملي.

لكن المقال لا يقدم السرعة بوصفها مكسباً بلا ثمن. فالكاتبة تصف شعوراً بالإرهاق من التنقل بين prompts وagents وPRs، وبنوع من الابتعاد عن الحرفة الإبداعية التي كانت تجدها في العمل المركز داخل Figma. وخلاصتها واضحة: يمكن لـ AI أن يسرّع الإنتاج ويزيد عدد التجارب، لكنه لا يسرّع الإبداع ولا يحاكي الذائقة التي تتكون من الوقت والخبرة والممارسة.

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