مصمم المنتجات مش محتاج ينافس الذكاء الاصطناعي… محتاج يشوف اللي هو مش شايفه
السؤال المنتشر حاليًا هو: هل الذكاء الاصطناعي هيستبدل مصمم المنتجات؟
لكن السؤال نفسه ناقص.
لأن المنافسة الحقيقية مش بين مصمم وأداة بتنتج واجهة أسرع منه. المنافسة بين شخص بيتعامل مع التصميم باعتباره مجموعة شاشات، وشخص فاهم إن كل شاشة هي مجرد جزء صغير من قرار أكبر له تأثير على المستخدم والبزنس والتقنية.
دلوقتي أي فريق تقريبًا يقدر يحوّل فكرة أولية إلى Prototype خلال ساعات. الأدوات تقدر تقترح Layout، وتكتب محتوى مبدئيًا، وتولّد Components، وأحيانًا تطلع نسخة تعمل داخل المتصفح.
لكنها لا تعرف وحدها هل الفكرة تستحق البناء، ولا ما الذي قد يحدث عندما يستخدمها عميل حقيقي، ولا كيف تؤثر على بقية المنتج.
وهنا تبدأ قيمة مصمم المنتجات، مش تنتهي.
المشكلة مش في إنتاج الواجهة UI، لكن في فهم عواقبها
تخيل تطبيق تقسيط سعودي يريد إضافة خيار يسمح للعميل بتأجيل القسط القادم.
من السهل توليد شاشة تعرض المبلغ، والتاريخ الجديد، وزر «تأكيد التأجيل». بصريًا، المهمة شبه مكتملة.
لكن المنتج لم يُصمم بعد.
ما الذي يحدث لو حاول العميل التأجيل بعد تاريخ الاستحقاق؟ هل التأجيل متاح لكل العملاء؟ هل توجد رسوم إضافية؟ متى تظهر الرسوم؟ ماذا لو ضغط المستخدم على التأكيد مرتين بسبب بطء الاتصال؟ وهل يفهم بوضوح أن التأجيل سيغير مواعيد الأقساط التالية؟
الأداة تستطيع رسم Modal لكل حالة، لكن يجب أن يوجد شخص يكتشف هذه الحالات أولًا، ويربطها بسياسات المنتج، ثم يقرر كيف تُشرح للمستخدم من غير تضليل أو تعقيد.
دي مش مهارة UI. دي قدرة على رؤية أثر القرار قبل ما يتحول إلى مشكلة.
المصمم الذي يركز على الشاشة سيسأل: أين نضع الزر؟
أما مصمم المنتجات فسيسأل: هل يجب أن يظهر الزر لهذا العميل أصلًا؟ وماذا يتوقع أن يحدث بعد الضغط عليه؟ وما القرار الذي يجب أن يفهمه قبل التأكيد؟
الفارق بين السؤالين هو الفارق بين تصميم واجهة وتصميم منتج.
أول قيمة حقيقية: اكتشاف المخاطر قبل وصولها للمستخدم
كل منتج يحتوي على لحظات قد يفقد فيها المستخدم ثقته. دور المصمم مش تجميل اللحظات دي بعد حدوثها، لكن اكتشافها أثناء تعريف التجربة.
لنفترض أن منصة حكومية عربية تتيح للمستخدم تقديم طلب للحصول على وثيقة رسمية. صمّم الفريق مسارًا واضحًا: إدخال البيانات، رفع المستندات، الدفع، ثم إرسال الطلب.
لكن ماذا لو انتهت جلسة المستخدم بعد رفع المستندات وقبل الدفع؟ هل سيبدأ من جديد؟ هل حُفظت ملفاته؟ هل يعرف أين يجد الطلب غير المكتمل؟
وماذا لو تم الدفع، لكن المنصة لم تستطع تحديث حالة الطلب فورًا؟ ظهور رسالة «حدث خطأ» هنا قد يدفع المستخدم إلى تكرار الدفع، بينما المشكلة الحقيقية ليست في العملية المالية نفسها، بل في تحديث حالتها داخل النظام.
التصميم الجيد في هذه الحالة ليس Alert أجمل. التصميم الجيد هو تحديد ما يعرفه النظام في كل لحظة، وما الذي نستطيع تأكيده للمستخدم، وما الإجراء الآمن الذي يمكنه اتخاذه.
المبدأ نفسه ينطبق على إمكانية الوصول.
قد تبدو صفحة تقديم الطلب منظمة، لكن ترتيب العناصر داخل الكود قد يجعل التنقل بلوحة المفاتيح يقفز بين الحقول بشكل غير منطقي. المستخدم المبصر سيرى واجهة مرتبة، بينما مستخدم لوحة المفاتيح أو قارئ الشاشة سيواجه تجربة مختلفة تمامًا.
معيار WCAG يوضح أن ترتيب التركيز يجب أن يحافظ على المعنى وقابلية الاستخدام، وليس مجرد مطابقة الشكل البصري. لذلك، مراجعة التصميم لا تكتمل بالنظر إلى Screenshot؛ يجب تجربة المسار كما سيستخدمه أشخاص مختلفون.
كلما استطاع المصمم اكتشاف هذه المخاطر مبكرًا، قلت القرارات الارتجالية أثناء التطوير، وقلّت المشكلات التي تصل إلى الدعم بعد الإطلاق.
ثاني قيمة: تحويل الرأي التصميمي إلى قرار يمكن الدفاع عنه
في فرق المنتجات، الجميع لديه رأي في الواجهة.
مدير المنتج يريد تقليل عدد الخطوات. فريق التسويق يريد إبراز العرض. المهندس يريد سلوكًا أبسط في التنفيذ. والإدارة تريد إطلاق الميزة في أسرع وقت.
لو دخل المصمم النقاش بجملة مثل «التصور ده أنظف»، فهو يضيف رأيًا جديدًا إلى مجموعة الآراء الموجودة، حتى لو كان رأيه مبنيًا على خبرة.
أما إذا قال إن المستخدم لا يفهم تكلفة الخدمة قبل التأكيد، وإن جلسات الاختبار أظهرت أن ثلاثة مستخدمين من أصل خمسة توقعوا مبلغًا مختلفًا، وإن بيانات الدعم تحتوي على شكاوى مرتبطة بالنقطة نفسها، فالنقاش يتغير.
هنا التصميم لم يعد ذوقًا. أصبح قرارًا له دليل.
تخيل متجرًا إلكترونيًا عربيًا يعاني من انسحاب العملاء عند اختيار عنوان التوصيل. الحل السريع قد يكون إعادة تصميم الصفحة بالكامل. لكن مراجعة تسجيلات الجلسات قد تكشف أن المشكلة الحقيقية ليست في شكل الصفحة، بل في أن الأحياء غير المدعومة لا تظهر إلا بعد إدخال كل البيانات.
في هذه الحالة، تغيير الألوان أو ترتيب الحقول لن يحل المشكلة. القرار المؤثر هو فحص نطاق التوصيل في وقت أبكر، ثم شرح البدائل المتاحة للعميل بوضوح.
قيمة المصمم هنا لم تأتِ من إنتاج واجهة مختلفة، بل من تحديد سبب المشكلة قبل إنفاق الوقت على حل غير مناسب.
وده لا يحتاج إلى مشروع بحث ضخم كل مرة. أحيانًا تكفي ثلاث أو أربع جلسات قصيرة، ومراجعة بيانات التحليلات، وحديث منظم مع فريق الدعم، للوصول إلى دليل أفضل من التخمين.
الأدوات يمكنها تلخيص المقابلات، وتجميع الملاحظات، واقتراح أنماط متكررة. لكنها لا تتحمل مسؤولية اختيار السؤال، ولا تعرف دائمًا إذا كان السلوك الذي تكرر مهمًا للمنتج أم مجرد تفصيلة جانبية.
المصمم يظل مسؤولًا عن تفسير الدليل، وربطه بالسياق، وتحويله إلى قرار.
ثالث قيمة: ربط المستخدم بالتقنية والبزنس
أقوى مصمم في الفريق مش بالضرورة أفضل شخص في استخدام Figma. غالبًا هو الشخص الذي يستطيع التحدث مع كل تخصص وفهم تأثير قراراته.
عندما يقول المهندس إن خدمة التحقق من الهوية قد تتأخر، يفكر المصمم في الرسالة التي ستظهر للمستخدم، وفي إمكانية استكمال التسجيل لاحقًا، وفي البيانات التي يجب حفظها.
وعندما يوضح فريق البزنس أن بعض العملاء لديهم حدود شراء مختلفة، يفكر المصمم في الوقت المناسب لعرض الحد، وكيفية شرح سبب اختلافه، وما الذي يمكن للعميل فعله إذا لم يكن كافيًا.
وعندما يوضح فريق الدعم أن المستخدمين يخلطون بين «إلغاء الطلب» و«استرداد المبلغ»، يعرف المصمم أن المشكلة ليست مجرد اختيار كلمة، بل في بناء توقع واضح لما سيحدث بعد كل إجراء.
في المنتجات المعتمدة على الذكاء الاصطناعي، الدور ده يصبح أكثر أهمية.
تخيل أداة عربية تساعد أصحاب الشركات في كتابة العقود. المستخدم قد يتعامل مع الناتج باعتباره صياغة قانونية نهائية، بينما النظام ينتج مسودة قد تحتوي على نقص أو خطأ.
تصميم الواجهة هنا لا يتوقف عند صندوق Prompt وزر «إنشاء». يجب أن توضح التجربة طبيعة الناتج، وتسمح بمراجعته وتعديله، وتُظهر مصدر المعلومات عند توفره، وتحدد الحالات التي تحتاج إلى مراجعة بشرية متخصصة.
إطار إدارة مخاطر الذكاء الاصطناعي الصادر عن NIST يتعامل مع الثقة وتقييم المخاطر كجزء من تصميم وتطوير واستخدام أنظمة الذكاء الاصطناعي، وليس كإضافة بعد إطلاقها. كما يشير ملف الذكاء الاصطناعي التوليدي إلى أهمية المراجعة البشرية والاختبار قبل النشر والتوثيق.
وده يوسّع دور المصمم: بدل تصميم شكل الإجابة فقط، يصبح مسؤولًا عن تصميم العلاقة بين المستخدم والنظام؛ متى يثق فيه، ومتى يراجعه، وكيف يصححه عندما يخطئ.
هل معنى ده إن المصمم لازم يتحول إلى Developer؟
لا.
لكن من الصعب تصميم منتج رقمي بعمق مع تجاهل طريقة عمله.
المطلوب مش أن يبني المصمم النظام كاملًا، بل أن يفهم ما يكفي لطرح أسئلة أفضل، وتجربة المنتج الحقيقي، ومراجعة التفاصيل بعد التنفيذ، والتواصل مع المهندسين من غير تحويل كل ملاحظة إلى وصف بصري غامض.
معرفة أساسيات HTML وCSS، وفهم الـComponents والـStates وطريقة انتقال البيانات، تساعد المصمم على إدراك تكلفة الحل وحدوده. كما تسمح له بإصلاح تفاصيل صغيرة عندما يكون ذلك متفقًا عليه داخل الفريق، من غير تجاوز مسؤولية المهندس عن جودة الكود ومعماريته.
الهدف من المعرفة التقنية مش إضافة لقب جديد بجانب اسم المصمم. الهدف هو تقليل المسافة بين ما تخيله وما وصل فعلًا إلى المستخدم.
وماذا عن المصمم المبتدئ؟
التحدي حقيقي، لأن جزءًا كبيرًا من العمل التنفيذي الذي كان يتعلم من خلاله المصمم المبتدئ أصبح أسرع أو قابلًا للأتمتة.
لكن محاولة إثبات القيمة من خلال عدد أكبر من الشاشات لن تحل المشكلة.
المشروع الأقوى في Portfolio مبتدئ قد يكون منتجًا صغيرًا، لكنه يوضح التفكير كاملًا: كيف عرّف المشكلة، وما الافتراض الذي اختبره، وما الذي تغيّر بعد الحديث مع المستخدمين، وكيف تعامل مع حالة خطأ أو بيانات ناقصة، وكيف قاس نجاح الحل.
شركة توظيف لن تحتاج إلى مشاهدة عشرين شاشة لتعرف إن كان المصمم يفكر جيدًا. أحيانًا تفسير قرار واحد صعب، مدعوم بدليل ومفهوم تقنيًا، يقول أكثر من مشروع كامل مبني على مسار مثالي.
القيمة انتقلت من المخرج إلى المسؤولية
الذكاء الاصطناعي جعل إنتاج الواجهة أسرع، لكنه لم يجعل قرارات المنتج سهلة.
ما زال هناك شخص يحتاج إلى فهم المشكلة، واكتشاف المخاطر، والموازنة بين احتياجات المستخدم وأهداف البزنس والقيود التقنية، ثم متابعة القرار حتى يصل إلى المنتج بصورة صحيحة.
لو كانت قيمة المصمم متوقفة على قدرته على إنتاج Screens، فمن الطبيعي أن يشعر بالتهديد من أداة تنتجها في دقائق.
أما لو كانت قيمته في قدرته على رؤية ما لا يظهر داخل الشاشة—الاستثناءات، وسوء الفهم، والمخاطر، والتأثير المتوقع—فالأداة تصبح جزءًا من طريقته في العمل، وليست بديلًا عنه.
ولو استفدت إشترك في النشرة
و حابب تتابع المسار الجديد وتوصلك الأعداد مباشرة:
https://gohodhod.com/@digital-products-newsletter
ولو وصلت لك الرسالة من صديق، اشترك علشان تتابع باقي السلسلة من البداية أو باللغة الإنجليزية من الموقع هنا .
التعليقات