فیلتر محصول در فروشگاه اینترنتی زمانی مفید است که خریدار بتواند از میان کالاهای واقعاً قابل‌مقایسه، گزینه‌های مناسب نیاز خود را پیدا کند و بداند چرا بعضی کالاها نمایش داده نمی‌شوند. افزودن چند چک‌باکس کنار فهرست، به‌تنهایی این مسئله را حل نمی‌کند. فیلتر خوب به دادهٔ منظم کالا، قواعد روشن ترکیب گزینه‌ها، بازخورد سریع، طراحی موبایل و تصمیم آگاهانه دربارهٔ URLهای قابل خزش نیاز دارد. این راهنما برای صاحب فروشگاه و تیم طراحی است که می‌خواهند پیش از ساخت یا بازطراحی، رفتار فیلتر را تعریف و با سناریوهای واقعی تحویل بگیرند.
فیلتر قرار است کدام تصمیم خرید را آسان کند؟
پیش از انتخاب کنترل‌های رابط، از خریدار بپرسید در هر دسته چه چیزی را اول حذف می‌کند. در لوازم روشنایی ممکن است نوع نصب، ابعاد و رنگ نور مهم باشد؛ در قطعات صنعتی، سازگاری با مدل دستگاه و موجودی؛ در پوشاک، سایز قابل سفارش. «برند» یا «محدودهٔ قیمت» چون در بسیاری از فروشگاه‌ها دیده می‌شود، لزوماً نخستین فیلتر مناسب شما نیست.
یک دستهٔ واقعی را انتخاب کنید و پنج پرسش پرتکرار مشتری را از مکالمات فروش، پشتیبانی و جست‌وجوی داخلی استخراج کنید. برای هر پرسش بنویسید کدام ویژگی کالا پاسخ آن است و آیا دادهٔ قابل‌اعتماد برای همهٔ کالاهای آن دسته وجود دارد. اگر ویژگی روی نیمی از کالاها خالی باشد، نمایش فیلتر ممکن است محصول مناسب را پنهان کند. طراحی صفحهٔ دسته‌بندی فروشگاه دربارهٔ ساختار خود فهرست و مسیر مرور است؛ این مقاله بر رفتار محدودکردن آن فهرست تمرکز دارد.
اول مدل داده را درست کنید، بعد رابط را بسازید
فیلتر فقط به اندازهٔ دادهٔ پشت آن دقیق است. نام‌گذاری یکدست ویژگی‌ها، واحدهای اندازه‌گیری و مقدارهای مجاز باید پیش از طراحی UI تعیین شود. اگر یک تأمین‌کننده رنگ را «آبی نفتی» و دیگری «سرمه‌ای» وارد کند، لازم است تصمیم بگیرید این دو در تجربهٔ خرید یکی هستند یا نه؛ ادغام خودکار بدون قواعد محصول می‌تواند گمراه‌کننده باشد.
برای هر دسته، یک واژه‌نامهٔ ویژگی بسازید: نام ویژگی، نوع مقدار، واحد، امکان چندمقداری، مقدار نامعلوم و مسئول اصلاح. ویژگی‌های عمومی مانند قیمت و موجودی را از ویژگی‌های اختصاصی دسته جدا کنید. فیلتر «قطر لوله» در دستهٔ پوشاک معنا ندارد. در یک فروشگاه چندتأمین‌کننده‌ای، قواعد اعتبارسنجی ورود داده نیز لازم است تا فیلتر با هر بار ورود محصول جدید خراب نشود.
تفاوت محصول و تنوع کالا
اگر یک محصول چند سایز یا رنگ دارد، باید روشن باشد فیلتر به کدام سطح اعمال می‌شود. خریدارِ سایز مشخص نباید کارت محصولی را ببیند که فقط سایزهای دیگر آن موجود است، مگر رابط این وضعیت را شفاف توضیح دهد. برعکس، تکرار همهٔ تنوع‌ها به‌صورت کارت مستقل ممکن است فهرست را شلوغ کند. تصمیم را با مدل موجودی و URL صفحهٔ محصول هماهنگ کنید. راهنمای صفحهٔ محصول فروشگاه به اطلاعاتی می‌پردازد که پس از انتخاب کالا باید نمایش داده شود؛ اینجا مسئلهٔ اصلی پیدا کردن کالای قابل سفارش است.
منطق ترکیب فیلترها را صریح بنویسید
کاربر معمولاً انتظار دارد انتخاب چند مقدار در یک گروه، گزینه‌ها را گسترش دهد؛ مثلاً «مشکی یا سرمه‌ای». انتخاب از دو گروه متفاوت معمولاً نتیجه را محدودتر می‌کند؛ مثلاً «مشکی یا سرمه‌ای» و «سایز متوسط». اما این قرارداد را نباید حدس زد. با مثال محصول واقعی، رفتار OR درون گروه و AND میان گروه‌ها را در مشخصات بنویسید و در تست پذیرش نشان دهید.
برای بازهٔ قیمت و اندازه، حداقل و حداکثر باید از مقدار قابل سفارش و واحد یکسان محاسبه شود. قیمتِ محصول چندتنوعی ممکن است بازه داشته باشد. اگر خریدار «تا سقف معین» می‌زند، مشخص کنید وجود یک تنوع در آن محدوده کافی است یا تمام تنوع‌ها باید مطابق باشند. شمارندهٔ کنار گزینه‌ها هم باید با وضعیت فیلترهای فعال سازگار باشد؛ شمارنده‌ای که بعد از انتخاب به‌روز نمی‌شود، اعتماد را کم می‌کند.
حالت بدون نتیجه یک بن‌بست نباشد
وقتی ترکیب انتخاب‌ها هیچ کالایی برنمی‌گرداند، صفحه نباید فقط «موردی یافت نشد» بگوید. فیلترهای فعال را نشان دهید، حذف یک گزینه و پاک‌کردن همه را آسان کنید و اگر داده اجازه می‌دهد نزدیک‌ترین جایگزین را با توضیح روشن پیشنهاد دهید. پیشنهاد جایگزین نباید کالای ناموجود را به‌جای کالای قابل سفارش جا بزند. این حالت را در محیط آزمایشی عمداً ایجاد کنید؛ اگر قابل تکرار نیست، در شرایط واقعی هم به‌سختی قابل پشتیبانی خواهد بود.
مرتب‌سازی را با فیلتر مخلوط نکنید
فیلتر مجموعهٔ کالاها را تغییر می‌دهد؛ مرتب‌سازی ترتیب همان مجموعه را. «ارزان‌ترین» بدون روشن‌بودن وضعیت موجودی، قیمت تنوع یا هزینهٔ ارسال ممکن است معنای متفاوتی برای خریدار داشته باشد. بعد از تغییر مرتب‌سازی، انتخاب‌های فیلتر باید حفظ شوند. اگر ترتیب پیش‌فرض بر اساس محبوبیت یا پیشنهاد تجاری است، عنوان آن را صادقانه نشان دهید و معیار داخلی را با ادعای بی‌پشتوانهٔ «بهترین» جایگزین نکنید.
تجربهٔ موبایل: فیلتر در دسترس، نتیجه قابل دیدن
در نمایش کوچک، پنل دائمی کنار محصولات جا نمی‌شود. دکمهٔ فیلتر باید نزدیک ابتدای فهرست، واضح و با تعداد انتخاب‌های فعال قابل تشخیص باشد. پس از بازکردن پنل، کاربر باید بداند چگونه گزینه‌ها را اعمال یا لغو کند و چه تعداد نتیجه باقی می‌ماند. اگر اعمال فیلتر زمان‌بر است، حالت بارگذاری را نشان دهید و مانع چند درخواست هم‌زمانِ گیج‌کننده شوید.
بازگشت از صفحهٔ محصول باید تا جای ممکن وضعیت فیلتر و جایگاه فهرست را نگه دارد؛ وگرنه خریدار مجبور می‌شود مسیر انتخاب را از اول تکرار کند. در موبایل، جای دکمهٔ اعمال و پاک‌کردن همه را طوری بگذارید که صفحه‌کلید یا نوار ثابت آن‌ها را نپوشاند. پنل فیلتر باید با صفحه‌کلید نیز قابل پیمایش باشد و برچسب هر گزینه برای ابزارهای کمکی خوانده شود. الگوی چک‌باکس W3C دربارهٔ برچسب، وضعیت انتخاب و تعامل کلید فاصله توضیح می‌دهد؛ در پیاده‌سازی معمول، کنترل بومی HTML اغلب نقطهٔ شروع ساده‌تری است.
آدرس فیلترها و سئو: تصمیمی جدا از رابط کاربر
URLهای فیلترشده می‌توانند ترکیب‌های بسیار زیادی تولید کنند. اگر برای هر رنگ، اندازه، برند و ترتیب یک URL قابل خزش بسازید، ربات‌ها ممکن است منابع زیادی را صرف صفحه‌های کم‌ارزش یا تقریباً تکراری کنند. راهنمای رسمی گوگل برای مدیریت خزش URLهای فیلترشده همین خطر را توضیح می‌دهد. این به معنی «همهٔ فیلترها را همیشه noindex کنید» نیست؛ ابتدا معلوم کنید کدام ترکیب واقعاً پاسخ یک نیاز جست‌وجوی مستقل است.
برای بیشتر انتخاب‌های موقت کاربر، صفحهٔ اصلی دسته و صفحه‌های محصول مسیرهای اصلی کشف‌اند. اگر ترکیبی مثل «چراغ مطالعهٔ شارژی» تقاضای مستقل، موجودی پایدار و محتوای مفید اختصاصی دارد، می‌توان برای آن صفحهٔ فرود مشخص با URL پایدار، متن و لینک داخلی مناسب ساخت؛ نه اینکه هر پارامتر تصادفی را صفحهٔ سئویی بنامید. تصمیم دربارهٔ canonical، محدودیت خزش یا ایجاد صفحهٔ فرود باید با رفتار واقعی CMS و دادهٔ Search Console سنجیده شود. robots.txt برای جلوگیری از خزش است، نه روشی برای تضمین حذف URL از نتایج؛ canonical نیز سیگنال ترجیح است، نه دستور قطعی.
پارامترها را مرتب و پایدار نگه دارید تا یک انتخاب واحد چند شکل URL نسازد. فیلترهای نامعتبر یا نتیجهٔ بی‌معنا را به انبوه صفحهٔ قابل ایندکس تبدیل نکنید. در sitemap فقط URLهایی را بگذارید که واقعاً می‌خواهید به‌عنوان صفحهٔ مستقل کشف شوند. معیار اصلی این است که صفحهٔ فرود پیشنهادی چه ارزشی فراتر از فهرست مادر دارد.
نمونهٔ عملی: فروشگاه لوازم روشنایی
فرض کنید دستهٔ «چراغ مطالعه» ۱۲۰ کالا دارد و تماس‌های فروش نشان می‌دهد مشتریان بیشتر دربارهٔ نوع نصب، منبع تغذیه و رنگ نور می‌پرسند. تیم ابتدا این سه ویژگی را برای کالاهای موجود پاک‌سازی می‌کند. سپس مشخص می‌کند «گیره‌ای یا رومیزی» درون یک گروه، «شارژی» در گروه دوم و «نور گرم» در گروه سوم چگونه ترکیب می‌شوند. قیمت و موجودی از تنوع قابل سفارش خوانده می‌شود، نه از یک متن توضیحی روی محصول.
در تست پذیرش، یک کاربر موبایل فیلتر «گیره‌ای»، «شارژی» و «موجود» را فعال می‌کند، یک محصول را باز می‌کند و برمی‌گردد. باید انتخاب‌ها و جایگاه فهرست حفظ شده باشند. اگر نتیجه صفر شد، حذف یکی از انتخاب‌ها در یک اقدام ممکن باشد. یک کاربر با صفحه‌کلید نیز باید به همان نتیجه برسد. در پشت صحنه، تیم بررسی می‌کند URL این ترکیب صرفاً حالت مرور است یا صفحهٔ فرود مستقلی با نیاز جست‌وجوی واقعی دارد. این تصمیم را از رفتار رابط جدا ثبت می‌کند.
اگر کاربر به‌جای مرور دسته، نام دقیق کالا یا کد فنی را می‌داند، احتمالاً جست‌وجوی داخلی فروشگاه مسیر بهتری است. فیلتر و جست‌وجو باید مکمل باشند: جست‌وجو مجموعهٔ اولیه را می‌سازد و فیلتر آن را محدود می‌کند، بدون اینکه وضعیت انتخاب‌ها ناگهان گم شود.
چه چیزهایی را در تحویل پروژه اندازه بگیریم؟
تنها شمار کلیک روی فیلتر کافی نیست. برای هر دسته، درصد جست‌وجو یا مرورِ بدون نتیجه، فیلترهای پرکاربرد، دفعات پاک‌کردن همه، بازگشت از صفحهٔ محصول و سهم کالاهای دارای ویژگی کامل را بررسی کنید. این‌ها نشانهٔ مسئله‌اند، نه اثبات مستقیم افزایش فروش. اگر فیلتر محبوبی بارها صفر نتیجه می‌دهد، ممکن است دادهٔ کالا ناقص باشد، گزینهٔ پیشنهادی نامناسب باشد یا واقعاً موجودی کافی نباشد.
در قرارداد یا معیار پذیرش، سناریوهای دادهٔ ناقص، چندتنوعی، ناموجود، تغییر قیمت، ترکیب چند فیلتر و بازگشت موبایل را بنویسید. یک مرور بصری از دسکتاپ کافی نیست. تست کنید که تغییر فیلتر چه اثری بر URL، دکمهٔ بازگشت مرورگر و لینک قابل اشتراک دارد. اگر فیلترها با جاوااسکریپت کار می‌کنند، خطای شبکه و بارگذاری کند نیز باید پیام قابل فهم داشته باشد.
جمع‌بندی و اقدام بعدی
فیلتر محصول، ابزار تصمیم‌گیری خریدار است؛ کیفیت آن از دادهٔ منظم، منطق قابل پیش‌بینی، دسترس‌پذیری و سیاست روشن URL می‌آید. از یک دستهٔ مهم شروع کنید، سه تا پنج پرسش واقعی مشتری را به ویژگی‌های قابل‌اتکا تبدیل کنید، ترکیب گزینه‌ها و حالت صفر نتیجه را آزمایش کنید، سپس تصمیم بگیرید کدام URLها ارزش صفحهٔ مستقل دارند. اگر مشتری پس از محدودکردن فهرست هنوز بین چند کالا مردد است، راهنمای جدول مقایسهٔ محصولات مرحلهٔ بعدی تجربهٔ انتخاب را پوشش می‌دهد.
برای طراحی یا بازطراحی این مسیر در فروشگاه خود، خدمت طراحی وب ایزی‌ساز را ببینید و یک دستهٔ نمونه، دادهٔ ویژگی‌ها و پرسش‌های پرتکرار خریداران را برای بررسی اولیه آماده کنید. برآورد فنی بر اساس همین داده و رفتار مطلوب، دقیق‌تر از درخواست کلی «فیلتر پیشرفته» خواهد بود.