راهنمای انجام یه UX Audit قبل از بازطراحی محصول
خلاصهٔ کاملتر
نویسنده میگه هر بازطراحی باید از یه متریک کسبوکار مشخص شروع بشه، مثلاً افت فعالسازی کاربرا یا رها کردن سبد خرید. باید این مشکل رو به یه جملهٔ قابل تست تبدیل کرد، مثلاً «کاربرا بین مرحلهٔ ارسال و پرداخت رها میکنن»، و بعد با گفتگوهای کوتاه ۱۵ دقیقهای با تیم محصول، پشتیبانی و فروش فهمید همه سر چی اختلاف نظر دارن. محدود کردن دامنهٔ بررسی به دو سه فلوی اصلی بهجای کل محصول، باعث میشه یافتهها عمیق و قابل اقدام باشن، نه سطحی.
قبل از نگاه کردن به هیچ صفحهای، باید دادههای واقعی جمع بشه: نرخ ریزش قیف، سشنریپلیهای کاربرایی که رها کردن، هیتمپ، تیکتهای پشتیبانی دستهبندیشده بر اساس فیچر، و نظرات اخیر کاربرا. اگه یه فیچر هم آمار قیف تمیزی داشته باشه هم حجم بالای تیکت، احتمالاً یه مشکلی هست که آنالیتیکس بهتنهایی نشونش نمیده. بعدش باید مسیر کامل کاربر رو برای فلوهای پولسازتر مثل آنبوردینگ، فعالسازی، پرداخت و تمدید، قدمبهقدم نقشهبرداری کرد.
مرحلهٔ بعد ارزیابی اکتشافیه: هر صفحه رو در برابر ده اصل قابلیت استفادهٔ نیلسن چک میکنن و هر تخلف رو با شواهد رفتاری ثبت میکنن، نه با قضاوت شخصی. طبق دادههای خود نیلسن، یه ارزیاب تنها حدود ۳۵ درصد مشکلات یه رابط کاربری رو پیدا میکنه، برای همین سه تا پنج ارزیاب مستقل توصیه میشه. بعدش باید با پنج تا هشت نفر بیرون از تیم، همون تسکهای نقشهٔ فلو رو بدون کمک تست کرد؛ چون آدمای بیرون از تیم دانش داخلی محصول رو ندارن و مشکلاتی که تو جلسات داخلی دیده نمیشن رو ظرف چند ثانیه پیدا میکنن.
نویسنده تأکید میکنه بررسی دسترسپذیری (طبق معیارهای WCAG مثل کنتراست رنگ، ناوبری با کیبورد و لیبل فرمها) و سرعت بارگذاری (Core Web Vitals) باید همون موقع انجام بشه، چون بازسازی یه فرم برای سرعت وقتی هنوز با کیبورد کار نمیکنه، هزینهٔ دوبارهکاری داره. در کنار لیست مشکلات، یه لیست جداگونه از چیزایی که کاربرا بدون مشکل انجام میدن هم نگه داشته میشه تا بازطراحی این بخشها رو خراب نکنه.
در آخر همهٔ یافتهها بر اساس میزان تأثیر روی کاربر و هزینهٔ اجراش امتیازدهی و رتبهبندی میشن، و خروجی نهایی شامل لیست رتبهبندیشدهٔ مشکلات، لیست چیزایی که نباید تغییر کنن، و عدد فعلی همون متریک اولیهست تا بعداً بشه ثابت کرد بازطراحی واقعاً کمک کرده یا نه.
نکات کلیدی:
- طبق دادههای نیلسن، یه ارزیاب تنها حدود ۳۵٪ مشکلات یه رابط کاربری رو پیدا میکنه؛ به همین خاطر سه تا پنج ارزیاب مستقل توصیه میشه
- تست کاربردپذیری باید با پنج تا هشت نفر بیرون از تیم و بدون راهنمایی انجام بشه
- بررسی دسترسپذیری (WCAG) و سرعت (Core Web Vitals) باید همزمان با بررسی طراحی انجام بشه، نه بعدش
- خروجی نهایی audit باید شامل لیست رتبهبندیشدهٔ مشکلات، لیست چیزای دستنخورده، و متریک پایه برای مقایسهٔ بعد از بازطراحی باشه




