طراحی سیستم آیکون یکپارچه

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

اعدادی مانند Grid بیست‌وچهار در بیست‌وچهار، stroke دو پیکسل و شعاع دو پیکسل می‌توانند انتخاب یک سیستم باشند، ولی قانون همه آیکون‌ها نیستند. مقصد، اندازه نمایش، قلم رابط و سبک محصول بر این انتخاب‌ها اثر دارند. برای نمونه، راهنمای رسمی آیکون‌های IBM شبکه پایه سی‌ودو پیکسلی را توصیف می‌کند. این تفاوت نشان می‌دهد باید قواعد سیستم خود را روشن بنویسید، نه اینکه یک مقدار رایج را بدون دلیل تکرار کنید.

فهرست معناها را پیش از شکل‌ها بسازید

کنترل‌های محصول را بررسی کنید و برای هرکدام نام عمل یا مفهوم را بنویسید: جست‌وجو، ذخیره، دانلود، حذف، بستن یا اطلاعات. بعضی واژه‌ها نزدیک به هم هستند ولی رفتار متفاوت دارند. «حذف» ممکن است داده را از بین ببرد، در حالی که «برداشتن از فهرست» فقط رابطه‌ای را تغییر دهد. اگر برای هر دو یک نشانه بدون متن استفاده شود، احتمال ابهام افزایش می‌یابد. قرارداد معنایی باید از رفتار واقعی بیاید.

هم‌معناها را نیز ثبت کنید. تیم محتوا ممکن است «ویرایش» بنویسد و طراح فایل را edit نام بگذارد؛ این تفاوت با یک نام اصلی و واژه‌های جست‌وجو قابل مدیریت است. نام فایل مبهم مانند icon-final به مصرف کمک نمی‌کند. دسته‌بندی را بر اساس نیاز جست‌وجو بسازید، نه صرفاً شکل ظاهری. پیدا کردن آیکون مناسب نباید به حافظه کسی وابسته باشد که آن را طراحی کرده است.

نشانه‌های اصلی را انتخاب کنید

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

استعاره‌های بصری نیز باید برای مخاطب قابل فهم باشند. شکل آشنای یک ابزار ممکن است برای یک گروه واضح و برای گروهی دیگر نامأنوس باشد. کنار آیکون متن قرار دهید و از مخاطب درباره عمل کنترل سؤال کنید. پرسش «این شکل چیست؟» با «با انتخاب این کنترل چه اتفاقی می‌افتد؟» یکسان نیست. موضوع کاربردی در راهنمای آیکونوگرافی وب با جزئیات بیشتری توضیح داده شده است.

Grid و محدوده داخلی

Grid به هماهنگی مختصات و نسبت‌ها کمک می‌کند، اما نباید همه شکل‌ها را به یک قاب داخلی یکسان فشرده کند. دایره و مربع با ابعاد هندسی برابر الزاماً وزن بصری برابر ندارند. چند key shape برای فرم‌های گرد، پهن و بلند تعریف کنید و اجازه اصلاح optical بدهید. هدف این است که آیکون‌ها در یک ردیف هم‌وزن دیده شوند، نه اینکه همه دقیقاً از یک مستطیل عبور کنند.

میان اندازه canvas و اندازه شکل تفاوت بگذارید. فایل می‌تواند فضای بیرونی ثابت داشته باشد تا جای‌گذاری آسان شود، در حالی که شکل داخل آن کمی متفاوت است. همچنین اندازه آیکون با اندازه ناحیه قابل کلیک یکسان نیست. آیکون کوچک می‌تواند در دکمه‌ای با فضای تعامل بزرگ‌تر قرار گیرد. تغییر stroke برای بزرگ کردن ناحیه کلیک، مسئله را حل نمی‌کند؛ ظرف کنترل مسئول آن فضاست.

قواعد خط و گوشه

برای سبک outline، ضخامت خط، نوع cap، اتصال‌ها و شعاع گوشه‌ها را مشخص کنید. تفاوت تصادفی این ویژگی‌ها مجموعه را پراکنده می‌کند. اما یک استثنای لازم برای نشانه پیچیده باید قابل ثبت باشد. اگر جزئیات فشرده هستند، حذف جزء غیرضروری ممکن است از نازک کردن تمام خطوط بهتر باشد. در اندازه کوچک، فاصله‌های داخل شکل به اندازه خط‌ها اهمیت دارند و بسته شدن آن‌ها معنی را تغییر می‌دهد.

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

اندازه و نسخه‌های مصرف

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

نسبت‌ها را با قلم و کنترل‌های کنار آیکون هم بسنجید. یک نشانه از نظر خودش متعادل است ولی کنار متن سنگین‌تر دیده می‌شود. baseline، فاصله از برچسب و جای آن در کنترل را بخشی از راهنمای مصرف کنید. اعداد فاصله بهتر است از قواعد عمومی محصول بیایند. هر مؤلفه نباید تنظیمی مستقل داشته باشد که در نهایت مجموعه را به چند زبان بصری تقسیم کند.

جهت در رابط فارسی

همه آیکون‌ها نباید در RTL آینه شوند. نشانه‌های حرکت در مسیر ناوبری ممکن است جهت متناسب بخواهند، اما علامت یک برند یا مفهوم ثابت معمولاً قرارداد دیگری دارد. برای هر نشانه جهت‌دار، تصمیم را ثبت کنید. «بعدی» در یک فهرست مرحله‌ای با جهت پخش رسانه یا علامت جغرافیایی الزاماً یک رفتار ندارد. آینه کردن عمومی تمام SVGها می‌تواند اطلاعات اشتباه بسازد.

جای آیکون کنار متن نیز باید با ترتیب خواندن و معنای کنترل هماهنگ باشد. استفاده از ویژگی‌های logical در CSS کمک می‌کند فاصله‌ها با جهت رابط تطبیق پیدا کنند. اما تغییر جای خودکار نباید جای تصمیم معنایی را بگیرد. متن فارسی و واژه لاتین در یک برچسب را با داده واقعی بررسی کنید. مسئله جهت فقط یک transform در فایل طراحی نیست، بلکه بخشی از رفتار مؤلفه است.

نام کنترل و کنتراست

آیکون تزئینی کنار متن لازم نیست دوباره همان معنی را اعلام کند. اگر کنترل فقط آیکون دارد، خود کنترل باید نام قابل فهم داشته باشد. اسم فایل یا title عمومی «icon» نام مناسبی برای عمل نیست. برچسب را به نتیجه عمل وصل کنید و حالت تغییرپذیر کنترل را نیز روشن کنید. اگر آیکون ذخیره پس از انتخاب به حذف از ذخیره تبدیل می‌شود، نام و وضعیت باید با رفتار تازه هماهنگ باشند.

تمایز رنگ و شکل را در زمینه‌های مصرف بسنجید. یک رنگ روی سفید ممکن است مناسب باشد ولی روی سطح خاکستری نه. راهنمای کنتراست و WCAG محدوده کنتراست متن و اجزای معنادار را جدا توضیح می‌دهد. حالت hover، focus و selected نیز باید بررسی شوند. شکل آیکون فقط یکی از بخش‌های کنترل است و ظاهر آن نباید نشان focus یا متن ضروری را پنهان کند.

نمونه مصرف هماهنگ

نمونه زیر یک فایل HTML مستقل با دو لینک واقعی مجله است. آن را با نام icon-links.html ذخیره و در مرورگر باز کنید. نصب و وابستگی خارجی ندارد؛ دو SVG داخل فایل هستند. آیکون‌ها تزئینی‌اند و نام لینک از متن می‌آید. اندازه پایه این نمونه بیست‌وچهار است، صرفاً برای همین نمایش آموزشی. فایل نشان می‌دهد قواعد مشترک چطور در مؤلفه مصرف می‌شوند؛ مجموعه عمومی آیکون آماده برای همه محصولات نیست.

<!doctype html><html lang="fa" dir="rtl"><meta charset="utf-8"><meta name="viewport" content="width=device-width,initial-scale=1"><title>لینک‌های دارای آیکون</title>
<style>body{font:1rem/1.8 system-ui;color:#17324d;margin:2rem}.links{display:flex;flex-wrap:wrap;gap:1rem}a{display:inline-flex;align-items:center;gap:.6rem;padding:.75rem;color:#084c8d;border:1px solid #46657d;border-radius:.5rem}a:focus-visible{outline:3px solid #084c8d;outline-offset:3px}.icon{width:24px;height:24px;flex:none;fill:none;stroke:currentColor;stroke-width:2;stroke-linecap:round;stroke-linejoin:round}</style>
<h1>راهنماهای تصویری وب</h1><nav class="links" aria-label="راهنماها">
<a href="https://tarahestan.com/magazine/svg-vector-graphics-web-guide"><svg class="icon" viewBox="0 0 24 24" aria-hidden="true" focusable="false"><rect x="4" y="3" width="16" height="18" rx="2"/><path d="M8 8h8M8 12h8M8 16h5"/></svg><span>راهنمای SVG</span></a>
<a href="https://tarahestan.com/magazine/web-image-optimization-format-compression"><svg class="icon" viewBox="0 0 24 24" aria-hidden="true" focusable="false"><rect x="3" y="4" width="18" height="16" rx="2"/><circle cx="8" cy="9" r="1"/><path d="m4 18 5-5 4 4 3-3 4 4"/></svg><span>بهینه‌سازی تصاویر</span></a>
</nav></html>

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

فایل، نسخه و مشارکت تیم

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

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