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