روال‌های مطلوب فرم پرداخت و نشانی

با کمک به کاربران برای تکمیل فرم‌های نشانی و پرداخت در سریع‌ترین و آسان‌ترین حالت ممکن، تبدیل‌ها را به حداکثر برسانید.

Sam Dutton

فرم‌های خوب طراحی‌شده به کاربران کمک می‌کنند و نرخ تبدیل را افزایش می‌دهند. یک اصلاح کوچک می‌تواند تفاوت بزرگی ایجاد کند!

در اینجا نمونه‌ای از فرم پرداخت ساده‌ای را می‌بینید که همه روال‌های مطلوب را نشان می‌دهد:

در اینجا نمونه‌ای از فرم نشانی ساده‌ای آورده شده است که همه روال‌های مطلوب را نشان می‌دهد:

بازبینه

استفاده از HTML معنادار

از عناصر و مشخصه‌هایی که برای این کار ساخته شده‌اند استفاده کنید:

  • ‫<form>،‏ <input>،‏ <label>، و <button>
  • ‫type، autocomplete، و inputmode

این ویژگی‌ها عملکرد داخلی مرورگر را فعال می‌کنند، دسترس‌پذیری را بهبود می‌بخشند، و به نشان‌گذاری شما معنی اضافه می‌کنند.

استفاده از عناصر HTML به‌صورت هدفمند

فرم را در <form> قرار دهید

ممکن است وسوسه شوید که عناصر <input> را در <form> قرار ندهید و ارسال داده‌ها را صرفاً با جاوا اسکریپت انجام دهید.

این کار را نکنید!

<form> HTML به شما امکان می‌دهد به مجموعه قدرتمندی از ویژگی‌های داخلی در همه مرورگرهای نو دسترسی داشته باشید، و می‌تواند به دردسترس قرار دادن سایت شما برای صفحه‌خوان‌ها و دیگر دستگاه‌های کمکی کمک کند. <form> همچنین ساختن عملکرد پایه را برای مرورگرهای قدیمی‌تر با پشتیبانی محدود از «جاوا اسکریپت» ساده‌تر می‌کند و ارسال فرم را حتی درصورت وجود اشکال در کد شما امکان‌پذیر می‌کند—و برای تعداد کمی از کاربران که واقعاً «جاوا اسکریپت» را غیرفعال می‌کنند.

اگر بیش‌از یک مؤلفه صفحه برای ورودی کاربر دارید، حتماً هرکدام را در عنصر <form> خودش قرار دهید. برای مثال، اگر جستجو و ثبت‌نام را در یک صفحه دارید، هرکدام را در <form> خودش قرار دهید.

از <label> برای برچسب‌گذاری عناصر استفاده کنید

برای برچسب‌گذاری <input>، <select>، یا <textarea>، از <label> استفاده کنید.

با دادن مقدار یکسان به مشخصه for برچسب و id ورودی، برچسب را با ورودی مرتبط کنید.

<label for="address-line1">Address line 1</label>
<input id="address-line1" …>

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

دکمه‌ها را مفید کنید

از <button> برای دکمه‌ها استفاده کنید! همچنین می‌توانید از <input type="submit"> استفاده کنید، اما از div یا برخی عناصر تصادفی دیگر که به‌عنوان دکمه عمل می‌کنند استفاده نکنید. عناصر دکمه رفتار دسترس‌پذیر، عملکرد ارسال فرم داخلی، و قابلیت سبک‌دهی آسان را ارائه می‌دهند.

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

غیرفعال کردن دکمه ارسال را پس‌از اینکه کاربر روی آن تک‌ضرب زده یا کلیک کرده است درنظر بگیرید—به‌ویژه وقتی کاربر درحال پرداخت یا ثبت سفارش است. بسیاری از کاربران دکمه‌ها را مکرراً کلیک می‌کنند، حتی اگر به‌درستی کار کنند. این کار می‌تواند تسویه‌حساب را مختل کند و بار سرور را افزایش دهد.

const form = document.querySelector('form');
const submitButton = form.querySelector('button[type="submit"]');

form.addEventListener('submit', () => {
  submitButton.disabled = true;
  submitButton.textContent = 'Placing order…';
});

ازسوی دیگر، دکمه ارسال را درحالی‌که منتظر ورودی کامل و معتبر کاربر است غیرفعال نکنید. برای مثال، دکمه ذخیره نشانی را فقط به‌دلیل اینکه چیزی وجود ندارد یا نامعتبر است غیرفعال نکنید. این کار به کاربر کمکی نمی‌کند—ممکن است کاربر همچنان روی دکمه تک‌ضرب بزند یا کلیک کند و تصور کند که دکمه خراب است. درعوض، اگر کاربران سعی کردند فرمی را با داده‌های نامعتبر ارسال کنند، برایشان توضیح دهید که مشکل چیست و برای رفع آن چه کاری باید انجام دهند. این امر به‌ویژه در تلفن همراه مهم است، جایی که وارد کردن داده‌ها دشوارتر است و داده‌های فرم نامعتبر یا مفقود ممکن است تا زمانی که کاربر تلاش می‌کند فرم را ارسال کند، در صفحه کاربر قابل مشاهده نباشد.

بیشترین بهره را از مشخصه‌های HTML ببرید

وارد کردن داده‌ها را برای کاربران آسان کنید

از typeمشخصه ورودی مناسب استفاده کنید تا صفحه‌کلید مناسب را در تلفن همراه ارائه دهید و اعتبارسنجی داخلی پایه را توسط مرورگر فعال کنید.

برای مثال، از type="email" برای نشانی‌های ایمیل و از type="tel" برای شماره تلفن‌ها استفاده کنید.

دو نماگرفت از تلفن‌های Android که صفحه‌کلید مناسب برای وارد کردن نشانی ایمیل (بااستفاده از type=email) و برای وارد کردن شماره تلفن (با type=tel) را نشان می‌دهد.
صفحه‌کلیدهای مناسب برای ایمیل و تلفن.

برای تاریخ‌ها، سعی کنید از عناصر select سفارشی استفاده نکنید. اگر به‌درستی پیاده‌سازی نشوند، تجربه تکمیل خودکار را خراب می‌کنند و در مرورگرهای قدیمی‌تر کار نمی‌کنند. برای اعدادی مانند سال تولد، به‌جای select، از عنصر input استفاده کنید، زیرا وارد کردن دستی ارقام می‌تواند آسان‌تر و کمتر مستعد خطا باشد تا انتخاب از یک فهرست کرکره‌ای طولانی—به‌ویژه در تلفن همراه. از inputmode="numeric" استفاده کنید تا مطمئن شوید صفحه‌کلید مناسب در تلفن همراه نمایش داده می‌شود و بااستفاده از نوشتار یا جای‌بان، نکات اعتبارسنجی و قالب را اضافه کنید تا مطمئن شوید کاربر داده‌ها را در قالب مناسب وارد می‌کند.

از تکمیل خودکار برای بهبود دسترس‌پذیری و کمک به کاربران برای جلوگیری از وارد کردن مجدد داده‌ها استفاده کنید

استفاده از مقادیر autocomplete مناسب به مرورگرها امکان می‌دهد با ذخیره ایمن داده‌ها و تکمیل خودکار مقادیر input،‏ select، و textarea به کاربران کمک کنند. این امر به‌ویژه در تلفن همراه مهم است و برای جلوگیری از نرخ بالای رها کردن فرم بسیار حیاتی است. تکمیل خودکار همچنین مزایای دسترس‌پذیری متعددی ارائه می‌دهد.

اگر مقدار تکمیل خودکار مناسبی برای فیلد فرم دردسترس است، باید از آن استفاده کنید. اسناد وب MDN فهرست کاملی از مقادیر و توضیحات مربوط به نحوه استفاده صحیح از آن‌ها را دارد.

مقادیر پایدار

نشانی صورت‌حساب

به‌طور پیش‌فرض، نشانی صورت‌حساب را همان نشانی تحویل کالا تنظیم کنید. با ارائه پیوندی برای ویرایش نشانی صورت‌حساب (یا استفاده از عناصر summary و details) به‌جای نمایش نشانی صورت‌حساب در فرم، درهم‌ریختگی بصری را کاهش دهید.

نمونه صفحه تصفیه‌حساب که پیوند تغییر نشانی صورت‌حساب را نشان می‌دهد.
پیوندی برای بررسی صورت‌حساب اضافه کنید.

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

<input autocomplete="shipping address-line1" ...>
<!-- Other fields omitted. -->
<input autocomplete="billing address-line1" ...>

به کاربران کمک کنید داده‌های درست را وارد کنند

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

می‌توانید مشخصه‌های محدودیت را به عناصر فرم اضافه کنید تا مقادیر قابل‌قبول را مشخص کنید، ازجمله min، max، و pattern. وضعیت اعتبار عنصر به‌طور خودکار براساس معتبر بودن یا نبودن مقدار عنصر تنظیم می‌شود، همان‌طور که شبه‌کلاس‌های CSS :valid و :invalid که می‌توانند برای سبک‌دهی به عناصر با مقادیر معتبر یا نامعتبر استفاده شوند.

برای مثال، HTML زیر ورودی سال تولد را بین ۱۹۰۰ و ۲۰۲۰ مشخص می‌کند. استفاده از type="number" مقادیر ورودی را فقط به اعداد محدود می‌کند، در محدوده‌ای که توسط min و max مشخص شده است. اگر بخواهید عددی خارج از محدوده وارد کنید، ورودی در وضعیت نامعتبر قرار خواهد گرفت.

مثال زیر از pattern="[\d ]{10,30}" برای اطمینان از معتبر بودن شماره کارت پرداخت استفاده می‌کند، درحالی‌که فاصله‌ها را مجاز می‌داند:

مرورگرهای مدرن همچنین اعتبارسنجی پایه را برای ورودی‌های با نوع email یا url انجام می‌دهند.

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

فرم ورود به سیستم در Chrome در رایانه که پیام‌واره مرورگر و تمرکز را برای مقدار ایمیل نامعتبر نشان می‌دهد.
اعتبارسنجی داخلی پایه توسط مرورگر.

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

همچنین باید از جاوا اسکریپت برای انجام اعتبارسنجی قوی‌تر هنگام وارد کردن داده‌ها توسط کاربران و هنگام ارسال فرم استفاده کنید. از Constraint Validation API (که به‌طور گسترده پشتیبانی می‌شود) برای افزودن اعتبارسنجی سفارشی بااستفاده از میانای کاربر مرورگر داخلی برای تنظیم تمرکز و نمایش پیام‌واره‌ها استفاده کنید.

در اعتبارسنجی فرم سمت کارخواه بیشتر بدانید.

به کاربران کمک کنید داده‌های الزامی را ازقلم نیندازند

از مشخصه required در ورودی‌ها برای مقادیر اجباری استفاده کنید.

وقتی فرمی ارسال می‌شود، مرورگرهای نو به‌طور خودکار پیام‌واره‌ای نشان می‌دهند و روی فیلدهای required که داده‌هایشان وارد نشده است تمرکز می‌کنند، و می‌توانید از کلاس کاذب :required برای برجسته کردن فیلدهای الزامی استفاده کنید. به جاوا اسکریپت نیاز نیست!

برای هر فیلد الزامی، یک ستاره به برچسب اضافه کنید و در ابتدای فرم یادداشتی اضافه کنید تا معنی ستاره را توضیح دهد.

ساده‌سازی تسویه‌حساب

Mind the mobile commerce gap

تصور کنید که کاربران شما بودجه خستگی دارند. اگر آن را تمام کنید، کاربران شما را ترک خواهند کرد.

باید اصطکاک را کاهش دهید و تمرکز را حفظ کنید، به‌ویژه در تلفن همراه. بسیاری از سایت‌ها در تلفن همراه ترافیک بیشتری دریافت می‌کنند اما در رایانه تبدیل بیشتری دارند—پدیده‌ای که به‌عنوان شکاف تجارت تلفن همراه شناخته می‌شود. ممکن است مشتریان ترجیح دهند خرید را در رایانه تکمیل کنند، اما نرخ تبدیل پایین‌تر در تلفن همراه نیز نتیجه تجربه کاربری ضعیف است. وظیفه شما این است که تبدیل‌های ازدست‌رفته در تلفن همراه را به حداقل برسانید و تبدیل‌ها در رایانه را به حداکثر برسانید. پژوهش‌ها نشان داده است که فرصت بزرگی برای ارائه تجربه بهتر فرم تلفن همراه وجود دارد.

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

تسویه‌حساب به‌عنوان مهمان را پیش‌فرض کنید

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

دلایل رها کردن سبد خرید درطول تسویه‌حساب.
از baymard.com/checkout-usability

می‌توانید ثبت‌نام حساب را بعداز تسویه‌حساب ارائه دهید. در آن مرحله، شما ازقبل بیشتر داده‌های لازم برای راه‌اندازی حساب را دارید، بنابراین ایجاد حساب باید برای کاربر سریع و آسان باشد.

نمایش پیشرفت تسویه‌حساب

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

نمایش پیشرفت تسویه‌حساب.

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

نام‌های معناداری به دکمه‌های فرم بدهید که نشان دهد مرحله بعدی چیست.

از مشخصه enterkeyhint در ورودی‌های فرم برای تنظیم برچسب کلید Enter صفحه‌کلید تلفن همراه استفاده کنید. برای مثال، از enterkeyhint="previous" و enterkeyhint="next" در فرم چندصفحه‌ای، enterkeyhint="done" برای ورودی نهایی در فرم، و enterkeyhint="search" برای ورودی جستجو استفاده کنید.

دو نماگرفت از فرم نشانی در Android که نشان می‌دهد چگونه مشخصه ورودی enterkeyhint نماد دکمه کلید ورود را تغییر می‌دهد.
دکمه‌های کلید Enter در Android: «بعدی» و «تمام».

مشخصه enterkeyhint در Android و iOS پشتیبانی می‌شود. می‌توانید در توضیح‌دهنده enterkeyhint اطلاعات بیشتری کسب کنید.

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

برداشتن موارد ناخواسته

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

دو نماگرفت در تلفن همراه که پیشرفت در تسویه‌حساب johnlewis.com را نشان می‌دهد. جستجو، پیمایش، و دیگر عوامل حواس‌پرتی برداشته شده‌اند.
جستجو، پیمایش، و دیگر عوامل حواس‌پرتی برای تسویه‌حساب برداشته شده است.

تمرکز سفر را حفظ کنید. اکنون زمان وسوسه کردن کاربران برای انجام کاری دیگر نیست!

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

برای کاربران بازگشتی می‌توانید روند تسویه‌حساب را با پنهان کردن داده‌هایی که نیازی به دیدن آن‌ها ندارند، حتی بیشتر ساده کنید. برای مثال: نشانی تحویل کالا را به‌صورت نوشتار ساده (نه در فرم) نمایش دهید و به کاربران اجازه دهید با دنبال کردن پیوند آن را تغییر دهند.

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

وارد کردن نام و نشانی را آسان کنید

فقط داده‌هایی را که نیاز دارید درخواست کنید

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

استفاده از یک ورودی نام

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

به‌ویژه، مگر اینکه دلیل خوبی برای این کار داشته باشید، زحمت افزودن ورودی جداگانه برای پیشوند یا عنوان (مانند خانم، دکتر، یا لرد) را به خود ندهید. کاربران می‌توانند درصورت تمایل آن را با نامشان تایپ کنند. همچنین، درحال‌حاضر تکمیل خودکار honorific-prefix در اکثر مرورگرها کار نمی‌کند، بنابراین افزودن فیلدی برای پیشوند نام یا عنوان، تجربه تکمیل خودکار فرم نشانی را برای اکثر کاربران مختل می‌کند.

فعال کردن تکمیل خودکار نام

از name برای نام کامل استفاده کنید:

<input autocomplete="name" ...>

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

  • honorific-prefix
  • given-name
  • nickname
  • additional-name-initial
  • additional-name
  • family-name
  • honorific-suffix

مجاز کردن نام‌های بین‌المللی

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

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

موارد غیرمجاز
<!-- Names with non-Latin characters (such as Françoise or Jörg) are 'invalid'. -->
<input pattern="[\w \-]+" ...>
انجام دهید
<!-- Accepts Unicode letters. -->
<input pattern="[\p{L} \-]+" ...>
مطابقت حرف یونی‌کد درمقایسه با مطابقت حرف فقط لاتین.

قالب‌های نشانی مختلف را بپذیرید

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

انعطاف‌پذیر کردن فرم‌های نشانی

کاربران را مجبور نکنید نشانی‌شان را در فیلدهای فرمی که مناسب نیست به‌زور جا دهند.

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

به‌ویژه در فیلدهای نشانی required دقت کنید. برای مثال، نشانی‌های شهرهای بزرگ در بریتانیا شهرستان ندارند، اما بسیاری از سایت‌ها همچنان کاربران را مجبور می‌کنند که شهرستان را وارد کنند.

استفاده از دو خط نشانی انعطاف‌پذیر می‌تواند برای انواع قالب‌های نشانی به‌اندازه کافی خوب عمل کند.

<input autocomplete="address-line1" id="address-line1" ...>
<input autocomplete="address-line2" id="address-line2" ...>

افزودن برچسب‌های منطبق:

<label for="address-line1">
Address line 1 (or company name)
</label>
<input autocomplete="address-line1" id="address-line1" ...>

<label for="address-line2">
Address line 2 (optional)
</label>
<input autocomplete="address-line2" id="address-line2" ...>

استفاده از یک ناحیه نوشتاری برای نشانی را درنظر بگیرید

انعطاف‌پذیرترین گزینه برای نشانی‌ها ارائه یک textarea است.

رویکرد textarea با هر قالب نشانی‌ای سازگار است و برای برش و جای‌گذاری عالی است—اما به‌خاطر داشته باشید که ممکن است با الزامات داده شما سازگار نباشد و اگر کاربران قبلاً فقط از فرم‌های دارای address-line1 و address-line2 استفاده کرده باشند، ممکن است تکمیل خودکار را ازدست بدهند.

برای textarea، از street-address به‌عنوان مقدار تکمیل خودکار استفاده کنید.

در اینجا نمونه‌ای از فرمی آورده شده است که استفاده از یک textarea برای نشانی را نشان می‌دهد:

فرم‌های نشانی را بین‌المللی و بومی‌سازی کنید

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

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

    ZIP code: US
 Postal code: Canada
    Postcode: UK
     Eircode: Ireland
         PIN: India

دیدن فرمی که با نشانی شما مطابقت ندارد یا از کلماتی که انتظار دارید استفاده نمی‌کند می‌تواند آزاردهنده یا گیج‌کننده باشد.

سفارشی‌سازی فرم‌های نشانی برای چندین منطقه ممکن است برای سایت شما ضروری باشد، اما استفاده از تکنیک‌هایی برای به‌حداکثر رساندن انعطاف‌پذیری فرم (همان‌طور که در بالا توضیح داده شد) ممکن است کافی باشد. اگر فرم‌های نشانی را بومی‌سازی نمی‌کنید، حتماً اولویت‌های کلیدی را برای مقابله با طیف وسیعی از قالب‌های نشانی درک کنید:

  • از بیش‌ازحد دقیق بودن درباره بخش‌های نشانی، مثل اصرار بر نام خیابان یا شماره خانه، خودداری کنید.
  • درصورت امکان، از required کردن فیلدها خودداری کنید. برای مثال، نشانی‌ها در بسیاری از کشورها کد پستی ندارند و نشانی‌های روستایی ممکن است نام خیابان یا جاده نداشته باشند.
  • از نام‌گذاری فراگیر استفاده کنید: «کشور/منطقه» به‌جای «کشور»؛ «کد پستی» به‌جای «کد پستی (ZIP)».

انعطاف‌پذیر باشید! نمونه فرم نشانی ساده بالا را می‌توان برای بسیاری از مکان‌ها به‌گونه‌ای تطبیق داد که «به‌اندازه کافی خوب» کار کند.

توصیه می‌کنیم از جستجوی نشانی با کد پستی اجتناب کنید

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

پیشنهاد نشانی کد پستی برای همه کشورها کار نمی‌کند—و در برخی مناطق، کدهای پستی می‌توانند شامل تعداد زیادی نشانی احتمالی باشند.

کد پستی ممکن است شامل نشانی‌های زیادی باشد!

انتخاب از فهرست طولانی نشانی‌ها برای کاربران دشوار است—به‌ویژه در تلفن همراه اگر عجله داشته باشند یا تحت فشار باشند. اگر به کاربران اجازه دهید از تکمیل خودکار استفاده کنند، می‌توانند نشانی کاملشان را با یک ضربه یا کلیک وارد کنند و این کار آسان‌تر است و احتمال خطا در آن کمتر است.

ورودی نام تکی امکان وارد کردن نشانی با یک تک‌ضرب (یک کلیک) را فراهم می‌کند.

ساده کردن فرم‌های پرداخت

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

کمک به کاربران برای اجتناب از وارد کردن مجدد داده‌های پرداخت

مطمئن شوید مقادیر autocomplete مناسب را در فرم‌های کارت پرداخت اضافه کنید، ازجمله شماره کارت پرداخت، نام روی کارت، تاریخ انقضا، و کد امنیتی:

  • cc-number
  • cc-name
  • cc-exp، یا cc-exp-month و cc-exp-year برای فیلدهای جداگانه
  • cc-csc

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

از عناصر سفارشی برای تاریخ کارت پرداخت استفاده نکنید

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

فرم پرداخت عناصر سفارشی را برای تاریخ انقضای کارت نشان می‌دهد که تکمیل خودکار را قطع می‌کند.
«تکمیل خودکار» همه فیلدها را پر کرد—به‌جز تاریخ انقضا!

استفاده از یک ورودی برای کارت پرداخت و شماره تلفن

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

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

بادقت اعتبارسنجی کنید

باید ورودی داده را هم به‌صورت هم‌زمان و هم قبل‌از ارسال فرم اعتبارسنجی کنید. یکی از راه‌های انجام این کار، افزودن مشخصه pattern به ورودی کارت پرداخت است. اگر کاربر سعی کند فرم پرداخت را با مقدار نامعتبر ارسال کند، مرورگر پیام هشداری نمایش می‌دهد و روی ورودی تمرکز می‌کند. به جاوا اسکریپت نیاز نیست!

بااین‌حال، عبارت باقاعده pattern شما باید به‌اندازه کافی انعطاف‌پذیر باشد تا بتواند طیف طول شماره کارت پرداخت را مدیریت کند: از ۱۴ رقم (یا احتمالاً کمتر) تا ۲۰ رقم (یا بیشتر). می‌توانید درباره ساختار شماره کارت پرداخت در LDAPwiki اطلاعات بیشتری کسب کنید.

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

آزمایش روی طیفی از دستگاه‌ها، پلاتفرم‌ها، مرورگرها، و نسخه‌ها

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

فرم پرداخت در iPhone 7 و 11. دکمه «تکمیل پرداخت» در iPhone 11 نشان داده می‌شود اما در iPhone 7 نشان داده نمی‌شود
همان صفحه در iPhone 7 و iPhone 11.
حاشیه داخلی را برای دریچه‌های دید کوچک‌تر تلفن همراه کاهش دهید تا مطمئن شوید دکمه تکمیل پرداخت پنهان نمی‌شود.

پیاده‌سازی Analytics و RUM

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

برای این کار به تجزیه‌وتحلیل و «پایش کاربر واقعی» نیاز دارید—داده‌هایی برای تجربه کاربران واقعی، مانند مدت‌زمان بار شدن صفحه‌های تسویه‌حساب یا مدت‌زمان تکمیل پرداخت:

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

تجزیه‌وتحلیل صفحه، تجزیه‌وتحلیل تعامل، و اندازه‌گیری عملکرد کاربر واقعی به‌ویژه زمانی ارزشمند می‌شوند که با گزارش‌های سرور، داده‌های تبدیل، و آزمایش A/B ترکیب شوند و به شما امکان دهند به سؤالاتی مانند اینکه آیا کدهای تخفیف درآمد را افزایش می‌دهند یا اینکه آیا تغییر در چیدمان فرم تبدیل‌ها را بهبود می‌بخشد، پاسخ دهید.

این امر به‌نوبه خود مبنایی محکم برای اولویت‌بندی تلاش‌ها، ایجاد تغییرات، و پاداش دادن به موفقیت‌ها دراختیارتان قرار می‌دهد.

ادامه دادن یادگیری