مشکل صفحه تنظیمات
صفحه تنظیمات جایی است که یکپارچگی محصول در آن جان می‌دهد. پنج کهن‌الگو، شش قانون، نمونه‌های واقعی از Linear، Notion و Vercel و یک ممیزی که می‌توانید با آن محصول را تحویل دهید.
صفحه تنظیمات صادق‌ترین صفحه محصول شماست. در یک اسکرول نشان می‌دهد تیم دقیقاً از گرفتن کدام تصمیم‌ها فرار کرده است. هر سوئیچ یک بحث فسیل‌شده است. هر تب تودرتو یک «بعداً درستش می‌کنیم» است که هیچ‌کس درستش نکرد.
بیشتر صفحه‌های تنظیمات زباله‌دانی‌اند. سه سال سوئیچ که مهندس‌هایی که نمی‌توانستند «نه» بگویند، مارکترهایی که یک گزینه انصراف می‌خواستند و PMهایی که «قابل تنظیمش کنیم» را جای «تصمیم بگیر» گذاشتند روی هم تلنبار کرده‌اند. نتیجه صفحه‌ای است که تیم از دمو دادنش خجالت می‌کشد و کاربر از دست زدن به آن می‌ترسد.
این نوشته دفاعی است از اینکه تنظیمات را یک سطح محصولی درجه‌یک بدانیم. پنج کهن‌الگو، شش قانون، نمونه‌های واقعی از محصولاتی که هر روز استفاده می‌کنید، و یک ممیزی برای اجرا پیش از انتشار.
تنظیمات صفحه‌ای است که تیم را لو می‌دهد
پراکندگی تنظیمات نشانه‌ای پیشرو از ناکارآمدی سازمانی است. وقتی تیم نمی‌تواند روی یک مقدار پیش‌فرض به توافق برسد، سوئیچ منتشر می‌شود. وقتی مشتری شکایت می‌کند و کسی نمی‌خواهد مقاومت کند، سوئیچ منتشر می‌شود. وقتی PM نمی‌تواند بین دو جریان یکی را انتخاب کند، هر دو پشت یک تنظیم منتشر می‌شوند.
شش ماه بعد هیچ‌کس یادش نیست نیمی از سوئیچ‌ها چرا وجود دارند. حذف یک تنظیم همان تصمیمی را می‌طلبد که تیم بار اول از آن طفره رفت، پس تنظیمات روی هم انباشته می‌شوند. به هر محصولی که بیش از سه سال است منتشر می‌شود نگاه کنید و تصمیم‌های نگرفته را در درخت تنظیماتش بشمارید.
پنج کهن‌الگوی صفحه‌های تنظیمات بد
صفحه‌های تنظیمات بد تصادفی نیستند. در پنج الگو می‌گنجند و هرکدام نقطه پایان نوعی خاص از تنبلی سازمانی است.
۱. زباله‌دان
انباشت زمانی. تنظیمات به ترتیب افزوده‌شدن ظاهر می‌شوند و هرگز گروه‌بندی نمی‌شوند. جدیدترین feature flag کنار یک ترجیح اعلان مال ۲۰۱۹ نشسته، کنار یک سوئیچ بتا که قرار بود دو سال پیش رسمی شود. Cursor دارد به این سمت سُر می‌خورد. هر نسخه سه سوئیچ به تب General اضافه می‌کند و حالا General یک اسکرول ۴۰ ردیفی از تصمیم‌های بی‌ربط است. زباله‌دان وضعیت پیش‌فرض هر صفحه تنظیماتی است که کسی فعالانه طراحی‌اش نمی‌کند.
۲. صفحه‌گسترده
ترجیحات الفبایی. تیم از سلسله‌مراتب دست کشیده و مرتب‌سازی را به سیستم‌عامل سپرده. هر سوئیچ وزن یکسان دارد و هر ردیف شبیه بقیه است. تنظیمات اعلان Slack اینجا زندگی می‌کند. صدا، نشان، موبایل، کانال، کلیدواژه، مزاحم نشوید، زمان‌بندی، سفارشی، همه در یک دیوار صاف بدون هیچ روایتی درباره اینکه کدام مهم است.
۳. بن‌بست
تنظیماتی که هیچ چیز دیدنی را تغییر نمی‌دهند. کاربر «Compact mode» را روشن می‌کند و صفحه عیناً همان می‌ماند. «Enable advanced features» را می‌زند و چیزی ظاهر نمی‌شود. بازطراحی System Settings در macOS از Apple نسلی از این‌ها تحویل داد: تنظیماتی که بی‌صدا توسط تنظیمات دیگر باطل می‌شوند، تنظیماتی که ریستارت می‌خواهند و صفحه هیچ‌وقت نمی‌گوید. بن‌بست به کاربر یاد می‌دهد تنظیمات کار نمی‌کنند و او به بقیه محصول هم اعتماد را از دست می‌دهد.
۴. هزارتو
ده سطح تب تودرتو. تنظیمات زیر یک دسته، یک زیردسته، یک بخش «Advanced» و یک مودال دفن شده‌اند. کاربر می‌داند آن سوئیچ هست، قبلاً هم زده، و باز پیدایش نمی‌کند. Jira قدیمی روی همین حرفه‌اش را ساخت: پروژه، برد، گردش‌کار، طرح، طرح مجوز، طرح اعلان، همه درخت‌های جدا.
۵. موزه
تنظیماتی که سه سال است کسی به آن‌ها دست نزده. باقی مانده‌اند چون حذفشان ریسکی به نظر می‌رسد. به قابلیت‌هایی اشاره می‌کنند که در ۲۰۲۳ بازنشسته شدند. هر محصول SaaS قدیمی یک جناح موزه دارد و هزینه‌اش تعهد تیم به نگهداری مسیرهای کدی است که باید دو رفکتور پیش کشته می‌شدند.
تنظیمات یک سطح محصولی است، نه انباری
بیشتر تیم‌ها تنظیمات را جایی می‌دانند که بقیه محصول در آن جمع‌وجور می‌شود. همین قاب‌بندی خودش باگ است. تنظیمات یکی از پراهرم‌ترین سطوح محصول است و قوی‌ترین تیم‌ها همین‌طور طراحی‌اش می‌کنند.
تنظیمات جهان‌بینی محصول درباره کاربر را بیان می‌کنند. چهار چیز را همزمان منتقل می‌کنند. تیم چقدر به کاربر اعتماد دارد. تیم حاضر است چقدر کنترل را با او تقسیم کند. تیم فکر می‌کند مقادیر پیش‌فرض درست چیست. و اینکه آیا تیم به وقت کاربر آن‌قدر احترام می‌گذارد که برای ۵٪ی که پیش‌فرض‌ها را تغییر می‌دهند طراحی کند، بی‌آنکه ۹۵٪ دیگر را تنبیه کند.
Linear تنظیمات را به‌صورت یک سطح جستجوی واحد طراحی کرد، با محوریت command-K و تقریباً بدون تب تودرتو. پیام ضمنی: کاربر شایسته است، جستجو سریع است و تیم کار سلسله‌مراتب را کرده تا کاربر مجبور نباشد. Notion مسیر مخالف را رفت و به همان شکل برنده شد. تنظیمات کنار چیزی هستند که روی آن اثر می‌گذارند. تنظیمات صفحه روی صفحه. تنظیمات دیتابیس روی دیتابیس. تنظیمات زمینه‌ای در دل کار محو می‌شوند.
Vercel از سلسله‌مراتب محدوده‌دار استفاده می‌کند: پروژه، تیم و حساب، هرکدام با برچسب روشن و محدود به منبعی که اداره می‌کنند. Stripe Dashboard اکشن‌محور است، جایی که هر صفحه «این کار را بکن» است، نه «این ترجیح را پیکربندی کن». تنظیمات مخزن GitHub محدوده را بی‌نقص اجرا می‌کند، با تفکیک تمیز مالکیت مخزن، سازمان و حساب.
شش قانونی که سرنوشت هر صفحه تنظیمات را تعیین می‌کنند
این قوانین روی هم اثر تجمعی دارند. پنج از شش را رعایت کنید و صفحه مثل یک سطح محصولی خوانده می‌شود. سه را رعایت کنید و ظرف یک سال به یکی از کهن‌الگوها سُر می‌خورد.
قانون ۱: اول جستجو
سلسله‌مراتب پشتیبان است، نه اصلی. کاربر نام تنظیم را می‌داند، پیش از آنکه بداند زیر کدام تب است. command-K در Linear تنظیمات را به‌عنوان یک نوع نتیجه درجه‌یک پوشش می‌دهد. Figma جستجوی تنظیمات اضافه کرد و زمان رسیدن به سوئیچ فوراً کم شد. اگر صفحه تنظیماتتان نوار جستجو ندارد، شرط بسته‌اید که کاربران معماری اطلاعات شما را حفظ کنند. نمی‌کنند.
قانون ۲: جایگذاری زمینه‌ای به‌جای ثبت‌خانه مرکزی
تنظیمات کنار چیزی هستند که روی آن اثر می‌گذارند. تنظیمات اعلان در پنل اعلان‌ها. تنظیمات صفحه روی صفحه. صفحه تنظیمات مرکزی برای مسائل سطح حساب مثل پروفایل، صورتحساب و نشست‌ها مناسب است و تقریباً هیچ چیز دیگر. Notion معیار طلایی است. پنل سمت راست Figma همین کار را برای ویژگی‌های لایه، فریم و کامپوننت انجام می‌دهد.
قانون ۳: پیش‌فرض‌های معقول که اعتماد می‌سازند
هر پیش‌فرض یک تصمیم محصولی است. بیان می‌کند تیم باور دارد پاسخ درست برای ۸۰٪ کاربران چیست. اگر پیش‌فرض غلط باشد، سوئیچ یک چسب زخم است. پیش‌فرض‌های اعلان Slack فرض می‌کنند شما می‌خواهید در دسترس باشید، نه ساکت. این شرط‌بندی برای کاربر میانه درست است. بیشتر تیم‌ها اول سوئیچ را طراحی می‌کنند و بگذارند پیش‌فرض خودش دربیاید. این ترتیب غلط است.
قانون ۴: افشای تدریجی به‌جای پراکندگی تخت
کاربر باید پنج تنظیمی را ببیند که ۹۰٪ کاربران به آن‌ها اهمیت می‌دهند. ۵۰ تنظیم دیگر یک کلیک عمیق‌تر می‌مانند، پشت یک عنصر روشن «Advanced». تنظیمات پروژه Vercel این را عالی اجرا می‌کند. صفحه اول دامنه، متغیرهای محیطی و حفاظت استقرار را نشان می‌دهد. بازنویسی‌های build، پیکربندی توابع و rewriteها در Advanced هستند.
قانون ۵: بدون یتیم
هر تنظیم به یک گروه تعلق دارد. هر گروه یک نام دارد. آزمون یتیم: هر برچسب را بدون هیچ زمینه دیگری بلند بخوانید. اگر یک طراح تیمتان نتواند بگوید آن سوئیچ چه می‌کند، یتیم است. یتیم‌ها نهال موزه‌اند.
قانون ۶: هر تنظیم باید نانش را دربیاورد
یک تنظیم یک قرارداد است. تیم متعهد می‌شود آن را برای همیشه نگه دارد، مستند کند، تست کند و درباره تعامل آن با هر تنظیم دیگر استدلال کند. بیشتر تنظیمات نمی‌توانند این اجاره را بپردازند. موضع پیش‌فرض برای هر تنظیم جدید باید «نه» باشد. تیم‌های خوب بیشتر از آنچه منتشر می‌کنند تنظیم می‌کُشند.
ضدالگوهایی که نشان می‌دهند مشکل عمیق‌تر است
سه الگو بیشتر از بقیه با هم صفحه‌های تنظیمات را می‌کُشند. هرکدام نشانه‌ای است که مشکل صفحه نیست، تیمی است که پشت آن ایستاده.
تنظیمات به‌جای تصمیم محصولی. تیم نتوانست روی opt-in یا opt-out به توافق برسد، پس به‌شکل سوئیچ منتشر شد. کاربر وارث بحث حل‌نشده می‌شود. اگر در استندآپ شنیدید «بیایید قابل تنظیمش کنیم»، دارید شکل‌گیری این ضدالگو را می‌بینید. تحلیل عمیق‌تر در طراحی عمدی اصطکاک آمده است.
تنظیماتی که طراحی بد را جبران می‌کنند. سوئیچ «compact mode» چون تراکم پیش‌فرض زیادی باز است. سوئیچ «high contrast» چون رنگ‌های برند در دسترس‌پذیری رد می‌شوند. سوئیچ «classic view» چون بازطراحی رد شد. هرکدام یک اصلاح واقعی است که لباس گزینه پوشیده. راه‌حل این است که تراکم، کنتراست و نماها را از همان بار اول درست طراحی کنید.
تنظیماتی که کسی نمی‌تواند در یک جمله توضیح دهد. اگر یک طراح نتواند بگوید تنظیم چه می‌کند، با روشن‌شدنش چه تغییر می‌کند و برای چه کسی است، آن تنظیم نباید منتشر شود. این آزمون را پیش از رسیدن هر سوئیچ جدید به کدبیس اجرا کنید.
ممیزی صفحه تنظیمات
هر صفحه تنظیمات را از این هفت سؤال بگذرانید. اگر برای شش‌تایشان «بله» قاطع ندارید، صفحه تمام نشده است.
- آیا کاربر می‌تواند هر تنظیمی را در کمتر از پنج ثانیه پیدا کند؟ اگر نه، صفحه جستجو ندارد یا سلسله‌مراتب خراب است.
- آیا هر تنظیم یک توضیح یک‌جمله‌ای دارد که غیرمهندس بفهمد؟ اگر برچسب برای توضیح به مهندس نیاز دارد، جایی در سطح محصول ندارد.
- آیا زدن سوئیچ اثری دیدنی و فوری دارد؟ تغییر وضعیت پنهان قاتل اعتماد است.
- آیا تنظیمات بر اساس وظیفه کاربر گروه‌بندی شده‌اند، نه بر اساس تیم قابلیت؟ صفحه‌ای که بر اساس مالکیت تیم‌ها سازمان‌دهی شده یک مصنوع داخلی است که به محصول نشت کرده. بر اساس هدف کاربر گروه‌بندی کنید.
- آیا پیش‌فرض‌ها جایی مکتوب مورد دفاع‌اند؟ تیم باید بتواند به یک سند، یک تصمیم سلسله‌مراتب بصری یا یک اصل برند اشاره کند. اگر پیش‌فرض «هرچه مهندس وسط اسپرینت گذاشت» است، صفحه تمام نشده.
- آیا می‌توانید نیمی از تنظیمات را بدون اینکه کاربر متوجه شود حذف کنید؟ اگر بله، انجامش بدهید. موزه سنگین‌تر از چیزی است که تیم فکر می‌کند.
- آیا صفحه شبیه بقیه محصول به نظر می‌رسد و حس می‌دهد؟ آن را کنار اصول طراحی لندینگ‌پیج بخوانید. اگر برند از هم می‌پاشد، صفحه تنظیمات از برند جدا افتاده است.
تیمی که این ممیزی را سالی دو بار اجرا می‌کند سطح تنظیماتی منتشر می‌کند که کاربران از آن جا نمی‌خورند. تیمی که هرگز اجرایش نمی‌کند صفحه‌ای منتشر می‌کند که ابزار جذب نیروی رقیب می‌شود.
اصل را انتخاب کنید، بعد صفحه را هرس کنید
تنظیمات جهان‌بینی تیم‌اند که در سوئیچ‌ها منجمد شده. تیم‌های خوب با صفحه مثل یک جریان درجه‌یک رفتار می‌کنند، با همان ظرافتی که برای onboarding، داشبورد و سایت بازاریابی به کار می‌برند.
سریع‌ترین راه اصلاح صفحه تنظیمات بازطراحی‌اش نیست. حذف نیمی از آن است. هر تنظیمی را که در آزمون یتیم، آزمون یک‌جمله‌ای و آزمون کسب‌ارزش رد می‌شود بردارید. آنچه می‌ماند ستون فقرات یک سطح تنظیمات واقعی است.
ارتباط با حالت‌های خالی اتفاقی نیست. هر دو صفحه نشان می‌دهند وقتی هیچ چیز دیگری روی صفحه نیست که حواس را پرت کند، تیم به چه باور دارد. همین انضباط در اصول طراحی وب هم دیده می‌شود.
پرسش‌های متداول
یک محصول باید چند تنظیم داشته باشد؟
تا حد ممکن کم. هر تنظیم قراردادی است که تیم برای همیشه نگهش می‌دارد. موضع پیش‌فرض برای هر تنظیم جدید باید «نه» باشد. اگر تیم نتواند تنظیم را در یک جمله توجیه کند، کاربری را که به او خدمت می‌کند نام ببرد و بگوید با روشن‌شدنش چه چیزی دیدنی تغییر می‌کند، آن تنظیم نباید منتشر شود.
تنظیمات باید در کجای محصول باشند؟
کنار چیزی که روی آن اثر می‌گذارند، نه در یک جناح مرکزی تنظیمات. تنظیمات صفحه روی صفحه. تنظیمات workspace روی workspace. تنظیمات اعلان در پنل اعلان‌ها. صفحه تنظیمات مرکزی برای مسائل سطح حساب مثل صورتحساب، پروفایل و نشست‌ها مناسب است و تقریباً هیچ چیز دیگر.
چطور صفحه تنظیماتی را که سال‌ها سوئیچ انباشته کرده پاکسازی کنم؟
ممیزی را اجرا کنید، بعد حذف کنید. هر تنظیم را بر اساس وظیفه کاربر گروه‌بندی کنید. یتیم‌ها، بن‌بست‌ها و قطعات موزه‌ای را شناسایی کنید. در گذر اول ۳۰٪ پایینی را بردارید و تیکت‌های پشتیبانی را تماشا کنید. اگر کسی شکایت نکرد، ۲۰٪ دیگر را حذف کنید.
صفحه تنظیمات را مثل صفحه اصلی طراحی کنید
صفحه تنظیمات زیرزمین نیست. اتاقی است که کاربران حرفه‌ای شما در آن زندگی می‌کنند و کاربران جدید شما را با آن قضاوت می‌کنند. با آن مثل صفحه اصلی، onboarding و داشبورد رفتار کنید. همان ظرافت را به کار ببرید. با همان اعتقاد منتشرش کنید.
اگر تیمی می‌خواهید که صفحه تنظیمات را مثل بقیه محصول طراحی کند و آن را از بک‌لاگ به ارث نبرد، Brainy را استخدام کنید. ما تنظیمات را به‌عنوان یک جریان درجه‌یک طراحی می‌کنیم، با انضباطی که صفحه را کوچک نگه می‌دارد و سوئیچ‌ها را وادار می‌کند اجاره‌شان را بپردازند.
Want a settings surface that reads like the product instead of the bug tracker? Brainy designs settings as a first-class flow, not a graveyard.
Get Started
