چطور پلتفرمی بسازیم که تیم واقعاً از آن استفاده کند؟

یک پروژه نرم‌افزاری می‌تواند از نظر فنی کاملاً موفق باشد.

سرورها پایدارند.

Featureها تحویل شده‌اند.

امنیت درست پیاده شده.

رابط کاربری هم مدرن و تمیز است.

اما چند هفته بعد یک اتفاق عجیب می‌افتد:

کاربران هنوز فایل Excel قبلی را باز می‌کنند.

اطلاعات را اول روی کاغذ می‌نویسند و بعد وارد سیستم می‌کنند.

برای انجام یک کار ساده به همکارشان پیام می‌دهند.

یا بدتر؛ بخشی از تیم اصلاً وارد پلتفرم نمی‌شود.

از نظر فنی، محصول Live شده است.

از نظر کسب‌وکار، هنوز Adoption اتفاق نیفتاده.

این تفاوت مهم است.

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

راهنمای GOV.UK برای سرویس‌های داخلی صریحاً می‌گوید کارکنان هم کاربر هستند و سرویس‌های داخلی باید مثل سرویس‌های عمومی، ساده، قابل‌استفاده، امن، Accessible و قابل‌بهبود طراحی شوند. این راهنما همچنین اشاره می‌کند سرویس داخلی خوب می‌تواند هزینه آموزش و خطا را کاهش دهد و زمان بیشتری برای انجام کار اصلی باقی بگذارد.

پس سؤال اصلی این نیست:

«چطور یک پلتفرم خوب طراحی کنیم؟»

سؤال بهتر این است:

«چطور کاری کنیم این پلتفرم واقعاً وارد جریان روزمره تیم شود؟»

از صفحه شروع نکنید؛ از کار شروع کنید

یکی از اشتباه‌های رایج در شروع پروژه این است که جلسه اول درباره Dashboard باشد.

چه کارت‌هایی داشته باشیم؟

منوی سمت راست باشد یا چپ؟

چه نموداری روی صفحه اول دیده شود؟

این سؤال‌ها مهم‌اند.

اما نه در ابتدا.

قبل از طراحی صفحه باید بدانیم کاربر در واقعیت می‌خواهد چه کاری را تمام کند.

مثلاً کاربر سیستم فروش شاید هدفش این نباشد که:

وارد صفحه مشتریان شود.

هدف واقعی او ممکن است این باشد:

سریع بفهمد مشتری آخرین بار چه چیزی خریده و الان باید چه پیگیری‌ای انجام دهد.

کاربر انبار شاید نخواهد:

فرم خروج کالا را تکمیل کند.

می‌خواهد:

کالا را با کمترین خطا تحویل دهد و مطمئن باشد موجودی درست ثبت شده است.

GOV.UK در Service Standard توصیه می‌کند طراحی از شناخت عمیق کاربر، Context و مسئله‌ای که می‌خواهد حل کند شروع شود، نه از یک فناوری یا Solution از پیش انتخاب‌شده. راهنمای آن در ژانویه ۲۰۲۶ حتی صراحتاً اضافه کرده که این اصل درباره فناوری‌های AI هم صدق می‌کند.

پس قبل از Wireframe باید بدانیم:

کاربر امروز دقیقاً چه کاری انجام می‌دهد؟

Workflow واقعی را ببینید، نه Workflow داخل جلسه را

وقتی از مدیر یک واحد می‌پرسید:

فرایند ثبت سفارش چگونه است؟

ممکن است یک Workflow تمیز و منطقی توضیح دهد.

اما وقتی کنار کاربر واقعی می‌نشینید، چیزهای دیگری می‌بینید.

اطلاعات از WhatsApp می‌آید.

یک فایل Excel وسط فرایند وجود دارد.

کاربر برای پیدا کردن کد مشتری از سیستم دیگری استفاده می‌کند.

بعضی اطلاعات را از حفظ وارد می‌کند.

برای یک Exception خاص به همکارش زنگ می‌زند.

و مرحله‌ای که در مستندات دو دقیقه به نظر می‌رسد، در واقع ۲۰ دقیقه طول می‌کشد.

به همین دلیل User Research فقط سؤال‌پرسیدن نیست.

Observation اهمیت زیادی دارد.

راهنمای User Research دولت بریتانیا پیشنهاد می‌کند تیم‌ها بفهمند کاربران چه کسانی هستند، چه کاری می‌خواهند انجام دهند، امروز چگونه انجامش می‌دهند و شرایط واقعی کار چه اثری روی رفتارشان دارد. همچنین Research را یک فعالیت مداوم می‌داند، نه کاری که فقط ابتدای پروژه انجام شود.

گاهی بهترین Requirement را کاربر به شما نمی‌گوید.

خودتان هنگام کارکردنش می‌بینید.

فرایند بد را فقط دیجیتالی نکنید

فرض کنید برای تأیید یک درخواست، امروز شش امضا لازم است.

ساده‌ترین Digital Transformation این است که همان شش مرحله را وارد نرم‌افزار کنیم.

حالا به‌جای شش امضای کاغذی، شش Approval دیجیتال داریم.

آیا فرایند بهتر شده؟

شاید فقط دیجیتالی شده باشد.

قبل از ساخت Workflow باید بپرسیم:

• این مرحله چرا وجود دارد؟
• آیا هنوز لازم است؟
• چه Riskی را کنترل می‌کند؟
• آیا می‌توان دو مرحله را یکی کرد؟
• آیا بخشی از تصمیم قابل‌اتوماسیون است؟
• آیا همه درخواست‌ها واقعاً باید همین مسیر را طی کنند؟

راهنمای GOV.UK برای سرویس‌های داخلی نیز هشدار می‌دهد که نباید صرفاً فرض کنیم یک فرایند فعلی همان User Need است؛ باید بررسی کرد خود فرایند لازم است یا می‌تواند بهتر شود.

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

برای نقش‌ها طراحی کنید، نه برای «کاربر»

در نرم‌افزار سازمانی چیزی به نام یک User عمومی اغلب وجود ندارد.

مدیر فروش و کارشناس فروش ممکن است وارد یک سیستم شوند، اما نیاز یکسانی ندارند.

کارشناس شاید روزانه ۱۰۰ بار:

ثبت، جست‌وجو و ویرایش

انجام دهد.

مدیر شاید هفته‌ای چند بار:

بررسی، مقایسه و تأیید

کند.

کارشناس مالی به اطلاعات دقیق تراکنش نیاز دارد.

مدیرعامل شاید فقط Exception و Trend را بخواهد.

اگر برای همه یک Dashboard و یک Navigation طراحی کنیم، احتمال زیادی وجود دارد که برای هیچ‌کس واقعاً خوب نباشد.

پس باید Roleها را از چند جهت بشناسیم:

• چه Taskهایی دارند؟
• کدام Task پرتکرار است؟
• چه اطلاعاتی باید ببینند؟
• چه چیزی را نباید ببینند؟
• کجا تصمیم می‌گیرند؟
• چه چیزی برایشان Urgent است؟
• و چه کاری فقط ماهی یک بار انجام می‌دهند؟

Permission فقط مسئله Security نیست؛ روی تجربه کاربری هم اثر دارد.

کاربر نباید با ده‌ها Feature روبه‌رو شود که هیچ‌وقت اجازه یا نیاز استفاده از آن‌ها را ندارد.

پرتکرارترین کار را کوتاه‌ترین مسیر کنید

در یک سایت عمومی شاید کاربر هر ماه یک بار وارد شود.

در نرم‌افزار سازمانی ممکن است یک کاربر روزی ۸۰ بار یک عملیات مشابه انجام دهد.

یک Click اضافه شاید در تست اولیه ناچیز به نظر برسد.

اما اگر:

۸۰ بار در روز × ۲۰۰ روز کاری × ۱۰۰ کاربر

تکرار شود، دیگر ناچیز نیست.

به همین دلیل Enterprise UX باید به Frequency حساس باشد.

برای Taskهای پرتکرار، مواردی مثل این‌ها اهمیت پیدا می‌کنند:

• Keyboard Shortcut
• Bulk Action
• Defaultهای هوشمند
• آخرین انتخاب‌ها
• Search سریع
• Filterهای ذخیره‌شده
• Copy / Duplicate
• Inline Edit
• و کاهش Navigation غیرضروری

راهنمای GOV.UK درباره سرویس‌های داخلی هم دقیقاً به این تفاوت اشاره می‌کند: کاربران Admin ممکن است مجبور باشند Taskها را سریع و پشت سر هم انجام دهند یا میان آن‌ها مرتب جابه‌جا شوند؛ بنابراین الگوی مناسب برای یک سرویس عمومی الزاماً برای یک سیستم داخلی پرتکرار مناسب نیست.

یک سؤال خوب هنگام طراحی این است:

کاربر این کار را چند بار در روز انجام می‌دهد؟

گاهی همین سؤال اولویت کل Interface را تغییر می‌دهد.

هر چیزی که وجود دارد نباید همیشه دیده شود

نرم‌افزار سازمانی معمولاً پیچیده است.

Roleهای مختلف.

تنظیمات زیاد.

حالت‌های استثنا.

Workflowهای مختلف.

قوانین سازمان.

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

اگر یک فرم ۳۵ فیلد دارد ولی برای ۹۰ درصد درخواست‌ها فقط ۱۰ فیلد لازم است، شاید بقیه بتوانند فقط زمانی ظاهر شوند که واقعاً نیازند.

اگر Advanced Settings فقط برای Administrator استفاده می‌شوند، لازم نیست کاربر عادی هر روز آن‌ها را ببیند.

این همان جایی است که Progressive Disclosure ارزش پیدا می‌کند:

ابتدا آنچه اکنون لازم است.

جزئیات بیشتر وقتی لازم شد.

هدف پنهان‌کردن Capability نیست.

هدف مدیریت Attention کاربر است.

کاربر نباید برای پیدا کردن یک چیز مهم، از میان چیزهایی عبور کند که امروز هیچ اهمیتی ندارند.

Consistency از خلاقیت مهم‌تر است

اگر دکمه Save در یک صفحه سبز، در صفحه بعد آبی و در صفحه سوم با آیکون نامشخص باشد، کاربر هر بار بخشی از Interface را دوباره یاد می‌گیرد.

همین مسئله درباره:

• Label
• Navigation
• Icon
• Table
• Filter
• Modal
• Error
• Date Format
• و Actionها

وجود دارد.

W3C در راهنمای Cognitive Accessibility روی Labelهای ثابت، رفتار قابل‌پیش‌بینی، Navigation روشن و Design سازگار تأکید می‌کند، چون تغییرهای غیرمنتظره و الگوهای متفاوت می‌توانند استفاده از محصول را سخت‌تر کنند.

در پلتفرم سازمانی، Design System فقط برای زیبایی نیست.

باعث می‌شود کاربر بتواند بخشی از رفتار نرم‌افزار را حدس بزند.

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

از زبان کاربران استفاده کنید

کاربر نباید اصطلاحات Architecture شما را یاد بگیرد تا بتواند کارش را انجام دهد.

اگر داخل شرکت همه می‌گویند:

«درخواست خرید»

اما نرم‌افزار نوشته:

Procurement Acquisition Entity

مشکل از کاربر نیست.

نام‌گذاری باید تا جای ممکن با زبان واقعی Domain هماهنگ باشد.

GOV.UK نیز در اصول طراحی خود توصیه می‌کند سرویس از همان زبانی استفاده کند که کاربران می‌شناسند و می‌فهمند.

این مورد به‌خصوص در نرم‌افزارهای تخصصی اهمیت دارد.

اصطلاح فنی همیشه بد نیست.

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

هدف ساده‌سازی بی‌دلیل نیست.

هدف:

حرف‌زدن به زبان خود کار است.

Search و Filter در سیستم‌های بزرگ Feature جانبی نیستند

وقتی ۳۰ مشتری دارید، List ساده جواب می‌دهد.

وقتی ۳۰۰ هزار رکورد دارید، Navigation معمولی دیگر کافی نیست.

در پلتفرم‌های سازمانی، Search و Filter اغلب جزئی از Workflow اصلی‌اند.

کاربر باید بتواند:

• با چند نوع Identifier جست‌وجو کند.
• Filterهای ترکیبی بسازد.
• نتیجه را Sort کند.
• Filter پرتکرار را ذخیره کند.
• نتیجه را Export کند، اگر مجاز است.
• و بعد از بازکردن یک رکورد، Context قبلی خودش را از دست ندهد.

این‌ها ممکن است Featureهای هیجان‌انگیزی برای Demo نباشند.

اما همان چیزهایی هستند که بعد از سه ماه تعیین می‌کنند تیم سیستم را دوست دارد یا از آن فرار می‌کند.

ورود دوباره اطلاعات یکی از سریع‌ترین راه‌های کشتن Adoption است

فرض کنید اطلاعات مشتری داخل CRM وجود دارد.

اما کاربر برای ساخت پیش‌فاکتور دوباره باید همان اطلاعات را وارد کند.

بعد اطلاعات پیش‌فاکتور برای حسابداری دوباره ثبت می‌شود.

بعد شماره سند دستی به CRM برمی‌گردد.

از نگاه معماری شاید سه System of Record جدا داشته باشیم.

از نگاه کاربر:

چرا باید یک چیز را سه بار بنویسم؟

اینجاست که Integration مستقیماً تبدیل به UX می‌شود.

API، Event و Integration فقط موضوع Backend نیستند.

اگر بتوانند Copy-Paste و ورود دوباره اطلاعات را حذف کنند، تجربه روزانه کاربر را تغییر می‌دهند.

W3C حتی در WCAG 2.2 معیار جدیدی با عنوان Redundant Entry اضافه کرده که هدفش کاهش نیاز کاربران به واردکردن دوباره اطلاعات در یک Process است.

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

Error Message باید بگوید حالا چه کار کنیم

این:

Error 1048

برای Developer شاید اطلاعاتی داشته باشد.

برای کاربر تقریباً هیچ.

حتی:

عملیات ناموفق بود.

کمک زیادی نمی‌کند.

Error خوب باید تا جای ممکن جواب دهد:

• چه اتفاقی افتاد؟
• چرا؟
• چه چیزی را باید اصلاح کنم؟
• آیا اطلاعات قبلی من حفظ شده؟
• می‌توانم دوباره تلاش کنم؟
• اگر حل نشد، از کجا کمک بگیرم؟

مثلاً:

«شماره مشتری پیدا نشد. شماره را بررسی کنید یا مشتری جدید بسازید.»

از:

Customer Reference Exception

خیلی مفیدتر است.

W3C در راهنمای Cognitive Accessibility نیز روی طراحی‌ای تأکید می‌کند که احتمال Error را کاهش دهد و اصلاح خطا را برای کاربر ساده کند.

سرعت بخشی از UX است

یک صفحه می‌تواند زیبا باشد و هنوز تجربه بدی داشته باشد.

اگر هر Search شش ثانیه طول بکشد.

اگر Save بدون Feedback بماند.

اگر جدول بزرگ Freeze شود.

اگر کاربر بعد از کلیک نداند درخواست ثبت شده یا نه.

Performance در سیستم سازمانی فقط Metric فنی نیست.

روی رفتار کاربر اثر می‌گذارد.

وقتی سیستم کند و غیرقابل‌اعتماد باشد، کاربران Workaround می‌سازند.

Excel.

پیام‌رسان.

کاغذ.

یا ذخیره اطلاعات برای «بعداً که سیستم بهتر شد».

اعتماد خیلی آرام ساخته می‌شود و با چند تجربه بد سریع از بین می‌رود.

Accessibility را Feature اضافه آخر پروژه نبینید

Accessibility فقط موضوع کاربران نابینا نیست.

افراد ممکن است محدودیت بینایی، حرکتی، شناختی یا شرایط موقتی داشته باشند.

یا اصلاً:

• روی Laptop کوچک کار کنند.
• در محیط شلوغ باشند.
• با Keyboard سریع‌تر باشند.
• سن بالاتری داشته باشند.
• یا مجبور باشند ساعت‌ها در روز از همان سیستم استفاده کنند.

W3C در WCAG 2.2 استانداردهای قابل‌آزمایشی برای دسترس‌پذیری ارائه می‌کند و توصیه می‌کند در سیاست‌های جدید از نسخه جاری WCAG استفاده شود. این نسخه موضوعاتی مثل Keyboard Focus، Target Size، Dragging، Consistent Help، Redundant Entry و Accessible Authentication را نیز پوشش می‌دهد.

نکته جالب این است که بسیاری از این تصمیم‌ها تجربه همه کاربران را بهتر می‌کنند.

Contrast بهتر.

Label روشن.

Keyboard Navigation.

Target قابل کلیک مناسب.

Form ساده‌تر.

Error قابل اصلاح.

این‌ها فقط Accessibility Feature نیستند.

ویژگی‌های یک Interface خوب‌اند.

UAT نباید فقط یعنی «Feature کار می‌کند»

User Acceptance Testing گاهی تبدیل می‌شود به یک Checklist فنی:

دکمه Save کار کرد؟

بله.

Report باز شد؟

بله.

Login انجام شد؟

بله.

اما UAT واقعی باید سؤال دیگری هم بپرسد:

آیا کاربر می‌تواند کار واقعی خودش را با این سیستم انجام دهد؟

بهتر است Scenarioهای واقعی داشته باشیم.

مثلاً:

«مشتری تماس گرفته، می‌خواهد وضعیت سفارش دیروزش را بداند و هم‌زمان آدرس تحویل را تغییر دهد.»

بعد ببینیم کاربر:

• از کجا شروع می‌کند؟
• کجا مکث می‌کند؟
• کجا اشتباه می‌کند؟
• چه اطلاعاتی پیدا نمی‌کند؟
• به چه Workaroundی برمی‌گردد؟

GOV.UK نیز توصیه می‌کند علاوه بر Technical Testing، Usability سرویس مرتب تست شود و افراد واقعی هرچه زودتر در چرخه توسعه وارد شوند.

آموزش لازم است؛ اما نباید UX بد را جبران کند

گاهی برای هر مشکل Interface یک جواب داریم:

در آموزش توضیح می‌دهیم.

اگر برای Save کردن یک فرم به آموزش ۲۰ دقیقه‌ای نیاز است، شاید مشکل آموزش نیست.

با این حال سیستم سازمانی می‌تواند پیچیدگی واقعی داشته باشد و Training بخشی طبیعی از Rollout است.

Microsoft در راهنمای Change Management برای Dynamics تأکید می‌کند تجربه آموزش کاربران باید اندازه‌گیری شود و Feedback Loop برای بهبود Training وجود داشته باشد، چون آموزش در پذیرش فرایند و سیستم جدید نقش دارد.

آموزش خوب می‌تواند ترکیبی باشد از:

• جلسه کوتاه Role-based
• ویدئوهای دو تا پنج دقیقه‌ای
• راهنمای داخل خود محصول
• Help Contextual
• Documentation قابل جست‌وجو
• نمونه سناریو
• و Super Userهای داخلی

مهم این است که کاربر مجبور نباشد یک PDF صدصفحه‌ای را بخواند تا یک Task روزمره را انجام دهد.

Rollout فقط یک Deployment فنی نیست

می‌توان بهترین نرم‌افزار دنیا را ساعت ۸ صبح دوشنبه برای ۵۰۰ کارمند فعال کرد و امیدوار بود همه خوشحال شوند.

احتمالاً اتفاق جالبی می‌افتد.

Change Management اهمیت دارد.

کاربران باید بدانند:

• چرا این سیستم آمده؟
• چه چیزی تغییر می‌کند؟
• از چه تاریخی؟
• چه چیزی بهتر می‌شود؟
• سیستم قبلی تا چه زمانی وجود دارد؟
• اگر سؤال داشتند کجا بروند؟
• و Feedbackشان چه می‌شود؟

Microsoft در Adoption Guidance فعلی Power Platform، موفقیت Adoption را فقط مسئله فنی نمی‌داند و روی Vision، Metric، Leadership Sponsorship، Governance، Training، Support و Community تأکید می‌کند. نسخه این Guidance در اوت ۲۰۲۶ به‌روزرسانی شده است.

Adoption یک پروژه مشترک Product + Technology + People است.

Championهای داخلی می‌توانند از تیم IT مؤثرتر باشند

در هر واحد معمولاً افرادی وجود دارند که:

• فرایند را خوب می‌شناسند.
• همکاران به آن‌ها اعتماد دارند.
• فناوری را سریع یاد می‌گیرند.
• و بقیه در صورت مشکل اول از آن‌ها سؤال می‌کنند.

این افراد می‌توانند Champion یا Super User باشند.

نقششان فقط آموزش نیست.

Feedback می‌دهند.

Issueهای واقعی را زود پیدا می‌کنند.

Feature جدید را معرفی می‌کنند.

و بین تیم Product و کاربران ترجمه ایجاد می‌کنند.

Microsoft در مدل Center of Excellence خود نیز Power Platform Championها را افرادی معرفی می‌کند که Adoption را ترویج می‌کنند و Feedback واقعی درباره فرایندها و نیاز به Support به تیم مرکزی می‌رسانند.

گاهی بهترین Ambassador سیستم کسی نیست که آن را ساخته.

کسی است که هر روز با آن کار می‌کند.

Adoption را با Login اندازه نگیرید

اینکه ۸۰ درصد کاربران یک بار وارد سیستم شده‌اند، چندان چیزی درباره موفقیت محصول نمی‌گوید.

ممکن است فقط Login کرده باشند چون Manager گفته است.

Metricهای مفیدتر بسته به محصول می‌توانند شامل این‌ها باشند:

Active Users

چه درصدی از کاربران واجد شرایط واقعاً فعال‌اند؟

Microsoft در Usage Analytics خودش نیز بین Enabled User، Active User، Returning User و First-time User تفاوت می‌گذارد تا Adoption فقط بر اساس تعداد Accountها سنجیده نشود.

Returning Users

چند نفر دوباره برمی‌گردند؟

این Metric در بسیاری از سیستم‌ها از Login اولیه معنی‌دارتر است.

Task Completion Rate

چه درصدی Task اصلی را با موفقیت تمام می‌کنند؟

Time on Task

انجام یک کار کلیدی چقدر زمان می‌برد؟

Error / Rework Rate

چند درصد عملیات نیاز به اصلاح دارد؟

Feature Adoption

Feature مهمی که ساخته‌ایم واقعاً استفاده می‌شود؟

Old Process Usage

چند نفر هنوز از Excel، Email یا سیستم قدیمی استفاده می‌کنند؟

Support Volume

کاربران بیشتر درباره چه چیزی سؤال یا Ticket ثبت می‌کنند؟

User Satisfaction

تجربه خود کاربران چیست؟

راهنمای Performance Measurement دولت بریتانیا نیز Completion Rate، User Satisfaction و Digital Take-up را جزو شاخص‌های اصلی می‌داند و تأکید می‌کند Analytics باید همراه User Research استفاده شود.

Averageها ممکن است مشکل یک گروه را پنهان کنند

فرض کنید Completion Rate کلی ۹۲ درصد است.

خوب به نظر می‌رسد.

اما وقتی Segment می‌کنیم:

کاربران قدیمی: ۹۷٪

کاربران جدید: ۶۴٪

حالا داستان عوض می‌شود.

یا:

Desktop: ۹۶٪

Tablet: ۶۸٪

یا:

واحد فروش: ۹۵٪

واحد عملیات: ۷۰٪

GOV.UK در راهنمای Performance Metrics توصیه می‌کند داده‌ها Segment شوند، چون Average کلی می‌تواند تفاوت رفتار گروه‌ها را پنهان کند. همچنین توصیه می‌کند Baseline ساخته شود و عملکرد به‌صورت مداوم در طول زمان بررسی شود.

Metric خوب فقط جواب نمی‌دهد:

چه اتفاقی افتاد؟

کمک می‌کند بفهمیم:

برای چه کسی اتفاق افتاد؟

Drop-offها را پیدا کنید

فرض کنید ۱۰۰۰ نفر فرایند درخواست را شروع می‌کنند.

۹۵۰ نفر مرحله اول را رد می‌کنند.

۹۲۰ نفر مرحله دوم.

اما فقط ۵۸۰ نفر مرحله سوم را کامل می‌کنند.

جایی بین مرحله دوم و سوم مسئله داریم.

ممکن است:

• فرم سخت باشد.
• اطلاعاتی لازم باشد که کاربر آن لحظه ندارد.
• Permission اشتباه باشد.
• Loading طولانی شود.
• یا اصطلاحی را نفهمد.

Analytics مشکل را نشان می‌دهد.

User Research دلیلش را پیدا می‌کند.

همین ترکیب Data + Research یکی از اصولی است که GOV.UK برای بهبود مستمر سرویس توصیه می‌کند.

Feedback داخل خود محصول را ساده کنید

اگر کاربر برای گزارش مشکل باید:

Screenshot بگیرد،

Email پیدا کند،

شماره Version بنویسد،

URL را Copy کند،

و توضیح دهد در کدام صفحه بوده،

احتمال زیادی وجود دارد که اصلاً Feedback ندهد.

یک Feedback Mechanism خوب می‌تواند بخشی از Context را خودش ثبت کند:

• Page
• User Role
• Browser
• Timestamp
• Version
• Correlation ID

بعد فقط از کاربر بپرسد:

چه چیزی درست کار نکرد؟

این کار Feedback را بیشتر و Debugging را سریع‌تر می‌کند.

اما مهم‌تر:

به Feedback جواب بدهید.

اگر کاربران ده بار یک مشکل را گزارش کنند و هیچ تغییری نبینند، بار یازدهم دیگر گزارش نمی‌دهند.

Feature زیاد الزاماً محصول بهتر نیست

یکی از راه‌های تبدیل یک سیستم خوب به یک سیستم سخت‌استفاده این است:

هر درخواست Feature را قبول کنیم.

واحد فروش یک گزینه می‌خواهد.

مالی یک Filter.

مدیریت یک Dashboard.

عملیات پنج Field.

سه سال بعد نرم‌افزار ۴۰۰ قابلیت دارد و کسی نمی‌داند نصف آن‌ها برای چیست.

Feature باید هزینه خودش را توجیه کند.

هزینه فقط Development نیست.

هر Feature جدید روی این‌ها اثر دارد:

• UI Complexity
• Testing
• Documentation
• Support
• Security
• Maintenance
• Training
• Performance
• و آینده Product

گاهی بهترین Feature جدید:

حذف یک Feature قدیمی است.

پلتفرم Live شده یعنی تازه Data واقعی داریم

قبل از Launch بخش زیادی از تصمیم‌های Product بر اساس Research و Hypothesis است.

بعد از Launch اتفاق مهمی می‌افتد:

رفتار واقعی داریم.

می‌بینیم کاربران واقعاً چه می‌کنند.

کدام Featureها استفاده می‌شوند.

کجا Drop می‌کنند.

چه چیزی را Search می‌کنند.

کجا Error می‌گیرند.

چه چیزی باعث Ticket می‌شود.

این مرحله پایان Product Development نیست.

شروع Iteration واقعی است.

GOV.UK Service Standard می‌گوید سرویس‌ها هیچ‌وقت واقعاً «تمام» نمی‌شوند و باید در طول عمرشان بر اساس تغییر نیاز کاربران و شواهد واقعی مرتب بهبود پیدا کنند.

Product موفق پلتفرمی نیست که Version 1 آن بی‌نقص باشد.

پلتفرمی است که:

Version بعدی‌اش از رفتار Version قبلی یاد گرفته باشد.

یک Framework عملی برای Adoption

از کجا بفهمیم تیم واقعاً پلتفرم را پذیرفته است؟

نه وقتی تمام Accountها ساخته شده‌اند.

نه وقتی Training تمام شده.

نه وقتی Software Live شده.

و حتی نه وقتی ۹۰ درصد کاربران یک بار Login کرده‌اند.

نشانه واقعی Adoption این است که پلتفرم تبدیل به مسیر طبیعی انجام کار شده باشد.

کاربر برای انجام کار اصلی اول به آن مراجعه کند.

نیازی به نگه‌داشتن سیستم موازی نداشته باشد.

اطلاعات را جای دیگری دوباره ثبت نکند.

Workaroundهای قدیمی کم شوند.

کاربران جدید بتوانند سریع‌تر یاد بگیرند.

و تیم بتواند بدون اجبار دائمی Management، فرایند را داخل همان Platform جلو ببرد.

این اتفاق فقط با UI زیبا ساخته نمی‌شود.

از شناخت کاربر شروع می‌شود.

با Workflow درست ادامه پیدا می‌کند.

به Integration، Performance و Accessibility وابسته است.

با Training و Change Management تقویت می‌شود.

و با Data و Feedback بهتر می‌شود.

پلتفرم خوب چیزی نیست که تیم مجبور باشد از آن استفاده کند.

چیزی است که بعد از مدتی ترجیح می‌دهد بدون آن کار نکند.

→بازگشت به مقالات