کاربر صفحه پروژه‌ها را باز می‌کند و چیزی نمی‌بیند. آیا هنوز پروژه‌ای نساخته، فیلترها همه نتایج را پنهان کرده‌اند یا دریافت اطلاعات شکست خورده است؟ هر سه حالت ممکن است یک فضای خالی بسازند، اما پاسخ درست به آن‌ها یکسان نیست. اگر برای همه بنویسیم «موردی وجود ندارد»، کاربر باید خودش علت را حدس بزند.
Empty State یا حالت خالی، بخشی از تجربه محصول است که توضیح می‌دهد چرا محتوای مورد انتظار دیده نمی‌شود و در صورت نیاز، مسیر بعدی را نشان می‌دهد. این وضعیت فقط مخصوص اولین ورود نیست؛ بعد از جست‌وجو، حذف آخرین آیتم، پایان کارها یا نداشتن دسترسی هم ممکن است رخ دهد. طراحی آن از تشخیص علت شروع می‌شود، نه انتخاب یک تصویر بامزه.
اول علت خالی‌بودن را پیدا کنید
در طراحی یک صفحه، به‌جای یک تصویر نهایی، وضعیت‌های مختلف داده را بنویسید. محتوا هنوز دریافت نشده، با موفقیت دریافت شده اما فهرست خالی است، به‌خاطر فیلتر دیده نمی‌شود یا درخواست خطا داده است؟ این تفاوت باید در قرارداد طراحی و توسعه روشن باشد. خالی‌بودن یک آرایه در لحظه آغاز درخواست، به‌تنهایی دلیل نمایش پیام «پروژه‌ای ندارید» نیست.
راهنمای Empty States در Carbon نیز میان نبود داده، وضعیت حاصل از عمل کاربر و مشکلاتی مانند خطا یا دسترسی تفاوت می‌گذارد. استفاده از یک الگوی بصری مشترک ممکن است، اما متن و اقدام باید با همان علت هماهنگ باشند. کاربر تازه‌وارد به ساخت اولین آیتم نیاز دارد؛ کسی که جست‌وجو کرده، شاید فقط لازم باشد یک فیلتر را بردارد.
برای نمونه فرضی یک ابزار مدیریت پروژه، پنج وضعیت ثبت کنید: هنوز هیچ پروژه‌ای ساخته نشده، جست‌وجو نتیجه ندارد، همه کارها انجام شده‌اند، دریافت اطلاعات شکست خورده و کاربر اجازه مشاهده ندارد. کنار هر وضعیت بنویسید چه چیزی معلوم است، چه چیزی معلوم نیست و چه کاری واقعاً در اختیار کاربر قرار دارد. همین فهرست، جلوی بسیاری از پیام‌های گمراه‌کننده را می‌گیرد.
شروع کار: محتوای آینده را توضیح دهید
در اولین استفاده، کاربر ممکن است هنوز نداند این صفحه برای چیست. عنوان «هنوز پروژه‌ای ندارید» وضعیت را روشن می‌کند و توضیح «پروژه‌های شما پس از ساخت اینجا نمایش داده می‌شوند» نقش صفحه را می‌گوید. اگر کاربر امکان ساخت دارد، دکمه «ساخت پروژه» او را مستقیم به همان جریان ببرد. مجبورکردن او به پیدا کردن مسیر در چند منو، راهنمایی را نیمه‌کاره می‌گذارد.
یک آموزش کوتاه می‌تواند مفید باشد، اما همه قابلیت‌های محصول را در این فضای خالی معرفی نکنید. کاربر برای شروع یک کار مشخص آمده است. اگر فرایند پیچیده‌تر است، یک لینک راهنمای مرتبط کنار اقدام اصلی کافی است. عنوان‌های تبلیغاتی مثل «ماجراجویی هیجان‌انگیزت را آغاز کن» در یک پنل کاری معمولاً اطلاعات کمتری از «اولین پروژه را بسازید» منتقل می‌کنند.
اگر نمونه آماده ارائه می‌کنید، مشخص کنید داده نمونه است. کاربر باید بداند چیزی که می‌بیند پروژه واقعی خودش نیست و بتواند آن را کنار بگذارد. پرکردن صفحه با داده ساختگی بدون این توضیح، ممکن است باعث شود او فکر کند حسابش قبلاً استفاده شده است. نمونه باید فهم ساختار را آسان کند، نه مالکیت داده را مبهم.
بدون نتیجه: مسیر جست‌وجو را حفظ کنید
بعد از جست‌وجو، «هیچ پروژه‌ای ندارید» پیام درستی نیست؛ شاید پروژه‌ها وجود دارند اما با عبارت فعلی مطابقت ندارند. پیام دقیق‌تر می‌تواند بگوید «برای این عبارت نتیجه‌ای پیدا نشد». عبارت جست‌وجو و فیلترهای فعال را نگه دارید تا کاربر ببیند چه چیزی را تغییر دهد. پاک‌کردن خودکار همه انتخاب‌ها، هم علت را پنهان می‌کند و هم تلاش قبلی او را از بین می‌برد.
اگر محدودیت از فیلترهاست، دکمه «پاک کردن فیلترها» باید همان فیلترها را بردارد. درباره باقی‌ماندن عبارت جست‌وجو تصمیم روشنی داشته باشید؛ نام اقدام باید با نتیجه‌اش هماهنگ باشد. برای طراحی نمایش و حذف این انتخاب‌ها، راهنمای Tag و Label System کمک می‌کند رفتار برچسب‌های فعال را مشخص کنید.
پیشنهاد جایگزین زمانی ارزش دارد که مرتبط و واقعی باشد. اگر موتور جست‌وجو قابلیت پیشنهاد عبارت دارد، می‌توان آن را نشان داد. در غیر این صورت، وعده «جست‌وجوی هوشمند» نسازید و فقط راه‌های موجود مثل کوتاه‌کردن عبارت یا حذف یک فیلتر را توضیح دهید. همچنین نتایج نامرتبط را بدون برچسب زیر عنوان نتیجه جست‌وجو قرار ندهید.
پایان کار همیشه به دکمه نیاز ندارد
فهرست کارهای امروز خالی است چون همه انجام شده‌اند. این وضعیت با نساختن هیچ کاری فرق دارد. پیام «همه کارهای امروز انجام شده‌اند» نتیجه را تأیید می‌کند و ممکن است به اقدام دیگری نیاز نداشته باشد. افزودن دکمه «کار جدید بسازید» فقط برای اینکه صفحه خالی نماند، می‌تواند با هدف استراحت یا پایان کار تعارض داشته باشد.
همین منطق برای صندوق پیام یا هشدارها هم کاربرد دارد. نبود هشدار لزوماً نقص نیست. اگر تنظیمات هشدار فعال است و اتفاقی رخ نداده، می‌توان وضعیت را به‌سادگی توضیح داد. اگر هنوز تنظیمی انجام نشده، پیام دیگری لازم است. پیش از نوشتن متن، از تیم بپرسید «خالی بودن در این صفحه نشانه موفقیت است، شروع است یا مشکل؟»
خطا، نبود داده و نداشتن دسترسی را یکی نکنید
اگر دریافت اطلاعات شکست خورده، نگویید «چیزی وجود ندارد». معلوم نیست فهرست واقعاً خالی باشد. عنوان «دریافت اطلاعات انجام نشد» صادقانه‌تر است. اگر تلاش دوباره ممکن است، آن را پیشنهاد کنید؛ اگر مشکل نیاز به اقدام دیگری دارد، مسیر واقعی را توضیح دهید. دکمه Retry که بارها همان خطا را بدون هیچ بازخوردی تکرار می‌کند، راه‌حل کامل نیست.
وقتی بخشی از صفحه قبلاً داده دارد، درباره حفظ آن تصمیم بگیرید. در یک بروزرسانی ناموفق، شاید بتوان داده قبلی را همراه با توضیح تازگی آن نگه داشت. این بهتر از ناپدیدشدن بی‌دلیل کل صفحه است، ولی تنها وقتی درست است که کاربر بفهمد اطلاعات تازه نشده‌اند. داده قدیمی را با ظاهر نتیجه موفق جدید نمایش ندهید.
برای نبود دسترسی، ساخت آیتم یا تلاش دوباره معمولاً کمکی نمی‌کند. پیام می‌تواند بگوید «برای مشاهده این بخش دسترسی لازم را ندارید» و اگر محصول فرایند درخواست دسترسی دارد، همان مسیر را ارائه کند. وجود داده محرمانه یا نام منابعی را که کاربر مجاز به دیدنشان نیست، در متن راهنما افشا نکنید. توضیح باید به حل مسئله کمک کند، نه جزئیات نامربوط را بازگو کند.
متن را با یک سؤال و یک پاسخ روشن بسازید
عنوان باید بگوید چه اتفاقی افتاده است. توضیح کوتاه، علت یا محتوای مورد انتظار را روشن کند. اقدام اصلی هم باید کاری را نام ببرد که بعد از انتخاب رخ می‌دهد. این ترتیب را با یک مثال ببینید: «هنوز فایلی اضافه نشده»؛ «فایل‌های این پروژه بعد از بارگذاری اینجا نمایش داده می‌شوند»؛ «بارگذاری فایل». این پیام از «خالی است؛ ادامه دهید» دقیق‌تر است.
در لحن، کاربر را مقصر فرض نکنید. «شما هیچ اطلاعاتی وارد نکرده‌اید» ممکن است درست باشد، اما «هنوز اطلاعاتی ثبت نشده» همان وضعیت را با لحن آرام‌تری می‌گوید. با این حال، نرم‌کردن متن نباید علت را حذف کند. در خطاهای جدی، شوخی و تصویر طنز می‌توانند تجربه نامناسبی بسازند. لحن را با اهمیت کار و شرایط کاربر هماهنگ کنید.
نام دکمه را مستقل از پاراگراف هم قابل فهم نگه دارید. «شروع» و «بریم» برای همه جریان‌ها روشن نیستند؛ «افزودن عضو» یا «ساخت پروژه» نتیجه را توضیح می‌دهند. اگر تنها راه فعلی خواندن راهنماست، آن را به‌عنوان راهنما معرفی کنید، نه دکمه‌ای که وانمود کند مستقیماً مشکل را برطرف می‌کند.
تصویر اختیاری است؛ خوانایی ضروری
در صفحه بزرگ، یک تصویر مرتبط می‌تواند به تشخیص وضعیت کمک کند. در یک کارت کوچک داشبورد، همان تصویر ممکن است فضای متن و دکمه را بگیرد. لازم نیست همه Empty Stateها تصویر داشته باشند. اگر چند بخش صفحه هم‌زمان خالی‌اند، تکرار چند تصویر بزرگ و چند دکمه پررنگ می‌تواند توجه را پراکنده کند. اولویت بصری را بر اساس کار اصلی صفحه نگه دارید.
پیام را در محدوده همان محتوایی قرار دهید که دیده نمی‌شود. اگر فقط جدول نتیجه خالی است، عنوان صفحه، جست‌وجو و فیلترهای لازم برای تغییر نتیجه باید همچنان قابل استفاده باشند. تصویر وسط کل صفحه نباید ابزارهای اصلاح وضعیت را دور از دسترس کند. فضای مناسب و گروه‌بندی متن و اقدام، از پرکردن ناحیه با عناصر تزئینی مهم‌تر است.
برای فارسی، عنوان طولانی و متن دوجهته را با عرض واقعی ببینید. در موبایل، دکمه باید قابل دسترس بماند و توضیح به سطرهای بسیار باریک تبدیل نشود. راهنمای تایپوگرافی فارسی و طراحی Mobile First به این تصمیم‌ها کمک می‌کنند. وسط‌چین‌کردن همه متن‌ها هم قاعده عمومی نیست؛ تراز مناسب را با طول نوشته و ساختار صفحه انتخاب کنید.
دسترس‌پذیری را در تغییر وضعیت حفظ کنید
اگر نتیجه جست‌وجو بدون بارگذاری صفحه تغییر می‌کند، کاربر صفحه‌خوان هم باید از نتیجه باخبر شود. معیار Status Messages در WCAG درباره قابل تشخیص بودن پیام‌های وضعیت برای فناوری کمکی، بدون نیاز به انتقال Focus، توضیح می‌دهد. پیام «نتیجه‌ای پیدا نشد» می‌تواند بسته به پیاده‌سازی یک پیام وضعیت باشد؛ انتخاب نقش یا Live Region را با نوع پیام هماهنگ کنید.
همه پیام‌ها را با اعلان فوری و شدید منتشر نکنید. جست‌وجوی زنده که با هر حرف متن طولانی می‌خواند، می‌تواند مزاحم باشد. همچنین Focus را بعد از هر تغییر به تیتر Empty State نبرید؛ کاربر شاید هنوز در حال تایپ یا انتخاب فیلتر باشد. کنترل‌های مربوط باید نام روشن، مسیر کیبورد و نشانه Focus قابل تشخیص داشته باشند.
اگر تصویر فقط تزئینی است و اطلاعاتش در متن آمده، در پیاده‌سازی رابط آن را برای صفحه‌خوان تکرار نکنید. اگر اطلاعات مستقل دارد، باید جایگزین متنی مناسب داشته باشد. پیام اصلی را داخل فایل تصویر قرار ندهید؛ متن واقعی امکان بزرگ‌نمایی، ترجمه و استفاده با ابزارهای کمکی را بهتر فراهم می‌کند.
قرارداد Empty State را همراه کامپوننت تحویل دهید
برای هر وضعیت، شرط نمایش، عنوان، توضیح، اقدام و نتیجه آن را ثبت کنید. مشخص کنید چه کسی مجاز به انجام اقدام است و در نبود مجوز چه متنی دیده می‌شود. Loading، Error و Empty را در نمونه‌ها جدا نگه دارید. اگر کامپوننت مشترک می‌سازید، جای تصویر و اقدام را اختیاری کنید تا تیم مجبور نباشد برای همه موقعیت‌ها اجزای اضافی بسازد.
در یک نمونه واقعی، حذف آخرین آیتم، جست‌وجوی بدون نتیجه و خطای دریافت را جدا مرور کنید. آیا کاربر علت را می‌فهمد؟ آیا اقدام همان کاری را می‌کند که نامش می‌گوید؟ آیا اطلاعات قبلی بی‌دلیل از دست می‌روند؟ Empty State خوب لازم نیست کاربر را همیشه به کاری دعوت کند؛ باید وضعیت را روشن کند و هر جا قدم بعدی مفید و ممکن است، آن را در دسترس بگذارد.
هنوز دیدگاهی ثبت نشده
اولین نفری باشید که نظر می‌دهد!