واریانت در فیگما؛ ساخت کامپوننت چندحالته قدم‌به‌قدم

واریانت در فیگما راهی است برای جمع کردن چند نسخه‌ی مرتبط از یک کامپوننت، مثلاً دکمه‌ی اصلی و فرعی در اندازه‌ها و وضعیت‌های مختلف، داخل یک مجموعه‌ی واحد به نام Component set. به‌جای ده کامپوننت جدا، یک کامپوننت دارید که در پنل راست با چند منوی کشویی بین حالت‌هایش جابه‌جا می‌شوید.

این ویژگی کتابخانه‌ی کامپوننت‌ها را خلوت‌تر، جست‌وجو را ساده‌تر و تغییر حالت را بدون جایگزین کردن نمونه‌ها ممکن می‌کند. در این راهنما واریانت‌ها را با سه مثال واقعی می‌سازیم و یاد می‌گیریم چه زمانی نباید واریانت جدید اضافه کرد.

واریانت دقیقاً چه مشکلی را حل می‌کند؟

پیش از واریانت‌ها، طراحان برای هر حالت یک کامپوننت جدا می‌ساختند و با نام‌هایی مثل Button/Primary/Large/Hover آن‌ها را مرتب می‌کردند. برای عوض کردن حالت یک دکمه باید کامپوننت را از کتابخانه پیدا و جایگزین می‌کردید. واریانت‌ها همین ساختار نام‌گذاری را به پراپرتی‌های قابل انتخاب تبدیل کردند.

• یک نقطه‌ی ورود: در پنل Assets فقط «Button» را می‌بینید، نه ده‌ها کامپوننت جدا.
• تغییر سریع: نوع، اندازه یا وضعیت را از منوی پنل راست عوض می‌کنید و تغییرات متن یا آیکون نمونه تا جای ممکن حفظ می‌شود.
• مستندسازی زنده: Component set نشان می‌دهد این کامپوننت دقیقاً چه حالت‌هایی دارد و چه حالتی وجود ندارد.
• پایه‌ی پروتوتایپ: واریانت‌ها اساس کامپوننت‌های تعاملی‌اند.

ساخت اولین واریانت در فیگما: دکمه

یک دکمه با اتولی‌اوت بسازید و آن را به کامپوننت تبدیل کنید. اگر هنوز با اتولی‌اوت راحت نیستید، اول آموزش اتولی‌اوت در فیگما را ببینید؛ واریانتی که روی اتولی‌اوت ساخته نشده باشد با تغییر متن به‌هم می‌ریزد.

• کامپوننت دکمه را انتخاب کنید و در پنل راست، کنار عنوان کامپوننت، گزینه‌ی افزودن واریانت (Add variant) را بزنید. فیگما کامپوننت را داخل یک Component set با کادر بنفش خط‌چین می‌گذارد و یک نسخه‌ی دوم می‌سازد.
• اگر از قبل چند کامپوننت جدا دارید، همه را انتخاب کنید و Combine as variants را بزنید.
• در پنل راست، نام پیش‌فرض پراپرتی (کلمه‌ی Property همراه با یک شماره) را به نامی معنادار مثل Type تغییر دهید و مقدارهای Primary و Secondary را به نسخه‌ها بدهید.
• پراپرتی دوم، مثلاً Size، را اضافه کنید و برای هر نوع، نسخه‌های Large و Small بسازید.
• ظاهر هر واریانت را جداگانه تنظیم کنید: رنگ پس‌زمینه، رنگ متن، حاشیه و ارتفاع.

فیگما نام هر واریانت را به شکل جفت‌های پراپرتی و مقدار ذخیره می‌کند، مثل Type=Primary, Size=Large. به همین دلیل می‌توانید با تغییر نام لایه‌ها هم پراپرتی‌ها را بسازید. واریانتی که در گوشه‌ی بالا و چپ Component set قرار دارد، حالت پیش‌فرض است و وقتی کامپوننت را از Assets روی بوم می‌کشید همان ظاهر می‌شود.

نام‌گذاری پراپرتی‌ها و مقدارها

نام‌گذاری خوب، تفاوت یک کتابخانه‌ی قابل استفاده و یک فهرست گیج‌کننده است. این قواعد را از روز اول رعایت کنید:

• پراپرتی‌ها را بر اساس محورهای مستقل تعریف کنید: نوع (Type)، اندازه (Size)، وضعیت (State). هر محور باید مستقل از بقیه قابل تغییر باشد.
• مقدارها را یکدست بنویسید؛ اگر یک جا Large است، جای دیگر Lg ننویسید.
• برای پراپرتی‌های دوحالته از مقدارهای True و False یا On و Off استفاده کنید؛ فیگما این‌ها را در پنل نمونه به شکل کلید روشن و خاموش نشان می‌دهد.
• نام پراپرتی‌ها را با واژه‌هایی هماهنگ کنید که برنامه‌نویس در کد استفاده می‌کند؛ اگر در کد variant و size دارید، در فیگما هم همان را ببینید.
• نام‌ها را انگلیسی نگه دارید، حتی در محصول فارسی؛ چون مستقیم با کد و ابزارهای تحویل هماهنگ می‌شوند.

مثال دوم: فیلد ورودی با وضعیت‌های مختلف

فیلد ورودی نمونه‌ی خوبی برای پراپرتی State است. یک فیلد «شماره‌ی موبایل» برای فرم ورود اپ را در نظر بگیرید که این حالت‌ها را لازم دارد:

• Default: کادر خاکستری و متن راهنما.
• Focus: کادر به رنگ برند و نشانگر تایپ.
• Filled: شماره وارد شده و متن راهنما بالای فیلد رفته است.
• Error: کادر قرمز و پیام خطا زیر فیلد، مثل «شماره‌ی موبایل باید با ۰۹ شروع شود».
• Disabled: کنتراست کمتر و بدون امکان تعامل.

دقت کنید پیام خطا فقط در حالت Error دیده می‌شود. به‌جای ساختن لایه‌ی جدید در یک واریانت، پیام خطا را در همه‌ی واریانت‌ها نگه دارید و در بقیه مخفی کنید. این کار باعث می‌شود متنی که طراح در یک نمونه نوشته، با تغییر State از دست نرود، چون فیگما تغییرات را بر اساس نام و ساختار یکسان لایه‌ها منتقل می‌کند.

کامپوننت تعاملی: واریانت‌هایی که در پروتوتایپ زنده می‌شوند

یکی از کاربردهای مهم واریانت‌ها، ساختن کامپوننت تعاملی (Interactive component) است. یک سوییچ روشن و خاموش برای صفحه‌ی تنظیمات اعلان‌های یک اپ بانکی بسازید:

• دو واریانت با پراپرتی State و مقدارهای Off و On بسازید.
• به زبانه‌ی Prototype بروید، واریانت Off را انتخاب کنید و یک تعامل On click با عمل Change to به واریانت On اضافه کنید.
• همین کار را برعکس برای On انجام دهید و انیمیشن را Smart Animate بگذارید.
• حالا هر نمونه‌ی این سوییچ در هر صفحه‌ای از پروتوتایپ، خودش با کلیک روشن و خاموش می‌شود.

با همین روش می‌توانید حالت Hover دکمه، باز و بسته شدن آکاردئون پرسش‌های متداول یا انتخاب چیپ‌های فیلتر در صفحه‌ی جست‌وجوی یک فروشگاه را بسازید، بدون این‌که برای هر حالت یک صفحه‌ی جدا در پروتوتایپ داشته باشید.

واریانت، کامپوننت جدا یا متغیر؟ معیار تصمیم

بیشتر سردرگمی‌ها از این‌جا می‌آید که طراح نمی‌داند یک تفاوت جدید را کجا تعریف کند. پیش از افزودن هر واریانت، این سه سؤال را به ترتیب بپرسید:

• آیا این دو چیز کاربرد متفاوتی دارند؟ اگر بله، دو کامپوننت جدا بسازید. کارت محصول و کارت مقاله ممکن است شبیه باشند، ولی کاربرد و محتوایشان فرق دارد.
• آیا ساختار لایه‌ها عوض می‌شود؛ مثلاً یک بخش اضافه یا جابه‌جا می‌شود یا چیدمان از افقی به عمودی می‌رود؟ اگر بله، واریانت مناسب است.
• آیا فقط رنگ، اندازه‌ی فونت یا فاصله عوض می‌شود و همین تفاوت در کل محصول تکرار می‌شود، مثل تم روشن و تیره یا برند اصلی و زیربرند؟ اگر بله، متغیر با چند Mode راه‌حل بهتری است.

یک مثال ایرانی: فرض کنید یک اپ پرداخت دارید که کارت‌های بانکی کاربر را نشان می‌دهد. شکل کارت برای همه‌ی بانک‌ها یکی است و فقط رنگ و لوگو فرق دارد. ساختن یک واریانت برای هر بانک، Component set را به ده‌ها نسخه می‌رساند؛ در حالی که با یک پراپرتی تعویض لوگو و چند متغیر رنگ، همان نتیجه با یک کامپوننت ساده به دست می‌آید. در مقابل، کارتی که در حالت «منقضی‌شده» یک نوار هشدار و دکمه‌ی تمدید اضافه دارد، تفاوت ساختاری دارد و واریانت State برایش منطقی است.

مراقب انفجار تعداد واریانت‌ها باشید

حساب ساده‌ای را در نظر بگیرید: دکمه‌ای با سه نوع، سه اندازه، پنج وضعیت و دو حالت با آیکون و بدون آیکون، ۹۰ واریانت می‌شود. نگه‌داری چنین مجموعه‌ای سخت است، فایل را سنگین می‌کند و هر تغییر کوچک باید ده‌ها بار تکرار شود.

• هر چیزی که فقط نمایش یا عدم نمایش یک لایه است (مثل آیکون) را به‌جای واریانت با پراپرتی Boolean کنترل کنید.
• متن دکمه را با پراپرتی Text قابل ویرایش کنید، نه با واریانت‌های جدا.
• تفاوت‌هایی که فقط رنگ یا فاصله‌اند، مثل حالت روشن و تیره، را با متغیرها و Modeها حل کنید؛ آموزش متغیرها در فیگما این روش را توضیح می‌دهد.
• وضعیت‌هایی را که در کد واقعاً وجود ندارند حذف کنید؛ اگر اپ موبایل شما Hover ندارد، واریانت Hover هم لازم نیست.

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

اشتباه‌های رایج در ساخت واریانت‌ها

• ساختار لایه‌ی متفاوت در واریانت‌ها؛ اگر نام لایه‌ی متن در یک واریانت Label و در دیگری Text باشد، متن نمونه با تغییر واریانت از دست می‌رود.
• Detach کردن نمونه برای یک تغییر کوچک؛ اگر حالتی کم است، به کامپوننت اصلی اضافه‌اش کنید.
• قرار دادن کامپوننت‌های بی‌ربط در یک Component set؛ دکمه و لینک متنی، حتی اگر شبیه باشند، معمولاً دو کامپوننت جدا هستند.
• چیدمان نامرتب داخل Component set؛ واریانت‌ها را در جدولی منظم با ردیف‌های نوع و ستون‌های وضعیت بچینید تا هر کسی در یک نگاه همه‌ی حالت‌ها را ببیند.

سوالات متداول

تفاوت کامپوننت و واریانت در فیگما چیست؟

کامپوننت یک عنصر قابل استفاده‌ی دوباره است و واریانت یکی از حالت‌های آن داخل یک Component set. برای مبانی کامپوننت‌ها، راهنمای کامپوننت در فیگما را بخوانید.

چطور واریانت پیش‌فرض را تغییر دهم؟

واریانتی که در گوشه‌ی بالا و چپ Component set قرار دارد پیش‌فرض است. کافی است واریانت دلخواه را به آن نقطه منتقل کنید.

آیا می‌شود واریانت‌های یک کامپوننت را از کتابخانه‌ی تیم استفاده کرد؟

بله؛ وقتی کتابخانه منتشر شود، Component set با همه‌ی واریانت‌هایش در فایل‌های دیگر قابل استفاده است. انتشار کتابخانه‌ی تیمی به پلن پولی فیگما نیاز دارد.

چند واریانت برای یک کامپوننت زیاد است؟

عدد ثابتی وجود ندارد، اما اگر برای پیدا کردن یک حالت مجبور به اسکرول در Component set هستید یا هر تغییر را ده‌ها بار تکرار می‌کنید، بخشی از واریانت‌ها را با پراپرتی یا متغیر جایگزین کنید.

کامپوننت‌هایی که با محصول رشد می‌کنند

واریانت‌ها وقتی خوب طراحی شوند، کتابخانه‌ی شما را از مجموعه‌ای از کامپوننت‌های پراکنده به سیستمی منظم تبدیل می‌کنند که هم طراح و هم برنامه‌نویس آن را می‌فهمد. محورهای مستقل تعریف کنید، ساختار لایه‌ها را یکسان نگه دارید و جلوی تکثیر بی‌دلیل واریانت‌ها را بگیرید. اگر می‌خواهید ساخت کامپوننت‌های چندحالته را روی یک پروژه‌ی واقعی و با بازخورد مربی تمرین کنید، دوره‌ی آموزش فیگما آکادمی طراحی دایره را ببینید؛ و برای ادامه‌ی مسیر به سمت کتابخانه‌ی کامل، دوره‌ی دیزاین سیستم قدم بعدی است.