فرض کن رنگ لینک‌ها و پس‌زمینهٔ دکمهٔ اصلی را از یک بنفش مشترک گرفته‌ای. موقع بررسی صفحه می‌بینی لینک‌ها بهتر است کمی تیره‌تر باشند. رنگ را تغییر می‌دهی، اما دکمه هم تیره می‌شود؛ در حالی که با رنگ دکمه مشکلی نداشتی.
این دو تا آن لحظه هم‌رنگ بودند، ولی دلیلی نداشت همیشه با هم تغییر کنند.
پالت رنگ به‌تنهایی مشخص نمی‌کند کدام بخش‌های صفحه باید با هم تغییر کنند. برای اینکه بتوانیم رنگ لینک را جدا از دکمه عوض کنیم، باید کاربرد هر رنگ را هم مشخص کنیم. توکن‌های طراحی برای همین به کار می‌آیند.
در قسمت قبل، صفحه‌ها را کنار کتابخانه گذاشتیم تا مشکلات تکراری را پیدا کنیم. حالا باید تصمیم بگیریم کدام انتخاب‌ها قرار است در سراسر محصول تکرار شوند و چطور آن‌ها را در اختیار طراح و توسعه‌دهنده بگذاریم.
اول مشخص کن چه چیزی را می‌خواهی یکدست کنی
در کار روی دیزاین‌سیستم رایتل، برای شناخت ساختار کامپوننت‌های متریال وقت گذاشتیم. این شناخت برای ساختن کامپوننت‌های موردنیازمان لازم بود. با این حال، استفاده از متریال قرار نبود جواب تمام سؤال‌های طراحی محصول را بدهد.
مثلاً برای نمایش خطای یک فیلد، انتخاب یک رنگ قرمز فقط بخشی از کار است. باید بدانیم کادر فیلد چه تغییری می‌کند، پیام خطا کجا می‌آید و آیا کنار آن آیکن هم لازم داریم. وقتی این موارد روشن شد، می‌توانیم برای هر بخش رنگ و فاصلهٔ مشخصی انتخاب کنیم و همان قاعده را در فرم‌های دیگر هم به کار ببریم.
توکن طراحی راهی برای نام‌گذاری و استفادهٔ دوباره از همین مقدارهاست. به‌جای اینکه هر بار کد یک رنگ یا عدد یک فاصله را وارد کنیم، آن را یک‌بار با یک نام تعریف می‌کنیم و در جاهای لازم به همان نام ارجاع می‌دهیم. یک توکن می‌تواند مقدار مشخصی داشته باشد یا مقدارش را از توکن دیگری بگیرد. تعریف گروه Design Tokens هم بر همین رابطهٔ نام و مقدار تکیه دارد.
بعد از انتخاب مقدارها، هنوز باید خوانایی پیام خطا و فاصله‌ها را در خود فرم بررسی کنیم. نام‌گذاری درست، مناسب‌بودن آن‌ها را تضمین نمی‌کند.
برای توضیح ادامهٔ مطلب، از چند نام و مقدار فرضی استفاده می‌کنم. این مثال‌ها از فایل توکن‌های رایتل یا نام‌گذاری متریال برداشته نشده‌اند.
اسم رنگ را از کاربردش جدا کن
برگردیم به همان لینک و دکمهٔ بنفش.
در پالت، رنگی با نام palette/purple/600 و کد #6B3FA0 داریم. این نام می‌گوید کدام بنفش را انتخاب کرده‌ایم، اما نمی‌گوید قرار است کجا استفاده شود. عدد ۶۰۰ هم اینجا فقط جای آن رنگ را در طیف بنفش مشخص می‌کند؛ اندازه یا درصد نیست.
برای متن لینک و پس‌زمینهٔ دکمه، دو نام جدا تعریف می‌کنیم و فعلاً هر دو را به همان بنفش وصل می‌کنیم:
| نام توکن | مقدارش را از کجا می‌گیرد؟ | کجا استفاده می‌شود؟ |
|---|---|---|
palette/purple/600 |
مقدار مستقیم #6B3FA0 |
یکی از رنگ‌های پالت |
color/text/link |
از palette/purple/600 |
متن لینک در حالت عادی |
color/background/action |
از palette/purple/600 |
پس‌زمینهٔ دکمهٔ اصلی در حالت عادی |
در این ساختار، رنگ پالت یک توکن پایه است که معمولاً به آن Primitive یا Reference می‌گویند. دو توکن بعدی کاربرد رنگ را مشخص می‌کنند و به آن‌ها Semantic می‌گویند. وقتی یک توکن مقدارش را از توکن دیگری می‌گیرد، این ارتباط Alias نام دارد.
حالا برای تیره‌تر کردن لینک‌ها، کافی است color/text/link را به بنفش تیره‌تری وصل کنیم. دکمه همچنان از رنگ قبلی استفاده می‌کند.
اما اگر به‌جای این کار، مقدار خودِ palette/purple/600 را تغییر بدهیم، در ساختار اولیه هم لینک عوض می‌شود و هم دکمه. هر دو هنوز به همان رنگ وصل‌اند. پس قبل از تغییر باید بدانیم می‌خواهیم رنگ پالت عوض شود یا فقط رنگی که برای لینک انتخاب کرده‌ایم.
این نوع نام‌گذاری برای تم روشن و تیره هم کمک می‌کند. مثلاً color/text/default از text/black انتخاب بهتری برای متن اصلی است. در تم تیره ممکن است متن روشن شود، ولی همچنان متن اصلی صفحه است. نامش هنوز معنی دارد، حتی وقتی رنگش عوض شده است. البته خوانایی آن روی پس‌زمینهٔ جدید را باید دوباره بررسی کنیم.
برای فاصله‌ها هم دلیل داشته باش
فرض کن برای فاصله‌گذاری از اندازه‌های ۴، ۸، ۱۲، ۱۶، ۲۴ و ۳۲ پیکسل استفاده می‌کنیم. این مجموعه کمک می‌کند در هر صفحه یک عدد تازه انتخاب نکنیم، ولی هنوز جواب نمی‌دهد که فاصلهٔ عنوان یک فیلد تا خود فیلد چقدر باشد.
اگر در چند فرم به همین فاصله نیاز داریم، می‌توانیم نام space/field/label-gap را برایش تعریف کنیم و آن را به مقدار ۸ پیکسل وصل کنیم. توضیحش هم باید مشخص باشد: فاصلهٔ عنوانی که بالای فیلد قرار دارد تا کادر فیلد.
بعداً اگر لازم شد این فاصله را بیشتر کنیم، مرجع همین توکن را تغییر می‌دهیم. فاصلهٔ ۸ پیکسلی بین آیکن و متن دکمه، که کاربرد دیگری دارد، سر جایش می‌ماند.
من برای هر فاصله در هر صفحه، توکن جدا نمی‌سازم. وقتی یک انتخاب در چند جا تکرار می‌شود و لازم است بتوانیم آن را مستقل از بقیه تغییر بدهیم، نام جدا به کار می‌آید. برای یک مورد خاص، شاید انتخاب یکی از فاصله‌های موجود و توضیح دلیلش کافی باشد. خودِ اندازه‌ها را هم باید با توجه به محصول انتخاب کنیم؛ این چند عدد فقط یک مثال‌اند.
برای تایپوگرافی، اندازهٔ فونت کافی نیست
دو متن می‌توانند هر دو ۱۶ پیکسل باشند، ولی یکی راحت خوانده شود و دیگری فشرده به نظر برسد. فونت، وزن آن، فاصلهٔ خطوط و عرضی که به متن داده‌ایم، همگی روی نتیجه اثر دارند.
به همین خاطر، اول مشخص می‌کنم متن چه کاربردی دارد: متن اصلی است، عنوان فیلد است یا توضیح زیر آن؟ بعد تنظیمات مناسب همان کاربرد را کنار هم می‌گذارم. نامی مثل type/body/default باید به طراح کمک کند استایل مناسب را پیدا کند.
در فیگما می‌توانیم فونت، اندازه، وزن و فاصلهٔ خطوط را در یک Text Style نگه داریم و با یک انتخاب روی متن اعمال کنیم. Variables هم برای نگهداری مقدارهای مشترک به کار می‌روند؛ مثلاً اندازهٔ فونتی که در چند استایل استفاده می‌شود. می‌توان این دو را با هم به کار برد و لازم نیست همهٔ استایل‌ها را با متغیر جایگزین کنیم. راهنمای فیگما این تفاوت را توضیح می‌دهد.
اگر محصول فارسی و انگلیسی دارد، متن واقعی هر دو زبان را امتحان کن. تنظیماتی که برای یک پاراگراف انگلیسی مناسب‌اند، ممکن است برای فارسی به فاصلهٔ خطوط متفاوتی نیاز داشته باشند. یک عنوان طولانی، پیام خطای دوخطی یا شمارهٔ تلفن وسط جملهٔ فارسی، خیلی بیشتر از یک متن کوتاه نمونه نشان می‌دهد کجا باید تنظیمات را اصلاح کنیم.
از یک فرم شروع کن و تغییرها را ببین
برای شروع لازم نیست فهرست بزرگی از توکن‌ها بسازیم. من همان فرم مرحلهٔ بررسی را برمی‌دارم و رنگ‌های موردنیازش را مشخص می‌کنم. برای یک فرم ساده، شاید حدود پنج یا شش کاربرد کافی باشد: رنگ متن اصلی، متن راهنما، لینک، خطا، پس‌زمینهٔ فرم و پس‌زمینهٔ دکمه.
فاصله‌های تکراری و استایل‌های متن را هم مشخص می‌کنم و آن‌ها را روی لایه‌های کامپوننت‌ها اعمال می‌کنم. بعد، هر بار یک مورد را تغییر می‌دهم تا نتیجه معلوم باشد. مثلاً فقط رنگ لینک را عوض می‌کنم و می‌بینم آیا دکمه ثابت مانده است. یا فاصلهٔ عنوان و فیلد را بیشتر می‌کنم و بررسی می‌کنم که فاصله‌های دیگر تغییر نکرده باشند.
اگر چیزی که انتظار نداشتم تغییر کرد، اتصالش به توکن را بررسی می‌کنم. اگر بخش موردنظر اصلاً تغییر نکرد، شاید هنوز مقدارش دستی وارد شده و به توکن وصل نباشد.
گاهی برای یک کامپوننت، توکن اختصاصی لازم می‌شود؛ مثلاً رنگ پس‌زمینهٔ دکمه در یک حالت مشخص باید جدا قابل‌تغییر باشد. اما از همان ابتدا برای تمام حالت‌های ممکن توکن نمی‌سازم. هر نام تازه باید کاربرد روشنی داشته باشد، وگرنه فقط انتخاب را برای طراح سخت‌تر می‌کند.
با توسعه‌دهنده دربارهٔ معادل توکن‌ها توافق کن
تا اینجا تصمیم‌ها را در فیگما مشخص کرده‌ایم. برای اینکه همان تصمیم‌ها در محصول هم اجرا شوند، باید با توسعه‌دهنده دربارهٔ نام و کاربردشان توافق کنیم. ساختن یک Variable در فیگما، به‌خودی‌خود چیزی را در وب‌سایت تغییر نمی‌دهد.
مثلاً color/text/link ممکن است در CSS با نام --color-text-link استفاده شود. لازم نیست شکل نوشتن این دو دقیقاً یکسان باشد، ولی باید معلوم باشد به یک کاربرد و یک مقدار اشاره می‌کنند.
در یک جدول کوتاه بنویسید هر توکن در طراحی چه معادلی در کد دارد. مشخص کنید نسخهٔ مرجع مقدارها کجاست و اگر چیزی تغییر کرد، چه کسی باید فیگما یا کد را به‌روز کند. این توافق جلوی حالتی را می‌گیرد که رنگ در فایل طراحی عوض شده، ولی محصول هنوز از مقدار قبلی استفاده می‌کند.
بعد یک صفحهٔ پیاده‌شده را با هم ببینید. رنگ لینک از توکن درست گرفته شده؟ پیام خطا از رنگ متن خطا استفاده می‌کند؟ عنوان طولانی درست نمایش داده می‌شود؟ این بررسی نشان می‌دهد تصمیمی که در کتابخانه گرفته‌ایم، در صفحهٔ واقعی هم جواب داده یا نه.
کنار نام هر توکن، کاربرد، مقدار یا توکنی که به آن وصل است و یک نمونهٔ استفاده را نگه دار. اگر انتخاب بین دو توکن هنوز برای طراح مبهم است، احتمالاً تفاوت کاربردشان خوب توضیح داده نشده یا هنوز دلیلی برای جدا بودنشان نداریم.
در قسمت بعد، «ساختن دکمه، بدون ساختن تمام ترکیب‌های ممکن»، سراغ خودِ کامپوننت می‌رویم: کدام تفاوت‌ها به Variant نیاز دارند، چه چیزهایی را می‌شود با Properties تنظیم کرد و چطور از ساختن نسخه‌هایی که استفاده نمی‌شوند پرهیز کنیم.