سیستمهای طراحی خوانا برای ماشین در سال ۲۰۲۶ اختیاری نیستند
ابزارهای هوش مصنوعی اکنون از سیستم طراحی شما میسازند، نه فقط از اسکرینشاتهایتان. اینجاست که میآموزید چگونه توکنها، کامپوننتها و حالتها را بهاندازه کافی ساختارمند کنید تا ماشین بتواند آنها را بخواند، بدون اینکه به بینظمی دامن بزنید.
ماشین اکنون سیستم شما را میخواند، نه اسکرینشات شما را
سیستم طراحی خود را همین حالا برای ماشین قابل خواندن کنید. ابزارهای طراحی هوش مصنوعی از ساختار زیرین کار شما میسازند، نه از تصویر یک صفحه تمامشده، و این ساختار همان چیزی است که آنها اکنون بر اساس آن عمل میکنند.
Figma AI و Claude Design دیگر قصد شما را از یک تصویر مسطح حدس نمیزنند. آنها توکنهای شما، تعریف کامپوننتهایتان و واریانتهای نامگذاریشدهتان را میخوانند، سپس از آنچه مییابند میسازند. ابزاری که سیستم شما را میخواند، هر تصمیمی که در آن کدگذاری کردهاید را به ارث میبرد، هم تصمیمهای درست و هم تصمیمهای سهلانگارانه.
این ساختار را به سقف کیفیت خروجی تبدیل میکند. یک سیستم دقیق، تولیدات دقیق ایجاد میکند. یک سیستم سهلانگار، تولیدات سهلانگار با سرعت بالا ایجاد میکند.
معنای واقعی «خوانا برای ماشین»
خوانا برای ماشین به معنای زیبا نیست. به این معناست که یک ابزار میتواند هر مقدار، نام و رابطهای را بدون حدس زدن حل کند.
یک طراح انسانی به کارتی با حاشیه خاکستری کمی غلط نگاه میکند، شانه بالا میاندازد و آن را بهاندازه کافی نزدیک به هم میرساند. یک ماشین نمیتواند شانه بالا بیندازد. یا توکنی با نام border.subtle پیدا میکند و از آن استفاده میکند، یا مقدار خام #E3E3E1 که بهصورت hard-code در یک کامپوننت نوشته شده را مییابد و آن تصادف را به عنوان یک قانون در نظر میگیرد.
چهار چیز یک سیستم را برای ماشین قابل فهم میکند:
- توکنهایی که هر مقداری را نامگذاری میکنند، بدون هیچ hex خامی که داخل کامپوننتها شناور باشد
- کامپوننتهایی که یک بار تعریف شدهاند، با واریانتها به عنوان خواص نامگذاریشده، نه به عنوان کپی
- حالتهایی که به عنوان واریانتهای صریح مشخص شدهاند: پیشفرض، hover، focus، غیرفعال، خطا
- هیچ موردی منفرد و جدا که بیصدا با سیستمی که در آن قرار دارد تناقض داشته باشد
چرا یک سیستم آشفته هوش مصنوعی را بدتر میکند، نه کندتر
یک سیستم آشفته ابزارهای هوش مصنوعی را کند نمیکند. تولید آشفتگی را سرعت میبخشد. اکثر مردم این را برعکس میفهمند.
وقتی یک طراح یک فایل آشفته را به ارث میبرد، آشفتگی خود را محدود میکرد، چون یک انسان فقط به همان سرعتی کپیپیست میکند که دارد و معمولاً متوجه میشود وقتی سه دکمه با هم در تناقضند. یک ماشین چنین اصطکاکی ندارد. Figma AI را به سمت سیستمی با چهار دکمه «primary» رقیب نشانه بگیرید و آن با خوشحالی یک صفحه پنجم تولید میکند که از هر چهارتا استفاده میکند، چون هیچ چیزی در ساختار به آن نگفته کدام یکی واقعی است.
هوش مصنوعی یک سیستم طراحی آشفته را درست نمیکند. آشفتگی را سریعتر تحویل میدهد.
این کل خطر است در یک جمله. ابزار یک تقویتکننده است، و تقویتکنندهها اهمیتی نمیدهند که سیگنال خوب باشد.
توکنها واحدی هستند که ماشین میتواند بخواند
سیستم توکن را در m3.material.io ببینید
توکنها کوچکترین چیزی هستند که یک ماشین میتواند با اطمینان بخواند، پس اینجاست که خوانایی ماشین به دست میآید یا از دست میرود. یک توکن یک تصمیم نامگذاریشده است، color.surface.raised، space.4، radius.md، که به یک مقدار اشاره میکند.
این اکنون بیشتر از دو سال پیش اهمیت دارد، چون یک نام تفسیر را زنده نگه میدارد اما یک hex code نه. وقتی یک ماشین color.text.danger میبیند، قصد را میفهمد. وقتی #D72638 میبیند، یک عدد میداند و هیچ چیز دیگری، و آن عدد را در جاهایی که هرگز نقش «خطر» نداشتند دوباره استفاده میکند.
سیستمهای واقعی نشان میدهند این کار درست چگونه است. Material Design 3 توکنها را به عنوان یک ساختار لایهای مستند میکند، از reference به system به component، نوع سلسله مراتب نامگذاریشدهای که ابزار میتواند طی کند. Shopify Polaris توکنهای خود را به عنوان یک مجموعه منتشرشده و قابل پرسوجو ارسال میکند، نه یک فایل Figma که کسی باید با چشم بررسی کند.
| سیستم طراحی | مالک | آنچه برای ماشینها نمایش میدهد |
|---|---|---|
| Polaris | Shopify | توکنهای منتشرشده و قابل پرسوجو و کاتالوگ کامپوننت ساختارمند |
| Material Design 3 | توکنهای طراحی لایهای، از reference به system به component | |
| Primer | GitHub | توکنها و کامپوننتهای ارسالشده به عنوان کد نسخهبندیشده |
| Atlassian Design System | Atlassian | توکنهای نامگذاریشده و حالتهای کامپوننت مستند در سراسر محصولات |
کامپوننتها و حالتهایی که ماشین میتواند حل کند
کاتالوگ را در polaris.shopify.com مرور کنید
یک کامپوننت تنها در صورتی برای ماشین قابل خواندن است که ماشین بتواند واریانتهای آن را با نام از هم تشخیص دهد. یک دکمه با خاصیت variant تنظیمشده بر primary، secondary، یا tertiary قابل فهم است. پنج کامپوننت جداگانه با نامهای «Button»، «Button 2»، «Button final»، «Button (new)» یک بازی حدسزدن است، و ماشین حدس میزند.
حالتها جایی هستند که اکثر سیستمها بیصدا شکست میخورند. طراحان حالت پیشفرض را رسم میکنند، آن را ارسال میکنند، و بقیه را به عنوان اطلاعات شفاهی در ذهن کسی رها میکنند. یک ماشین نمیتواند اطلاعات شفاهی بخواند.
هر کامپوننت تعاملی به این پنج حالت به عنوان واریانتهای صریح نامگذاریشده نیاز دارد:
- پیشفرض (Default)
- نگهداشتن موس (Hover)
- فوکوس (Focus)
- غیرفعال (Disabled)
- خطا (Error)
اگر یک حالت یک واریانت نامگذاریشده نباشد، ابزار یا یکی اختراع میکند یا آن را حذف میکند. هر دو اشتباه است.
چگونه سیستم خود را بدون بازسازی برای هوش مصنوعی آماده کنید
نیازی نیست سیستم را از نو بسازید. خوانایی ماشین بیشتر یک کار تمیزکاری است، و پربازدهترین اصلاحات ساختاری هستند، نه بصری.
این چکلیست را روی فایل واقعی خود اجرا کنید:
- هر مقدار hex، فاصله، و radius که hard-code شده را با یک ارجاع توکن جایگزین کنید
- کامپوننتهای تکراری را در یک تعریف با واریانتهای نامگذاریشده ادغام کنید
- حالتهای گمشده را به عنوان واریانتهای صریح اضافه کنید: پیشفرض، hover، focus، غیرفعال، خطا
- هر instance جداشدهای که با سیستم تناقض دارد را حذف یا دوباره متصل کنید
- چیزها را با قصد نامگذاری کنید،
text.dangerنهred.600، تا نام معنا داشته باشد - قوانینی که یک انسان فرض میکند اما هرگز مستند نکرده را بنویسید، در متنی که ابزار بتواند بخواند
اصلاحات ساختاری را اول انجام دهید، توکنها و کامپوننتهای تکراری، چون اینها چیزی است که ماشین قبل از هر چیز دیگری میخواند. یک سیستم قابل فهم اما ساده از یک سیستم زیبا پر از موارد منفرد جداشده، هر بار که ابزاری از آن تولید میکند، برتر است.
Brainy به طراحان کمک میکند تصمیمات تیزتری بگیرند، سریعتر، روی کاری که واقعاً تحویل میشود. کنار جامعه سازندگان Brainy بسازید.
این چه تغییری برای طراح ایجاد میکند
کار یک سطح بالاتر میرود. زمان کمتری برای هل دادن پیکسلها به صد صفحه، زمان بیشتری برای تعریف سیستمی که آن صفحات از آن کامپایل میشوند. ارزش کار شما به تصمیمات کدگذاریشده در ساختار تغییر مییابد.
این خبر خوبی است برای کسانی که تفکر سیستماتیک را دوست دارند و خبر بدی برای کسانی که ارزششان در سرعت اجرا بود. ابزاری که از توکنهای شما میسازد یک طراح سیستممحور تیز را ارزشمندتر میکند و یک طراح سریع اما سهلانگار را کمتر ارزشمند.
همچنین هزینه یک تصمیم سهلانگارانه را بالا میبرد. یک رنگ hard-code شده قبلاً در یک صفحه مینشست. حالا میتواند به هر صفحهای که ابزار تولید میکند انتشار یابد، پس میانبرهای کوچک به روشی ترکیب میشوند که وقتی یک انسان گلوگاه بود، هرگز چنین نبود.
سوالات متداول
خوانا برای ماشین یعنی هر مقداری با نام قابل حل باشد
توکنها مقادیر خام را جایگزین میکنند، کامپوننتها یک بار با واریانتهای نامگذاریشده تعریف میشوند، و هر حالت صریح است. اگر ماشین باید یک پیکسل را تفسیر کند به جای خواندن یک نام، آن بخش خوانا برای ماشین نیست.
آیا باید سیستم طراحی خود را برای ابزارهای هوش مصنوعی بازسازی کنم؟
نه. بیشتر کار تمیزکاری است، جایگزینی مقادیر hard-code شده با توکنها، ادغام کامپوننتهای تکراری، و نامگذاری حالتها. بازسازی به ندرت پاسخ است. ابتدا ساختار را محکم کنید و همان فایل برای ابزار بسیار قابل فهمتر میشود.
کدام سیستمهای طراحی مراجع خوبی برای خوانایی ماشین هستند؟
Shopify Polaris و Material Design 3 واضحترین مثالهای عمومی هستند، چون هر دو توکنهای ساختارمند و کامپوننتهای مستند منتشر میکنند. GitHub Primer و Atlassian Design System هم مراجع قوی هستند، چون هر دو توکنها و کامپوننتها را به عنوان کد نسخهبندیشده به جای فایلهای ثابت ارسال میکنند.
آیا ابزارهای طراحی هوش مصنوعی کار سیستمهای طراحی را جایگزین میکنند؟
برعکس. وقتی یک ابزار از سیستم شما میسازد، خود سیستم ارزشمندترین آرتیفکت میشود. ساختن صفحات تکراری خودکار میشود، و تصمیمات کدگذاریشده در توکنها و کامپوننتها بیشتر اهمیت مییابند، نه کمتر.
چه چیزی سریعترین خروجی هوش مصنوعی را خراب میکند؟
موارد منفرد جداشده و حالتهای مستندنشده. یک instance جداشده به ابزار یک تناقض یاد میدهد، و یک حالت گمشده آن را مجبور میکند یکی اختراع کند. هر دو خروجیهایی مطمئن اما غلط تولید میکنند که تا وقتی بررسی نکنید درست به نظر میرسند.
ساختار اول، سپس بگذارید ماشین بسازد
این تغییر ساده است برای گفتن و ناخوشایند برای عمل کردن. یک ابزار اکنون سیستم شما را میخواند و از آن میسازد، پس سیستم محصول است و صفحات محصول جانبی هستند.
قبل از اینکه هر ابزاری را به آن نشانه بگیرید، ساختار را قابل فهم کنید. مقادیر را توکن کنید، کامپوننتها را تکراریزدایی کنید، حالتها را نامگذاری کنید، موارد منفرد جداشده را از بین ببرید. این کار را بکنید و Figma AI، Claude Design، و هر چیزی که بعد میآید به یک ضریب نیرو تبدیل میشوند به جای ضریب آشفتگی.
برای بیشتر بررسیهای سیستمهای طراحی و ابزارها، خواندن مقالات Brainy را ادامه دهید. و اگر میخواهید کنار جامعه سازندگان Brainy بسازید، بیایید ببینید چه چیزی میسازیم.
Brainy به طراحان کمک میکند تصمیمات تیزتری بگیرند، سریعتر، روی کاری که واقعاً تحویل میشود.
Brainy helps designers make sharper calls, faster, on the work that actually ships. See what we are building for creators.
Get Started
