چرا Prompt Engineering دیگر برای Design System کافی نیست؟

چرا Loop Engineering می‌تواند مهم‌ترین تحول بعدی در Design System Engineering باشد؟

ساخت یک کامپوننت دیگر مسئله اصلی نیست.

اگر همین امروز از Claude، GPT یا Gemini بخواهید یک Button یا Avatar برای Design System بسازد، احتمالاً کمتر از یک دقیقه بعد، کامپوننتی با کد React، استایل Tailwind، چند Variant و حتی مستندات اولیه روی صفحه خواهید داشت.

اگر این سؤال را سه سال پیش از یک تیم طراحی محصول می‌پرسیدید، پاسخ کاملاً متفاوت بود. ساخت یک کامپوننت جدید، به هماهنگی بین طراح محصول، مهندس فرانت‌اند، متخصص Accessibility، نویسنده مستندات و تیم Design System نیاز داشت. خروجی نهایی معمولاً بعد از چند روز آماده می‌شد و انتشار آن نیز به چند مرحله بازبینی وابسته بود.

امروز اما بسیاری از این فعالیت‌ها در چند دقیقه انجام می‌شوند.

در نگاه اول، به نظر می‌رسد مسئله حل شده است.

اما اگر یک سؤال دیگر بپرسیم، تصویر کاملاً تغییر می‌کند.

اگر فردا یکی از Design Tokenهای شما تغییر کند چه اتفاقی می‌افتد؟

اگر مقدار radius-md از ۸ پیکسل به ۱۲ پیکسل تغییر کند:

• چند کامپوننت باید اصلاح شوند؟
• کدام مستندات باید به‌روزرسانی شوند؟
• آیا Storybook هنوز معتبر است؟
• آیا Snapshot Testها همچنان Pass می‌شوند؟
• آیا Component جدید با Accessibility Guidelines تیم سازگار است؟
• آیا Migration Guide باید منتشر شود؟
• آیا این تغییر روی نسخه‌های موبایل و دسکتاپ رفتار متفاوتی ایجاد می‌کند؟

جالب اینجاست که تقریباً هیچ‌کدام از این سؤال‌ها به «ساخت کامپوننت» مربوط نیستند.

همه آن‌ها به چرخه نگهداری کامپوننت مربوط می‌شوند.

و دقیقاً همین‌جا است که تفاوت بین Prompt Engineering و Loop Engineering آغاز می‌شود.

مسئله‌ای که بیشتر تیم‌ها اشتباه تشخیص داده‌اند

در دو سال گذشته، تقریباً تمام تمرکز صنعت روی بهتر نوشتن Promptها بوده است.

هزاران مقاله منتشر شد که توضیح می‌داد چگونه Role تعریف کنیم، Context بیشتری بدهیم، Few-shot Example اضافه کنیم یا ساختار خروجی را کنترل کنیم. نتیجه هم واقعاً چشمگیر بود؛ کیفیت پاسخ مدل‌ها نسبت به نسل اول آن‌ها چندین برابر بهتر شد.

اما این پیشرفت، یک سوءبرداشت بزرگ هم ایجاد کرد.

بسیاری از تیم‌ها تصور کردند که مشکل اصلی همکاری با AI، کیفیت Prompt است.

در حالی‌که در پروژه‌های واقعی، Prompt فقط آغاز کار است.

فرض کنید Claude برای شما یک Badge Component تولید کرده است. آیا این به معنی پایان کار است؟

خیر.

در یک Design System بالغ، تولید Component تنها یکی از ده‌ها فعالیتی است که باید انجام شود. بعد از تولید، کامپوننت باید وارد چرخه‌ای شود که کیفیت، سازگاری و قابلیت نگهداری آن را تضمین کند.

این چرخه معمولاً شامل موارد زیر است:

• بررسی انطباق با Design Tokens
• اعتبارسنجی قوانین Accessibility
• مقایسه با Componentهای موجود برای جلوگیری از Duplicate شدن
• تولید یا به‌روزرسانی Storybook
• اجرای Unit Test و Visual Regression Test
• تکمیل مستندات فنی و طراحی
• بررسی اثر تغییر روی سایر Componentها
• آماده‌سازی Release Note و Migration Guide

اگر هیچ‌کدام از این مراحل انجام نشود، حتی بهترین Prompt دنیا هم فقط یک خروجی خوب تولید کرده است؛ نه یک Component آماده انتشار.

به همین دلیل است که بسیاری از تیم‌ها، با وجود استفاده روزانه از Claude یا GPT، هنوز نتوانسته‌اند فرآیند توسعه Design System خود را متحول کنند.

آن‌ها سرعت تولید را افزایش داده‌اند، اما ساختار تصمیم‌گیری همچنان همان ساختار قدیمی باقی مانده است.

Design Systemها همیشه بر پایه Loop ساخته شده‌اند

شاید عجیب به نظر برسد، اما مفهوم Loop Engineering چیز کاملاً جدیدی نیست.

در واقع، Design Systemها از سال‌ها قبل بر پایه Loop کار می‌کردند؛ فقط این Loopها توسط انسان اجرا می‌شدند.

وقتی یک کامپوننت جدید وارد Design System می‌شود، هیچ تیم بالغی این فرآیند را به شکل زیر اجرا نمی‌کند:

1. نیاز محصول←
2. طراحی←
3. پیاده‌سازی←
4. انتشار

در عمل، مسیر بسیار پیچیده‌تر است.

کامپوننت طراحی می‌شود، بازبینی می‌شود، اصلاح می‌شود، دوباره بررسی می‌شود، وارد تست می‌شود، مستنداتش تکمیل می‌شود، وابستگی‌هایش ارزیابی می‌شود و در نهایت، اگر تمام معیارهای کیفیت را پاس کند، منتشر می‌شود.

یعنی از همان ابتدا، خروجی محصول یک Loop بوده است، نه یک خط مستقیم.

تفاوت امروز این است که برای اولین بار، AI می‌تواند درون این Loop قرار بگیرد؛ نه فقط در ابتدای آن.

این تغییر کوچک به نظر می‌رسد، اما در عمل، تعریف نقش Design System Engineer را تغییر می‌دهد.

تا دیروز، ارزش یک مهندس دیزاین‌سیستم در توانایی طراحی و پیاده‌سازی Componentها بود.

فردا، ارزش او در طراحی چرخه‌هایی خواهد بود که Agentها بتوانند در آن‌ها تولید، اعتبارسنجی، مستندسازی و انتشار را به‌صورت خودکار انجام دهند.

و این دقیقاً همان نقطه‌ای است که Loop Engineering از یک تکنیک جدید، به یک مهارت استراتژیک تبدیل می‌شود.

سه نسل توسعه Design System

از فرآیندهای سنتی تا Loop Engineering

اگر امروز از یک تیم باتجربه بپرسید «ساخت یک کامپوننت جدید چقدر زمان می‌برد؟» احتمالاً پاسخ آن‌ها فقط یک عدد نخواهد بود. چون توسعه یک کامپوننت در یک Design System بالغ، صرفاً طراحی یک رابط کاربری نیست؛ بلکه مجموعه‌ای از تصمیم‌های طراحی، مهندسی، مستندسازی و حاکمیت است که باید به‌صورت هماهنگ انجام شوند.

در کمتر از پنج سال، نحوه انجام این فرآیند سه بار تغییر کرده است. هر نسل، بخشی از مشکلات نسل قبل را حل کرد، اما هم‌زمان محدودیت‌های جدیدی هم به همراه آورد.

در ادامه، این سه نسل را با یک مثال مشترک بررسی می‌کنیم.

نسل اول؛ Traditional Workflow

زمانی که هر کامپوننت یک پروژه بود

فرض کنید تیم تصمیم گرفته است یک Avatar Component به Design System اضافه کند.

در مدل سنتی، این درخواست با یک جلسه آغاز می‌شود. تیم محصول نیاز را توضیح می‌دهد، طراح تجربه کاربری سناریوهای استفاده را بررسی می‌کند و تیم Design System مشخص می‌کند که آیا واقعاً به یک کامپوننت جدید نیاز هست یا می‌توان از الگوهای موجود استفاده کرد.

پس از تأیید، طراحی آغاز می‌شود. اندازه‌ها، حالت‌ها، رفتارهای تعاملی، قوانین دسترسی‌پذیری و ارتباط آن با سایر کامپوننت‌ها بررسی می‌شود. سپس توسعه‌دهنده فرانت‌اند نسخه اولیه را پیاده‌سازی می‌کند، QA آن را تست می‌کند، مستندات نوشته می‌شود و در نهایت پس از چند مرحله بازبینی، کامپوننت منتشر می‌شود.

این فرآیند ممکن است بین چند روز تا چند هفته زمان ببرد؛ اما یک ویژگی مهم دارد:

تقریباً هیچ تصمیم مهمی بدون بررسی انسانی وارد Design System نمی‌شود.

جریان کار

1. نیاز محصول←
2. تحلیل نیاز←
3. طراحی UX/UI←
4. Design Review←
5. پیاده‌سازی←
6. Code Review←
7. Accessibility Review←
8. QA←
9. Documentation←
10. Release

افراد درگیر

• Product Designer — تعریف نیاز و سناریوها
• Design System Designer — طراحی ساختار کامپوننت
• Front-end Engineer — پیاده‌سازی
• QA Engineer — تست عملکرد
• Accessibility Specialist — بررسی WCAG
• Technical Writer — مستندات
• Design Lead — تأیید نهایی

مزایا

• کیفیت خروجی بسیار بالا است، چون هر مرحله توسط متخصص همان حوزه بررسی می‌شود.
• تصمیم‌ها مستند هستند و قابلیت پیگیری دارند.
• احتمال ایجاد ناسازگاری با سایر بخش‌های Design System پایین است.
• فرآیند انتشار تحت Governance مشخص انجام می‌شود.

محدودیت‌ها

اما این مدل هزینه سنگینی دارد.

اضافه شدن یک Variant جدید یا حتی تغییر یک Design Token می‌تواند دوباره بخش بزرگی از این چرخه را فعال کند. هر تغییر کوچک، وابستگی‌های متعددی ایجاد می‌کند و سرعت توسعه به‌شدت کاهش می‌یابد.

مشکل اصلی این نسل، کیفیت نبود؛ هزینه نگهداری بود.

نسل دوم؛ Prompt Engineering

زمانی که تولید کامپوننت از چند روز به چند دقیقه رسید

ورود مدل‌هایی مانند Claude، GPT و Gemini، اولین تغییر اساسی را ایجاد کرد.

برای اولین بار، تیم‌ها توانستند به‌جای شروع از یک فایل خالی، تنها با یک Prompt، نسخه اولیه یک کامپوننت را تولید کنند.

امروز می‌توان چنین درخواستی نوشت:

یک Avatar Component با React و Tailwind ایجاد کن. از Design Tokens استفاده کن، سه اندازه داشته باشد، از تصویر، Initial و Icon پشتیبانی کند و مستندات Markdown هم تولید کن.

چند ثانیه بعد، AI کد، مستندات و حتی نمونه استفاده را تولید می‌کند.

این اتفاق، سرعت توسعه را به‌شکل چشمگیری افزایش داد.

جریان کار

1. Prompt←
2. AI Generate←
3. Developer Review←
4. اصلاح←
5. استفاده

چه چیزهایی حذف شدند؟

Prompt Engineering بسیاری از فعالیت‌های تکراری را حذف کرد:

• نوشتن Boilerplate Code
• ساخت Variantهای اولیه
• تولید Documentation اولیه
• تولید مثال‌های استفاده
• تولید API Table
• تولید تست‌های اولیه

اما چه چیزهایی هنوز باقی ماندند؟

مشکل اینجاست که AI فقط همان چیزی را تولید می‌کند که از او خواسته شده است.

او نمی‌داند:

• آیا این کامپوننت با سایر کامپوننت‌ها هم‌پوشانی دارد؟
• آیا قبلاً تصمیمی درباره این رفتار گرفته شده است؟
• آیا Design Token جدید با قوانین برند سازگار است؟
• آیا Storybook باید تغییر کند؟
• آیا این تغییر روی ۱۲ کامپوننت دیگر هم اثر می‌گذارد؟
• آیا Migration Guide باید منتشر شود؟

این اطلاعات معمولاً در فایل‌های مختلف، ریپازیتوری‌ها، مستندات یا ذهن اعضای تیم قرار دارند.

به همین دلیل، اگرچه Prompt Engineering زمان تولید را کاهش داد، اما زمان اعتبارسنجی و نگهداری را تقریباً دست‌نخورده باقی گذاشت.

بزرگ‌ترین سوءبرداشت درباره Prompt Engineering

بسیاری از تیم‌ها هنوز تصور می‌کنند که کیفیت خروجی AI فقط به کیفیت Prompt وابسته است.

در حالی‌که در پروژه‌های واقعی، مشکل اصلی Prompt نیست؛ Context است.

اگر AI فقط Design Tokens را ببیند، خروجی متفاوتی تولید می‌کند.

اگر علاوه بر آن، Component Specification، Accessibility Rules، Decision Log، Usage Guidelines و Documentation را هم در اختیار داشته باشد، خروجی کاملاً تغییر می‌کند.

بنابراین، محدودیت اصلی Prompt Engineering این نیست که AI ضعیف است؛ بلکه این است که AI فقط بخشی از دانش سیستم را می‌بیند.

همین نقطه، زمینه تولد نسل سوم را فراهم کرد؛ نسلی که هدفش تولید پاسخ بهتر نیست، بلکه مدیریت چرخه کامل تصمیم‌گیری است.

و این همان چیزی است که امروز با نام Loop Engineering شناخته می‌شود.