تجربه کاربری نرم‌افزارهای سازمانی یعنی طراحی سیستم‌هایی که کارمندان هر روز و ساعت‌ها با آن‌ها کار می‌کنند، طوری که کار با کمترین خطا، کمترین زمان و کمترین نیاز به آموزش انجام شود. تفاوت اصلی آن با محصولات مصرفی این است که کاربر معمولاً حق انتخاب ندارد، گردش‌کارها چندمرحله‌ای و چندنقشی‌اند و هر ثانیه‌ی اضافه در یک فرم، هزاران بار در روز تکرار می‌شود.
در این مقاله از نگاه تیم طراحی دییر توضیح می‌دهیم چرا UX نرم‌افزارهای B2B و سازمانی معمولاً ضعیف است، چطور باید برای کاربران حرفه‌ای و گردش‌کارهای پیچیده طراحی کرد، تحقیقات کاربر داخل سازمان چه تفاوتی با تحقیق روی کاربران عمومی دارد، با سیستم‌های قدیمی چه کنیم و بازگشت سرمایه‌ی این کار را چطور بسنجیم. اگر دنبال جزئیات یک نوع سیستم مشخص هستید، راهنماهای طراحی پنل ادمین و طراحی CRM اختصاصی را هم ببینید؛ این مقاله نگاه کلان‌تری به همه‌ی نرم‌افزارهای سازمانی دارد.
تجربه کاربری نرم‌افزارهای سازمانی چیست و چه فرقی با محصولات مصرفی دارد؟
نرم‌افزار سازمانی به هر سیستمی گفته می‌شود که برای اداره‌ی کار یک سازمان ساخته شده است: از سامانه‌ی منابع انسانی و اتوماسیون اداری گرفته تا سیستم مالی، انبار، پنل عملیات، ابزار پشتیبانی مشتری و پلتفرم‌های B2B که یک شرکت به شرکت دیگر می‌فروشد. اصول پایه‌ی UX در این سیستم‌ها همان اصولی است که در راهنمای طراحی UI/UX آمده، اما شرایط استفاده آن‌قدر متفاوت است که بسیاری از توصیه‌های رایج طراحی اپ‌های مصرفی اینجا کار نمی‌کند یا حتی نتیجه‌ی معکوس دارد.
| ویژگی | محصول مصرفی | نرم‌افزار سازمانی |
|---|---|---|
| انتخاب کاربر | کاربر آزادانه نصب یا حذف می‌کند | سازمان انتخاب می‌کند و کاربر موظف به استفاده است |
| خریدار و کاربر | معمولاً یک نفر | اغلب دو گروه جدا با اولویت‌های متفاوت |
| الگوی استفاده | کوتاه و پراکنده | طولانی، روزانه و تکراری |
| پیچیدگی کار | چند مسیر ساده | گردش‌کار چندمرحله‌ای با نقش‌ها و مجوزها |
| حجم داده | کم و شخصی | زیاد، جدولی و مشترک بین تیم‌ها |
| هزینه‌ی خطا | معمولاً ناراحتی کاربر | خطای مالی، حقوقی یا عملیاتی |
| معیار موفقیت | جذب، ماندگاری، تبدیل | سرعت انجام کار، دقت و پذیرش در سازمان |
نتیجه‌ی این تفاوت‌ها ساده است: در نرم‌افزار سازمانی «ساده‌سازی» به معنای حذف قابلیت‌ها نیست، بلکه به معنای مرتب کردن پیچیدگی است. کاربری که هر روز صدها پرونده را بررسی می‌کند، به صفحه‌ای خلوت با یک دکمه‌ی بزرگ نیاز ندارد؛ به صفحه‌ای نیاز دارد که اطلاعات لازم برای تصمیم را یک‌جا ببیند و بدون جابه‌جایی بین چند پنجره کارش را تمام کند.
چرا تجربه کاربری نرم‌افزارهای سازمانی معمولاً ضعیف است؟
در پروژه‌هایی که ما در دییر روی سیستم‌های داخلی سازمان‌ها کار کرده‌ایم، ریشه‌ی ضعف تجربه کاربری نرم‌افزارهای سازمانی تقریباً هیچ‌وقت «طراح بد» نبوده است. مشکل ساختاری است و از نحوه‌ی خرید، ساخت و توسعه‌ی این سیستم‌ها می‌آید:
- جدایی خریدار از کاربر: تصمیم خرید یا ساخت را مدیران می‌گیرند و فهرست قابلیت‌ها را مقایسه می‌کنند، نه تجربه‌ی روزمره‌ی اپراتوری که باید با سیستم کار کند.
- انباشت قابلیت‌ها: هر واحد سازمان در طول سال‌ها یک فیلد، یک دکمه یا یک گزارش اضافه خواسته و کسی مسئول یکپارچه نگه داشتن کل تجربه نبوده است.
- ساختار سازمانی در رابط کاربری: منوها بر اساس چارت سازمانی یا ساختار پایگاه داده چیده شده‌اند، نه بر اساس کاری که کاربر می‌خواهد انجام دهد.
- سیستم‌های قدیمی و وصله‌شده: بخش‌هایی از سیستم سال‌ها پیش ساخته شده و کسی جرئت دست زدن به آن را ندارد.
- نبود بازخورد واقعی: کاربر ناراضی نمی‌تواند محصول را ترک کند، پس نارضایتی‌اش در هیچ داشبوردی دیده نمی‌شود و به‌جای آن در قالب خطا، کندی و راه‌حل‌های دورزننده مثل فایل اکسل موازی ظاهر می‌شود.
وقتی این ریشه‌ها را بشناسید، می‌فهمید چرا بازطراحی ظاهری کافی نیست. تا زمانی که مسیرهای کاری، معماری اطلاعات و فرایند تصمیم‌گیری درباره‌ی قابلیت‌ها اصلاح نشود، یک پوسته‌ی تازه فقط همان مشکلات قبلی را با رنگ‌های جدید نشان می‌دهد.
طراحی برای کاربران حرفه‌ای (Power Users) چه اصولی دارد؟
بیشتر کاربران نرم‌افزار سازمانی پس از چند هفته به کاربر حرفه‌ای تبدیل می‌شوند. آن‌ها سیستم را از حفظ‌اند، الگوهای تکراری کارشان را می‌شناسند و بیش از هر چیز از کندی و کلیک‌های اضافه رنج می‌برند. طراحی برای این گروه با طراحی برای کاربر تازه‌کار فرق دارد، هرچند هر دو باید در یک سیستم پوشش داده شوند.
سرعت و میان‌برها
میان‌برهای صفحه‌کلید، جست‌وجوی سراسری، عملیات گروهی روی چند ردیف جدول، پر شدن خودکار فیلدها بر اساس انتخاب قبلی و حفظ موقعیت کاربر پس از بازگشت به فهرست، چیزهایی هستند که در یک اپ مصرفی جزئیات به حساب می‌آیند اما در سیستم سازمانی تفاوت بین یک روز کاری روان و یک روز فرساینده را می‌سازند.
تراکم اطلاعات کنترل‌شده
کاربر حرفه‌ای به صفحه‌های پرتراکم عادت دارد و آن را ترجیح می‌دهد، به شرط اینکه سلسله‌مراتب بصری روشن باشد. یعنی مهم‌ترین داده‌ها برجسته باشند، وضعیت‌ها با رنگ و برچسب ثابت نشان داده شوند و جزئیات کمتر مهم با یک کلیک در دسترس باشد. اصول طراحی داشبورد و جدول‌های داده در این بخش نقش اصلی را دارند.
پیش‌فرض‌های هوشمند و شخصی‌سازی محدود
ذخیره‌ی فیلترهای پرکاربرد، انتخاب ستون‌های جدول و نماهای ذخیره‌شده به هر نقش اجازه می‌دهد سیستم را با کار خودش تطبیق دهد. اما شخصی‌سازی بی‌حدومرز هم خطرناک است، چون آموزش، پشتیبانی و مستندسازی را سخت می‌کند. معمولاً بهتر است چند نمای استاندارد برای هر نقش طراحی شود و کاربر فقط در همان چارچوب تغییر ایجاد کند.
گردش‌کارهای پیچیده و چندنقشی را چطور طراحی کنیم؟
قلب هر نرم‌افزار سازمانی گردش‌کار است: درخواستی ثبت می‌شود، بین چند نقش دست‌به‌دست می‌شود، در هر مرحله داده‌ای به آن اضافه یا از آن کم می‌شود و در نهایت به نتیجه می‌رسد. بیشتر مشکلات UX در همین انتقال‌ها رخ می‌دهد، نه در تک‌صفحه‌ها.
اول نقشه‌ی کار، بعد صفحه
پیش از کشیدن هر وایرفریمی، گردش‌کار را با همه‌ی نقش‌ها، وضعیت‌ها و نقاط تصمیم‌گیری روی کاغذ بیاورید. ابزارهایی مثل نقشه‌ی سرویس و نقشه‌ی سفر مشتری در نسخه‌ی داخلی‌شان، یعنی نقشه‌ی سفر کارمند، کمک می‌کنند ببینید کار کجا متوقف می‌شود، کجا دوباره‌کاری اتفاق می‌افتد و کجا کاربر مجبور است اطلاعات را از سیستم دیگری کپی کند.
حالت‌های استثنا را جدی بگیرید
در سیستم‌های سازمانی، مسیر استثنا گاهی بخش بزرگی از کار روزانه است: درخواست ناقص که برگشت می‌خورد، تأییدکننده‌ای که در مرخصی است، سندی که باید اصلاح شود. اگر این حالت‌ها در طراحی دیده نشوند، کاربران راه‌حل‌های خودشان را می‌سازند و داده از سیستم بیرون می‌رود.
وضعیت همیشه روشن باشد
هر کاربر در هر لحظه باید بداند یک پرونده در چه مرحله‌ای است، منتظر چه کسی است و قدم بعدی او چیست. نوار وضعیت، تاریخچه‌ی تغییرات، ذخیره‌ی خودکار پیش‌نویس و پیام‌های خطای دقیق که بگویند چه چیزی را چطور اصلاح کنیم، از ابزارهای اصلی این شفافیت‌اند. معماری اطلاعات درست هم کمک می‌کند ناوبری بر اساس وظایف کاربر چیده شود، نه بر اساس جدول‌های پایگاه داده.
تحقیقات کاربر داخل سازمان چگونه انجام می‌شود؟
روش‌های تحقیقات کاربر در پروژه‌های سازمانی همان روش‌های آشنا هستند، اما اجرای آن‌ها چالش‌های خاص خودش را دارد. دسترسی به کاربران از مسیر مدیران می‌گذرد، کاربران ممکن است از گفتن انتقاد نگران باشند و داده‌های کاری محرمانه‌اند. تجربه‌ی ما نشان می‌دهد این چند روش بیشترین ارزش را دارند:
- مشاهده‌ی میدانی و سایه‌به‌سایه شدن: نشستن کنار کاربر در محیط واقعی کار نشان می‌دهد چه چیزی واقعاً اتفاق می‌افتد، نه آنچه در دستورالعمل نوشته شده.
- مصاحبه‌ی زمینه‌ای با نقش‌های مختلف: اپراتور، سرپرست، مدیر و واحد پشتیبانی هر کدام بخشی از تصویر را می‌بینند.
- تحلیل دورزننده‌ها: فایل‌های اکسل موازی، یادداشت‌های چسبیده به مانیتور و گروه‌های پیام‌رسان کاری، نقشه‌ی دقیق کمبودهای سیستم فعلی‌اند.
- بررسی داده‌های رفتاری و تیکت‌های پشتیبانی: لاگ استفاده و پرسش‌های پرتکرار نشان می‌دهد کاربران کجا گیر می‌کنند.
- تست کاربردپذیری با سناریوهای واقعی کار: با داده‌ی نمونه‌ای که شبیه داده‌ی واقعی است، نه با فرم‌های خالی.
یک نکته‌ی کلیدی این است که حتماً بین «آنچه مدیران می‌گویند کاربران انجام می‌دهند» و «آنچه کاربران واقعاً انجام می‌دهند» تمایز بگذارید. این فاصله تقریباً همیشه وجود دارد و بزرگ‌ترین فرصت‌های بهبود در همان جا پنهان است. اگر تیم داخلی شما فرصت یا مهارت اجرای این پژوهش‌ها را ندارد، یک تیم تحقیقات کاربر مستقل می‌تواند این بخش را مستقل و بی‌طرف انجام دهد.
با سیستم‌های قدیمی (Legacy) چه کنیم؟
کمتر سازمانی می‌تواند سیستم اصلی‌اش را یک‌شبه خاموش کند و سیستم تازه‌ای روشن کند. سیستم قدیمی با همه‌ی ضعف‌هایش، دانش سال‌ها کار سازمان را در خود دارد و کاربرانش حافظه‌ی عضلانی ساخته‌اند. به همین دلیل مدرن‌سازی تجربه کاربری نرم‌افزارهای سازمانی بیشتر شبیه بازسازی ساختمانی است که مردم هنوز در آن زندگی می‌کنند.
- مدرن‌سازی تدریجی: به‌جای جایگزینی کامل، پرکاربردترین یا دردسرسازترین گردش‌کارها را اول بازطراحی کنید و بقیه را مرحله‌به‌مرحله پیش ببرید.
- حفظ الگوهای ذهنی مفید: اصطلاحات، ترتیب فیلدها و میان‌برهایی که کاربران به آن عادت دارند و مشکلی ایجاد نمی‌کنند، بی‌دلیل تغییر نکنند.
- اجرای موازی و بازگشت‌پذیر: برای دوره‌ای کوتاه امکان استفاده از نسخه‌ی قدیم و جدید در کنار هم، ریسک پذیرش را کم می‌کند.
- لایه‌ی رابط روی هسته‌ی قدیمی: گاهی می‌توان پیش از بازنویسی کامل منطق پشتی، رابط کاربری تازه‌ای روی همان داده‌ها ساخت.
منطق کلی این مسیر با بازطراحی وبسایت شباهت دارد، اما ریسک آن بیشتر است، چون یک تغییر اشتباه می‌تواند کار روزانه‌ی یک واحد کامل را متوقف کند.
پذیرش و آموزش: وقتی کاربر مجبور به استفاده است
یک تصور اشتباه رایج این است که چون استفاده از نرم‌افزار سازمانی اجباری است، پذیرش آن تضمین‌شده است. در واقعیت، کاربری که سیستم را دوست ندارد آن را حداقلی و ناقص استفاده می‌کند، داده‌ها را دیر یا ناقص وارد می‌کند و کارهای اصلی را بیرون از سیستم انجام می‌دهد. نتیجه این است که سازمان هزینه‌ی سیستم را می‌پردازد اما داده‌ی قابل اتکایی از آن نمی‌گیرد.
برای افزایش پذیرش، کاربران کلیدی هر واحد را از همان مرحله‌ی تحقیق وارد پروژه کنید تا خودشان سفیر سیستم جدید شوند. آموزش را داخل محصول بیاورید: راهنمای مرحله‌به‌مرحله در اولین استفاده، توضیح کوتاه کنار فیلدهای حساس و حالت‌های خالی که بگویند قدم بعدی چیست. یادتان باشد هر ساعت آموزش کلاسی که برای کار با یک صفحه لازم است، معمولاً نشانه‌ی مشکلی در طراحی همان صفحه است.
در نرم‌افزار سازمانی، هر کلیک اضافه فقط یک کلیک نیست؛ ضرب در تعداد کاربران و تعداد دفعات تکرار در روز، به ساعت‌ها کار از دست‌رفته‌ی سازمان تبدیل می‌شود.
بازگشت سرمایه تجربه کاربری نرم‌افزارهای سازمانی را چطور بسنجیم؟
مزیت بزرگ پروژه‌های سازمانی این است که اثر UX در آن‌ها مستقیم‌تر از محصولات مصرفی قابل اندازه‌گیری است، چون به زمان و هزینه‌ی عملیات گره خورده است. کلید کار این است که پیش از شروع طراحی، وضعیت فعلی را اندازه بگیرید تا بعداً بتوانید مقایسه کنید.
- زمان انجام وظایف کلیدی: مثلاً مدت ثبت یک سفارش یا بررسی یک پرونده، پیش و پس از بازطراحی.
- نرخ خطا و دوباره‌کاری: تعداد فرم‌هایی که برگشت می‌خورند یا اصلاح می‌شوند.
- زمان رسیدن کارمند جدید به سرعت کار عادی: هرچه کوتاه‌تر، هزینه‌ی آموزش و جابه‌جایی نیرو کمتر.
- حجم درخواست‌های پشتیبانی داخلی: پرسش‌هایی که به خاطر ابهام رابط کاربری ایجاد می‌شوند.
- میزان استفاده‌ی واقعی: چه سهمی از کار در سیستم انجام می‌شود و چه سهمی بیرون از آن.
وقتی این سنجه‌ها را در تعداد کاربران و تعداد تکرار روزانه ضرب کنید، معمولاً تصویری روشن از ارزش مالی بهبود تجربه کاربری به دست می‌آید؛ تصویری که برای قانع کردن مدیران و گرفتن بودجه‌ی مراحل بعدی بسیار کارآمدتر از استدلال‌های کلی درباره‌ی «زیبایی» یا «مدرن بودن» است.
نقش دیزاین سیستم در یکپارچگی نرم‌افزارهای سازمانی
سازمان‌های بزرگ معمولاً ده‌ها سیستم داخلی دارند که هر کدام را تیمی جدا و در زمانی متفاوت ساخته است. کاربری که روزانه بین سه یا چهار سیستم جابه‌جا می‌شود، با سه یا چهار منطق متفاوت برای جدول، فیلتر، تاریخ و پیام خطا روبه‌روست. یک دیزاین سیستم سازمانی با کامپوننت‌های مشترک، الگوهای تعاملی ثابت و قواعد نوشتاری یکسان، این بار ذهنی را کم می‌کند، تجربه کاربری نرم‌افزارهای سازمانی را در کل مجموعه یکدست می‌سازد و توسعه‌ی سیستم‌های بعدی را هم سریع‌تر و کم‌هزینه‌تر می‌سازد.
برای نرم‌افزارهای سازمانی فارسی، این سیستم باید از ابتدا به راست‌چین بودن، اعداد فارسی و لاتین، تقویم شمسی، جدول‌های پرتراکم و فرم‌های طولانی فکر کرده باشد. این‌ها جزئیاتی هستند که در کیت‌های آماده‌ی خارجی معمولاً نادیده گرفته می‌شوند و بعداً هزینه‌ی زیادی برای اصلاح دارند.
چطور یک پروژه UX سازمانی را شروع کنیم؟
اگر قصد بهبود یک سیستم داخلی یا ساخت یک وب اپلیکیشن سازمانی تازه را دارید، به‌جای شروع با فهرست بلند قابلیت‌ها، از یک یا دو گردش‌کار پرتکرار و پرهزینه شروع کنید. وضعیت فعلی آن‌ها را بسنجید، با کاربران واقعی پژوهش کنید، راه‌حل را با نمونه‌ی اولیه تست کنید و پس از پیاده‌سازی دوباره اندازه بگیرید. این چرخه‌ی کوچک هم نتیجه‌ی ملموس می‌دهد و هم پشتوانه‌ی لازم برای ادامه‌ی کار را در سازمان می‌سازد.
ما در دییر در خدمات طراحی محصول و UI/UX این مسیر را از پژوهش در محل کار کاربران تا طراحی دیزاین سیستم و همراهی تیم توسعه پیش می‌بریم و نمونه‌هایی از تجربه‌مان در محصولات بزرگ را در بخش نمونه‌کارها می‌توانید ببینید.
سؤالات متداول
تفاوت UX سازمانی با UX محصولات B2C چیست؟
در محصولات B2C کاربر خودش محصول را انتخاب می‌کند و هدف اصلی جذب و نگه‌داشتن اوست. در نرم‌افزار سازمانی کاربر معمولاً مجبور به استفاده است و هدف، انجام سریع، دقیق و کم‌خطای کارهای تکراری و چندنقشی است.
آیا ساده کردن نرم‌افزار سازمانی یعنی حذف قابلیت‌ها؟
نه. کاربران حرفه‌ای به قابلیت‌ها نیاز دارند. ساده‌سازی یعنی مرتب کردن پیچیدگی، نمایش اطلاعات به ترتیب اهمیت و حذف مراحل و کلیک‌های غیرضروری، نه حذف ابزارهایی که کار واقعی به آن‌ها وابسته است.
تحقیقات کاربر در سازمان چقدر زمان می‌برد؟
به تعداد نقش‌ها، پراکندگی واحدها و دسترسی به کاربران بستگی دارد. معمولاً بهتر است پژوهش را روی یک یا دو گردش‌کار اولویت‌دار متمرکز کنید تا سریع‌تر به نتیجه برسید و دامنه را مرحله‌به‌مرحله گسترش دهید.
آیا باید سیستم قدیمی را کامل کنار بگذاریم؟
در بیشتر موارد نه. مدرن‌سازی تدریجی، یعنی بازطراحی گردش‌کارهای کلیدی یکی پس از دیگری، ریسک کمتری دارد، کار روزانه‌ی سازمان را متوقف نمی‌کند و فرصت می‌دهد هر مرحله با داده‌ی واقعی ارزیابی شود.
چطور مدیران را برای سرمایه‌گذاری روی UX قانع کنیم؟
با عدد. زمان انجام وظایف کلیدی، نرخ خطا، زمان آموزش و حجم درخواست‌های پشتیبانی را پیش از پروژه اندازه بگیرید و اثر بهبود آن‌ها را در تعداد کاربران و تکرار روزانه نشان دهید.
اگر سیستم سازمانی شما کند، پرخطا یا کم‌استفاده است و می‌خواهید بدانید از کجا باید شروع کرد، خوشحال می‌شویم درباره‌اش گفت‌وگو کنیم؛ کافی است درخواست همکاری را ثبت کنید.
