خریدار رنگ آبی و اندازه متوسط را انتخاب می‌کند. تعداد نتیجه کم می‌شود، اما معلوم نیست کالاها هر دو ویژگی را دارند یا یکی از آن‌ها را. سپس روی یک محصول می‌رود و بعد از بازگشت، تمام انتخاب‌ها پاک شده‌اند. فیلتر کاربردی باید منطق محدود کردن مجموعه و وضعیت فعال را روشن نگه دارد. نمایش چند checkbox در کنار محصولات، بدون این قرارداد، فقط ظاهر ابزار انتخاب را ایجاد می‌کند.
فیلتر برای مقایسه ویژگی‌های شناخته‌شده مناسب است. مخاطب ممکن است مدل مشخصی نداند ولی بودجه، اندازه یا کاربرد مورد نظرش را بشناسد. ویژگی‌ها باید به همان دسته مربوط باشند و داده قابل اعتماد داشته باشند. فیلتر ظرفیت برای حافظه کاربرد دارد؛ افزودن همان گزینه به همه دسته‌ها کمکی نمی‌کند. طراحی از شناخت کالا و زبان مخاطب شروع می‌شود، نه از شمار گزینه‌های قالب فروشگاه.
داده را پیش از کنترل مرتب کنید
اگر اندازه یک محصول با عبارت «M» و دیگری با «متوسط» ذخیره شده، ابتدا باید رابطه آن‌ها روشن شود. رابط نمی‌تواند داده ناسازگار را با طراحی ظاهری اصلاح کند. مقدارهای استاندارد، واحد اندازه‌گیری و روش برخورد با داده ناموجود را تعیین کنید. خالی بودن ویژگی با «ندارد» یکسان نیست. محصولی که اطلاعاتش کامل نشده نباید بی‌دلیل در نتیجه‌ای ظاهر شود که ادعای ویژگی قطعی دارد.
نام فیلتر را با واژه‌ای بنویسید که مخاطب برای انتخاب استفاده می‌کند. اصطلاح فنی می‌تواند توضیح کوتاه داشته باشد، ولی عنوان پیچیده بدون راهنما انتخاب را دشوار می‌کند. اگر ویژگی فقط برای کارشناسان معنی دارد، آن را در گروه تکمیلی قرار دهید. برای مقدارهای عددی، واحد را در عنوان یا کنار کنترل نشان دهید تا فرد قیمت، وزن یا ظرفیت را با مبنای اشتباه مقایسه نکند.
منطق چندانتخابی را صریح کنید
در یک گروه رنگ، انتخاب آبی و سبز معمولاً می‌تواند به معنی هرکدام از این دو باشد. میان گروه رنگ و اندازه، معمولاً هر دو محدودیت همزمان اعمال می‌شوند. این قرارداد باید در سرور و رابط یکسان باشد. اگر محصول چند variant دارد، صرف داشتن رنگ آبی در یک variant و اندازه متوسط در دیگری شاید کافی نباشد؛ مخاطب ترکیب قابل خرید را می‌خواهد، نه دو ویژگی جدا که هیچ گزینه‌ای همزمان آن‌ها را ندارد.
برای بازه قیمت، حدود شامل یا خارج از مرز را مشخص کنید و مقدارهای نامعتبر را قابل اصلاح نگه دارید. دو فیلد عددی می‌توانند از slider دقیق‌تر باشند، به‌ویژه برای ورود مقدار مشخص. اگر slider هم وجود دارد، راه ورودی جایگزین مفید است. قالب عدد فارسی و لاتین، جداکننده و واحد پول باید با قرارداد داده هماهنگ شوند. خطای فرمت نباید انتخاب‌های دیگر را پاک کند.
گروه‌بندی معنایی و بصری
راهنمای Grouping Controls در W3C استفاده از fieldset و legend را برای کنترل‌های مرتبط توضیح می‌دهد. گروه «رنگ» باید در ساختار سند نیز قابل فهم باشد، نه فقط با فاصله بصری. هر checkbox نام روشن و ناحیه انتخاب مناسب داشته باشد. کنترل native اغلب نقطه شروع خوبی است؛ ظاهر سفارشی نباید رفتار صفحه‌کلید و وضعیت انتخاب را از بین ببرد.
گروه‌های طولانی می‌توانند به بخش قابل باز کردن نیاز داشته باشند، اما انتخاب فعال نباید پس از بسته شدن گروه پنهان و فراموش شود. برای فهرست برندهای زیاد، جستجوی داخل همان گروه می‌تواند مفید باشد اگر دامنه آن معلوم است. نتیجه این جستجو با نتیجه محصولات متفاوت است و باید برچسب جدا داشته باشد. محدودیت‌های فعال را نزدیک فهرست محصولات یا در خلاصه‌ای روشن نمایش دهید.
تعداد نتیجه چه چیزی را می‌شمارد؟
عدد کنار یک گزینه می‌تواند تعداد نتیجه در وضعیت جاری یا تعداد کل محصولات آن ویژگی باشد. این دو معنی متفاوت دارند. اگر انتخاب گزینه شمارش را عوض می‌کند، معلوم کنید گزینه‌های دیگر بر چه مبنایی محاسبه شده‌اند. برای گزینه انتخاب‌شده، عدد نباید بدون توضیح با منطق حذف یا افزودن شرط تناقض داشته باشد. شمارش باید با پرسش قابل فهم کاربر سازگار باشد: بعد از انتخاب چه مجموعه‌ای می‌بینم؟
در موجودی و قیمت متغیر، عدد نتیجه ممکن است در لحظه خرید تغییر کند. آن را تضمین دسترسی نهایی معرفی نکنید. اگر شمارش تقریبی است، این محدودیت باید در جای مناسب روشن باشد. گزینه صفر هم همیشه نباید پنهان شود؛ نمایش غیرفعال همراه دلیل می‌تواند وجود یک ویژگی را معلوم کند. انتخاب میان پنهان و غیرفعال به نیاز مقایسه و حجم فهرست مربوط است، نه یک قانون همگانی.
اعمال فوری یا دکمه تأیید
اعمال فوری برای مجموعه‌ای با پاسخ سریع می‌تواند بازخورد خوبی بدهد. در چندانتخابی گسترده یا درخواست پرهزینه، دکمه «نمایش نتایج» اجازه می‌دهد چند محدودیت یکجا انتخاب شوند. Reload بودن یا نبودن به‌تنهایی کیفیت را تعیین نمی‌کند. وضعیت انتظار، حفظ انتخاب‌ها و هماهنگی نتیجه با آخرین ورودی مهم‌ترند. اگر فهرست پیش از تأیید هنوز قدیمی است، این رابطه را واضح نگه دارید.
در درخواست‌های همزمان، پاسخ قبلی نباید جای پاسخ تازه بنشیند. لغو یا تشخیص درخواست معتبر باید در منطق برنامه وجود داشته باشد. هنگام خطا، انتخاب‌های مخاطب را حفظ کنید و مسیر تلاش دوباره بدهید. نتیجه خالی با شکست شبکه فرق دارد. راهنمای Search و فیلتر درباره این وضعیت‌ها و مدیریت درخواست‌های همزمان توضیح بیشتری ارائه می‌کند.
موبایل نیاز به قرارداد باز و بسته شدن دارد
پنل کناری، Bottom Sheet یا صفحه جدا انتخاب‌های ممکن‌اند؛ یکی برای همه فروشگاه‌ها بهتر نیست. اگر پنل modal است، مدیریت focus و خروج نیاز دارد. اگر صفحه جدا است، بازگشت باید انتخاب‌ها را حفظ کند. تعداد فیلتر، طول فهرست و نیاز همزمان به مشاهده محصول بر انتخاب اثر دارند. شکل پنل باید به کار انتخاب کمک کند و کنترل پایان کار از دسترس خارج نشود.
در پنل با دکمه اعمال، بستن بدون تأیید باید رفتار مشخص داشته باشد: انتخاب‌های موقت حفظ می‌شوند یا کنار گذاشته می‌شوند؟ مخاطب نباید این موضوع را بعد از چند بار استفاده کشف کند. تعداد نتیجه پیش‌بینی‌شده روی دکمه می‌تواند کمک کند اگر معتبر است. برای جزئیات modal، راهنمای Dialog قرارداد focus و بستن را توضیح می‌دهد. تغییر ظاهر به sheet این مسئولیت‌ها را حذف نمی‌کند.
حذف و بازنشانی را از هم جدا کنید
هر محدودیت فعال باید راه حذف مشخص داشته باشد. حذف فقط رنگ با پاک کردن همه فیلترها فرق دارد. برچسب کنترل را دقیق بنویسید؛ علامت ضربدر کنار «آبی» باید نامی مانند «حذف فیلتر رنگ آبی» داشته باشد. اگر جستجو هم فعال است، معلوم کنید «پاک کردن همه» عبارت جستجو را نیز حذف می‌کند یا فقط فیلترها را. مرتب‌سازی می‌تواند قرارداد جدا داشته باشد.
حفظ وضعیت در نشانی به بازگشت، اشتراک‌گذاری و باز کردن محصول در تب تازه کمک می‌کند، ولی ورودی‌های خصوصی نباید به query عمومی منتقل شوند. نام پارامترها و مقدارهای مجاز را پایدار نگه دارید. اگر یک گزینه حذف یا تغییر نام داده شده، نشانی قدیمی باید رفتار قابل فهم داشته باشد. بازگشت از محصول بهتر است همان مجموعه، انتخاب و موقعیت قبلی را تا حد مناسب حفظ کند.
حالت خالی مسیر اصلاح می‌خواهد
اگر ترکیب محدودیت‌ها نتیجه ندارد، عبارت و انتخاب‌های فعال را نمایش دهید. پیشنهاد حذف یک شرط می‌تواند مفید باشد، ولی شرط‌ها را بی‌خبر تغییر ندهید. نمایش محصول نامطابق در میان نتایج اصلی باعث می‌شود مخاطب به فیلتر اعتماد نکند. اگر پیشنهاد جایگزین دارید، آن را بخش جدا با توضیح تفاوت قرار دهید؛ کالا با اندازه دیگر نباید به عنوان نتیجه دقیق معرفی شود.
برای مخاطبی که قصد خرید دارد، موجودی و شرایط خرید هم در نتیجه مهم‌اند. فهرست زیبا با محصولات غیرقابل خرید کار را تمام نمی‌کند. راهنمای Checkout ادامه مسیر انتخاب تا پرداخت را توضیح می‌دهد. وعده اینکه فیلتر همیشه در چند ثانیه مخاطب را به محصول می‌رساند قابل دفاع نیست؛ دامنه داده، نیاز انتخاب و کیفیت نتیجه بر زمان اثر دارند.
تحویل و نگهداری
برای هر گروه، نام، نوع کنترل، واحد، منطق ترکیب، رفتار داده خالی و شمارش را ثبت کنید. حالت‌های انتظار، خطا، صفر نتیجه و گزینه حذف‌شده باید در قرارداد وجود داشته باشند. معیار موفقیت را انجام کار و پیدا کردن گزینه مناسب قرار دهید، نه صرفاً تعداد انتخاب فیلتر. گاهی یک دسته‌بندی روشن‌تر نیاز به چند محدودیت را کم می‌کند و این کاهش تعامل می‌تواند نتیجه خوبی باشد.
فیلتر قابل اعتماد از همکاری داده و رابط شکل می‌گیرد. مقدارهای درست بدون توضیح مناسب گیج‌کننده‌اند و رابط روشن با داده ناسازگار نتیجه غلط می‌دهد. انتخاب‌های فعال را قابل مشاهده نگه دارید، منطق نتیجه را ثابت کنید و امکان اصلاح را حفظ کنید. این قرارداد باعث می‌شود مخاطب بتواند مجموعه را آگاهانه محدود کند و پس از رفتن به جزئیات، مسیر انتخاب خود را از دست ندهد.
هنوز دیدگاهی ثبت نشده
اولین نفری باشید که نظر می‌دهد!