نوشته‌ها

مقدمه

در طراحی تجربه کاربری، «دقت بدون همدلی» یکی از چالش‌های مهمی است که بسیاری از سازمان‌ها با آن مواجه‌اند. Adrian Reed در مقاله‌ای با همین عنوان، به بررسی شکاف میان دقت فنی و وضوح انسانی در طراحی خدمات و فرآیندهای سازمانی می‌پردازد. او معتقد است که بسیاری از تجربه‌های مشتریان با زبان‌هایی طراحی شده‌اند که هیچ ارتباطی با درک واقعی کاربران ندارند. این مقاله ترجمه‌ای است از نسخه اصلی منتشرشده توسط دیجیراتی

تجربه واقعی مشتری و تأثیر زبان فنی

در طراحی تجربه کاربری، استفاده از اصطلاحات تخصصی مانند «MSISDN» به‌جای «شماره تلفن» می‌تواند باعث سردرگمی کاربران شود. Reed با مثال‌هایی از شرکت‌های بزرگ نشان می‌دهد که این نوع دقت فنی، بدون در نظر گرفتن دانش عمومی کاربران، منجر به افزایش تماس‌های پشتیبانی و نارضایتی می‌شود. این موضوع نشان می‌دهد که طراحی تجربه کاربری باید بر پایه وضوح و همدلی باشد.

دقت فنی در مقابل وضوح انسانی

Reed تأکید می‌کند که دقت در زبان زمانی مؤثر است که دانش مشترک وجود داشته باشد. در محیط‌های داخلی سازمان‌ها، استفاده از اصطلاحات تخصصی قابل قبول است، اما وقتی این زبان به سمت مشتریان منتقل می‌شود، باید با همدلی و وضوح جایگزین شود. طراحی تجربه کاربری بدون همدلی، باعث ایجاد فاصله میان سازمان و مشتری می‌شود.


آموزش مشتری یا همدلی با او؟

یکی از نکات طنزآمیز مقاله، نقد این باور اشتباه است که «باید مشتری را آموزش داد». در واقع، مشتریان انتظار همدلی دارند، نه آموزش. استفاده از زبان ساده و قابل فهم، به‌جای اصطلاحات پیچیده، تجربه بهتری برای کاربران رقم می‌زند. طراحی تجربه کاربری باید بر اساس نیازهای واقعی کاربران شکل گیرد.

نتیجه‌گیری: صدای مشتری را جدی بگیریم

برای جلوگیری از مشکلات ناشی از دقت بدون همدلی، سازمان‌ها باید صدای مشتری را در مراحل کشف، طراحی و اجرا وارد کنند. ایجاد مکانیزم‌های بازخورد، تست‌های کاربردپذیری و دادن اختیار به کارکنان خدمات مشتری برای اعمال تغییرات، از جمله راهکارهای مؤثر هستند.

📌 برای آشنایی بیشتر با اصول طراحی همدلانه، مقاله مثال BPMN از فرآیند دریافت وام را نیز مطالعه کنید.

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

📚 اطلاعات منبع مقاله

این مقاله ترجمه‌ای است از نوشته‌ی Adrian Reed، مشاور ارشد در شرکت Blackmetric Business Solutions، که در زمینه تحلیل کسب‌وکار فعالیت دارد. عنوان مقاله اصلی: “Precision Without Empathy: When ‘Correct’ Isn’t ‘Clear’” تاریخ انتشار: ۱۴ جولای ۲۰۲۵ منبع: www.adrianreed.co.uk

 

فرآیند حال حاضر در مورد مدیریت تغییرات بوده که بر حسب Change Management مبتنی بر استاندارد ITIL ایجاد گردیده است.

مدیریت تغییرات در ITIL
مدیریت تغییرات در ITIL

شرح فرآیند

Submit

این فرآیند می تواند از سوی هر واحدی آغاز شود، که اصطلاحا نام آنرا واحد “درخواست کننده” می نامیم. با باز کردن فرم تغییرات و انتخاب از روی الگوهای پیش فرض و یا انتخاب گزینه سایر و تکمیل فرم مربوطه (با توجه به اطلاعات مورد نیاز) فرآیند آغاز می گردد. در مرحله بعد در صورت انتخاب تمپلیت، مقادیر پیش فرض در فرم اطلاعاتی مربوطه قرار می گیرد. پس از آن درخواست کننده نسبت به تکمیل اطلاعات فرم تغییر اقدام می نماید. پس از ثبت، درخواست برای واحد مدیریت تغییرات ارسال و این واحد نسبت به بررسی آن اقدام می نماید. در صورت عدم تائید درخواست، توسط واحد مدیریت تغییرات، این موضوع به درخواست کننده اطلاع رسانی شده و فرآیند خاتمه می یابد.

Approval

در صورتیکه درخواست مورد تائید این واحد باشد به صورت سیستمی تعداد گروه هایی که می بایست تغییر را تائید نمایند (“تائید کنندگان”) تعیین می شوند. در مرحله بعد و پس از مشخص شدن تعداد گروه های “تایید کنندگان” افراد هر یک از گروه ها به صورت سیستمی جهت تایید مشخص می گردند. درخواست تغییر مورد نظر توسط تائید کنندگان بررسی و در صورتیکه نیاز به اطلاعات بیشتر برای بررسی داشته باشند فرم تغییر به درخواست کننده ارجاع داده می شود تا نسبت به ثبت اطلاعات تکمیلی مورد نیاز اقدام نماید. پس از آن مجددا برای اخذ تائیدات لازم برای واحدهای تائید کننده ارسال می گردد.


بیشتر بخوانید:


در حالتی که اطلاعات کافی بوده و تمامی گروه های تائید کننده درخواست تغییر را تائید نمایند. این تغییر به کلیه افراد سازمان اطلاع رسانی خواهد شد. (در فرآیند Change Management این موضوع به کلیه واحدها اعلام می گردد تا اگر واحد دیگری فعالیت همزمانی با درخواست مربوطه داشته باشد، آن درخواست نیز قابل اجرا بوده و در وقت و هزینه صرفه جویی گردد).

Assign

در مرحله بعد درخواست تغییر برای “اقدام کننده” (واحدی که تغییر مورد نظر را می بایست انجام دهد.) و همچنین “تحویل گیرنده” (واحدی که پس از تغییر موارد را بررسی و تحویل خواهد گرفت.) به صورت موازی اطلاع رسانی می گردد.

In Progress

پس از هماهنگی این دو واحد واحد اقدام کننده شروع به اعمال تغییرات مورد نیاز می نماید. شروع به تغییرات مجددا برای تمامی واحدهای ذینفع اطلاع رسانی می گردد.

Update Tools

پس از اعمال تغییرات تیم تحویل گیرنده اقدام به بررسی و تست تغییرات رخ داده کرده. در صورت عدم وجود مشکل، اصطلاحا اقدام به تحویل گرفتن تغییرات مورد نظر می نماید و اطلاع رسانی آن به تمامی واحدهای ذینفع انجام می گردد. واحدهای ذینفع نیز دارای تسک های خاص خود بوده که نیاز به بررسی و انجام آن ها می باشد. پس از اتمام آن ها فرآیند تغییر خواسته شده به اتمام می رسد. حالتی نیز در برخی موارد رخ می دهد که در آن واحد تحولی گیرنده نسبت به تغییر اعمال شده نظر منفی دارد.

در این حالت اگر زمان برای انجام تغییرات باقی مانده باشد که مجددا به تیم اقدام کننده ارجاع تا نسبت به رفع مشکلات اقدام نماید و اگر زمانی برای تغییرات باقی نمانده باشد اطلاع رسانی به ذینفعان انجام شده و درخواست تغییر بسته می شود.

pending close

واحدمدیریت تغییرات نتیجه کارهای انجام شده در هر واحد را بررسی می نماید. زمانی که از صحت اطلاعات اطمینان بدست آورد درخواست را پایان میدهد.

Release

زمانی که درخواست می خواهد بسته شود، به تمام ذینفعان فرآیند اطلاع رسانی صورت خواهد گرفت

Resubmit

در فرآیند ذکر شده حالتی وجود دارد که تغییرات به صورت فورس می بایست انجام شده و فرصت گرفتن تائیدات مورد نیاز نمی باشد. در این حالت درخواست تغییر بدون تائید واحد مدیریت تغییرات و واحدهای دیگر وارد فاز اجرایی شده و اطلاع رسانی جهت ارسال تغییر به واحد اقدام کننده و تحویل گیرنده و دیگر واحدهای ذینفع انجام می پذیرد.

یکی از اهداف فرآیند Change Management که سعی شده است در این فرآیند درنظر گرفته شود حفظ اصول و استنداردهای ITIL می باشد.