تخيَّل تطبيق للحجوزات حيث يقوم العميل بتغيير موعده قد أخذه سابقًا، ولكن عند التغير التطبيق لم يُقدِّم للعميل حالة تُوضِّح أن الحجز تغيَّر فعليًا، لذلك يتصل العميل بالشركة حتى يستفسر عن وضع حجزه. هنا لدينا مشكلة وقد يكون مُصمِّم المُنتَج هو المسؤول عن التعامل معها في الشركة.
تصميم المنتجات الرقمية (Digital Product Design) هو عملية تخطيط وتصميم منتج رقمي مثل (تطبيق، موقع، منصة، أو نظام برمجي) من أول فكرة حتى تجربة قابلة للاستخدام، بحيث يحل مشكلة حقيقية للمستخدم ويحقق أهداف الجهة التي تبنيه.
ماذا يفعل المُصمِّم قبل الرسم؟
في مثالنا الافتراضي، لا نعرف بعد سبب الاتصال بالدعم. قد يكون الوصول إلى التعديل صعبًا، أو قد لا توجد مواعيد بديلة، أو تكون رسالة التأكيد غير واضحة.
يراجع المُصمِّم ما يعرفه الفريق: أسئلة الدعم، وبيانات الاستخدام المتاحة، وطريقة تعديل الحجز الحالية. ثم يتعاون مع الباحث أو يشارك في البحث بحسب دوره وخبرته، ليفهم ما يحدث عند محاولة تغيير الموعد.
لنفترض، لأغراض الشرح، أن الملاحظة كشفت أن العميل يُكمِل التعديل لكنه لا يعرف هل أُلغيَ الموعد السابق. أصبحت المشكلة أوضح، حيث أن مفهوم الحالة السابقة ليس واضح للمُستخدِم بشكل كافي، لذلك يتحرَّك مُصمِّم المُنتَجات بناءً على هذه النتائج.
من المشكلة إلى حَلّ قابل للاختبار
دور المُصمِّم الآن هو أن يقترح شاشة تأكيد تعرض الموعد الجديد، وتُوضِّح أن الموعد السابق استُبدِل به. ويناقش مع المُطوِّر متى يمكن إظهار هذه الرسالة: هل اكتمل التعديل فعلًا، أم أن الطلب ما زال قيد المعالجة؟ هذا النقاش من الناحية التقنية.
ثم يُعِدّ نموذجًا أوليًا يستطيع الشخص استخدامه لتغيير موعد تجريبي. نطلب منه إتمام المهمة، وبعدها نسأله عمّا يعتقد أنه حدث. إذا ظنّ أن لديه حجزين، فالتصميم لم يُوضِّح النتيجة بما يكفي.
قد يُعدِّل المُصمِّم التسمية أو ترتيب المعلومات أو طريقة عرض الحالة. ليس المطلوب الدفاع عن الفكرة الأولى، بل الوصول إلى حَلّ يفهمه الشخص ويمكن للفريق تنفيذه.
ويظهر هذا الربط بين البحث والقرارات والنماذج ومراجعة التنفيذ في وصف دور مُصمِّم المُنتَج لدى GitLab. وهو مثال على تنظيم الدور في شركة، لا تعريف مُلزِم لجميع الفرق.
ما المُخرَجات التي يُسلِّمها؟
تختلف المُخرَجات بحسب المشكلة. في مثال تغيير الموعد، يحتاج الفريق إلى أكثر من صورة لشاشة النجاح:
شرح المشكلة: العميل لا يعرف إن كان الموعد القديم أُلغيَ بعد التعديل.
تدفُّق الاستخدام: الخطوات من فتح الحجز إلى اختيار البديل وظهور النتيجة.
نموذج أولي: نسخة يمكن تجربتها قبل بناء التفاصيل كاملةً.
واجهات وحالات: ما يظهر أثناء التحميل والنجاح والتعذُّر، وعند عدم وجود بدائل.
نصوص وقواعد: متى تُعرَض كل رسالة، وما الذي يستطيع الشخص فعله بعدها.
ملاحظات التحقُّق: ما الذي فهمه المشاركون، وما الذي يحتاج إلى تعديل أو متابعة.
لا يجب إنتاج هذه الأشياء كلها في كل مهمة. تغيير تسمية واضحة قد لا يحتاج إلى نموذج مُفصَّل، بينما تغيير خطوات الحجز يحتاج إلى فهم العلاقات بين الحالات، أي أنك أنت كمُصمِّم تُحدِّد ما هو المطلوب للتسليم بحسب تعقيد وحاجة المهمة نفسها.
المهم أن يستطيع الفريق تنفيذ القرار وفهم سببه. ويشرح دليل تصميم واجهات الاستخدام كيف تتحوَّل الفكرة إلى واجهة بحالات واضحة قابلة للتنفيذ.
ما علاقته بـ UI وUX؟
تصميم واجهات الاستخدام (UI) يهتم بما يراه الشخص ويتفاعل معه: ترتيب العناصر، والأحجام، والتباين، والمُكوِّنات وحالاتها وإنشاء نظام تصميم. في مثالنا، يشمل إبراز الموعد الجديد وجعل حالة الموعد السابق واضحة للمُستخدِم.
أما تجربة المُستخدِم (UX) فالموضوع أشمل ويُركِّز على التفاعل مع المُنتَج وتحديد طريقة التنقُّل والمعلومات التي سوف تظهر ومتى، هذه كلها جزء من تفاصيل تجربة المُستخدِم. يمكنك التوسُّع في شرح تصميم تجربة المُستخدِم.
ويختصّ باحث المُستخدِمين بالبحث عن المعلومات المُتعلِّقة التطبيق، وتحليل المنافسين وفهم المُستخدِمين وغيرها. في مثالنا، يساعد على اختيار المشاركين وصياغة المهمة وفهم ما لاحظناه، بدل تحويل انطباع من مقابلة واحدة إلى حقيقة عامة.
مُصمِّم المُنتَج يجمع هذه المعارف في قرارات التصميم أي أنه يلعب أكثر من دور واحد في نفس الوقت، بالإضافة إلى أنه يتواصل بشكل مباشر مع أصحاب القرار في الشركة بهدف معرفة أهداف الشركة المطلوبة ضمن هذه المُنتَج وذلك من أجل التأكد من تحقيق المُنتَج لهذه الأهداف، أي أن دوره لا يقتصر فقط مع المُستخدِم مثل الأدوار السابقة وإنما أيضاً يعمل مباشرة مع المسؤولين في الشركة لتحقيق أهداف الشركة.
لكن المُسمَّيات تتداخل بين الشركات المختلفة؛ قد يقوم شخص بعنوان «مُصمِّم UX» بعمل واسع يشبه دور مُصمِّم المُنتَج، أي أنه حتى الآن لا يوجد عُرف واضح ومُحدَّد لكل تسمية وظيفية مُتَّفَق عليها ضمن كل الشركة، الأمر واسع ويختلف من شركة لأخرى، ولكن الأمور تدور في المجال الذي تكلَّمنا عنه بشكل عام.
ما فرق مُصمِّم المُنتَج عن مدير المُنتَج؟
يساعد مدير المُنتَج الفريق على تحديد الاتجاه والأولويات والنتائج المطلوبة، مع مراعاة المُستخدِمين والعمل والموارد. يناقش دليل Atlassian هذه المسؤوليات وتغيّر تفاصيلها بحسب الفريق، حيث يلعب مدير المُنتَج دور أكبر من متابعة نتائج كل ميزة يتم العمل عليها ويُخطِّط في كل أطراف الفريق مثل التطوير والتسويق والمبيعات من أجل تنفيذ الميزات وتطوير المُنتَج بشكل عام.
في مثال الحجوزات، يناقش مدير المُنتَج أولوية تقليل اتصالات التأكيد مقارنةً بمشكلات أخرى. ويساعد المُصمِّم على فهم سبب الالتباس وتجربة الحلول. ويُوضِّح للمُطوِّر ما يحتاجه النظام حتى يعرض حالة الحجز بدقة.
هذه ليست عملية يكتب فيها المدير الطلب ثم يُمرِّره إلى المُصمِّم والمُطوِّر دون نقاش. قد يكشف البحث أن الطلب الأصلي لا يعالج المشكلة، وقد يُغيِّر القيد التقني شكل الحَلّ. أي أن دور مدير المُنتَج ليس فقط إرسال المهام وإنما مناقشتها ومتابعتها مع كل الأقسام التي تعمل في الشركة.
كيف يختلف الدور بين الفرق؟
في فريق صغير، قد يعمل المُصمِّم على البحث والواجهات والنصوص والنماذج. هذا لا يجعله مُتخصِّصًا عميقًا في كل مجال؛ وحيث يحتاج إلى معرفة متى يطلب مساعدة، وما حدود خبرته.
أما في فريق أكبر، قد يوجد باحث وكاتب محتوى ومُصمِّم واجهات أو فريق لنظام التصميم. عندها يتوزَّع العمل، ويصبح توضيح المسؤوليات والتعاون بينها مهمًا.
اسأل قبل بدء المشروع: من يجمع الدليل؟ من يراجع النص؟ من يختبر التنفيذ؟ ومن يتابع النتيجة؟ هذه الإجابات أفيد من الاتفاق على مُسمّى وظيفي ثم افتراض أن الجميع يفهمه بالطريقة نفسها.
ما المهارات التي تحتاجها؟
تحتاج إلى فهم المُستخدِمين، وترتيب المعلومات، وتصميم التفاعل والواجهات، وبناء نماذج تساعد على الاختبار. وتحتاج أيضًا إلى شرح قراراتك، وفهم القيود التقنية، والتعاون مع الفريق دون تحويل النقاش إلى تفضيلات شخصية، أي أن دور مُصمِّم المُنتَجات في الوقت الحالي هو أشمل من دور مُصمِّم UI/UX، لذلك يجب أن تمتلك خبرات أوسع بشكل عام.
إذا كنت تستكشف هذا المسار، خذ مهمة صغيرة مثل تغيير موعد. حاول فهمها، وارسم حَلًّا، ثم اطلب من شخص مناسب تجربته. لاحظ هل تستمتع بفهم سبب التعثُّر ومراجعة قرارك، إلى جانب رسم الشاشة. هذه تجربة أقرب إلى طبيعة العمل من تعلُّم الأداة وحدها.
المصادر
تاريخ النشر
16 أكتوبر 2026
آخر تعديل
16 أكتوبر 2026
