چرا Loop Engineering میتواند مهمترین تحول بعدی در Design System Engineering باشد؟
ساخت یک کامپوننت دیگر مسئله اصلی نیست.
اگر همین امروز از Claude، GPT یا Gemini بخواهید یک Button یا Avatar برای Design System بسازد، احتمالاً کمتر از یک دقیقه بعد، کامپوننتی با کد React، استایل Tailwind، چند Variant و حتی مستندات اولیه روی صفحه خواهید داشت.
اگر این سؤال را سه سال پیش از یک تیم طراحی محصول میپرسیدید، پاسخ کاملاً متفاوت بود. ساخت یک کامپوننت جدید، به هماهنگی بین طراح محصول، مهندس فرانتاند، متخصص Accessibility، نویسنده مستندات و تیم Design System نیاز داشت. خروجی نهایی معمولاً بعد از چند روز آماده میشد و انتشار آن نیز به چند مرحله بازبینی وابسته بود.
امروز اما بسیاری از این فعالیتها در چند دقیقه انجام میشوند.
در نگاه اول، به نظر میرسد مسئله حل شده است.
اما اگر یک سؤال دیگر بپرسیم، تصویر کاملاً تغییر میکند.
اگر فردا یکی از Design Tokenهای شما تغییر کند چه اتفاقی میافتد؟
اگر مقدار radius-md از ۸ پیکسل به ۱۲ پیکسل تغییر کند:
- 1چند کامپوننت باید اصلاح شوند؟
- 2کدام مستندات باید بهروزرسانی شوند؟
- 3آیا Storybook هنوز معتبر است؟
- 4آیا Snapshot Testها همچنان Pass میشوند؟
- 5آیا Component جدید با Accessibility Guidelines تیم سازگار است؟
- 6آیا Migration Guide باید منتشر شود؟
- 7آیا این تغییر روی نسخههای موبایل و دسکتاپ رفتار متفاوتی ایجاد میکند؟
جالب اینجاست که تقریباً هیچکدام از این سؤالها به «ساخت کامپوننت» مربوط نیستند.
همه آنها به چرخه نگهداری کامپوننت مربوط میشوند.
و دقیقاً همینجا است که تفاوت بین Prompt Engineering و Loop Engineering آغاز میشود.
مسئلهای که بیشتر تیمها اشتباه تشخیص دادهاند
در دو سال گذشته، تقریباً تمام تمرکز صنعت روی بهتر نوشتن Promptها بوده است.
هزاران مقاله منتشر شد که توضیح میداد چگونه Role تعریف کنیم، Context بیشتری بدهیم، Few-shot Example اضافه کنیم یا ساختار خروجی را کنترل کنیم. نتیجه هم واقعاً چشمگیر بود؛ کیفیت پاسخ مدلها نسبت به نسل اول آنها چندین برابر بهتر شد.
اما این پیشرفت، یک سوءبرداشت بزرگ هم ایجاد کرد.
بسیاری از تیمها تصور کردند که مشکل اصلی همکاری با AI، کیفیت Prompt است.
در حالیکه در پروژههای واقعی، Prompt فقط آغاز کار است.
فرض کنید Claude برای شما یک Badge Component تولید کرده است. آیا این به معنی پایان کار است؟
خیر.
در یک Design System بالغ، تولید Component تنها یکی از دهها فعالیتی است که باید انجام شود. بعد از تولید، کامپوننت باید وارد چرخهای شود که کیفیت، سازگاری و قابلیت نگهداری آن را تضمین کند.
این چرخه معمولاً شامل موارد زیر است:
- 1بررسی انطباق با Design Tokens
- 2اعتبارسنجی قوانین Accessibility
- 3مقایسه با Componentهای موجود برای جلوگیری از Duplicate شدن
- 4تولید یا بهروزرسانی Storybook
- 5اجرای Unit Test و Visual Regression Test
- 6تکمیل مستندات فنی و طراحی
- 7بررسی اثر تغییر روی سایر Componentها
- 8آمادهسازی 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
- 4Design Review
- 5پیادهسازی
- 6Code Review
- 7Accessibility Review
- 8QA
- 9Documentation
- 10Release
افراد درگیر
- 1Product Designer — تعریف نیاز و سناریوها
- 2Design System Designer — طراحی ساختار کامپوننت
- 3Front-end Engineer — پیادهسازی
- 4QA Engineer — تست عملکرد
- 5Accessibility Specialist — بررسی WCAG
- 6Technical Writer — مستندات
- 7Design Lead — تأیید نهایی
مزایا
- 1کیفیت خروجی بسیار بالا است، چون هر مرحله توسط متخصص همان حوزه بررسی میشود.
- 2تصمیمها مستند هستند و قابلیت پیگیری دارند.
- 3احتمال ایجاد ناسازگاری با سایر بخشهای Design System پایین است.
- 4فرآیند انتشار تحت Governance مشخص انجام میشود.
محدودیتها
اما این مدل هزینه سنگینی دارد.
اضافه شدن یک Variant جدید یا حتی تغییر یک Design Token میتواند دوباره بخش بزرگی از این چرخه را فعال کند. هر تغییر کوچک، وابستگیهای متعددی ایجاد میکند و سرعت توسعه بهشدت کاهش مییابد.
مشکل اصلی این نسل، کیفیت نبود؛ هزینه نگهداری بود.
نسل دوم؛ Prompt Engineering
زمانی که تولید کامپوننت از چند روز به چند دقیقه رسید
ورود مدلهایی مانند Claude، GPT و Gemini، اولین تغییر اساسی را ایجاد کرد.
برای اولین بار، تیمها توانستند بهجای شروع از یک فایل خالی، تنها با یک Prompt، نسخه اولیه یک کامپوننت را تولید کنند.
امروز میتوان چنین درخواستی نوشت:
یک Avatar Component با React و Tailwind ایجاد کن. از Design Tokens استفاده کن، سه اندازه داشته باشد، از تصویر، Initial و Icon پشتیبانی کند و مستندات Markdown هم تولید کن.
چند ثانیه بعد، AI کد، مستندات و حتی نمونه استفاده را تولید میکند.
این اتفاق، سرعت توسعه را بهشکل چشمگیری افزایش داد.
جریان کار
- 1Prompt
- 2AI Generate
- 3Developer Review
- 4اصلاح
- 5استفاده
چه چیزهایی حذف شدند؟
Prompt Engineering بسیاری از فعالیتهای تکراری را حذف کرد:
- 1نوشتن Boilerplate Code
- 2ساخت Variantهای اولیه
- 3تولید Documentation اولیه
- 4تولید مثالهای استفاده
- 5تولید API Table
- 6تولید تستهای اولیه
اما چه چیزهایی هنوز باقی ماندند؟
مشکل اینجاست که AI فقط همان چیزی را تولید میکند که از او خواسته شده است.
او نمیداند:
- 1آیا این کامپوننت با سایر کامپوننتها همپوشانی دارد؟
- 2آیا قبلاً تصمیمی درباره این رفتار گرفته شده است؟
- 3آیا Design Token جدید با قوانین برند سازگار است؟
- 4آیا Storybook باید تغییر کند؟
- 5آیا این تغییر روی ۱۲ کامپوننت دیگر هم اثر میگذارد؟
- 6آیا 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 شناخته میشود.
کامنتها
…