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

آزمون درختی (Tree Testing) چیست؟

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

آزمون درختی (Tree Testing) روشی است برای سنجیدن اینکه ساختار ناوبری شما قابل‌فهم است یا نه — بدون اینکه هیچ صفحه‌ای طراحی شده باشد. به شرکت‌کننده فقط فهرستی متنی از دسته‌ها و زیردسته‌ها نشان می‌دهید (همان «درخت») و از او می‌خواهید کاری را انجام دهد: «می‌خواهید بفهمید هزینهٔ ارسال به شهرستان چقدر است؛ کجا کلیک می‌کنید؟» او در درخت پیش می‌رود و شما می‌بینید کجا می‌رسد.

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

چطور اجرا می‌شود

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

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

چهار نتیجه و تلهٔ موفقیت غیرمستقیم

خروجی آزمون درختی معمولاً در چهار دسته گزارش می‌شود:

سه‌تای اول روشن‌اند، اما آن‌که بیشترین سوءتفاهم را می‌سازد موفقیت غیرمستقیم است: کاربر بالاخره به صفحهٔ درست رسیده، ولی اول جای دیگری رفته و برگشته. این در گزارش‌ها معمولاً در ستون «موفق» می‌نشیند و نرخ موفقیت را دلگرم‌کننده نشان می‌دهد.

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

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

اعداد را چطور بخوانیم

این بخش هم افزودهٔ مترجم است، چون خروجی خام ابزارها معمولاً چند عدد است و تیم‌ها نمی‌دانند کدامش مهم است. سه چیز را باید نگاه کنید:

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

دربارهٔ آستانه‌ها هم یک هشدار لازم است: عدد مطلق به‌تنهایی معنای زیادی ندارد، چون کاملاً به سختی وظیفه‌هایی که نوشته‌اید بستگی دارد. اگر وظیفه‌ها ساده باشند، ۹۰ درصد چیز خاصی را ثابت نمی‌کند. کاربرد اصلی این اعداد مقایسه‌ای است: نسخهٔ الف در برابر نسخهٔ ب با همان وظیفه‌ها و همان جمعیت، یا ساختار فعلی در برابر ساختار پیشنهادی. برای همین، اگر می‌خواهید آزمون درختی واقعاً به تصمیم ختم شود، از اول دو نسخه بسازید و هر دو را بیازمایید؛ آزمون تک‌نسخه‌ای معمولاً به بحث دربارهٔ اینکه «۷۲ درصد خوب است یا بد؟» ختم می‌شود و همان‌جا می‌ماند.

و یک نکتهٔ عملی برای گزارش‌دادن: به‌جای اسلاید پر از درصد، برای هر وظیفهٔ شکست‌خورده یک خط بنویسید که می‌گوید کاربران کجا رفتند و پیشنهاد شما چیست. تصمیم‌گیرنده با «۳۸ درصد موفقیت مستقیم» کاری نمی‌تواند بکند، اما با «بیشتر کاربران هزینهٔ ارسال را زیر پشتیبانی می‌جویند؛ پیشنهاد می‌کنم آن را به راهنمای خرید منتقل کنیم و یک ارجاع در پشتیبانی بگذاریم» می‌تواند.

نسبتش با دسته‌بندی کارت

این دو روش اغلب با هم اشتباه می‌شوند، در حالی که دو سر یک فرایندند:

• - دسته‌بندی کارت: تولیدی است. کاربران به شما می‌گویند چه چیزهایی به هم مربوط‌اند و آن‌ها را چه می‌نامند. خروجی‌اش پیشنهاد ساختار است.
• - آزمون درختی: ارزیابانه است. ساختاری که ساخته‌اید را می‌سنجد. خروجی‌اش عدد است، نه پیشنهاد.

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

یک نکتهٔ مهم هم دربارهٔ ترتیب زمانی: بهترین زمان این آزمون پیش از شروع طراحی رابط است. اگر تا وقتی صفحه‌ها ساخته شده‌اند صبر کنید، تغییر ساختار به معنی دوباره‌کاری در طراحی و کد است و معمولاً کسی زیر بارش نمی‌رود؛ آن‌وقت با یک ساختار معیوب که همه می‌دانند معیوب است، سال‌ها زندگی می‌کنید.

وظیفه‌ای که نتیجه را خراب می‌کند

این بخش افزودهٔ مترجم است، چون کیفیت آزمون درختی تقریباً به‌طور کامل به کیفیت نوشتن وظیفه‌ها بستگی دارد. متداول‌ترین خطاها:

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

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

آزمون درختی در محصولات فارسی‌زبان

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

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

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

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

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

جمع‌بندی

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

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