تصور کنید کاربری برای اولین بار وارد یک نرم‌افزار حرفه‌ای می‌شود. هدفش ساده است: می‌خواهد اولین کار واقعی‌اش را انجام دهد. اما با ده‌ها منو، تنظیمات پیشرفته و اصطلاح ناآشنا روبه‌رو می‌شود.
حالا اگر برای کمک به این کاربر، بخش زیادی از امکانات را پنهان کنیم، چه اتفاقی برای کاربران حرفه‌ای می‌افتد که هر روز به همان قابلیت‌ها نیاز دارند؟
این یکی از چالش‌های جدی طراحی محصول است: چطور می‌توانیم استفاده از یک محصول پیچیده را آسان کنیم، بدون اینکه توانایی‌های ارزشمندش را قربانی سادگی کنیم؟
پاسخ لزوما در حذف قابلیت‌ها یا طراحی یک رابط کاربری خلوت‌تر نیست. گاهی باید به‌جای تغییر آنچه محصول می‌تواند انجام دهد، شیوه آشناشدن کاربر با قابلیت‌هایش را تغییر بدهیم.
سوال مصاحبه چیست و مصاحبه‌کننده چه چیزی را ارزیابی می‌کند؟
سوال دوازدهم مجموعه هزار سوال مصاحبه مدیر محصول این است:
«چطور تجربه شروع کار با یک ابزار حرفه‌ای پیچیده را ساده می‌کنید، بدون اینکه از قدرت و قابلیت‌های آن کم شود؟»
این سوال در دسته تفکر محصول و طراحی تجربه کاربری قرار می‌گیرد.
مصاحبه‌کننده می‌خواهد ببیند آیا می‌توانیم مسئله واقعی کاربر را از ظاهر پیچیده محصول جدا کنیم یا نه.
پاسخ قوی باید نشان دهد که می‌توانیم:
- کاربران تازه‌کار و حرفه‌ای را بر اساس نیاز و رفتارشان تفکیک کنیم.
- بفهمیم کاربران در کدام مرحله و به چه دلیلی دچار مشکل می‌شوند.
- بدون حذف قابلیت‌های ضروری، مسیر رسیدن به اولین نتیجه ارزشمند را کوتاه کنیم.
- میان سادگی، انعطاف‌پذیری، هزینه پیاده‌سازی و نیازهای کاربران حرفه‌ای تعادل برقرار کنیم.
- راه‌حل پیشنهادی را با شواهد و معیارهای قابل‌اندازه‌گیری ارزیابی کنیم.
مصاحبه‌کننده بیشتر از اینکه دنبال یک طراحی زیبا باشد، می‌خواهد منطق تصمیم‌گیری ما را بشنود.
ابتدا باید بفهمیم پیچیدگی از کجا آمده است
هر پیچیدگی‌ای در محصول لزوما بد نیست.
یک نرم‌افزار تخصصی ممکن است برای انجام کارهای پیچیده به تنظیمات و قابلیت‌های متعددی نیاز داشته باشد. مثلا یک ابزار تحلیل داده باید بتواند منابع مختلف اطلاعات را مدیریت کند، محاسبات سفارشی انجام دهد و سطح دسترسی کاربران را کنترل کند.
حذف این امکانات ممکن است ظاهر محصول را ساده‌تر کند، اما از ارزش واقعی آن بکاهد.
بنابراین باید میان دو نوع پیچیدگی تفاوت بگذاریم.
پیچیدگی ضروری: پیچیدگی‌ای که از ماهیت کار و نیاز واقعی کاربران ناشی می‌شود. حذف آن ممکن است انجام کارهای تخصصی را غیرممکن یا محدود کند.
پیچیدگی غیرضروری: پیچیدگی‌ای که از طراحی نامناسب، اصطلاحات مبهم، مراحل تکراری، دسته‌بندی ضعیف امکانات یا نمایش زودهنگام تنظیمات ناشی می‌شود.
وظیفه ما حذف کورکورانه پیچیدگی نیست؛ باید پیچیدگی غیرضروری را کاهش دهیم و پیچیدگی ضروری را قابل‌فهم و قابل‌کنترل کنیم.
قبل از ارائه راه‌حل چه سوال‌هایی می‌پرسیم؟
ابتدا باید چند موضوع را روشن کنیم.
آیا کاربران تازه‌کار در استفاده از خود محصول مشکل دارند یا هنوز دانش تخصصی لازم برای انجام کارشان را ندارند؟ این دو مسئله به راه‌حل‌های متفاوتی نیاز دارند.
کاربران در اولین مراجعه دقیقا می‌خواهند چه کاری انجام دهند؟ کدام مراحل برای رسیدن به نتیجه ضروری هستند؟ آیا محصول برای یک کارشناس مستقل طراحی شده یا چند نقش سازمانی با سطح دسترسی متفاوت دارد؟
همچنین باید مشخص کنیم کاربران کجا متوقف می‌شوند. هنگام تنظیم اولیه؟ در مواجهه با اصطلاحات فنی؟ هنگام اتصال داده‌ها؟ یا زمانی که نمی‌دانند قدم بعدی چیست؟
اگر داده کافی وجود نداشته باشد، به‌جای حدس‌زدن، فرضیه‌ها را مشخص می‌کنیم و سراغ مشاهده رفتار واقعی کاربران می‌رویم.
کاربران تازه‌کار و حرفه‌ای لزوما دو گروه ثابت نیستند
یکی از اشتباهات رایج این است که تصور کنیم همه کاربران جدید مبتدی هستند و همه کاربران قدیمی حرفه‌ای.
ممکن است یک تحلیلگر باتجربه برای اولین بار از نرم‌افزار ما استفاده کند. او مفاهیم تخصصی را می‌شناسد و فقط باید با ساختار ابزار آشنا شود.
در مقابل، کاربری که مدت‌ها عضو محصول بوده ممکن است برای اولین بار بخواهد از یک قابلیت پیشرفته استفاده کند.
پس بهتر است کاربران را علاوه بر سابقه استفاده، بر اساس هدف، مهارت مرتبط و نوع کاری که قصد انجامش را دارند بشناسیم.
برای مثال، سه وضعیت می‌تواند مبنای بررسی باشد:
- کاربری که می‌خواهد اولین کار معمول را انجام دهد و به راهنمایی نیاز دارد.
- کاربری که کارهای معمول را بلد است، اما به‌تازگی سراغ یک قابلیت پیشرفته رفته است.
- کاربر حرفه‌ای که می‌خواهد بدون مراحل اضافه، مستقیما به ابزارهای تخصصی دسترسی داشته باشد.
این تقسیم‌بندی یک فرض اولیه برای تحقیق است، نه اینکه از ابتدا همه کاربران را به سه گروه قطعی محدود کنیم.
سه مسیر برای ساده‌سازی محصول
مسیر اول: حذف یا پنهان‌کردن گسترده قابلیت‌ها
اولین پیشنهاد ممکن است طراحی یک نسخه ساده و محدود از نرم‌افزار باشد.
این تصمیم گاهی منطقی است؛ مثلا زمانی که محصول واقعا دو بازار مستقل با نیازهای متفاوت دارد.
اما اگر کاربران تازه‌کار قرار است به‌مرور از همان محصول حرفه‌ای استفاده کنند، یک نسخه بیش از حد محدود می‌تواند مانع رشد آن‌ها شود.
ضمن اینکه نگهداری دو تجربه کاملا متفاوت، هزینه توسعه و پشتیبانی را افزایش می‌دهد و ممکن است جابه‌جایی میان آن‌ها را دشوار کند.
بنابراین این گزینه را بدون شواهدی از تفاوت پایدار نیازها انتخاب نمی‌کنیم.
مسیر دوم: آموزش کامل محصول در اولین ورود
راه دیگر این است که هنگام ورود، تمام بخش‌های محصول را با یک تور آموزشی معرفی کنیم.
این روش در نگاه اول جذاب است، اما یک مشکل دارد: کاربر معمولا برای یادگرفتن تمام امکانات وارد محصول نشده؛ می‌خواهد کار مشخصی را انجام دهد.
تحقیقات Nielsen Norman Group درباره راهنماهای آغازین نشان می‌دهد آموزش‌های اجباری و خارج از زمینه استفاده، اغلب نادیده گرفته می‌شوند و لزوما عملکرد کاربران را بهتر نمی‌کنند.
البته آموزش مرحله‌به‌مرحله برای تعاملات کاملا جدید یا فرایندهای حساس می‌تواند مفید باشد؛ به‌خصوص وقتی کاربر واقعا به آن نیاز دارد.
پس مسئله، حذف آموزش نیست؛ زمان و شیوه ارائه آن است.
مسیر سوم: شروع مبتنی بر وظیفه و نمایش تدریجی قابلیت‌ها
در بیشتر ابزارهای حرفه‌ای، انتخاب اولیه من ترکیبی از دو رویکرد است:
شروع مبتنی بر وظیفه (Task-Based Onboarding) و افشای تدریجی امکانات (Progressive Disclosure).
در این مدل، کاربر ابتدا با قابلیت‌هایی روبه‌رو می‌شود که برای انجام کار فعلی‌اش لازم دارد. گزینه‌های تخصصی همچنان وجود دارند، اما در جای مشخص و قابل‌دسترسی نمایش داده می‌شوند.
برای مثال، به‌جای اینکه هنگام ساخت اولین گزارش، تمام تنظیمات فیلتر، فرمول‌نویسی، اتصال داده و سطح دسترسی را یکجا نمایش دهیم، ابتدا کاربر را به ساخت یک گزارش معتبر هدایت می‌کنیم.
بااین‌حال، تنظیمات پیشرفته حذف نمی‌شوند. کاربر حرفه‌ای می‌تواند بدون عبور از مراحل آموزشی به آن‌ها دسترسی داشته باشد.
این همان منطقی است که Jakob Nielsen در توضیح Progressive Disclosure مطرح می‌کند: گزینه‌های اصلی در ابتدا دیده می‌شوند و امکانات تخصصی در صورت نیاز در دسترس قرار می‌گیرند.
اما نمایش تدریجی هم محدودیت دارد. اگر قابلیت‌های مهم را بیش از حد پنهان کنیم یا مسیر دسترسی به آن‌ها نامشخص باشد، فقط پیچیدگی را از صفحه اصلی به بخش‌های دیگر منتقل کرده‌ایم.
طراحی یک تجربه شروع کار مناسب چه ویژگی‌هایی دارد؟
۱. کاربر را به اولین نتیجه واقعی برسانیم
هدف اصلی تجربه شروع کار نباید تکمیل یک آموزش یا عبور از چند صفحه معرفی باشد.
باید مشخص کنیم اولین نتیجه‌ای که برای کاربر ارزش دارد چیست.
مثلا در یک ابزار مدیریت پروژه، ساختن یک پروژه خالی لزوما به معنی دریافت ارزش نیست. شاید کاربر زمانی ارزش محصول را تجربه کند که وظایف واقعی تیم را ثبت کند، مسئولیت‌ها را مشخص کند و بتواند وضعیت پیشرفت کار را ببیند.
این لحظه را می‌توان اولین تجربه ارزشمند یا First Value نامید.
۲. راهنمایی را در زمان نیاز نشان دهیم
به‌جای نمایش همه آموزش‌ها هنگام ورود، راهنما را در همان نقطه‌ای ارائه می‌کنیم که کاربر با ابهام مواجه شده است.
مثلا توضیح یک فیلتر پیشرفته زمانی ظاهر شود که کاربر آن قابلیت را باز می‌کند.
راهنما باید قابل‌بستن باشد و کاربر بتواند بعدا دوباره به آن دسترسی پیدا کند.
۳. مسیر سریع کاربران حرفه‌ای را حفظ کنیم
کاربران باتجربه نباید مجبور شوند هر بار مراحل آموزشی را طی کنند.
دسترسی مستقیم به امکانات، میان‌برهای صفحه‌کلید، جست‌وجوی فرمان‌ها و امکان شخصی‌سازی محیط می‌توانند در حفظ بهره‌وری این گروه نقش داشته باشند.
یکی از اصول شناخته‌شده کاربردپذیری Nielsen نیز بر انعطاف‌پذیری و کارایی برای کاربران تازه‌کار و باتجربه تاکید می‌کند.
۴. کنترل را از کاربر نگیریم
راهنمایی خوب نباید کاربر را در یک مسیر اجباری گرفتار کند.
امکان ردکردن آموزش، بازگشت به مراحل قبل، تغییر تنظیمات اولیه و اصلاح اشتباهات باید متناسب با ماهیت محصول وجود داشته باشد.
البته مراحل ضروری امنیتی، مجوزهای دسترسی یا کنترل‌های حساس را نباید صرفا برای کوتاه‌کردن مسیر حذف کنیم.
مثال کاربردی: بازطراحی شروع کار با یک نرم‌افزار تحلیل فروش
سناریوی فرضی
فرض کنیم یک شرکت نرم‌افزاری، محصولی تحت وب برای تحلیل فروش سازمانی دارد.
محصول به کاربران اجازه می‌دهد داده‌های فروش را وارد کنند، داشبورد بسازند، گزارش‌های سفارشی تهیه کنند و سطح دسترسی اعضای تیم را مدیریت کنند.
دو گروه از کاربران برای ما اهمیت دارند.
گروه اول، کارشناسان فروشی هستند که می‌خواهند خیلی سریع گزارش فروش هفتگی بسازند.
گروه دوم، تحلیلگران باتجربه‌ای هستند که به اتصال چند منبع داده، محاسبات سفارشی و تنظیمات پیشرفته نیاز دارند.
در نسخه فعلی فرضی، همه کاربران پس از ورود با مجموعه یکسانی از گزینه‌های فنی روبه‌رو می‌شوند.
مسئله‌ای که می‌خواهیم بررسی کنیم: آیا نمایش تنظیمات تخصصی پیش از انجام اولین کار، مانع رسیدن کاربران جدید به نتیجه می‌شود؟
برای پاسخ، ابتدا رفتار واقعی را بررسی می‌کنیم. مسیر کاربران از اولین ورود تا ساخت گزارش را اندازه می‌گیریم، با افراد هر دو گروه گفت‌وگو می‌کنیم و مشاهده می‌کنیم دقیقا کجا سردرگم می‌شوند.
اگر شواهد فرضیه ما را تایید کنند، می‌توانیم این تجربه را آزمایش کنیم:
شروع ساده برای کاربر جدید: کاربر با انتخاب هدف «ساخت اولین گزارش فروش» وارد یک مسیر کوتاه می‌شود. محصول فقط اطلاعات ضروری را می‌پرسد، امکان ورود داده معتبر را فراهم می‌کند و او را به ساخت و ذخیره یک گزارش واقعی می‌رساند.
حفظ دسترسی حرفه‌ای: تحلیلگر باتجربه از همان ابتدا می‌تواند به تنظیمات پیشرفته، فرمول‌های سفارشی و ابزارهای تخصصی دسترسی داشته باشد.
راهنمایی درون‌محصولی: در زمان استفاده از قابلیت‌های پیچیده، توضیحات کوتاه و مرتبط نمایش داده می‌شوند، بدون اینکه انجام کار متوقف شود.
کنترل ریسک: اعتبارسنجی داده‌ها و مجوزهای امنیتی برای هر دو مسیر یکسان باقی می‌ماند. ساده‌سازی نباید باعث شود داده نامعتبر پذیرفته شود یا کاربر به اطلاعات غیرمجاز دسترسی پیدا کند.
در این سناریو، هیچ نتیجه‌ای از پیش قطعی نیست. باید آزمایش کنیم که آیا کاربران جدید واقعا زودتر به نتیجه می‌رسند و آیا سرعت یا دقت کاربران حرفه‌ای آسیب می‌بیند.
موفقیت را چطور اندازه‌گیری کنیم؟
یکی از اشتباهات مهم این است که تعداد تکمیل‌کنندگان آموزش را معیار اصلی موفقیت قرار دهیم.
ممکن است کاربران همه مراحل آموزشی را پشت سر بگذارند، اما همچنان نتوانند کاری را که برایش وارد محصول شده‌اند انجام دهند.
برای سناریوی فرضی تحلیل فروش، معیارها را این‌طور تعریف می‌کنیم:
معیار اصلی موفقیت (Outcome Metric):
نرخ کاربرانی که در هفت روز اول، اولین گزارش واقعی و معتبر خود را می‌سازند و ذخیره می‌کنند.
مخرج این نرخ، کاربران جدید واجد شرایطی است که به قابلیت گزارش‌سازی دسترسی دارند. کسانی که به دلیل محدودیت سازمانی هنوز مجوز لازم را نگرفته‌اند، جداگانه بررسی می‌شوند تا مشکل دسترسی با مشکل طراحی تجربه کاربری اشتباه گرفته نشود.
معیارهای تشخیصی (Diagnostic Metrics):
زمان میانه رسیدن به اولین گزارش معتبر، نرخ رهاکردن هر مرحله، خطاهای ورود داده و میزان موفقیت کاربران در انجام وظیفه بدون کمک در آزمون‌های کاربردپذیری.
معیارهای محافظ (Guardrail Metrics):
زمان انجام کارهای پیشرفته برای کاربران باتجربه، نرخ خطا در تنظیمات حساس، درخواست‌های پشتیبانی مرتبط با پیدانکردن قابلیت‌ها و مشکلات امنیتی یا دسترسی.
این شاخص‌ها باید پیش از اجرای آزمایش تعریف شوند. سپس با یک نسخه مبنا یا گروه مقایسه مناسب بررسی می‌کنیم که تغییر جدید چه اثری داشته است.
افزایش سرعت ساخت اولین گزارش، اگر با کاهش دقت گزارش‌ها یا اختلال جدی در کار تحلیلگران همراه باشد، موفقیت محسوب نمی‌شود.
اگر فقط دو هفته فرصت داشته باشیم چه می‌کنیم؟
در چنین شرایطی، بازطراحی کامل محصول انتخاب مناسبی نیست. باید سریع‌ترین مسیر یادگیری معتبر را پیدا کنیم.
در هفته اول، داده‌های موجود را بررسی می‌کنیم، مسیر فعلی شروع کار را ترسیم می‌کنیم و با نمونه کوچکی از کاربران تازه‌کار و حرفه‌ای مصاحبه و مشاهده انجام می‌دهیم. هدف این است که یکی دو مانع اصلی را با شواهد مشخص شناسایی کنیم.
در هفته دوم، یک نمونه اولیه محدود می‌سازیم که مسیر انجام اولین وظیفه را ساده می‌کند و دسترسی پیشرفته را حفظ می‌کند.
آن را با کاربران نماینده هر دو گروه آزمایش می‌کنیم و موفقیت در انجام وظیفه، زمان صرف‌شده و مشکلات کشف قابلیت‌ها را می‌سنجیم.
اگر نتایج امیدوارکننده باشد، برای آزمایش کنترل‌شده در محصول واقعی برنامه‌ریزی می‌کنیم. اگر نه، قبل از توسعه گسترده، فرضیه را اصلاح می‌کنیم.
دو هفته برای اثبات اثر بلندمدت بر نگهداشت کاربران کافی نیست، اما می‌تواند برای ردکردن یک ایده ضعیف یا مشخص‌کردن مسیر آزمایش بعدی مفید باشد.
چه زمانی باید تصمیم خود را تغییر دهیم؟
انتخاب نمایش تدریجی قابلیت‌ها یک تصمیم مشروط است، نه یک قانون همیشگی.
اگر مشاهده کنیم کاربران جدید عمدتا به دلیل نداشتن دانش تخصصی شکست می‌خورند، نه پیچیدگی رابط کاربری، صرفا تغییر صفحه شروع کار مسئله را حل نمی‌کند. در این صورت باید آموزش عملی مرتبط یا پشتیبانی تخصصی را بررسی کنیم.
اگر کاربران حرفه‌ای برای پیداکردن ابزارهای پرکاربرد به کلیک‌های بیشتری نیاز پیدا کنند، باید معماری اطلاعات، میان‌برها یا میزان دسترسی مستقیم را اصلاح کنیم.
اگر فرایند اولیه شامل تنظیمات حساس امنیتی یا الزامات قانونی باشد، کوتاه‌کردن مسیر نباید به قیمت حذف کنترل‌های ضروری تمام شود.
و اگر تحقیقات نشان دهد دو گروه از کاربران واقعا نیازهای مستقل و پایدار دارند، ممکن است طراحی محیط‌های کاری متفاوت از یک مسیر شروع مشترک مناسب‌تر باشد.
مدیر محصول باید بداند چه شواهدی از تصمیمش حمایت می‌کنند و چه شواهدی باعث می‌شوند از آن صرف‌نظر کند.
پاسخ پیشنهادی در مصاحبه
اگر بخواهم این سوال را در مصاحبه پاسخ بدهم، می‌توانم بگویم:
«من قبل از اینکه سراغ ساده‌کردن رابط کاربری بروم، می‌خواهم بفهمم کاربران دقیقا کجا گیر می‌کنند و چه کاری را می‌خواهند انجام دهند. چون لزوما پیچیده‌بودن یک ابزار حرفه‌ای به معنی بدبودن طراحی آن نیست.
اول کاربران را بر اساس هدف و میزان آشنایی‌شان با کار و محصول تفکیک می‌کنم. بعد بررسی می‌کنم برای رسیدن به اولین نتیجه ارزشمند، واقعا به کدام قابلیت‌ها نیاز دارند.
احتمالا اولین گزینه‌ای که آزمایش می‌کنم، یک مسیر شروع کار مبتنی بر وظیفه همراه با نمایش تدریجی امکانات است. یعنی کاربران تازه‌کار بدون درگیری با تنظیمات غیرضروری کارشان را شروع کنند، اما کاربران حرفه‌ای همچنان دسترسی مستقیم به ابزارهای پیشرفته داشته باشند.
قبل از توسعه گسترده، با نمونه اولیه و آزمون کاربردپذیری بررسی می‌کنم آیا کاربران جدید راحت‌تر کارشان را انجام می‌دهند یا نه. در کنارش حواسم هست سرعت و دقت کاربران حرفه‌ای کاهش پیدا نکند.
اگر داده‌ها نشان دهند مشکل اصلی آموزش تخصصی است یا راه‌حل پیشنهادی استفاده حرفه‌ای را سخت‌تر می‌کند، مسیرم را تغییر می‌دهم. هدفم حذف امکانات نیست؛ می‌خواهم محصول بدون از دست‌دادن قدرتش، یادگیری و استفاده آسان‌تری داشته باشد.»
سوال‌های تکمیلی مصاحبه
اگر فقط دو هفته برای حل مسئله وقت داشته باشید، چه می‌کنید؟
این یکی از سوال‌های تکمیلی منبع اصلی است.
پاسخ مناسب باید بر اولویت‌بندی یادگیری تمرکز کند. به‌جای قول‌دادن برای بازطراحی کل محصول، یک مشکل پرتکرار و تاثیرگذار را انتخاب می‌کنیم، شواهد موجود را بررسی می‌کنیم و با نمونه اولیه آن را می‌آزماییم.
همچنین توضیح می‌دهیم در این فرصت محدود چه چیزی را می‌توانیم بفهمیم و چه چیزی همچنان نیازمند بررسی بیشتر است.
چه شواهدی باعث می‌شوند راه‌حل پیشنهادی خودتان را رد کنید؟
این دومین سوال تکمیلی منبع است و بخش مهمی از توان تصمیم‌گیری مدیر محصول را می‌سنجد.
اگر کاربران جدید با مسیر ساده‌شده همچنان نتوانند اولین کار را انجام دهند، باید علت شکست را دوباره بررسی کنیم.
اگر حذف جزئیات از صفحه اولیه باعث پنهان‌شدن اطلاعات مهم شود، یا کاربران حرفه‌ای برای انجام کارهای معمول خود زمان بیشتری صرف کنند، راه‌حل نیازمند اصلاح است.
همچنین اگر مصاحبه‌ها و آزمون‌ها نشان دهند فرض اولیه ما درباره نیاز کاربران اشتباه بوده، باید آمادگی کنارگذاشتن آن را داشته باشیم.
اشتباهات رایج در پاسخ به این سوال
ساده‌سازی را با حذف امکانات یکسان بدانیم. این رویکرد ممکن است ارزش اصلی محصول را برای مخاطبان حرفه‌ای از بین ببرد.
برای همه کاربران یک تجربه یکسان طراحی کنیم. افراد با اهداف و مهارت‌های متفاوت، لزوما به مسیر شروع یکسانی نیاز ندارند.
بدون تحقیق، از روی سلیقه تصمیم بگیریم. خلوت‌ترشدن صفحه به‌تنهایی ثابت نمی‌کند که انجام کار آسان‌تر شده است.
تور آموزشی را راه‌حل قطعی بدانیم. آموزش خارج از زمان نیاز ممکن است فقط یک مانع دیگر به مسیر کاربر اضافه کند.
فقط نرخ تکمیل آموزش یا تعداد کلیک‌ها را بسنجیم. این اعداد نشان نمی‌دهند کاربر توانسته نتیجه موردنظرش را به دست بیاورد یا نه.
قابلیت‌های پیشرفته را در لایه‌های نامشخص پنهان کنیم. چنین تغییری می‌تواند هزینه استفاده برای کاربران باتجربه را بالا ببرد.
ریسک‌های عملیاتی و امنیتی را نادیده بگیریم. کوتاه‌شدن مسیر زمانی ارزشمند است که کیفیت و ایمنی استفاده حفظ شود.
جمع‌بندی
برای ساده‌کردن شروع کار با یک نرم‌افزار حرفه‌ای، نباید از همان ابتدا سراغ حذف قابلیت‌ها برویم. ابتدا باید کاربران و کارهای اصلی‌شان را بشناسیم، موانع واقعی را پیدا کنیم و مسیری طراحی کنیم که رسیدن به اولین نتیجه ارزشمند را آسان‌تر کند.
در بسیاری از ابزارهای حرفه‌ای، ترکیب شروع کار مبتنی بر وظیفه، نمایش تدریجی امکانات و راهنمایی در زمان نیاز می‌تواند نقطه شروع مناسبی باشد؛ به شرط آنکه دسترسی سریع کاربران باتجربه، کنترل‌های ضروری و انعطاف‌پذیری محصول حفظ شود. اگر شواهد نشان دهند که مانع اصلی جای دیگری است یا این طراحی به کاربران حرفه‌ای آسیب می‌زند، باید تصمیم را بازنگری کنیم.
یک محصول حرفه‌ای لازم نیست برای ساده‌بودن، قابلیت‌های کمتری داشته باشد؛ باید کمک کند هر کاربر در زمان مناسب به امکاناتی برسد که برای انجام کارش نیاز دارد.
