تتيح الـ specs وإطارات Figma للناس أن يومئوا موافقةً دون أن يستشعروا الشيء قط. لحظة أن تستطيع نقر تدفّق فعلًا، تظهر ردود الفعل الحقيقية — «آه، تبويب Saved ينبغي أن يكون بجوار المقال، لا مدفونًا في قائمة». هذا النظام يجعل Claude يبني صفحة web واحدة مكتفية بذاتها تفتحها في متصفّحك وتنقر حولها، كي تتفاعل مع أثرٍ حقيقي قبل أن يمسّه مهندس واحد. تقود الأمر كله من محادثة Claude Desktop — تصف ما تريده، تنقر نقرًا مزدوجًا على الملف الذي يكتبه Claude، وتنقر حوله. الغاية كلها أن تتعلّم وتقرر برخص. الـ prototype للقرار، لا للإطلاق — هو شيء قابل للرمي، ومعاملته كبداية مسبقة للإنتاج هي كيف تنتهي بإطلاق سباغيتي بيانات وهمية.
- الـ spec للـ v1 من اختبر فكرة تحت الضغط إلى spec للـ v1 — أو على الأقل التدفّق الأساسي والشاشات، مُلصَقةً في المحادثة في Claude Desktop أو مُسقَطةً كملف
spec.md. - القرار الواحد الذي على هذا الـ prototype حسمه — «هل يبدو تدفّق الحفظ-ثم-العثور بديهيًا؟» — كي تبني نحو سؤال، لا نحو الصقل.
- بضعة عناصر مثال واقعية (3-5 عناوين مقالات وهمية، اسما مستخدمين وهميين) كي تبدو الشاشة حقيقية، لا
Lorem ipsum.
-
اذكر القرار، ثم اجعل Claude يخطّط الشاشات
ابنِ نحو سؤال، لا نحو منتج منجز. تسمية القرار مقدّمًا تُبقي الـ prototype صغيرًا — لا تبني إلا ما يلزم للإجابة عنه.
أنت تطلبأريد prototype قابلًا للنقر للإجابة عن سؤال واحد (ONE): هل يبدو تدفّق حفظ-المقال-ثم-العثور-عليه-في-Saved بديهيًا لقارئ لأول مرة؟ من spec.md، اسرد الحد الأدنى من الشاشات والنقرات اللازمة لاختبار ذلك — لا أكثر. لا تكتب أي كود بعد.ما تحصل عليه خطة شاشات صغيرة — «عرض قائمة بـ 5 مقالات لكلٍ زر Save، وتبويب Saved يُظهر ما حفظته؛ النقر على Save ينقله، النقر على المقال يفتح stub». إن اقترح شاشات تسجيل دخول وإعدادات، فاسحبه عائدًا إلى التدفّق الواحد.
prototype يحاول إظهار كل شيء لا يثبت شيئًا. سؤال واحد، أقل عدد من الشاشات يجيب عنه.
-
اجعل Claude يبني صفحة واحدة قابلة للفتح
اطلب ملفًا واحدًا مكتفيًا بذاته بكل شيء مضمّن، كي يكون فتحه نقرة مزدوجة — لا install، لا build step، لا server. هذا ما يجعله شيئًا قابلًا للرمي يمكنك تسليمه لأي أحد.
أنت تطلبابنِ ملف `prototype.html` واحدًا مكتفيًا بذاته بكل الـ HTML والـ CSS والـ JavaScript مضمّنًا — لا ملفات خارجية، لا frameworks للتثبيت. قائمة بهذه الـ 5 مقالات وهمية، لكلٍ زر Save؛ النقر على Save ينقل المقال إلى تبويب 'Saved'؛ يستطيع تبويب Saved إزالة الحفظ. اجعله قابلًا للفتح بنقرة مزدوجة على الملف.ما تحصل عليه ملف
prototype.htmlواحد تستطيع فتحه مباشرةً في متصفّحك والنقر فيه فعلًا. Save ينقل مقالًا إلى تبويب Saved، والإزالة تعيده — التدفّق الحقيقي، يعمل محليًا، مبنيًا من بيانات وهمية.إن كنت تفضّل بناء هذا بنفسك خطوةً خطوة، فتبويب Recipes يمشي عبر صنع صفحة قابلة للنقر من الصفر — الفكرة نفسها، مع توجيه أكثر.
-
انقره كأنك مبتدئ مرتبك
استخدمه كما سيستخدمه مستخدم حقيقي، لا كما صمّمته أنت. الاحتكاك الذي تصطدم به وأنت تنقر حوله هو بالضبط الـ feedback الذي جئت لأجله — وهو مجاني الآن، مكلف لاحقًا.
أنت تطلبنقرت فيه. هذا ما بدا خاطئًا: [تبويب Saved كان صعب العثور / الحفظ لم يعطِ تأكيدًا / لم أستطع معرفة ما حُفظ سلفًا]. حدّث prototype.html ليجرّب إصلاحًا لكلٍ، وأخبرني بما غيّرته ولماذا.ما تحصل عليه ملف
prototype.htmlمنقّح إضافةً إلى قائمة قصيرة بالتغييرات — «أضفت حالة 'Saved ✓' على الزر كي ترى ما حُفظ سلفًا؛ نقلت تبويب Saved أعلى بجوار Articles». تُكرّر على أثرٍ حقيقي في دقائق. -
اكتب القرار الذي أنتجه الـ prototype
المُخرَج ليس الصفحة — بل القرار الذي تستطيع اتخاذه الآن. التقط ما تعلّمته كي يُحذف الـ prototype دون فقدان الدرس.
أنت تطلببناءً على شعور هذا الـ prototype، اكتب ملاحظة قرار من 5 أسطر: هل يعمل التدفّق كما هو، ما الذي يحتاج للتغيير قبل أن نبنيه فعليًا، وهل ما زال يستحق الوقت الهندسي؟ كن صادقًا إن كانت الإجابة 'ليس بعد'.ما تحصل عليه ملاحظة قصيرة قابلة للدفاع — «التدفّق يعمل بمجرد أن يُظهر Save حالة مؤكَّدة؛ تبويب Saved يحتاج أن يكون في المستوى الأعلى؛ يستحق البناء، تقدير صغير. مخاطرة مفتوحة: ماذا يحدث للمحفوظات عند إلغاء نشر مقال». تلك الملاحظة، لا الـ HTML، هي ما تحمله قُدمًا.
- قارن تدفّقين: ابنِ اثنين من الـ prototypes لنفس الميزة وانقر كليهما، ثم اطلب من Claude تلخيص أيّهما بدا أوضح ولماذا — اختبار A/B رخيص قبل الالتزام باتجاه.
- سلّمه لمستخدم حقيقي: يمكن إرسال صفحة الملف الواحد لعميل واحد موثوق لينقرها؛ اقرنها بـ اخلُص الـ feedback إلى إشارة roadmap لتدمج ردّ فعله في النمط الأوسع.
- خذه إلى الهندسة: بمجرد أن تقرّر، غذِّ الـ prototype وملاحظة القرار إلى اقرأ codebase الخاص بك بالإنجليزية البسيطة لتحديد نطاق أين ستعيش النسخة الحقيقية.
- الـ prototype للقرار، لا للإطلاق. هذه بيانات وهمية وكود قابل للرمي بالتصميم — تسليمه للهندسة كنقطة بداية يُطلق بالضبط الاختصارات التي أخذتها للتحرك بسرعة. المُخرَج هو القرار، ثم تحذف الصفحة.
- لا تبذره ببيانات عملاء حقيقية لتجعله يبدو حقيقيًا — اخترع مقالات وأسماء مثال. prototype ببيانات PII حيّة في ملف HTML واحد هو تسريب ينتظر أن يُعاد توجيهه.
- Claude يبني الـ prototype؛ أنت تتخذ القرار. «إنه يعمل» ليس «ينبغي أن نبنيه» — البشري ما زال يمتلك ما إذا كان التدفّق يستحق وقتًا هندسيًا حقيقيًا.
ستحصل في النهاية على prototype قابل للنقر والفتح استخدمته لتستشعر التدفّق وملاحظة قرار من 5 أسطر تلتقط القرار — كي تلتزم بالوقت الهندسي على أساس رد فعل لشيء حقيقي، لا تخمين عن mockup.
أسئلة يطرحها الناس
- كم يستغرق بناء prototype بهذه الطريقة؟
- نحو 30 دقيقة من الـ spec إلى الصفحة القابلة للنقر — دقائق لتخطيط الشاشات، ودقائق لكتابة Claude الملف، ثم الباقي للنقر والتكرار. المغزى أن الدورة كاملةً أسرع من إطار Figma يحتاج أحد لشرحه.
- هل أحتاج معرفة الكود لأفعل هذا؟
- لا. تصف ما تريده بلغة عادية ويكتب Claude ملف الـ HTML المكتفي بذاته. كل ما تحتاجه هو القدرة على فتح ملف في متصفّح بنقرة مزدوجة — لا install، لا build step، لا terminal.
- هل يمكنني إرسال الـ prototype لعميل حقيقي لينقره؟
- نعم، لكن فقط إن احتوى بيانات مخترعة — لا تُبذر الـ prototype بأسماء عملاء أو بريد إلكتروني أو تفاصيل حسابات حقيقية. ملف HTML واحد ببيانات PII حيّة سهل إعادة توجيهه عن طريق الخطأ؛ استخدم عناوين مقالات وهمية وأسماء مستخدمين مخترعة، ثم ادمج ردّ فعله مع خلاصة الـ feedback للسياق.
- هل يجب أن أسلّم ملف الـ prototype للهندسة كنقطة بداية؟
- لا. الـ prototype بيانات وهمية وكود قابل للرمي بالتصميم — تسليمه للهندسة كبداية مسبقة يُطلق بالضبط الاختصارات التي أخذتها للتحرك بسرعة. المُخرَج الذي تحمله قُدمًا هو ملاحظة القرار من 5 أسطر، لا ملف الـ HTML.