Future ForgeFuture ForgeFuture ForgeFuture Forge
ServicesWorkPackagesNotesAboutContact
Start
  1. Home
  2. /Notes
Future ForgeFuture Forge

Product engineering studio — design, build, and deploy software.

Discuss your project

Contact

hello@futureforge.ir09128464105
Future ForgeFuture Forge

Product engineering studio — design, build, and deploy software.

Services

Product engineeringFull-stack engineeringEngineering auditArchitecture consultingInfrastructure and deploymentAI in the product

Explore

WorkNotesFAQPackages

Free tools

Engineering auditArchitecture advisorProject estimatorPrompt tool

Company

AboutContact

Discuss your project

Describe the problem and the constraints. If there is a fit, we will schedule a conversation.

Discuss your project

Contact

hello@futureforge.ir09128464105
GitHubLinkedIn

© 2026 FutureForge. All rights reserved.

HomeServicesWorkStart
Product engineering

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

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

SE
Soheil Ebrahimpour

Founder & product engineer

·Sep 6, 2026·5 min read
طراحی فرم خوب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 به ۰۹۱–۰۹۲ برگردید.

Author

SE

Soheil Ebrahimpour is the founder of FutureForge. He works on product design, architecture, and getting custom software into production.

Related notes

Related notes

Categories

Related services

From note to project

If this topic is close to your product or system, we can talk about the real scope.

If you are unsure about architecture or the build path, we can talk about the project.

Describe the problem and the constraints. If there is a fit, we will schedule a conversation.

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

Product engineering

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

Sep 6, 2026

Product engineering

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

Sep 6, 2026

Product engineering

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

Sep 6, 2026

Product engineering

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

Sep 6, 2026

Product engineering

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

Sep 6, 2026
All notes40
Software architecture3
Glossary1
Operations4
Product engineering25
Web guide7
Product engineering
Full-stack engineering
Engineering audit
Architecture consulting
Infrastructure and deployment
Discuss your project
Free tools
Discuss your project