یکی از بزرگترین سوءتفاهمها درباره Design System این است که تغییر یک Token را معادل تغییر یک مقدار در یک فایل میدانیم. شاید از بیرون همینطور به نظر برسد؛ کافی است مقدار radius-md را از 8px به 12px تغییر دهیم، تغییرات را Commit کنیم و نسخه جدید را منتشر کنیم.
اما تیمهایی که مسئول نگهداری یک Design System هستند، میدانند چنین تغییری تقریباً هیچوقت به همین سادگی نیست.
فرض کنید تیم طراحی تصمیم گرفته گوشههای گرد رابط کاربری را کمی نرمتر کند. در جلسه Design Review، همه روی تغییر radius-md از 8px به 12px توافق میکنند. از این لحظه به بعد، سؤال اصلی دیگر این نیست که «چطور مقدار Token را تغییر دهیم؟» بلکه این است که «این تصمیم چه پیامدهایی برای کل سیستم دارد؟»
اولین مرحله؛ شناسایی دامنه تأثیر تغییر
ممکن است radius-md فقط در چند Button استفاده نشده باشد. این Token میتواند در Cardها، Inputها، Modalها، Dropdownها، Tooltipها، Toastها و دهها کامپوننت دیگر هم استفاده شده باشد. حتی بعضی از این کامپوننتها، خودشان پایه ساخت کامپوننتهای دیگری هستند. بنابراین یک تغییر کوچک ممکن است بهصورت زنجیرهای روی صدها صفحه محصول اثر بگذارد.
در این مرحله، AI اگر فقط نقش یک Code Generator را داشته باشد، کار چندانی از پیش نمیبرد. تولید کد مسئله نیست؛ مسئله، درک ساختار Design System است. AI باید بتواند وابستگیها را تحلیل کند، تشخیص دهد کدام کامپوننتها مستقیماً تحت تأثیر قرار میگیرند و کدام تغییرها بهصورت غیرمستقیم در سراسر محصول منتشر میشوند.
آیا حالا میتوانیم نسخه جدید را منتشر کنیم؟
فرض کنیم مرحله تحلیل با موفقیت انجام شد و تمام فایلهای مربوط به Design Tokens و کامپوننتها بهروزرسانی شدند.
هنوز نه!
حالا باید مطمئن شویم این تصمیم از نظر تجربه کاربری هم درست بوده است. تستهای بصری اجرا میشوند تا مشخص شود آیا تغییر Radius باعث بههمریختن Layout یا ایجاد ناسازگاری در Variantهای مختلف شده یا نه. شاید Buttonها همچنان درست نمایش داده شوند، اما در بعضی Cardها نسبت Radius به Padding دیگر متعادل نباشد. شاید بعضی Shadowها نیاز به تنظیم مجدد داشته باشند. شاید در صفحات قدیمیتر، این تغییر باعث شود بعضی اجزا ناهماهنگ به نظر برسند.
اگر هرکدام از این بررسیها با شکست مواجه شوند، فرآیند متوقف نمیشود؛ بلکه به مرحله اصلاح برمیگردد. تغییر انجام میشود، دوباره تستها اجرا میشوند و این چرخه تا رسیدن به نتیجه مطلوب ادامه پیدا میکند.
مستندسازی و آمادهسازی انتشار
بعد از آن نوبت به مستندسازی میرسد. تصاویر Documentation باید بهروزرسانی شوند، نمونههای Storybook دوباره تولید شوند، Release Notes تغییرات را توضیح دهد و در صورتی که این تغییر برای تیمهای محصول اثرگذار باشد، Migration Guide هم منتشر شود.
نکته مهم این است که هیچیک از این مراحل مستقل از هم نیستند. خروجی هر مرحله، ورودی مرحله بعد است و نتیجه هر بررسی میتواند مسیر کل فرآیند را تغییر دهد.
تفاوت Prompt Engineering و Loop Engineering
اگر از AI فقط بخواهیم مقدار یک Token را تغییر دهد، در حال استفاده از Prompt Engineering هستیم. اما اگر AI بتواند تغییر را تحلیل کند، وابستگیها را شناسایی کند، تستها را اجرا کند، نتایج را ارزیابی کند، در صورت نیاز اصلاحات انجام دهد و در نهایت مستندات و نسخه جدید را آماده انتشار کند، دیگر با یک Prompt طرف نیستیم؛ با یک Loop روبهرو هستیم.
- تحلیل تغییر
- شناسایی وابستگیها
- اعمال تغییر
- اجرای تستها
- ارزیابی و اصلاح
- مستندسازی
- انتشار
Loop Engineering دقیقاً از همین نقطه آغاز میشود. هدف آن تولید سریعتر خروجی نیست، بلکه مدیریت چرخهای از تصمیمگیری، اعتبارسنجی و بازخورد است؛ چرخهای که سالهاست هسته اصلی توسعه Design System را تشکیل میدهد و اکنون AI میتواند به یکی از اعضای فعال آن تبدیل شود.
مقالات مرتبط
چرا Prompt Engineering دیگر برای Design System کافی نیست؟
ساخت کامپوننت با هوش مصنوعی سریع شده، اما مسئله واقعی در چرخه نگهداری، اعتبارسنجی، مستندسازی و انتشار آن است؛ جایی که Loop Engineering وارد میشود.
چرا و چطور به Graph Engineering رسیدیم؟
وقتی چند مسئولیت مستقل، مسیرهای شرطی، اجرای موازی و نقاط تصمیم متعدد داریم، یک Loop بهتنهایی کافی نیست؛ اینجا Graph Engineering وارد میشود.
کامنتها
…