نگاهی به چند اشتباه رایج در طراحی نرم‌افزارهای تعاملی
اگر مدام به کاربر هشدارهای بی‌مورد بدیم، حساسیتش نسبت به وقایع گزارش‌شده توسط نرم‌افزار کم می‌شه. درباره این و چند اشتباه دیگه در طراحی حرف بزنیم
چوپان دروغگو در نرم‌افزار
از ویندوز ویستا به بعد مایکروسافت یک فناوری برای افزایش امنیت را معرفی کرد به نام User Access Control که کارش این بود که از کاربر بپرسد آیا مطمئن است؟ UAC در ظاهر راه حل مناسبی برای کاهش ریسک‌های امنیتی به نظر می‌آمد اما تعداد زیاد پیغام‌ها و این حقیقت که UAC برای هر چیز کوچکی سوال می‌پرسید باعث این شد که کاربران ویندوز بعد از مدتی نسبت به آن واکنش نشان ندهند! یعنی هر زمان که پیغام UAC را می‌دیدند به دلیل سابقه پیغام‌های بی‌مورد قبلی، بدون خواندن آن پیغام پنجره را ببندند یا yes بزنند که این خود نقض غرض بود. بعضی دیگر از کاربران هم اساساً این ویژگی را off می‌کنند.
اگر نرم‌افزاری که طراحی و پیاده‌سازی کردید بیش از حد به کاربر پیغام هشدارگونه می‌دهد این باعث سلب اطمینان کاربران از نرم‌افزار می‌شود و دیگر به نوعی نرم‌افزار یک چوپان دروغگو محسوب می‌شود که به هیچ دلیلی می‌خواهد کاربر را دچار استرس تصمیم‌گیری کند.
جنبه دیگری نیز در این ماجرا وجود دارد: در طراحی نرم‌افزارهای ایرانی بسیار دیدم که موقع خروج می‌پرسند آیا مطمئن هستید که می‌خواهید خارج شوید؟ این در حالی است که هیچ فایل ذخیره نشده‌ای در نرم‌افزار نیست. طراح نرم‌افزار باید بپذیرد که اگر کاربر مطمئن نبود روی دکمه خروج کلیک نمی‌کرد. در واقع شانس اینکه کاربر به صورت تصادفی با موس روی دکمه خروج کلیک کرده باشد به اندازه شانس پیدا شدن پنگوئن در استوا کم است!
عدم پذیرش مسئولیت توسط تولیدکننده نرم‌افزار
نرم‌افزار خوب باید بتواند با الگوریتم‌های خودش بیشتر تصمیمات را گرفته و نتیجه را به کاربر منتقل کند و فقط در دریافت ورودی‌ها از کاربر انتظار پاسخ داشته باشد. تصمیم‌گیری در خصوص نحوه پردازش اطلاعات باید از طریق بخش تنظیمات صورت بگیرد نه اینکه هر کاربر نظر کاربر را درباره تصمیماتش بپرسیم. این‌طوری نرم‌افزار تبدیل به یک موجودیت کاملاً منفعل می‌شود. درست است که در برنامه‌نویسی ما باید دقیقاً به کامپیوتر بگوییم که چه می‌خواهیم و چطوری پردازش را انجام دهد اما گاهی اوقات هم عدم پذیرش مسئولیت اتفاقات توسط برنامه‌نویس برای کاربر آزاردهنده است.
یک نمونه از این عدم پذیرش مسئولیت در نرم‌افزار دیگر مایکروسافت یعنی SQL Server مشاهده می‌شود. در نسخه 2008 به بعد، اگر شما در یک دیتابیس یک جدول ایجاد و سپس سعی کنید آن جدول را تغییر دهید، SQL Server بر اساس تنظیمات پیش فرض به شما اجازه ذخیره تغییرات را نمی‌دهد. شما مجبور هستید برای تغییر دادن به بخش تنظیمات نرم‌افزار رفته و گزینه را علامت بزنید که مشخص می‌کند مسئولیت این تغییرات با شماست!
رفتار و نگاه کاربر به نرم‌افزار همیشه مانند رفتار و نگاه طراح و برنامه‌نویس نیست
چیز دیگری که استفاده بیش از حد آن باعث صدمه دیدن ارتباط کاربران با نرم‌افزار می‌شود، اعمال سلیقه طراح/برنامه‌نویس به کاربر است. به عنوان مثال در نرم‌افزاری داخلی دیدم که چون بعضی کاربران موقع کار با نرم‌افزار آن را می‌بستند و بعد notification های نرم‌افزار را دریافت نمی‌کردند، تصمیم بر آن شد که دکمه بستن پنجره ویندوزی نرم‌افزار disable شود! این تحمیل سلیقه باعث ناراحتی بخش دیگری از کاربران که برای خروج از نرم‌افزار باید کلیک اضافه داشته باشند می‌شود.
برای طراحی یک نرم‌افزار موفق باید بتوانیم رفتار کاربر را شبیه‌سازی کنیم، صرف تولید نرم‌افزاری که یک فرایند را به صورت عادی و بدون تغییر الکترونیکی می‌کند به معنی تولید نرم‌افزار موفق نیست. نرم‌افزار باید بتواند فرایندهایی که کاربر با آن‌ها درگیر است را ساده‌سازی کند. در پروسه تولید نرم‌افزار به جز الکترونیکی شدن فرآیندها، ساده‌سازی و اضافه شدن دقت و سرعت انجام کارها هم مهم است.
در این مورد بیشتر صحبت خواهیم کرد.