ذخیره سبد خرید در فروشگاه اینترنتی یعنی مشتری بتواند انتخاب‌های قبلی خود را در مراجعه بعدی ادامه دهد؛ اما این قابلیت فقط نگهداری چند شناسه کالا نیست. فروشگاه باید مشخص کند سبد به مرورگر تعلق دارد یا حساب کاربری، هنگام ورود چه چیزی ادغام می‌شود و تغییر قیمت یا موجودی چگونه به خریدار اطلاع داده خواهد شد. سبد ذخیره‌شده نباید وعده رزرو کالا، قیمت ثابت یا امکان پرداخت بدون بررسی دوباره بدهد.
اگر مشتری با موبایل کالا انتخاب می‌کند و خرید را با لپ‌تاپ ادامه می‌دهد، طراحی درست باید مسیر ادامه خرید را روشن کند. در مقابل، اگر روی دستگاه مشترک از حساب خارج شود، نباید نفر بعدی بتواند سبد شخصی او را ببیند. این راهنما معیارهای اجرایی و آزمون پذیرش این قابلیت را توضیح می‌دهد؛ هدف، ساخت تجربه‌ای قابل اعتماد است، نه وعده افزایش قطعی فروش.
سبد ذخیره‌شده دقیقاً چه مسئله‌ای را حل می‌کند؟
مشتری ممکن است برای بررسی اندازه، هماهنگی با همکار یا مقایسه چند گزینه خرید را نیمه‌تمام بگذارد. حذف انتخاب‌های او در مراجعه بعدی باعث تکرار کار می‌شود. ذخیره سبد کمک می‌کند همان انتخاب‌ها دوباره قابل بررسی باشند. با این حال، نمایش همان کالاها به معنی معتبر بودن شرایط قبلی خرید نیست؛ فروشگاه باید وضعیت فعلی را کنار انتخاب قبلی نشان دهد.
این موضوع با ثبت سفارش تفاوت دارد. سبد محل تصمیم‌گیری است، اما سفارش باید اطلاعات مشخص و قابل پیگیری از خرید نهایی داشته باشد. همچنین سبد جای فهرست علاقه‌مندی‌ها را نمی‌گیرد: علاقه‌مندی می‌تواند محل نگهداری بلندمدت گزینه‌ها باشد، در حالی که سبد باید برای بررسی تعداد، قیمت و آمادگی پرداخت طراحی شود. اگر این تفاوت روشن نباشد، مشتری ممکن است باقی‌ماندن کالا در سبد را تضمین موجودی تلقی کند.
ابتدا مالکیت سبد را تعیین کنید
سبد مهمان به چه چیزی متصل است؟
برای کاربری که وارد حساب نشده، ادامه خرید معمولاً به همان مرورگر یا شناسه نشست وابسته است. پاک‌شدن داده مرورگر، استفاده از حالت خصوصی یا تعویض دستگاه می‌تواند این پیوند را از بین ببرد. بنابراین نباید برای مهمان وعده بازیابی خودکار روی همه دستگاه‌ها نمایش داده شود، مگر اینکه سازوکار مشخص و امنی برای آن پیاده‌سازی شده باشد.
راهنمای خرید مهمان بدون ثبت‌نام اجباری به انتخاب‌های مربوط به حساب کاربری می‌پردازد. در طراحی سبد ماندگار نیز بهتر است حفظ انتخاب‌ها به بهانه‌ای برای اجبار زودهنگام ثبت‌نام تبدیل نشود. می‌توان محدودیت سبد مهمان را کوتاه و شفاف توضیح داد و امکان اتصال آن به حساب را در نقطه‌ای مناسب ارائه کرد.
سبد حساب کاربری چگونه بازیابی می‌شود؟
در سبد متصل به حساب، سرور باید پس از احراز هویت، سبد مجاز همان کاربر را برگرداند. وجود شناسه سبد در درخواست کافی نیست؛ مالکیت و مجوز دسترسی هم باید بررسی شوند. در طراحی فنی، نگهداری نسخه سبد در مرورگر می‌تواند برای نمایش سریع مفید باشد، اما نباید مرجع نهایی قیمت، موجودی یا مالکیت محسوب شود.
سیاست تعداد سبدهای فعال نیز باید مشخص باشد. آیا هر حساب یک سبد فعال دارد یا برای فروشگاه‌ها و ارزهای متفاوت سبدهای جداگانه ساخته می‌شود؟ این تصمیم باید با مدل واقعی فروشگاه هماهنگ باشد. ادغام کالاهای ناسازگار در یک سبد مشترک، بدون توجه به محدودیت تحویل یا فروشنده، مسئله را به مرحله پرداخت منتقل می‌کند.
ورود به حساب: ادغام، جایگزینی یا انتخاب مشتری؟
فرض کنید مهمان روی موبایل دو کالا انتخاب کرده و حساب او از قبل سبد دیگری دارد. ورود نباید بدون توضیح یکی از این سبدها را حذف کند. سه سیاست قابل بررسی هستند: ادغام انتخاب‌ها، فعال‌کردن سبد جدید با حفظ امکان رسیدگی به سبد قبلی، یا درخواست انتخاب از مشتری در موقعیت‌های دارای تعارض مهم.
در مستندات راهبردهای ادغام سبد commercetools، ادغام با سبد موجود و استفاده از سبد مهمان به‌عنوان سبد فعال جدید، دو راهبرد جداگانه هستند. این نمونه نشان می‌دهد رفتار ورود باید تصمیمی صریح باشد؛ جزئیات یک پلتفرم را نباید قانون عمومی همه فروشگاه‌ها دانست.
برای کالاهای تکراری، صرف برابر بودن عنوان کافی نیست. رنگ، اندازه، فروشنده یا گزینه شخصی‌سازی ممکن است متفاوت باشد. حتی برای یک گونه کاملاً یکسان نیز جمع‌کردن تعدادها همیشه انتخاب مناسبی نیست. تیم محصول باید تعیین کند تعداد بیشتر حفظ شود، تعدادها جمع شوند یا تأیید مشتری لازم باشد. نتیجه ادغام باید در صفحه سبد توضیح داده شود و مشتری بتواند تعداد نهایی را اصلاح کند.
بازگرداندن انتخاب قبلی، همراه با شرایط امروز
هر بار که سبد بازیابی می‌شود، اقلام باید با اطلاعات فعلی فروشگاه تطبیق داده شوند. بررسی دوباره در آستانه ثبت سفارش نیز لازم است، زیرا ممکن است میان بازشدن سبد و پرداخت شرایط تغییر کند. قیمت ارسالی مرورگر نباید بدون اعتبارسنجی مبنای مبلغ سفارش باشد.
تغییرها را به چند حالت قابل فهم تقسیم کنید:
- قیمت عوض شده است: قیمت فعلی و توضیح تغییر را نشان دهید؛ مبلغ قبلی را مبلغ قابل پرداخت معرفی نکنید.
- تعداد درخواستی موجود نیست: تعداد قابل خرید را اعلام کنید و تغییر را پنهانی انجام ندهید.
- کالا یا گونه انتخابی حذف شده است: ردیف را با وضعیت مشخص نگه دارید تا مشتری دلیل نبودن آن را بفهمد.
- کد تخفیف منقضی یا نامعتبر شده است: آن را از محاسبه معتبر کنار بگذارید و علت را توضیح دهید.
- روش ارسال قبلی دیگر قابل استفاده نیست: انتخاب مجدد را پیش از پرداخت درخواست کنید.
این کنترل‌ها باید به اطلاعات قابل فهم محصول متصل باشند. طراحی صفحه محصول فروشگاه اینترنتی مکمل این مسیر است: مشتری باید بتواند ویژگی کالای بازیابی‌شده را باز کند، گونه انتخابی را بررسی کند و با آگاهی تصمیم بگیرد. حذف بی‌توضیح ردیف‌ها ممکن است ظاهر سبد را مرتب کند، اما اعتماد و امکان اصلاح انتخاب را از بین می‌برد.
چند دستگاه و چند تب؛ آخرین ذخیره همیشه درست نیست
اگر لپ‌تاپ نسخه قدیمی سبد را باز نگه داشته باشد و مشتری روی موبایل کالایی را حذف کند، ذخیره دوباره صفحه قدیمی نباید آن کالا را بی‌خبر برگرداند. راهکار فنی باید تغییرات هم‌زمان را تشخیص دهد. برای نمونه، هر سبد می‌تواند نسخه داشته باشد و درخواست تغییر بر اساس همان نسخه پذیرفته یا برای تطبیق دوباره رد شود.
رفتار رابط کاربری به اندازه کنترل سرور مهم است. پیام «سبد شما در دستگاه دیگری تغییر کرده» همراه با تازه‌سازی وضعیت، از بازنویسی خاموش بهتر است. اگر تغییر قابل ادغام نیست، مشتری باید نتیجه را ببیند و تصمیم بگیرد. ارسال دوباره درخواست پس از قطع شبکه نیز نباید تعداد یک کالا را ناخواسته چند بار افزایش دهد.
در تعریف نیازمندی، تفاوت «تعداد را روی سه قرار بده» با «یک عدد اضافه کن» را ثبت کنید. اولی یک مقدار هدف دارد؛ دومی یک عمل افزایشی است که تکرار آن نتیجه متفاوتی ایجاد می‌کند. تیم توسعه باید برای درخواست‌های قابل تکرار، تشخیص اجرای قبلی و بازگشت پاسخ مناسب را طراحی کند؛ صرف نمایش علامت بارگذاری کافی نیست.
خروج از حساب و دستگاه مشترک را جدی بگیرید
در دستگاه مشترک، خروج باید نمایش سبد شخصی و دسترسی به آن را متوقف کند. بازگشت با دکمه مرورگر یا بازماندن تب دیگر نباید اطلاعات حساب قبلی را قابل استفاده نگه دارد. اگر پس از خروج سبد مهمان تازه‌ای ساخته می‌شود، کالاهای حساب قبلی نباید بدون تصمیم روشن به آن منتقل شوند.
مدت نگهداری سبد را نیز متناسب با نیاز کسب‌وکار مشخص کنید. نگهداری همیشگی، تصمیم پیش‌فرض بی‌هزینه‌ای نیست: داده قدیمی زیاد می‌شود و تجربه بازیابی ممکن است پر از کالاهای حذف‌شده باشد. هنگام انقضا می‌توان پیام روشنی نمایش داد، اما نباید وانمود کرد انتخاب‌های قبلی هنوز موجود هستند. سیاست نگهداری باید با توضیحات حریم خصوصی و امکانات واقعی حذف داده هماهنگ باشد.
بازیابی سبد با ارسال پیام تبلیغاتی یکی نیست. داشتن سبد متصل به حساب، به‌خودی‌خود مجوز ارسال هر نوع پیام در هر کانال محسوب نمی‌شود. قابلیت یادآوری باید جداگانه تعریف شود و ترجیحات ارتباطی مشتری را رعایت کند. برای شروع پروژه، می‌توان ذخیره و بازیابی داخل سایت را مستقل از پیام‌رسانی اجرا و ارزیابی کرد.
پس از پرداخت چه اتفاقی برای سبد می‌افتد؟
سفارش موفق باید از سبد در حال خرید جدا شود. پس از قطعی‌شدن نتیجه سفارش، دستگاه دیگر نباید همان اقلام خریداری‌شده را به‌عنوان سبد آماده پرداخت قبلی بازگرداند. با این حال، پاک‌کردن سبد صرفاً هنگام انتقال کاربر به درگاه نیز درست نیست؛ ممکن است پرداخت کامل نشده باشد یا نتیجه هنوز روشن نباشد.
وضعیت پرداخت و ثبت سفارش باید از مسیر معتبر فروشگاه تعیین شود. اگر نتیجه موقتاً نامشخص است، رابط کاربری باید همین ابهام را نشان دهد و کاربر را به بررسی سفارش هدایت کند، نه اینکه او را به پرداخت تکراری سوق دهد. «خرید دوباره» نیز بهتر است یک اقدام روشن باشد که اقلام را با قیمت و موجودی فعلی وارد سبد جدید می‌کند.
مثال عملی: ادامه خرید از موبایل به لپ‌تاپ
این سناریو فرضی است، نه گزارش نتیجه یک پروژه. مشتری با موبایل یک کفش آبی در اندازه مشخص و دو لیوان انتخاب می‌کند. حساب او از قبل یک لیوان مشابه در سبد دارد. هنگام ورود، سیاست فروشگاه برای ردیف تکراری، حفظ تعداد بیشتر است؛ پس دو لیوان باقی می‌ماند و پیام کوتاهی نتیجه ادغام را توضیح می‌دهد.
روز بعد مشتری روی لپ‌تاپ وارد می‌شود. کفش همچنان قابل خرید است، اما فقط یک لیوان موجود است و تخفیف قبلی پایان یافته. صفحه سبد این دو تغییر را نشان می‌دهد و پیش از ادامه، اصلاح تعداد و مبلغ نهایی را قابل مشاهده می‌کند. مشتری لیوان را حذف می‌کند و خرید کفش را انجام می‌دهد. موبایل پس از تازه‌سازی باید وضعیت جدید را دریافت کند، نه سبد قدیمی را دوباره فعال کند.
ارزش این مثال در عدد فروش یا نرخ تبدیل نیست؛ در شفاف‌بودن قرارداد رفتار است. تیم محصول، توسعه و پشتیبانی می‌توانند همین سناریو را اجرا کنند و درباره نتیجه مورد انتظار توافق داشته باشند. اگر هر تیم برداشت متفاوتی دارد، هنوز نیازمندی برای اجرا آماده نیست.
چک‌لیست پذیرش قبل از انتشار قابلیت
برای تحویل پروژه، فقط آزمایش حالت معمول کافی نیست. مجموعه زیر را با حساب‌ها و داده‌های آزمایشی اجرا کنید:
- مهمان پس از بستن و بازکردن همان مرورگر، رفتار وعده‌داده‌شده را دریافت کند.
- ورود روی دستگاه دوم، فقط سبد مجاز همان حساب را بازیابی کند.
- ردیف تکراری با گونه یکسان و متفاوت، مطابق سیاست مستند ادغام شود.
- تغییر هم‌زمان دو دستگاه، حذف یا تعداد جدید را خاموش بازنویسی نکند.
- پایان تخفیف، کاهش موجودی و حذف کالا، پیام واضح داشته باشند.
- قطع و وصل شبکه، باعث اجرای چندباره یک افزایش تعداد نشود.
- خروج از حساب، دسترسی تب‌های قدیمی به سبد شخصی را محدود کند.
- سفارش موفق، با بازیابی نسخه قدیمی به خرید تکراری تبدیل نشود.
در موبایل، پیام تغییر قیمت و دکمه اصلاح تعداد باید بدون پیمایش افقی قابل استفاده باشند. برای دسترسی‌پذیری، وضعیت خطا فقط با رنگ بیان نشود و کنترل‌های تعداد نام قابل فهم داشته باشند. سنجش فنی نیز بهتر است خطاهای بازیابی، تعارض نسخه و موارد اصلاح دستی را ثبت کند، بدون ذخیره بی‌دلیل اطلاعات حساس مشتری در گزارش‌ها.
از یک سیاست روشن شروع کنید
برای نسخه نخست، تصمیم‌های اصلی را محدود و قابل آزمون نگه دارید: مالکیت سبد، مدت نگهداری، قاعده ادغام، اعتبارسنجی شرایط خرید و رفتار پس از خروج یا پرداخت. سپس با مشاهده استفاده واقعی، پیچیدگی‌های لازم را اضافه کنید. وجود سبد ماندگار به‌تنهایی موفقیت تجاری را تضمین نمی‌کند؛ کارکرد درست و توضیح صادقانه محدودیت‌ها شرط اولیه اعتماد است.
در خدمات طراحی سایت ایزی‌ساز، این قابلیت می‌تواند به‌عنوان بخشی مشخص از مسیر خرید تعریف شود. برای بررسی نیاز فروشگاه و محدوده اجرا، سناریوی فعلی، انواع مشتری، محدودیت موجودی و انتظار خود از ادامه خرید میان دستگاه‌ها را آماده کنید تا پیشنهاد اجرایی بر اساس رفتار قابل تحویل نوشته شود، نه صرفاً نام یک قابلیت.