کاربردپذیری به زبان ساده: چرا کاربران سامانه‌ها را ترک می‌کنند؟
دنیای وب با دنیای واقعی یک فرق بزرگ دارد: اگر وارد مغازه‌ای شوید و چیدمانش بد باشد، شاید چند دقیقه تحمل کنید و جنس را پیدا کنید. اما در وب، کاربر به اندازه یک کلیک با بستن سایت شما و رفتن به سراغ رقیب فاصله دارد! هیچ کاربری نمی‌نشیند دفترچه راهنما بخواند تا بفهمد سیستم شما چطور کار می‌کند. اگر صفحه اصلی در ۵ ثانیه اول نگوید اینجا کجاست و چه کاری راه می‌اندازد، کاربر رفته است.
— یاکوب نیلسن (پدر کاربردپذیری وب)
۵ ستون اصلی یک محصول خوش‌دست (استاندارد NN/g)
برای اینکه بدانیم یک طراحی واقعاً کاربردپذیر است یا فقط ظاهر قشنگی دارد، باید این ۵ فاکتور را بسنجیم:
۱. یادگیری ساده (Learnability)
کاربر دفعه اولی که با سیستم شما روبه‌رو می‌شود، چقدر راحت و بدون پرس‌وجو از دیگران می‌تواند کار اصلی‌اش را راه بیندازد؟
۲. سرعت دست به کار شدن (Efficiency)
وقتی قلق سیستم دست کاربر آمد، آیا کارها سریع پیش می‌رود یا برای یک کار ساده باید ۱۰ تا کلیک اضافه بکند؟
۳. فراموش نشدن (Memorability)
اگر کاربر ۲ ماه به سیستم سر نزند و برگردد، دوباره گیج می‌شود یا راحت کارش را مثل روز اول ادامه می‌دهد؟
۴. جلوگیری و نجات از خطا (Errors)
کاربر چقدر اشتباه می‌کند؟ اگر وسط کار اشتباهی دکمه‌ای را زد، سیستم کار را خراب می‌کند یا به او راه برگشت ساده می‌دهد؟
۵. حس رضایت و حال خوب (Satisfaction)
کار با نرم‌افزار حس روانی و تسلط به آدم می‌دهد، یا بعد از کار با آن خسته و عصبی از پای سیستم بلند می‌شوید؟
فرمول طلایی: تفاوت فیچردار بودن با مفید بودن
خیلی وقت‌ها مدیران محصول و برنامه‌نویس‌ها این دو مفهوم را اشتباه می‌گیرند:
- کارایی و امکانات (Utility): آیا این دکمه یا امکانی که کاربر می‌خواهد اصلاً در سیستم وجود دارد؟
- کاربردپذیری (Usability): آیا استفاده از این امکان راحت و سرراست است؟
اگر یک نرم‌افزار حسابداری صدها قابلیت جادویی داشته باشد اما دکمه صدور فاکتورش زیر ۳ لایه منوی پنهان دفن شده باشد، عملاً بی‌مصرف است. مفید بودن یک محصول حاصل ضرب این دوتاست: قابلیت به درد بخور + استفاده بی‌دردسر.
چرا کاربردپذیری در سامانه‌های داخلی و اداری چند برابر مهم‌تر است؟
در سامانه‌های درون‌سازمانی (مثل ERP، CRM یا سیستم‌های صدور فاکتور و انبارداری)، کاربران نمی‌توانند تب مرورگر را ببندند چون مجبورند با آن کار کنند. اما هزینه رابط کاربری بد مستقیماً از جیب شرکت می‌رود:
- ساعت‌ها وقت پرسنل برای سر و کله زدن با فرم‌های عجیب هدر می‌رود.
- هزینه‌های آموزش کارمندان جدید سر به فلک می‌کشد.
- خطاهای انسانی در ثبت اعداد و اطلاعات بالا می‌رود و کل دیتابیس آلوده می‌شود.
طبق آمار نیلسن، صرف فقط ۱۰ درصد از بودجه پروژه برای اصلاح کاربردپذیری، سرعت انجام کار پرسنل و بازدهی سیستم را به طور میانگین بیش از ۲.۵ برابر می‌کند.
تست کاربردپذیری چطور کار می‌کند؟ (سه قدم خیلی ساده)
خیلی‌ها فکر می‌کنند تست کاربری یعنی یک استودیو شیشه‌ای با دوربین‌های پیشرفته! اصلاً اینطور نیست. کل تجهیزات لازم: یک اتاق خلوت، یک کاربر واقعی و یک دفترچه یادداشت است.
- کاربر هدف را بیاورید: کسی که در جریان پروژه نبوده و به سیستم شما عادت نکرده است.
- یک هدف مشخص به او بدهید: مثلاً بگویید «تصور کن می‌خواهی یک پیش‌فاکتور جدید ثبت کنی و برای مشتری بفرستی؛ این کار را انجام بده».
- فقط تماشا کنید و کاملاً سکوت کنید: هیچ راهنمایی نرسانید. هر جا کاربر موس را تکان نداد و به فکر فرو رفت، یعنی طراحی شما گیر دارد.
تست کاربردپذیری با جلسات پرسش‌وپاسخ (Focus Group) زمین تا آسمان فرق دارد. در جلسه نظرخواهی، آدم‌ها سعی می‌کنند مؤدب باشند و می‌گویند: «آره به نظرم منوی خوبیه». اما وقتی پشت سیستم می‌نشینند، ۳ دقیقه دنبال همان منو می‌گردند! رفتار عینی کاربر مهم است، نه تعارف‌ها و نظراتش.
چه زمانی تست کنیم؟ (بزرگ‌ترین اشتباه تیم‌ها)
بزرگ‌ترین اشتباه این است که سیستم را کامل کدنویسی می‌کنند، بالا می‌آورند و روز آخر یادشان می‌افتد تست کنند! در این مرحله اگر بفهمید فلو اشتباه است، تغییر دادن آن یعنی دوباره‌کاری‌های میلیونی و بازنویسی دیتابیس و معماری.
- مرحله ۱ روی کاغذ و وایرفریم تست کنید: تغییر یک طرح کاغذی ۲ دقیقه زمان می‌برد، اما تغییر کد ۲ هفته!
- مرحله ۲ سیستم رقبا را ببینید: ببینید کاربران در سایت‌های مشابه با چه مشکلاتی دست‌وپنجه نرم می‌کنند تا شما همان چاله را حفر نکنید.
- مرحله ۳ با ۵ کاربر شروع کنید: نیازی به تست با ۱۰۰ نفر ندارید؛ همان ۵ کاربر اول، بیش از ۸۰ درصد سوتی‌ها و گره‌های اصلی سامانه شما را بیرون می‌کشند.
