صفحه Settings جایی است که کاربر رفتار برنامه، حساب یا نمایش را با نیازش هماهنگ می‌کند. این صفحه نباید انبار گزینه‌هایی باشد که در مسیر اصلی جایی پیدا نکرده‌اند. هر تنظیم باید دامنه، اثر و روش ذخیره روشن داشته باشد. اگر کاربر نداند تغییر فقط روی همین دستگاه است یا برای تمام حساب اعمال می‌شود، حتی یک کنترل ساده می‌تواند نتیجه ناخواسته بسازد. طراحی از تعریف همین قرارداد شروع می‌شود و نه از انتخاب شکل Switch.
برای مثال فرضی، برنامه مدیریت پروژه‌ای تنظیم زبان، اعلان و دسترسی تیم دارد. زبان رابط شاید ترجیح شخصی باشد، اعلان به حساب مربوط شود و دسترسی اعضا فقط در اختیار مدیر تیم باشد. جمع کردن این‌ها در یک فهرست بدون توضیح، مسئولیت را مبهم می‌کند. کاربر باید بداند اکنون کدام بخش را تغییر می‌دهد و چه کسانی از نتیجه تأثیر می‌گیرند. تفاوت حساب، پروژه و دستگاه در ساختار و متن صفحه اهمیت دارد.
دامنه تنظیم را پیش از گروه‌بندی مشخص کنید
برای هر گزینه، مالک، محل ذخیره و اثر را بنویسید. آیا تغییر فوراً اعمال می‌شود؟ آیا در دستگاه دیگر هم دیده می‌شود؟ آیا مدیر می‌تواند آن را محدود کند؟ در مثال، خاموش کردن اعلان شخصی نباید پیام ضروری همه اعضای تیم را متوقف کند. این تعریف به پیاده‌سازی و متن کمک می‌کند. اگر رفتار محصول هنوز مشخص نیست، یک توضیح کوتاه در رابط جای تصمیم واقعی را نمی‌گیرد.
گزینه‌های شخصی و مدیریتی را با عنوان روشن جدا کنید. اگر دسترسی لازم وجود ندارد، علت و مسیر درخواست را توضیح دهید و اطلاعات حساس را نمایش ندهید. وجود دکمه غیرفعال به‌تنهایی علت محدودیت را روشن نمی‌کند. تقسیم مسئولیت تیم از نظر نقش و اختیار مرتبط است. صفحه Settings باید همین مرزها را در سطح محصول ترجمه کند تا کاربر از روی ظاهر، اختیار اشتباه برداشت نکند.
گروه‌ها را با زبان کاربر نام‌گذاری کنید
حساب، نمایش، اعلان و امنیت می‌توانند شروع باشند، اما دسته‌ها باید با مدل ذهنی محصول سازگار باشند. نام داخلی سرویس یا اصطلاح معماری برای کاربر کافی نیست. گزینه‌های مرتبط را کنار هم بگذارید و تعداد عنوان‌های مشابه را کم کنید. اگر صفحه طولانی است، ناوبری یا جست‌وجوی تنظیمات ممکن است مفید باشد. جست‌وجو جای ساختار روشن را نمی‌گیرد؛ کاربر نباید نام دقیق گزینه را از قبل بداند تا آن را پیدا کند.
در مثال، تنظیم اعلان ایمیل و اعلان داخل برنامه شاید زیر یک گروه باشند، ولی باید تفاوت کانال و موضوع معلوم شود. گزینه‌ای مانند «اعلان فعال» خیلی کلی است؛ کاربر نمی‌داند چه پیامی و کجا دریافت می‌کند. واژه‌ها را در کل محصول یکسان نگه دارید. ساختار اطلاعات و Wireframe برای بررسی این گروه‌بندی و مسیر پیدا کردن گزینه مرتبط‌اند.
کنترل را براساس نوع تصمیم انتخاب کنید
Switch برای وضعیت روشن یا خاموش مناسب است، به‌ویژه وقتی اثر آن فوری و قابل فهم است. Checkbox می‌تواند انتخابی در مجموعه یا فرم باشد. Radio برای یک انتخاب از چند گزینه و Select برای بعضی فهرست‌ها مناسب‌اند. این‌ها قانون ظاهری نیستند؛ رفتار و تعداد گزینه‌ها را ببینید. حذف حساب یا تغییر مالکیت، یک ترجیح ساده نیست و نباید مثل روشن کردن حالت تاریک نمایش داده شود.
الگوی Switch در W3C APG وضعیت و رفتار صفحه‌کلید آن را توضیح می‌دهد. نام کنترل باید ثابت و روشن بماند تا وضعیت جدا فهمیده شود. تغییر برچسب همراه با روشن و خاموش شدن می‌تواند ابهام بسازد. کاربرد درست Toggle به جزئیات این تصمیم مرتبط است. شکل ظاهری مشابه، رفتار معنایی یکسان را تضمین نمی‌کند.
ذخیره فوری و دکمه ذخیره را مخلوط نکنید
اگر همه تغییرها با دکمه ذخیره ثبت می‌شوند، کاربر باید وضعیت ذخیره‌نشده را بفهمد. اگر هر گزینه فوراً اعمال می‌شود، بازخورد همان موقع لازم است. ترکیب این دو روش در یک صفحه بدون مرز روشن، کاربر را نامطمئن می‌کند. در مثال زبان، ممکن است تغییر رابط فوراً دیده شود اما ثبت حساب شکست بخورد؛ ظاهر تازه نباید به معنای ذخیره موفق تلقی شود. قرارداد ذخیره باید با رفتار واقعی سرور هماهنگ باشد.
برای ذخیره غیرهم‌زمان، وضعیت در حال ثبت، موفق و خطا را نشان دهید. کلیک تکراری نباید درخواست متناقض بسازد. اگر تغییر نرسید، گزینه را به وضعیت قبلی برگردانید یا وضعیت نامعلوم را روشن کنید. راهنمای اعلان فرم W3C بر پیام روشن و راه اصلاح تأکید دارد. جمله «ذخیره شد» فقط زمانی درست است که ثبت واقعاً تأیید شده باشد.
پیش‌فرض را با نیاز و حریم خصوصی هماهنگ کنید
کاربر ممکن است هیچ‌وقت صفحه تنظیمات را باز نکند، بنابراین پیش‌فرض بر تجربه اثر زیادی دارد. برای اعلان، جمع‌آوری داده یا اشتراک محتوا، نیاز و پیامد را بررسی کنید. گزینه‌ای که داده را عمومی می‌کند نباید پشت عنوان مبهم پنهان شود. این مقاله قانون عمومی رضایت برای همه کشورها تعیین نمی‌کند؛ نوع داده و حوزه فعالیت مهم‌اند. در طراحی، پیش‌فرض و توضیح باید با سیاست واقعی و انتخاب آگاهانه سازگار باشند.
برای ترجیح نمایش مانند Theme، استفاده از تنظیم سیستم می‌تواند گزینه‌ای باشد، اما کاربر باید بتواند انتخاب را بفهمد و در صورت امکان تغییر دهد. مقدار «خودکار» را توضیح دهید که از چه چیزی پیروی می‌کند. اگر تنظیم از سیاست سازمان آمده، آن را به‌عنوان انتخاب شخصی قابل تغییر نمایش ندهید. تفاوت مقدار پیش‌فرض، مقدار فعلی و مقدار تحمیل‌شده را حفظ کنید تا کاربر علت رفتار محصول را بفهمد.
تغییر پرریسک را از ترجیح معمولی جدا کنید
حذف داده، لغو اشتراک یا خروج از همه دستگاه‌ها اثر متفاوتی دارند. متن باید نتیجه، دامنه و امکان برگشت را روشن کند. برای اقدام برگشت‌ناپذیر، تأیید متناسب می‌تواند لازم باشد؛ اما هر تغییر کوچک را با دیالوگ متوقف نکنید. تأیید تکراری ممکن است به عادت کلیک بدون خواندن برسد. ریسک را واقعی بسنجید و از رنگ به‌تنهایی برای هشدار استفاده نکنید.
اگر امکان Undo وجود دارد، زمان و نتیجه آن را توضیح دهید. بازنشانی همه تنظیمات نیز باید بگوید کدام مقدارها عوض می‌شوند و کدام داده باقی می‌ماند. تجربه فرم برای پیام و تأیید مرتبط است. دکمه «بازنشانی» بدون زمینه می‌تواند تنظیم شخصی یا کل پروژه را تداعی کند؛ دامنه را در عنوان و توضیح روشن نگه دارید.
موبایل، صفحه‌کلید و ترجمه را در نظر بگیرید
کنترل کوچک یا توضیحی که فقط با Hover دیده می‌شود، در موبایل مشکل می‌سازد. برچسب و توضیح باید رابطه روشن با کنترل داشته باشند. ترتیب حرکت صفحه‌کلید، حالت Focus و اعلام وضعیت اهمیت دارند. برای متن فارسی، راست‌به‌چپ بودن نباید معنای روشن و خاموش یا ترتیب گزینه‌ها را مبهم کند. Mobile First و نوشتار فارسی به این مرحله مرتبط‌اند.
عنوان و توضیح را با متن نزدیک به واقعیت ببینید تا طول ترجمه کنترل را از جای خود خارج نکند. اگر یک گزینه فقط در بعضی دستگاه‌ها کار می‌کند، محدودیت را بگویید. پنهان شدن ناگهانی تنظیم بدون دلیل، پیگیری مشکل را سخت می‌کند. راهنمای پشتیبانی باید بداند مقدار از کجا می‌آید و چه چیزی بر آن اولویت دارد. صفحه Settings بخشی از سیستم رفتار محصول است، نه فقط مجموعه‌ای از کنترل‌های مستقل.
اگر مقدار در چند دستگاه تغییر می‌کند، وضعیت آخرین ثبت و تعارض را در طراحی در نظر بگیرید. کاربر نباید پس از بازگشت ببیند انتخابش بدون توضیح عوض شده است. روش حل تعارض باید با معماری محصول و انتظار اعلام‌شده هماهنگ بماند.
با پرسش‌های واقعی صفحه را بازبینی کنید
ببینید کاربر می‌تواند گزینه مورد نیاز را پیدا کند، اثر آن را پیش‌بینی کند و از ذخیره شدن مطمئن شود یا نه. تعداد کلیک تنها معیار کافی نیست. سؤال‌های تکراری پشتیبانی و تغییرهای ناخواسته می‌توانند نشانه ابهام باشند. تعریف شاخص کمک می‌کند سنجش به هدف وصل بماند. از یک گروه روشن و قرارداد ذخیره مشخص شروع کنید و گزینه تازه را فقط وقتی اضافه کنید که نیاز واقعی دارد.
هنوز دیدگاهی ثبت نشده
اولین نفری باشید که نظر می‌دهد!