Future ForgeFuture ForgeFuture ForgeFuture Forge
خدماتنمونه‌کارهاپکیج‌هایادداشت‌هادرباره ماتماس
شروع پروژه
  1. خانه
  2. /یادداشت‌ها
Future ForgeFuture Forge

استودیوی مهندسی محصول — طراحی، ساخت و استقرار نرم‌افزار.

پروژه‌تان را مطرح کنید

ارتباط

hello@futureforge.ir09128464105
Future ForgeFuture Forge

استودیوی مهندسی محصول — طراحی، ساخت و استقرار نرم‌افزار.

خدمات

طراحی و ساخت محصولتوسعه فول‌استکممیزی مهندسیمشاوره معماریزیرساخت و استقرارهوش مصنوعی در محصول

کاوش

نمونه‌کارهایادداشت‌هاپرسش‌هاپکیج‌ها

ابزارهای رایگان

ممیزی مهندسیمشاور معماریتخمین پروژهابزار پرامپت

شرکت

درباره ماتماس

پروژه‌تان را مطرح کنید

مسئله و محدودیت را بنویسید. اگر تطابق داشته باشیم، برای گفتگو هماهنگ می‌کنیم.

پروژه‌تان را مطرح کنید

ارتباط

hello@futureforge.ir09128464105
GitHubLinkedIn

© 2026 FutureForge. همه حقوق محفوظ است.

خانهخدماتنمونه‌کارهاشروع پروژه
مهندسی محصول

فرم‌های خوب چگونه طراحی می‌شوند؟

اصول طراحی فرم وب بر اساس NN/g: برچسب پایدار، یک ستون، خطای مشخص، کاهش بار شناختی، و پرهیز از placeholder مضر.

سا
سهیل ابراهیم‌پور

بنیان‌گذار و مهندس محصول

·۱۵ شهریور ۱۴۰۵·5 دقیقه مطالعه
طراحی فرم خوبform UXplaceholderخطای فرمکاهش cognitive loadusability فرم

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

Nielsen Norman Group در توصیه‌های usability فرم‌های وب و مقالات بعدی دربارهٔ placeholder و بار شناختی، اصولی تکرارشونده دارد: برچسب بیرون فیلد و همیشه可见، چیدمان منطقی، شفافیت نیازمندی‌ها، و پیام خطای مشخص با نشانه‌های چندگانه نه فقط رنگ.

این مقاله اصول، ضدالگوها، و چک‌لیست انتشار را برای تیم‌های وب جمع می‌کند.

پاسخ کوتاه

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

Placeholder به‌جای برچسب مضر است چون با تایپ ناپدید می‌شود و حافظه را درگیر می‌کند. NN/g صریحاً توصیه می‌کند برچسب و راهنمای مهم بیرون فیلد بماند. چهار اصل ساختار، شفافیت، وضوح و پشتیبانی چارچوب مفیدی برای کاهش بار شناختی‌اند.

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

چهار اصل کاهش بار شناختی (NN/g)

  1. Structure: مسیر تکمیل منطقی و گروه‌بندی مرتبط.
  2. Transparency: از اول بگویید چه لازم است و تقریباً چقدر طول می‌کشد.
  3. Clarity: ابهام در برچسب و فرمت نگذارید.
  4. Support: راهنمای به‌موقع، پیشگیری از خطا، کمک هنگام اشتباه.

این چهار کلمه را بالای بکلاگ فرم بنویسید؛ بحث سلیقه را کوتاه می‌کند.

چیدمان و ساختار

  • ترجیح یک ستون؛ چند ستون جریان عمودی را می‌شکند (جز فیلدهای کوتاه مرتبط مثل شهر/کدپستی در صورت تناسب).
  • برچسب نزدیک فیلد مربوط؛ فاصلهٔ گروه‌ها بیشتر از فاصلهٔ برچسب-فیلد.
  • اقدام اصلی واضح؛ Cancel اگر لازم است کم‌رنگ‌تر از Submit.
  • از Reset/Clear پیش‌فرض بپرهیزید؛ ریسک پاک شدن تصادفی بالاست.

NN/g در «Website Forms Usability» همین توصیه‌ها را به‌عنوان نقطهٔ شروع می‌دهد و می‌گوید انحراف باید دلیل داشته باشد.

برچسب، راهنما، Placeholder

برچسب بیرون فیلد بماند. راهنمای فرمت (مثلاً نمونه تاریخ) هم بیرون و پایدار. Placeholder را برای مثال مکمل استفاده کنید فقط اگر برچسب جدا دارید؛ و حتی آن را برای اطلاعات حیاتی به کار نبرید. الگوی floating label بهتر از نبود برچسب است ولی باز هم راهنمای طولانی را جایگزین نمی‌کند.

خطاها و اعتبارسنجی

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

خطاهای سرور را از اعتبارسنجی جدا کنید و در Error State مناسب نشان دهید.

جدول تصمیم فیلد

سؤالاگر بلهاگر خیر
بدون این داده ارزش تحویل‌دادنی نیست؟فیلد اجباریحذف یا مرحلهٔ بعد
می‌توانیم از حساب/سیستم پر کنیم؟پیش‌پر کردنپرسیدن از کاربر
فرمت حساس است؟ماسک/نمونه بیرون فیلدآزادی ورودی با نرمال‌سازی
داده حساس است؟HTTPS، حداقل نگهداشت، توضیح چرانپرسید

فرم‌های چندمرحله‌ای

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

موبایل و دسترس‌پذیری

  • نوع صفحه‌کلید مناسب (email, tel, numeric).
  • هدف لمس کافی؛ فاصلهٔ بین کنترل‌ها.
  • label مرتبط با input؛ خطا با aria زنده.
  • ترتیب فوکوس منطقی؛ تلهٔ فوکوس در modal درست.

WCAG و MDN برای این لایه مرجع‌اند؛ فرم غیرقابل‌صفحه‌کلید یعنی حذف بخشی از کاربران.

ضدالگوهای رایج

  • اجبار ساخت حساب قبل از دیدن قیمت.
  • فیلدهای بازاریابی اختیاریِ پیش‌تیک‌خورده.
  • CAPTCHA سخت بدون جایگزین دسترس‌پذیر.
  • پرسیدن دوبارهٔ داده‌ای که کاربر刚 داده.
  • پیام موفقیت در حالی که ذخیره نشده.

اندازه‌گیری

نرخ شروع/اتمام، رها کردن هر فیلد (اگر ابزار دارید)، زمان تکمیل، و دلیل تیکت پشتیبانی. بهبود را با حذف فیلد یا وضوح برچسب نسبت به تغییر رنگ دکمه مقایسه کنید؛ اغلب حذف برنده است.

همکاری حقوقی و امنیت

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

چک‌لیست انتشار فرم

  1. فهرست فیلدها با justification.
  2. برچسب و راهنما بیرون فیلد.
  3. حالت‌های خالی/خطا/لود دکمه.
  4. تست موبایل و صفحه‌کلید.
  5. بازنویسی پیام‌ها با Writer یا مالک محتوا.
  6. لاگ خطا برای تشخیص مشکل واقعی کاربر.

جمع‌بندی برای تصمیم

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

این هفته یک فرم پرت cocoon رها شدن را باز کنید؛ یک فیلد غیرضروری حذف و سه پیام خطا را بازنویسی کنید.

منابع و مراجع

  • Nielsen Norman Group — Website Forms Usability: Top 10 Recommendations — https://www.nngroup.com/articles/web-form-design/
  • Nielsen Norman Group — Placeholders in Form Fields Are Harmful — https://www.nngroup.com/articles/form-design-placeholders/
  • Nielsen Norman Group — Few Guesses, More Success: 4 Principles to Reduce Cognitive Load in Forms — https://www.nngroup.com/articles/4-principles-reduce-cognitive-load/

برای متن خطا و CTA به ۰۹۱–۰۹۲ برگردید.

نویسنده

سا

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

یادداشت‌های مرتبط

یادداشت‌های مرتبط

دسته‌بندی‌ها

خدمات مرتبط

از یادداشت تا پروژه

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

اگر در انتخاب معماری یا مسیر توسعه مطمئن نیستید، می‌توانید درباره پروژه صحبت کنیم.

مسئله و محدودیت را بنویسید. اگر تطابق داشته باشیم، برای گفتگو هماهنگ می‌کنیم.

سهیل ابراهیم‌پور
یادداشت‌ها
چرا کاربران بعضی سایت‌ها را سریع ترک می‌کنند؟
Empty State، Error State و Loading State چیست؟
چرا متن بد می‌تواند حتی یک UI زیبا را خراب کند؟
UX Writing چیست و چرا متن‌های سایت بخشی از تجربه کاربری هستند؟
UX مهم‌تر است یا UI؟

مهندسی محصول

چرا کاربران بعضی سایت‌ها را سریع ترک می‌کنند؟

۱۵ شهریور ۱۴۰۵

مهندسی محصول

Empty State، Error State و Loading State چیست؟

۱۵ شهریور ۱۴۰۵

مهندسی محصول

چرا متن بد می‌تواند حتی یک UI زیبا را خراب کند؟

۱۵ شهریور ۱۴۰۵

مهندسی محصول

UX Writing چیست و چرا متن‌های سایت بخشی از تجربه کاربری هستند؟

۱۵ شهریور ۱۴۰۵

مهندسی محصول

UX مهم‌تر است یا UI؟

۱۵ شهریور ۱۴۰۵
همه یادداشت‌ها40
معماری نرم‌افزار3
واژه‌نامه1
عملیات و استقرار4
مهندسی محصول25
راهنمای وب7
طراحی و ساخت محصول
توسعه فول‌استک
ممیزی مهندسی
مشاوره معماری
زیرساخت و استقرار
پروژه‌تان را مطرح کنید
ابزارهای رایگان
پروژه‌تان را مطرح کنید