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

گزارش کاربردپذیری (Usability Report) چیست؟

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

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

آزمون خوب بود. گزارش نه. این مقاله دربارهٔ همان قدم آخری است که تعیین می‌کند آزمون به تغییر برسد یا در یک پوشه بماند.

گزارش کاربردپذیری چیست؟

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

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

گزارش چه چیزی را نشان می‌دهد

منبع پنج چیز را برمی‌شمارد که یک گزارش خوب نشان می‌دهد:

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

سه مورد آخر همان سه سنجهٔ استاندارد کاربردپذیری‌اند: اثربخشی، کارایی و رضایت. شرح بیشتر این سنجه‌ها را در سنجه‌های تجربهٔ کاربری آورده‌ام.

یک گزارش، سه خواننده

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

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

بیان مسئله، و اولویت

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

این قالب یک فایدهٔ پنهان دارد. پیشنهاد را از شکایت جدا می‌کند. «دکمه‌ها کوچک‌اند» یک شکایت است. «کاربران موبایل به دکمه‌های بزرگ‌تر نیاز دارند، چون ۲۳ درصدشان اشتباه زدند» یک مسئلهٔ قابل‌حل است، با یک عدد که بعد از تغییر می‌شود دوباره سنجیدش.

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

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

هفت گام نوشتن گزارش

منبع فرایند را در هفت گام شرح می‌دهد. نکتهٔ مهمش این است که گزارش از قبل از آزمون شروع می‌شود، نه بعد از آن.

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

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

چالش‌ها

منبع شش چالش رایج را نام می‌برد:

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

گزارشی که خوانده شود

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

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

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

گزارش کاربردپذیری در بافت فارسی

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

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

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

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

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

جمع‌بندی

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

اگر یک جمله بماند، همین باشد: گزارش برای تغییر نوشته می‌شود، نه برای بایگانی. اگر کسی آن را نخواند یا به کاری نرسد، آزمون هم انگار انجام نشده است.