اشتباهات طراحی فروشگاه اینترنتی که در ایران خرید را نیمه‌کاره می‌گذارند

بیشتر اشتباهات طراحی فروشگاه اینترنتی که فروش را کم می‌کنند، در رنگ و چیدمان صفحهٔ اصلی نیستند؛ در مسیر خرید هستند، از جعبهٔ جست‌وجو تا برگشت از صفحهٔ بانک. چند تا از پرهزینه‌ترینشان فقط در فروشگاه ایرانی پیش می‌آیند: جست‌وجویی که «ي» عربی و «ی» فارسی را دو حرف می‌داند، فرمی که شمارهٔ موبایل درست را چون با رقم فارسی تایپ شده رد می‌کند، و سفارشی که پولش پرداخت شده ولی در پنل شما «پرداخت‌نشده» مانده است. این‌ها در فروشگاه آمریکایی به این شکل وجود ندارند، برای همین در فهرست‌هایی که از منابع خارجی ترجمه شده‌اند هم نیستند.

آمار سبد خرید رها شده چه می‌گوید و چه نمی‌گوید

مؤسسهٔ Baymard نتیجهٔ ۵۰ پژوهش مختلف دربارهٔ سبد خرید رها شده را کنار هم گذاشته و به میانگین ۷۰٫۲۲ درصد رسیده است؛ یعنی از هر ده نفری که کالایی در سبد می‌گذارند، حدود هفت نفر خرید را تمام نمی‌کنند. بخش بزرگی از این عدد طبیعی است. در نظرسنجی خود Baymard از خریداران آنلاین آمریکایی، ۴۲ درصد گفته‌اند سبد را رها کرده‌اند چون فقط داشتند نگاه می‌کردند.

وقتی این گروه کنار گذاشته شود، پنج دلیل بعدی این‌ها هستند. ستون آخر برداشت ماست از اینکه هر کدام در فروشگاه ایرانی چه شکلی پیدا می‌کند، نه دادهٔ آن پژوهش.

مهم‌ترین تفاوت در ردیف آخر است. در فروشگاه ایرانی یک نقطهٔ شکست هست که در آن نظرسنجی اصلاً وجود ندارد: خریدار سایت را ترک می‌کند، در صفحهٔ بانک پول می‌دهد و باید برگردد. پژوهش عمومی معادلی برای فروشگاه‌های ایرانی پیدا نکردیم، پس این درصدها را جهت‌نما بخوانید، نه اندازهٔ دقیق بازار ما.

۱. جست‌وجویی که «ي» و «ی» را دو حرف می‌داند

یک کلمه در فارسی چند شکل نوشتاری دارد و برای خریدار همه‌شان یکی‌اند. «ی» و «ک» فارسی با «ي» و «ك» عربی در ظاهر فرقی ندارند ولی کدشان فرق دارد، و کافی است عنوان محصول را کسی از فایل اکسل تأمین‌کننده کپی کرده باشد و مشتری با صفحه‌کلید گوشی جست‌وجو کند. نیم‌فاصله هم همین‌طور است: «دست‌بند»، «دست بند» و «دستبند» سه رشتهٔ متفاوت‌اند. رقم‌ها هم؛ مشتری «آیفون ۱۵» را با رقم فارسی می‌نویسد و عنوان محصول iPhone 15 است.

جست‌وجویی که رشته‌ها را همان‌طور که تایپ شده‌اند مقایسه کند، برای کالایی که در انبار دارید «نتیجه‌ای یافت نشد» نشان می‌دهد. خریدار فکر نمی‌کند جست‌وجوی شما خراب است؛ فکر می‌کند کالا را ندارید و می‌رود سراغ فروشگاه بعدی.

راه درست یکسان‌سازی است، و نکتهٔ مهمش این است که روی هر دو طرف انجام شود؛ هم روی متن محصول‌ها هنگام ساختن ایندکس جست‌وجو، هم روی عبارتی که کاربر تایپ می‌کند. بیشتر موارد با چهار قاعده حل می‌شوند: «ي» و «ك» به شکل فارسی، نیم‌فاصله به فاصله، رقم‌های فارسی و عربی به یک شکل، و فهرست کوتاهی از نام برندها به هر دو خط تا «سامسونگ» و Samsung یکی دیده شوند. ابزاری که برای بررسی مطالب همین وبلاگ نوشته‌ایم، پیش از هر مقایسه سه قاعدهٔ اول را اجرا می‌کند؛ بدون آن، دو نوشتار از یک عبارت را دو عبارت جدا می‌دید.

صفحهٔ «نتیجه‌ای یافت نشد» هم نباید بن‌بست باشد. دسته‌بندی‌های نزدیک، پرفروش‌ها و شمارهٔ تماس را همان‌جا نشان دهید. و فهرست جست‌وجوهای بی‌نتیجه را هر هفته بخوانید. این فهرست ارزان‌ترین پژوهش بازاری است که در اختیار دارید، چون یا کالایی را نشان می‌دهد که با نام دیگری در فروشگاه هست، یا کالایی که مشتری دنبالش است و شما ندارید.

۲. فیلترهایی که به صفحهٔ خالی می‌رسند

کاربر سه فیلتر می‌زند و به صفحه‌ای خالی می‌رسد، و حالا باید حدس بزند کدام فیلتر مقصر بوده است. دو کار ساده جلوی این را می‌گیرد: کنار هر گزینه تعداد نتیجه‌اش را بنویسید و گزینه‌ای را که به صفر می‌رسد غیرفعال کنید. فیلترهای فعال هم باید بالای فهرست دیده شوند و تک‌تک قابل حذف باشند.

دو اشکال دیگر کمتر به چشم می‌آیند. اولی دادهٔ نامرتب است. وقتی رنگ یک محصول «قرمز» ثبت شده، دیگری «قرمز» با یک فاصلهٔ اضافه در انتها و سومی «red»، فیلتر رنگ سه گزینهٔ قرمز دارد که هر کدام بخشی از کالاها را نشان می‌دهد. این را هیچ طراحی رابطی درست نمی‌کند؛ مقدار ویژگی‌ها باید در پنل مدیریت از فهرست انتخاب شود، نه با تایپ آزاد.

دومی روی موبایل پیش می‌آید. کاربر فیلتر می‌زند، وارد صفحهٔ یک محصول می‌شود، دکمهٔ برگشت را می‌زند و فهرست بدون فیلتر جلویش است. اگر وضعیت فیلترها در نشانی صفحه نگه داشته شود، برگشت دقیقاً همان‌جایی را نشان می‌دهد که کاربر ترکش کرده بود.

۳. هزینهٔ ارسالی که در آخرین قدم پیدا می‌شود

در همان نظرسنجی Baymard، هزینه‌های اضافه بزرگ‌ترین دلیل رها کردن سبد بود و ۱۲ درصد هم گفته بودند نتوانسته‌اند مبلغ کل سفارش را از اول ببینند یا حساب کنند. در ایران این مشکل یک لایهٔ اضافه دارد: هزینهٔ ارسال به شهر مقصد و روش ارسال بستگی دارد، و خیلی از فروشگاه‌ها به‌جای حساب کردنش، ارسال را «پس‌کرایه» می‌کنند.

پس‌کرایه هزینه را از خریدار پنهان نمی‌کند؛ فقط آن را به دم در منتقل می‌کند. اگر سایت نگوید حدوداً چقدر است، همان غافلگیری است، فقط دیرتر و این بار جلوی مأمور پست. گاهی نتیجه‌اش به‌جای سبد رها شده، مرسوله‌ای است که تحویل گرفته نمی‌شود و با هزینهٔ شما برمی‌گردد.

راهش ساده‌تر از آن است که به نظر می‌رسد. در صفحهٔ محصول بگذارید کاربر استانش را انتخاب کند و هزینه و زمان تقریبی ارسال را همان‌جا ببیند. اگر آستانهٔ ارسال رایگان دارید، در سبد خرید بنویسید چقدر تا آن مانده است. و به‌جای جملهٔ کلی «ارسال سه تا هفت روز کاری»، تاریخ تقریبی رسیدن را برای همان شهر نشان دهید. ارسال کُند در آن نظرسنجی دومین دلیل رها کردن سبد بود، و تاریخ مشخص، حتی اگر دور باشد، از بازهٔ مبهم باورپذیرتر است.

۴. صفحهٔ ورودی که جلوی سبد خرید ایستاده

اجبار به ساختن حساب کاربری در نظرسنجی Baymard دلیل ۱۸ درصد از رها کردن‌ها بود. رایج‌ترین الگوی ورود در فروشگاه‌های ایرانی شمارهٔ موبایل و کد پیامکی است و این انتخاب درستی است: شمارهٔ موبایل را برای هماهنگی ارسال لازم دارید، پس گرفتنش هزینهٔ اضافه‌ای برای خریدار ندارد. اشکال‌ها در جزئیات همین الگوست.

• ورود پیش از دیدن سبد، یا حتی پیش از افزودن کالا به آن خواسته می‌شود. جای درستش لحظهٔ تسویه است.
• بعد از کد پیامکی، ساختن رمز عبور هم اجباری است. رمز را بعد از خرید پیشنهاد دهید، نه پیش از آن.
• فیلد کد، autocomplete="one-time-code" و inputmode="numeric" ندارد. اپل همین نشانه را برای پر کردن خودکار کدهای پیامکی مستند کرده، و طبق MDN اگر خط آخر پیامک به شکل @shop.ir #12345 باشد، Safari هنگام رسیدن پیامک کد را پیشنهاد می‌دهد.
• پیامک دیر می‌رسد و صفحه هیچ نشانی از ارسال دوباره ندارد. یک شمارندهٔ معکوس کنار دکمهٔ «ارسال دوباره» به کاربر می‌گوید منتظر چه باشد.
• بعد از ورود، سبد خالی است. کالاهایی که کاربر پیش از ورود در سبد گذاشته بود باید با سبد حسابش یکی شوند، وگرنه او را دوباره تا صفحهٔ محصول برگردانده‌اید.

۵. فرمی که رقم فارسی را قبول نمی‌کند

این یکی مخصوص فروشگاه‌های فارسی است و از همه راحت‌تر پیش می‌آید. خریدار با صفحه‌کلید فارسی گوشی شماره‌اش را می‌نویسد: ۰۹۱۲۳۴۵۶۷۸۹. فرم آن را با الگویی مثل /^09\d{9}$/ می‌سنجد، و در جاوااسکریپت، طبق MDN، \d فقط معادل [0-9] است. نتیجه یک شمارهٔ درست است و پیغام «شمارهٔ موبایل معتبر نیست»، و خریداری که نمی‌فهمد کجای کار را اشتباه کرده. همین اتفاق برای کد پستی ده‌رقمی و کد ملی هم می‌افتد.

رفعش یک خط کد است: پیش از اعتبارسنجی و ذخیره، رقم‌های فارسی (U+06F0 تا U+06F9) و عربی (U+0660 تا U+0669) را به رقم لاتین متناظرشان برگردانید. پیغام خطا هم باید بگوید چه چیزی اشتباه است. «شماره باید ۱۱ رقم باشد و با ۰۹ شروع شود» به خریدار کمک می‌کند؛ «ورودی نامعتبر» نه.

بقیهٔ فرم هم همین منطق را دارد و هر فیلد باید دلیلی داشته باشد. Baymard در آزمون‌هایش به این رسیده که یک فرایند پرداخت خوب می‌تواند با ۷ تا ۸ فیلد تمام شود، در حالی که فرایند پرداخت در فروشگاه‌های آمریکایی به‌طور میانگین ۱۴٫۸۸ فیلد را از ابتدا نشان می‌دهد. کد ملی را فقط وقتی بپرسید که باید فاکتور رسمی صادر کنید، و ایمیل را فقط وقتی که واقعاً چیزی به ایمیل می‌فرستید.

برای فیلدهای عددی inputmode="numeric" بگذارید تا صفحه‌کلید عددی باز شود. با مقدارهای autocomplete هم، مثل tel-national برای موبایل، postal-code برای کد پستی، address-level1 برای استان و address-level2 برای شهر، به مرورگر اجازه می‌دهید اطلاعاتی را که قبلاً ذخیره کرده خودش پر کند. فهرست کامل این مقدارها در MDN آمده است.

۶. صفحهٔ بانک؛ تنها بخش مسیر که دست شما نیست

در بیشتر فروشگاه‌های ایرانی، خریدار برای پرداخت از سایت شما بیرون می‌رود و شمارهٔ کارت و رمز دوم پویا را در صفحهٔ درگاه وارد می‌کند. دو چیز از همین‌جا نتیجه می‌شود.

اول اینکه نشانه‌های اعتماد باید به سؤال درست جواب بدهند. خریدار نگران نیست کارتش در سایت شما لو برود، چون آن را در سایت شما وارد نمی‌کند. نگران این است که کالا برسد و اگر ایرادی داشت بتواند برگرداند. شمارهٔ تلفنی که جواب می‌دهد، شرایط مرجوعی کنار دکمهٔ پرداخت و نماد اعتماد الکترونیکی به این سؤال جواب می‌دهند؛ نشان «پرداخت امن» که خودتان روی سایت گذاشته‌اید، نه.

دوم اینکه پیش از فرستادن خریدار به بانک به او بگویید چه در انتظارش است: مبلغ نهایی، اینکه برای رمز دوم پویا گوشی‌اش را لازم دارد، و اینکه بعد از پرداخت به سایت برمی‌گردد. در صفحهٔ بانک چیزی نیست که به او بگوید هنوز در مسیر درست است.

یک الزام فنی هم هست که اشتباه در آن کل درگاه را به خطر می‌اندازد. زرین‌پال در تیر ۱۴۰۴ اعلام کرد که به تأکید شاپرک، صفحه‌ای که پرداخت از آن شروع می‌شود و صفحه‌ای که خریدار بعد از پرداخت به آن برمی‌گردد باید روی همان دامنه‌ای باشند که درگاه برایش ثبت شده، و بعد از ۸ مرداد ۱۴۰۴ هر مغایرتی از نگاه شاپرک تخلف است و می‌تواند به تعلیق درگاه برسد. فروشگاهی که تسویه را روی دامنهٔ جداگانه‌ای گذاشته، یا از ربات تلگرام و صفحهٔ اینستاگرام مستقیم لینک درگاه می‌فرستد، همین‌جا گیر می‌کند. راهی که خود زرین‌پال پیشنهاد می‌دهد، یک صفحهٔ فاکتور روی دامنهٔ اصلی است که خریدار از آنجا به بانک برود.

۷. برگشت از بانک؛ جایی که سفارشِ پرداخت‌شده گم می‌شود

خریدار پرداخت را تمام می‌کند و پیامک برداشت را از بانکش می‌گیرد. بعد، پیش از آنکه به سایت شما برگردد، تب را می‌بندد، اینترنتش قطع می‌شود، یا سرور شما در همان لحظه جواب نمی‌دهد. سفارش در پنل شما «پرداخت‌نشده» می‌ماند و پول از حساب او رفته است. تماس بعدی‌اش با پشتیبانی از سخت‌ترین تماس‌هایی است که یک فروشگاه می‌گیرد.

درگاه‌ها برای همین حالت ابزار دارند. مستندات زرین‌پال توضیح می‌دهد که خریدار با پارامتر Status به سایت برمی‌گردد که یا OK است یا NOK؛ NOK یعنی تراکنش ناموفق بوده یا خریدار خودش لغوش کرده، و فروشگاه فقط وقتی OK برگشته، تراکنش را با verify تأیید می‌کند. برای پرداخت‌هایی که هیچ‌وقت تأیید نشده‌اند هم متد جداگانهٔ unVerified هست که فهرست پرداخت‌های موفقِ تأییدنشده را برمی‌گرداند. ابزار هست؛ اشکال از فروشگاهی است که صفحهٔ برگشت را تنها راه خبردار شدن از پرداخت می‌داند. سه چیز این حفره را می‌بندد.

• یک کار زمان‌بندی‌شده که هر چند دقیقه پرداخت‌های تأییدنشده را از درگاه می‌گیرد و سفارش‌های مربوط به آن‌ها را نهایی می‌کند.
• صفحهٔ برگشتی که سه حالت را از هم جدا می‌کند: موفق، ناموفق، و «هنوز تأیید نشده». حالت سوم هیچ‌وقت نباید بنویسد پرداخت ناموفق بود، چون ممکن است پول کم شده باشد؛ باید بگوید سفارش در حال بررسی است و تا کی خبر می‌دهید.
• تازه کردن صفحهٔ برگشت، یا دو بار رسیدن یک پاسخ از درگاه، نباید دو سفارش بسازد.

این سه مورد یکی از دلیل‌های فاصلهٔ قیمت دو پیش‌فاکتور فروشگاه است، و در نوشته‌ای دربارهٔ اینکه قیمت یک پروژهٔ وب از کجا می‌آید توضیح داده‌ایم چرا هیچ‌کدامشان در دموی روز اول دیده نمی‌شوند.

۸. موبایل، و تصویرهایی که دکمهٔ خرید را جابه‌جا می‌کنند

طبق Statcounter، در اوت ۲۰۲۶ سهم موبایل از بازدیدهای وب در ایران ۶۴٫۱۹ درصد و سهم دسکتاپ ۳۵٫۴۹ درصد بوده است. این عدد برای کل وب است، نه فقط فروشگاه‌ها، ولی برای اینکه نسخهٔ موبایل را نسخهٔ اصلی بدانید کافی است.

در صفحهٔ محصول، اشکال رایج تصویری است که ابعادش در کد مشخص نشده. تا تصویر برسد مرورگر جایی برایش نگه نمی‌دارد، و وقتی رسید همه‌چیزِ زیرش پایین می‌رود؛ از جمله دکمهٔ «افزودن به سبد» که کاربر همان لحظه می‌خواست لمسش کند. MDN توضیح می‌دهد که width و height به مرورگر اجازه می‌دهند نسبت ابعاد را پیش از بار شدن تصویر حساب کند و جا را از قبل نگه دارد.

دو کار ارزان دیگر هم هست: چند تصویر از زاویه‌های مختلف با امکان بزرگ‌نمایی، و دکمهٔ خریدی که روی موبایل هنگام اسکرول پایین صفحه بماند. بقیهٔ ماجرای سرعت، از قالب تصویر تا اسکریپت‌های اضافه، در رابطهٔ سرعت سایت با فروش آمده است.

اشتباهات طراحی فروشگاه اینترنتی خودتان را در یک بعدازظهر پیدا کنید

برای پیدا کردن این اشکال‌ها ابزار گران لازم نیست. یک گوشی میان‌رده، اینترنت همراه و چند ساعت وقت کافی است.

• یک خرید کامل روی گوشی انجام دهید، با صفحه‌کلید فارسی و به نشانی‌ای در استانی دیگر، تا صفحهٔ بانک و برگشت از آن.
• پنج کالا را همان‌طور جست‌وجو کنید که مشتری می‌نویسد: یکی با «ي» عربی که از جایی کپی شده، یکی با فاصله به‌جای نیم‌فاصله، یکی با رقم فارسی و یکی با نام برند به فارسی.
• در محیط آزمایشی درگاه، پرداخت را تمام کنید و پیش از برگشت به سایت تب را ببندید. ببینید پنل مدیریت همان لحظه چه نشان می‌دهد و ده دقیقه بعد چه.
• فهرست جست‌وجوهای بی‌نتیجهٔ ماه گذشته را بخوانید.

بعد همین مسیر را از پنج نفر بیرون از تیم بخواهید و فقط تماشا کنید. یاکوب نیلسن در سال ۲۰۰۰ برآورد کرد که آزمون با پنج کاربر حدود ۸۵ درصد مشکل‌های کاربردپذیری را پیدا می‌کند، و پیشنهادش این بود که به‌جای یک آزمون بزرگ، سه دور آزمون پنج‌نفره انجام شود و بین هر دور، ایرادها اصلاح شوند.

بیشتر آنچه این آزمون پیدا می‌کند بازطراحی لازم ندارد. یکسان‌سازی جست‌وجو، تبدیل رقم‌ها، نشان دادن هزینهٔ ارسال و تطبیق پرداخت‌های تأییدنشده همه روی همان فروشگاه فعلی انجام می‌شوند. بازطراحی وقتی توجیه دارد که پلتفرم فعلی اجازهٔ همین تغییرها را ندهد؛ نشانه‌های اینکه سایت واقعاً به بازطراحی رسیده را جدا نوشته‌ایم.

اگر هم فروشگاه را تازه می‌سازید، این هشت مورد را پیش از شروع در دامنهٔ کار بنویسید و روز تحویل، کنار چک‌لیست پیش از انتشار سایت، یکی‌یکی آزمایش کنید. آنچه در ساخت یک فروشگاه اختصاصی تحویل می‌دهیم از همین مسیر خرید شروع می‌شود.