Skip to content

نموذج التصميم بالألماسة المزدوجة

بعد تحليل الاحتياجات ومقابلات المستخدمين، تتجمع لدينا عادةً مواد كثيرة: تجارب مستخدمين مختلفين، ومشكلات الأدوات الحالية، وعدة اتجاهات محتملة للتحسين. وعندما تكثر المواد، تصبح المفاضلة بينها هي الصعوبة الجديدة.

إذا لم نفصل بين «فهم المشكلة» و«تصميم الحل»، فمن السهل أن نجري المقابلات ونحن نبحث عن مبررات للوظيفة التي نفضّلها. يفصل نموذج الألماسة المزدوجة (Double Diamond) بين هذين النوعين من العمل عبر مرحلتين من التوسّع ثم التضييق.

يشرح هذا الفصل مراحل Discover وDefine وDevelop وDeliver، ويوضح مدخلات كل مرحلة ومخرجاتها وأخطاءها الشائعة.

1. دورتان من التوسّع والتضييق

نموذج الألماس المزدوج هو إطار عمل تصميم كلاسيكي روجت له Design Council البريطانية. يرسم عملية التصميم والابتكار الكاملة في شكل ألماسين متتاليين.

السبب في كونه "ألماسًا" هو أن كل ألماس يحتوي على نوعين من الأفعال المتعاكسة لكنها مهمة بنفس القدر:

  • التوسع: افتح الأفق أولاً، وانظر إلى المزيد من الاحتمالات
  • التضييق: ثم ضيق النطاق، واتخذ القرارات والتضحيات

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

  1. Discover: فهم واسع للمستخدمين والمشاكل والبيئة والسوق
  2. Define: استخلاص المشكلة الأساسية التي تستحق الحل حقًا من كمية كبيرة من المعلومات
  3. Develop: تطوير حلول متعددة متنوعة حول المشكلة الأساسية
  4. Deliver: الفرز، صنع النماذج الأولية، الاختبار، وتسليم الحل الأنسب

تعالج المرحلتان الأوليان فضاء المشكلة، وتعالج المرحلتان الأخيرتان فضاء الحل.

الرسم الرسمي للألماسة المزدوجة من Design Council
لنبدأ بالرسم الأصلي. تتوسع الألماسة اليسرى من Discover ثم تضيق عند Define، وتتوسع اليمنى من Develop ثم تضيق عند Deliver. وليست العملية خطًا يسير إلى الأمام مرة واحدة؛ يمكن العودة عندما يكشف الاختبار مشكلة. المصدر: Design Council، بترخيص CC BY 4.0.

إذا ضغطت هذه الخطوات الأربع في جملة واحدة أسهل في التذكر، فهي:

  • الألماس الأول: أوضح أولاً ما هي المشكلة التي يجب حلها بالضبط
  • الألماس الثاني: ثم قرر بأي حل ستحلها

وهذه هي الجملة الدقيقة التي قلتها:

  • الألماس الأول: عمل الشيء الصحيح
  • الألماس الثاني: عمل الشيء بشكل صحيح

2. لماذا نفصل المشكلة عن الحل

الإيقاع الأكثر شيوعًا بين المبتدئين عند صنع المنتجات غالبًا ما يكون هكذا:

  • التفكير في فكرة
  • الشعور بأن هذا الاتجاه رائع
  • البدء فورًا في رسم النموذج الأولي
  • أثناء العمل، اكتشاف أن الوظائف تزداد أكثر فأكثر
  • في النهاية، عدم المعرفة ما هي المشكلة التي يتم حلها بالضبط

قيمة نموذج الألماس المزدوج ليست في جعل العملية معقدة، بل في إجبارك على فصل "فهم المشكلة" و"تصميم الحل".

هذا الأمر يبدو عاديًا، لكنه مهم جدًا في الواقع. لأن العديد من المنتجات الفاشلة لم تفشل لأن التنفيذ لم يكن جادًا، بل لأن:

  • تم اختيار المشكلة الخاطئة
  • تم سوء فهم المستخدم
  • تم تثبيت الحل مبكرًا جدًا
  • تم إنفاق الكثير من الوقت في صقل التفاصيل، دون التحقق من الاتجاه

نموذج الألماس المزدوج يذكرك باستمرار:

  • لا تفترض أن المشكلة ثابتة لمجرد أن الفكرة مريحة
  • لا تفترض أن الحل يستحق التنفيذ لمجرد أنه يمكن صنعه
  • لا تفترض أن المستخدم سيحتاجه حقًا لمجرد أن النموذج الأولي يبدو كاملًا

3. الألماسة الأولى: فضاء المشكلة

الألماس الأول يركز على المشكلة نفسها، وليس الحل.

يمكنك فهمه كجملة واحدة: لا تستعجل في العمل، أوضح أولاً ما إذا كان يستحق العمل أم لا.

3.1 Discover: افتح مساحة المشكلة أولاً

المهمة الأساسية لمرحلة Discover هي البحث الواسع، وليس الاستنتاج السريع.

ما يتم فعله عادةً في هذه الخطوة يشمل:

  • مشاهدة كيف يعمل المستخدمون في السيناريوهات الحقيقية
  • مقابلة المستخدمين المحتملين، ومعرفة متى واجهوا المشكلة آخر مرة
  • مراقبة كيف يتدبرون الأمر حاليًا
  • النظر إلى كيفية تعامل المنافسين والبدائل
  • جمع معلومات السوق والعمليات والقيود وسلسلة القيمة

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

مثلاً، إذا كنت تريد صنع أداة "AI يساعد في تنظيم محاضر الاجتماعات"، ففي مرحلة Discover يجب أن تركز أكثر على:

  • أين يكون المستخدم في أكثر ألم بعد الاجتماع
  • هل الصعوبة في التدوين، أم في التنظيم، أم في المشاركة
  • هل يكتبون بأنفسهم، أم يجعلون المتدربين يكتبون، أم يستمعون للتسجيل مرة أخرى، أم لا ينظمون أبدًا
  • أي سيناريوهات الاجتماعات تحتاج أكثر لمحاضر، وأيها لا تحتاج أبدًا

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

ورشة بحث لدى Creative Commons مع أوراق وملاحظات كثيرة
مواد Discover الحقيقية تكون متنوعة. أجرى فريق Creative Commons عام 2018 عدد 81 مقابلة، ونظم 36 مقابلة سابقة. تمثل الأوراق الأسئلة والملاحظات إجابات المشاركين والنقاط وسيلة للمقارنة. حافظ الفريق هنا على الاختلافات ولم يختزلها مبكرًا في إجابة واحدة. الحالة والصورة: Creative Commons، بترخيص CC BY 4.0.

3.2 Define: استخلص المشكلة الأساسية من كومة المعلومات

إذا كان Discover هو فتح الأفق، فإن Define هو بدء التضييق.

ما يجب فعله في مرحلة Define ليس الاحتفاظ بكل الملاحظات، بل السؤال:

  • أي مشكلة هي الأكثر استحقاقًا للحل أولاً
  • أي مشكلة هي الأكثر تكرارًا والأكثر ألمًا والأكثر قيمة
  • أي سيناريو سنستهدفه فقط في النسخة الأولى

جوهر هذه الخطوة هو تحويل موضوع واسع إلى تعريف مشكلة واضح.

مثلاً، في البداية قد تقول:

أريد صنع أداة AI لتحسين كفاءة الاجتماعات.

في مرحلة Define، قد يصبح التعبير الأفضل:

سنحل أولاً مشكلة عدم قدرة فرق المشاريع على إخراج محضر يتضمن المهام والمسؤولين والمواعيد النهائية في غضون 10 دقائق بعد اجتماعات التعاون التي تستمر من 30 إلى 60 دقيقة.

هنا تبدأ المشكلة في الوضوح:

  • من هو المستخدم
  • ما هو السيناريو
  • ما هو العائق
  • ما هو معيار النجاح

جوهر Define هو التضييق من "مشاكل كثيرة" إلى "أي مشكلة سنحلها أولاً هذه المرة".

فريق Creative Commons يرتب ملاحظات المقابلات ويجمعها حسب الموضوع
Define ليس اختيار العبارة الأكثر جاذبية. جمع الفريق 117 مقابلة وصنّفها وبحث عن الأنماط المتكررة، ثم استخلص 9 رؤى. تمثل المجموعات والألوان الطريق من الإجابات الخام إلى الموضوعات والأولويات. الحالة والصورة: Creative Commons، بترخيص CC BY 4.0.

4. الألماسة الثانية: فضاء الحل

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

4.1 Develop: تطوير حلول متنوعة حول المشكلة الأساسية

تركيز مرحلة Develop هو استكشاف حلول محتملة متعددة حول نفس المشكلة.

لاحظ أن التوسع هنا يختلف عن مرحلة Discover.

  • توسع Discover هو استكشاف مساحة المشكلة
  • توسع Develop هو استكشاف مساحة الحلول

بالعودة إلى مثال محاضر الاجتماعات، في مرحلة Develop، يمكنك البدء في التفكير:

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

هذه الخطوة مناسبة جدًا للعصف الذهني، ومناسبة جدًا أيضًا للعمل مع الفريق لفتح الحلول.

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

لوحة حلول من ورشة تفكير تصميمي لدى Wikimedia Deutschland
تحتفظ Develop بعدة إجابات أولًا. وُزعت الأفكار المرشحة بحسب الموضوع ولم تتحول بعد إلى قائمة وظائف واحدة. قيمة التوسّع ليست عدد الملاحظات، بل مقارنة مسارات مختلفة قبل الاختيار. الصورة: Corinna Schuster (WMDE) / Wikimedia Commons، بترخيص CC BY-SA 4.0.

4.2 Deliver: اختيار الحل، صنع النموذج الأولي، الاختبار والتسليم

مرحلة Deliver هي مرحلة التضييق في الألماس الثاني.

ما يجب عليك فعله هنا ليس الاستمرار في التفكير في المزيد، بل بدء الحكم:

  • أي حل هو الأنسب للمرحلة الحالية
  • أي نسخة هي الأصغر لكنها الأكثر فائدة
  • أي الوظائف يجب تنفيذها أولاً وأيها يمكن تأجيله
  • كيفية صنع نموذج أولي واختباره والتحقق منه على نطاق صغير

العديد من الأشخاص يعتقدون أن Deliver يعني "الإطلاق". في الواقع معناه الأكثر دقة هو: تحويل حل إلى شيء قابل للاختبار والتحقق والتكرار.

قد يكون:

  • مخطط تدفق منخفض الدقة
  • نموذج أولي Figma
  • MVP قابل للتشغيل
  • اختبار مستخدمين على نطاق صغير
  • نسخة مكررة بعد تغذية راجعة حقيقية

تركيز Deliver ليس "التسليم المثالي"، بل وضع الحل في بيئة حقيقية للتحقق في أسرع وقت ممكن.

شخص يكتب في حقل إدخال على نموذج أولي ورقي
قابلية الاختبار لا تعني اكتمال الكود. يسمح النموذج الورقي للمشارك بالنقر والكتابة، ثم يبدّل الباحث الصفحة التالية. وهذا يكفي لفحص المسار والنص وترتيب العمليات، قبل قضاء أسابيع في تنفيذ اتجاه قد يكون خاطئًا. الصورة: d_jan / Wikimedia Commons، بترخيص CC BY 2.0.

5. الفرق بين المراحل الأربع

بعد أن ناقشنا المراحل الأربع، يضعها الشكل التالي ضمن عملية واحدة. اختر مرحلة وقارن بين عملها ومخرجاتها وما لا ينبغي فعله فيها مؤقتًا.

مقارنة المراحل الأربع

قارن العمل والمخرجات في كل مرحلة

اختر مرحلة لعرض العمل المطلوب فيها.

Problem divergenceWhat have we not seen yet?
ما يجب فعله الآن

Observe users in context, interview them, and collect workarounds and unusual moments.

مخرجات المرحلة

Context notes · Problem list · Behavioral evidence

ليس الآن

Do not explain causes too early or start prototyping.

إذا كنت دائمًا تخلط بين المراحل الأربع، يمكنك حفظ هذا الإصدار مباشرة:

المرحلةماذا تفعلالكلمات المفتاحيةالمخرجات الشائعة
Discoverفهم المشكلةبحث، مراقبة، مقابلات، جمع معلوماترؤى المستخدمين، ملاحظات السيناريوهات، قائمة المشاكل
Defineتعريف المشكلةاستخلاص، تركيز، تضحيات، إعادة صياغة المشكلةتعريف المشكلة، الأولويات، نقطة دخول MVP
Developاستكشاف الحلولعصف ذهني، مقارنة، إبداع مشترك، تصور النماذج الأوليةقائمة الحلول، مخططات التدفق، اتجاهات النماذج الأولية
Deliverالتحقق من الحلولنموذج أولي، اختبار، تكرار، تسليمنموذج أولي، تغذية راجعة من الاختبار، نسخة محسنة

وإذا ضغطنا أكثر، فهذا هو الشكل:

  • Discover / Define: حل "عمل الشيء الصحيح"
  • Develop / Deliver: حل "عمل الشيء بشكل صحيح"

6. أخطاء نموذج الألماس المزدوج الأكثر شيوعًا

6.1 Discover لم يكتمل بعد، وتم الانتقال مباشرة إلى Deliver

هذا هو الأكثر شيوعًا. العديد من الأشخاص بمجرد أن تكون لديهم فكرة يبدأون في رسم النماذج الأولية وكتابة PRD وتوصيل النماذج وصنع الصفحات.

المشكلة ليست أنك لا تعمل بجدية، بل أنك ربما لم تؤكد بعد ما إذا كانت المشكلة تستحق الحل.

6.2 Discover لفترة طويلة، لكن Define لا يحدث أبدًا

النوع الآخر من المتطرفين هو البحث المستمر، والاطلاع المستمر على المواد، والمقابلات المستمرة، لكن عدم الجراءة على التضييق.

الألماس المزدوج ليس لجعلك تتوسع إلى ما لا نهاية، بل لتذكيرك: بعد التوسع يجب الدخول في الحكم والتضحيات.

6.3 بعد Define، يتم تعديل المشكلة سرًا

العديد من الفرق في مرحلة Develop، بسبب سهولة حل معين، تقوم بتعديل تعريف المشكلة بشكل عكسي ليتوافق مع الحل الموجود.

هذا خطير جدًا. لأنك ربما لا تحل المشكلة، بل تبحث عن مبرر للحل الذي تفضله.

6.4 سوء فهم Deliver على أنه "إطلاق شامل"

Deliver لا يعني أنه لا يُعد منتهيًا إلا بعد إكمال المنتج بالكامل. في كثير من الأحيان، نموذج أولي قابل للاختبار، أو جولة تجريب مستخدمين حقيقيين، هي بالفعل deliver جيد.

7. في منتجات AI، كيفية استخدام نموذج الألماس المزدوج

منتجات AI عرضة بشكل خاص للوقوع في فخ "القدرات أولاً"، لأن قدرات النموذج تبدو مغرية جدًا. ستشعر برغبة قوية في التفكير مباشرة:

  • هل يتم توصيل الوسائط المتعددة
  • هل يتم عمل Agent
  • هل يتم إضافة سير عمل
  • هل يتم توصيل الصوت والصور والبحث عبر الإنترنت

لكن نموذج الألماس المزدوج سيجبرك على السؤال أولاً:

  • أين يعلق المستخدم حقًا
  • هل هذه النقطة العائقية تتطلب AI حتمًا
  • إذا لم يتم استخدام AI، فأين أسوأ جزء في الطريقة الحالية
  • بعد إضافة AI، ما هو التقدم الأساسي

هذا يساعدك في تجنب حالة شائعة: قدرات قوية جدًا، لكن القيمة ضعيفة جدًا.

ترتيب عملي هو:

  1. في مرحلة Discover، راقب كيف يتعامل المستخدمون مع المهام حاليًا
  2. في مرحلة Define، اكتب السيناريو الأكثر ألمًا كتعريف مشكلة واضح
  3. في مرحلة Develop، قارن أي قدرات AI هي الأنسب لخدمة هذه المشكلة
  4. في مرحلة Deliver، اصنع أصغر نسخة ودع المستخدمين الحقيقيين يختبرونها

8. قالب ألماس مزدوج يمكن استخدامه مباشرة

إذا كنت تصنع منتجك الخاص، يمكنك البدء بالكتابة وفقًا لهذا الترتيب:

Discover

  • من هم المستخدمون الذين لاحظتهم؟
  • متى واجهوا هذه المشكلة آخر مرة؟
  • كيف يحلونها حاليًا؟
  • أين يكون أكثر ما يزعجهم وأبطأهم وأقل ما يطمئنهم؟

Define

  • من بين هذه المشاكل، أيها الأكثر استحقاقًا للحل أولاً؟
  • أي سيناريو هو الأكثر تكرارًا أو الأكثر أهمية؟
  • من سنخدم في النسخة الأولى فقط، وماذا سنحل فقط؟
  • بعد الحل الناجح، ماذا سيتغير في حالة المستخدم؟

Develop

  • بالنسبة لهذه المشكلة، ما هي الحلول المحتملة؟
  • أي الحلول هي الأخف والأسرع والأسهل للتحقق؟
  • أيها يجب عمله، وأيها يمكن تأجيله؟

Deliver

  • ما هو أصغر شيء يمكننا تسليمه للتحقق من هذا الاتجاه؟
  • هل هو مخطط تدفق، أم نموذج أولي، أم MVP؟
  • من نحتاج لاختباره؟
  • بعد الاختبار، كيف نحكم على ما إذا كنا سنستمر أم نعدل أم نتخلى؟
مشاركون في ورشة تفكير تصميمي لويكيميديا ألمانيا يطوّرون حلولًا معًا
مرحلة Develop لا تعني انتظار فكرة مثالية. عندما تتحول الأفكار سريعًا إلى أشياء مرئية، يصبح من الأسهل مقارنتها ودمجها واستبعادها. الصورة: Corinna Schuster (WMDE)، CC BY-SA 4.0.

9. مثال يمكن فهمه حتى من المبتدئين تمامًا

لنفترض أنك تريد صنع أداة AI "تساعد طلاب الجامعات في إعداد سيرهم الذاتية للبحث عن عمل".

العديد من الأشخاص في البداية سيدخلون مباشرة في الألماس الثاني، ويبدأون في التفكير:

  • هل يتم تجميل تلقائي بنقرة واحدة
  • هل يتم إعادة كتابة ذكية
  • هل يتم مطابقة تلقائية مع وصف الوظيفة
  • هل يتم توليد مقدمة ذاتية

لكن وفقًا لنموذج الألماس المزدوج، العملية الأفضل ستكون:

الألماس الأول

Discover

  • تحدث مع الخريجين الجدد عن متى عدلوا سيرتهم الذاتية آخر مرة
  • انظر كيف يحولون سيرتهم القديمة إلى نسخة جديدة
  • افهم ما يزعجهم أكثر: "لا أعرف كيف أكتب" أم "لا أعرف كيف أعدل" أم "لا أعرف كيف أحكم على جودتها"

Define

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

الألماس الثاني

Develop

  • فكر في عدة حلول: مكتبة قوالب، إعادة كتابة AI، مقارنة مع الوظيفة، تقييم السيرة الذاتية، مراجع حالات

Deliver

  • النسخة الأولى فقط "إعادة كتابة نقاط الخبرة بناءً على وصف الوظيفة"
  • جربها مع 5 طلاب، وانظر ما إذا كانوا سيقدمون النسخة الأولى من سيرتهم الذاتية بشكل أسرع

ستكتشف أنه بمجرد أن يتم تنفيذ الألماس الأول بشكل متين، سيكون الألماس الثاني أوضح بكثير.

نموذج أولي مرسوم يدويًا لـ Mitmach-O-Mat من ورشة ويكيميديا ألمانيا
يكفي في البداية أن يجيب النموذج الأولي عن سؤال واحد. حتى من دون نظام بصري مكتمل، يمكن ملاحظة ما إذا كان المشارك يفهم الخطوة التالية. النموذج: Corinna Schuster / WMDE، CC BY-SA 4.0.

10. استخدام AI ضمن عملية الألماسة المزدوجة

نموذج الألماس المزدوج نفسه ليس أداة AI، لكن AI مناسب جدًا ليكون "مسرعًا" في المراحل الأربع. المفتاح ليس جعل AI يتخذ القرارات بدلاً منك، بل جعله يساعدك في توسيع الأفق وتنظيم المعلومات ومقارنة الحلول وتوليد مواد التحقق.

11.1 في مرحلة Discover، استخدم AI للقيام بجولة تمهيدية للمعلومات

قبل المقابلات والبحث الرسمي، يمكنك جعل AI يساعدك في عمل مسح خفيف للمشاكل، مثلاً:

  • ما هي البدائل الشائعة في السوق
  • عما يشكو المستخدمون أكثر في المجتمعات العامة
  • في أي سيناريوهات ومجموعات تظهر هذه المشكلة عادةً
  • ما الذي تتجاهله المنتجات الحالية عادةً

هذه الخطوة لا يمكنها استبدال البحث الحقيقي، لكنها مناسبة جدًا لمساعدتك في بناء خريطة مشاكل بسرعة.

إدخال بسيط للمبتدئين يمكن أن يكون:

text
أريد صنع أداة تساعد طلاب الجامعات في تعديل سيرهم الذاتية.
لا تساعدني في التفكير في الوظائف أولاً، بل ساعدني في رؤية ما هي المشاكل الأكثر شيوعًا التي يواجهها الناس في هذه المسألة.

AI قد يخرج:

text
خريطة المشاكل الأولية:

1. لا أعرف ما هي الخبرات التي يجب كتابتها
2. لا أعرف كيف أعدل لتناسب الوظيفة
3. عدلت عدة نسخ لكنني لا أزال غير متأكد مما إذا كانت جيدة بما فيه الكفاية
4. أحتاج شخصًا يراجع لي، لكن من المحرج أن أزعج الآخرين في كل مرة
5. بسبب عدم اليقين، أؤخر التقديم دائمًا

هدف هذا النوع من المخرجات ليس أن يستنتج بدلاً منك، بل أن يساعدك في الدخول إلى Discover بشكل أسرع.

11.2 في مرحلة Define، دع AI يساعدك في تضييق تعريف المشكلة

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

text
فيما يلي ملاحظات البحث وتغذية المستخدمين التي جمعتها في مرحلة Discover:
[ألصق المحتوى]

ساعدني في ثلاثة أشياء:
1. تلخيص أنماط المشاكل الأكثر تكرارًا
2. ترتيب 3 مشاكل تستحق الحل أولاً حسب تكرار المشكلة وشدة الألم وقابلية التحقق
3. اكتب كل مشكلة كتعريف مشكلة محدد في جملة واحدة

هذا سيساعدك على الدخول إلى Define بشكل أسهل، بدلاً من البقاء في حالة "المشاكل كثيرة".

يمكنك حتى كتابة الإدخال ببساطة شديدة:

text
المشاكل التي جمعتها حاليًا هي:
1. الجميع لا يعرف ماذا يكتب في السيرة الذاتية
2. الجميع لا يعرف كيف يعدل
3. الجميع يشعر دائمًا بأنه لم يعدل بشكل جيد ويخاف من التقديم

ساعدني في رؤية أي مشكلة أنسب للحل أولاً في النسخة الأولى.

AI قد يخرج:

text
المشكلة المقترح حلها أولاً:

"الطالب الذي يقدم على تدريب لأول مرة، غير متأكد مما إذا كانت سيرته الذاتية قد وصلت إلى مستوى قابل للتقديم، ولذلك يعدلها مرارًا ويؤخر التقديم."

الأسباب:
1. هذه المشكلة أكثر تحديدًا
2. يمكنها تفسير سلوك التأجيل
3. أسهل في تصميم نسخة صغيرة للتحقق

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

11.3 في مرحلة Develop، استخدم AI لتوسيع حلول متعددة

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

text
لقد عرفت المشكلة الأساسية: [تعريف مشكلتك]
لا تعطيني إجابة نهائية مباشرة، بل اقترح 2-3 اتجاهات حل من كل من الزوايا التالية:
1. MVP الأخف
2. الحل الأنسب للتحقق من الطلب
3. الحل الأنسب لتحسين التجربة
4. حل لا يعتمد على AI
5. حل يعتمد على AI
أخيرًا قارن مزايا ومخاطر وتكلفة التحقق لكل حل.

بهذه الطريقة لن تكون مقيدًا بحل واحد في مرحلة مبكرة جدًا.

يمكنك كتابة إدخال بسيط:

text
تعريف مشكلتي الحالي هو:
"طالب الجامعة غير متأكد مما إذا كانت سيرته الذاتية يمكن تقديمها، ولذلك يؤخر التقديم دائمًا."

ساعدني في التفكير في 4 حلول مختلفة، لا تعطيني واحدًا فقط.

AI قد يخرج:

text
الحل 1: قائمة تحقق لقابلية تقديم السيرة الذاتية
الحل 2: إعادة كتابة مستهدفة بناءً على وصف الوظيفة
الحل 3: تقديم تحذيرات المخاطر بعد أن يحمل المستخدم سيرته الذاتية
الحل 4: تقديم مقارنة مع حالات ممتازة لمساعدة المستخدم في تقييم الفجوة

هذا يجعل من الأسهل الدخول في "مقارنة الحلول" بدلاً من التركيز فقط على اتجاه إعادة كتابة AI منذ البداية.

11.4 في مرحلة Deliver، استخدم AI لتوليد نصوص النماذج الأولية ومواد الاختبار

عندما تدخل مرحلة Deliver، AI مناسب جدًا لتسريع هذه الأعمال:

  • توليد نصوص الصفحات في النماذج الأولية منخفضة الدقة
  • تنظيم سكريبت اختبار المستخدمين
  • توليد عدة إصدارات قابلة للمقارنة من العناوين والأزرار والتعليمات
  • تنظيم التغذية الراجعة وقائمة المشاكل بعد الاختبار

مثلاً، يمكنك جعل AI يساعدك في توليد سكريبت اختبار مستخدمين لمدة 20 دقيقة، أو مساعدتك في تنظيم تغذية 5 مستخدمين راجعة إلى أساس حكم "استمر / عدل الاتجاه / توقف".

إدخال بسيط يمكن أن يكون:

text
صنعت نموذجًا أوليًا بسيطًا جدًا:
المستخدم يحمل سيرته الذاتية، والنظام يخبره بأي الأماكن لا تزال غير مناسبة للتقديم.

ساعدني في توليد سكريبت اختبار مستخدمين لمدة 15 دقيقة.

AI قد يخرج:

text
سكريبت اختبار 15 دقيقة:

1. اطلب من المستخدم أولًا وصف تجربة تقديم السيرة الذاتية الأخيرة
2. دع المستخدم يكمل تحميل السيرة الذاتية بشكل مستقل
3. راقب ما إذا كان يفهم نتائج التغذية الراجعة
4. اسأل: أي من هذه التلميحات كانت الأكثر فائدة، وأيها أربكك
5. اسأل: قبل التقديم المرة القادمة، هل تريد استخدامه مرة أخرى

هذا النوع من المخرجات عملي جدًا، لأنه يساعدك على الانتقال من "أنهيت النموذج الأولي" إلى "كيف أختبر بعد ذلك".

11.5 دع AI يلعب دور "حارس المرحلة"

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

text
العب دور مدرب عملية المنتج.
فيما يلي حالة مشروعي الحالية: [وصفك]
احكم على ما إذا كنت أشبه بالوجود في Discover أم Define أم Develop أم Deliver.
وأخبرني:
1. هل قفزت مبكرًا جدًا إلى المرحلة التالية
2. ما هو الإجراء الأكثر أهمية الذي يجب إكماله في المرحلة الحالية
3. أي الأشياء يجب ألا أفعلها الآن

هذا مفيد جدًا للمبتدئين، لأنك تتسرع بسهولة في "رسم النموذج الأولي قبل أن توضح المشكلة".

11. الخلاصة

  • تُستخدم Discover وDefine لصياغة تعريف المشكلة، وتُستخدم Develop وDeliver لصياغة الحل والتحقق منه.
  • يوسّع التباعد الخيارات، ويضيّق التقارب نطاقها استنادًا إلى الأدلة.
  • ينبغي تعريف المشكلة قبل استكشاف الحلول، مع إمكان مراجعته وفق نتائج الاختبار اللاحق.
  • هدف Deliver هو الحصول على نتيجة اختبار نتعلم منها، وليس بالضرورة تسليم منتج كامل.

12. تمرين

动手练习

رتّب فكرتك باستخدام نموذج الماسة المزدوجة

يرجى إكمال الواجبات التالية بناءً على المحتوى أعلاه:

  1. اختر فكرة منتج تريد صنعها مؤخرًا، واكتب مسودتها في أربع خطوات Discover و Define و Develop و Deliver
  2. في مرحلة Define، أجبر نفسك على تقليص المشكلة إلى جملة واحدة محددة
  3. في مرحلة Develop، اذكر 3 حلول مختلفة على الأقل، بدلاً من التركيز فقط على أول فكرة تتبادر إلى الذهن
  4. في مرحلة Deliver، اكتب أصغر نسخة تحقق يمكن تسليمها في غضون أسبوع

قراءة إضافية

هذه المقالة تشير أساسًا إلى المواد الرسمية من Design Council حول Double Diamond، وهي مناسبة للمتابعة والقراءة: