تجاوز إلى المحتوى
تعلّم لعملك المرجع مقالات المحفوظات
العربية

playbook

ابنِ prototype قابلًا للنقر كي تقرر

حوّل spec إلى صفحة web واحدة قابلة للفتح تنقر فيها — شيء قابل للرمي تبنيه كي تستشعر التدفّق وتتخذ القرار، لا للإطلاق أبدًا.

متوسّط ~30 دقيقة

متى تلجأ إلى هذا

تتيح الـ specs وإطارات Figma للناس أن يومئوا موافقةً دون أن يستشعروا الشيء قط. لحظة أن تستطيع نقر تدفّق فعلًا، تظهر ردود الفعل الحقيقية — «آه، تبويب Saved ينبغي أن يكون بجوار المقال، لا مدفونًا في قائمة». هذا النظام يجعل Claude يبني صفحة web واحدة مكتفية بذاتها تفتحها في متصفّحك وتنقر حولها، كي تتفاعل مع أثرٍ حقيقي قبل أن يمسّه مهندس واحد. الغاية كلها أن تتعلّم وتقرر برخص. الـ prototype للقرار، لا للإطلاق — هو شيء قابل للرمي، ومعاملته كبداية مسبقة للإنتاج هي كيف تنتهي بإطلاق سباغيتي بيانات وهمية.

جهّز هذا أولًا

  • الـ spec للـ v1 من **اختبر فكرة تحت الضغط إلى spec للـ v1** — أو على الأقل التدفّق الأساسي والشاشات في ملف spec.md.
  • القرار الواحد الذي على هذا الـ prototype حسمه — «هل يبدو تدفّق الحفظ-ثم-العثور بديهيًا؟» — كي تبني نحو سؤال، لا نحو الصقل.
  • بضعة عناصر مثال واقعية (3-5 عناوين مقالات وهمية، اسما مستخدمين وهميين) كي تبدو الشاشة حقيقية، لا Lorem ipsum.

الـ workflow

  1. اذكر القرار، ثم اجعل Claude يخطّط الشاشات

    ابنِ نحو سؤال، لا نحو منتج منجز. تسمية القرار مقدّمًا تُبقي الـ prototype صغيرًا — لا تبني إلا ما يلزم للإجابة عنه.

    أنت تطلب 
    أريد prototype قابلًا للنقر للإجابة عن سؤال واحد (ONE): هل يبدو تدفّق حفظ-المقال-ثم-العثور-عليه-في-Saved بديهيًا لقارئ لأول مرة؟ من spec.md، اسرد الحد الأدنى من الشاشات والنقرات اللازمة لاختبار ذلك — لا أكثر. لا تكتب أي كود بعد.

    ما تحصل عليه خطة شاشات صغيرة — «عرض قائمة بـ 5 مقالات لكلٍ زر Save، وتبويب Saved يُظهر ما حفظته؛ النقر على Save ينقله، النقر على المقال يفتح stub». إن اقترح شاشات تسجيل دخول وإعدادات، فاسحبه عائدًا إلى التدفّق الواحد.

    prototype يحاول إظهار كل شيء لا يثبت شيئًا. سؤال واحد، أقل عدد من الشاشات يجيب عنه.

  2. اجعل Claude يبني صفحة واحدة قابلة للفتح

    اطلب ملفًا واحدًا مكتفيًا بذاته بكل شيء مضمّن، كي يكون فتحه نقرة مزدوجة — لا install، لا build step، لا server. هذا ما يجعله شيئًا قابلًا للرمي يمكنك تسليمه لأي أحد.

    أنت تطلب 
    ابنِ ملف `prototype.html` واحدًا مكتفيًا بذاته بكل الـ HTML والـ CSS والـ JavaScript مضمّنًا — لا ملفات خارجية، لا frameworks للتثبيت. قائمة بهذه الـ 5 مقالات وهمية، لكلٍ زر Save؛ النقر على Save ينقل المقال إلى تبويب 'Saved'؛ يستطيع تبويب Saved إزالة الحفظ. اجعله قابلًا للفتح بنقرة مزدوجة على الملف.

    ما تحصل عليه ملف prototype.html واحد تستطيع فتحه مباشرةً في متصفّحك والنقر فيه فعلًا. Save ينقل مقالًا إلى تبويب Saved، والإزالة تعيده — التدفّق الحقيقي، يعمل محليًا، مبنيًا من بيانات وهمية.

    إن كنت تفضّل بناء هذا بنفسك خطوةً خطوة، فتبويب *Recipes* يمشي عبر صنع صفحة قابلة للنقر من الصفر — الفكرة نفسها، مع توجيه أكثر.

  3. انقره كأنك مبتدئ مرتبك

    استخدمه كما سيستخدمه مستخدم حقيقي، لا كما صمّمته أنت. الاحتكاك الذي تصطدم به وأنت تنقر حوله هو بالضبط الـ feedback الذي جئت لأجله — وهو مجاني الآن، مكلف لاحقًا.

    أنت تطلب 
    نقرت فيه. هذا ما بدا خاطئًا: [تبويب Saved كان صعب العثور / الحفظ لم يعطِ تأكيدًا / لم أستطع معرفة ما حُفظ سلفًا]. حدّث prototype.html ليجرّب إصلاحًا لكلٍ، وأخبرني بما غيّرته ولماذا.

    ما تحصل عليه ملف prototype.html منقّح إضافةً إلى قائمة قصيرة بالتغييرات — «أضفت حالة 'Saved ✓' على الزر كي ترى ما حُفظ سلفًا؛ نقلت تبويب Saved أعلى بجوار Articles». تُكرّر على أثرٍ حقيقي في دقائق.

  4. اكتب القرار الذي أنتجه الـ prototype

    المُخرَج ليس الصفحة — بل القرار الذي تستطيع اتخاذه الآن. التقط ما تعلّمته كي يُحذف الـ prototype دون فقدان الدرس.

    أنت تطلب 
    بناءً على شعور هذا الـ prototype، اكتب ملاحظة قرار من 5 أسطر: هل يعمل التدفّق كما هو، ما الذي يحتاج للتغيير قبل أن نبنيه فعليًا، وهل ما زال يستحق الوقت الهندسي؟ كن صادقًا إن كانت الإجابة 'ليس بعد'.

    ما تحصل عليه ملاحظة قصيرة قابلة للدفاع — «التدفّق يعمل بمجرد أن يُظهر Save حالة مؤكَّدة؛ تبويب Saved يحتاج أن يكون في المستوى الأعلى؛ يستحق البناء، تقدير صغير. مخاطرة مفتوحة: ماذا يحدث للمحفوظات عند إلغاء نشر مقال». تلك الملاحظة، لا الـ HTML، هي ما تحمله قُدمًا.

اجعله ملكك

  • **قارن تدفّقين:** ابنِ اثنين من الـ prototypes لنفس الـ feature وانقر كليهما، ثم اطلب من Claude تلخيص أيّهما بدا أوضح ولماذا — اختبار A/B رخيص قبل الالتزام باتجاه.
  • **سلّمه لمستخدم حقيقي:** يمكن إرسال صفحة الملف الواحد لعميل واحد موثوق لينقرها؛ ازدوج بها مع **اخلُص الـ feedback إلى إشارة roadmap** لطيّ ردّ فعله في النمط الأوسع.
  • **خذه إلى الهندسة:** بمجرد أن تقرّر، غذِّ الـ prototype وملاحظة القرار إلى **اقرأ codebase الخاص بك بالإنجليزية البسيطة** لتحديد نطاق أين ستعيش النسخة *الحقيقية*.

انتبه إلى

  • الـ prototype للقرار، لا للإطلاق. هذه بيانات وهمية وكود قابل للرمي بالتصميم — تسليمه للهندسة كنقطة بداية يُطلق بالضبط الاختصارات التي أخذتها للتحرك بسرعة. المُخرَج هو *القرار*، ثم تحذف الصفحة.
  • لا تبذره ببيانات عملاء حقيقية لتجعله يبدو حقيقيًا — اخترع مقالات وأسماء مثال. prototype ببيانات PII حيّة في ملف HTML واحد هو تسريب ينتظر أن يُعاد توجيهه.
  • Claude يبني الـ prototype؛ أنت تتخذ القرار. «إنه يعمل» ليس «ينبغي أن نبنيه» — البشري ما زال يمتلك ما إذا كان التدفّق يستحق وقتًا هندسيًا حقيقيًا.

ستحصل في النهاية على prototype قابل للنقر والفتح استخدمته لتستشعر التدفّق وملاحظة قرار من 5 أسطر تلتقط القرار — كي تلتزم بالوقت الهندسي على أساس رد فعل لشيء حقيقي، لا تخمين عن mockup.