بهترین روشهای طراحی فرم: ۱۰ قانون برای وب و موبایل
۱۰ قانون برای طراحی فرمهایی که تبدیل میکنند. بررسی واقعی فرمهای ثبتنام Notion، Tally و Mercury، به علاوه الگوهای mobile-first که واقعاً کار میکنند.
بهترین روشهای طراحی فرم: ۱۰ قانون برای وب و موبایل
هزینه یک فرم بد
یک فرم بد یک مالیات استراتژیک بر هر دلاری است که برای آوردن کسی به صفحه خرج کردید. نرخ تکمیل فرمهای ثبتنام، پرداخت و آنبوردینگ به طور متوسط حدود ۱۲٪ است وقتی اصطکاک وجود دارد. اصطکاک را حذف کنید و این عدد از ۵۰٪ بالاتر میرود.
شکاف تقریباً هیچوقت به کپیرایتینگ یا برندینگ ربطی ندارد. به ده قانون مربوط است، که به شکل ثابت اعمال شوند.
فرمهای ۳۰ فیلدی به سبک Salesforce وجود دارند چون کسی یک طرح پایگاه داده را روی صفحه ریخت و اسمش را فرم گذاشت. کاربر برای این چیز ثبتنام نکرده بود. او برای محصول آمده بود، و منطق واجد شرایط بودن شما lead را از دست داد.
قانون ۱: یک ستون، یک کار در هر صفحه
یک ستون، همیشه. چیدمانهای چند ستونی در grid طراحی Figma کارآمد به نظر میرسند و نرخ تکمیل را روی صفحه میکشند.
چشم از چپ به راست میخواند و انتظار پیوستگی دارد. وقتی فیلدها در دو ستون تقسیم میشوند، کاربر باید تصمیم بگیرد کدام مسیر را دنبال کند، و آن تصمیم لحظهای اصطکاک ایجاد میکند قبل از اینکه یک کاراکتر تایپ کرده باشند.
فرم ثبتنام Notion یک ستون مرکزی با یک فیلد در هر لحظه روی موبایل است. فرم سریع به نظر میرسد چون یک چیز میخواهد. این قانون است.
قانون ۲: موقعیت label بیشتر از سبک label اهمیت دارد
Labelها بالای فیلد میروند. نه داخل آن، نه کنار آن. بالا، همیشه قابل مشاهده.
متن placeholder که به عنوان label استفاده میشود لحظهای که کاربر شروع به تایپ میکند ناپدید میشود. در آن مرحله باید فیلد را پاک کنند تا به یاد بیاورند چه چیزی پر میکنند. فرم آنبوردینگ Mercury از labelهای دائمی بالای فیلد روی هر input استفاده میکند تا context هیچوقت در میانه پر کردن از دست نرود.
Floating labelها، که از موقعیت placeholder هنگام focus به بالا متحرک میشوند، یک میانه قابل قبول هستند، اما برای accessible بودن به کنتراست دقیق و زمانبندی مناسب نیاز دارند. وقتی شک دارید، label را بالا بگذارید و همانجا بگذارید بماند.
تحقیقات UX پشت موقعیتگذاری label به طور عمیق در راهنمای ما درباره روشهای تحقیق UX پوشش داده شده است.
قانون ۳: ترتیب فیلدها از واقعیت کاربر پیروی میکند، نه از طرح پایگاه داده
توالی فیلدهایتان باید با نحوه تفکر یک نفر درباره کار مطابقت داشته باشد، نه با نحوه ساختاردهی مهندسان به مدل داده.
یک فرم پرداخت که قبل از تأیید سبد خرید آدرس ارسال را میخواهد بار context را روی کاربر میگذارد. Stripe Checkout، مرجع کانونیک برای UX فرم hosted-checkout، فرم را در سه مرحله توالی میدهد:
- ایمیل (شما کی هستید)
- پرداخت (چطور پرداخت میکنید)
- آدرس (کجا میرود)
این توالیی است که یک انسان معقول در حضور فیزیکی استفاده میکرد. وقتی پایگاه داده ترتیب فیلد را تعیین میکند، فرمهایی میگیرید که قبل از کشور کد پستی میخواهند، یا قبل از نام شرکت عنوان شغلی.
قانون ۴: validation را inline انجام دهید، هرگز هنگام submit
فیلد را لحظهای که کاربر آن را ترک میکند validate کنید، نه وقتی submit میزنند.
Validation هنگام submit یعنی کاربر یک فرم ده فیلدی پر میکند، دکمه را میزند، و با دیواری از خطاهای قرمز روبرو میشود. هر خطا یک کار اصلاحی است، و هر کار اصلاحی ریسک از دست دادن آنها را دارد. Inline validation که روی blur فعال میشود، خطا را قبل از اینکه کاربر ادامه دهد نشان میدهد.
ورود به Apple ID فرمت ایمیل را روی blur validate میکند و قبل از فعال شدن دکمه submit در دسترس بودن حساب را تأیید میکند. آن ترتیببندی از دو دسته خطا به یکباره جلوگیری میکند. الگوهای تعامل پشت این موضوع در راهنمای طراحی microinteraction ما پوشش داده شده است.
قانون ۵: mobile-first یعنی صفحهکلیدهای موبایل
هر نوع فیلد باید صفحهکلید صحیح را فراخوانی کند. این ۸۰٪ از طراحی فرم موبایل است.
اگر یک فیلد شماره تلفن میخواهد و صفحهکلید متن پیشفرض ظاهر میشود، فرم قبل از اینکه کاربر چیزی تایپ کند شکسته است. از inputmode="numeric" روی فیلدهای عددی استفاده کنید، type="email" برای نمایش کلید @، و inputmode="decimal" برای قیمتها. iOS و Android هر دو از کل محدوده حالتهای input پشتیبانی میکنند.
صفحهکلید دستگاه اصلی ورودی روی موبایل است. مشخص کردن اشتباه آن یک فرم بصری درست طراحی شده را به یک فرم ناامیدکننده تبدیل میکند.
| نوع فیلد | ویژگی HTML صحیح |
|---|---|
| ایمیل | type="email" |
| تلفن | type="tel" |
| عدد صحیح | inputmode="numeric" |
| اعشاری / قیمت | inputmode="decimal" |
| URL | type="url" |
| جستجو | inputmode="search" |
برای پایه گستردهتر mobile-first که این الگوها در آن قرار دارند، اصول طراحی وب ریسپانسیو را ببینید.
قانون ۶: پیشرفت، microcopy، و مشکل فرمهای طولانی
اگر فرم بیشتر از پنج فیلد نیاز دارد، به کاربر نشان دهید کجای جریان هستند.
فرم رزرو چند مرحلهای Airbnb در طول مسیر یک progress indicator با مراحل نامگذاری شده نشان میدهد. کاربرانی که میتوانند ببینند ۶۰٪ مسیر را طی کردهاند، به طور قابل اندازهگیری بیشتر از کاربرانی که هیچ نقطه مرجعی ندارند کار را تمام میکنند.
Tally برای فرمهای embeddable خود رویکرد متفاوتی اتخاذ میکند: یک سوال در یک لحظه با یک progress bar دائمی در بالا، که به طور مستمر در تست کاربری مستند شده آنها از فرمهای تک صفحهای طولانی بهتر عمل میکند.
Microcopy همین کار را انجام میدهد. "مرحله ۲ از ۴" صادقانهتر از یک progress bar ساده است. "ما به این برای تأیید هویت شما نیاز داریم" از یک فیلد حساس بدون label مفیدتر است.
قانون ۷: پیامهای خطا دستورالعمل هستند، نه اتهام
پیامهای خطا را به صیغه امری بنویسید، نه اتهام.
"این فیلد الزامی است" یک اتهام است. "آدرس ایمیل خود را برای ادامه وارد کنید" یک دستورالعمل است. کاربر از قبل میداند چیزی اشتباه رفته. آنچه نیاز دارند راهحل است.
بهترین کپی خطا شرط دقیق و اقدام دقیق را نام میبرد: "رمز عبور باید حداقل ۸ کاراکتر باشد و یک عدد شامل باشد." Stripe Checkout این را دقیقاً انجام میدهد. پیام روی blur ظاهر میشود، مشکل را نام میبرد، و لحظهای که شرط برطرف میشود ناپدید میشود.
هیچ وضعیت قرمز طولانی وجود ندارد. فقط کار میکند.
قانون ۸: Autofill یک ویژگی است، نه یک فکر بعدی
ویژگی autocomplete به مرورگر دقیقاً میگوید چه چیزی پر کند. از آن روی هر فیلد استفاده کنید.
یک فرم پرداخت با ویژگیهای autocomplete صحیح حدود ۱۲ ثانیه روی یک تلفن با داده ذخیره شده تکمیل میشود. بدون آنها، همان فرم دو دقیقه طول میکشد چون کاربر همه چیز را دستی تایپ میکند. آن شکاف ۱۰۸ ثانیهای جایی است که بیشتر رها شدن پرداخت موبایل اتفاق میافتد، و بستن آن هیچ هزینهای ندارد. راهنمای کتابخانه کامپوننت UI نحوه قرار دادن این ویژگیها را در کامپوننتهای فرم سیستم طراحی پوشش میدهد تا هیچوقت گم نشوند.
| فیلد | مقدار autocomplete |
|---|---|
| ایمیل | email |
| نام | given-name |
| نام خانوادگی | family-name |
| تلفن | tel |
| آدرس خیابان | street-address |
| شهر | address-level2 |
| کد پستی | postal-code |
| شماره کارت | cc-number |
| انقضای کارت | cc-exp |
قانون ۹: دکمه submit همه چیز را تصمیم میگیرد
دکمه submit قرارداد است. label، state، و موقعیت آن نشان میدهد آیا کاربر میتواند به اتفاقی که بعد میافتد اعتماد کند.
یک دکمه خاکستری بدون توضیح به کاربر میگوید فرم شکسته است اما نمیگوید چرا. این یک بنبست است. یک دکمه با برچسب "Submit" به کاربر هیچچیز درباره آنچه موافقت میکنند نمیگوید.
"حساب من را بساز"، "آزمایش رایگان من را دریافت کن"، و "شروع به ساختن" همه صادقانهتر هستند. دکمه را فقط وقتی غیرفعال کنید که بتوانید دلیل را در UI توضیح دهید. Tally از کپی دکمه مخصوص اقدام در هر مرحله در form builder خود استفاده میکند، و این مستقیماً به نرخ تکمیل بالاتر از متوسط آنها برای جریانهای B2B embedded کمک میکند.
قانون ۱۰: با انگشت شست واقعی، داده واقعی، تأخیر واقعی تست کنید
تست یک فرم روی مرورگر دسکتاپ با wifi سریع هیچ اطلاعات معناداری درباره اینکه آیا کار میکند به شما نمیدهد.
روی یک دستگاه Android میانرده با اتصال 4G با دادههای واقعی در هر فیلد تست کنید:
- یک نام با کاراکتر لهجهدار
- یک آدرس با شماره آپارتمان در خط دوم
- یک ایمیل ۲۲ کاراکتری
- یک نام ۱ کاراکتری
موارد لبه دنیای واقعی فرمهایی را که در Figma تمیز به نظر میرسند میشکنند. تأخیر واقعی نشان میدهد آیا validation calls ورودی را مسدود میکنند یا به صورت async اجرا میشوند. آن تمایز در یک شبیهساز مرورگر نامرئی است و روی تلفنی با دو نوار سیگنال فاجعهبار است.
برای audit فرم ثبتنام، پرداخت یا آنبوردینگ خود نیاز دارید؟ Brainy audit کامل ده قانونه را روی صفحههای واقعی، داده واقعی، و اعداد تبدیل واقعی اجرا میکند.
جایی که طراحان هنوز بدترین فرمها را ارسال میکنند
بدترین فرمهای موجود در تولید امروز سه الگو مشترک دارند:
- فرمهای lead فروش سازمانی: صفحههای واجد شرایط ۳۰ فیلدی به سبک Salesforce با انتخابگرهای اجباری "درآمد سالانه" و بدون inline validation
- جریانهای آنبوردینگ چند مرحلهای که پیشرفت را ذخیره نمیکنند: یک تماس تلفنی در مرحله ۷ از ۹ کاربر را به مرحله ۱ برمیگرداند
- جریانهای پرداخت که قبل از اینکه موبایل اصلی شود ساخته شدند، هرگز بازسازی نشدند: هر فیلد عددی هنوز از
type="text"استفاده میکند چون "روی دسکتاپ خوب کار میکند"
انتخابهای وضعیت خطا در هر سه مورد نیز تمایل دارند با نیازمندیهای کنتراست شکست بخورند؛ الگوهای کنتراست رنگ accessible آن نقطه شکست خاص را برطرف میکنند.
نخ مشترک در هر سه: فرم برای سیستم طراحی شد، نه برای کسی که آن را پر میکند. راهحل یکسان است.
ده قانون را اجرا کنید. با موبایل شروع کنید. بگذارید پایگاه داده طرح خودش را مرتب کند.
سوالات متداول
یک فرم باید چند فیلد داشته باشد؟
به اندازهای که نتیجه نیاز دارد. تعداد درست تعداد فیلدهایی است که با حذف یک فیلد دیگر محصول میشکند. هر فیلدی که اضافه میکنید نرخ تکمیل را کاهش میدهد. از صفر شروع کنید و فقط چیزی را اضافه کنید که اجباری است.
باید از فرمهای چند مرحلهای یا تک صفحهای استفاده کنم؟
برای بیشتر از پنج فیلد، چند مرحلهای تقریباً همیشه از تک صفحهای بهتر عمل میکند. الزام نشان دادن پیشرفت است. بدون آن، فرمهای چند مرحلهای بدتر از تک صفحهای عمل میکنند چون کاربر هیچ ایدهای از طولانی بودن مسیر ندارد. مراحل را نام ببرید و نشان دهید کجای توالی هستند.
بهترین روش برای علامتگذاری فیلدهای اجباری چیست؟
فیلدهای اختیاری را علامت بزنید، نه اجباری را. اگر اکثر فیلدها اجباری هستند (که باید باشند، با توجه به قانون بالا)، علامتگذاری هر فیلد با ستاره قرمز نویز بصری است.
استثناها را علامت بزنید. "اختیاری" کنار یک فیلد اطلاعات معناداری است. یک ستاره کنار هر فیلد نیست.
چطور با نیازمندیهای رمز عبور بدون تنبیه کاربر کنار بیایم؟
نیازمندیها را قبل از اینکه کاربر شروع به تایپ کند نشان دهید، نه بعد از اینکه شکست خوردند. یک checklist کوچک که با برآورده شدن هر شرط فعال میشود بهتر از دیوار خطای post-submit عمل میکند. Apple ID و اکثر جریانهای auth فعلی از این الگو استفاده میکنند. بازخورد زنده، مثبت، و هرگز تنبیهی نیست.
آیا عرض فیلد چیزی را منتقل میکند؟
بله، و کاربران آن را میخوانند. عرض فیلد طول ورودی مورد انتظار را نشان میدهد. یک فیلد کوتاه یک پاسخ کوتاه را نشان میدهد. یک فیلد با عرض کامل یک پاسخ طولانیتر را نشان میدهد.
عرض فیلد را با طول ورودی مورد انتظار مطابقت دهید اگر چیدمان اجازه میدهد. یک فیلد کد پستی با عرض کامل شبیه یک اشتباه است. یک text area برای آدرس خیابان شبیه افراط است. container را با content مورد انتظار مطابقت دهید.
چه چیزی بیشترین رها شدن فرم موبایل را ایجاد میکند؟
نوع صفحهکلید اشتباه شماره یک است. کار نکردن autofill شماره دو است. هر دو شکستهای خاموش هستند: فرم درست به نظر میرسد، کاربر فقط نمیتواند آن را به طور کارآمد تکمیل کند.
هر دو را با دو ویژگی در هر فیلد برطرف کنید. سرمایهگذاری ۱۵ دقیقه است. بازگشت در تبدیل پرداخت در همان sprint قابل اندازهگیری است.
Need a form audit on your sign-up, checkout, or onboarding flow? Brainy runs the full ten-rule audit on real screens, real data, and real conversion numbers.
Get Started
