طراحی سیستم آیکون: ساخت آیکونوگرافی‌ای که از ۵۰ نماد جلوتر هم دوام بیاورد
راهنمای یک طراح شاغل برای سیستمهای آیکون. گرید، ضخامت خط، اصلاح بصری، نامگذاری، حاکمیت و قوانینی که نمی‌گذارند کتابخانه آیکون بعد از دست‌خوردن سومین طراح بپوسد.
اغلب کتابخانه‌های آیکون محصولات می‌پوسند. طراح اول مجموعه‌ای تمیز از چهل نماد تحویل می‌دهد. طراح دوم سه آیکون دیگر لازم دارد و آن‌ها را با دست و با ضخامت خط اشتباه ترسیم میکند. طراح سوم برای تحویل یک فیچر در روز جمعه از یک پک رایگان دانلود میکند. تا سال دوم محصول، ستون آیکونها در هر صفحه شبیه چهار برند مختلف است که در یک ناوبری دوخته شده‌اند.
این مقاله نسخه عملی ماجراست. گرید، ضخامت خط، اصلاح بصری، نامگذاری، حاکمیت و مجموعه کوچکی از قوانین که یک سیستم آیکون را تا بیش از ۵۰ نماد منسجم نگه می‌دارند. نه ویترین «آیکون هفته»، نه قالب‌هایی که ادای سیستم را درمی‌آورند؛ فقط تصمیم‌هایی که کتابخانه واقعی را در یک تیم واقعی زنده نگه می‌دارند.
سیستم آیکون واقعاً چیست
سیستم آیکون مجموعه‌ای منسجم از پیکتوگراف‌هاست که با قوانین مشترک اداره می‌شود. اندازه گرید، ضخامت خط، شعاع گوشه، تراز بصری، نامگذاری و فرایند افزودن آیکون جدید. هدف یک پوشه پر از SVG نیست. هدف سیستمی است که هر طراح یا مهندسی بتواند بدون برهم زدن ریتم بصری محصول آن را گسترش دهد.
یک انبوه آیکون سیستم نیست. یک فایل Figma با ۲۰۰ نماد و بدون قانون هم سیستم نیست. سیستم محدودیت دارد، تصمیم‌های نام‌دار دارد و فرایندی مکتوب برای وقتی که کسی به آیکونی نیاز دارد که هنوز وجود ندارد.
راهنمای سیستمهای طراحی سیستم گسترده‌تری را پوشش می‌دهد که آیکونها درونش زندگی میکنند. این مقاله مشخصاً به لایه آیکونوگرافی می‌پردازد.
چرا آیکونها مهم‌تر از ظاهرشان هستند
آیکونها فشرده‌ترین بخش UI در هر محصول‌اند. یک آیکون ۲۴ در ۲۴ پیکسلی در هر اینچ مربع بیش از هر عنصر دیگر صفحه معنا حمل میکند. سیستم را درست بسازید تا محصول یکپارچه به نظر برسد. غلط بسازید تا هر صفحه به شکلی که کاربر نمی‌تواند توضیح دهد «ناجور» حس شود.
آیکونها به شکل عجیبی هم مقیاس می‌گیرند. انحراف تایپ‌فیس بین دو صفحه به‌راحتی دیده می‌شود. انحراف آیکون سخت‌تر نامگذاری می‌شود اما در حس بلندتر فریاد می‌زند. مغز پیکتوگراف را سریع‌تر از متن پردازش میکند، یعنی ناهماهنگی آیکون را زودتر از ناهماهنگی متن می‌فهمد.
محصولی که آیکونها را بهعنوان سیستمی منسجم تحویل می‌دهد حتی وقتی بقیه کار خشن است صیقلی به نظر می‌رسد. محصولی که آیکونها را بی‌قانون تحویل می‌دهد حتی وقتی بقیه کار تیز است ارزان به نظر می‌رسد.
گرید همان سیستم است
هر کتابخانه آیکون منسجم با یک گرید شروع می‌شود. گرید داربست نامرئی‌ای است که هر آیکون به آن می‌چسبد. بدون آن، آیکونها در اندازه، ضخامت و تعادل بصری منحرف میشوند و راهی برای اجبار انسجام در code review نیست.
گرید پایه
یک اندازه گرید پایه انتخاب کنید و درونش زندگی کنید. دو پیش‌فرضی که در ۲۰۲۶ جواب می‌دهند:
- گرید ۲۴ پیکسلی برای آیکون‌های UI محصول. اندازه استاندارد اغلب رابط‌های مدرن.
- گرید ۲۰ پیکسلی برای رابط‌های داده‌محور فشرده، داشبوردها و ابزارهای ادمین.
گرید فقط اندازه بوم نیست. ناحیه زنده درون بوم هم هست، جایی که آیکون واقعاً می‌نشیند. گرید ۲۴ پیکسلی ناحیه زنده ۲۰ پیکسلی دارد، با ۲ پیکسل حاشیه از هر طرف. این حاشیه به آیکون جا برای نفس کشیدن می‌دهد و مانع می‌شود کنار عناصر مجاور فشرده به نظر برسد.
خطوط راهنما درون گرید
ناحیه زنده خطوط راهنمای داخلی دارد که شکل را کنترل میکنند. ناحیه زنده ۲۰ پیکسلی چهار شکل راهنما می‌گیرد:
| شکل | اندازه | کاربرد |
|---|---|---|
| مربع | ۱۸×۱۸ px | اغلب آیکون‌های مستطیلی (پوشه، سند) |
| دایره | ۲۰×۲۰ px | آیکون‌های گرد (خورشید، اطلاعات، آواتار) |
| مستطیل بلند | ۱۶×۲۰ px | آیکون‌های عمودی (باتری، تلفن) |
| مستطیل پهن | ۲۰×۱۶ px | آیکون‌های افقی (جستوجو، پیام) |
هر خط راهنما در همان اندازه آیکونی با تعادل بصری تولید میکند. دایره‌ای که در ۱۸ پیکسل کشیده شود کوچکتر از مربع ۱۸ پیکسلی دیده می‌شود، چون چشم انسان دایرهها را کوچکتر می‌خواند. خطوط راهنما این ویژگی ادراکی را جبران میکنند.
ضخامت خط بهعنوان توکن
یک ضخامت خط انتخاب کنید و به آن بچسبید. اغلب سیستمهای آیکون محصول در گرید ۲۴ پیکسلی از خط ۱.۵ یا ۲ پیکسلی استفاده میکنند. بر اساس صدای برند انتخاب کنید.
خط ۱.۵ پیکسلی سبک، فنی و مدرن خوانده می‌شود. خط ۲ پیکسلی مطمئن، صمیمی و در دسترس. خط ۳ پیکسلی پررنگ، کودکانه یا چاپی. یکی را انتخاب کنید. بهعنوان توکن مستند کنید. هر آیکونی که ضخامت دیگری دارد رد کنید.
بخش واژه‌نامه توکن‌های طراحی توضیح می‌دهد ضخامت خط چطور در معماری گسترده‌تر توکن‌ها جا می‌گیرد.
اصلاح بصری تفاوت را می‌سازد
تراز ریاضی همان تراز بصری نیست. آیکون‌هایی که کاملاً به گرید می‌چسبند اغلب غلط به نظر می‌رسند، چون چشم انسان پیکسل نمی‌سنجد؛ وزن و تعادل ادراکشده را می‌سنجد.
چرا اصلاح بصری وجود دارد
یک دایره ۲۰ در ۲۰ پیکسلی و یک مربع ۲۰ در ۲۰ پیکسلی هم‌اندازه خوانده نمی‌شوند. مربع جرم بصری بیشتری دارد چون کادرش را کامل پر میکند. دایره در گوشه‌ها فضای خالی دارد که چشم آن را شیء کوچکتر ثبت میکند.
راه‌حل این است که دایره را کمی بزرگتر از کادر بکشید، گاهی ۱ تا ۲ پیکسل. ریاضی میگوید غلط، چشم میگوید درست. همیشه به چشم اعتماد کنید.
اصلاح‌های بصری رایج
پنج اصلاح بیشتر کارهای آیکون را پوشش می‌دهند:
- دایرهها بزرگتر از مربعها دیده میشوند. خطوط راهنمای دایره را ۱ تا ۲ پیکسل بزرگتر کنید.
- مثلثها کوچکتر از مربعها دیده میشوند. خطوط راهنمای مثلث را ۲ تا ۳ پیکسل بزرگتر کنید.
- خطوط مورب نازکتر از افقیها به نظر می‌رسند. ۰.۲۵ تا ۰.۵ پیکسل به وزن خطوط مورب اضافه کنید.
- مرکز آیکون‌های نامتقارن جابه‌جا می‌شود. دکمه‌های پخش، فلش‌ها و شورون‌ها را با چشم مرکز کنید، نه با کادر محیطی.
- گوشه‌های تیز کوچکتر خوانده میشوند. گوشه‌های داخلی را کمی گرد کنید تا با وزن ادراکشده گوشه‌های بیرونی بخواند.
این اصلاح‌ها نظر شخصی نیستند. هر آیکون را هم با نسخه ریاضی‌کامل و هم با نسخه اصلاح‌شده بصری، کنار هم و در اندازه‌های کوچک تست کنید. نسخه اصلاح‌شده همیشه برنده است. همیشه.
تصمیم‌های سبکی که روی هم انباشته میشوند
وقتی گرید و ضخامت‌ها تعیین شد، هر تصمیم سبکی دیگر باید یک‌بار گرفته و همه‌جا اعمال شود. ناهماهنگی در هر کدام از این‌ها یعنی کتابخانه به دست آدم‌های زیادی خورده است.
شعاع گوشه
یک شعاع گوشه بیرونی و یک شعاع گوشه داخلی انتخاب کنید. این دو جفت‌جفت کار میکنند.
شعاع بیرونی ۱ پیکسل و داخلی ۰.۵ پیکسل تیز و مدرن خوانده می‌شود. بیرونی ۲ پیکسل و داخلی ۱ پیکسل صمیمی و گرد. مجموعه‌ای با لبه‌های تیز و بدون شعاع معمارانه و جدی به نظر می‌رسد.
حرکت غلط، مخلوط کردن شعاع‌ها در یک کتابخانه است. حتی یک آیکون با گوشه‌های تیزتر از بقیه شبیه قرض‌گرفته از مجموعه‌ای دیگر است.
سر خط و اتصال‌ها
خط‌ها انتها دارند. سر خط می‌تواند صاف، گرد یا بیرون‌زده باشد. اتصال بین خطوط می‌تواند miter (تیز)، گرد یا bevel (بریده) باشد. از هر کدام یکی انتخاب کنید و در کل سیستم اعمال کنید.
سر خط گرد و اتصال گرد مجموعه‌ای صمیمی و دوست‌داشتنی می‌سازد. سر خط صاف و اتصال miter مجموعه‌ای دقیق و فنی. سر خط‌های مخلوط در یک کتابخانه مجموعه‌ای نیمه‌کاره می‌سازد.
توپر در برابر توخالی
اغلب سیستمهای آیکون مدرن از هر آیکون دو نسخه دارند: نسخه outline برای حالتهای غیرفعال و نسخه توپر برای حالتهای فعال. نسخه outline از خط استفاده میکند. نسخه توپر همان شکل را با داخل پرشده.
این دو نسخه باید از نظر بصری متعادل باشند. نسخه توپر در همان اندازه اغلب سنگین‌تر و مسلط‌تر از outline دیده می‌شود. راه‌حل این است که ردپای نسخه توپر را ۱ تا ۲ پیکسل کوچک کنید تا وزن بصری در همان مقیاس با outline یکی شود.
بخش واژه‌نامه حالت فوکوس توضیح می‌دهد جابه‌جایی outline به توپر چطور در طراحی گسترده‌تر حالتهای تعاملی جا می‌گیرد.
نامگذاری آیکون نیمی از سیستم است
کتابخانه‌ای با ۲۰۰ آیکون خوش‌کشیده که هیچ‌کس پیدایشان نمی‌کند کتابخانه‌ای است که هیچ‌کس استفاده‌اش نمی‌کند. نامگذاری لایه قابلیت کشف است و نامگذاری بد سریع‌تر از ترسیم بد پذیرش را می‌کشد.
الگوهای نامگذاری مقیاس‌پذیر
از نامگذاری شیءمحور استفاده کنید، نه استعاره‌محور. آیکون ذره‌بین search یا magnifier است، هرگز find یا look. شیء ثابت است. استعاره با زمینه عوض می‌شود.
برای آیکون‌های چندکلمه‌ای از kebab-case استفاده کنید: arrow-left، chevron-down، cloud-upload. یکدستی در حروف به مهندسها اجازه می‌دهد کتابخانه را grep کنند، در IDE تکمیل خودکار بگیرند و بدون غلط تایپی تحویل دهند.
پسوند جهتی را فقط در صورت نیاز بیاورید. arrow کافی نیست. arrow-left، arrow-right، arrow-up، arrow-down حداقل مجموعه است. برای شورون‌ها، caretها و هر پیکتوگراف جهت‌دار دیگر هم همین‌طور.
نامگذاری نسخه‌ها
وقتی آیکونی چند نسخه دارد (outline، توپر، دورنگ)، نسخه را بهعنوان پسوند اضافه کنید:
search(outline پیش‌فرض)search-filledsearch-duotone
این الگو به مهندس اجازه می‌دهد search-filled را بدون گشتن در پوشه‌ای جدا داخل یک دکمه بگذارد. نامگذاری قابل‌پیش‌بینی از سازمان‌دهی بی‌نقص سریع‌تر است.
نقشه مترادفها
بزرگ‌ترین شکست نامگذاری، آیکونی است که طراح پیدا نمی‌کند چون کلمه اشتباه را جستوجو کرده. کنار کتابخانه یک نقشه مترادف بسازید. cart با bag و shopping هم تطبیق می‌خورد. home با house و dashboard. delete با trash، remove و bin.
اغلب ابزارهای جست‌وجوی آیکون مدرن (Iconify، Lucide، Phosphor) نقشه مترادف را در UI جست‌وجویشان دارند. همین را در کتابخانه داخلی بسازید، یا بپذیرید که طراحها مدام آیکون تکراری اضافه میکنند چون نسخه موجود را پیدا نکرده‌اند.
حاکمیت سیستم را زنده نگه می‌دارد
تصمیم‌های فنی بالا را هر طراح کاربلدی می‌تواند بازتولید کند. تصمیم‌های حاکمیتی‌اند که سیستمِ زنده را از سیستمی که در سال دوم می‌میرد جدا میکنند.
منبع واحد حقیقت
یک جا انتخاب کنید که آیکونها در آن زندگی میکنند. یا کتابخانه Figma، یا ریپوی کد با SVGها، یا سرویس میزبانی‌شده‌ای مثل Iconify. فقط یکی. کتابخانه همان‌جاست. هر طراح از همان‌جا برمی‌دارد. هر مهندس از همان‌جا برمی‌دارد.
سیستمی با دو منبع حقیقت، صفر منبع حقیقت دارد. کتابخانه Figma و کتابخانه کد تا هفته سوم از هم دور میشوند و از آن پس هر صفحه آیکون‌هایی تحویل می‌دهد که با سیستم نمی‌خوانند.
فرایند مشارکت
فرایند افزودن آیکون جدید را مستند کنید. این فرایند باید شامل این‌ها باشد:
- اول جستوجو کنید. مطمئن شوید آیکون با نام دیگری از قبل وجود ندارد.
- افزودن را توجیه کنید. در یک جمله بنویسید آیکون چه چیزی را نشان می‌دهد و کجا استفاده می‌شود.
- طبق مشخصات بکشید. با گرید، ضخامت خط، شعاع گوشه، سر خط و اتصال‌های کتابخانه موجود هماهنگ باشید.
- بازبینی بصری. طراح دوم آیکون را در اندازه‌های ۱۶، ۲۰ و ۲۴ پیکسل از نظر تعادل بصری بررسی میکند.
- نامگذاری و تحویل. نام از الگوی نامگذاری پیروی میکند. در همان PR هم به Figma و هم به کد برسد.
سیستمی بدون فرایند مشارکت سیستمی است که دورش می‌زنند. اولین باری که طراحی فوری به آیکون نیاز پیدا کند، از یک پک رایگان دانلود میکند و بدون پرسیدن تحویل می‌دهد. از آن لحظه کتابخانه یک فورک دارد.
فرایند منسوخ‌سازی
آیکونها منسوخ میشوند. بازطراحی سبک قدیمی را بازنشسته میکند، فیچری حذف می‌شود، بازسازی برند زبان بصری را عوض میکند. مستند کنید آیکونها چطور از کتابخانه خارج میشوند، نه فقط چطور وارد میشوند.
آیکون‌های منسوخ را در کتابخانه با برچسبی قابل‌مشاهده علامت بزنید. ۹۰ روز در دسترس نگهشان دارید تا صفحه‌های موجود فرصت مهاجرت داشته باشند. بعد حذفشان کنید. کتابخانه‌ای که هرگز آیکون حذف نمی‌کند موزه می‌شود و موزه‌ها نادیده گرفته میشوند.
آیکونها چطور به کد می‌رسند
تحویل بین طراحی و کد جایی است که اغلب سیستمهای آیکون می‌شکنند. کتابخانه Figma بی‌نقص است، کتابخانه کد قبرستانی از SVGهای ناهماهنگ است و مهندسها به هیچ‌کدام اعتماد نمی‌کنند.
SVG همان فرمت است
آیکونها را به‌صورت SVG تحویل دهید. نه PNG، نه فونت آیکون. SVG برداری است، بدون افت کیفیت به هر اندازه‌ای مقیاس می‌گیرد، از ارث‌بری رنگ جاری برای تم‌سازی آسان پشتیبانی میکند و آن‌قدر کوچک است که داخل کامپوننت‌ها inline شود.
هر SVG یک viewBox مطابق گرید دارد (۲۴×۲۴ یا ۲۰×۲۰)، برای stroke و fill از currentColor استفاده میکند و transform یا استایل زائد ندارد. یک SVG تمیز زیر ۱ KB است. اغلب کتابخانه‌های آیکون آیکون‌هایی ۳ تا ۵ KB تحویل می‌دهند چون با تنظیمات پیش‌فرض اکسپورت شده‌اند، که متادیتا، transform و استایل inlineای را جاسازی میکند که هیچ‌کس لازمشان ندارد.
بهینه‌سازی غیرقابل مذاکره است
هر SVG را پیش از ورود به ریپوی کد از SVGO رد کنید. SVGO متادیتا را پاک میکند، مسیرها را ساده میکند، ویژگیهای زائد را حذف میکند و به‌طور متوسط حجم فایل را ۶۰ تا ۸۰ درصد کم میکند.
برای کتابخانه‌ای با ۲۰۰ آیکون، تفاوت بین بهینه‌نشده و بهینه‌شده معمولاً ۴۰۰ KB در هر بارگذاری صفحه است. این یعنی ضربه به Lighthouse، پسرفت core web vitals و تجربه موبایل کندتر بی‌دلیل.
پوشش‌های کامپوننتی
هر SVG را در یک کامپوننت تایپ‌دار (React، Vue، Svelte) بپیچید. کامپوننت اندازه، رنگ و props دسترس‌پذیری می‌گیرد. مهندس هرگز SVG خام ایمپورت نمی‌کند. او <Icon name="search" size={20} /> را ایمپورت میکند و سیستم بقیه را انجام می‌دهد.
این الگو یعنی کتابخانه آیکون می‌تواند فرمت خروجی زیرین خود را (SVG، اسپرایت، فونت آیکون) بدون دست زدن به کد مصرف‌کننده عوض کند. کامپوننت همان API است و SVG پیاده‌سازی.
بخش واژه‌نامه هندآف طراحی انضباط گسترده‌تر تحویل را پوشش می‌دهد. آیکونها از معدود مواردی هستند که طراح و مهندس واقعاً مالکیت مشترک دارند.
شکست‌های رایج سیستم آیکون
هر ممیزی آیکون همان شکست‌ها را پیدا میکند. اگر سیستم با هر کدام از این‌ها تحویل شود، کتابخانه یک بازطراحی تا بازنویسی کامل فاصله دارد.
سه ضخامت خط در یک کتابخانه. تقریباً همیشه یعنی کتابخانه از چند پک رایگان سرهم شده است. راه‌حل، بازکشی اجباری کل مجموعه با یک ضخامت است.
نسخه‌های توپر و outline با مقیاس متفاوت. نسخه توپر بزرگتر از outline دیده می‌شود چون کسی وزن ادراکشده را جبران نکرده. راه‌حل این است که نسخه توپر را ۱ تا ۲ پیکسل کوچک کنید تا هر دو هم‌اندازه خوانده شوند.
شعاع گوشه ناهماهنگ. نصف آیکونها گوشه گرد دارند، نصف تیز. تقریباً همیشه چون دو طراح مختلف بدون قانون مکتوب مشارکت کرده‌اند. راه‌حل تعریف یک شعاع و ریفکتور است.
نامگذاری با استعاره. آیکون‌هایی با نام find، look، discover به‌جای شیئی که نشان می‌دهند. طراحها پیدایشان نمی‌کنند. راه‌حل تغییر نام به قراردادهای شیءمحور است.
نبود فرایند منسوخ‌سازی. کتابخانه ۳۵۰ آیکون دارد که ۸۰ تایش استفاده نمی‌شود یا جایگزین شده. این حجم اضافه جستوجو را کند و طراح‌های جدید را گیج میکند. راه‌حل ممیزی فصلی و چرخه منسوخ‌سازی ۹۰ روزه است.
سیستمهای آیکون در شرایط ۲۰۲۶
سه تغییر نحوه ساخت سیستمهای آیکون را عوض کرده است. سیستم باید از آن‌ها جان سالم به در ببرد.
فونت‌های آیکون متغیر واقعی شده‌اند. فرمت‌های جدید اجازه می‌دهند یک فایل آیکون چند ضخامت، حالت پر و اندازه بصری را حمل کند که نرم درون‌یابی میشوند. مزیت فنی عظیم است؛ ریسک طراحی این است که تیم‌ها چون می‌توانند، هر نسخه را در هر صفحه تحویل می‌دهند. نسخه‌هایی را که تحویل میشوند انتخاب کنید. بقیه را حذف کنید.
ابزارهای AI آیکون را در چند ثانیه تولید میکنند. Midjourney، DALL-E و ChatGPT با یک پرامپت می‌توانند آیکونی قابل‌قبول بسازند. ریسک این است که طراحها آیکون کشیدن را کنار می‌گذارند و شروع به پرامپت دادن میکنند، که انسجام سیستم را می‌کشد چون هر پرامپت سبکی کمی متفاوت می‌دهد. از AI برای پیش‌نویس اول استفاده کنید. هر خروجی را ریفکتور کنید تا با سیستم بخواند.
Lucide، Phosphor و Heroicons خط پایه را تعیین میکنند. این کتابخانه‌های باز بیش از ۱۵۰۰ آیکون با گرید، ضخامت و نامگذاری یکدست عرضه میکنند. برای اغلب محصولات، شروع از یکی از این‌ها و سفارشی‌سازی سریع‌تر و بهتر از ساختن از صفر است. آیکون سفارشی فقط برای مفاهیم خاص محصول کشیده می‌شود که کتابخانه‌های باز پوشش نمیدهند.
بخش واژه‌نامه wcag خط پایه‌های دسترس‌پذیری را پوشش می‌دهد که کنتراست و برچسب‌گذاری آیکون را کنترل میکنند. آیکون‌های درون عناصر تعاملی به نام‌های دسترس‌پذیر نیاز دارند، نه فقط برچسب بصری.
سوالات متداول
سیستم آیکون باید از چه اندازه گریدی استفاده کند؟
گرید ۲۴ پیکسلی برای UI عمومی محصول، گرید ۲۰ پیکسلی برای رابط‌های داده‌محور فشرده. گرید از هر طرف ۲ پیکسل حاشیه دارد و ناحیه زنده ۲۰ یا ۱۶ پیکسلی‌ای باقی می‌گذارد که آیکون واقعاً در آن می‌نشیند. یکی را انتخاب کنید و در کل کتابخانه درونش زندگی کنید.
خط آیکونها چقدر ضخیم باشد؟
۱.۵ تا ۲ پیکسل در گرید ۲۴ پیکسلی. ۱.۵ پیکسل سبک و فنی خوانده می‌شود، ۲ پیکسل مطمئن و صمیمی. یک ضخامت انتخاب کنید، بهعنوان توکن مستند کنید و هر مشارکتی با ضخامت دیگر را رد کنید.
اصلاح بصری در طراحی آیکون چیست؟
تمرین تنظیم آیکونها تا حتی وقتی ریاضی میگوید تراز هستند متعادل به نظر برسند. دایرهها بزرگتر از مربعها دیده میشوند، مثلثها کوچکتر، موربها نازکتر از افقیها. اصلاح بصری این ویژگیهای ادراکی را جبران میکند. همیشه به چشم بیش از کادر محیطی اعتماد کنید.
آیکونها باید توپر باشند یا توخالی؟
اغلب سیستمهای مدرن هر دو را عرضه میکنند. outline برای حالتهای غیرفعال، توپر برای حالتهای فعال. این دو نسخه باید از نظر بصری متعادل باشند، که معمولاً یعنی نسخه توپر ۱ تا ۲ پیکسل از outline کوچکتر است تا وزن ادراکشده یکی شود.
آیکونها در یک سیستم طراحی چطور نامگذاری شوند؟
شیءمحور، kebab-case، و در صورت نیاز با پسوند جهتی. Search، نه find. Arrow-left، نه back. از نقشه مترادفها استفاده کنید تا طراحها بتوانند با کلمات جایگزین جستوجو کنند. پسوند نسخه (filled، duotone) اضافه کنید تا مهندسها با یک ایمپورت نسخه درست را بردارند.
چه وقت آیکون سفارشی بسازیم و چه وقت از کتابخانه باز استفاده کنیم؟
از یک کتابخانه باز (Lucide، Phosphor، Heroicons) بهعنوان پایه استفاده کنید. فقط مفاهیم خاص محصول را که آن کتابخانهها پوشش نمیدهند سفارشی بکشید. ساختن مجموعه ۳۰۰ آیکونی از صفر در ۲۰۲۶ تقریباً همیشه تلاش هدررفته است. پایه باز را سفارشی کنید، اضافهها را مستند کنید و تحویل دهید.
سیستم هزینه‌اش را پس می‌دهد
کتابخانه آیکون منسجم ارزان‌ترین راه برای صیقلی نشان دادن یک محصول است. کتابخانه آیکون در حال انحراف سریع‌ترین راه برای ارزان نشان دادنش. هزینه ساختن سیستم یک تا دو هفته کار منضبط است. هزینه نساختنش یک مالیات بصری دائمی روی هر صفحه‌ای است که محصول تحویل می‌دهد، تا ابد.
یک گرید انتخاب کنید. یک ضخامت انتخاب کنید. یک شعاع گوشه انتخاب کنید. یک الگوی نامگذاری انتخاب کنید. فرایند مشارکت و منسوخ‌سازی را بنویسید. SVGها را بهینه کنید. در کامپوننت تایپ‌دار بپیچیدشان. بعد همه این‌ها را در code review اجرا کنید.
ستون آیکون در هر صفحه یکی از پرتراکم‌ترین نشانه‌های کیفیت محصول است. یک‌بار درستش کنید تا بقیه طراحی را بر دوش بکشد.
اگر تیمی می‌خواهید که سیستم آیکون را بهعنوان بخشی از تحویل گسترده‌تر سیستم طراحی بسازد، Brainy را استخدام کنید. گرید، حاکمیت و کد در یک پروژه، نه چیزی که آخر کار بچسبانند.
مطالعه مرتبط
Want an icon library that holds up across 200 screens and four designers? Brainy ships icon systems built into the design system, with grid, governance, and code in one handoff.
Get Started
