چطور کاربر رو مجبور نکنیم از شیرپوینت فرار کنه؟

واقعیت تلخ اینه که در خیلی از سازمان‌ها، شیرپوینت نه یک ابزار کمکی،
بلکه یک اجبار سازمانیه.

کاربر:

• فقط چون مجبور است واردش می‌شود

• فقط حداقل کار را انجام می‌دهد

• و به محض اینکه راه دور زدنش را پیدا کند… فرار می‌کند 😅

سؤال مهم این نیست که چرا کاربر SharePoint را دوست ندارد؛
سؤال درست این است:
ما چه کارهایی می‌کنیم که او را فراری می‌دهیم؟

اشتباه شماره ۱: SharePoint را برای سیستم می‌سازیم، نه انسان

بسیاری از پیاده‌سازی‌ها این‌طور شروع می‌شوند:

«بیایید اول لیست‌ها و ستون‌ها را طراحی کنیم»

در حالی که کاربر اصلاً با لیست و ستون کاری ندارد.
کاربر فقط می‌خواهد:

• درخواست ثبت کند

• وضعیتش را ببیند

• و کارش راه بیفتد

هرچیزی غیر از این، نویز است.

اشتباه شماره ۲: همه‌چیز را یک‌جا جلوی کاربر می‌ریزیم

فرم‌های ۲۰–۳۰ فیلدی، قاتل تجربه کاربر هستند.

کاربر وقتی وارد فرم می‌شود و با یک دیوار اطلاعات روبه‌رو می‌شود:

• مضطرب می‌شود

• تمرکزش را از دست می‌دهد

• یا فرم را نصفه رها می‌کند

کاربر نباید مجبور شود فکر کند سیستم چه می‌خواهد؛
سیستم باید بفهمد کاربر چه می‌خواهد.

اشتباه شماره ۳: زبان سیستم به‌جای زبان کاربر

عبارت‌هایی مثل:

• Status

• Category Code

• Ref ID

برای تیم IT عادی‌اند،
اما برای کاربر نهایی یعنی: «این سیستم مال من نیست».

زبان نامفهوم = فاصله
فاصله = فرار

اشتباه شماره ۴: نبود بازخورد واضح

کاربر فرم را Submit می‌کند…
هیچ اتفاقی نمی‌افتد.

نه پیام موفقیت،
نه شماره پیگیری،
نه اینکه مرحله بعد چیست.

در ذهن کاربر:

«نکنه ثبت نشد؟»

و کاربری که مطمئن نیست، اعتماد نمی‌کند.

راهکار اول: مسیر کاربر را کوتاه کن

از خودت بپرس:

• حداقل اطلاعات لازم چیست؟

• کدام فیلدها واقعاً ضروری‌اند؟

• کدام تصمیم را می‌توان بعداً گرفت؟

اصل طلایی:

هر چیزی که الآن لازم نیست، الآن نباید دیده شود.

راهکار دوم: SharePoint را هوشمند کن، نه شلوغ

با کمی JavaScript یا Power Platform:

• فیلدها شرطی نمایش داده شوند

• فرم‌ها واکنش‌گرا باشند

• خطاها قبل از Submit نشان داده شوند

این یعنی:
کاربر کمتر اشتباه می‌کند
سیستم کمتر اذیت می‌کند

راهکار سوم: به کاربر احترام بگذار (واقعاً)

احترام یعنی:

• پیام خطا را انسان‌گونه بنویسی

• به کاربر بگویی بعدش چه می‌شود

• مسیر برگشت داشته باشد

❌ «خطا در ثبت اطلاعات»
✅ «ثبت انجام نشد. لطفاً فیلد تاریخ را بررسی کنید.»

راهکار چهارم: SharePoint را نامرئی کن

بهترین تجربه کاربری زمانی اتفاق می‌افتد که:

کاربر اصلاً حس نکند دارد با SharePoint کار می‌کند.

او فقط:

• یک فرم ساده می‌بیند

• یک داشبورد شفاف

• یک مسیر مشخص

SharePoint باید پشت صحنه بماند.

راهکار پنجم: اول انسان، بعد تکنولوژی

قبل از هر توسعه:

• با کاربر صحبت کن

• رفتار واقعی‌اش را ببین

• مقاومتش را بفهم

خیلی وقت‌ها مشکل این نیست که SharePoint بد است؛
مشکل این است که هیچ‌کس از کاربر نپرسیده چه می‌خواهد.

نشانه‌های اینکه کاربر در حال فرار است 🚨

اگر این‌ها را دیدی، دیر شده:

• اکسل‌های شخصی موازی

• واتساپ به‌جای فرم

• تماس مستقیم به‌جای ثبت درخواست

• جمله‌ی معروف: «بی‌خیال، خودم درستش می‌کنم»

جمع‌بندی نهایی

کاربر از SharePoint فرار نمی‌کند؛
از تجربه بد فرار می‌کند.

SharePoint اگر:

• ساده باشد

• محترمانه رفتار کند

• کار را سریع راه بیندازد

نه‌تنها فراری نیست،
بلکه می‌شود ابزار اصلی کار روزانه.

چک‌لیست هشدار 🚨 مخصوص مدیران پروژه SharePoint

اگر حتی ۳ مورد از این‌ها رو دیدی، پروژه در خطره:

🔴 هشدارهای رفتاری

☐ کاربران فقط موقع اجبار وارد سیستم می‌شوند
☐ آموزش دیده‌اند، ولی باز سؤال‌های تکراری می‌پرسند
☐ کارها به‌صورت تلفنی یا واتساپی انجام می‌شود
☐ فایل اکسل شخصی کنار سیستم رسمی شکل گرفته

📌 این‌ها نشانه مقاومت پنهان کاربره، نه «ضعف آموزش».

🔴 هشدارهای طراحی

☐ فرم‌ها طولانی‌تر از ۱۰–۱۲ فیلد هستند
☐ همه فیلدها همیشه نمایش داده می‌شوند
☐ اصطلاحات سیستمی در UI دیده می‌شود
☐ کاربر بعد از Submit نمی‌داند چه اتفاقی افتاده

🔴 هشدارهای فنی

☐ هر تغییر کوچک نیاز به دخالت IT دارد
☐ اسکریپت‌ها بدون ساختار و مستند هستند
☐ Performance برای کاربر نهایی بررسی نشده
☐ تست واقعی با کاربر انجام نشده است

🔴 هشدار مدیریتی (خیلی مهم)

☐ پروژه فقط با واحد IT طراحی شده
☐ KPI پذیرش کاربر تعریف نشده
☐ موفقیت پروژه فقط «تحویل فنی» تلقی شده
☐ بازخورد کاربر نهایی جمع‌آوری نشده

جمع‌بندی مدیریتی

اگر پروژه‌ای:

تحویل شده ولی استفاده نمی‌شود
یعنی شکست خورده، حتی اگر از نظر فنی بی‌نقص باشد.

مثال واقعی: قبل و بعد از نجات یک پروژه SharePoint

سناریو سازمانی

سیستم ثبت درخواست خدمات داخلی در یک سازمان متوسط.

🔻 قبل (نسخه‌ای که کاربران ازش فرار می‌کردند)

• یک فرم ۲۸ فیلدی

• بدون ترتیب منطقی

• اصطلاحات کاملاً فنی

• هیچ پیام راهنما یا بازخورد

• فقط از دسکتاپ قابل استفاده

نتیجه واقعی:

• کاربران ترجیح می‌دادند تماس بگیرند

• مدیران درخواست‌ها را ناقص دریافت می‌کردند

• داده‌ها غیرقابل اعتماد بودند

🔺 بعد (نسخه‌ای که پذیرفته شد)

اقدامات کلیدی:

• فرم به ۳ مرحله ساده تقسیم شد

• فیلدها شرطی شدند (JavaScript)

• زبان فرم کاملاً انسانی شد

• پیام موفقیت + شماره پیگیری اضافه شد

• نسخه موبایل‌پسند طراحی شد

📈 نتیجه قابل اندازه‌گیری

• افزایش ۷۰٪ استفاده واقعی

• کاهش تماس‌های مستقیم با واحد پشتیبانی

• افزایش دقت داده‌ها

• رضایت کاربران غیر IT

📌 نکته مهم:
هیچ ابزار جدیدی اضافه نشد؛ فقط طراحی عاقلانه.

درس نهایی برای مدیران پروژه

موفقیت پروژه SharePoint یعنی:

• کاربر بدون آموزش خاص ازش استفاده کند

• بدون اجبار وارد شود

• و بدون فرار، کارش راه بیفتد

اگر کاربر فرار می‌کند،
مشکل سیستم نیست—تصمیم‌های ماست.