در نرم‌افزارهای سازمانی، برخلاف اپلیکیشن‌های مصرفی، کاربر معمولاً نرم‌افزار را خودش انتخاب نکرده است؛ مدیریت سازمان آن را خریده و او موظف است هر روز با آن کار کند. همین تفاوت ساده، بنیان تفاوت طراحی تجربه کاربری (User Experience یا UX) در این دو دنیاست. وقتی کاربر انتخاب نکرده باشد، بازخوردش هم شکل دیگری دارد: به‌جای حذف اپلیکیشن، خطا می‌کند، دور می‌زند، فایل اکسل موازی می‌سازد و در نهایت با پشتیبانی تماس می‌گیرد. طراحی تجربه کاربری در نرم‌افزار سازمانی، یعنی مدیریت همین هزینه‌های پنهان.
دو ذی‌نفع با دو معیار موفقیت متفاوت
هر نرم‌افزار سازمانی حداقل دو نفر اصلی دارد: کسی که امضا می‌کند و کسی که هر روز کلیک می‌کند. خریدار، فهرست قابلیت‌ها، یکپارچگی با سامانه‌های دیگر و شرایط پشتیبانی را می‌بیند. کاربر اما با جزئیات درگیر است: اینکه ثبت یک رکورد چند کلیک می‌برد، اینکه پس از ذخیره فرم به حالت اول برمی‌گردد یا نه، و اینکه اگر اشتباه کند چقدر طول می‌کشد تا جبرانش کند.
اگر طراحی فقط برای راضی کردن خریدار انجام شود، محصولی به وجود می‌آید که همه قابلیت‌ها را دارد و هیچ‌کدام را سریع و قابل اتکا ارائه نمی‌کند. نشانه‌اش هم مشخص است: کاربران بخشی از فرایند را به اکسل منتقل می‌کنند.
به‌جای «راحتی»، زمان و خطا را اندازه بگیرید
در تجربه کاربری مصرفی، معیارها اغلب احساسی‌اند. در نرم‌افزار سازمانی بهتر است سراغ معیارهای قابل شمارش برویم:
- زمان انجام وظیفه تکرارشونده: یک کار پرتکرار مانند ثبت سفارش، تخصیص تیکت یا صدور سند را انتخاب کنید و زمان انجامش را برای یک کاربر واقعی اندازه بگیرید. همین عدد، معیار مقایسه نسخه‌های بعدی است.
- زمان تا اولین کار مفید: کاربر تازه‌کار چند دقیقه بعد از ورود می‌تواند یک کار واقعی و درست انجام دهد؟
- نرخ خطای ورود داده و هزینه بازگشت: سیستم چند بار جلوی اشتباه را می‌گیرد و اگر اشتباه ثبت شد، اصلاحش چند مرحله است؟
- نسبت مراجعه به پشتیبانی: کدام صفحه‌ها بیشترین تماس پشتیبانی را می‌سازند؟ این فهرست، نقشه راه طراحی است.
- میزان دور زدن سیستم: چند فایل اکسل موازی و چند گروه پیام‌رسان بیرون از نرم‌افزار برای انجام کارها شکل گرفته است؟
سه تصمیم طراحی با بیشترین اثر
۱. چگالی اطلاعات، نه سادگی مینیمال
کاربر سازمانی، کاربر حرفه‌ای است. او روزی چند ساعت با نرم‌افزار کار می‌کند و برعکس کاربر اپلیکیشن موبایل، از دیدن اطلاعات بیشتر نمی‌ترسد. پنهان کردن هر چیز در منوهای چندلایه و صفحه‌های پشت سر هم، «ساده» به نظر می‌رسد ولی کار را کند می‌کند. جدول‌های فشرده‌تر، فیلترهای ذخیره‌شده، ستون‌های قابل تنظیم و مرتب‌سازی سریع، اغلب ارزشمندتر از یک صفحه خالی و آراسته‌اند. مثلاً در سامانه‌های مدیریت تماس و CRM که اپراتور در هر ساعت ده‌ها تعامل را ثبت می‌کند، هر کلیک اضافه در یک فرم در پایان روز به عددی بزرگ تبدیل می‌شود.
۲. صفحه‌کلید به‌عنوان شهروند درجه‌یک
کاربری که تمام روز داده وارد می‌کند، خیلی زود موس را کنار می‌گذارد. ترتیب منطقی حرکت با کلید Tab، میان‌برهای قابل کشف، جست‌وجوی سراسری و امکان ثبت و رفتن به رکورد بعدی بدون ترک صفحه، سرعت کار را چند برابر می‌کند. این ویژگی‌ها در دموی محصول دیده نمی‌شوند، اما در بازخورد روزمره کاربران اولین چیزی هستند که به آن اشاره می‌کنند.
۳. جلوگیری از خطا، نه گزارش خطا
پیام خطای خوب، نشانه طراحی ناکافی است؛ طراحی خوب اجازه نمی‌دهد خطا رخ دهد. محدود کردن قالب ورودی، پیش‌فرض‌های هوشمند بر اساس زمینه کاربر، پیش‌نمایش پیش از ثبت نهایی و امکان بازگشت (Undo) به‌جای پرسیدن مکرر «آیا مطمئنید؟»، همگی خطا را کم می‌کنند. تأییدهای پی‌درپی به «کوری تأیید» منجر می‌شود؛ کاربر بدون خواندن، همه را تأیید می‌کند.
یادگیری سریع در برابر سرعت بالا
یکی از سخت‌ترین تعادل‌ها در طراحی نرم‌افزار سازمانی همین است: طراحی ساده، کار را برای کاربر تازه‌کار آسان می‌کند، اما همان سادگی برای کاربر حرفه‌ای که هزار بار این کار را انجام داده، دست‌وپاگیر می‌شود. راه‌حل معمول، لایه‌بندی است: مسیر پیش‌فرض روشن برای همه، و مسیر میان‌بر برای کسی که تجربه دارد. کاربر حرفه‌ای نباید هر بار از یک ویزارد چندمرحله‌ای عبور کند.
در همین بخش، دسترس‌پذیری (Accessibility) را جدی بگیرید. کاربران سازمانی از نظر سن، بینایی، شنوایی و محیط کاری بسیار متنوع‌اند: اتاق پرصدا، مانیتور کوچک، نور نامناسب. رعایت رهنمودهای دسترس‌پذیری وب نه یک کار تشریفاتی، بلکه مستقیماً روی سرعت و کاهش خطای همه کاربران اثر می‌گذارد.
بدهی تجربه کاربری: بدهی فنیِ نامرئی
تصمیم‌های کوچک بد، مثل یک دکمه در جای اشتباه، یک پیام مبهم یا فرمی بیش از حد بلند، به‌تنهایی کشنده نیستند، اما مانند بدهی فنی انباشته می‌شوند. نتیجه، نرم‌افزاری است که کار می‌کند ولی کاربران از آن بیزارند و مدیران نمی‌دانند چرا بازدهی پایین است. دو کار عملی: اول، هر بار که پشتیبانی یک تماس تکراری می‌گیرد، آن را به‌عنوان یک نقص طراحی ثبت کنید، نه یک مشکل کاربر. دوم، به‌جای پروژه‌های بزرگ بازطراحی، اصلاح‌های کوچک را در جریان کار عادی تیم بگنجانید؛ همان منطقی که در مدیریت پروژه نرم‌افزاری چابک برای سایر کارها به کار می‌برید.
جمع‌بندی
در نرم‌افزار سازمانی، تجربه کاربری یک ویژگی لوکس یا بحث زیبایی‌شناسی نیست؛ ابزاری برای کاهش خطا، کوتاه کردن زمان انجام کار و کم کردن وابستگی به پشتیبانی است. چون کاربر حق انتخاب ندارد، هزینه تجربه بد هم به سادگی قابل اندازه‌گیری نیست و در قالب سکوت و دور زدن سیستم ظاهر می‌شود. اگر می‌خواهید بدانید طراحی یک نرم‌افزار سازمانی خوب است یا نه، از تیم پشتیبانی و از کاربرانی بپرسید که هر روز با آن کار می‌کنند؛ نه از فهرست قابلیت‌ها.
