کنار عنوان یک سند، آیکونی شبیه فلش قرار دارد. کاربر نمی‌داند با انتخاب آن فایل دانلود می‌شود، صفحه تازه باز می‌شود یا سند برای دیگری ارسال خواهد شد. شکل از نظر بصری تمیز است، اما معنای عمل مبهم مانده است. طراحی آیکون در رابط وب از همین رابطه میان شکل، محل و رفتار شروع می‌شود. یک مجموعه هماهنگ زمانی به کار می‌آید که کاربر بتواند نتیجه انتخاب هر نشانه را پیش‌بینی کند.
آیکون‌ها زبان جهانی با معنای ثابت نیستند. تجربه قبلی، فرهنگ، زمینه صفحه و حتی شکل نزدیک آن‌ها بر برداشت اثر می‌گذارد. نشانه قلب در یک فروشگاه ممکن است علاقه‌مندی باشد و در یک شبکه اجتماعی واکنش به محتوا. شکل چرخ‌دنده اغلب با تنظیمات همراه است، ولی این آشنایی دلیل کافی برای پنهان کردن عنوان یک بخش مهم نیست. معنای آیکون باید در همان محصول روشن شود.
وظیفه هر نشانه را قبل از ترسیم بنویسید
برای هر آیکون یک جمله عملی بنویسید: «این دکمه فایل گزارش را دانلود می‌کند» یا «این نشانه وضعیت پیش‌نویس را نشان می‌دهد». اگر جمله به چند رفتار متفاوت اشاره دارد، احتمالاً نیاز به تفکیک کنترل دارید. آیکون تزئینی کنار یک عنوان، آیکون نشان‌دهنده وضعیت و آیکون داخل دکمه سه نقش متفاوت دارند. طراحی، نام قابل دسترس و رفتار تعاملی آن‌ها نباید یکسان فرض شود.
فهرست اولیه را با نام رفتار نگه دارید، نه فقط نام شکل. «ذخیره پیش‌نویس» از «دیسک» دقیق‌تر است؛ چون ممکن است بعدها شکل تغییر کند و رفتار ثابت بماند. این فهرست برای همکاری طراح و توسعه‌دهنده هم مفید است. وقتی چند تیم از یک کتابخانه استفاده می‌کنند، باید معلوم باشد هر نشانه به چه عمل مشخصی اشاره دارد و در چه موقعیتی استفاده از آن مجاز است.
اندازه تصویر را از اندازه هدف جدا کنید
گفتن اینکه همه آیکون‌ها باید حداقل ۲۴ پیکسل باشند، دو موضوع را با هم مخلوط می‌کند. اندازه خود نقاشی بر خوانایی اثر دارد؛ اندازه ناحیه قابل انتخاب بر امکان لمس یا کلیک. ممکن است آیکون ۲۰ پیکسلی داخل دکمه‌ای بزرگ‌تر کاملاً قابل استفاده باشد. برعکس، تصویر ۲۴ پیکسلی بدون فاصله از کنترل کناری همچنان انتخاب اشتباه را آسان می‌کند.
معیار Target Size در WCAG 2.2 برای هدف‌های تعاملی حداقل و استثناهایی مانند فاصله مناسب را توضیح می‌دهد. آن را قانون اندازه همه تصاویر تعبیر نکنید. در عمل، فضای لمس را با padding دکمه و فاصله میان کنترل‌ها طراحی کنید. محل focus و hover نیز بهتر است مرز همان ناحیه را روشن کند تا کاربر بداند چه چیزی قابل انتخاب است.
هماهنگی مجموعه را در جزئیات بسازید
دو آیکون ممکن است هر دو outline باشند، اما ضخامت خط، زاویه گوشه و تراکم جزئیاتشان متفاوت باشد. کنار هم قرار دادن آن‌ها حس ناهماهنگی می‌سازد. یک مجموعه کوچک را با قواعد روشن طراحی کنید: شبکه پایه، ضخامت خط، شکل انتها، میزان گردی و فضای خالی دور نقاشی. قواعد باید به تصمیم قابل بررسی تبدیل شوند، نه عبارت مبهمی مانند «همه آیکون‌ها مدرن باشند».
با این حال، یکسان بودن عددی همیشه به وزن بصری یکسان منتهی نمی‌شود. دایره، مثلث و مستطیل در یک قاب هم‌اندازه متفاوت دیده می‌شوند. برخی شکل‌ها به اصلاح نوری نیاز دارند تا کنار هم متعادل شوند. نگاه به مجموعه در اندازه واقعی رابط از بزرگ‌نمایی فایل طراحی مفیدتر است؛ جزئیاتی که در صفحه طراحی زیبا هستند ممکن است در نوار ابزار به لکه‌ای نامفهوم تبدیل شوند.
برچسب متنی را دشمن سادگی ندانید
در اولین استفاده، آیکون همراه متن می‌تواند ابهام را کم کند. برای عملیات حساس مثل حذف حساب، عنوان دقیق حتی در فضای محدود ارزش دارد. استفاده از tooltip به‌تنهایی جای متن قابل مشاهده را نمی‌گیرد؛ کاربر صفحه لمسی ممکن است همان رفتار hover را نداشته باشد. اگر مجبور به کنترل فقط آیکونی هستید، نام قابل دسترس و راه فهم معنا باید مستقل از حرکت نشانگر فراهم شود.
در راهنمای تصاویر کاربردی W3C، توضیح جایگزین تصویر بر وظیفه آن تمرکز دارد. برای دکمه جستجو، نام عمل مهم است، نه شرح «ذره‌بین خاکستری». اگر متن دکمه از قبل وجود دارد، تصویر همراه آن معمولاً نباید همان نام را دوباره برای صفحه‌خوان تکرار کند. تصمیم درباره متن جایگزین را با نقش تصویر و متن اطرافش هماهنگ کنید.
وضعیت‌ها را فقط با تعویض شکل بیان نکنید
قلب خالی و پر می‌تواند وضعیت علاقه‌مندی را نشان دهد، اما رفتار کنترل باید حالت انتخاب‌شده را هم منتقل کند. در دکمه toggle، وضعیت برنامه‌ای مانند aria-pressed به توضیح این رابطه کمک می‌کند. برای نشانه خطا، رنگ قرمز به‌تنهایی کافی نیست؛ متن کوتاه باید معلوم کند چه چیزی خراب شده و چه اقدامی لازم است. وضعیت غیرفعال نیز بهتر است با علت یا توضیح نزدیک همراه باشد.
اگر آیکون بعد از ارسال درخواست تغییر می‌کند، زمان تغییر را مشخص کنید. تغییر فوری ممکن است خوش‌بینانه باشد و در صورت شکست نیاز به بازگشت و پیام داشته باشد. تغییر پس از تأیید سرور می‌تواند به حالت انتظار نیاز پیدا کند. این تصمیم بخشی از طراحی Microinteractions و بازخورد است. آیکون نباید موفقیت را اعلام کند در حالی که عمل هنوز انجام نشده است.
کنتراست و پس‌زمینه را با هم ببینید
آیکون خاکستری کم‌رنگ روی زمینه سفید ممکن است در طرح اولیه ظریف به نظر برسد، ولی تشخیص آن در شرایط نوری مختلف دشوار باشد. برای اجزای رابط و گرافیک‌های ضروری، معیار Non-text Contrast نسبت کنتراست و دامنه کاربرد را شرح می‌دهد. هر جزء تزئینی الزام یکسانی ندارد؛ نشانه‌ای که برای فهم عمل لازم است با تزئین صفحه تفاوت دارد.
رنگ‌ها را در حالت عادی، انتخاب‌شده، غیرفعال و focus کنار هم مشخص کنید. در Dark Mode صرفاً همه رنگ‌ها را معکوس نکنید؛ آیکون روی سطح کارت و آیکون روی زمینه اصلی ممکن است به رنگ‌های متفاوت نیاز داشته باشند. برای اطلاعات معنی‌دار، ترکیب شکل و متن کمک می‌کند معنا هنگام تغییر رنگ یا استفاده از نمایشگر متفاوت باقی بماند. نورپردازی نمایشی یا سایه‌های پیچیده نباید تشخیص مرز شکل را دشوار کنند.
در رابط فارسی، جهت را بر اساس معنا تغییر دهید
همه نشانه‌ها با راست‌به‌چپ شدن صفحه نباید آینه شوند. فلش حرکت در سلسله‌مراتب یا بازگشت ممکن است به جهت متن وابسته باشد؛ لوگو، ساعت یا نشانه‌ای که مفهوم فیزیکی خاصی دارد لزوماً چنین نیست. برای هر مورد مشخص کنید فلش به حرکت رابط اشاره دارد یا به جهت واقعی. تغییر خودکار همه فایل‌ها با یک transform می‌تواند معنا یا شکل آشنا را خراب کند.
هم‌ترازی متن و آیکون نیز نیاز به توجه دارد. عنوان فارسی ممکن است چند خط شود و آیکون بهتر است به خط اول یا مرکز کنترل وابسته باشد، بسته به نقش آن. فاصله را با ویژگی‌های منطقی CSS مانند margin-inline تعریف کنید تا با جهت رابط سازگار بماند. در توضیح سیستم طراحی، جای آیکون پیش و پس از متن را صریح بنویسید؛ «سمت چپ» بدون توجه به زبان ممکن است قرارداد پایداری نباشد.
انتخاب کتابخانه و تحویل فایل
کتابخانه آماده زمانی مناسب است که سبک آن با محصول هماهنگ باشد و شکل‌های ضروری شما را پوشش دهد. پیش از افزودن آن، مجوز، نام‌گذاری و روش دریافت فایل‌ها را از مستندات همان پروژه بخوانید. تعداد زیاد آیکون به‌تنهایی مزیت نیست. اگر فقط چند نشانه استفاده می‌کنید، وارد کردن کل مجموعه می‌تواند هزینه‌ای بی‌دلیل باشد؛ روش دریافت باید با ابزار ساخت و سیاست پروژه سازگار شود.
SVG اغلب برای شکل‌های برداری کاربرد دارد، ولی فایل را پیش از استفاده از نظر محتوای اضافی و منبع آن بررسی کنید. ابعاد و viewBox باید مشخص باشند و رنگ به شکلی تعریف شود که کنترل آن در رابط ممکن باشد. برای آیکون‌های تولیدشده داخل پروژه، نگهداری نسخه اصلی و نام رفتار کمک می‌کند تغییر بعدی قابل پیگیری باشد. افزودن یک آیکون تازه باید همان قواعد مجموعه موجود را رعایت کند.
در مرور نهایی، از کاربر بخواهید نتیجه انتخاب کنترل را توضیح دهد؛ صرف پسندیدن ظاهر نشانه پاسخ کافی نیست. موارد اشتباه را کنار رفتار واقعی ثبت کنید. سپس عنوان، محل یا شکل را متناسب با علت ابهام اصلاح کنید. مجموعه موفق مجموعه‌ای است که در کار روزانه معنی روشنی دارد، در اندازه واقعی خوانا می‌ماند و وضعیت‌های عمل را قابل اعتماد نشان می‌دهد.
هنوز دیدگاهی ثبت نشده
اولین نفری باشید که نظر می‌دهد!