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

بیشتر موکاپ‌ها صفحه را در حالت «خوشحال» نشان می‌دهند: داده هست، همه چیز موفق است، کاربر ایده‌آل. واقعیت محصول پر از لحظه‌هایی است که هنوز داده‌ای نیست، درخواست شکست خورده، یا سیستم در حال انتظار است. Empty State، Error State و Loading State نام همین حالت‌های غیرخوشحال‌اند که اگر طراحی نشوند، UI زیبا در تولید مضحک یا ترسناک به نظر می‌رسد.

Nielsen Norman Group دربارهٔ empty state می‌نویسد فضای خالی پیش‌فرض نباید فقط خالی بماند؛ می‌تواند وضعیت سیستم را بگوید، یادگیری را بالا ببرد، و مسیر شروع کار را نشان دهد. همین منطق به خطا و بارگذاری هم سرایت می‌کند: سکوت سیستم اعتماد را می‌خورد.

این مقاله تعریف هر حالت، اصول طراحی، نمونه‌ها، و جاگذاری در فرآیند تیم را می‌دهد.

پاسخ کوتاه

Empty State وقتی است که ظرف یا صفحه هنوز محتوایی برای نمایش ندارد (حساب تازه، فیلتر بدون نتیجه، لیست پاک‌شده). Error State وقتی است که عمل یا بارگذاری شکست خورده یا ورودی نامعتبر است. Loading State وقتی است که نتیجه هنوز نیامده و باید انتظار مدیریت شود.

طراحی این سه، بخشی از UX و UI است نه «بعداً». بدون آن‌ها کاربر نمی‌داند سیستم مرده، خالی است، یا کند. با آن‌ها می‌توانید اضطراب را کم کنید و اقدام بعدی را روشن بگذارید.

صفحهٔ خالی بدون راهنما باگ تجربه است؛ حتی اگر API درست ۲۰۰ برگرداند.

Empty State: فرصت نه شرمساری

طبق NN/g، empty state می‌تواند: ۱) وضعیت را بگوید، ۲) کشف قابلیت را بالا ببرد، ۳) میان‌بر به کار کلیدی بدهد. خالی ماندن محض توسعه را سریع‌تر می‌کند ولی اعتماد و یادگیری را می‌زند.

• اولین استفاده: «هنوز پروژه‌ای نیست» + دکمهٔ ساخت پروژه.
• نتیجهٔ جستجوی صفر: توضیح فیلتر + پاک کردن فیلتر.
• مجوز ناکافی: شفاف بگویید چرا خالی است و از چه کسی دسترسی بخواهد.
• پایان لیست واقعی: «همه را دیدید» تا با خطای بارگذاری اشتباه نشود.

از سرزنش («هیچ کاری نکرده‌اید!») بپرهیزید. لحن باید دعوت باشد نه نمرهٔ انضباط.

Error State: راهنما در شکست

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

• قابل‌درک برای انسان؛ کد فنی در جزئیات یا لاگ.
• غیرسرزنش‌گر: «رمز نادرست است» به‌جای «اشتباه وارد کردید دوباره».
• قابل‌اقدام: تلاش دوباره، تغییر ورودی، تماس پشتیبانی، وضعیت سیستم.
• پایدار: با اسکرین ریدر و صفحه‌کلید قابل درک.

Loading State: مدیریت انتظار

کاربر در انتظار، مدل ذهنی می‌سازد: آیا کلیک ثبت شد؟ باید دوباره بزند؟ Skeleton، progress، و غیرفعال کردن دکمهٔ ارسال تکراری از دوباره‌کاری و دادهٔ تکراری جلوگیری می‌کند. web.dev تأکید می‌کند سرعت بخشی از تجربه است؛ وقتی کندی اجتناب‌ناپذیر است، بازخورد صادقانه آسیب را کم می‌کند.

• برای کمتر از حدود ۳۰۰ms شاید نیازی به اسپینر نباشد (چشمک آزاردهنده).
• برای انتظار طولانی‌تر: اسکلتون هم‌ساختار با محتوا بهتر از اسپینر عمومی است.
• عمل مخرب: Progressive disable و پیام «در حال انجام…».
• اگر شکست خورد، به‌وضوح به Error State بروید نه اسکلتون ابدی.

جدول مقایسه

حالت‌های ترکیبی و لبه‌ها

Partial failure: بخشی از ویجت‌ها لود شده، یکی خطا. هر بلوک وضعیت خودش را نشان دهد تا کل صفحه قرمز نشود. Offline: پیام شبکه + محتوای کش‌شده اگر دارید. Permission: خالیِ دسترسی با مسیر درخواست. این لبه‌ها در محصولات B2B زیادند و باید در پروتوتایپ بیایند.

مالکیت در تیم

طراح ساختار و سلسله‌مراتب را می‌گذارد؛ Writer متن را؛ فرانت رفتار و زمان‌بندی را؛ بک‌اند کد خطا و خالی بودن معنایی را (فرق 200 خالی با 404 با 403). اگر API همیشه 200 با پیام رشته‌ای مبهم بدهد، UI نمی‌تواند معجزه کند.

چک‌لیست قبل از انتشار فیچر

1. فریم Empty برای اولین استفاده و برای صفر نتیجه.
2. فریم Error برای اعتبارسنجی و برای 5xx/شبکه.
3. فریم Loading برای اولین واکشی و برای اقدام ارسال.
4. متن نهایی فارسی، نه Lorem.
5. تست با throttling شبکه و با حساب تازه.

ضدالگوها

• اسپینر بی‌پایان بدون timeout.
• صفحهٔ سفید کامل بدون توضیح.
• Alert کلی برای هر خطای فیلد.
• Empty تزئینی بدون CTA.
• پیام موفقیت در حالی که عمل شکست خورده (خوش‌بینی دروغین).

ارتباط با اعتماد و ترک سایت

کاربر در حالت بلاتکلیف سریع می‌رود. مقالهٔ ۰۹۵ ترک را از زاویهٔ UX و عملکرد می‌بیند؛ حالت‌های سیستم همان نقطهٔ تماس اضطراب‌اند. سرمایه‌گذاری روی این فریم‌ها معمولاً ارزان‌تر از کمپین بازگردانی است.

الگوهای متنی آماده

Empty: «هنوز [آیتم] ندارید. اولین را بسازید تا [ارزش].» Error شبکه: «اتصال برقرار نشد. وضعیت اینترنت را بررسی کنید و دوباره تلاش کنید.» Error اعتبارسنجی: «[فیلد] را به صورت [قالب] وارد کنید.» Loading دکمه: همان برچسب + «…» یا اسپینر داخل دکمه با aria-busy.

الگو را در Design System و واژه‌نامه نگه دارید تا هر تیم دوباره اختراع نکند.

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

Empty، Error و Loading بخش اصلی محصول‌اند نه ضمیمه. آن‌ها وضعیت را می‌گویند، یادگیری می‌دهند، و از بن‌بست جلوگیری می‌کنند. در هر فیچر، سه فریم غیرخوشحال را مثل فریم خوشحال اجباری کنید و با شبکهٔ کند و حساب خالی بیازمایید.

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

منابع و مراجع

• Nielsen Norman Group — Designing Empty States in Complex Applications — https://www.nngroup.com/articles/empty-state-interface-design/
• Nielsen Norman Group — UX Writing: Study Guide — https://www.nngroup.com/articles/ux-writing-study-guide/
• web.dev — Why does speed matter? — https://web.dev/articles/why-speed-matters

برای فرم‌ها که پر از خطا و خالی‌اند، مقالهٔ ۰۹۴ مکمل است.