گرافیک و برندینگ

طراحی آیکون: اصول و سبک‌ها

انتخاب مفهوم و خانواده آیکون، Grid و optical balance، تفاوت glyph و target، برچسب دسترس‌پذیر، کنتراست و قرارداد RTL و تحویل.

1404/11/05 1 دقیقه مطالعه 2,319 بازدید

آیکون باید در زمینهٔ استفاده فهمیده شود

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

همچنین همهٔ آیکون‌ها لازم نیست در ۱۶ پیکسل همان جزئیات نسخهٔ بزرگ را حفظ کنند. اندازهٔ هدف، کاربرد و سیستم مقصد باید تعیین شوند. ممکن است برای اندازهٔ کوچک نسخهٔ ساده‌تر لازم باشد. یک علامت تزئینی در پوستر با control کوچک toolbar قرارداد متفاوت دارد. طراحی باید این تفاوت را ثبت کند. هدف این راهنما انتخاب فرم، اندازه و رفتار است و در این مرحله تصویر یا مجموعهٔ آیکون تازه تولید نمی‌شود.

ابتدا مفهوم و عمل را جدا کنید

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

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

یک مجموعه باید قواعد مشترک داشته باشد

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

Grid به قرار دادن نقطه‌ها و حفظ نسبت کمک می‌کند. انتخاب ۲۴ در ۲۴ یا ۱۶ در ۱۶، وابسته به اندازهٔ خروجی و سیستم است؛ هیچ grid واحدی برای همهٔ آیکون‌ها الزامی نیست. فضای اطراف شکل باید در محدودهٔ export روشن باشد تا alignment در مصرف‌کننده قابل پیش‌بینی شود. یک شکل پر از فضای خالی ممکن است کنار شکل دیگر کوچک‌تر دیده شود، حتی وقتی فایل‌ها اندازهٔ برابر دارند. بنابراین اندازهٔ bounding box و اندازهٔ دیداری را جدا بخوانید.

Outline و filled نقش و وزن متفاوت دارند

Outlined با خط مرزی شکل را می‌سازد و filled سطح اصلی را پر می‌کند. Duotone از دو سطح یا tone برای تمایز استفاده می‌کند. سبک آزاد یا دست‌کشیده می‌تواند برای هویت خاص مناسب باشد، اما در toolbar متراکم شاید خوانایی دیگری داشته باشد. انتخاب سبک را به محصول وصل کنید. ترکیب چند خانوادهٔ نامرتبط در یک مجموعه، تفاوت وزن و زبان شکل ایجاد می‌کند. اگر از library آماده استفاده می‌کنید، نسخه و خانوادهٔ انتخاب‌شده را ثبت کنید.

در Material Symbols، محورهایی مانند fill، weight و optical size امکان تنظیم ظاهر خانواده را می‌دهند. راهنمای رسمی Material Symbols این قابلیت‌ها را توضیح می‌دهد. داشتن محور تنظیم به معنی مناسب بودن هر ترکیب برای همهٔ اندازه‌ها نیست. مقدارها باید با نقش و کنتراست مجموعه هماهنگ باشند. همچنین تغییر حالت filled می‌تواند بخشی از نمایش انتخاب باشد، ولی وضعیت انتخاب باید برای همهٔ کاربران قابل تشخیص بماند.

تمرین با سه نقش محدود

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

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

اندازهٔ نماد با اندازهٔ target فرق دارد

یک نماد ۲۰ پیکسلی می‌تواند داخل دکمه‌ای بزرگ‌تر قرار بگیرد. سطح قابل کلیک نباید فقط خط‌های باریک خود نماد باشد. WCAG 2.2 در معیار Target Size Minimum اندازهٔ ۲۴ در ۲۴ CSS pixel یا شرایط استثنای مشخص را مطرح می‌کند؛ این عدد اندازهٔ الزامی خود glyph نیست. توضیح رسمی Target Size شرایط و استثناها را بیان می‌کند. حداقل معیار هم لزوماً راحت‌ترین اندازه برای همهٔ controlها نیست.

فاصلهٔ controlهای نزدیک، امکان اشتباه در انتخاب را تغییر می‌دهد. نماد حذف کنار ویرایش باید target و فاصلهٔ روشن داشته باشد. بزرگ کردن glyph بدون افزایش سطح control ممکن است مشکل کلیک را حل نکند. در فایل طراحی، bounding box آیکون و bounding box دکمه را جدا نام‌گذاری کنید. این تفکیک هنگام handoff کمک می‌کند توسعه‌دهنده اندازهٔ شکل را با محدودهٔ تعامل اشتباه نگیرد. مقالهٔ Figma Dev Mode و تحویل به کد برای همین ارتباط مفید است.

برچسب و نام دسترس‌پذیر را نگه دارید

اگر آیکون فقط کنار متن همان عمل است، معمولاً لازم نیست دوباره همان معنی را به ابزار خواندن صفحه اعلام کند. اگر control تنها آیکون دارد، باید نام قابل فهم برای آن تعریف شود. Tooltip هم به تنهایی جای نام و دسترسی مناسب را نمی‌گیرد؛ رفتار hover در touch و keyboard یکسان نیست. تصمیم دربارهٔ نمایش متن باید از نیاز کاربر و وضوح عمل بیاید، نه فقط از محدودیت ظاهری toolbar. حذف متن از عمل ناشناخته می‌تواند هزینهٔ یادگیری را بالا ببرد.

نام باید عمل را بگوید، نه شکل را. «دانلود فایل» از «فلش پایین» کاربردی‌تر است. در حالت‌های مختلف هم نام و وضعیت باید هماهنگ باشند؛ دکمهٔ توقف نباید بعد از تغییر رفتار همچنان شروع نامیده شود. نوشتهٔ دسترس‌پذیری از روز اول این مرز HTML و معنا را ادامه می‌دهد. خود فایل آیکون نمی‌تواند رفتار button، focus و وضعیت disabled را برای مصرف‌کننده تعیین کند.

کنتراست به نقش گرافیکی وابسته است

آیکون لازم برای فهم یا استفادهٔ control باید از زمینه قابل تشخیص باشد. معیار Non-text Contrast برای بخش‌های گرافیکی و controlهای مربوط، نسبت و استثناهای مشخص دارد. توضیح Non-text Contrast شرایط را شرح می‌دهد. این معیار را نباید به تمام تزئین‌های بی‌معنا یا به جای معیار کنتراست متن استفاده کرد. نقش عنصر تعیین می‌کند کدام اطلاعات لازم است دیده شود.

در حالت hover، selected و disabled، فقط تغییر ظریف رنگ ممکن است کافی نباشد. اگر انتخاب برای انجام کار مهم است، نشانهٔ وضعیت و قرارداد control باید روشن باشد. روی زمینهٔ تیره هم نسخهٔ آیکون را با رنگ و وزن مناسب تعریف کنید. مقالهٔ Color Contrast برای بررسی زمینهٔ رنگ مفید است. نام یک رنگ در palette، بدون دیدن ترکیب واقعی، شاهد خوانایی نیست.

جهت را از معنی نماد انتخاب کنید

فلش ادامهٔ ناوبری ممکن است در RTL نیاز به تغییر جهت داشته باشد. لوگو، نماد یک شیء واقعی یا علامت عددی را نباید خودکار آینه کرد. اگر مجموعه دو نسخهٔ جهت دارد، قرارداد استفاده را ثبت کنید. نوشتهٔ Logical Properties و RTL نشان می‌دهد جهت layout همهٔ شکل‌ها را خودکار اصلاح نمی‌کند. در طراحی آیکون هم تصمیم دربارهٔ mirroring از معنی شروع می‌شود، نه از یک دستور عمومی flip.

تحویل مجموعه باید قرارداد داشته باشد

نام‌ها را بر اساس مفهوم و حالت بنویسید و اندازهٔ هدف، style و روش تغییر رنگ را مشخص کنید. برای SVG، ساختار خروجی و محدودهٔ viewBox باید مناسب مصرف باشد؛ وکتور بودن به تنهایی ظاهر همهٔ اندازه‌ها را درست نمی‌کند. مقالهٔ سیستم آیکون یکپارچه نگهداری مجموعه را ادامه می‌دهد. آیکون خوب در زمینهٔ واقعی به فهم و عمل کمک می‌کند؛ باقی ماندن برچسب برای بعضی نقش‌ها، نشانهٔ شکست طراحی نیست.

واکنش به این مقاله

اشتراک‌گذاری این مقاله:
دیدگاه‌ها 0
۰ / ۲۰۰۰

هنوز دیدگاهی ثبت نشده

اولین نفری باشید که نظر می‌دهد!