برای طراحی فرم درخواست خدمات، فقط اطلاعاتی را بخواهید که بدون آن‌ها نمی‌توانید درخواست را بفهمید یا پیگیری کنید. در یک فرم شروع همکاری، معمولاً یک راه ارتباطی و موضوع درخواست ضروری‌اند؛ نام، نشانی سایت، بودجه و توضیحات باید بر اساس کاربرد واقعی‌شان اجباری، اختیاری یا به گفت‌وگوی بعدی منتقل شوند.
فرم خوب با زدن دکمه ارسال تمام نمی‌شود. کاربر باید بتواند در موبایل راحت آن را پر کند، خطا را بفهمد و بعد از ارسال بداند درخواستش ثبت شده و قدم بعدی چیست.
اول مشخص کنید فرم قرار است چه کاری انجام دهد
«شروع گفت‌وگو»، «دریافت برآورد قیمت» و «ثبت سفارش قطعی» سه هدف متفاوت‌اند:
- شروع گفت‌وگو: اطلاعات مختصر برای شناخت موضوع و برقراری ارتباط.
- برآورد قیمت: اطلاعات کافی درباره محدوده کار و عوامل مؤثر بر هزینه.
- ثبت سفارش قطعی: جزئیات لازم برای انجام خدمت و تعهدات دو طرف.
جمع‌کردن همه این اطلاعات در اولین تماس، فرم را بی‌دلیل سنگین می‌کند.
قبل از چیدن فیلدها، این جمله را کامل کنید:
بعد از دریافت فرم، مسئول پیگیری باید بتواند …
مثلاً: «موضوع درخواست را تشخیص دهد و برای روشن‌کردن نیاز با متقاضی تماس بگیرد.»
اگر هدف همین است، احتمالاً دریافت نشانی پستی، نام حقوقی شرکت و فایل کامل شرح پروژه در این مرحله ضرورتی ندارد.
این نگاه، فرم را به بخشی از مسیر کاربر تبدیل می‌کند. برای شناخت این مسیر، مقاله طراحی تجربه کاربری چیست؟ راهنمای پایه برای طراحی UX را بخوانید.
کدام فیلدها واقعاً لازم‌اند؟
برای هر سؤال، سه پرسش مطرح کنید: چه کسی از پاسخ استفاده می‌کند؟ چه تصمیمی با آن می‌گیرد؟ آیا همین حالا لازم است؟
اگر پاسخ روشنی ندارید، فعلاً آن سؤال را حذف کنید. راهنمای طراحی سؤال در GOV.UK نیز بر دانستن دلیل هر سؤال و درخواست اطلاعات واقعاً ضروری تأکید دارد.
| فیلد | پیشنهاد برای شروع همکاری | شرط استفاده |
| نام | اغلب اختیاری | برای خطاب‌کردن مفید است؛ معمولاً نام کامل شناسنامه‌ای لازم نیست. |
| راه ارتباطی | ضروری | یک مسیر قابل پیگیری کافی است؛ تلفن و ایمیل را بی‌دلیل هم‌زمان اجباری نکنید. |
| نوع خدمت | وابسته به صفحه | در فرم عمومی برای ارجاع درخواست مفید است؛ در صفحه اختصاصی خدمت، موضوع را نمایش دهید و دوباره نپرسید. |
| توضیح مسئله | اختیاری یا ضروریِ کوتاه | اگر انتخاب خدمت برای پیگیری کافی است، اختیاری؛ برای بررسی یک مسئله مشخص، توضیح کوتاه می‌تواند ضروری باشد. |
| نشانی سایت | وابسته به خدمت | برای بررسی سایت موجود کاربرد دارد؛ برای ساخت سایت جدید نباید مانع ارسال شود. |
| بودجه و موعد اجرا | مشروط | وقتی در پذیرش یا اولویت‌بندی اولیه اثر دارند؛ با امکان اعلام «هنوز مشخص نیست»، اگر این پاسخ پذیرفتنی است. |
| فایل و اطلاعات حقوقی | معمولاً مرحله بعد | زمانی دریافت شوند که بررسی یا انجام کار واقعاً به آن‌ها وابسته باشد. |
این جدول، پیشنهاد طراحی برای تماس اولیه است؛ نسخه ثابت همه کسب‌وکارها نیست. مثلاً یک مجموعه خدمات حضوری ممکن است بدون دانستن شهر نتواند درخواست را بپذیرد. در آن حالت، شهر فیلدی ضروری است.
سؤال اختیاری هم باید کاربرد داشته باشد
اختیاری‌کردن همه سؤال‌های اضافی، مشکل شلوغی فرم را حل نمی‌کند. سؤال بدون کاربرد را حذف کنید و کنار فیلدهای باقی‌مانده، «اختیاری» را واضح بنویسید.
همچنین کاربر همیشه پاسخ دقیق ندارد. اگر برای شروع همکاری لازم نیست نوع خدمت یا بودجه را قطعی بداند، گزینه «هنوز مطمئن نیستم» یا «هنوز مشخص نیست» را در نظر بگیرید. پذیرش پاسخ نامشخص، وقتی پاسخ معتبری است، در راهنمای GOV.UK هم توصیه شده است.
چیدمان فرم را برای خواندن و پاسخ‌دادن طراحی کنید
برای یک فرم کوتاه، چیدمان تک‌ستونه نقطه شروع مناسبی است: عنوان، توضیح مختصر، سؤالها و سپس دکمه ارسال. چند ستون صرفاً برای کوتاه‌تر دیده‌شدن فرم، می‌تواند مسیر خواندن را پیچیده کند.
برچسب فیلد را همیشه در دسترس نگه دارید
برچسب هر فیلد را بالای آن قرار دهید؛ متن نمونه داخل کادر جای برچسب را نمی‌گیرد. با شروع تایپ، کاربر همچنان باید بداند چه چیزی وارد می‌کند.
برچسب باید برای فناوری‌های کمکی نیز به ورودی مربوط متصل باشد. راهنمای برچسب‌گذاری W3C توضیح می‌دهد که این ارتباط چگونه به شناسایی درست کنترل‌های فرم کمک می‌کند.
توضیح کمکی هم بهتر است کوتاه و مشخص باشد. مثلاً زیر «توضیح درخواست» بنویسید: «کدام صفحه یا کار برای کاربر مشکل دارد؟» این سؤال، پاسخ‌دادن را از یک کادر خالی با عنوان مبهم «پیام» آسان‌تر می‌کند.
نوع انتخاب را با سؤال هماهنگ کنید
برای چند خدمت محدود، گزینه‌های قابل مشاهده را امتحان کنید:
- اگر فقط یک انتخاب مجاز است، از انتخاب تک‌گزینه‌ای استفاده کنید.
- اگر چند خدمت هم‌زمان پذیرفته می‌شود، انتخاب چندگزینه‌ای لازم دارید.
- اگر خدمت از صفحه مشخص است، همان را نمایش دهید و سؤال تکراری نپرسید.
آیکون می‌تواند به تشخیص گزینه‌ها کمک کند، اما نام خدمت باید کنار آن خوانا باشد.
دکمه اصلی باید نتیجه عمل را روشن کند
در فرم تماس اولیه، «ارسال درخواست» عمل پیش رو را مشخص می‌کند. عبارت‌هایی مانند «تأیید» ممکن است معلوم نکنند کاربر دقیقاً چه چیزی را تأیید می‌کند.
دکمه باید در چیدمان به‌وضوح دیده شود و وضعیت فعال، فوکوس و در حال ارسال آن مشخص باشد. برای ادامه این موضوع، راهنمای طراحی دکمه سایت را ببینید.
وایرفریم فرم کوتاه با حالت خطا و موفقیت
مثال زیر فرضی است: یک مجموعه خدمات دیجیتال، درخواست تماس اولیه دریافت می‌کند و امکان پاسخ‌گویی تلفنی یا ایمیلی دارد. نام و توضیح اختیاری‌اند؛ موضوع و یک راه ارتباطی برای پیگیری لازم‌اند.
این سه حالت برای آموزش هستند؛ امکان ورود اطلاعات یا ارسال ندارند.
حالت اول: فرم آماده تکمیل
| جایگاه | محتوای فرم |
| عنوان | درخواست بررسی خدمات |
| راهنمای کوتاه | موضوع و راه ارتباط را مشخص کنید تا درخواست را پیگیری کنیم. نام و توضیح اختیاری‌اند. |
| ورودی نام | نام «اختیاری» |
| انتخاب خدمت | طراحی سایت / سئو و محتوا / بهبود تجربه کاربری / هنوز مطمئن نیستم |
| روش پاسخ‌گویی | ایمیل / تماس تلفنی |
| ورودی ارتباط | ایمیل؛ با انتخاب تماس تلفنی، این فیلد به شماره تماس تغییر می‌کند. |
| توضیح کمکی | برای پیگیری همین درخواست استفاده می‌شود. |
| کادر چندخطی | توضیح کوتاه «اختیاری»؛ کدام صفحه یا کار برای کاربر مشکل دارد؟ |
| دکمه اصلی | ارسال درخواست |
اگر مجموعه فقط یک مسیر پاسخ‌گویی دارد، انتخاب روش را حذف کنید و همان مسیر را شفاف نشان دهید. انتخابی که تیم امکان انجامش را ندارد، نباید در فرم باشد.
حالت دوم: خطای ورودی
فرض کنید کاربر ایمیل را به‌صورت mina@ وارد کرده است.
| محل نمایش | وضعیت |
| بالای فرم | درخواست ارسال نشد؛ ایمیل را بررسی کنید. |
| فیلد ایمیل | مقدار واردشده باقی می‌ماند و کادر مشخص می‌شود. |
| زیر فیلد ایمیل | ایمیل را کامل وارد کنید؛ مانند name@example.com |
| سایر فیلدها | پاسخها بدون تغییر حفظ می‌شوند. |
| دکمه | ارسال درخواست |
کاربر باید بتواند مستقیماً به فیلد مشکل‌دار برسد، آن را اصلاح کند و دوباره ارسال کند.
حالت سوم: ثبت موفق
پس از تأیید ثبت درخواست، فرم جای خود را به پیام روشن می‌دهد:
درخواست شما ثبت شد.
موضوع: بهبود تجربه کاربری
پاسخ را به ایمیل واردشده می‌فرستیم.
فعلاً نیازی به ارسال دوباره نیست.
در نسخه اجرایی، بازه پاسخ‌گویی واقعی و مسیر پیگیری نیز به این پیام اضافه می‌شود. وعده زمانی باید با ظرفیت تیم هماهنگ باشد؛ عددی صرفاً برای کامل‌شدن طراحی ننویسید.
خطا باید مسیر اصلاح را نشان دهد
«اطلاعات نامعتبر است» به کاربر نمی‌گوید چه کاری انجام دهد. پیام مفید، فیلد مشکل‌دار و روش اصلاح را مشخص می‌کند. طبق راهنمای بازخورد فرم W3C، پیام‌های خطا باید روشن و کوتاه باشند و به رفع مشکل کمک کنند.
برای این فرم، بررسی ورودی‌ها هنگام تلاش برای ارسال نقطه شروع مناسبی است. اگر بررسی زودتر انجام می‌شود، کاربر را هنگام نوشتن یک ورودی ناتمام با هشدار مکرر متوقف نکنید.
در طراحی خطا این موارد را لحاظ کنید:
- پیام کنار فیلد مربوط دیده شود.
- اگر چند خطا وجود دارد، خلاصه‌ای بالای فرم با امکان رفتن به فیلدها نمایش داده شود.
- رنگ قرمز تنها نشانه خطا نباشد؛ توضیح متنی هم لازم است.
- پاسخ‌های صحیح حفظ شوند.
- پیام‌ها با صفحه‌کلید و صفحه‌خوان قابل دسترسی باشند.
خطای سرویس را هم از اشتباه کاربر جدا کنید. وقتی سامانه نمی‌تواند درخواست را ثبت کند، نمایش پیام «ایمیل نامعتبر است» کاربر را به اصلاح چیزی هدایت می‌کند که مشکلی ندارد.
هنگام ارسال و بعد از آن چه اتفاقی بیفتد؟
در زمان پردازش، وضعیت «در حال ارسال…» را نشان دهید و جلوی ارسال تکراری را بگیرید. پیام موفقیت فقط پس از تأیید ثبت درخواست ظاهر شود.
اگر ارتباط قطع شد و وضعیت ثبت معلوم نیست، همین ابهام را توضیح دهید؛ موفقیت یا شکست قطعی اعلام نکنید.
بعد از ثبت، موضوع درخواست، روش پاسخ‌گویی و زمان واقعی پیگیری را روشن کنید. اگر کد پیگیری وجود دارد، نشانش دهید. این ساختار با الگوی تأیید نهایی GOV.UK هم‌راستاست که بر توضیح قدم بعدی و زمان آن تأکید دارد.
فرم فارسی در موبایل چه ملاحظاتی دارد؟
نسخه موبایل را با واردکردن اطلاعات واقعی آزمایش کنید؛ کوچک‌کردن پنجره مرورگر به‌تنهایی کافی نیست.
- جهت متن: برچسب‌ها و توضیحات راست‌به‌چپ باشند؛ ایمیل، شماره و نشانی وب با جهت متناسب نمایش داده شوند تا ترتیب کاراکترها به‌هم نریزد.
- صفحه‌کلید مناسب: برای تلفن و ایمیل، صفحه‌کلید مناسب باز شود و چسباندن متن یا تکمیل خودکار بی‌دلیل محدود نشود.
- پذیرش شماره: ارقام فارسی و لاتین و قالب‌های مورد پشتیبانی را آزمایش کنید. محدودیت کشور یا فرمت را پیش از خطا توضیح دهید.
- لمس راحت: کل برچسب گزینه قابل لمس باشد؛ کاربر مجبور نباشد دایره‌ای کوچک را دقیق لمس کند.
- دیده‌شدن کنترل‌ها: بازشدن صفحه‌کلید، بزرگ‌کردن متن و نمایش خطا نباید دکمه یا فیلد فعال را پشت عناصر ثابت پنهان کند.
- شفافیت استفاده از اطلاعات: کاربرد اطلاعات تماس را کوتاه و مطابق واقعیت توضیح دهید. انتخاب دریافت پیام تبلیغاتی را با درخواست خدمت یکی نکنید.
چطور بفهمیم فرم بهتر شده است؟
از چند نفر نزدیک به مخاطب واقعی بخواهید با موبایل یک درخواست آزمایشی بفرستند. بدون راهنمایی نگاه کنید کجا مکث می‌کنند، کدام سؤال را نمی‌فهمند و آیا متوجه ثبت موفق می‌شوند.
یک ورودی اشتباه و یک اختلال ارسال را هم در محیط آزمایشی بررسی کنید.
بعد از انتشار، نرخ تکمیل را با تعریف ثابت بسنجید:
نرخ تکمیل فرم = تعداد ثبت‌های موفق ÷ تعداد شروع‌های یکتای فرم × ۱۰۰
کنار این شاخص، خطاهای پرتکرار، درخواست‌های قابل پیگیری و تفاوت موبایل و دسکتاپ را بررسی کنید. برای این سنجش، متن پیام، شماره و ایمیل کاربران را به ابزار تحلیل ارسال نکنید.
بیشترشدن تعداد فرم‌ها به‌تنهایی نشانه بهبود نیست؛ درخواست‌ها باید مرتبط و قابل پیگیری باشند. همچنین در مقایسه قبل و بعد، تغییر منبع ترافیک یا شرایط کمپین را در نظر بگیرید و هر تغییر را علت قطعی نتیجه ندانید.
پرسش‌های متداول
فرم درخواست خدمات چند فیلد داشته باشد؟
عدد ثابتی ندارد. معیار، اطلاعات لازم برای اقدام بعدی است. اگر یک سؤال در پیگیری اولیه کاربرد ندارد، حذفش کنید یا به مرحله بعد ببرید.
فرم کوتاه را چندمرحلهای کنیم؟
برای نمونه کوتاه این مقاله، یک صفحه نقطه شروع سادهتری است. چندمرحلهایکردن زمانی ارزش بررسی دارد که سؤالها زیاد، شاخهدار یا نیازمند تصمیمهای جداگانه باشند؛ با حفظ پاسخها و امکان بازگشت.
آیا آپلود فایل را اجباری کنیم؟
فقط اگر بررسی اولیه بدون فایل ممکن نیست. در غیر این صورت، دریافت آن را به ادامه گفت‌وگو منتقل کنید. اگر آپلود لازم است، نوع و حجم مجاز و وضعیت ارسال فایل از ابتدا روشن باشد.
آیا کاربر باید برای ارسال درخواست حساب بسازد؟
برای تماس اولیه معمولاً ضرورتی ندارد. اگر پیگیری امن چند درخواست یا دسترسی به مدارک به حساب وابسته است، دلیل آن را توضیح دهید و مرحله ساخت حساب را متناسب با همان نیاز طراحی کنید.
از سؤال‌های ضروری شروع کنید
برای اصلاح فرم، ابتدا هدف و کاربرد تک‌تک فیلدها را مشخص کنید؛ سپس چیدمان موبایل، اصلاح خطا و تأیید ثبت را طراحی و آزمایش کنید. فرم زمانی آماده است که کاربر بتواند درخواست را کامل کند و تیم شما هم اطلاعات کافی برای قدم بعدی داشته باشد.
برای بررسی تجربه کاربری با سبک‌تر، نشانی صفحه و مشکلی را که کاربر هنگام انجام کار دارد بفرستید.
توی این مقاله
برای طراحی سایت، بهتر دیده‌شدن یا تولید محتوا، از اینجا شروع کن.
