نویسنده: تحریریهٔ بنیاد طراحی تعامل · منبع: بنیاد طراحی تعامل (IxDF) · ترجمهٔ آزاد: سپنتا پویا · تیر ۱۴۰۵ · زمان مطالعه: حدود ۱۲ دقیقه

ارزیابی اکتشافی (Heuristic Evaluation) چیست؟

💡 این متن ترجمهٔ آزاد است: محتوای مقالهٔ اصلی با نگارش مستقل فارسی و با ذکر منبع بازگو شده و ترجمهٔ کلمه‌به‌کلمه نیست. لینک مقالهٔ اصلی در پایین صفحه آمده است.

ارزیابی اکتشافی (Heuristic Evaluation) یک روش وارسی کاربردپذیری است که در آن گروه کوچکی از متخصصان، رابط کاربری یک محصول را با اتکا به مجموعه‌ای از «قاعده‌های سرانگشتی» شناخته‌شده — یعنی همان اکتشاف‌ها یا Heuristics — می‌سنجند تا مشکلات کاربردپذیری را پیش از آنکه به دست کاربر واقعی برسند، پیدا کنند. کلمهٔ «Heuristic» به معنای اصل یا میان‌بری تجربی است که معمولاً درست از آب درمی‌آید؛ در طراحی، این اصول چکیدهٔ ده‌ها سال تجربهٔ جمعی دربارهٔ آن چیزی‌اند که یک رابط را قابل‌استفاده می‌کند.

جذابیت این روش در سرعت و صرفه‌جویی آن است: به‌جای آنکه ماه‌ها منتظر بمانید تا آزمون کاربری برگزار کنید، چند متخصص در چند روز محصول را زیر ذره‌بین می‌برند و فهرستی از ایرادها بیرون می‌کشند. به همین دلیل ارزیابی اکتشافی را اغلب یک روش «تخفیفی» (discount usability) می‌نامند — ارزان، سریع و بدون نیاز به آزمایشگاه. این روش مکمل — و نه جایگزین — آزمون کاربردپذیری با کاربران واقعی است.

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

ارزیابی اکتشافی را Jakob Nielsen و Rolf Molich در سال ۱۹۹۰ معرفی کردند. ایدهٔ آن‌ها ساده اما انقلابی بود: لازم نیست برای پیداکردن هر ایراد کاربردپذیری، حتماً کاربر واقعی بیاورید؛ اگر مجموعه‌ای از اصول درست در اختیار متخصصان قرار دهید، آن‌ها می‌توانند بخش بزرگی از مشکلات را پیشاپیش تشخیص دهند. نیلسن بعدها این فهرست را پالایش کرد و به ده اصلی رساند که امروز به «ده اصل کاربردپذیری نیلسن» (Nielsen's 10 Usability Heuristics) مشهورند و گاه به شوخی «ده فرمان طراحی تعامل» خوانده می‌شوند.

نکتهٔ مهم این است که این ده اصل، دستورالعمل‌های خشک و ریز نیستند؛ آن‌ها «قاعده‌های کلی» (broad rules of thumb) هستند، نه راهنمای گام‌به‌گام. همین کلی‌بودن باعث می‌شود بعد از سه دهه هنوز برای وب، اپلیکیشن موبایل، دستیار صوتی و حتی رابط‌های واقعیت افزوده کاربرد داشته باشند.

ده اصل کاربردپذیری نیلسن

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

• - ۱. مرئی‌بودن وضعیت سیستم: سیستم باید همیشه از طریق بازخورد به‌موقع، کاربر را در جریان آنچه در حال رخ‌دادن است بگذارد. نوار پیشرفت هنگام آپلود، تیک «ارسال شد» زیر پیام، یا تغییر رنگ دکمه پس از کلیک — همه نمونه‌ای از این اصل‌اند. کاربری که نمی‌داند کجای فرایند است، اعتمادش را از دست می‌دهد.
• - ۲. تطابق میان سیستم و دنیای واقعی: سیستم باید به زبان کاربر حرف بزند، نه به زبان مهندسان. مفاهیم، کلمات و ترتیب کارها باید با انتظار طبیعی کاربر از دنیای واقعی هم‌خوان باشد؛ آیکون سطل زباله برای حذف، یا واژهٔ «سبد خرید» به‌جای اصطلاح فنی، از همین اصل می‌آیند.
• - ۳. کنترل و آزادی کاربر: کاربران مدام اشتباه می‌کنند؛ باید راه خروج روشنی داشته باشند. دکمهٔ «واگرد» (Undo) و «ازنو» (Redo)، لغو یک عملیات نیمه‌کاره و بازگشت آسان، به کاربر حس تسلط می‌دهد، نه حس به‌دام‌افتادن.
• - ۴. سازگاری و رعایت استانداردها: کاربر نباید مجبور شود حدس بزند که آیا کلمه‌ها، موقعیت‌ها و کنش‌های متفاوت معنای یکسانی دارند یا نه. رعایت قراردادهای رایج پلتفرم و یکدستی درون خودِ محصول، بار شناختی را کم می‌کند.
• - ۵. پیشگیری از خطا: بهتر از هر پیام خطای خوبی، طراحی‌ای است که اصلاً اجازه ندهد خطا رخ دهد. غیرفعال‌کردن دکمه تا وقتی فرم کامل نشده، یا گرفتن تأیید پیش از یک اقدام بازگشت‌ناپذیر، جلوی مشکل را از ریشه می‌گیرد.
• - ۶. تشخیص به‌جای یادآوری: بار حافظهٔ کاربر را کم کنید. گزینه‌ها، کنش‌ها و اطلاعات باید در لحظهٔ نیاز دیده شوند، نه اینکه کاربر مجبور باشد آن‌ها را از صفحهٔ قبل به خاطر بسپارد. این همان تفاوت میان «انتخاب از فهرست» و «به‌یادآوردن از حافظه» است — که پیوند نزدیکی با مدل‌های ذهنی کاربر دارد.
• - ۷. انعطاف‌پذیری و کارآمدی استفاده: رابط خوب هم برای تازه‌کار و هم برای حرفه‌ای جواب می‌دهد. میان‌برهای پنهانِ صفحه‌کلید یا امکان شخصی‌سازی به کاربر باتجربه سرعت می‌دهد، بی‌آنکه تازه‌کار را سردرگم کند.
• - ۸. طراحی زیبا و مینیمال: هر عنصر اضافی روی صفحه، توجه را از عناصر مهم می‌دزدد. رابط باید فقط اطلاعات مرتبط را نشان دهد؛ سادگی بصری، خودش نوعی کاربردپذیری است.
• - ۹. کمک به کاربر برای تشخیص، تحلیل و رفع خطا: پیام‌های خطا باید به زبان ساده بیان شوند، دقیقاً بگویند مشکل چیست و راه‌حل روشنی پیشنهاد دهند — نه اینکه فقط یک کد خطای مبهم نشان دهند.
• - ۱۰. کمک و مستندات: در حالت آرمانی سیستم باید بدون راهنما هم قابل‌استفاده باشد، اما داشتن مستندات در دسترس، متمرکز بر کار کاربر و قابل‌جست‌وجو، برای موقعیت‌های پیچیده ضروری است.

مزایا و محدودیت‌ها

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

اما این روش نقطه‌ضعف‌های جدی هم دارد که باید با چشم باز پذیرفت:

• - وابستگی به تخصص ارزیاب: کیفیت خروجی مستقیماً به دانش و تجربهٔ کسانی بستگی دارد که ارزیابی می‌کنند. ارزیاب کم‌تجربه، هم مشکلات را از دست می‌دهد و هم موارد بی‌اهمیت را بزرگ می‌کند.
• - تکیه بر فرض‌ها: متخصص بر پایهٔ تصور خودش از «کاربردپذیری خوب» قضاوت می‌کند، نه رفتار واقعی کاربر. گاهی این تصور با واقعیت میدان فاصله دارد.
• - خطای مثبت کاذب: پژوهش‌ها نشان داده‌اند بخش بزرگی از موارد گزارش‌شده در ارزیابی اکتشافی، در عمل اصلاً برای کاربران مشکل‌ساز نیستند؛ در برخی مطالعات این نسبت به حدود ۴۳٪ هم رسیده است.
• - پوشش محدود: ارزیابی اکتشافی به‌تنهایی تنها بخشی از مشکلات واقعی را می‌یابد؛ برآوردهایی وجود دارد که این روش حدود یک‌پنجم مشکلاتی را که آزمون کاربری کشف می‌کند، پیدا می‌کند.

پیام روشن است: ارزیابی اکتشافی را به‌عنوان یک صافیِ سریع و ارزان در ابتدای کار به‌کار ببرید، اما آن را جایگزین شنیدن صدای کاربر واقعی نکنید. بهترین نتیجه وقتی به‌دست می‌آید که این روش را در کنار آزمون کاربردپذیری بگذارید.

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

یک ارزیابی اکتشافیِ منظم، هشت گام کمابیش مشخص دارد:

• - ۱. دامنه و هدف را روشن کنید: تعیین کنید دقیقاً چه بخشی از محصول قرار است ارزیابی شود و به دنبال چه چیزی هستید — کل جریان خرید، یا فقط صفحهٔ تسویه‌حساب؟
• - ۲. کاربران هدف را بشناسید: با کمک پرسوناها تصویری روشن از کسی که محصول برایش ساخته شده در ذهن داشته باشید تا ارزیابی از دید او انجام شود، نه از دید خودتان.
• - ۳. سه تا پنج ارزیاب انتخاب کنید: نیلسن نشان داد که یک ارزیاب حدود ۳۵٪ مشکلات را می‌یابد، اما سه تا پنج ارزیاب با هم پوشش بسیار بهتری می‌دهند بی‌آنکه هزینه سرسام‌آور شود. بیش از پنج نفر معمولاً بازده نزولی دارد.
• - ۴. پنج تا ده اصل مرتبط را انتخاب کنید: لازم نیست همیشه هر ده اصل نیلسن را به‌کار ببرید؛ می‌توانید مجموعه‌ای متناسب با نوع محصول برگزینید یا اصول تخصصی‌تری برای حوزهٔ خاص خود اضافه کنید.
• - ۵. ارزیاب‌ها را توجیه کنید: پیش از شروع، به آن‌ها بگویید چه بخش‌هایی را باید بپوشانند و چه سناریوهایی را دنبال کنند تا کار پراکنده نشود.
• - ۶. وارسیِ نخست — کاوش آزاد: در دور اول، هر ارزیاب آزادانه با رابط کار می‌کند تا با جریان کلی و منطق محصول آشنا شود.
• - ۷. وارسیِ دوم — تحلیل نظام‌مند: در دور دوم، ارزیاب با تمرکز و به‌کمک همان فهرست اصول، تک‌تک عناصر را وارسی می‌کند و هر نقض اصل را همراه با محل و شدت آن ثبت می‌کند.
• - ۸. جمع‌بندی و گردآوری یافته‌ها: در پایان، ارزیاب‌ها یافته‌هایشان را کنار هم می‌گذارند، موارد تکراری را ادغام می‌کنند و مشکلات را بر اساس شدت رتبه‌بندی می‌کنند تا تیم بداند اول سراغ کدام برود.

خروجی نهایی معمولاً فهرستی رتبه‌بندی‌شده از مشکلات است؛ هر مورد به یک اصلِ نقض‌شده گره خورده و شدت آن (از «اشکال ظاهری» تا «فاجعهٔ کاربردپذیری») مشخص شده است. همین ساختار است که ارزیابی اکتشافی را به ابزاری عملی برای اولویت‌بندی اصلاحات تبدیل می‌کند.

شدت مشکل: بدون آن، گزارش قابل استفاده نیست

این بخش افزودهٔ مترجم است، چون خروجی معمول ارزیابی اکتشافی فهرستی بلند از ایرادهاست که همه هم‌وزن به نظر می‌رسند — و تیم توسعه با فهرست هم‌وزن هیچ کاری نمی‌تواند بکند. راه‌حل، دادن رتبهٔ شدت به هر مورد است. مقیاس متداول چهار پله دارد:

• - ۰ — ایراد نیست. ارزیاب اشتباه کرده یا موردی سلیقه‌ای است. این پله را حذف نکنید؛ وجودش باعث می‌شود ارزیاب‌ها راحت‌تر موارد مشکوک را مطرح کنند.
• - ۱ — زیبایی‌شناختی. آزاردهنده اما بی‌اثر بر انجام کار. اگر وقت اضافه بود اصلاح شود.
• - ۲ — جزئی. کاربر کند می‌شود ولی کار را تمام می‌کند.
• - ۳ — عمده. کاربر بخشی از کار را از دست می‌دهد یا مسیر را اشتباه می‌رود؛ باید اصلاح شود.
• - ۴ — فاجعه. کاربر نمی‌تواند کار را انجام دهد، داده از دست می‌رود، یا اعتماد می‌شکند. پیش از انتشار باید حل شود.

شدت را از سه چیز حساب کنید: تکرار (چند نفر و چند بار با آن روبه‌رو می‌شوند)، اثر (کاربر می‌تواند دورش بزند یا نه)، و پایداری (یک‌بار سکندری می‌خورد و یاد می‌گیرد، یا هر بار تکرار می‌شود). موردی که تکرار بالا و اثر کم دارد، معمولاً مهم‌تر از موردی است که فقط یک بار و برای اقلیتی رخ می‌دهد.

و یک قاعدهٔ عملی برای نوشتن هر مورد: اصل نقض‌شده + محل دقیق + شدت + پیشنهاد. جملهٔ «ناوبری گیج‌کننده است» به هیچ کاری ختم نمی‌شود؛ «نقض اصل ۱ (نمایش وضعیت سامانه) — در مرحلهٔ پرداخت هیچ نشانی از مرحلهٔ فعلی نیست — شدت ۳ — نشانگر مرحله اضافه شود» یک وظیفهٔ قابل واگذاری است.

چه چیزی را پیدا نمی‌کند

این بخش هم در منبع نیست و برای پرهیز از پرتکرارترین سوءاستفاده از این روش نوشته شده: جای‌گزین‌کردن آن با آزمون کاربر. ارزیابی اکتشافی ارزان و سریع است، اما نابیناییِ ساختاری دارد:

• - نمی‌داند کاربر واقعاً چه می‌خواهد. این روش می‌گوید رابط با اصول می‌خواند یا نه، نه اینکه محصول مسئلهٔ درستی را حل می‌کند یا نه. رابطی می‌تواند هر ده اصل را رعایت کند و هنوز چیزی باشد که کسی لازمش ندارد.
• - دانش دامنه را نمی‌بیند. ارزیابی که با کار یک حساب‌دار یا اپراتور انبار آشنا نیست، نمی‌فهمد کدام میان‌بُر برای متخصص حیاتی است. در محصولات تخصصی، این محدودیت جدی‌ترین است.
• - مشکل‌های خیالی می‌سازد. بخشی از یافته‌های هر ارزیابی اکتشافی چیزهایی هستند که کاربر واقعی هرگز به آن‌ها برنمی‌خورد. برای همین است که رتبهٔ شدت لازم است — و پلهٔ صفر.
• - به تعداد و ترکیب ارزیاب حساس است. یک ارزیاب بخش کوچکی از مشکلات را پیدا می‌کند؛ سه تا پنج ارزیاب مستقل پوشش را به‌شکل محسوسی بالا می‌برد. نکتهٔ کلیدی «مستقل» است: اگر با هم کار کنند، به سرعت هم‌نظر می‌شوند و همان نقطهٔ کور مشترک را می‌سازند.

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

اجرای ارزیابی روی رابط فارسی

این بخش هم افزودهٔ مترجم است و از اجرای این روش روی محصولات فارسی‌زبان می‌آید. چند بند به چک‌لیست اضافه کنید که در فهرست اصلی نیستند:

یکدستی جهت. بررسی کنید کل رابط راست‌به‌چپ است یا بخشی جا مانده: جهت پیکان‌ها، جای منوی همبرگری، ترتیب نوار پایین، جداکنندهٔ مسیر راهنما. نیمه‌قرینه بودن، نقض مستقیم اصل «یکدستی و استاندارد» است.

زبان سامانه در برابر زبان کاربر. اصل «تطابق سامانه با دنیای واقعی» در فارسی معمولاً با واژهٔ اداری نقض می‌شود: «کارتابل»، «امور مشترکین»، «ثبت درخواست». هر برچسبی که کاربر در گفت‌وگوی روزمره به کار نمی‌برد، یک مورد قابل ثبت است.

ارقام و قالب‌ها. پذیرش هم‌زمان ارقام فارسی و لاتین، نمایش قالب پیش از ورود (کد ملی، شبا، شمارهٔ موبایل)، جداکنندهٔ هزارگان، و تاریخ شمسی — هرکدام جای نقض «پیشگیری از خطا» است.

پیام خطا به فارسی انسانی. پیام‌هایی که ترجمهٔ تحت‌اللفظی متن انگلیسی‌اند («ورودی نامعتبر»، «عملیات ناموفق») اصل «کمک به تشخیص و رفع خطا» را نقض می‌کنند. معیار: پیام باید بگوید چه شد، چرا، و حالا چه باید کرد.

خوانایی متن فارسی. ارتفاع خط کم، قلم نامناسب برای اندازهٔ کوچک، و کنتراست ضعیف — سه نقض متداول که در بازبینی‌های چپ‌به‌راست کمتر دیده می‌شوند چون حروف متصل فارسی به فضای عمودی بیشتری نیاز دارند.

جمع‌بندی

• - ارزیابی اکتشافی یعنی سنجش رابط به‌دست چند متخصص با تکیه بر قاعده‌های سرانگشتیِ کاربردپذیری — روشی سریع، ارزان و مناسب مراحل اولیه.
• - این روش را نیلسن و مولیش در ۱۹۹۰ معرفی کردند و ستون فقرات آن، ده اصل کاربردپذیری نیلسن است.
• - ده اصل از «مرئی‌بودن وضعیت سیستم» تا «کمک و مستندات» را پوشش می‌دهند و پس از سه دهه هنوز روی هر پلتفرمی کاربرد دارند.
• - نقاط ضعف جدی دارد: وابستگی به تخصص ارزیاب، خطای مثبت کاذب و پوشش محدود؛ پس جایگزین آزمون کاربری نیست، مکمل آن است.
• - اجرای درست آن هشت گام دارد؛ سه تا پنج ارزیاب، بهترین تعادل میان پوشش و هزینه را می‌دهند.
• - بدون رتبهٔ شدت، گزارش فهرستی هم‌وزن است که تیم توسعه با آن کاری نمی‌تواند بکند؛ شدت را از تکرار، اثر و پایداری حساب کنید.
• - هر مورد را این‌طور بنویسید: اصل نقض‌شده + محل دقیق + شدت + پیشنهاد. «ناوبری گیج‌کننده است» به هیچ کاری ختم نمی‌شود.
• - این روش نمی‌گوید محصول مسئلهٔ درستی را حل می‌کند یا نه، و در محصولات تخصصی دانش دامنه را نمی‌بیند؛ جایش پیش از آزمون کاربر است نه به‌جای آن.
• - سه تا پنج ارزیابِ مستقل لازم است — اگر با هم کار کنند، هم‌نظر می‌شوند و همان نقطهٔ کور مشترک را می‌سازند.