آپدیت جدید فیگما، طراحی، کد و هوش مصنوعی در یک محیط!

فیگما از قابلیت‌های جدیدش رونمایی کرد؛ طراحی، کد و هوش مصنوعی در یک محیط!

تا همین چند وقت پیش، فرایند طراحی و توسعه محصول معمولاً بین چند ابزار مختلف تقسیم می‌شد. طراح‌ها در Figma روی رابط کاربری کار می‌کردن، تصمیم‌ها و نیازمندی‌ها در ابزارهای مستندسازی ثبت می‌شدن و توسعه‌دهنده‌ها برای پیاده‌سازی، سراغ محیط کدنویسی می‌رفتن.این تقسیم کار به‌خودی‌خود مشکل‌ساز نیست، اما وقتی اطلاعات بین ابزارها منتقل می‌شن، بخشی از Context ممکنه از بین بره. برای مثال، توسعه‌دهنده می‌تونه ظاهر یک Component رو ببینه، اما لزوماً نمی‌دونه چرا یک Variant انتخاب شده یا چه محدودیت‌هایی برای استفاده از اون وجود داره.با ورود Agentهای هوش مصنوعی به فرایند توسعه، این مسئله اهمیت بیشتری پیدا کرده. چون حالا فقط انسان‌ها نیستن که باید تصمیم‌های طراحی رو درک کنن؛ Agentها هم برای تولید خروجی درست به اطلاعات و قواعد پروژه نیاز دارن.فیگما در رویداد Config India 2026 و در مطلبی با عنوان Build by Design مجموعه‌ای از قابلیت‌های جدید رو معرفی کرده که تلاش می‌کنن این فاصله رو کمتر کنن.از ترکیب طراحی و کد در Canvas گرفته تا مستندسازی تصمیم‌ها، اتصال Design System به منابع کد و گسترش قابلیت‌های MCP، جهت کلی این تغییرات مشخصه:

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

۱. Code Layers؛ وقتی کد وارد محیط طراحی می‌شه

یکی از قابلیت‌های مهم معرفی‌شده، Code Layers است؛ قابلیتی که تلاش می‌کنه فاصله بین Prototypeهای طراحی و پیاده‌سازی مبتنی بر کد رو کمتر کنه.در Workflowهای معمول، طراح ممکنه یک Prototype تعاملی در فیگما بسازه، اما توسعه‌دهنده برای پیاده‌سازی اون مجبور باشه بخش زیادی از رفتارها و ساختار رو دوباره در کد ایجاد کنه.از طرف دیگه، اگر توسعه‌دهنده یک نمونه تعاملی با کد ساخته باشه، بررسی و همکاری روی اون در محیط طراحی همیشه ساده نیست.Code Layers تلاش می‌کنه این دو محیط رو به هم نزدیک‌تر کنه.با این قابلیت، تیم‌ها می‌تونن نمونه‌های مبتنی بر کد رو وارد Canvas فیگما کنن و اون‌ها رو در کنار طراحی‌های دیگه بررسی کنن. همچنین مسیرهایی برای استفاده از منابع GitHub و دریافت رابط کاربری صفحات وب از طریق افزونه Chrome معرفی شده.

این قابلیت چه تغییری ایجاد می‌کنه؟

فرض کنین تیم محصول در حال طراحی یک Dashboard با جدول‌های تعاملی، فیلترهای پیچیده و نمودارهای پویاست.در یک Prototype معمولی، نمایش دقیق تمام رفتارهای این صفحه ممکنه به تعاملات متعدد و شبیه‌سازی‌های دستی نیاز داشته باشه.اما وقتی نمونه‌ای مبتنی بر کد در محیط طراحی قابل‌بررسی باشه، تیم می‌تونه رفتار واقعی‌تری رو مشاهده کنه و درباره جزئیات تعامل تصمیم بگیره.این موضوع به‌خصوص برای Componentهایی که رفتار پیچیده‌تری دارن، مثل Date Picker، Data Table یا فرم‌های چندمرحله‌ای، می‌تونه مفید باشه.البته نباید Code Layers رو با تبدیل کامل و بدون خطای طراحی به کد Production اشتباه بگیریم. وجود کد در Canvas لزوماً به معنی آماده بودن اون برای انتشار، سازگاری با معماری پروژه یا رعایت تمام قواعد Design System نیست.ارزش اصلی این قابلیت در نزدیک‌تر کردن محیط بررسی طراحی و رفتار پیاده‌سازی‌شده است.

۲. Figma Specs؛ تصمیم‌های طراحی هم بخشی از خروجی می‌شند

یکی از مشکلات رایج در همکاری بین طراحی و توسعه اینه که فایل طراحی معمولاً نتیجه نهایی تصمیم‌ها رو نشون می‌ده، نه تمام دلایل پشت اون‌ها رو.برای مثال، ممکنه در یک صفحه از Drawer به‌جای Modal استفاده شده باشه. توسعه‌دهنده می‌تونه این انتخاب رو در طراحی ببینه، اما لزوماً نمی‌دونه دلیل اون محدودیت فضای صفحه، نوع تعامل کاربر یا تصمیم مشترک تیم محصول بوده.اگر این Context جایی ثبت نشده باشه، احتمال داره در مراحل بعدی توسعه از بین بره.قابلیت Figma Specs با هدف نزدیک‌تر کردن نیازمندی‌ها، تصمیم‌ها و اطلاعات پروژه به محیط طراحی معرفی شده.با این قابلیت، تیم‌ها می‌تونن توضیحات و اطلاعات مرتبط با محصول رو در کنار طراحی‌ها نگه دارن تا ارتباط بین چیزی که طراحی شده و چیزی که باید ساخته بشه واضح‌تر باشه.

چرا Specs برای Agentها اهمیت داره؟

فرض کنین از یک Agent برنامه‌نویسی می‌خوایم یک فرم ثبت‌نام رو براساس فایل فیگما پیاده‌سازی کنه.Agent ممکنه بتونه ساختار صفحه، فیلدها و دکمه‌ها رو تشخیص بده، اما از روی ظاهر طراحی همیشه نمی‌تونه متوجه بشه که:- کدوم فیلدها اجباری هستن و چه Validationهایی دارن؟- در صورت قطع ارتباط با سرور چه اتفاقی باید بیفته؟- کاربر در چه شرایطی اجازه رفتن به مرحله بعد رو داره؟- چه محدودیت‌هایی برای نمایش اطلاعات حساس وجود داره؟این اطلاعات معمولاً در ظاهر نهایی صفحه دیده نمی‌شن.وقتی نیازمندی‌ها و تصمیم‌ها به‌شکل ساختاریافته در دسترس باشن، Agent می‌تونه علاوه بر ظاهر، Context بیشتری درباره رفتار موردانتظار محصول دریافت کنه.البته کیفیت نتیجه همچنان به دقت مستندات و نحوه استفاده Agent از اون‌ها بستگی داره.نکته مهم اینه که Agent برای پیاده‌سازی درست، فقط به تصویر طراحی نیاز نداره؛ باید بدونه طراحی قراره چه مسئله‌ای رو حل کنه و چه محدودیت‌هایی داره.

۳. Design Systemها فقط Library نیستن؛ قواعد و منابع کد هم اهمیت دارن

یکی از مهم‌ترین بخش‌های این به‌روزرسانی برای تیم‌هایی که روی Design System کار می‌کنن، قابلیت اضافه کردن Guidelines و Code Sources به Libraryهای فیگماست.تا امروز، بخش زیادی از اطلاعات Design System در فایل‌های طراحی، مستندات وب و Repositoryهای کد نگهداری می‌شد. این ساختار برای تیم‌هایی که با سیستم آشنا هستن قابل‌استفاده است، اما وقتی یک Agent وارد فرایند می‌شه، ممکنه ارتباط بین این منابع رو به‌درستی تشخیص نده.برای مثال، Agent ممکنه در فایل فیگما یک Button با ظاهر مشخص پیدا کنه، اما ندونه این Button در پروژه React چه APIای داره، چه Variantهایی پشتیبانی می‌کنه یا چه زمانی نباید از اون استفاده کرد.در چنین شرایطی، حتی اگر ظاهر خروجی درست باشه، پیاده‌سازی می‌تونه با Design System فاصله داشته باشه.

Guidelines چه کمکی می‌کنن؟

Guidelines به تیم‌ها اجازه می‌دن قواعد استفاده از سیستم رو در کنار Library ارائه کنن.فرض کنین در Design System مشخص شده که برای تأیید عملیات حساس باید از Modal استفاده بشه، اما برای ویرایش اطلاعات تکمیلی، Drawer انتخاب مناسب‌تریه.اگر این قاعده فقط در ذهن اعضای تیم یا یک سند جداگانه وجود داشته باشه، Agent ممکنه بدون توجه به اون تصمیم بگیره.اما وقتی Guidelines در دسترس باشن، می‌تونه هنگام انتخاب Pattern به این اطلاعات مراجعه کنه.این موضوع درباره Tokenها، رفتار Componentها، Accessibility و قواعد Responsive هم صدق می‌کنه.

Code Sources چه تفاوتی ایجاد می‌کنه؟

Code Sources چه تفاوتی ایجاد می‌کنه؟Code Sources با نزدیک‌تر کردن منابع کد به Library طراحی، به ارتباط بین Component بصری و پیاده‌سازی واقعی اون کمک می‌کنه.برای مثال، یک Input در فایل طراحی ممکنه Stateهای مختلفی مثل Default، Error و Disabled داشته باشه.اما در کد، نحوه استفاده از این Stateها به API و ساختار Component وابسته است.اگر Agent فقط ظاهر Input رو ببینه، ممکنه خودش ساختار جدیدی بسازه. اما دسترسی به منابع کد می‌تونه کمک کنه پیاده‌سازی موجود رو پیدا کنه و از همون استفاده کنه.البته این قابلیت‌ها به‌تنهایی تضمین نمی‌کنن که Agent همیشه Component مناسب رو انتخاب کنه. همچنان باید خروجی بررسی بشه و منابع طراحی و کد با هم هماهنگ نگه داشته بشن.

یک تغییر مهم برای تیم‌های Design System

فیگما همچنین پیش‌نمایشی از قابلیت‌های مدیریت متمرکز Design System ارائه کرده که هدفشون ساده‌تر کردن بررسی وابستگی‌ها، شناسایی بخش‌های ناقص مستندات و مدیریت وضعیت Componentهاست.این موضوع اهمیت زیادی داره، چون هرچه تعداد محصولات و تیم‌های مصرف‌کننده بیشتر بشه، نگهداری سیستم هم پیچیده‌تر می‌شه.برای مثال، قبل از تغییر یک Component باید بدونیم چه بخش‌هایی از محصول به اون وابسته هستن و تغییر موردنظر چه تأثیری روی مصرف‌کننده‌ها می‌ذاره.در چنین شرایطی، Design System دیگه فقط مجموعه‌ای از Componentهای قابل‌استفاده نیست؛ به زیرساخت مشترکی برای مدیریت تصمیم‌های طراحی و توسعه تبدیل می‌شه.برای تیم‌های Design System، مهم‌ترین تغییر اینه که قواعد استفاده از Componentها به‌اندازه خود Componentها اهمیت پیدا می‌کنن.

🔗 ۴. گسترش Figma MCP؛ Agentها به Context بیشتری دسترسی پیدا می‌کنن

یکی دیگه از بخش‌های مهم معرفی فیگما، توسعه قابلیت‌های MCP است.پروتکل Model Context Protocol یا MCP به ابزارهای هوش مصنوعی اجازه می‌ده با منابع اطلاعاتی و ابزارهای بیرونی ارتباط برقرار کنن.در فرایند طراحی و توسعه، این ارتباط می‌تونه کمک کنه Agent به‌جای تکیه بر اطلاعات عمومی یا حدس زدن جزئیات، به داده‌های مرتبط با پروژه دسترسی داشته باشه.فیگما در این به‌روزرسانی از گسترش ابزارهای MCP برای کار با Specs، Code Layers و سایر منابع طراحی صحبت کرده. همچنین اتصال‌های بیشتری با ابزارهای مختلف و بهبودهایی برای کاهش خطا و مصرف Token معرفی شده.

چرا این موضوع مهمه؟

فرض کنین یک تیم طراحی، فایل فیگما، مستندات نیازمندی‌ها و Component Library مشخصی داره.حالا از Agent می‌خوایم یک صفحه جدید رو پیاده‌سازی کنه.بدون دسترسی مناسب به Context پروژه، Agent ممکنه مجبور بشه درباره بخشی از جزئیات تصمیم‌گیری کنه؛ تصمیم‌هایی که شاید قبلاً توسط تیم طراحی گرفته شدن.اما اگر اطلاعات طراحی، نیازمندی‌ها و منابع مرتبط از طریق MCP قابل‌دسترسی باشن، Agent می‌تونه قبل از پیاده‌سازی به اون‌ها مراجعه کنه.این تفاوت به‌خصوص زمانی مهم می‌شه که چند Agent یا ابزار مختلف در یک پروژه استفاده می‌شن.برای مثال، ممکنه یک تیم از Claude Code استفاده کنه و تیم دیگه از Codex. اگر هر دو بتونن به منابع مشترک پروژه دسترسی داشته باشن، وابستگی به توضیح دستی قواعد در هر Prompt کمتر می‌شه.البته اتصال به MCP به‌تنهایی کافی نیست.Agent باید بدونه چه زمانی به منابع مراجعه کنه، اطلاعات مرتبط رو درست انتخاب کنه و اون‌ها رو در پیاده‌سازی رعایت کنه.این موضوع برای دیگ هم اهمیت داره. چون با استفاده از DIG MCP، Agentهای سازگار می‌تونن به اطلاعات Componentها، Tokenها و Patternهای دیزاین سیستم دسترسی داشته باشن.در نتیجه، مسئله فقط وصل کردن یک Agent به یک سرور نیست؛ باید بررسی کنیم آیا این اتصال واقعاً باعث می‌شه خروجی به قواعد Design System نزدیک‌تر بشه یا نه.

۵. Figma Make و Payload؛ از Prototype به وب‌سایت‌های متصل به داده

یکی دیگه از قابلیت‌های معرفی‌شده، امکان استفاده از Payload در Figma Make است.در بسیاری از ابزارهای تولید رابط کاربری با هوش مصنوعی، ساخت یک صفحه ظاهری نسبتاً ساده شده؛ اما وقتی بخوایم صفحه به داده‌های واقعی، API یا سیستم مدیریت محتوا متصل بشه، پیچیدگی بیشتری ایجاد می‌شه.برای مثال، ساخت ظاهر یک صفحه وبلاگ با چند Card و تصویر ممکنه زمان زیادی نگیره.اما اگر بخوایم محتوا از یک CMS دریافت بشه، امکان مدیریت مقاله‌ها وجود داشته باشه و داده‌ها بدون تغییر دستی کد به‌روزرسانی بشن، به ساختار فنی بیشتری نیاز داریم.قابلیت‌های Payload در Figma Make با هدف نزدیک‌تر کردن فرایند ساخت رابط کاربری به وب‌اپلیکیشن‌های متصل به داده معرفی شدن.

چه کاربردی می‌تونه داشته باشه؟

فرض کنین تیم مارکتینگ می‌خواد یک Landing Page برای معرفی محصول جدید بسازه.در روش معمول، طراح صفحه رو آماده می‌کنه و توسعه‌دهنده اتصال اون به CMS و APIهای موردنیاز رو انجام می‌ده.با ابزارهایی مثل Figma Make و قابلیت‌های جدید اتصال به داده، ممکنه بخشی از این فرایند سریع‌تر انجام بشه و تیم بتونه نمونه‌ای نزدیک‌تر به محصول واقعی بسازه.اما همچنان باید بین یک Prototype قابل‌استفاده و یک محصول آماده انتشار تفاوت بذاریم.مسائلی مثل امنیت، مدیریت دسترسی، عملکرد، نگهداری و کیفیت کد همچنان به بررسی فنی نیاز دارن.بنابراین، این قابلیت رو بهتره قدمی برای کاهش فاصله بین نمونه اولیه و محصول قابل‌استفاده بدونیم، نه جایگزینی کامل برای فرایند توسعه.

آیا فیگما داره مرز بین طراح و توسعه‌دهنده رو از بین می‌بره؟

با کنار هم قرار دادن این قابلیت‌ها، ممکنه این برداشت ایجاد بشه که فیگما می‌خواد تمام مراحل طراحی و توسعه رو در یک ابزار ادغام کنه.اما به نظرم تغییر مهم‌تر، مربوط به نحوه انتقال اطلاعات بین مراحل ساخت محصول است.تا امروز، بخش زیادی از همکاری طراحی و توسعه بر پایه انتقال خروجی انجام می‌شد.طراح فایل رو آماده می‌کرد، توسعه‌دهنده اون رو بررسی می‌کرد و اگر اطلاعاتی درباره رفتار، محدودیت‌ها یا تصمیم‌های طراحی وجود نداشت، باید دوباره از طراح سؤال می‌پرسید.حالا با ورود Agentها، این فاصله می‌تونه مسئله‌سازتر بشه.چون Agent ممکنه در نبود اطلاعات کافی، خودش تصمیم‌هایی بگیره که با قواعد محصول یا Design System هماهنگ نیستن.قابلیت‌های جدید فیگما تلاش می‌کنن بخشی از این Context رو در دسترس‌تر کنن؛ از Specs که نیازمندی‌ها رو ثبت می‌کنه تا Guidelines و Code Sources که اطلاعات بیشتری درباره نحوه استفاده از Componentها ارائه می‌دن.این تغییر به معنی حذف نقش طراح یا توسعه‌دهنده نیست.بلکه می‌تونه کمک کنه تصمیم‌های انسانی، هنگام استفاده از ابزارهای هوش مصنوعی هم حفظ بشن.

این تغییرات چه معنایی برای آینده Design Systemها دارن؟

برای تیم‌های Design System، شاید مهم‌ترین پیام این به‌روزرسانی این باشه که داشتن یک Component Library کامل، دیگه به‌تنهایی کافی نیست.فرض کنین یک Design System ده‌ها Component، صدها Token و مستندات گسترده‌ای داره.اگر Agent نتونه Component مناسب رو پیدا کنه، تفاوت Variantها رو بفهمه یا به کد واقعی دسترسی داشته باشه، ممکنه همچنان خروجی‌هایی خارج از سیستم تولید کنه.در چنین شرایطی، کیفیت Design System فقط به طراحی Componentها وابسته نیست؛ نحوه ارائه اطلاعات سیستم به ابزارهای هوش مصنوعی هم اهمیت پیدا می‌کنه.این موضوع چند مسئولیت جدید برای تیم‌های Design System ایجاد می‌کنه.اول اینکه مستندات باید علاوه بر توضیح نحوه استفاده، محدودیت‌ها و قواعد انتخاب Componentها رو هم مشخص کنن.دوم اینکه ارتباط بین Componentهای طراحی و پیاده‌سازی کد باید تا جای ممکن شفاف باشه.سوم اینکه تیم‌ها باید خروجی Agentها رو از نظر سازگاری با Design System ارزیابی کنن، نه فقط از نظر ظاهر یا سرعت تولید.برای مثال، اگر یک Agent با دسترسی به Library و مستندات، همچنان Button جدیدی خارج از سیستم بسازه، باید بررسی کنیم مشکل از نحوه استفاده Agent از اطلاعات بوده یا اطلاعات موجود به‌اندازه کافی واضح نبودن.این بررسی می‌تونه به بهبود خود Design System هم کمک کنه.

جمع‌بندی؛ فیگما فقط ابزارهای جدید معرفی نکرده

قابلیت‌های معرفی‌شده در Config India 2026 نشون می‌دن فیگما داره روی ارتباط نزدیک‌تر طراحی، کد، مستندات و Agentهای هوش مصنوعی سرمایه‌گذاری می‌کنه.Code Layers تلاش می‌کنه نمونه‌های مبتنی بر کد رو به محیط طراحی نزدیک‌تر کنه. Specs اطلاعات و تصمیم‌های پروژه رو در کنار طراحی قرار می‌ده. Guidelines و Code Sources ارتباط Design System با قواعد استفاده و پیاده‌سازی واقعی رو تقویت می‌کنن و توسعه MCP مسیر دسترسی Agentها به این اطلاعات رو گسترش می‌ده.در کنار این‌ها، قابلیت‌های جدید Figma Make هم تلاش می‌کنن فاصله بین ساخت رابط کاربری و اتصال اون به داده‌های واقعی رو کمتر کنن.البته موفقیت این تغییرات به نحوه استفاده تیم‌ها، کیفیت مستندات و میزان هماهنگی ابزارها با Workflow واقعی پروژه‌ها بستگی داره.اما جهت کلی مشخصه:وقتی ساختن UI سریع‌تر می‌شه، ارزش تصمیم‌های طراحی و انتقال درست اون‌ها به مرحله توسعه بیشتر می‌شه.شاید در آینده، یکی از مهم‌ترین ویژگی‌های یک Design System موفق این نباشه که فقط انسان‌ها بتونن ازش درست استفاده کنن؛ بلکه این باشه که Agentها هم بتونن قواعدش رو پیدا کنن، بفهمن و در خروجی خودشون رعایت کنن.

منابع