توکنهای طراحی نسخهبندیشده تازه تبدیل به یک رویه استاندارد شدهاند
توکنهای طراحی حالا در pull request ها بررسی میشوند، بهصورت معنایی diff میشوند و همراه با changelog منتشر میشوند، دقیقاً همانطور که مهندسان کد را در پلتفرمهای مختلف منتشر میکنند.
یک توکن طراحی دیگر صرفاً مقداری نیست که export کنی و فراموشش کنی. این یک تغییر نسخهبندیشده در محصول است که از یک branch، یک pull request، یک review و یک changelog عبور میکند، دقیقاً همانطور که مهندسان کد منتشر میکنند. این تغییر آرام، وقتی بلند شد که طراحان شروع کردند به ثبت pull request های واقعی برای ویرایش پالت رنگی: یک توکن رنگ تغییر کرد، در یک PR بررسی شد، تأیید شد، merge شد و همراه با یک ورودی changelog منتشر شد.
دلیل اهمیت این موضوع مکانیکی است، نه زیباییشناختی. وقتی یک توکن تغییر میکند، میتواند به هر پلتفرم و محصولی که آن را میخواند سرایت کند، پس یک ویرایش بررسینشده در یک نمونهرنگ حالا یک تغییر در محیط production است. تمام داستان همین است، و بقیهی این مقاله دربارهی این است که این فرآیند چگونه کار میکند و آیا واقعاً به آن نیاز دارید یا نه.
معنای واقعی «توکنهای نسخهبندیشده» چیست
یعنی توکنهای شما در یک repository زندگی میکنند، نه فقط در یک فایل Figma. مقادیر مربوط به رنگ، فاصلهگذاری (spacing)، تایپوگرافی، شعاع گوشهها (radius) و حرکت (motion) بهصورت دادههای ساختاریافته ذخیره میشوند که یک سیستم version-control میتواند آنها را خط به خط ردیابی کند.
کاتالیزور این تحول، Tokens Studio است. Tokens Studio به شما اجازه میدهد توکنها را درون Figma ویرایش کنید و سپس آن مجموعهتوکن را با یک repository در GitHub همگامسازی (sync) کنید. به محض اینکه توکنهای شما در یک repo قرار بگیرند، هر تغییری به یک commit تبدیل میشود، هر تغییر پیشنهادی به یک pull request تبدیل میشود و هر release به یک نسخهی برچسبخورده (tagged version) با تاریخچهای قابل خواندن تبدیل میشود.
پس «توکنهای نسخهبندیشده» یک استعاره نیست. این عمل واقعی قرار دادن تصمیمات طراحی زیر همان workflow گیت (git) است که GitHub در اختیار مهندسان قرار میدهد، و سپس استفاده از حفاظهای ایمنی که همراه آن میآیند: branch ها برای جداسازی کار، review ها برای گرفتن اشتباهات، و یک changelog تا کسی مجبور نباشد حدس بزند چه چیزی تغییر کرده است.
این تغییر بزرگ: یک ویرایش توکن حالا یک تغییر در production است
این بخشی است که کل ماجرا را بازتعریف میکند. یک توکن، طبق تعریف، مشترک (shared) است. کل دلیلی که شما color.brand.primary را به یک توکن تبدیل کردید بهجای یک مقدار هگزادسیمال پراکنده در صفحات مختلف، این بود که یک تغییر، هر جایی که از آن استفاده میکند را بهروزرسانی کند.
همین ابرقدرت، در عین حال ریسک هم هست. لحظهای که آن توکن را ویرایش میکنید، عملاً یک تغییر برای هر دکمه، لینک، نشان (badge) و وضعیت (state) در وب، iOS و Android پیشنهاد دادهاید. چیزی به اسم «فقط همین یک صفحه» وجود ندارد. Style Dictionary، مرحلهی build ای که اغلب تیمها همراه با توکنهایشان از آن استفاده میکنند، مجموعهتوکن ادغامشده (merged) را برای هر پلتفرم کامپایل میکند، پس یک ویرایش تکی به یک release چندپلتفرمی تبدیل میشود.
اگر با آن مثل یک ذخیرهی معمولی (casual save) رفتار کنید، یک تغییر تستنشده را به کل سطح محصول خود در production منتشر کردهاید. اگر با آن مثل کد رفتار کنید، قبل از اینکه به جایی برسد، یک review دریافت میکند.
نقشهراه version-control، اعمالشده روی توکنها
این جدولی است که ارزش ذخیره کردن دارد. هر رویهای که مهندسان برای انتشار امن کد استفاده میکنند، حالا معادل تمیزی در دنیای توکنهای طراحی دارد.
| رویهی نرمافزاری | معادل آن در توکنها |
|---|---|
| Branch | یک نسخهی کاری از مجموعهتوکن که در آن یک پالت را بدون دستزدن به production ویرایش میکنید |
| Pull request | تغییر پیشنهادی توکن، باز شده برای review پیش از merge شدن |
| Code review | تأیید یک design-systems lead روی تغییر نمونهرنگ، فاصلهگذاری یا تایپوگرافی و شعاع تأثیر آن (blast radius) |
| Semantic version | بالا بردن نسخهی release توکن تا مصرفکنندگان بدانند آیا یک patch است، یک minor یا یک breaking change |
| Changelog | سابقهای قابل خواندن برای انسان از اینکه چه چیزی تغییر کرده، چرا، و روی کدام پلتفرمها اثر گذاشته |
| Continuous integration | کامپایل خودکار توکنهای ادغامشده توسط Style Dictionary برای وب، iOS و Android بهمحض merge شدن |
این تطبیق صرفاً یک ایدهی بامزه نیست. هر ردیف یک حالت خرابی واقعی را حل میکند.
Branch ها مانع از این میشوند که آزمایشهای نیمهتمام پالت رنگی به production نشت کنند. Review ها مشکلاتی مثل «رنگ برند را تیرهتر کردم و کنتراست را در سه وضعیت خراب کرد» را پیش از اینکه کاربران ببینند، میگیرند. Semantic versioning به تیمهای اپلیکیشن میگوید که آیا میتوانند بهروزرسانی شما را یک جمعه pull کنند یا باید برایش برنامهریزی کنند.
معنای diff معنایی (semantic diff) یک پالت رنگی چیست
یک semantic diff نشان میدهد یک تغییر توکن واقعاً چه معنایی دارد، نه فقط اینکه کدام کاراکترها جابهجا شدهاند. یک git diff خام به شما میگوید #ff6b3d تبدیل به #ff6434 شده است. یک semantic diff به شما میگوید رنگ اصلی برند کمی اشباعتر (saturated) شده، اینکه حالا روی ۱۴ کامپوننت اثر میگذارد، و اینکه مقدار جدید در وضعیت غیرفعال (disabled state) از آستانهی کنتراست شما پایینتر میرود.
در عمل، pull request به سطح review تبدیل میشود. نمونهرنگ قدیمی سمت چپ قرار میگیرد، نمونهرنگ جدید سمت راست، ویژگیهای تغییریافته فهرست میشوند، و یک reviewer آن را تأیید میکند یا درخواست تغییر میدهد. تمام مراسم همین است، و دقیقاً همان مهارتی است که یک code reviewer از قبل دارد.
ارزش این کار این است که یک تصمیم رنگی دیگر نامرئی نیست. پیش از این workflow، تغییرات پالت در یک فایل Figma اتفاق میافتاد، export میشد، و بدون هیچ سابقهای از اینکه چه کسی چه چیزی را تصمیم گرفته، به production میرسید. حالا تصمیم یک نویسنده، یک reviewer، یک timestamp و یک دلیل دارد. وقتی سه هفته بعد چیزی اشتباه بهنظر میرسد، شما changelog را میخوانید بهجای اینکه از تیم بازجویی کنید.
چرا این اتفاق الان دارد میافتد
سه چیز در کنار هم قرار گرفتند:
- Tokens Studio مسیر رفتوبرگشت بین Figma و GitHub را عملی کرد، پس طراحان دیگر برای قرار دادن توکنها در یک repo به یک مهندس نیاز ندارند.
- Style Dictionary بهعنوان لایهی build بالغ شد که یک منبع توکن را به خروجی مخصوص هر پلتفرم تبدیل میکند، و همین چیزی است که یک merge را به یک release واقعی تبدیل میکند.
- GitHub همیشه آنجا بود، بهعنوان بستر اصلی، با branch ها، pull request ها، review ها، release ها و changelog هایی که از قبل توسط هر تیم مهندسی روی کرهی زمین آزموده شده بودند.
محرک دیگر، مقیاس (scale) است. پلتفرمهایی مثل Supernova مدیریت و توزیع توکنها در میان چندین محصول را به یک محصول تبدیل کردهاند، که این دقیقاً نوع ابزاری است که فقط زمانی سراغش میروید که پالت شما بیش از یک اپ را تغذیه میکند. وقتی یک مجموعهتوکن هم به وب، هم به دو اپ native و هم به یک سایت مارکتینگ خدمت میکند، جملهی «فایل Figma را ویرایش کردم» دیگر جملهی امنی نیست.
نکتهی منصفانهی مقابل (design-ops theater واقعی است)
بیشتر تیمها به کل مراسم git-flow برای پالت رنگیشان نیاز ندارند. اگر یک استودیوی سهنفره هستید که یک محصول منتشر میکنید، پیچیدن هر تغییر رنگ کوچک در یک branch، یک pull request، دو تأیید و یک ارتقای semantic version، چیزی نیست جز کسپلی یک فرآیند (process cosplay). شما دارید هزینهی overhead مهندسی را میپردازید تا در برابر یک blast radius که اصلاً ندارید، محافظت کنید.
design-ops theater یک حالت خرابی واقعی است. بهنظر پیشرفت میرسد چون artifact تولید میکند: PR ها، changelog ها، صفهای review، برچسبهای وضعیت. اما artifact ها همان نتیجه (outcome) نیستند. اگر تغییر توکن شما فقط روی یک محصول اثر میگذارد که یک نفر مالک آن است، review در واقع شما هستید که خودتان را بررسی میکنید، و changelog دفترچهخاطراتی است که برای مخاطبی به تعداد یک نفر نگه میدارید.
این overhead در هر دو طرف واقعی است. version control به توکنها امنیت واقعی میدهد، و در عین حال تیمهایی را که آنقدر کوچکاند که اصلاً به آن نیازی ندارند، وسوسه میکند تا بهجای محصول، فرآیند منتشر کنند. دامی که در کمین است، پذیرفتن این آیین (ritual) فقط به این دلیل است که جدی بهنظر میرسد، و بعد تعجب کردن از اینکه چرا تغییرات سادهی رنگ حالا دو روز طول میکشد.
چطور توکنهای خود را زیر version control ببرید
از تصمیم شروع کنید، نه از ابزار. توکنهایی را نسخهبندی کنید که به بیش از یک مکان منتشر میشوند و وقتی تغییر میکنند چیزی را خراب میکنند. بقیه را در Figma، جایی که جایشان آنجاست، رها کنید.
اگر از این خط عبور کردید، راهاندازی کوتاه است:
- مجموعهتوکن خود را به داخل Tokens Studio در Figma منتقل کنید تا مقادیر، دادهی ساختاریافته باشند، نه استایلهای پراکنده.
- آن مجموعه را با یک repository در GitHub همگامسازی کنید. حالا هر تغییر یک commit است و هر پیشنهاد یک pull request.
- Style Dictionary را بهعنوان مرحلهی build اضافه کنید تا یک merge، توکنها را بهطور خودکار برای وب، iOS و Android کامپایل کند.
- قانون review خودتان را تعیین کنید. چه کسی باید پیش از merge شدن یک تغییر توکن را تأیید کند، و چه چیزی breaking محسوب میشود.
- changelog را همانطور که پیش میروید بنویسید. یک خط بهازای هر تغییر: چه چیزی تغییر کرده، چرا، و روی کدام پلتفرمها.
اگر از نسخهی دستیساخته فراتر رفتید، پلتفرمی مثل Supernova توکنها را در میان محصولات مدیریت و توزیع میکند تا مجبور نباشید pipeline را دستی پرستاری کنید. وقتی تعداد محصولات مصرفکننده، نه تعداد طراحان، توزیع دستی را دردناک میکند، سراغ آن بروید.
از این قانون برای تعیین جایگاه هر توکن استفاده کنید.
| موقعیت | جایی که توکن باید زندگی کند |
|---|---|
| به یک محصول خدمت میکند، یک مالک دارد، blast radius پایین | Figma، نیازی به مراسم PR نیست |
| به چندین پلتفرم یا محصول خدمت میکند | Repository، همراه با review و یک changelog |
| تغییر آن میتواند کنتراست، چیدمان (layout) یا برند را خراب کند | Repository، همراه با یک تأیید الزامی |
| آزمایشی یا محلی برای یک صفحه | Figma، آن را نسخهبندی نکنید |
سؤالات متداول
آیا تیمهای کوچک به توکنهای نسخهبندیشده نیاز دارند؟
معمولاً نه. اگر توکنهای شما فقط به یک محصول خدمت میکنند که یک نفر مالک آن است، review در واقع شما هستید که تغییر خودتان را تأیید میکنید و changelog یک دفترچهخاطرات است. وقتی یک ویرایش توکن میتواند برای کسی که در اتاق نیست چیزی را خراب کند، آن را بپذیرید.
تفاوت Tokens Studio و Style Dictionary چیست؟
Tokens Studio جایی است که توکنها را ویرایش و sync میکنید، و Figma را به یک repository در GitHub متصل میکند تا تغییرات به pull request تبدیل شوند. Style Dictionary مرحلهی build است که توکنهای ادغامشده را برای هر پلتفرم کامپایل میکند. یکی نویسندگی و review را مدیریت میکند، دیگری توزیع را.
آیا میتوان توکنها را بدون GitHub نسخهبندی کرد؟
میتوانید از هر میزبان version-control ای استفاده کنید، اما GitHub بستر رایج است چون branch ها، pull request ها، review ها، release ها و changelog ها از قبل بالغ هستند. این رویه مهمتر از برند است. آنچه نیاز دارید جایی است که در آن یک تغییر توکن به یک رویداد قابل بررسی و ثبتشده تبدیل شود.
semantic diff برای یک توکن طراحی چیست؟
این یک نمایش از معنای یک تغییر توکن است، نه فقط اینکه کدام کاراکترها تغییر کردهاند. بهجای نشان دادن اینکه یک مقدار هگزادسیمال به مقدار دیگری تبدیل شده، نمونهرنگ قدیمی را کنار نمونهرنگ جدید نشان میدهد، اینکه کدام کامپوننتها تحت تأثیر قرار گرفتهاند، و اینکه آیا این تغییر از یک آستانه مثل کنتراست عبور کرده یا نه. این کار یک تصمیم رنگی را قابل بررسی میکند.
آیا این جایگزین قضاوت طراح من میشود؟
نه. این کار قضاوت را بهجای نامرئی رها کردن، ثبت و بررسی میکند. این workflow تصمیم نمیگیرد که آیا رنگ جدید برند درست است یا نه؛ فقط مطمئن میشود که یک انسان آن را تأیید کرده و یک changelog، پیش از انتشار در هر پلتفرم، دلیل آن را توضیح میدهد.
نتیجهگیری (آنچه منتشر میشود را نسخهبندی کنید)
این تغییر واقعی است. Tokens Studio، Style Dictionary و GitHub با هم، توکن طراحی را از یک export ثابت به یک تغییر محصول نسخهبندیشده با branch ها، review ها، semantic diff ها و یک changelog تبدیل کردند. وقتی یک ویرایش میتواند همزمان روی هر پلتفرمی منتشر شود، سزاوار همان حفاظهای ایمنی است که مهندسان از قبل استفاده میکنند.
نظم و انضباط، دانستن جایگاه دقیق آن خط است. توکنهایی را نسخهبندی کنید که در پلتفرمهای مختلف منتشر میشوند و وقتی جابهجا میشوند چیزی را خراب میکنند. بقیه را در Figma رها کنید و در برابر وسوسهی پیچیدن یک تغییر رنگ تکمالکیتی در یک pull request با دو تأیید، مقاومت کنید.
Need a design system that ships across platforms without breaking? Brainy builds them.
Get Started
